Subject: [Simple] Multiparty MSRP-01 submitted

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Mon, 28 Jan 2008 19:42:59 +0100

The new version tries to encapsulate the recent discussions from the
list about nicknames and consistent routing of messages.  It doesn't try
to resolve all open issues, but suggest a general direction for the way
forward.  

Change log:
1. Removed the Nickname URI.
2. The "Sending and Receiving Instant Messages" section no longer has
references to nicknames.
3. Changed the order of things as internal dependencies changed
4. Added a Nickname Provider URI which provides unambiguous scope for
the nickname.
5. The focus has to provide a single routable anonymous address called a
Replacement URI if privacy is requested by a participant when joining. 
6. Sending private messages are now limited to a single participant.
7. Removed the Siderbar section
8. Removed the section "Nicknames and Multiple SIP Addresses of Record"
as the nickname URI can't collide with SIP AOR's any more.
9. Added a 428 response code to REPORT request for "Private messages not
supported by recipient" feedback.
10. Removed the section "Mapping Nicknames to Other identities"

The most radical change not discussed on the list is the removal of
sidebars.  Supporting it will require some quite more semantics in the
MSRP mixer, and I wanted to know if the general direction is ok before
going down that path. OTOH, there are multiple reasons for keeping it
this way.  Firstly avoid making the composition complex when forwarding
messages having a multitude of replacement and participant URIs.  It
could prove error prone having anonymous URIs reviled unintentionally.
Secondly it is now possible to detect if a single recipient is not able
to receive private messages, and it can be rendered at the senders UI.
Thirdly we avoid having two different ways of doing sidebars when XCON
is in place.

If there is interest in having sidebar support in this memo, and I can
add extra semantics for this in next version of the draft.  

Thanks,
Geir Arne

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

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 29 Jan 2008 15:43:23 -0500

Geir Arne,

Thank you for your work in getting out a new version of this document.

First, I think the removal of sidebars is reasonable. In particular,  I 
found the -00 text on sidebars to be confusing. So in the absence of a 
concrete proposal for how to support sidebars, I favor not dealing with 
sidebars at all in this document.

Note: If this document is not going to provide support for sidebars, 
then I would recommend deleting the sentence in the introduction (3rd 
sentence of paragraph 3) that discusses the ability to form 
sub-conferences within an existing conference.

Second, I think that the discussion of nicknames has improved in this 
version of the document. I wholeheartedly agree with Brian Rosen that we 
should clearly separate routing issues from display issues, and the 
current text is better in this regard.

My understanding from reading the current document is that a nickname is 
a participant identity that is intended to be presented to the user by 
the UI. Furthermore, a nickname consists of a string (e.g. "HappyBob") 
along with a provider URI (e.g. [email-masked]) 
indicating the scope of the nickname. This URI specifies a service that 
is able to validate that a user with a particular SIP AOR has the right 
to assert the given nickname within the specified scope. The document 
doesn't specify a mechanism for validating the use of a nickname within 
a scope, however, if the scope is equal to the conference server then 
the validation is trivial.

Therefore, there appear to be (up to) three identities associated with a 
user: (1) A SIP AOR that a participant uses to communicate with the 
conference server (This is in particular the identity used for 
authentication to the conference server); (2) A SIP URI that is used to 
address private messages (This is the SIP URI that is distributed to 
other participants via the conference event package. This SIP URI is 
equal to the SIP AOR unless the participant uses a privacy header in the 
INVITE sent to the conference server); (3) a nickname that is intended 
to be rendered to other participants by their chat UI (This nickname is 
distributed to other conference participants via the conference event 
package). The first two identities are used for routing messages within 
a conference and should probably not be rendered by the UI (especially 
when the SIP URI is not meaningful, as in the case where the conference 
server assigns a replacement URI in response to a privacy request). The 
third identity is intended to be used for display to the end-user and is 
presumably the identity that will be referred to in the text of the 
conference messages.

Please correct me if I have misunderstood the intent of the document.

Given my understanding of nicknames in the current document, I have the 
following comments:

--- In regards to the first paragraph of Section 7, I think the 
functionality of receiving a private message without revealing a SIP AOR 
is orthogonal to providing a nickname for display to other users.

--- In paragraph four of Section 7, you mention that a conference server 
may not accept nicknames for a particular conference. In such a case 
should the UI render the SIP URI (obtained via the conference event 
package) to the end-user? (I think we should provide suggestions for UI 
rendering of identity. Otherwise we create user confusion when Alice 
believes she is rendered to Bob as [email-masked]', but in truth 
Bob's UI renders Alice as 'NoNickname#1'.)

--- In paragraph five of Section 7, I don't understand the sentence 
"Also referring to nicknames of participants inside the chat itself may 
be ambiguous if a participant is referring to a nickname without any 
scope." Could you please clarify?

--- In paragraph one of Section 7.1, I would suggest clarifying that 
this mechanism is to 'reserve' a nickname for a participant (for as long 
as the participant is a member of the conference). In particular, the 
text at the end of Section 7 uses the term 'reservation' for the first 
nickname operation. Therefore, I think it is important to also use the 
word 'reserve' in Section 7.1. (Similarly, I would modify paragraph six 
of 7.1 to say that the NICKNAME request fails if 'the same nickname has 
already been reserved by another participant')

--- In paragraph four (and five) of Section 7.1, I think it would be 
helpful to clarify that the server is validating a connection between a 
nickname and a participant's SIP AOR. That is, I think referring to a 
SIP URI here could be ambiguous because there are potentially many SIP 
URIs associated with a participant (e.g. the AOR in the from header, the 
GRUU in the contact header, the replacement URI created by the 
conference server to provide user anonymity, etc).

--- In paragraph six, the meaning of the text 'for which the conference 
server has no authority' is unclear to me. I would consider deleting 
this clause and just saying 'the Use-Nickname header contains a nickname 
provider URI for which the conference server is unable to validate the 
nicknames'.

--- In Section 9.4, there is an example of sending a private message 
addressed to Bob's nickname. In contrast, Section 6.2 specifies that 
private messages be addressed to the recipients SIP AOR (or replacement 
URI in the case where privacy was requested). I would recommend that the 
example in Section 9.4 be changed to remove reference to nicknames.

Finally, I have two other non-nickname related comments:

-- The second paragraph of section 5.2 refers to RFC 4574, I believe it 
should be RFC 4575

-- Paragraph 4 of Section 6.1 says "An MSRP switch that receives a SEND 
request from a participant SHOULD first verify that the From header 
field of the Message/CPIM wrapper is correctly populated with a valid 
URI as indicated earlier." I was unable to find the earlier indication 
that you refer to. Including a reference to a particular section of this 
document would be helpful.

Thanks again for your work on this document,
- Matt Lepinski :->

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 30 Jan 2008 12:04:52 +0100

Matt,

Thank you for the feedback.  I plan to publish another version including
your comments before the 17th of February.

Comments inline.

Geir Arne

> -----Original Message-----
> From: Matt Lepinski [mailto:[email-masked]]
> 
> Geir Arne,
> 

Done.

> the validation is trivial.

The validation is outside the scope of this document. Hopefully the
general nickname mechanism will provide it.  As you pointed out -
validation inside the conference instance it self or the conference
server should be trivial.

> Please correct me if I have misunderstood the intent of the document.

You are very much correct, and your description of the semantics reveals
an issue.  If there is a client that doesn't support nicknames, that
user will refer to other participants inside the chat by their SIP URI
(replacement URI or SIP AOR).  If another client supporting nicknames is
in the same conference, that user may refer to participants by their
nicknames.  This might lead to confusing chats where the users having
clients not supporting nicknames will not understand who it is being
referred to when nicknames are being used.  It seems like nicknames can
not be optional if used in a conference.

> is orthogonal to providing a nickname for display to other users.

Yes, the introduction of the nickname text has to be changed.  It is
still influenced by the pervious proposed mechanism which routed
messages and provided anonymity using the nickname itself.  

> Bob's UI renders Alice as 'NoNickname#1'.)

Good point.  Even if we make nicknames mandatory to support, it's a very
valid use case that the server will not allow nicknames.  That will not
lead to the confused situation of having some clients using nicknames -
while others do not.  Some clarifying text should be added to guide
implementers when nicknames are not allowed.

> scope." Could you please clarify?

What about: "Also referring to nicknames of participants inside the chat
itself may be ambiguous if a participant is referring to a nickname
without a reference to the nickname provider URI.  Two or more nicknames
can be equal inside a conference while having different nickname
providers URIs"

> already been reserved by another participant')

Done.  

> conference server to provide user anonymity, etc).

Done.  
 
> provider URI for which the conference server is unable to validate the

Much better.  Done.
 
> example in Section 9.4 be changed to remove reference to nicknames.

Missed that one.  Done.

> -- The second paragraph of section 5.2 refers to RFC 4574, I believe
it

Yes, done.

> document would be helpful.

Will add some clarifying text.

> Thanks again for your work on this document,

Thanks again for providing valuable feedback.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 30 Jan 2008 10:59:04 -0500

I haven't had time to organize a complete review of this version.  I agree
with Matt that it's much improved.

We have discussed the notion of validating nicknames as part of the
generalized nickname discussion.  The notion was that there was a URI that
you could ask "did you assign this nickname to this AoR?"  The text in the
document is consistent with that notion.

However, I thought we agreed that in MSRP Chat, the only nicknames allowed
were those assigned by the chat server.  Externally scoped nicks were not
considered.  Nicks were restricted to be unique within the chat server.
This avoided the issue of how you render the same nick from different
domains.

Since you don't describe the validation, and you don't describe how to
render nick collision from different domains, I think you can just drop the
whole validation URI.  You simply propose a nick, which has to be unique in
the chat server domain, it is accepted or not, and you use it.  

I also agree with Matt that you are known to the chat server by your AoR,
and you are known to other participants by the URI in the roster, which may
be your AoR or may be anonymous, and that's all there is.  Nicks show up in
the roster and are used to render UIs, and not to address.

I wonder if the server can assign you a nick if you don't ask for one.  It
could use any algorithm it wanted to.  It would put that in the nickname
field in the roster.  Then everyone has the same string to render for the
UI.

Brian

> Sent: Tuesday, January 29, 2008 3:43 PM
> To: [email-masked]
> Cc: Geir Arne Sandbakken
> Subject: Re: [Simple] Multiparty MSRP-01 submitted
> 
> Geir Arne,
>

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 30 Jan 2008 18:05:03 +0100

Brian,

Thank you for the feedback.  Comments inline.

Geir Arne

> From: Brian Rosen [mailto:[email-masked]]
> 
> render nick collision from different domains, I think you can just
drop
> the whole validation URI.  You simply propose a nick, which has to be 
> unique in the chat server domain, it is accepted or not, and you use
it.

If you think that the Nickname Provider URI (validation URI) is not
required to be backwards compatible with a general mechanism, I will be
happy to remove it.  Then the focus can have whatever policy it likes to
ensure uniqueness of the nickname string - as long as the nickname at
least is unique in a conference instance.  This leaves the clients in
the clear.

> and you are known to other participants by the URI in the roster,
which
> may be your AoR or may be anonymous, and that's all there is.  Nicks 
> show up in the roster and are used to render UIs, and not to address.

This was the intent of the current draft.  The reason I introduced the
"replacement URI" terminology was that I added the property of routing
anonymous messages inside the MSRP switch.  If it is ok to use the
terminology "anonymous URI" for such a purpose, I can remove the
"replacement URI" definition as well.  I just wanted to be cautions as
several specifications use/define anonymous URI, and did not want to
come into conflict with them.

> field in the roster.  Then everyone has the same string to render for
the

We can not have a conference/chat combining client with and without
nicknames, so the server would need to render something before the
participant sets it.  Alternatively the participant is not part of the
conference before the nickname is set.

> > >list about nicknames and consistent routing of messages.  It
doesn't
> try
> > >5. The focus has to provide a single routable anonymous address
called
> a
> > >9. Added a 428 response code to REPORT request for "Private
messages
> not

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 30 Jan 2008 14:56:51 -0500

> least is unique in a conference instance.  This leaves the clients in
I am okay with that.  The generalized mechanism can define the validation
URI idea.  

> come into conflict with them.
I think the draft ought to say that the URI in the roster must be useful for
addressing private messages or for any other addressing purposes within the
chat.  That means they are probably not in an anonymous domain, but rather a
random user part of a URI in the chat domain.  I don't think you need any
other mechanism in MSRP.

> conference before the nickname is set.
I think it's the former: if a participant didn't ask for a nickname, the
server assigns him one and shows it in the roster.  Everyone uses what's in
the roster for rendering UIs.  I don't like the other idea of not letting
the participant in the chat until he has a nickname.

Brian