Subject: Re: [Simple] Using nicknames in conference event packages (draft-ietf-simple-chat)

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Jul 2012 15:34:35 -0500

(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!

Ben.

On Jun 14, 2012, at 9:37 AM, Saúl Ibarra Corretgé wrote:

> Hi,
> 
> The draft-ietf-simple-chat specification states that the 'nickname' extension defined by XCON (RFC 6501) should be used to convey the nickname in the conference event package. I think section 7.4 could clarify this a bit more, since the following may happen:
> 
> Alice joins the conference from multiple endpoints, but same AoR. The way the conference event payload is defined, there will be only one <user> element, because the 'entity' attribute needs to be unique and in the context of a SIP conference the entity most likely will be the user's AoR. There will be 2 <endpoint> elements, representing each of Alice's SIP clients, so putting the nickname there would IMHO make more sense.
> 
> Also, using XCON just for the nickname attribute may not be desired by some (that's me at least :-) ) so what about adding something along these lines to section 7.4? "A conference focus MAY choose to use the display-text element in the 'endpoint' or 'user' element to convey the user's nickname".
> 
> 
> Regards,
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 11 Jul 2012 09:59:29 +0200

Hi Ben,

> 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 interoperabil…

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

---

From: "Geir Sandbakken (geirsand)" <[email-masked]>
Date: Fri, 13 Jul 2012 12:55:44 +0000

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-masked]> wrote:

>> 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:
>> 
>> 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.
>> 
>
>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.
>
>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
>
>
>