On Oct 7, 2011, at 12:28 PM, Miguel A. Garcia wrote:
>
>
> On 07/10/2011 12:17, Saul Ibarra Corretge wrote:
>> Hi,
>>
>> On Oct 7, 2011, at 8:09 AM, Miguel A. Garcia wrote:
>>
>>>
>>>
>>> On 07/10/2011 0:57, Ben Campbell wrote:
>>>
>>>>> 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?
>>>>
>>>
>>> It is hard to determine what the future will bring. If we remove the extensibility now, and in the future we want to create an extension, then we will be forced to create a new SDP attribute. If we have the extensibility in place, but not the IANA registry, we can always create the IANA registry at a later point.
>>>
>>> So, I am leaning towards being conservative, and allow the extensibility of the SDP 'chatroom' attribute, without having an IANA registry at this point.
>>>
>>
>> At some point we did consider extending this attribute to specify that you may send some custom arbitrary data within a chat stream, for example, so if a server would add 'x-something' to the 'chatroom' attribute the client would know that it may send this kind of data. I'd like to see extensibility for 'chatroom' allowed.
>
> I agree with the extensibility of the attribute. I believe we can have a policy indicating that if someone wants to extend this attribute for their own purpose, they should prepend the value with the reversed DNS name of the organization, for example: com.example.foo-chat. For the time being, this seems to be enough.
>
+1
The reversed DNS name of the organization seems good to me.
Regards,
--
Saúl Ibarra Corretgé
AG Projects
_______________________________________________
Simple mailing list
Simple@...
https://www.ietf.org/mailman/listinfo/simple