Subject: [Simple] Review of draft-ietf-simple-chat-06

From: Ben Campbell <[email-masked]>
Date: Thu, 13 May 2010 14:33:44 -0500

<as-individual>

Hi,

I think this version pretty much addresses my WGLC comments from 05. I have a few new comments, none of which I consider major.

I copied Miguel directly, in case any of these impact his round of edits.

Thanks!

Ben.

----------------------------------------------

Substantive Comments:

-- 5.2, 2nd to last paragraph:

The draft should either explain what it means by an "anonymous URI", or reference an explanation elsewhere. (I note comments from Paul on the anonymous URI reference that occurs later in the draft.)

-- 6.1, 2nd paragraph after bullet list:

I think the proscription that the switch MUST NOT modify SEND bodies is too strong. I think the idea is that you don't modify _content_. But it might be perfectly reasonable for a switch to rechunk content in the same way that an MSRP relay can. Do we intend to forbid that? If the concern is that we don't break potential integrity protection, that should not be a problem for rechunking, since any crypto should be applied prior to chunking in the first place.

-- 6.1, last paragraph:

Why are the SHOULDs here not MUSTs?

-- 6.2, 4th paragraph:

it's not quite enough that the to header is not the conference uri. It must match an actual participant, right?

-- 6.3 3rd paragraph:

How does this interact with the idea that a participant may join from more than one location? Can a private message end up with multiple reports?

-- 6.3, last paragraph, last sentence:

I think the requirement is backwards. The switch must not report a failure on a message it was actually able to forward.

-- 7 (General)

We need to say something about how REPORTs and responses are handled for the NICKNAME method. I _think_ the right answer is that NICKNAME requests MUST NOT contain Failure-Report or Success-Report headers. Since it's a non-SEND request, "responses" are sent end-to-end. 4976 says that relays will treat non-SEND requests the same way they treat REPORT requests, which is to forward them, but never generate responses or REPORTs as a result.

-- 7.5 " If nicknames are not supported nor allowed, the participant list conference will be less presentable."

Why? This is a ui consideration. I think I can come up with a presentable way to display URIs, at least if they have display names.

-- 9.3: 

What happens to the MSRP responses if Failure-Report is set to "no"? We probably need some comment on that in the definition of the NICKNAME method. I think it might be reasonable to forbid Failure-Report:no for NICKNAME. (Maybe even forbid the *-Report headers entirely, and force the default reporting model.

It might also be of interest to show an MSRP relay in this example, to illustrate how the NICKNAME status code

Editorial Comments:

-- Section 3, Req-8:

I think there are some words missing?

-- 5.2, 2nd paragraph: "The SIP URI from the dialog of which the participant is known to the focus, MUST be notified to the MSRP switch."

The sentence is awkward. I think you want something like: "The focus must inform the MSRP switch of the participant's SIP URI." (or "identity", or something)

-- 5.2, last paragraph: "This is to prevent that the MSRP switch distributes private messages to participants who do not support private messaging."

Awkward sentence. I suggest "This is to prevent the MSRP switch from distributing..."

-- 6.1, 2nd paragraph

s/accepted-types/accept-types

-- 6.2, last paragraph:

This paragraph is hard to follow--I suggest rewording it. I think I understand that the idea is that if the same identity joins a chat from multiple MSRP sessions, each session should get a copy of any private message to that identity. But it's hard to be sure from the text.

-- 7.1, 3rd paragraph, last sentence:

I think there are some missing words.

-- 9 (General)

What do the "F" prefixes for each message refer to? E.g. F1, F2, etc. There's no "F"s in the ladder diagrams. 

Also, thanks for adding the figure numbers--but I think it went a little overboard. I don't think of the message details as "figures" per se, and the captions on them are distracting.

-- 9.1, F2:

s/envelops/envelopes

-- 9.3:

MSRP responses should not include the Byte-Range header. That goes in SEND or REPORT requests, but not responses per se.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 17 May 2010 12:35:04 +0200

Hi Ben:

Thanks for the review. Some inline comments.

> I copied Miguel directly, in case any of these impact his round of edits.

The MSRP switch can rechunk.

We will clarify that what the MSRP cannot modify is the content of the 
message.

> Why are the SHOULDs here not MUSTs?

I believe these are SHOULDs because these are just recommendations that 
affect the implementation of the endpoint and not the interoperability of 
the protocol. One can implement and endpoint that behaves somehow 
differently without breaking the specification.

> it's not quite enough that the to header is not the conference uri. It must match an actual participant, right?

That's correct. Actually, the text refers to a validation explained in 
Section 6.1, which hints for a "valid" URI of the From header. I have 
clarified in Section 6.1 that is a "valid URI of a participant".

> How does this interact with the idea that a participant may join from more than one location? Can a private message end up with multiple reports?

No, I don't think so. The text says that reports that the MSRP switched 
are not propagated to the sender.

> I think the requirement is backwards. The switch must not report a failure on a message it was actually able to forward.

Yes, true. But this paragraph is discussing what to do with a message if 
the recipient does not support private messages, and the sentence says 
what is obvious: the MSRP switch must not forward a private message if 
the recipient does not support private messaging.

On editing this paragraph in the draft, I have realized that we may have 
a scenario with a private message addressed to several recipients, some 
of them might support private messages and others not. In the sake of 
simplicity, I think we should say that the whole message is rejected.

Please revised my proposed text and comment it:

           For private messages, if one of the recipients does not
           support private messages, the MSRP switch MUST reject the
           request with a 428 response.  This new response 428 indicate
           that the recipient does not support private messages. A
           REPORT request MUST include a Message/CPIM wrapper, with the
           original From header field included in the SEND request, and
           the To header field of the original message.  The MSRP
	  switch MUST NOT forward private messages to a recipient that
	  does not support private messaging.

> We need to say something about how REPORTs and responses are handled for the NICKNAME method. I _think_ the right answer is that NICKNAME requests MUST NOT contain Failure-Report or Success-Report…

Agreed. I have added a sentence in Section 7.1, when the construction of 
NICKNAME requests is described.

> Why? This is a ui consideration. I think I can come up with a presentable way to display URIs, at least if they have display names.

I am not responsible for this sentence, so I am just guessing that the 
intention is to say that, for a user, a nickname is easier to render and 
remember that any URI, which is a network address.

> What happens to the MSRP responses if Failure-Report is set to "no"? We probably need some comment on that in the definition of the NICKNAME method. I think it might be reasonable to forbid Failure…

The NICKNAME method has been discussed earlier in this e-mail and agreed 
to forbid *-Report headers on it.

> It might also be of interest to show an MSRP relay in this example, to illustrate how the NICKNAME status code

Honestly, I think we have enough examples. We have put effort in 
demonstrating chunking and other aspects, such as nicknames. I guess MSRP 
relays are better described in RFC 4976.

> I think there are some words missing?

Ok, slightly reworded.

> The sentence is awkward. I think you want something like: "The focus must inform the MSRP switch of the participant's SIP URI." (or "identity", or something)

Yes, the sentence is poor. Furthermore, I disagree with having a "MUST" 
strength here, because it is imposing a requirement on the 
focus-to-MSRP-switch interface, which is outside the scope of this 
document. I propose:

	  The MSRP switch needs to be aware of the URIs of the
	  participant (SIP, Tel, or IM URIs) in order to validate
	  messages sent from this participant prior to their
	  forwarding. This information is known to the focus of the
	  conference. Therefore an interface between the focus and the
	  MSRP switched is assumed. However, the interface between the
	  focus and the MSRP switch is outside the scope of this
	  document.

> Awkward sentence. I suggest "This is to prevent the MSRP switch from distributing..."

Correct. And I have also remove the MUST strength between the focus and 
the MSRP switch.

> s/accepted-types/accept-types

fixed

> This paragraph is hard to follow--I suggest rewording it. I think I understand that the idea is that if the same identity joins a chat from multiple MSRP sessions, each session should get a copy of…

Can you be a bit more specific on what is hard to follow. Or even suggest 
some wording, because I don't know what is the text that is hard to follow.

> I think there are some missing words.

Correct. Fixed.

> What do the "F" prefixes for each message refer to? E.g. F1, F2, etc. There's no "F"s in the ladder diagrams.

I have fixed the figures to include Fx :-)

> Also, thanks for adding the figure numbers--but I think it went a little overboard. I don't think of the message details as "figures" per se, and the captions on them are distracting.

Done.

> s/envelops/envelopes

Fixed.

> MSRP responses should not include the Byte-Range header. That goes in SEND or REPORT requests, but not responses per se.

Fixed.

/Miguel

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 17 May 2010 14:07:59 -0500

Hi Miguel and Geir Arne,

Thanks for the response. A few response-responses below. Anything I've edited out should be taken as "Okay".

Thanks!

Ben.

>> I copied Miguel directly, in case any of these impact his round of edits.

I didn't see a response on this one. I know you talked about taking out the reference that Paul mentioned. But I'm afraid we're now in the position of saying to use this "thing" without any way for an implementor to know what the "thing" actually is.

[...]

> I believe these are SHOULDs because these are just recommendations that affect the implementation of the endpoint and not the interoperability of the protocol. One can implement and endpoint that behaves somehow differently without breaking the specification.

I'm okay with the parts that talk about how you render the message to the recipient. But is it reasonable for the parts about inspecting the From and To headers to be SHOULDs? What happens if you don't do that, and the From or To had an unexpected value?

[...]

> No, I don't think so. The text says that reports that the MSRP switched are not propagated to the sender.

The problem is, the text says that the switch MUST forward reports for private messages. This is (I assume) based on the assumption that private messages are not "switched" to more than one destination. But the guidance for handling the same person connected on multiple sessions was to switch the private message to each connection. So in that case they _are_ switched to multiple destinations.

The text as written gives the sender good reason to assume that REPORTS will be handled e2e for private messages. The sender has no way of knowing that the recipient is connected multiple times.

I think their are two possible approaches to this: The first would be to allow e2e reports for any message that goes to a single destination, and give guidance that the sender cannot know in advance whether this will be the case or no. The second would be to merely make the switch act as a b2bua for report purposes regardless of message type. I have a mild preference for the second for the sake of simplicity, but can live with either.

> Yes, true. But this paragraph is discussing what to do with a message if the recipient does not support private messages, and the sentence says what is obvious: the MSRP switch must not forward a private message if the recipient does not support private messaging.
> 
> On editing this paragraph in the draft, I have realized that we may have a scenario with a private message addressed to several recipients, some of them might support private messages and others not. In the sake of simplicity, I think we should say that the whole message is rejected.
> 

I'm generally okay with this, but I note that we're having to add quite a bit of complexity around this idea than a single participant may have multiple connections to the same chat session. Is that feature really worth it?

And while we're at it, can a participant in a chat room be another chat room?

[...]
> Can you be a bit more specific on what is hard to follow. Or even suggest some wording, because I don't know what is the text that is hard to follow.

Hmm. Looks okay now. Either I was tired when I reviewed it, or maybe I pointed to the wrong section. In any case, never mind :-)

[...]

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 May 2010 09:12:50 +0200

Hi Ben

Some more inline comments.

> I didn't see a response on this one. I know you talked about taking out the reference that Paul mentioned. But I'm afraid we're now in the position of saying to use this "thing" without any way for…

True, I didn't have an immediate comment, and forgot to eventually 
address it.

So, what can we do with the anonymous URI. I think that the spirit of the 
draft is to say that it is possible to use any mechanism to get an 
anonymous URI. One of these mechanisms is a temporary GRUU, in which case 
we can refer to RFC 5627.

Is it ok if we refer to RFC 5627 as an example of a mechanism to obtain 
an anonymous URI?

> I'm okay with the parts that talk about how you render the message to the recipient. But is it reasonable for the parts about inspecting the From and To headers to be SHOULDs? What happens if you d…

Let's analyze the SHOULDs on a case by case basis:

1) The sender SHOULD populate the From header of the Message/CPIM wrapper 
with a proper identity by which the user is recognized in the conference.

The protocol is not broken if the sender uses an unknown identity in the 
 From header, but messages sent "from this identity" will most likely be 
rejected by the MSRP switch. From my perspective, it is OK to have a 
SHOULD, but I don't have a problem in turning it into a MUST.

2) The MSRP switch that receives a SEND request from a participant SHOULD 
first verify that the From header field of the Message/CPIM wrapper is 
correctly populated with a valid URI of a participant.

This is clearly a SHOULD because it is describing an action determined by 
the most common policy: only participants of the conference can inject 
messages to the conference. This is a policy of the switch, someone could 
have other policy. Besides, there are some senders to which this 
restriction does not apply, for example, a super user, or the conference 
itself it it sends a Message of the Day or welcome message.

3) Here is a non-normative "should":
    Then the MSRP switch should inspect the To header field of the
    Message/CPIM wrapper.

I think this should be MUST. It is required that the MSRP switch inspects 
the To header of the CPIM wrapper in order to determine whether the 
message is private or regular. I suggest this to be turn to a MUST.

4) Instead, once the MSRP switch has received the
    headers of the Message/CPIM body it SHOULD start the distribution
    process.

This is describing a best practice or what is believed to be the best 
implementation option, but it does not have any effect in the protocol, 
just in the performance and the end user experience. I suggest to leave 
it as it is.

5) An MSRP endpoint that receives a SEND request from the MSRP switch
    containing a Message/CPIM wrapper SHOULD first inspect the To header
    field of the Message/CPIM body.

This inspection is not strictly needed, for example, if an endpoint does 
not implement private messaging, then there is no need to do such 
inspection. I suggest to leave this as a SHOULD. There is a similar 
sentence affecting to the From header, which I suggest to leave as is for 
the same reason.

I guess the decisions we take in 6.1 should be extrapolated to 6.2.

> I think their are two possible approaches to this: The first would be to allow e2e reports for any message that goes to a single destination, and give guidance that the sender cannot know in advanc…

I agree with the use case. Not only that, a private message may contain 
more than one recipient. So, the use case of a one-to-many private 
message clearly exists.

My take on this is that we should probably move away from the intention 
of the draft. Rather than having two report models, there should be only 
one, which valid for both private and regular messages. We should clearly 
specify that reports are exclusively handled between the endpoint and the 
MSRP switch, and never end to end (to avoid that a user receives several 
reports).

Will this solve the issue? Do we foresee additional problems if we unify 
the report model for both private and regular messages?

> I'm generally okay with this, but I note that we're having to add quite a bit of complexity around this idea than a single participant may have multiple connections to the same chat session. Is tha…

Actually, the feature that probably adds complexity is the idea of 
sending a private message to multiple recipients. We are taking the 
simplest approach, which is, "everything must be OK, otherwise everything 
is rejected". I don't think this is too much complexity

> And while we're at it, can a participant in a chat room be another chat room?

The use case of cascaded focus/switches has never been a requirement. I 
would simply say that we have never thought of it. Most likely this 
should be another effort, and we should keep restricted to our initial scope.

/Miguel

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

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 18 May 2010 11:59:51 +0200

Miguel, Ben

[snip snip]
> Is it ok if we refer to RFC 5627 as an example of a mechanism to
obtain

Version -05 tried to include behavior for utilizing temporary GRUU's as
the mechanism to achieve anonymity, but it raised a few issues. I'm not
sure referring to it will raise the same ones, but version 6 tried move
in the direction of explaining the desired effects instead of explaining
how to get it.  IMHO this is not the draft that should resolve anonymous
URI interoperability.

Geir Arne

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 18 May 2010 13:04:38 +0200

Miguel, Ben

Comments inline.

> > [snip snip]
> > I think their are two possible approaches to this: The first would
be
> to allow e2e reports for any message that goes to a single
destination,
> and give guidance that the sender cannot know in advance whether this
> will be the case or no. The second would be to merely make the switch
> act as a b2bua for report purposes regardless of message type. I have
a
> mild preference for the second for the sake of simplicity, but can
live
> with either.

This has been discussed before - and we have even consensus poll. The
current draft does not support having multiple recipients in the To
header.  Both private messages and chat room messages have one and only
one recipient making it possible to have a single response code for
message delivery failure.  It makes things explicit, and the client
doesn't have to guess what went wrong.

> of the draft. Rather than having two report models, there should be
> only one, which valid for both private and regular messages. We should
> clearly specify that reports are exclusively handled between the
endpoint and
> the MSRP switch, and never end to end (to avoid that a user receives
> several reports).

The main reason for not propagating the reports for chat room messages
is that a client could receive multiple ones.  That is not an issue for
private messages, and the current draft allows for the forwarding the
report.  We could remove this possibility to have a single reporting
model.

Geir Arne

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 May 2010 14:32:19 +0200

Hi Geir:

I agree that this draft should not solve the issue of anonymous URIs. I 
was just trying to highlight that we have one example of a mechanism at 
the UE's disposal to get an anonymous URI. I think it is feasible, and it 
is better than nothing.

/Miguel

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 May 2010 14:36:36 +0200

Inline comments.

> doesn't have to guess what went wrong.

Ok, if this is the case, then the draft needs text to say that multiple 
To headers are not supported, forbid the UE to insert multiple To 
headers, and needs to include provisions for the MSRP switch to reject a 
message if contains multiple To headers.

> report.  We could remove this possibility to have a single reporting

I would suggest to do it. This way, if in the future multiple To headers 
are allowed in private messages, you do not need to change the model again.

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 May 2010 08:35:23 -0500

> how to get it.  IMHO this is not the draft that should resolve anonymous

I think I would be okay with the temp gruu. I'd probably be even ok if we said the mechanism for an anonymous URL is simply out of scope. My complaint on the existing text is we say you can use an anonymous URL as if we expect one to know what that means.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 May 2010 08:39:30 -0500

> doesn't have to guess what went wrong.

I was going to make a similar comment. Does the current draft forbid multiple CPIM To header values?

> report.  We could remove this possibility to have a single reporting

Even with a single To header value, the draft allows the private message to be sent to more than one place, due to the possibility that the recipient is connected with multiple simultaneous MSRP sessions.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 May 2010 08:45:00 -0500

On reflection, since we had a prior consensus to remove the GRUU reference, we should probably not add it back unless we've found some strong new argument. I'm okay with the mechanism being out of scope as long as we explicitly say that.

On May 18, 2010, at 7:32 AM, "Miguel A. Garcia" <[email-masked]> wrote:

> Hi Geir:
> 
> I agree that this draft should not solve the issue of anonymous URIs. I was just trying to highlight that we have one example of a mechanism at the UE's disposal to get an anonymous URI. I think it is feasible, and it is better than nothing.
> 
> /Miguel
>

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 18 May 2010 17:09:38 +0200

Ben,

[snip snip]
> Even with a single To header value, the draft allows the private
> message to be sent to more than one place, due to the possibility that
> the recipient is connected with multiple simultaneous MSRP sessions.

I was thinking that only one was directly addressed.  Seems like the
reporting optimization for private messages only creates havoc, and
should be removed.

Geir Arne

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Tue, 18 May 2010 17:40:31 +0200

Miguel,

Comments inline.

> headers, and needs to include provisions for the MSRP switch to reject
> a message if contains multiple To headers.

If we allow for multiple To headers, a lot of behavior needs to be
addressed. A possible worst case scenario could be having a client
adding a To header with the chat room URI, and adding another To header
for a private message recipient that doesn't support private messages
and finally one To header for a private message recipient that does
support it.  I'm not opposed to doing this, but I'll rather see it in as
a future extension not interfering with basic interoperability.

> I would suggest to do it. This way, if in the future multiple To
> headers are allowed in private messages, you do not need to change the
model
> again.

Agreed. Seems like the best thing to do.

Geir Arne

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 May 2010 20:39:16 +0200

> a future extension not interfering with basic interoperability.

I think it is reasonable to dispatch this document with the known 
limitation that private messages can only be addressed to one and only 
one recipient. If there is future interest in supporting multi-recipient 
private messages, an extension or a revision of the document can address it.

So, let me revise the document to clarify that issues I pointed out in an 
earlier e-mail:

- The draft clearly needs to state the intended limitation.
- The draft should forbid adding more than one To header to any message
- The draft should say that the MSRP switch needs to reject messages 
containing multiple To headers.

/Miguel

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 May 2010 21:01:04 +0200

> On reflection, since we had a prior consensus to remove the GRUU reference, we should probably not add it back unless we've found some strong new argument. I'm okay with the mechanism being out of…

OK, let's go for it.

/Miguel

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 14:29:18 -0400

I agree. There are many rat holes to be investigated regarding anonymous 
participation.

	Thanks,
	Paul