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

[Ben Campbell <[e-mail]>]

Thanks for the thorough review Enrico and Alexey!

Miguel and Geir Arne: What are your thoughts?

Thanks!

Ben.

On Feb 6, 2012, at 3:50 AM, 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.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
>    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.
> 
> 
> Nits [Only the few that came out in non-nitpicking read]
> 
> S. 3, REQ-3: s/depend no/depend on/
> 
> S. 4, second paragraph after Figure 2: s/a text/text/
> 
> 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/
> 
>