Subject: [Simple] comments on draft-ietf-simple-chat

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Jul 2007 17:09:41 -0400

The draft worries about MSRP chatrooms negotiating the capability for 
private and sidebar functions. Wouldn't it be easier to require all MSRP 
  mixers to support this functionality? Then you only need to worry 
about conference-unaware participants.

Figure 1: should clarify that this is showing only the MSRP 
relationship, not the SIP one.

> The conference focus of a chat room MUST learn the chatroom
>    capabilities of each participant that joins the chat room, and MUST
>    inform the MSRP mixer of such support.  This is to prevent that the
>    MSRP mixer distributes private messages to participants who do not
>    support private messaging.

this text seems out of place here since you havent said anything about 
what is involved in learning such capabilities.

> In particular, this specification does not provide
>    a general mechanism for domains issuing nicknames, other than the
>    domain of the conference server.  

I think this is good, but the conversational text above talks about 
domain nicknames. I think it should speak only of chatroom nicknames.

> An example of a nickname is:
> 
>           sip:[email-masked]

If a nickname is scoped to a conference, the URI has to include a 
conference identifier so that such URIs are unique and properly scoped. 
I'd suggest something like:

sip:"msrp-nicknames" "/" <nickname> "/" <conf-uri-userpart> @ domain

> The
>    validation can also fail, e.g., if the Use-Nickname header contains a
>    nickname URI for which the conference server has no authority and the
>    conference server does not have the means to validate the nickname
>    from the domain that issued it.  

This seems to say that what a user should be able to reserve is ONLY the 
  <nickname> part above, so that the only error possible is that the 
nickname is in use.

I'd suggest that the text on nicknames clarify why this is IM specific. 
I think the reason is, that unlike audio or video, IM's contain sender 
identifiers as part of the media, and the purpose of this function is 
the IM-specific process of their reservation.

In fact, this is not entirely true; there is a rough equivalent in RTP 
which is the CNAME. There is a media-specific (i.e., RTP-based) approach 
for declaring (if not reserving) cnames, which is via RTCP. So this is 
really just an analagous function.

> A policy in the
>    MSRP mixer determines whether avoidance of collisions between
>    nicknames and regular Addresses of Record is enforced.

Practically speaking this is impossible to do. This is why I suggest 
formal structure around the user part of the URI to guarantee this.

> A policy in the conference
>    server determines whether a user who is participating in the
>    conference from various UAs is allowed to use the same nickname
>    across those UAs.  

This requires knowledge of this alias relationship which may be hard or 
impossible to know. Why is this needed?

> If the sender of the message wants to remain anonymous to the rest of
>    the participants, and providing that the policy of the conference
>    allows anonymous participation, the creator SHOULD populate the From
>    header of the Message/CPIM body with an anonymous identity, e.g.,
>    using the "anonymous" SIP URI as described in RFC 3261 [RFC3261]

Ugh, this is a bug I'd rather not propagate....

> 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.  If the
>    URI included in the From header field of the Message/CPIM wrapper is
>    not valid (e.g, because it does not "belong" to the user), then the
>    MSRP switch MUST generate a 403 response and MUST NOT forward the
>    SEND request to any of the participants.  Otherwise, the MSRP switch
>    SHOULD generate a 200 response according to the MSRP rules for
>    response generation.

Hmm, I wonder if, you take the model that NICKNAME is like CNAME/SSRC, 
then the only thing that you would be allowed send in the MSRP is the 
nickname, and then in that case this authentication is easy - you only 
need to verify that the sender had reserved that nickname. Would allow a 
much lighter relationship between the focus and the msrp switch.

Section 7 - should break it up into sections on client and switch 
behavior requirements.

>  Then the MSRP switch should inspect the To header field of the
>    Message/CPIM wrapper.  If the To header field of the Message/CPIM
>    wrapper contains the chat room URI, the MSRP switch can generate a
>    copy of the SEND request to each of the participants in the
>    conference except the sender. 

MUST generate a copy

Suggest merging 7.1 and 7.2 since they are largely the same, differing 
only in construction and interpreation of To field.

>  Sidebars
> 
>    This document does not provide any protocol means to create,
>    manipulate, or send messages to sidebars.  In many cases, a sidebar
>    is a logical subgroup of participants which exists only in each of
>    the recipients endpoints.  Sending a message to the sidebar is
>    modelled as a private message addressed to each of the members of the
>    sidebar.  As such, it is to possible to re-create the 'sidebar user
>    experience' totally in the endpoints by correlating collections of
>    private messages, thus, this document does not create any sidebar-
>    specific mechanism.

I'd suggest that private messaging is distinct from a sidebar. The 
latter is an object that is really a full conference within a 
conference, allowing for audio and video. Private messaging is a much 
more lightweight, transient form of communication.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 30 Jul 2007 13:30:03 +0300

Jonathan,

thanks for your comments. In order to keep the discussion under control, 
I am going to split your mail in a series open issues and post 
separately. So folks interested in the discussion, I will suggest to not 
reply to this e-mail and wait for each separate post.

/Miguel

Jonathan Rosenberg wrote:
>  mixers to support this functionality? Then you only need to worry about 
> conference-unaware participants.
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland