[RTW] [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"

[DRAGE, Keith (Keith)]

> > Assuming the profile is intended to be proposed standard, 
> then presumably you need to ensure all the constituent parts 
> are of proposed standard, or some equivalent referenceable 
> standard in some other organisation.
> The term I prefer in requirements is "stable reference" - we 
> need to know what we refer to.
> If we have a standards-track and a non-standards-track spec 
> for the same thing, I do think we should most often prefer 
> the standards-track spec, but I don't want to be dogmatic about it.

To profile a document to me has a defined meaning, and at least one ISO have defined, i.e. it takes an existing specification or specifications and states which requirements apply. Mandatory requirements can only be mandatory in the profile. Option requirements can become mandatory in the profile. RFC 2026 seems to use the term "Applicability statement" with much the same meaning.

As such, I believe the following applies (quoting from RFC 2026) but this is also my understanding for profile.

   An AS may not have a higher maturity level in the standards track
   than any standards-track TS on which the AS relies (see section 4.1).
   For example, a TS at Draft Standard level may be referenced by an AS
   at the Proposed Standard or Draft Standard level, but not by an AS at
   the Standard level.

So a profile at proposed standard needs to call up proposed standard specifications. I certainly allow us to take equivalent level documents from other organisations. 

I agree this is not the most important thing to get the charter resolved, but it may result in some other IETF groups needing to do a little more work than you expect. The biggest impact would be if iLBC is chosen as that has a codec definition (and payload format) at experimental level (RFC 3951 and RFC 3952). As to why they are experimental, I don't know, but I suspect that IETF was required to produce a payload definition, and for that it needed a referencerable document for the codec definition, but did not want to get involved at that time in standards track activity for the codec itself. (Nowadays that would not be a block to producing a standards track payload type).

In any case, it would seem to send the wrong message to profile something that is still formally experimental.

No issue with your other responses.

Keith

> -----Original Message-----
> From: dispatch-bounces at ietf.org 
> [mailto:dispatch-bounces at ietf.org] On Behalf Of Harald Alvestrand
> Sent: Thursday, January 06, 2011 5:07 PM
> To: DRAGE, Keith (Keith)
> Cc: rtc-web at alvestrand.no; 'dispatch at ietf.org'
> Subject: Re: [dispatch] Charter proposal: The activity 
> hitherto known as "RTC-WEB at IETF"
> 
> On 01/06/11 14:52, DRAGE, Keith (Keith) wrote:
> > Nowhere have you specified in the milestones what status 
> the intended deliverables are.
> Indeed, there isn't even an explicit list of deliverables. 
> That has to be added.
> My thinking goes like:
> 
> - Profile document (or documents): Proposed Standard
> - API mapping document: either Info or Proposed
> - Scenarios document (I think we need one): Informational
> 
> Thoughts?
> 
> > Assuming the profile is intended to be proposed standard, 
> then presumably you need to ensure all the constituent parts 
> are of proposed standard, or some equivalent referenceable 
> standard in some other organisation.
> The term I prefer in requirements is "stable reference" - we 
> need to know what we refer to.
> If we have a standards-track and a non-standards-track spec 
> for the same thing, I do think we should most often prefer 
> the standards-track spec, but I don't want to be dogmatic about it.
> > Opus does not yet have a RTP payload format, although I 
> understand one is planned, no drafts exist at the moment.
> Coordination item for the CODEC WG.
> > iLBC is defined as an experimental RFC - does it need to be 
> upgraded to standards track or is there some other reference.
> >
> > VP8 has no RTP payload format defined, unless it is 
> masquerading under some other name.
> I know some people have been working on this, but I don't 
> think there is a draft yet.
> > Presumably you need a paragraph in the charter relating to 
> working with other groups (in particular IETF WG) to ensure 
> that profiled specifications exist and are brought to 
> standards track level.
> Yes, definitely.
> > regards
> >
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: dispatch-bounces at ietf.org
> >> [mailto:dispatch-bounces at ietf.org] On Behalf Of Harald Alvestrand
> >> Sent: Thursday, January 06, 2011 11:54 AM
> >> To: 'dispatch at ietf.org'
> >> Cc: rtc-web at alvestrand.no
> >> Subject: [dispatch] Charter proposal: The activity 
> hitherto known as 
> >> "RTC-WEB at IETF"
> >>
> >> This is the first of 3 messages going to the DISPATCH list (in the 
> >> hope of keeping discussions somewhat organized).
> >>
> >> This is the draft of a charter for an IETF working group 
> to consider 
> >> the subject area of "Real time communication in the Web browser 
> >> platform".
> >> This is one of a paired set of activities, the other one 
> being a W3C 
> >> activity (either within an existing WG or in a new WG) 
> that defines 
> >> APIs to this functionality.
> >>
> >> The two other messages will contain the W3C proposed charter and a 
> >> kickoff for what's usually the most distracting topic in any such
> >> discussion: The name of the group.
> >> Without further ado:
> >>
> >> -------------------------------------
> >>
> >> Version: 2
> >>
> >> Possible Names:
> >> <This space deliberately left blank for later discussion>
> >>
> >> Body:
> >>
> >> Many implementations have been made that use a Web browser 
> to support 
> >> interactive communications directly between users including voice, 
> >> video, collaboration and gaming, but until now, such applications 
> >> have required the installation of nonstandard plugins and browser 
> >> extensions.
> >> There is a desire to standardize such functionality, so that this 
> >> type of application can be run in any compatible browser.
> >>
> >> Traditionally, the W3C has defined API and markup 
> languages such as 
> >> HTML that work in conjunction with with the IETF over the wire 
> >> protocols such as HTTP to allow web browsers to display media that 
> >> does not have real time interactive constraints with another human.
> >>
> >> The W3C and IETF plan to collaborate together in their traditional 
> >> way to meet the evolving needs of browsers.
> >> Specifically the IETF will provide a set of on the wire protocols, 
> >> including RTP, to meet the needs on interactive 
> communications, and 
> >> the W3C will define the API and markup to allow web application 
> >> developers to control the on the wire protocols. This will allow 
> >> application developers  to write applications that run in 
> a browser 
> >> and facilitate interactive communications between users 
> for voice and 
> >> video communications, collaboration, and gaming.
> >>
> >> This working group will select and define a minimal set of 
> protocols 
> >> that will enable browsers to:
> >>
> >> * have interactive real time voice and video between users 
> using RTP
> >> * interoperate with compatible voice and video systems 
> that are not 
> >> web based
> >> * support direct flows of non RTP application data between 
> browsers 
> >> for collaboration and gaming applications
> >>
> >> Fortunately very little development of new protocol at IETF is 
> >> required for this, only selection of existing protocols 
> and selection 
> >> of minimum capabilities to ensure interoperability. The following 
> >> protocols are candidates for including in the profile set:
> >>
> >> 1) RTP/ RTCP
> >>
> >> 2) a baseline audio codec for high quality interactive audio.
> >> Opus will be considered as one of the candidates
> >>
> >> 3) a baseline audio codec for PSTN interoperability. G.711 
> and iLBC 
> >> will be considered
> >>
> >> 4) a baseline video codec. H.264 and VP8 will be considered
> >>
> >> 5) Diffserv based QoS
> >>
> >> 6) NAT traversal using ICE
> >>
> >> 7) RFC 4833 based DTMF transport
> >>
> >> 8) RFC 4574 based Label support for identifying streams purpose
> >>
> >> 9) Secure RTP and keying
> >>
> >> 10) support for IPv4, IPv6 and dual stack browsers
> >>
> >> The working group will cooperate closely with the W3C 
> activity that 
> >> specifies a semantic level API that allows the control and 
> >> manipulation of all the functionality above. In addition, the API 
> >> needs to communicate state information and events about what is 
> >> happening in the browser that to applications running in 
> the browser. 
> >> These events and state need to include information such 
> as: receiving 
> >> RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP,  and 
> >> signalling state.
> >>
> >> The following topics will be out of scope for the initial phase of 
> >> the WG but could be added after a recharter: RTSP, RSVP, 
> NSIS, LOST, 
> >> Geolocation, IM&  Presence, NSIS, Resource Priority,
> >>
> >> Milestones:
> >>
> >> February 2011 Candidate "sample" documents circulated to DISPATCH
> >>
> >> March 2011 BOF at IETF Prague
> >>
> >> April 2011 WG charter approved by IESG. Chosen document 
> sets adopted 
> >> as WG documents
> >>
> >> May 2011 Functionality to include and main alternative protocols 
> >> identified
> >>
> >> July 2011 IETF meeting
> >>
> >> Aug 2011 Draft with text reflecting agreement of what the protocol 
> >> set should be
> >>
> >> Nov 2010 Documentation specifying mapping of protocol 
> functionality 
> >> to W3C-specified API produced
> >>
> >> Dec 2011 Protocol set specification to IESG
> >>
> >> April 2012 API mapping document to IESG
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch at ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >>
> 
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>