Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt

Ben Campbell <ben@nostrum.com> Mon, 19 November 2012 21:12 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: simple@ietfa.amsl.com
Delivered-To: simple@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37C821F8750 for <simple@ietfa.amsl.com>; Mon, 19 Nov 2012 13:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.408
X-Spam-Level:
X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgaroXGTzcca for <simple@ietfa.amsl.com>; Mon, 19 Nov 2012 13:12:47 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48DEC21F8739 for <simple@ietf.org>; Mon, 19 Nov 2012 13:12:45 -0800 (PST)
Received: from [10.12.11.26] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAJLCe4h079405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Nov 2012 15:12:40 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <50A7BBA9.7040904@ericsson.com>
Date: Mon, 19 Nov 2012 15:12:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 21:12:47 -0000

Thanks Miguel. I think this version is much improved. But of course, here's a few questions and comments:

Questions: 

5.2 : There is new normative language in section 5.2 concerning the use of "accept-types" and "accept-wrapped-types" Do I read it correctly that and endpoint SHOULD (i.e. RECOMMENDED) include accept-wrapped-types, and a focus MAY do so? Do we allow either to include anything _other_ than message/cpim in accept-types?  If not, what does it mean to include only message/CPIM in "accept-types" and not include "accept-wrapped-types"?

The last paragraph of 5.2 says that the focus must inform the switch of the chat room capabilities of each participant, and that it does this with the SDP "chatroom" attribute. Do we assume anything about how the focus and switch communicate? I thought the chatroom attribute was more about how the focus communicates this with _endpoints_.

6.1, paragraph starting with "Once the MSRP switch receives the last chunk..."

Should that really be a normative "MUST discard"? Seems like this is an implementation question more than a protocol question. Could we merely say "the MSRP switch discards..."?

Editorial:

6.1, 3rd paragraph: Seems like this paragraph is now redundant due to the additions in 5.2.

7.1, third paragraph: "... character may be result encoded in more than one
      octet"
do you mean ...: may be as a result encoded..."?

11, paragraph 5: I think the reader may be confused into thinking you mean force the SDP offer/answer to occur over TLS, rather than using the offer/answer to force the MSRP session to be over TLS.


On Nov 17, 2012, at 10:30 AM, Miguel A. Garcia <Miguel.A.Garcia@ericsson.com> wrote:

> Hi:
> 
> So, the long awaited version -17 of the MSRP chat draft has been posted. This version addresses all the comments received in the IESG review and various directorates that also took a look at the draft. Among others, these are the most relevant changes.
> 
> - Added definitions of "identifier" and "to log in".
> - New Section 4.1 lists all the Policy Attributes of the chat room in a single section.
> - Clarified that congestion can occur due to the chat room application or due to some other application.
> - Clarified that the MSRP switch should learn the recipient's capabilities through the 'accept-wrapped-types' in SDP. Procedures as for what to do if the MSRP switch is aware that a recipient does not support a given media type.
> - Quite a few clarifications around chunked messages. It was clarified when the MSRP switch has to delete the temporarily stored state. Also, how to deal with situations where the connection is broken before the reception of the last chunk.
> - Added a length limit to MSRP nicknames: they must be between 1 and 1023 octets, after UTF-8 encoding.
> - Fixed a bug: the error result code is 425 rather than 423 in the examples.
> - Added more security considerations around the usage of TLS, policies to preserve a nickname once the use logs off, confusable nicknames, rendering of nicknames that contain scripts or code, and anonymity when using TLS with certificates.
> 
> From the authors' perspective, we believe the draft is ready. I will contact the IESG members to verify that the current version satisfies their comments.
> 
> /Miguel
> 
> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.
>> 
>> 	Title           : Multi-party Chat Using the Message Session Relay Protocol (MSRP)
>> 	Author(s)       : Aki Niemi
>>                           Miguel A. Garcia-Martin
>>                           Geir A. Sandbakken
>> 	Filename        : draft-ietf-simple-chat-17.txt
>> 	Pages           : 42
>> 	Date            : 2012-11-17
>> 
>> Abstract:
>>    The Message Session Relay Protocol (MSRP) defines a mechanism for
>>    sending instant messages within a peer-to-peer session, negotiated
>>    using the Session Initiation Protocol (SIP) and the Session
>>    Description Protocol (SDP).  This document defines the necessary
>>    tools for establishing multi-party chat sessions, or chat rooms,
>>    using MSRP.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-simple-chat-17
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>> 
>> 
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple