Re: [AVT] Open issue on hdrext draft

[Tom Taylor <[e-mail]>]

This was the last word on the topic, quite a while ago. I think we have 
agreement on Expert Review and a publicly available specification. One of the 
criteria for the expert would be to prevent excessive duplication of 
functionality. What else?

Magnus Westerlund wrote:
> 
> Dave Singer skrev:
>> At 13:43  +0200 4/10/07, Magnus Westerlund wrote:
>>> [e-mail] skrev:
>>>
>>> What we are discussing is what rules applies for the IETF URN space,
>>> i.e. the header extensions that will look like they are blessed by IETF.
>>> The current draft version was in fact a) as this specified
>>> "Specification Required" from RFC 2434:
>>>
>>> "      Specification Required - Values and their meaning must be
>>>            documented in an RFC or other permanent and readily available
>>>            reference, in sufficient detail so that interoperability
>>>            between independent implementations is possible."
>>>
>>> I think A is fine but would probably prefer this to be b) with explicit
>>> rule requiring a publicly available specification.
>> I'm sorry, I may have mis-written something, since I tried to agree with
>> you here!  The current intention is that for the IETF URN space, a
>> standards-track RFC is required.  And that for IANA registration, an
>> IETF URN is required:
>>
>> "To be registered
>>    with IANA, the extension MUST use this IETF URN form; to use the IETF
>>    URN form, the extension MUST be defined in an RFC."
>>
>> If there is other text that isn't clear, can you tell me what it is?
> 
> In section 9.1 of draft-ietf-avt-rtp-hdrext-13:
> 
>    The rtp-hdrext namespace under urn:ietf:params: needs to be created
>    for management, referenced to RFCxxxx.  Additions in this namespace
>    shall be made on the basis of "Specification Required".
> 
> Which indicates that you can add new entires only requiring a
> specification which is actually a contradiction to what is written in
> Section 5:
> 
>    For extensions defined in RFCs, the URI used SHOULD be a URN starting
>    "urn:ietf:params:rtp-hdrext:" and followed by a registered,
>    descriptive name.  These URNs are managed by IANA.  To be registered
>    with IANA, the extension MUST use this IETF URN form; to use the IETF
>    URN form, the extension MUST be defined in an RFC.
> 
> 
> So I think you need to use the Standards Action level in 9.1 to match
> the section 5 text.
> 
>>> Having an expert look
>>> at any registrations to ensure that they are not totally wacko is in my
>>> book a good thing.
>> Me too, no dispute here.
>>
>>> But at the same time put minimal bar on the
>>> registrations. Other SDOs should basically be able to send in an email
>>> with a request containing a reference and things usually go through.
>>>
>> So, you would permit non-IETF URIs in the IANA registry, also, after,
>> what 'expert review' and with 'publicly available specification required'?
>>
>> That's fine by me also.
>>
> 
> I think we can allow people to use the public IANA registry for header
> extensions as long as there is a reasonable and publicly available.
> 
> Thus I would use Expert Review and some requirements on what the Expert
> is allowed to approve. Where the primary is: Open publicly available
> Specification. But there is likely that some more should be written.
> 
> Cheers
> 
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt