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

[Ben Campbell <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/simple