Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments

[Paul Kyzivat <[e-mail]>]

On 5/30/12 8:52 PM, Shida Schubert wrote:
>
> Hi Paul;
>
>   my comments inline on relevant point..
>
> On May 31, 2012, at 12:52 AM, Paul Kyzivat wrote:
>
>>
>>
>>>> 11. Section 5.2.1 last paragraph
>>>>
>>>> I am assuming that the text is trying to mandate entity adding SIP Feature-Caps header to add a "new" header on top of the existing one if there is and
>>>> prohibit SIP entity wanting to indicate features and capabilities from adding only the value.. Am I correct? If so this I think should be explicitly stated.
>>>
>>> The ABNF allows for having multiple header fields, or a single header field with comma separated values, and the semantics are identical in both cases.
>>> However, we normally don't explicitly talk about both options, but instead talk about adding new header fields.
>>
>> Christer and I discussed this. I had proposed some wording that covered both ways. But it was cumbersome, and I'm not aware of any other draft that deals with it. So I decided I was ok with this. But if Shida has an idea of how to make this clear without being cumbersome then I'm all for it.
>>
>
>   I am okay with it too. I was just wanting to clarify it...
>
>   It may help for those implementors that have read the draft once and
> end up implementing based on ABNF, to add a note in ABNF repeating
> what is stated at the end of 5.2.1.. To encourage implementors to
> follow what is suggested.. To take it even further you can add a text
> with "MUST NOT add value to an existing SIP Feature-Caps header" but
> that may be too much..

I don't want to take a stand that way. I think either way is equally 
acceptable. And adding to an existing header saves bytes, which can 
sometimes matter. So I don't want to discourage doing so.

	Thanks,
	Paul