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.
/Miguel
>
>
> Regards,
>
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Simple mailing list
Simple@...
https://www.ietf.org/mailman/listinfo/simple