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

["Mary Barnes" <[e-mail]>]

Document: draft-ietf-simple-chat-04
Reviewer: Mary Barnes
Review Date: April 21, 2009
WGLC LC End Date: April 27, 2009

Summary: On the right track but needs a good bit more work prior to
progressing.

General comments/questions/caveats:
-----------------------------------
1) Caveat and comments: I am not an MSRP expert and the doc really needs
review by one prior to forwarding, in particular with regards to
ensuring normative protocol changes are correct. Obviously, if Ben is
the PROTO shepherd, that should cover it.  However, my personal opinion
is the doc needs a couple more detailed reviews, or at a minimum
feedback that folks believe the document is ready,  since it is
standard's track. 

2) General question: Does anyone have a implementation of MSRP chat?
That might help identify additional reviewers and would certainly help
validate the completeness of the protocol changes in this document. 

3) General question: What is the relationship between the "MSRP Switch"
and an "MSRP Relay"?   It might be good to also show a diagram of how
the "MSRP Switch" fits into the overall MSRP model, including relays.
This may be quite obvious to most folks, but I think it would help the
average developer understand the "big picture".  It would also help to
clarify this in the definition of "MSRP Switch" (in Terminology -
section 2) since the definition uses the term "relay". One suggestion
might be to use the term "distributed" or "replicated and forwarded",
which is the term that is used in the XCON chat document. 

4) Caveat: I did not review the call flows in detail. Again, if there's
an implementation, it might be good to pull real call flows or have one
of the implementers validate the call flows in the document.


Larger issues (i.e., must be resolved prior to leaving WG):
-----------------------------------------------------------
1) Section 6.2 Private Messages: Either I'm not understanding OR there
is some duplicate text between paragraphs 5 (starting with  "If the
recipient is valid...") and paragraph 7.  I also found that text rather
dense and think that a table might help to clarify the handling of the
various cases of support (or not) of private messages. Also, it might
help to add some more discrete sections to section 6.2.  In particular,
it might help to split out the "sender" versus "recipient" processing,
as well as "MSRP Switch".

2) Nicknames
a) Section 3 (Requirements)
i) REQ-3: deals with determining identities. I'm assuming this should
include Nicknames, however, the definition of Nickname doesn't put it
into the general category of being an Identifer. So, perhaps the
definition of Nickname (in section 2) should be changed to something
like the following OR a separate requirement for Nicknames should be
added:
OLD
  Nickname: a pseudonym or descriptive name associated to a
      participant.  See Section 7 for details
NEW
  Nickname: an additional identifier for a user which provides a
pseudonym or descriptive name associated with the
      participant.  See Section 7 for details

This would consistent with its description in 7.1 - i.e., the statement
"Nicknames are an alternate form of
   identity, associated ....."

b) If a Nickname is another form of identifier,  it should be mentioned
in section 6.1 in the list of identities. 

c) Section 7, 1st paragraph, last sentence.  This is where some of my
confusion is introduced, if a Nickname is another form of Identifier,
then it doesn't seem to me that anonymity is being preserved.  This
likely be more clear when the security considerations are further
documented. 

d) Section 7.1 (Using Nicknames):
i) Paragraph 4 introduces a normative reference to P-Asserted-Identity
(RFC 3325) since this is the only mechanism described for the validation
of the SIP AOR for Nicknames.  
ii) RFC 3325 is not currently listed as a reference, but needs to be
added (to the normative section). 
iii) This security requirement needs to be added to the Security
Considerations (Section 11). And, actually a more detailed description
of potential security issues around the use of Nicknames should be added
to Section 11.

e) Section 7.2 & 7.3(Modifying a Nickname and Removing a Nickname):
These sections do not seem to address the reuse of a Nickname that has
been changed (i.e., the old one) or one that has been deleted. It would
seem that the Nickname should certainly not be reusable within the same
chat room instance in which it was previously being used. And, it would
seem that a specific or recommended length of time should be associated
with a system reusing a specific Nickname. 

f) Section 7.4 (Nicknames in the Conference Event Package):
Aren't you adding the <nickname> attribute to the "user-type" attribute
rather than the the "user" element?  It would be helpful either way to
show the new attribute as it would appear in the context of the schema
for clarity
Also, it might be nice to add an example Conference Event notification
to one of the examples. 


Minor issues (i.e., wbn to resolve or clarify prior to leaving WG):
------------------------------------------------------------------
1) Section 3 (Requirements): REQ-10: I would suggest that you delete the
"(and perhaps others)" from that requirement. It doesn't seem reasonable
to have that as a core requirement since it's open ended, thus you can't
be sure this solution would address the "others". 

2) Section 5.2 - this section doesn't seem to mention how conference
"unaware" participants are involved. Based on the 1st sentence of the
second paragraph of the Requirements (section 3) I understood that they
would be supported. If not, then that needs to be documented. 

3) Section 6.1, second paragraph after the bulleted list, first
sentence. I think the "Then" needs to be qualified, since this
processing wouldn't occur unless the URI is valid.  Thus, I would
suggest to preface that sentence with "If the URI is valid, then"

4) Section 8, 2nd paragraph:  How does the switch respond (to the
sender) in the case of a message sent to a participant that does not
support the functionality in this document?  It would seem that the
sender should be notified, so that Alice could be contacted via another
mechanism or the chat room host might want to pick an alternate
mechanism for communicating.  

Nits/editorial comments (depending upon who does the gen-art review, you
will likely see them again, so it's likely easier to address now): 
------------------------------------------------------------------------
-------
1) Section 1 (Introduction): There's a bit of redundancy in this
section. It would add clarity to move the 4th paragraph prior to the
current 3rd and delete the first sentence in the current third paragraph
as it's redundant with that in the 4th.  The 2nd sentence of the third
paragraph is really too detailed and would fit much better as an intro
to the 5th paragraph.  Thus, I would suggest the following changes:

OLD (3rd P):
   Several such systems already exist in the Internet.  Participants in
   a chat room can be identified with a pseudonym or nickname, and
   decide whether their real identity is disclosed to other
   participants.  Participants can also use a rich set of features such
   as the ability to send private instant messages to other
   participants.  They also allow combining instant messaging with other
   media components, such as voice, video, white boarding, screen
   sharing, and file transfer.

OLD (4th P):

   Similar conferences are already available today with other
   technologies different than MSRP.  For example, Internet Relay Chat
   (IRC) [RFC2810], Extensible Messaging and Presence Protocol [RFC3920]
   based chat rooms, and many other proprietary systems provide this
   kind of functionality.  It makes sense to specify equivalent
   functionality for MSRP-based systems to both provide competitive
   features as well as enable interworking between the systems.


OLD (5th P):
   
   This document defines requirements, conventions, and extensions for
   providing private messages and nickname management in centralized
   conferences with MSRP.  This document, however, does not specify
   functionality that can be used in conference with media different
   than MSRP.  This memo uses the SIP Conferencing Framework [RFC4353]
   as a design basis.  It also aims to be compatible with the
   Centralized Conferencing Framework [I-D.ietf-xcon-framework].  It is
   expected that future mechanisms will be developed for providing
   similar functionality in generic conferences, i.e., where the media
   is not only restricted to MSRP.  The mechanisms described in this
   document provide a future compatible short-term solution for MSRP
   centralized conferences.

================ NEW (with some minor editorial changes
=================
NEW (merging 4th paragraph with the 3rd):
   
   Similar conferences supporting chat rooms are already available today

   supporting media other than MSRP.  For example, Internet Relay Chat
   (IRC) [RFC2810], Extensible Messaging and Presence Protocol [RFC3920]
   based chat rooms, and many other proprietary systems provide chat
room
   functionality.  Specifying equivalent
   functionality for MSRP-based systems provides competitive
   features and enables interworking between the systems.  
   While existing systems combine instant messaging with other
   media components, such as voice, video, white boarding, screen
   sharing, and file transfer, this document does not specify
   functionality associated with media other than MSRP. 

NEW (5th paragraph (with some 3rd paragraph text) becoming the 4th
paragraph): 
   This document defines requirements, conventions, and extensions for
   providing private messages and nickname management in centralized
   conferences with MSRP.  Participants in
   a chat room can be identified with a pseudonym or nickname, and
   decide whether their real identity is disclosed to other
   participants.  Participants can also use a rich set of features such
   as the ability to send private instant messages to other
   participants.  This memo uses the SIP Conferencing Framework
[RFC4353]
   as a design basis.  It also aims to be compatible with the
   Centralized Conferencing Framework [RFC5239].  It is
   expected that future mechanisms will be developed for providing
   similar functionality in generic conferences, i.e., where the media
   is not only restricted to MSRP.  The mechanisms described in this
   document provide a future compatible short-term solution for MSRP
   centralized conferences.

2) Section 2 (Terminology):
a) Private Instant Message - suggest the following change:
OLD
   Private Instant Message:   an instant message sent in a chat room
      whose intended to a single participant.  A private IM is usually
      rendered distinctly from the rest of the IMs, as to indicate that
      the message was a private communication.


NEW
    Private Instant Message:   an instant message sent in a chat room
      intended for a single participant.  A private IM is usually
      rendered distinctly from the rest of the IMs, indicating that
      the message was a private communication.

b) Anonymous URI: "..in the a..." ->  "...in the..."

2) Section 6.2 (Private Messages):
a) 3rd paragraph, 1st sentence: It's not clear to me what is meant by
"regular instant message". Is it referring to the "received" instant
message which is to be sent to the specific participant. 
b) 5th paragraph, 3rd sentence: "...cased by..." -> "...caused by...."

3) Section 7.1 (Nicknames)
a) 1st paragraph: "as long as the participants is" -> "as long as the
participantis"
b) 1st paragraph: "other mechanisms may exists" -> "other mechanisms may
exist" 

4) Section 7.5 - "chat room do not allow" -> "chat room does not allow"

5) Section 8, 6th paragraph (the one right after the attribute syntax):
i)  "allows to use the procedures" ->  "allows the use of the
procedures" (2 occurences)


6) In addition to the nits listed above, the IDNITS identified below
must be fixed prior to forwarding the document. 

idnits 2.11.08 

tmp/draft-ietf-simple-chat-04.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
------------------------------------------------------------------------
----

     No issues found here.

  Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == Line 602 has weird spacing: '...ssaging  and P...'

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is
what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     Then the MSRP switch MUST inspect the To header field of the
     Message/ CPIM wrapper.  If the To header field of the Message/CPIM
     wrapper does not contain the chat room URI, it must check if it
contains
     a participants URI associated with a participant.  If the URI in
the To
     header can not be resolved (e.g. cased by a mistyped URI or that
the
     recipient has abandoned he chat room), and the Failure-Report
header
     field of the SEND request was either not present in the original
request,
     or had a value of "yes" or "partial", the MSRP switch MUST generate
a
     REPORT request to the sender.  The status header field MUST be set
to
     427.  The new 427 status code indicates a failure to resolve the
     recipient URI in the To header field.  If the recipient is valid,
but the
     recipient does not support private messages, and the Failure-Report
     header field of the SEND request was either not present in the
original
     request, or had a value of "yes" or "partial", the MSRP switch MUST
send
     a REPORT request having the status code of 428.  The new response
428
     indicate that the recipient does not support private messages.  In
either
     case the 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 message MUST not be
forwarded
     to the recipient if above conditions applies.  The MSRP switch
should
     search it's mapping table to find the MSRP session established
towards
     the recipient.  If a match is found the MSRP switch MUST create a
SEND
     request and MUST copy the contents of the sender's message to it.


  Checking references for intended status: Proposed Standard
 
------------------------------------------------------------------------
----

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

  == Outdated reference: draft-ietf-xcon-framework has been published as
RFC
     5239


     Summary: 1 error (**), 3 warnings (==), 0 comments (--).