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

[Ben Campbell <[e-mail]>]

On Nov 20, 2012, at 2:48 AM, "Miguel A. Garcia" <[e-mail]> wrote:

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

It's optional because you don't always need to enforce a wrapper, in which case you could just used accept-types. As  you say, there is no default. I don't recall 4975 stating a behavior for having only a wrapper type in accept-types and no accept-wrapped-types value. I don't think we can expect interoperable behavior.


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

Okay.

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

Again, I'm not sure how the endpoint will interpret that. (Maybe the switch only accepts empty message/cpim docs?). If the switch wants to accept anything, but only in a message/cpim wrapper, it should include an accept-wrapped-types with a "*".

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

I agree. But the text appears to say that it uses the SDP chatroom attribute to do so. Is that the intent?

[...]

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

I'm still not clear on what "may result encoded" means. Do you mean "may result in encoding..."?  (Or is result-encoded  a term of art I've missed?)

> 
>> 
>> 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
>> <[e-mail]> 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, [e-mail] 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 [e-mail] https://www.ietf.org/mailman/listinfo/simple
>>>> 
>>>> 
>>> 
>>> -- Miguel A. Garcia [phone] Ericsson Spain
>>> _______________________________________________ Simple mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/simple
>> 
> 
> -- 
> Miguel A. Garcia
> [phone]
> Ericsson Spain