Subject: [Gen-art] Gen-ART review of draft-ietf-simple-chat-13

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Feb 2012 11:13:47 +0100

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document:                  draft-ietf-simple-chat-13
Reviewer:                   Christer Holmberg
Review Date:              12-02.11
IETF LC End Date:     12-02-06
IESG Telechat date: (if known)

Summary:          Ready, but some additional text may be needed based on the minor issues.

Major issues:     None

Minor issues:

- The second paragraph of section 7.1 says that a NICKNAME request MUST contain a Use-Nickname header, but in the sixth paragraph the inclusion is a SHOULD.

- It is not clearly indicated whether the Use-Nickname header is allowed for other methods than NICKNAME.

- Section 8 does not specify whether there are SDP offer/answer considerations/restrictions associated with the new attribute. For example: 
-- Must the attribute tokens in an answer be a subset of the tokens in an offer?
-- Can an SDP answer contain an attribute if the offer didn't?
-- If a user sends a new SDP offer within a session, can the token values be modified? What does it mean if the attribute is not present in a new SDP offer?

Nits/editorial comments:

- Sometimes the document talks about "multi-party chat", "multi-party conference", "conference", and "chat room". Would it be possible to use more consistant terminology?

- Requirements
-- REQ-4: Isn't this requirement already covered by REQ-3?
-- REQ-6: Change "progress" to "duration" or "length".

- There is no definition/reference for "roster".

Regards,

Christer

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 13 Feb 2012 09:05:45 +0100

Hi Christer,

Thanks for your comments, I agree with most of them. Allow me to answer a 
couple of issues of disagreements.

 > -- REQ-4: Isn't this requirement already covered by REQ-3?

No. Req-3 claims for a mechanism for the recipient of a message to 
determine whether the receive message is private or regular.

Req-4 claims for the a mechanism to send private messages.

 > - There is no definition/reference for "roster".

Roster is a not a technical term. According to the Merriam-Webster 
dictionary, there are two entrances for "roster":

1
   a : a roll or list of personnel
   b : such a list giving the order in which a duty is to be performed <a 
duty roster> c : the persons listed on a roster

2: an itemized list

I think the term is clear when we use it in the context of a conference 
with participants.

/Miguel

On 11/02/2012 11:13, Christer Holmberg wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Feb 2012 09:08:09 +0100

Hi,

> Req-4 claims for the a mechanism to send private messages.

True. I didn't realize Req-3 was related to the recipient.

> I think the term is clear when we use it in the context of a conference

Ok.

Regards,

Christer

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