Subject: [Simple] Review of draft-ietf-simple-chat-05.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 17 Dec 2009 11:44:27 +0100

I review the latest version of the draft-ietf-simple-chat-05. I have only 
a suggestion to better improve the understanding of outsiders:

-  The reader can be confused and think that participants learn other 
partipants' nicknames in received MSRP SEND messages. In other words, one 
can think that a received MSRP SEND message contains the nickname of the 
sender. However, the approach the draft describes is different: a 
participant learns other participants' nicknames through a notification 
to the conference event package. This requires each participant to map 
nicknames to other participants' SIP URIs. It is the endpoint's 
responsibility to map a sender's URI to a nickname and display it 
accordingly to the user. This fact should deserve a couple of explanatory 
paragraphs at the beginning of Section 7.

- In Section 9.4, the paragraph that describes flow F1, the text reads:

    She
    addresses the CPIM message to the Bob's nickname, which she learned
    from a notification in the conference event package.

It is incorrect to say that a CPIM message is addressed to Bob's 
nickname. Section 6.1 indicates the types of identities that can be used 
in CPIM messages, and these do not include nicknames. ONLY URIs are allowed.

- I noticed that in many CPM messages examples the draft uses the 
following two SIP URIs:

   sip:[email-masked]
   sip:[email-masked]

   While these are valid SIP URIs, the reader can confuse them with 
nicknames embedded in SIP URIs (a feature that is no longer in this 
version of the draft). Therefore, I would suggest to replace them more 
common SIP URIs:

   sip:[email-masked]
   sip:[email-masked]

- Section 9.5 shows an example of a chuncked private message. If this is 
the purpose of the example, I suggest to replace the GRUU in the From 
header of the CPIM message with a regular URI. We have Section 9.6 to 
show an example of using GRUUs, so no need to mix concepts in the example.

- Figure 20 misses the Flow 4, presumably a 200 response for the MSRP SEND 3.

- In Section 5.2, penultimate paragraph, the text reads:

    The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu
    [I-D.ietf-sip-gruu].

I don't know which recommendation if the GRUU draft the text is referring 
to, so this isn't going to be implemented. The suggestion is to 
explicitly refer to the recommendation (whichever it is).

I also have a number of editorial comments, but these are of no interest 
to the list.

BR,

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

---

From: Geir Arne Sandbakken <[email-masked]>
Date: Thu, 17 Dec 2009 14:15:13 +0100

Miguel,

Thank you very much for the review.  Comments inline.

Miguel A. Garcia wrote:
> I review the latest version of the draft-ietf-simple-chat-05. I have 
> only a suggestion to better improve the understanding of outsiders:
>
> partipants' nicknames in received MSRP SEND messages. In other words, 
> one can think that a received MSRP SEND message contains the nickname 
> of the sender. However, the approach the draft describes is different: 
> a participant learns other participants' nicknames through a 
> notification to the conference event package. This requires each 
> participant to map nicknames to other participants' SIP URIs. It is 
> the endpoint's responsibility to map a sender's URI to a nickname and 
> display it accordingly to the user. This fact should deserve a couple 
> of explanatory paragraphs at the beginning of Section 7.
>
> nickname. Section 6.1 indicates the types of identities that can be 
> used in CPIM messages, and these do not include nicknames. ONLY URIs 
> are allowed.
Yes, this wording was right for a previous revision of the draft, but 
not any more.  I will change it so no nickname terminology are mentioned 
together with the CPIM messages at all.

> version of the draft). Therefore, I would suggest to replace them more 
Agree, and fixed.  This mistake has already created confusion.

> - Section 9.5 shows an example of a chuncked private message. If this 
> is the purpose of the example, I suggest to replace the GRUU in the 
> From header of the CPIM message with a regular URI. We have Section 
> 9.6 to show an example of using GRUUs, so no need to mix concepts in 
> the example.
>
> I don't know which recommendation if the GRUU draft the text is 
> referring to, so this isn't going to be implemented. The suggestion is 
> to explicitly refer to the recommendation (whichever it is).
The allocation of anonymous URIs is no longer part of the specification, 
and all references to GRUU have been removed from the draft.

> I also have a number of editorial comments, but these are of no 
> interest to the list.
Thanks!
>       Miguel
Thanks,
Geir Arne