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