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

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Tue, 20 November 2012 08:48 UTC

Return-Path: <miguel.a.garcia@ericsson.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 0F12221F86EC for <simple@ietfa.amsl.com>; Tue, 20 Nov 2012 00:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 FmSbYXXjVbjD for <simple@ietfa.amsl.com>; Tue, 20 Nov 2012 00:48:57 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8A19121F86E5 for <simple@ietf.org>; Tue, 20 Nov 2012 00:48:56 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-da-50ab43f61153
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0E.AB.26143.6F34BA05; Tue, 20 Nov 2012 09:48:54 +0100 (CET)
Received: from [159.107.24.207] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 20 Nov 2012 09:48:53 +0100
Message-ID: <50AB43F5.9020803@ericsson.com>
Date: Tue, 20 Nov 2012 09:48:53 +0100
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
In-Reply-To: <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rveb8+oAgyOLlSzmd55mt1g48R+r A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXRsegta8Eky4quddNZGxjb9LoYOTkkBEwk Fl+cygxhi0lcuLeerYuRi0NI4CSjxObeW4wQzhpGiaVHpjCBVPEKaEs8/DeVEcRmEVCVmLqh C6ybTcBconXjRvYuRg4OUYFgiTnX+CHKBSVOznzCAmKLCChJPG/eygJSwiwgLPG81wEkLCxg L3H82xImiFVTGCU+TJnDCFLDCZT4+90CpIZZwFbiwpzrLBC2vMT2t3PAtgoJaEpMvrmUeQKj 4Cwk22YhaZmFpGUBI/MqRvbcxMyc9HKjTYzAgDy45bfqDsY750QOMUpzsCiJ81pv3eMvJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgdFQutQn4J732ska/25PO6nP+4U/UMX3msrR6J8loWdn 5LaGtfJk/DdasLUyUOjqL+1G5fWvXTZNV53bcVUv1lPxV33V//9NuRe0d62P7Hp2QP3Hvcd9 k5NDiie9er5S4GRDIuOV45I35oV8L86M2i7efbP6ZsUrLkPT43LRB50/GgT7z5tVmqTEUpyR aKjFXFScCABQeZ21FgIAAA==
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: Tue, 20 Nov 2012 08:48:58 -0000

Hi Ben,

thanks for your comments. See inline answers.

On 19/11/2012 22:12, Ben Campbell wrote:
> 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?

Yeap, it is recommended, though optional. The reason is that the UE can 
(and will most likely) add a start "*" to indicate that it supports 
additional formats not explicitly signaled. So, if most endpoints add a 
start "*", then it is not clear what is the benefit of it.

Remember that MSRP mandates accept-types and leaves accept-wrapped-types 
as optional.

 > Do we allow either to
> include anything _other_ than message/cpim in accept-types?

Yes, we do. Bear in mind that and endpoint establishing a session will 
create SDP according to what it supports, before knowing that the session 
will end up in a chat server. So, we cannot mandate that the endpoint 
populates ONLY those values that are required by the server. We can 
mandate (and this is the spirit of the draft) that endpoints include at 
least those values required by the server, but we don't expect those 
values to be alone.

So, to answer your question, yes, it is allowed to have something else 
than message/cpim in the SDP offer, but that will not be used by this draft.


> If not,
> what does it mean to include only message/CPIM in "accept-types" and
> not include "accept-wrapped-types"?

It means that the endpoint can receive message/CPIM bodies, as required 
by this draft, but we don't know which kind of wrapped type the endpoint 
supports. Therefore, the MSRP server will not screen supported media 
types, and will blindly send all the content to the endpoint, 
independently of its media type.

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

The communication between the focus (SIP UA) and the MSRP switch is 
outside the scope of the document. I suspect most implementations 
implement a single function offering both focus and MSRP switch, in which 
case standardization is not required. I mean, this is an internal interface.

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

Sounds good to me.

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

Fair enough. In Section 5.2 I have added a reminder of the mandatory 
nature of the accept-types, and have deleted that redundant paragraph in 
Section 6.1

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

I meant "may result encoded". Fixed, thanks.

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

True. I am clarifying the text.

Thanks,

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

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