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

From: Rohan Mahy <[email-masked]>
Date: Mon, 7 Mar 2005 11:32:47 -0600

On Mar 7, 2005, at 11:24, Brian Rosen wrote:

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

Brian,  what you are describing seems out of scope.  What identifier 
the user uses is irrelevant.  In the SIP case, an INVITE got sent by 
the IM client, or to the IM client.  I think you are trying to describe 
either the "Identity" of the user associated with the IM client, or the 
userpart of the the "Identity".  How you map between a "screen name" 
and the URI used to refer to the user of the client is WAY, WAY, WAY 
out of the scope of this discussion.

thanks,
-rohan

> 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
>
>> 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 15:27:31 -0500

Rohan

I don't agree.  We're trying, piecemeal, to design a system.  There is a
HUGE problem with the "piecemeal" part of that, and  I've been striving
mightily to try to keep the big picture in mind against a whole lot of folks
that want one part to get finished, and let the next part deal with whatever
mess is created by their part.

We are (apparently) trying to design this system so that works for simple
conferences with undefined structure, to IM systems with chat rooms, and
complex interactions between media streams described by XCON templates.

We've told anyone that tried to do something different that "It's
conferencing, see ...."  I basically agree with that, but we have to make it
work.

Here we have one piece, being designed, apparently, in isolation.  It has
one characteristic that interacts with one other characteristic in another
piece (you need a URI to kick someone out of a conference by SIP means
alone).

Now, I'd actually propose that such a mechanism is way beyond the kind of
functionality we need "by SIP means alone", but let's keep slogging.

Conference Package, proposes to make the URI the index into a structure of
users.  One might ask "do we need an index" and if so, what for?  Let's keep
slogging.

URI's are intrinsic to SIP, and SIP is to be used for IM and IM identifies
users by nicknames.

So is a nickname a URI? How, exactly?

How can we design a system for an IM chat room that allows someone to kick
someone else out of a chat room without agreeing on how we identify users?

If it's not in scope here, where is it in scope, and what do we need to do
to stop this until we get that settled?   

You need a URI to connect to a focus.  No one is arguing with that.  It's
not clear to me that said URI can, or should be, used for other purposes,
especially those which are used by one participant to affect another.
If we define nicknames better, lots of things might become clearer.

Brian

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Monday, March 07, 2005 12:33 PM
> To: Brian Rosen
> Cc: 'Johnston, Alan'; [email-masked]; [email-masked];
> [email-masked]; Rohan Mahy; [email-masked]
> Subject: Re: [Sipping] RE: Proposed resolution to index in conference-
> package
> 
> 
> > Well, you can't use anonymous URIs to INVITE someone.
> > 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
> > To get someone in, I "Invite" him via his nickname.
> > I don't have anything remotely like a URI in the general case.
>