Re: Simple chat: Christer's comments

Hi, 

>>>> - 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.
>>
>> Why not "MUST only"?
>
> Because I want to leave an open door for someone who has a very good reason to add this header to a method different than NICKNAME.

Fair enough, but if that is the intention then I don't think SHOULD fits either. Instead, I rather write that this specification only defines the usage of the header for NICKNAME, and if someone wants to use it with another method the usage must be defined in a dedicated spec.

>>>> - 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.
>>
>> Would it be better to say that it is allowed to included a 'chatroom' attribute in an SDP answer, even if the associated offer did not contain one?
>>
>> That way you actually describe answerer behavior, rather than just indicating that the offerer may receive the attribute in an answer.
>
> I have now replaced the last sentence of the proposed new text with this one:
>
>     Consequently, an SDP answer MAY contain a 'chatroom'
>	attribute even if its corresponding SDP offer did not include
>	it.

Ok.


>>>     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.
>>
>> It is good, but to be really clear I would also suggest the following sentence - where I'll let you add the end of the sentence :)
>>
>> "If the 'chatroom' attribute is not included in a subsequent SDP offer/answer, it indicates that<insert-end-of-sentence>."
>
> Ok, this is the new sentence:
>
>     If the 'chatroom' attribute is not included in a
>	subsequent SDP offer/answer, but is corresponding MSRP stream
>	is still in place, it indicates that support for the
>	procedures indicated in this document are disabled.

Good.

Regards,

Christer