Re: Using nicknames in conference event packages (draft-ietf-simple-chat)

Hi Saúl Ibarra Corretgé,

Listening to implementers is important - and we value your feedback.  The
nickname has been discussed at lengths - in the approximate 20 revisions
of the draft numerous alternatives have been proposed.  This includes
usage of a nickname specific SIP AOR, a SIP URI parameter extension, a
nickname attribute extension of RFC 4575 that would have required a bis,
usage of display name part of the SIP AOR and finally the consensus
decision of utilizing the XCON method that extends the USER element of
4575 with a nickname attribute.

It's a bit risky to respond to either one of the alternatives from memory,
but I believe that using the display name of the SIP AOR would be
ambiguous for clients supporting or not supporting the extensions of this
draft. Enforcing the nickname uniqueness is done by the 423 response code
of the MSRP nickname request - and therefore is only applicable by UA's
supporting the request.

Thanks,
Geir A

On 7/11/12 9:59 AM, "Saúl Ibarra Corretgé" <[email protected]> wrote:

>Hi Ben,
>
>On Jul 10, 2012, at 10:34 PM, Ben Campbell wrote:
>
>> (as chair)
>> 
>> Hi, and sorry for the late response.
>> 
>> The decision to use the xcon conference event package format is the
>>result of an explicit SIMPLE consensus call back in December of 2010.
>>That doesn't mean we can't readdress it, but we would need a really new
>>and strong technical reason to do so at this late stage. (The draft is
>>in IESG evaluation.) See the following email and the resulting thread:
>> 
>> http://www.ietf.org/mail-archive/web/simple/current/msg09093.html
>> 
>> (as individual)
>> 
>> The current text in the draft says use of that format is RECOMMENDED,
>>i.e. it's at SHOULD strength. According to RFC 2119, that means the "...
>>may exist valid reasons in particular circumstances to ignore a
>>particular item, but the full implications must be understood and
>>carefully weighed before choosing a different course" allows an
>>implementation to choose another approach if there is good reason, and
>>the implementer is aware of the consequences of the decision."
>> 
>> It seems to me that an implementation could choose to user other
>>methods to express a nickname and not necessarily be non-compliant. But
>>I would be concerned that doing so could cause interoperability problems
>>between switches and clients.
>> 
>
>Thanks for your comments!
>
>It's unfortunate that I wasn't implementing nickname support back then
>:-S Anyway, here is my concern, mainly based in my experience with its
>implementation:
>
>The nickname is a replacement of a user's display name, and we have a way
>to set it (MSRP NICKNAME) but there doesn't seem to be a reliable way to
>convey this. If XCON is not implemented the draft doesn't specify how one
>should proceed. I applied Common Sense (TM) and used the display-text
>element in the User section (RFC 4575 payload). I'd love to see a mention
>about this in the draft.
>
>XCON is recommended, yes, but requiring it just for the <nickname>
>element feels to much to me. It would be desirable that endpoints not
>supporting XCON can also get the nickname in a non
>implementation-specific way which they can rely upon.
>
>This brings me to another concern: the draft says that
>
>"A main
>   difference is that a nickname is unique inside a chat room to allow
>   an unambiguous reference to a participant in the chat."
>
>since not all participants might be using a nickname, is the focus
>supposed to prevent setting a nickname which collides with a
>participant's display name? If the <display-text> element of a user or
>endpoint contains either a display name or a nickname (as I proposed
>above) then this should probably be checked, or endpoints connected to
>the focus could be confused about participant's identity.
>
>
>Regards,
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>
>
>_______________________________________________
>Simple mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/simple