APPSDIR review of draft-ietf-simple-chat-13
Enrico Marocco <enrico.marocco <at> telecomitalia.it>
2012-02-06 09:50:30 GMT
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/
_______________________________________________
apps-discuss mailing list
apps-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
RSS Feed