Subject: Re: [Sipping] RE: Proposed resolution to index in conference-package

From: "Johnston, Alan" <[email-masked]>
Date: Mon, 07 Mar 2005 16:59:04 +0000

Brian,

We need the URI instead of a nickname because a nickname can not be put in a Refer-To header field for all the 3rd party operations in cc-conferencing.

Existing mechanisms break if we do away with URIs whereas you nothing breaks if we go with Cullen's proposal.

Thanks,
Alan

-----Original Message-----
From: Brian Rosen <[email-masked]>
To: 'Orit Levin' <[email-masked]>; 'Cullen Jennings' <[email-masked]>; 'sipping' <[email-masked]>
CC: Johnston, Alan <[email-masked]>; 'Rohan Mahy' <[email-masked]>; 'Roni Even' <[email-masked]>
Sent: Mon Mar 07 13:13:31 2005
Subject: RE: [Sipping] RE: Proposed resolution to index in conference-package

Orit

> As it has been defined for a couple of years now, the <user> 'entity' is
> the signaling (and otherwise control) means to get to this user.  From
> this perspective - the focus decision to not disclosure this property to
> other participants is what makes the user "anonymous". Note, that an
> "anonymous" user can still be addressed by another user by sending REFER
> to the focus. "Anonymous" doesn't imply anything about "why the user is
> anonymous" (e.g. because the <user> hasn't been authenticated or because
> the user wanted his/her identity be shielded from others). This
> additional aspect is not reflected in the basic package. I will be glad
> adding the clarification above to the text.

I think you are missing the point.

Yes, we can bend the URI into something we can use.
Should we?

I think not.  I think there is no reason to force the reference to
a participant to be a URI.  All we need to be able to do is to
represent a participant in the package, and either a URI or a nickname is a
reasonable way to do this.  I rather like the way most IM systems work,
and I think that it might work very well in a video conference.  I don't
think bending anonymous URIs for this purpose is a useful artifice.

There is no other reason in SIP conferencing to be able to have one
participant refer to another by a URI.  There aren't any mechanisms that
need this.

> > No, I don't think so.  At this level, there is no URI to
> > refer to the user, there is only the nickname.  You can make
> > the container have an id (a number that has no meaning) and
> > then have nicknames or uris as subelements, as long as both
> > are optional, or you can define entity as either a URI or a
> > nickname.
> >
> Although technically possible, I don't see a single reason for changing
> the indexing of the <users> container to another arbitrary index. (Very
> much in line with your own arguments regarding other containers.) If the
> focus doesn't want to expose any of the users' uris - then all users
> become "anonymous". The nickname should be placed in an existing
> <display-text> sub-element of a <user>.
Actually, I agree that creating a new index is not a good idea.
Here, there aren't two containers that need a common element correlator.
We don't need an index at all.

> > > As a result, requiring in the conference-package that the
> > <endpoint>
> > > media streams are globally indexed would put an unnecessary
> > burden on
> > > these applications and should be avoided.
> > I don't agree, or at least, I think it's a "don't care" situation.
> 
> Is it a "don't care" situation for all the media indexes and we can
> close this topic without touching the media definitons of -09?
> ...Or are you referring to some particular subset of the media
> information. If so, could you, please, clarify the part that you
> strongly disagree with, really want to be changed, and want continue
> discussing on the list and in the meeting?
All we need is an identifier that is common to the two media containers.
Anything that appears in both that can be used to relate them when they
appear in both containers will do.  The label serves that purpose.

> 
> > If you have an XCON conference, then you always have labels.
> > It may not be necessary, even in an XCON conference to have
> > the participants label their streams, especially if they only
> > contribute one stream for each possible media type.  In that
> > case, as in the case of a conference server that is not XCON
> > compliant, the focus can make up any name it likes (including
> > "1", "2" or "3") to use for the element id.  There is no need
> > for another indexing element.  The only reason you need them
> > is to correlate streams in active and available, and the
> > label is a unique identifier.
> >
> When you define an "index" in the package you must define its scope. All
> systems will have to apply to this definition. You can not say that
> "label" is the media index for endpoint media streams  without mandating
> it being unique in the context of the whole conference for every system.
> ... And this is a big and unnecessary burden to those simple
> conferencing system which will not use the available and active
> containers.
Yes, the label has to be unique within the conference.
They have to be unique per function, not per participant, right?
However, it's the focus that is supplying the NOTIFY here.
I'm not sure I understand what you are worried about.

If there is a template, the template defines the labels, and participants
would need to use those labels if they wanted things to work.

On simple conferences, I don't think you would see labels on the participant
SDP, but if you did the focus is free to ignore them and supply whatever
labels it likes on the NOTIFY, since they have no defined meaning in the
conference.  

Let's take an example.
Suppose there are no labels, but there is a single audio in and audio out
from each participant.

It's always confusing what the reference point for in and out is (focus or
participant).  Let's say two participants self-label streams "audio-in" and
"audio-out" but exchange the direction (one labels them with respect to
itself, the other labels them with respect to the server).  I would say that
the focus, in the NOTIFY, could ignore the labels used on the participant
SDP.  I would say it would be VERY confusing if it reproduced them the way
the participants labeled them.  I would go so far as to say that labels
applied when there is no template are explicitly ignored by the focus, and
the focus is free to use whatever labels it likes in the NOTIFY (as long as
they are unique)

Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Mar 2005 12:24:44 -0500

Well, you can’t use anonymous URIs to INVITE someone.
If you had an anonymous URI that the focus generated, you could use it to
kick someone out, and I had not recalled that problem, so it looks like I
have to cave, even if I think it’s really poor system design.

But, let’s ask the question that Miguel and Aki and others keep asking, how
do I make current IM chat rooms work?

To get someone in, I “Invite” him via his nickname.
I don’t have anything remotely like a URI in the general case.

To kick him out, I use his nickname.

Every reference I have to participants are nicknames.  

What do we do?

One possibility is that nickname@imservice is your URI, and not an anonymous
URI. Of course “nickname” <anythingyouwant@imservice> is equivalent.

Is that the way you think it works?
We have to DEFINE this somehow, somewhere, because I clearly want the right
thing to happen when I conference participants from independent IM services.
Here “right thing” means my UI uniformly uses nicknames, and not something
else.

It’s definitely not an anonymous URI.

Brian

________________________________________
From: Johnston, Alan [mailto:[email-masked]] 
Sent: Monday, March 07, 2005 11:59 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] RE: Proposed resolution to index in
conference-package

Brian,

We need the URI instead of a nickname because a nickname can not be put in a
Refer-To header field for all the 3rd party operations in cc-conferencing.

Existing mechanisms break if we do away with URIs whereas you nothing breaks
if we go with Cullen's proposal.

Thanks,
Alan

-----Original Message-----
From: Brian Rosen <[email-masked]>
To: 'Orit Levin' <[email-masked]>; 'Cullen Jennings'
<[email-masked]>; 'sipping' <[email-masked]>
CC: Johnston, Alan <[email-masked]>; 'Rohan Mahy' <[email-masked]>;
'Roni Even' <[email-masked]>
Sent: Mon Mar 07 13:13:31 2005
Subject: RE: [Sipping] RE: Proposed resolution to index in
conference-package

Orit

Let's take an example.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2005 13:40:32 -0500

I haven't been following this closely, but it sounds like the semantics 
of nicknames still aren't nailed down. What is the lifetime of the 
binding of a nickname to a user? Is it simply a single conference, or is 
it some extended period of time? And if it is for an extended period of 
time, what manages the namespace of nicknames?

If it is just for the duration of a conference, then it isn't especially 
useful for inviting people to the conference.

If it is for an extended period of time, then it needs something to 
manage the namespace, and the combination of the nickname and the 
identification of the namespace could be represented as a URI.

Even nicknames that are scoped to a conference could be rendered as URIs 
that are bound to users only for the duration of the conference.

My feeling is that nicknames bound only to a conference are likely to be 
a source of trouble. I spend a good deal of time in conferences, often 
with much the same set of people. It would be very misleading if in my 
conference on monday the RedBarron was Joe, but on Tuesday Alice got to 
the conference before Joe did and grabbed the RedBarron nickname.

Nicknames seem to me to be a feature of an anonomization service. It 
could be combined with a conferencing service, or not.

This of course has no real impact on how it might appear in a UI. It 
would be quite possible for a UI to recognize some forms of URI as 
representing nicknames and render those in the UI in a friendly form.

	Paul