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

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

Hi Enrico:

Thanks for your review.

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.

I think the document clearly describes the allowed characters in 
nicknames by making a reference to RFC 4975. In Section 7.1, the syntax 
of the Use-Nickname header is written as:

                Use-Nickname = "Use-Nickname:" SP nickname
                nickname = quoted-string
                ; quoted-string defined in RFC 4975

According to RFC 4975:

    quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
    qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
                / UTF8-NONASCII
    qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
    BACKSLASH = "\"
    UPALPHA  = %x41-5A
    ALPHANUM = ALPHA / DIGIT


So, I think it is described.

With respect to normalization, I am not sure if a nickname needs to be 
normalized and now this normalization should take place. Let me know the 
text that you are missing and I will add it to the draft.




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

I agree that this explanation can be added to the draft.

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

Right, we can remove one of the MSRP Relays and leave the other one, 
indicating that both configurations are possible.


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

Yes, correct. We need to explain how, which is by means of the chatroom 
attribute in SDP (Section 8). We will add the forward pointer.

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

I also sympathize your proposal. We had this for avoiding creating very 
detailed error conditions. But I wouldn't mind to differentiate both 
error cases. Perhaps we should take this to the WG for comments.

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

Good catches. We will fix them.

Thanks,

      Miguel

-- 
Miguel A. Garcia
[phone]
Ericsson Spain