Subject: RE: [Simple] Chat sessions

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2004 21:28:29 -0600

I agree with Jonathan's assessment of how this work should
proceed. Specifically, I want to reinforce the following
points:

 - Any nickname work should be done as part of a general
   conferencing solution, and should not be IM specific.

 - Sending of messages to a subset of users in a conference
   is *also* not IM specific, and will be addressed using
   media policy in XCON. It should not be defined using
   CPIM, since that will provide conflicting methods for
   providing this functionality.

Additionally, I feel *strongly* that specifying the use of
intentionally invalid URIs in the "From:" headers in CPIM
is a violation of the spirit of CPIM.

  "The URI indicates an address for the originator."

It would seem that creating intentionally invalid URIs
is counterindicated by the meaning of the word "address"
(in this context, a place where an entity may be reached
for the purposes of communication).

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, February 25, 2004 13:11
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Simple] Chat sessions
> 
> 
> To answer this question, in RTP, the SSRC is used for identification. 
> The SSRC is mapped to a name through the RTCP SDES packets, 
> which come 
> every once in a while, and bind the SSRC to a CNAME. The 
> CNAME can also 
> be associated with supplementary data, such as the NAME 
> parameter, which 
> basically provides a nickname. Its described in RFC3500 thusly:
> 
> > 6.5.2 NAME: User Name SDES Item
> > 
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     NAME=2    |     length    | common name of source       ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >    This is the real name used to describe the source, e.g., 
> "John Doe,
> >    Bit Recycler".  It may be in any form desired by the user.  For
> >    applications such as conferencing, this form of name may 
> be the most
> >    desirable for display in participant lists, and 
> therefore might be
> >    sent most frequently of those items other than CNAME.  
> Profiles MAY
> >    establish such priorities.  The NAME value is expected to remain
> >    constant at least for the duration of a session.  It 
> SHOULD NOT be
> >    relied upon to be unique among all participants in the session.
> 
> 
> I see the IM nickname as being equivalent; an in-band 
> identifier of the 
> user name.
> 
> RTP defines the scope of these nicknames as bound to a 
> session, and does 
> not require uniqueness. Thats a bit different than what is being 
> proposed here.
> 
> Note that we have always had a problem with SSRC/CNAME that 
> there was no 
> easy way to map them to a SIP URI that could be used for 
> signaling. That 
> is, the CNAME is not necessarily the SIP URI that one would 
> want to use 
> to contact the user. For example, if I'm in a conference and 
> I want to 
> have a private call with a user, outside of the conference, 
> what SIP URI 
> to use?
> 
> I also agree with comments raised by Brian and others that 
> requirements 
> for management of nicknames - creation, deletion, and scope - are not 
> tied to IM. If we need that functionality, we should 
> introduce them as 
> requirements in the general conferencing work. Additionally, the 
> mechanism for this management should not be IM specific. Seems to me 
> like CPCP would be the ideal way to set them up. I believe 
> they would be 
> useful for general conferencing as has been pointed out. The 
> only thing 
> thats really IM specific is how such information is conveyed in the 
> message; usage of From in cpim seems reasonable to me.
> 
> One other thing in the draft that I would like to point out, is that 
> there is a feature that allows for private conversations. 
> This is done 
> by allowing a user to address an IM to one or more group 
> participants, 
> using To and CC CPIM fields. To me, this is also another conference 
> function that is not specific to IM. In fact, I dont see how 
> it differs 
> from sidebars.
> 
> Thanks,
> Jonathan R.
> 
> Paul Kyzivat wrote:
> 
> > Hmm. I was wondering about that too. I guess one 
> possibility would be to 
> > send the mapping from SSRC in RTCP. (I am not very 
> knowledgable about 
> > RTP, but I think RTCP carries a mapping from SSRC to text names.)
> > 
> > Another way would be for the SSRC to itself be considered a form of 
> > nickname and be published as part of the conference state. 
> (I guess that 
> > would require a facility for multiple nicknames per participant.)
> > 
> >     Paul
> > 
> > [email-masked] wrote:
> > 
> >> Just out of curiosity: how do you transport the display name (nick 
> >> name) for audio or video? In RTP? or does the recipient 
> have to have 
> >> local mapping between SSRCs and display names?
> >>
> >> /Hisham
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>> ext Paul Kyzivat
> >>> Sent: 23.February.2004 18:56
> >>> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> >>> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo)
> >>> Subject: Re: [Simple] Chat sessions
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> [email-masked] wrote:
> >>>
> >>>> Thanks for your comments. See my comments inline.
> >>>>
> >>>>
> >>>>> From: ext Paul Kyzivat [mailto:[email-masked]]
> >>>>>
> >>>>> Its good to think about things like this. But I think the 
> >>>>
> >>>>
> >>> goal should
> >>>
> >>>>> not be to introduce special features for chat conferences. It 
> >>>>> should be to learn what features users of chat 
> conferences expect, 
> >>>>> and ensure that comparable features are available via our 
> >>>>> conference framework, and available with any media when 
> that makes 
> >>>>> sense. So I think some of these ideas need to flow back 
> into the 
> >>>>> conference framework.
> >>>>
> >>>>
> >>>> If we want to move things to the conference framework,
> >>>
> >>>
> >>> > then we need to develop a complete solution, based on
> >>> > requirements that... I dind't see so far. For instance,
> >>> > I believe all the requirements related to nicknames are
> >>> > addressing the session based conferences so far.
> >>> > We may want to extend those requriements, but there 
> aren't any now.
> >>>
> >>> I agree there aren't. I am suggesting that *where it makes sense* 
> >>> these should be advanced as requirements against conferences in 
> >>> general, rather than being focused as requirements only for chat 
> >>> conferences.
> >>>
> >>>
> >>>> Particularly, I don't know how useful is to use nicknames in
> >>>
> >>>
> >>> > an audio/video conference. The feature is useful in a conference
> >>> > of instance messages, but not so much in the other...
> >>> > Still, we may want to extend the conference package so that the
> >>> > user element can contain a <nickname> sub-element.
> >>> > This would allow a user to display the nickname of the 
> conferees,
> >>> > no matter what the media is.
> >>>
> >>> Exactly. This becomes interesting in multimedia conferences to.
> >>> For instance it becomes a tag to use in identifying 
> current speaker.
> >>>
> >>> It also may provide a better way to deal with anonymous 
> participants 
> >>> in all sorts of conferences, by giving them nicknames as 
> handles to 
> >>> reference them by.
> >>>
> >>> Then, instead of saying: "Will the anonymous participant with the 
> >>> deep voice please repeat his question?", you can say: 
> "Darth, will 
> >>> you please repeat your question?".
> >>>
> >>>
> >>>>> However it is relatively trivial to be more accomodating, 
> >>>>
> >>>>
> >>> adding and
> >>>
> >>>>> removing cpim wrappers according to the desires of the 
> individual 
> >>>>> endpoints.
> >>>>
> >>>>
> >>>> Basically, there are two ideas here: endpoints SHOULD use
> >>>
> >>>
> >>> > message/cpim when addressing a conference.
> >>> > The focus MUST use message/cpim. The idea is that the focus
> >>> > should indicate the nickname of the sender of the message,
> >>> > which is conveyed in the From header of the 
> message/cpim message.
> >>> > Endpoints SHOULD use messgae/cpim to relief the focus from
> >>> > wrapping messages when the focus distributes a copy.
> >>>
> >>> Sounds good to me.
> >>>
> >>>
> >>>>> Nickname management is problematic. It seems as though 
> >>>>
> >>>>
> >>> nicknames will
> >>>
> >>>>> need to be authenticated and authorized. But it isn't 
> at all clear 
> >>>>> that the focus is the right entity to do so. (The scope 
> is wrong.)
> >>>>
> >>>>
> >>>> I don't think a nickname has to be authorized. Users are 
> authorized,
> >>>
> >>>
> >>> > and once a user is authorized, she can choose any 
> available nickname.
> >>> > Is this what you meant?
> >>>
> >>>> Regarding the scope of the nicknames, I believe a 
> nickname should be
> >>>
> >>>
> >>> > unique within a conference server or an administrative domain.
> >>> > At least I don't see a valid requirement in getting nicknames
> >>> > valid across difrerent servers or different 
> administrative domains.
> >>>
> >>> I guess this depends on how large and long lived these scopes are.
> >>> It clearly isn't good if the scope is a single conference.
> >>>
> >>> It isn't good if it is a conference server either, if 
> that is just 
> >>> one of a large pool of independent servers that are 
> chosen at random 
> >>> as hosts for conferences.
> >>>
> >>> When the same group of users join in a number of 
> conferences over a 
> >>> period of time, within that scope a nickname should be bound to a 
> >>> user for as long as that user wants it to remain bound.
> >>>
> >>>
> >>>>> I think this would be better served by using real, 
> routable im: or 
> >>>>> sip: uris. As needed, service providers can exist to 
> host nicknames 
> >>>>> and forward requests addressed to them to other addresses.
> >>>>
> >>>>
> >>>> The point is that a nickname should not let you track 
> the real user.
> >>>
> >>>
> >>> > Only the conference server is able to map the real SIP 
> URI to the 
> >>> nickname,
> >>> > but not users. For instance, if user B receives an 
> instant message
> >>> > (through the conference server) from user A, B should 
> only see the
> >>> > nickname, unless A wants to disclose his real URI.
> >>>
> >>>> Making nicknames a real URI loose the semantics of the 
> "nickname".
> >>>
> >>>
> >>> > We don't want that behaviour, we want a nickname to 
> remain a nickname,
> >>> > something meaningless.
> >>>
> >>> That depends on how things are administered. There could be 
> >>> "nickname" servers, that are nothing but specialized 
> proxies. I would 
> >>> contract with one of these servers for whatever nicknames I want. 
> >>> These would be unique usernames within the domain managed by that 
> >>> server. Each would be configured to forward to an address of my 
> >>> choice. I would be given control to turn forwarding on and off 
> >>> selectively, so perhaps it would only work when I was 
> actively using 
> >>> a particular nickname in a conference.
> >>>
> >>> Then I could use the nickname as my address when joining a 
> >>> conference. I could permit the conference server to disclose this 
> >>> address, and yet my true identity would remain hidden.
> >>>
> >>> The advantage of this is that it decouples the administration of 
> >>> nickname namespaces from the administration of conference servers.
> >>>
> >>> But I am not necessarily opposed to coupling nickname 
> namespaces with 
> >>> conference administration *if* the scoping can be made reasonable.
> >>>
> >>>     Paul
> >>>
> >>>
> >>> _______________________________________________
> >>> Simple mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>
> >>
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Sat, 28 Feb 2004 11:11:56 +0200

>    conferencing solution, and should not be IM specific.

Agreed.

>    providing this functionality.

That's only if you think they provide the same functionality. Read my 
previous post - I think sidebars are orthogonal to sending a message to 
a subset of users in a conference (or in a conference sidebar, same thing).

> for the purposes of communication).

I'm open to suggestions on alternate solutions to fulfill the requirement.

Cheers,
Aki

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Sat, 28 Feb 2004 11:11:56 +0200

Agreed.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 28 Feb 2004 23:58:43 -0500

>>    providing this functionality.
\>
> a subset of users in a conference (or in a conference sidebar, same thing).

Certainly participants in a conference can try to note who some of the 
participants are and interact with them directly, and this is orthogonal 
with sidebars. But of course that only works if the participants 
disclose addresses that can be used to communicate directly with them.

If you want the conference focus to act as a broker in establishing 
communication between subsets of members of the conference, so that it 
can happen even when the participant identities are hidden, then I think 
you are very much into the realm of sidebars.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 28 Feb 2004 23:58:43 -0500

\>

	Paul