[apps-discuss] APPSDIR review of draft-ietf-simple-chat-13
Enrico Marocco <enrico.marocco@telecomitalia.it> Mon, 06 February 2012 09:49 UTC
Return-Path: <enrico.marocco@telecomitalia.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4721F85C9; Mon, 6 Feb 2012 01:49:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.544
X-Spam-Level:
X-Spam-Status: No, score=-100.544 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLnoO3CvscqI; Mon, 6 Feb 2012 01:49:16 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 248D521F85C3; Mon, 6 Feb 2012 01:49:16 -0800 (PST)
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Feb 2012 10:49:06 +0100
Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Feb 2012 10:49:04 +0100
Message-ID: <4F2FA266.8040406@telecomitalia.it>
Date: Mon, 06 Feb 2012 10:50:30 +0100
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, draft-ietf-simple-chat.all@tools.ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms080108030207010104060809"
Cc: IESG <iesg@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2012 09:49:17 -0000
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] APPSDIR review of draft-ietf-simpl… Enrico Marocco
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Ben Campbell
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Miguel A. Garcia
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Ben Campbell
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Miguel A. Garcia
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Alexey Melnikov
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Miguel A. Garcia
- Re: [apps-discuss] APPSDIR review of draft-ietf-s… Alexey Melnikov