[Simple] WGLC Review of draft-ietf-simple-chat-04

[Ben Campbell <[e-mail]>]

(as individual contributor)

Summary: This is improving, but there are still some issues that need  
work.

*** Major Issues: ***

1) This draft depends on the use of message/cpim envelopes to  
determine the final recipients of a message. The draft does not take  
into account that with large content, the overall message may be  
broken into chunks. Chunks subsequent to the initial one will not  
contain the CPIM headers. How does an MSRP conference switch figure  
out how to process a mid-message chunk? I can think of two choices off  
hand:

  	a) The MSRP switch has to fully assemble each message prior to  
sending to final recipients. This will be a problem for large  
messages, and would only be remotely feasible with rather draconion  
message size policies.

	b) The MSRP switch must be "message-id stateful", so that once it  
processes an initial chunk, it knows to treat any future chunks with  
the same message-id the same way.

Both of these require keeping more state than I like, but short of  
ditching the CPIM approach altogether, I think b) is the best we can  
do. Whichever route we go, this draft needs discussion and examples of  
switching chunked messages.

2) The draft still has inconsistencies and errors in the way it  
interacts with MSRP reporting complexities. I commented on this in a  
previous version, and the author added language in some sections, but  
other sections still assume a single reporting model. Also, the  
current language replicates a lot of normative text from RFC4975,  
which I think is a mistake.

I think it would be better to treat status reporting abstractly, and  
have a separate section that talks about how this maps into MSRPs  
reporting models. For example, if the normative sections in this draft  
says things like "If condition FOO occurs, send an XXX response", it  
would be better to say "If condition FOO occurs, return an error code  
of XXX". Then in a separate section, point out that MSRP has multiple  
ways of reporting status (including simply not reporting it at all) ,  
and that implementations must follow the those same mechanisms for any  
new error conditions described in this document.

I think this would also help to reduce the dense, complex language  
that Mary commented on in her review.

3) The draft starts off saying that it does not address conferences  
including media types other than MSRP, yet it goes on to say that MSRP  
streams are likely to be part of mixed-media conferences. Req-2 even  
states this as a requirement. If we _do_ want this to cover mixed  
media conferences, then I will have to open old wounds around the  
sending of nickname reservations in MSRP rather than in the signaling  
channel, as I think otherwise you risk nicknames getting out of sync  
for the different media types.

I think the best solution at this point is to simple search and  
destroy any text in the draft implying that this is for mixed-media  
conferencing.


*** Minor Issues and Editorial Comments: ***

-- Section 1, last paragraph: 

This paragraph needs some wordsmithing. It currently makes a number of  
otherwise unrelated assertions about the document.

-- Section 2, paragraph 2:

What do we mean by "tightly coupled"? Are there such things as  
"loosely coupled" conferences?

-- Definition of Chat Room URI: Are we talking about SIP URIs or MSRP  
URIs?

-- Definition of MSRP switch: Need to clarify that a switch is an MSRP  
endpoint, not a relay. 

-- Definition of Anonymous URI: Need reference for GRUU. Also, please  
expand the acronym on first mention.

-- Section 3: Should the numbered requirements use RFC2119 normative  
language?


-- Req-2: This seems to contradict previous statements that this draft  
does not enable mixed-media conferences. Do we not fulfill this  
requirement?

-- Req-3: Does Req-8 contravene this requirement?

-- Req-4: By "determine the recipient", do you mean a participant must  
be able to select the destination of a message it sends, or learn all  
the recipients of a received message?

-- Req-9: I don't think the requirement is really that the switch can  
originate messages, but that the conference owner or administrator may  
send messages to the conference (possibly by using some automated  
agent.) As stated, the requirement has an architectural assumption  
that the switch is that agent.

-- Req-10: Learn features supported by what? The switch? Other  
participants? Also, the "perhaps others" language adds vagueness.

-- Section 4: Paragraph 1:

Need more precision on whether you are talking about signaling, media,  
or both. I infer signaling from the UA and Focus terms, but it would  
be better to be explicit.

-- Paragraph 1: "Each conference participant establishes an MSRP  
session with an MSRP
    switch,..."

We're talking about the same switch, right? i.e. "the MSRP switch"  
rather than "an MSRP switch"?

-- Figure 1: It would be nice to show or reference a picture showing  
how the MSRP switch relates to the conference focus.

-- Last paragraph: Need more precision on SIP vs MSRP, i.e. sends a  
SIP BYE request, and disconnects the MSRP session.

-- Section 5.2, paragraph 1:

It's not always an "additional" message media type--we could have an  
MSRP only conference, right?

-- Last paragraph: How can a participant not support 
receipt of private messages and otherwise support MSRP? What makes  
them different from any other MSRP message that the switch would send?

-- Section 5.3: Regardless of policies on _when_ a chat-room gets  
deleted, what actually happens when an in-progress chatroom is deleted?

-- First paragraph after bullet list: Second sentence is redundant  
with the bullet list.

-- Paragraph 10: Do we need to think about IMDN?

-- Last Paragraph: I think this is a cut/paste or other edit error, as  
it seems to be redundant with several previous statements.

-- Section 6.2: The bulk of this section is identical to that for  
regular messages. Is the only difference that the private message  
contains a particular user in the CPIM To header, and the new error  
code? If so, you could just explain the difference, and say all the  
rest is as usual.

-- Also, since the CPIM To header could contain several kinds of URLs,  
you need to say something more about identity matching according to  
the matching rules of the URL scheme.

-- 2nd to last paragraph: Redundant paragraph--editing error?

-- Section 7.5: Are there normative statements implied in this  
section? Also, 2nd sentence is a fragment.

-- Section 8, 2nd paragraph:

The question of whether an endpoint supports private messages makes me  
wonder if a generic MSRP endpoint is going to work with normal  
conference messages, where the CPIM To header does not match the  
recipient identity.

-- Examples:

We need an example of a multi-chunk message sent to a conference.

Section 9.4: Need an example showing an error sending the private  
message to the final recipient.

Section 9.5: This is entirely a gruu example--does it belong in this  
draft?