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

From: Enrico Marocco <[email-masked]>
Date: Mon, 6 Feb 2012 10:50:30 +0100

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/

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Feb 2012 08:35:28 -0600

Thanks for the thorough review Enrico and Alexey!

Miguel and Geir Arne: What are your thoughts?

Thanks!

Ben.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 7 Feb 2012 15:12:35 +0100

Hi Enrico:

Thanks for your review.

See inline comments.

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

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

> some of MSRP flows in the diagram flow straight from the client to the

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

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

> It would be better to use different response codes for different error

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.

> S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/

Good catches. We will fix them.

Thanks,

      Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Feb 2012 14:11:09 -0600

On Feb 7, 2012, at 8:12 AM, Miguel A. Garcia wrote:

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

I agree that if we think we need to allocate additional error codes, we should run that by the work group. Miguel, can you send a note to the SIMPLE list on that?

Thanks!

Ben.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 8 Feb 2012 08:51:07 +0100

Yes, I will ping the SIMPLE WG.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Feb 2012 18:17:14 +0000

Hi Miguel,

On 07/02/2012 14:12, Miguel A. Garcia wrote:
> nicknames by making a reference to RFC 4975. In Section 7.1, the 
> syntax of the Use-Nickname header is written as:
>
If ABNF is saying that only UTF-8 is allowed, then the current text is Ok.
> 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.

Have a look at ResourcePrep:
http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

If you can't wait for Precis to finish, you can also use an older 
version (based on StringPrep):
http://www.rfc-editor.org/rfc/rfc6122.txt