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

[Alexey Melnikov <[e-mail]>]

On 03/09/2012 15:41, Miguel A. Garcia wrote:
> 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>.

That would be perfect, thanks.

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

Yes, this is addressed.


>> 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.
Sounds good.
>
>> 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.
>
Ok.

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

Thanks, will sanity check it when it is posted.