> On Oct 6, 2011, at 2:59 PM, Miguel A. Garcia wrote:
>> the MSRP chat was reviewed in MMUSIC, and we got two main comments:
>> 1) extensibility of the 'chatroom' attribute in SDP. Do we need an IANA registry
>> 2) Privacy concerns of this attribute.
>> The review is here:
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg08940.html >>
>> For issue 1, I think that we don't need an IANA registry at this point, in particular because we are not expecting extensions to this attribute. My proposal is to simply indicate that organizations that want to extend this attribute and create new tokens should use their reversed names to avoid clashes among then.
> Out of curiosity, if we don't expect extensions, do we need the extension point int he ABNF?
We aren't always as good at predicting the future as we might wish, so I
think it is still good to include an extension point. But we don't need
to include a registry in that case - we can simply state that a revision
to the draft is required to make an extension.
> If an organization creates more than one extension token, is it up to that organization to coordinate them?
If the intent is to allow private extensions without registration, then
the ABNF needs to be modified to specify the syntax for the private
names (distinct from any future standardized values), and the usage
rules (e.g. reverse FQDN syntax) need to be spelled out.