Subject: [Simple] Comments on draft-ietf-simple-chat-02

From: Ben Campbell <[email-masked]>
Date: Sat, 8 Mar 2008 14:13:09 -0600

Hi,

I think this draft has made overall good progress. I have a few  
comments, none of which fall into the "this won't work" category. I  
apologize in advance if some of these have already been discussed to  
death--I've slept since then.

General:

The draft assumes throughout that MSRP is operating in the default  
reporting model, i,e. Success-Report: no and Failure-Report: yes (or  
both headers missing.) It needs to either discuss how things work in  
other reporting models, or state that chat sessions MUST use the  
default reporting model. In particular, the draft needs to state what  
the switch does with REPORT requests, and how it handles downstream  
failures.

Given that chat requires the use of application/cpim for all messages,  
the draft needs to point out that this should be signaled in the sdp  
accept-types and accept-wrapped-types attributes. For example, you  
would have an accept-types value of "message/cpim" and an accept- 
wrapped-types containing everything you allow inside the envelope. (Or  
possibly "*").

Requirements for handling anonymous senders are sort of scattered  
through several sections. It might be worth consolidating them  
somewhere. Also, the draft assumes that MSRP switches are responsible  
for mapping From header values for anonymous messages--would it be  
feasible to put this responsibility on the sending UA? (I.e. why not  
have them put the replacement URI in the From header themselves?)

6.2, Paragraph 3 "The sender SHOULD populate the From header with the  
identity..."

Why is this not a MUST?

Paragraph 6, last sentence:"If a replacement URI is present in the  
sender's message, it MUST use the mapping and replaced it with the URI  
for which the recipient is known to the focus."

I don't understand--how would this case ever occur? And why would this  
be different than any other case of having an incorrect From identity?  
Also, the antecedent to "It" is not clear to me.

Paragraph 7: "If the To header field is not set to the chat room URI,  
then it is a private message."

Shouldn't the receiving endpoint validate that the CPIM To header  
actually points to the user in this case?

"The endpoint might have also received further identity information  
through a subscription to the SIP conference event package [RFC4575]."

What if it did? What would it do differently?

Paragraph 8 (on having multiple instances of the same user in a  
conference)

I think this needs some more thought. I can imagine that if I joined  
twice with the same identity in the conference, I would want to get  
private messages on both sessions--but what if I join with different  
identities, both of which the MSRP switch knows belong to me? I'm not  
sure I would expect to have a private message to one identity  
delivered to the second.

Section 7.1, paragraph 3:

I'm not sure a 501 is the correct response here. Technically a 501  
means the MSRP device does not understand the NICKNAME method at all,  
not just for this chat room. While not specified, it would not be  
unreasonable for a UA to remember that that it got a 501 from a given  
server, and assume NICKNAME is not supported for _any_ chat room on  
that server. 403 is probably a better choice.

Paragraph 5: 423 response code

Would not a 403 be appropriate here, as the user requested something  
he is not allowed to do? (Maybe _this_ should be 403, and the 501  
mentioned above should be something different?)

Also, it seems to me that the case of me not being authorized for a  
nickname, and the case of a nickname already being in use for this  
conference are subtly different. Do we expect the same UA behavior in  
both cases?

Section 7.2:

How would I remove a nickname without assigning a new one?

Section 8:

Is support for private messaging and nicknames considered optional for  
devices that implement chat? If not, then we could get by simply  
signaling support for chat or not. If they are optional, that was not  
clear to me from the specification on them (maybe I missed something.)

Section 9.3, Figure 13:

How would things look if either message 5 or 6 indicated a failure?

Section 9.4, figure 17?

Why is message 4 in the figure if this is a private message to bob?

Security Considerations:

I think we are going to need more discussion here. Some possible  
examples of things to think about. Even if the answers seem obvious to  
us it might not to others:

Can MSRP switches be used for amplification attacks? I don't think so,  
since endpoints must explicitly join sessions, but I might be missing  
something. It's worth a discussion.

We could use some more on anonymous and private messaging, and how  
things might go wrong.

Is there any way for someone to join a conference without the other  
participants knowing?

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Miguel Garcia <[email-masked]>
Date: Sun, 09 Mar 2008 17:41:46 +0200

Hi Ben:

Thanks for your comments. Inline discussion.

Ben Campbell wrote:
> accept-types and accept-wrapped-types attributes. For example, you would 
> have an accept-types value of "message/cpim" and an accept-wrapped-types 
> containing everything you allow inside the envelope. (Or possibly "*").

That is the intention. Section 5.2 says:

    The conference focus of a chat room MUST include support for a
    Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by
    setting the 'accept-types' MSRP media line attribute in the SDP offer
    or answer to include 'Message/CPIM'.

However, the section does not say anything about participants. I think 
there is some history behind. So, there should be some text around that 
says the same about the endpoints, no only the focus.

I noticed also that there is a mistake in the second paragraph of 
Sections 6.1 and 6.2, when the text says:

    The actual instant message payload inside 'Message/CPIM'
    MAY be of any type negotiated in the SDP 'accepted-types' attribute
    according to the MSRP rules.

The text should s/accepted-types/accept-wrapped-types because we say 
that accept-types should always be message/cpim, and the actual payload 
types go in the accept-wrapped-types.

> actually points to the user in this case?

No, not at all. A sends a private message to B with Cc to C. It is a 
private message, but the CPIM To header is set to B, even in the message 
sent to C.

> Paragraph 8 (on having multiple instances of the same user in a conference)
> 
> sure I would expect to have a private message to one identity delivered 
> to the second.

Yes, but.... what is wrong with the text? The text says about :

    a participant, identified by a SIP Address of
    Record, joins a conference of instant messages from two or more
    different SIP UAs.

So, the text is dealing with joining the room with the same identity 
from two devices. I don't think the text says nothing about two 
different identities, in which case, it is obvious that the conference 
server won't have the means to link the two identities, and will treat 
them as separate.

> I'm not sure a 501 is the correct response here. Technically a 501 means 
> the MSRP device does not understand the NICKNAME method at all, not just 
> for this chat room. While not specified, it would not be unreasonable 
> for a UA to remember that that it got a 501 from a given server, and 
> assume NICKNAME is not supported for _any_ chat room on that server. 403 
> is probably a better choice.

I agree.

> Would not a 403 be appropriate here, as the user requested something he 
> is not allowed to do? (Maybe _this_ should be 403, and the 501 mentioned 
> above should be something different?)

I don't think so. How would you able to distinguish "403 Nickname method 
not allowed in this chatroom" from "403 I cannot give you this 
particular nickname but you can try another one". I think the semantics 
of the response should clearly say "You have selected a nickname that I 
can't give to you. Please select a another nickname and try again". 
Therefore I propose to keep the current 423 response.

So, 403 should be interpreted as "do not try again, not allowed here". 
423 should be interpreted as "change your value, and re-try".

> conference are subtly different. Do we expect the same UA behavior in 

yes, see above.

> How would I remove a nickname without assigning a new one?

Good question. I think a NICKNAME method containing a Use-Nickname 
header with the empty value "" will do it. But the text should 
explicitly say it, and indicate that the focus should always allow users 
to remove the nickname in this way.

> clear to me from the specification on them (maybe I missed something.)

The main thing here is the chat room policy, which may disallowed either 
nicknames or private messages, or both. That's the reason why we need 
that level of granularity.

> How would things look if either message 5 or 6 indicated a failure?

How would that different from MSRP as per RFC 4975? I would like figures 
to have a value for the chat room draft. And the point of this figure is 
to show how a message is distributed (which is obvious, but still...).

> Why is message 4 in the figure if this is a private message to bob?

Ooops, this is obviously an error. There should be a 200 OK from Bob to 
the MSRP switch rather than the MSRP SEND to Charlie.

> Is there any way for someone to join a conference without the other 

I agree, the section should provide answers to all these questions.

        Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Ben Campbell <[email-masked]>
Date: Sun, 9 Mar 2008 21:23:45 -0500

Hi Miguel,

Thanks for the quick response!

Did you have any thoughts on my first comment, concerning MSRP report  
models? Quoted again for convenience:

"The draft assumes throughout that MSRP is operating in the default  
failures."

More inline:

On Mar 9, 2008, at 10:41 AM, Miguel Garcia wrote:

>> Given that chat requires the use of application/cpim for all  
>> messages, the draft needs to point out that this should be signaled  
>> in the sdp accept-types and accept-wrapped-types attributes. For  
>> example, you would have an accept-types value of "message/cpim" and  
>> an accept-wrapped-types containing everything you allow inside the  
>> envelope. (Or possibly "*").
>

I think we need to make this a little stronger, as we are doing more  
than indicating support for Message/CPIM--we are indicating that we  
_require_ it. That would mean the "accept-types" attribute would  
contain "message/cpim" and nothing else. Yes, this is pedantic--but if  
someone were to use "message/cpim *", they would have indicated  
support for message/cpim, but  the other side could still choose not  
to use it.

> However, the section does not say anything about participants. I  
> think there is some history behind. So, there should be some text  
> around that says the same about the endpoints, no only the focus.
>
> that accept-types should always be message/cpim, and the actual  
> payload types go in the accept-wrapped-types.

>
>
>
>
>> Paragraph 7: "If the To header field is not set to the chat room  
>> URI, then it is a private message."
> private message, but the CPIM To header is set to B, even in the  
> message sent to C.
>

So should the recipient endpoint check to see if its user is on the To  
_or_ CC list?

Also, unless I missed something (which happens more often than not), I  
didn't find any text talking about the use of the CC header, other  
than a passing mention of its existence.

>> I think this needs some more thought. I can imagine that if I  
>> joined twice with the same identity in the conference, I would want  
>> to get private messages on both sessions--but what if I join with  
>> different identities, both of which the MSRP switch knows belong to  
>> me? I'm not sure I would expect to have a private message to one  
>> identity delivered to the second.
>
> different identities, in which case, it is obvious that the  
> conference server won't have the means to link the two identities,  
> and will treat them as separate.

Ah, I think the text is okay on rereading it.

>> means the MSRP device does not understand the NICKNAME method at  
>> all, not just for this chat room. While not specified, it would not  
>> be unreasonable for a UA to remember that that it got a 501 from a  
>> given server, and assume NICKNAME is not supported for _any_ chat  
>> room on that server. 403 is probably a better choice.
>
> I agree.
>
>> Would not a 403 be appropriate here, as the user requested  
>> something he is not allowed to do? (Maybe _this_ should be 403, and  
>> the 501 mentioned above should be something different?)
>
> I don't think so. How would you able to distinguish "403 Nickname  
> method not allowed in this chatroom" from "403 I cannot give you  
> this particular nickname but you can try another one". I think the  
> semantics of the response should clearly say "You have selected a  
> nickname that I can't give to you. Please select a another nickname  
> and try again". Therefore I propose to keep the current 423 response.
>
> So, 403 should be interpreted as "do not try again, not allowed  
> here". 423 should be interpreted as "change your value, and re-try".

Okay, I can buy that.

>> conference are subtly different. Do we expect the same UA behavior  
>> in both cases?
>
> yes, see above.
>

Okay.

> explicitly say it, and indicate that the focus should always allow  
> users to remove the nickname in this way.

I was assuming something like that--assuming the semantics of an empty  
nickname string mean the right thing. Would it make sense to  
completely omit the Use-Nickname header?

>
>
>> Section 8:
>> Is support for private messaging and nicknames considered optional  
>> for devices that implement chat? If not, then we could get by  
>> simply signaling support for chat or not. If they are optional,  
>> that was not clear to me from the specification on them (maybe I  
>> missed something.)
>
> The main thing here is the chat room policy, which may disallowed  
> either nicknames or private messages, or both. That's the reason why  
> we need that level of granularity.

Okay.

> How would that different from MSRP as per RFC 4975? I would like  
> figures to have a value for the chat room draft. And the point of  
> this figure is to show how a message is distributed (which is  
> obvious, but still...).
>

Is the switch expected to generate a REPORT request back to the  
original sender that delivery to the recipient failed? (This is  
loosely connected to my first comment on how this draft interacts with  
the various error reporting models that one can request in MSRP.)

> Ooops, this is obviously an error. There should be a 200 OK from Bob  
> to the MSRP switch rather than the MSRP SEND to Charlie.

Okay.

>> examples of things to think about. Even if the answers seem obvious  
>> to us it might not to others:
>> Can MSRP switches be used for amplification attacks? I don't think  
>> so, since endpoints must explicitly join sessions, but I might be  
>> missing something. It's worth a discussion.

Cool.

Thanks!

Ben.

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 Mar 2008 19:32:00 +0200

Ben:

I haven't given a thought to the reporting model and all the 
implications. Certainly, this is a topic for further consideration.

Issue: requiring message/cpim. I agree that we need to put all these 
warnings that you mention.

Issue: checking the recipient's URI in CPIM headers. The discussion 
follows below.
> So should the recipient endpoint check to see if its user is on the To 

Mmmm... so this check will allow to detect an error, right? that is the 
only benefit of it. If an MSRP switch accidentally forwards a private 
message for a recipient that is not listed in the To or Cc headers, then 
  we can safely conclude that the MSRP switch made a mistake. I have no 
problem with providing guidance to detecting this type of error.

> didn't find any text talking about the use of the CC header, other than 
> a passing mention of its existence.

I agree. Perhaps we should indicate in the overall description that the 
draft allows to send private messages to one or more recipients, as well 
as one or more carbon copy recipients. We should also mention that the 
draft does not allow to provide the effect of sending blind carbon 
copies like e-mail systems.

Issue: removing a nickname. Discussion below
> nickname string mean the right thing. Would it make sense to completely 
> omit the Use-Nickname header?

I prefer to be explicit. The semantics are "I want to set my nickname to 
an empty string". So let's do it so in the protocol.

Issue: MSRP reporting model.
>> figures to have a value for the chat room draft. And the point of this 
>> figure is to show how a message is distributed (which is obvious, but 
>> still...).
>>
> 
> Is the switch expected to generate a REPORT request back to the original 
> sender that delivery to the recipient failed? (This is loosely connected 
> to my first comment on how this draft interacts with the various error 
> reporting models that one can request in MSRP.)

Deferred for further consideration, as per previous discussion.

/Miguel

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Mar 2008 13:55:26 -0400

On Mar 10, 2008, at 1:32 PM, Miguel Garcia wrote:

>> I was assuming something like that--assuming the semantics of an  
>> empty nickname string mean the right thing. Would it make sense to  
> I prefer to be explicit. The semantics are "I want to set my  
> nickname to an empty string". So let's do it so in the protocol.

So my UA would then display you as ""? Or should it revert back to  
displaying your AOR? I would think the semantics for the second case  
would be "remove my nickname entirely".
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 14:01:21 -0400

> would be "remove my nickname entirely".

I agree. I would propose: if you want your nickname to be your uri, you 
use the NICKNAME method to change your nickname to your URI.

/a

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 Mar 2008 20:07:33 +0200

> use the NICKNAME method to change your nickname to your URI.

Ok, I don't have problem with this approach.

I understand that the draft should also explicitly say that there is no 
such thing like a user without a nickname, because by default, users are 
allocated with the nickname of his SIP URI. I think we should make it 
explicit in the draft.

/Miguel

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 14:10:26 -0400

On 3/10/08 2:07 PM, Miguel Garcia wrote:
>>>>>> Good question. I think a NICKNAME method containing a 
>>>>>> Use-Nickname  header with the empty value "" will do it. But the 
>>>>>> text should  explicitly say it, and indicate that the focus 
>>>>>> should always allow  users to remove the nickname in this way.
>>>>>>         
>>>>> empty nickname string mean the right thing. Would it make sense 
>>>>> to  completely omit the Use-Nickname header?
>>>>>       
>>> displaying your AOR? I would think the semantics for the second 
>>> case  would be "remove my nickname entirely".
>>>   
>>
>> I agree. I would propose: if you want your nickname to be your uri, 
>> you use the NICKNAME method to change your nickname to your URI.
>>
>
> I understand that the draft should also explicitly say that there is 
> no such thing like a user without a nickname, because by default, 
> users are allocated with the nickname of his SIP URI. I think we 
> should make it explicit in the draft.

That seems quite reasonable.

/a

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Mar 2008 14:40:15 -0400

On Mar 10, 2008, at 2:10 PM, Adam Roach wrote:

>>>>>>> Good question. I think a NICKNAME method containing a Use- 
>>>>>>> Nickname  header with the empty value "" will do it. But the  
>>>>>> I was assuming something like that--assuming the semantics of  
>>>>>> an  empty nickname string mean the right thing. Would it make  
>>>>>> sense to  completely omit the Use-Nickname header?
>>>>>>
>>>> So my UA would then display you as ""? Or should it revert back  
>>>> to  displaying your AOR? I would think the semantics for the  
>>>> second case  would be "remove my nickname entirely".
>>>>
>>>
>>> I agree. I would propose: if you want your nickname to be your  
>>> uri, you use the NICKNAME method to change your nickname to your  
>>> URI.
>>>
>>
>> I understand that the draft should also explicitly say that there  
>> is no such thing like a user without a nickname, because by  
>> default, users are allocated with the nickname of his SIP URI. I  
>> think we should make it explicit in the draft.
>

Agreed.

Thanks!

Ben.