Simple chat: Christer's comments

I am now addressing comments that Christer did in his Gen-ART review. I 
want to thank Christer for sending these comments.

See his comments below and my inline reply.

> 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.

That is not totally correct. The second paragraph says:

"The NICKNAME request MUST include a new Use-Nickname header"

whereas the sixth paragraph tries to say (but apparently failed) in which 
methods the Use-Nickname header could be included:

    The Use-Nickname header field carries a
    nickname string, and SHOULD be included in the NICKNAME requests.

I proposed to add "only" to clarify the paragraph:

    The Use-Nickname header field carries a
    nickname string and SHOULD only be included in NICKNAME requests.


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

I think it should be clear now, see previous comment.


> - 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?
>

Good point. I have reworded these paragraphs, let me know what you think:

    The 'chatroom' attribute merely indicates the capabilities supported
    and allowed by the local policy.  This attribute is not a negotiation
    subject to the SDP offer/answer model, but instead a declaration.
    Therefore, a 'chatroom' attribute included in an SDP answer does not
    need to be a subset of the 'chatroom' attribute included in its
    corresponding SDP offer.  It is also possible that an SDP answer
    contains a 'chatroom' attribute even if its corresponding SDP offer
    did not include it.

    On doing subsequent SDP offer/answer exchanges pertaining to the same
    session, the 'chatroom' attribute MAY be modified with respect an
    earlier SDP offer/answer exchange.  The new value of this attribute
    indicate the current support and local policy, meaning that some
    restrictions can apply now or might have been removed.

I have also added a normative reference to RFC 3264 in the above text and 
other parts of the draft where the SDP offer/answer model is mentioned.

>
> 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?
>

Yes.

Wherever possible, i.e., in most places, I am trying to use "chat room". 
There are places where is not possible, for example, when we refer to the 
conference event package, conference framework, conference focus, etc. 
But I guess this solves your concern.

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

No, these are different. 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.

> -- REQ-6: Change "progress" to "duration" or "length".

Done.


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


Roster is a not a technical term, therefore, it is not subject to be 
define in this draft.


BR,

     Miguel


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