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

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
> <[email protected]> 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, [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/simple
>>>
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ Simple mailing list
>> [email protected] https://www.ietf.org/mailman/listinfo/simple
>

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