Re: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05

[Jonathan Lennox <[e-mail]>]

>> I think in reality, these URIs are used as nearly-opaque identifiers; the
>> exception being that a device that accepts the extension labeled with a URI
>> will necessarily know what the rules are for testing for equality with that URI.
>> 
>> But is there any reason to allow URIs that aren't URNs?  (Within URNs, issues
>> of equality testing, etc., are generally well-specified.)  The text seems to
>> suggest that the URI can be used to look up the meaning of the extension in
>> some way other than using the URI to index a database, but I don't see how
>> that can be made to work in practice.
>> And once the URIs are indexes, it seems best to limit them to being URNs.
>> Then again, XML namespaces are named by URIs, not just URNs.
>> 
>> The meaning of the sendonly, etc. attributes seems to be inadequately
>> specified.  Given that an extmap attribute can exist at the session level even
>> when media streams have different direction attributes, it seems that the
>> only simple rule is that the direction attribute in the extmap determines
>> which direction(s) the extension may be sent in theoretically, but because of
>> media directionality, the header will only be sent in a direction that is within
>> the directionality of the extmap and also the directionality of the stream.
> [Roni Even] OK, this is understood from the text since you do not send header extensions but adds them to an RTP packet. So I not sure that anyone will think to send RTP header extension to a unidirectional send stream. Yet it may be an interesting case when you support sending the same SDES item in both RTCP, which is  in RFC7941. I assume that in that case only RTCP will be used. 

The convention is to use URLs for proprietary / non-standardized header extensions, and this is existing practice in the wild.  For example, Chrome’s JSEP negotiates http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time.