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

From: [email-masked]
Date: Sat, 17 Nov 2012 08:06:11 -0800

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/

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sat, 17 Nov 2012 17:30:33 +0100

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-masked] wrote:
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2012 11:10:24 -0500

AFAICT, this draft has addressed all the concerns I previously raised.
In looking through it, I came across some small editorial issues:

Figure 1, near the bottom, has a dangling "|".

In section 4.1:

    Nicknames:   Whether the chat room accepts users to be recognized
       with a nickname.  See Section 7, Section 7.1, and Section 8 for
       details.  Also, the scope of uniqueness of the nickname: the chat
       room (conference instance), a real or domain, a server, etc.

Something is wrong in the last sentence - "a real" *what*?

Section 5.2: s/The chat room them uses/The chat room then uses/

Section 6.2: in the last paragraph, at the end, s/URI.m/URI./

	Thanks,
	Paul

On 11/17/12 11:30 AM, Miguel A. Garcia wrote:
> - Clarified that congestion can occur due to the chat room application
> or due to some other application.
> 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.
> - Added a length limit to MSRP nicknames: they must be between 1 and
> 1023 octets, after UTF-8 encoding.
> - Added more security considerations around the usage of TLS, policies
> to preserve a nickname once the use logs off, confusable nicknames,
>>   This draft is a work item of the SIP for Instant Messaging and
>> Presence Leveraging Extensions Working Group of the IETF.
>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 19 Nov 2012 15:12:41 -0600

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 <[email-masked]> 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.
> 
> - 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.
> - 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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2012 17:34:43 -0500

> 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 anythin…

This was in response to comments I made some time ago.
The point was to future-proof this, so that if in the future there is a 
new type (say message/cpim++) that something that implements that will 
be able to indicate support for both message/cpim and message/cpim++ and 
still be conforming to this spec.

(Of course, if both ends then support message/cpim++ and decide to use 
it, then they will cease to be operating in accord with this spec. 
Instead they will be following some new spec that calls for use of 
message/cpim++.)

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 20 Nov 2012 09:48:53 +0100

Hi Ben,

thanks for your comments. See inline answers.

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

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

> 6.1, 3rd paragraph: Seems like this paragraph is now redundant due to

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
>> 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.
>>
>> contact the IESG members to verify that the current version
>> satisfies their comments.
>>
>> /Miguel
>>
>>> 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.
>>>
>>>
>>> _______________________________________________ Simple mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/simple
>>>
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ Simple mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/simple
>

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 20 Nov 2012 12:23:57 +0100

Hi Paul,

Thanks for your comments. See inline answers.

> Figure 1, near the bottom, has a dangling "|".

fixed.

> Something is wrong in the last sentence - "a real" *what*?

It should say "a realm or domain".

> Section 5.2: s/The chat room them uses/The chat room then uses/

fixed.

> Section 6.2: in the last paragraph, at the end, s/URI.m/URI./

Fixed.

/Miguel

>>> directories.
>>> Protocol (MSRP)

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2012 09:08:24 -0600

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

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

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

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

[...]

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

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?)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2012 17:40:05 -0600

(As Chair)

This version incorporates some non-trivial changes as a result of the IESG review. There's some new normative language. I think it is likely that there will be one or two more revisions, but I expect them to be pretty minor. That is, I expect the version that the ADs actually approves will be substantially similar to this one.

Please take a look, and verify that the changes do not introduce any new problems. If you have objections please send them to the authors and the list ASAP. I don't plan to call yet another formal WGLC at this point; so if there are no objections the draft will progress when it gets AD approval.

Thanks!

Ben.

Begin forwarded message:

> From: "Miguel A. Garcia" <[email-masked]>
> Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt
> Date: November 17, 2012 10:30:33 AM CST
> To: [email-masked]
> 
> Hi:
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 21 Nov 2012 11:31:52 +0100

Hi Ben.

See further discussion below.

On 20/11/2012 16:08, Ben Campbell wrote:
>>> Thanks Miguel. I think this version is much improved. But of
>>> course, here's a few questions and comments:
>>>
>>> Questions:
>>>
[snip]
>
>>
>>
>>> 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 "*".

Let's back up a bit an analyze the scenarios. We have two scenarios:

a) The endpoint declare all its supported media types in the 
accept-wrapped-types attribute in SDP. The MSRP switch will screen those 
types, and if the MSRP receives a wrapped media type that this endpoint 
does not support, it won't forward that e-mail to the endpoint.

b) The endpoint declares a few of the supported media types, but not all, 
because it adds an asterisk '*' to the accept-wrapped-types attribute in 
SDP. Or, alternatively, the endpoint does not declare any supported media 
types (there is no accept-wrapped-types at all in SDP). In this case, the 
MSRP switch will not screen the wrapped types in received messages, and 
will forward all of them to the endpoint. Therefore, the endpoint may 
receive some media types that is not able to render. This is the same 
scenario we may have with web browsers today. Some implementations will 
incorrectly render it in binary, others will point to a plug-in download, 
etc.

I don't know what else should we do from the standards point of view, 
besides what MSRP mandates and does not mandate.

>
>>
>>>
>>> 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_.
>>
>> implement a single function offering both focus and MSRP switch, in
>> which case standardization is not required. I mean, this is an
>> internal interface.
>

No, that is not the intent. I will revise this paragraph to clarify that 
this interface is not SDP.

>> 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'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?)

Here I am using the term "result" as a verb, not as a noun. The 
definition of "result" in the Merriam-Webster dictionary is:

result: to proceed or arise as a consequence, effect, or conclusion. 
Example: <death resulted from the disease>

So, I believe "may result encoded" is correct, isn't it?

/Miguel

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Nov 2012 16:26:33 -0600

Hi Miguel, see inline. Also, be advised I leave on holiday tomorrow, through 3 Dec, so I might be laggy on email during the next several days.

On Nov 21, 2012, at 4:31 AM, Miguel A. Garcia <[email-masked]> wrote:

[...]

> [
> a) The endpoint declare all its supported media types in the accept-wrapped-types attribute in SDP. The MSRP switch will screen those types, and if the MSRP receives a wrapped media type that this endpoint does not support, it won't forward that e-mail to the endpoint.
> 
> b) The endpoint declares a few of the supported media types, but not all, because it adds an asterisk '*' to the accept-wrapped-types attribute in SDP. Or, alternatively, the endpoint does not declare any supported media types (there is no accept-wrapped-types at all in SDP). In this case, the MSRP switch will not screen the wrapped types in received messages, and will forward all of them to the endpoint. Therefore, the endpoint may receive some media types that is not able to render. This is the same scenario we may have with web browsers today. Some implementations will incorrectly render it in binary, others will point to a plug-in download, etc.
> 
> I don't know what else should we do from the standards point of view, besides what MSRP mandates and does not mandate.

My concern is we seem to allow the case of putting "message/cpim" in accept-wrapped-types, and _nothing_else_. While that doesn't violate 4975, it creates a nonsensical case. That is, it can be interpreted to mean you can only accept message/cpim without content in it. I suppose some implementers might interpret it to mean you can accept message/cpim without restriction, but I don't think that will be universal.

So, if an endpoint or a switch includes message/cpim (or any other envelope type) it needs to also indicate one or more leaf types. It can do that in either accept-types or accept-wrapped-types, and it can wildcard it with a "*". 

So, back to your scenarios, in the case of a), the endpoint needs to put message/cpim in accept-types, and the other media types in either accept-types or accept-wrapped types, depending on whether it wants to _require_ vs _allow_ the use of message/cpim. In case b), the endpoint either puts "message/cpim" in accept-types and "*" in accept-wrapped-types, or it just puts "*" in accept-type, depending on the same question as in a). In no case does it make sense for the endpoint to include nothing but "message/cpim".

It seems to me that we could make this easier by not getting too wrapped around the MSRP mechanics, and state more what the endpoints need to indicate semantically. For example, it seems like a chat endpoint MUST support message/cpim, and MAY require it. If it requires it, it MUST indicate what leaf types it supports, either explicitly or in the form of a wildcard.  A switch MUST support message/CPIM and SHOULD require it. If it requires it, it also MUST indicate what leaf types it supports...

Endpoints and switches use accept-types and accept-wrapped-types to do these things as described in RFC 4975.

> Here I am using the term "result" as a verb, not as a noun. The definition of "result" in the Merriam-Webster dictionary is:
> 
> result: to proceed or arise as a consequence, effect, or conclusion. Example: <death resulted from the disease>
> 

II get that you are using "result" as a verb. But "result encoded" doesn't parse.  I suggest either "As a result, the character may be encoded..." or "Therefore, the character may be encoded...". Or possibly, "This may result in the encoding of the character..."

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 26 Nov 2012 12:37:40 +0100

Hi,

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

I'm ok with this version. A couple of minor editorial comments though:

In sec 4.1: "Chunk reception timer:   The value of a time that" -> "The value of a timer that"

In sec 6.2 "whether a message was not deliver" -> "whether a message was not delivered"

Regards,

--
Saúl Ibarra Corretgé
AG Projects