Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13

["Miguel A. Garcia" <[e-mail]>]

Enrico, Alexey:

I am pulling up your original review of draft-ietf-simple-chat back in 
February, and I will try to address the pending issues.

The current version of the draft is 16: 
http://datatracker.ietf.org/doc/draft-ietf-simple-chat/

See inline comments.

On 06/02/2012 10:50, Enrico Marocco wrote:
> Document: draft-ietf-simple-chat-13
> Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP)
> Reviewers: Alexey Melnicov and Enrico Marocco
> Review Date: 2012-02-06
> IETF Last Call Date: 2012-02-06
>
>
> Summary: This draft is almost ready for publication as a Proposed
> Standard, but has a major issue to be taken into consideration and a few
> minor issues to be fixed.
>
>
> Major Issue
>
> The document doesn't describe allowed characters in Nicks and any
> normalization that needs to be applied.

With respect to the issue of "allowed characters", only UTF-8 s allowed. 
This draft is an extension to RFC 4975 (MSRP). The ABNF syntax of the 
Use-Nickname header refers to RFC 4975. Section 9 of RFC 4975 says: "MSRP 
is a text protocol that uses the UTF-8 [14] transformation format". So, I 
believe this issue is solved by indirect reference. However, to add a bit 
more emphasis, we can add the following text:

           According to <xref target="RFC4975">RFC 4975</xref>, MSRP
	  uses the <xref target="RFC3629"> UTF-8 transformation
           format</xref>. The syntax of the MSRP NICKNAME method and the
           "Use-Nickname" header field is built upon the <xref
           target="RFC4975">MSRP formal syntax </xref> using the
           <xref target="RFC5234">Augmented Backus-Naur Form (ABNF
           </xref>.



With respect to the issue of normalization, I believe this is now solved 
in version 16. Section 7.1 contains now the following paragraphs:

    If the policy of the chat room allows the usage of nicknames, any new
    nickname requested MUST be prepared and compared with nicknames
    already in use or reserved following the rules defined in Preparation
    and Comparison of Nicknames [I-D.ietf-precis-nickname].

    This mitigates the problem of nickname duplication, but it does not
    solve a problem whereby users can choose similar (but different)
    characters to represent two different nicknames.  For example, "BOY"
    and "B0Y" are different nicknames which can mislead users.  The
    former uses the capital letter "O" while the latter uses the number
    zero "0".  In many fonts the letter "O" and the number zero "0" might
    be quite similar, and difficult to be perceived as different
    characters.  Chat rooms MAY provide a mechanism to mitigate
    confusable nicknames.

>
>
> Minor Issues
>
> The document strictly forbids multiple To: headers in the CPIM message,
> that could be used for example to send public personal messages (i.e.
> messages addressed to some particular individual, but shared with the
> entire conference, a-la Twitter). If there's a reason for that, some
> explanation would be useful.

This was a decision taken by the working group due to the complexity. For 
example, what happens if one of the recipients is correct, but another 
one is incorrect or has left the chat room. Should the server process the 
message to one recipient and not to the other? what would be the error? 
It was also conflicting with requirements for side conferences, something 
that was part of the deliverables in XCON.

At the end of the day, the endpoint can always send multiple messages,
each one with a single To header.

To address this issue, I proposed to add the following text in Section 6.2:

	      This version of the specification does not support
	      sending a private message to multiple recipients, i.e.,
	      the presence of multiple To headers in the Message/CPIM
	      wrapper of the MSRP SEND request. This is due to added
	      complexity, for example, with the need to determine
	      whether a message was not deliver to some of the
	      intended recipients. Implementations that still want to
	      recreate this function can send a series of single
	      private messages, one private message per intended
	      recipient. The endpoint can correlate this series of
	      messages and create the effect of a private message
	      addressed to multiple recipients.

>
> Figure 1 seems to imply that MSRP relays are mandatory. Since they are
> not -- and the draft is pretty clear about it -- I'd suggest to have
> some of MSRP flows in the diagram flow straight from the client to the
> switch.

Agreed.

>
> A reference to the SDP mechanism defined in S. 8.  would be useful in in
> S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part
> that deals with discovering of client capability.
>

Agreed for section 5.2. The proposed change is as follows:

Last paragraph in Section 5.2 starts with:

	  The conference focus of a chat room MUST learn the chat room
	  capabilities of each participant that joins the chat
	  room. This is achieved by the exchange of new 'chatroom'
	  attributes in SDP (see <xref target="chatroom-attribute"/>
	  for further details).


But I believe the last paragraph of S. 6.2 does not talk about 
discovering capabilities, so I think the text does not fit there. But I 
have found a paragraph in S 4 that talks about capability discovery, so I 
have added the last sentence of the previous paragraph too.

> In Section 5.2:
>
>      The conference focus of a chat room MUST learn the chat room
>
> How can this be achieved? A forward pointer might be missing here.

Yes, this is the previously mentioned paragraph.
>
>      capabilities of each participant that joins the chat room.  The
>      conference focus MUST inform the MSRP switch of such support in
>      order to prevent the MSRP switch from distributing private messages
>      to participants who do not support private messaging.  The recipient
>      would not be able to render the message as private, and any
>      potential reply would be sent to the whole chat room.
>
> In Section 7.1:
>
>      The reservation of a nickname can fail, e.g. if the NICKNAME request
>      contains a malformed or non-existent Use-Nickname header field, or
>      if the same nickname has already been reserved by another
>      participant (i.e., by another URI) in the chat room.  The
>      validation can also fail where the sender of the message is not
>      entitled to reserve the nickname.  In any of these cases the MSRP
>      switch MUST answer the NICKNAME request with a 423 response.  The
>      semantics of the 423 response are: "Nickname usage failed; the
>      nickname is not allocated to this user".
>
> It would be better to use different response codes for different error
> conditions.

In the current version 16, these have been split into two errors:
- 424: Malformed nickname
- 425: Nickname reserved or already in use

We believe this solves the issue.

>
>
> Nits [Only the few that came out in non-nitpicking read]
>
> S. 3, REQ-3: s/depend no/depend on/

ok.

>
> S. 4, second paragraph after Figure 2: s/a text/text/

ok

>
> A few 2119 refuses can be also found in the text, e.g.:
>
> S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/

Ok.

Thanks for your comments. They will be deployed in a newer version of the 
document.

/Miguel


-- 
Miguel A. Garcia
[phone]
Ericsson Spain