Re: Simple chat: Christer's comments

Hi Christer, see some inline replies.

On 26/02/2012 20:05, Christer Holmberg wrote:
>
> 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.


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

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



/Miguel

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