Re: [Sip] Sip-199-02: majors and nits from Robert (was: RE: WGLC for draft-ietf-sip-199-02)

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

>>>maj-3) The document defines an option tag but doesn't say what it
means
>>>if it shows up in a Require: header.
>>
>>I think we could say that it means that the UAS must support 199.
>>Whether it then actually sends 199 depends on whether it fulfils the 
>>UAS criteria for sending 199 (see maj-2).
>
>I think that is bad mojo.  You don't want calls failing just because a
b2bua or the far-end UAS doesn't support 199. 
>
>What recourse would there be for the UAC?  What would the UAC do if it
got a 420 response because of it?  It would make 
>the call again without the 199 option tag in Require, or worse it would
fail the call and the user will call tech 
>support - because nothing is going to change when they make another
call attempt with that option tag in Require.  And 
>that is basically the definition of when NOT to put something in
Require, but rather in Supported.

...which is a good reason to say that the UAC should not use Require:
199. But, we still need to say what it means IF it does so, and I think
that was what Robert was thinking about.

>IMHO the draft should say a UAC MUST NOT put the option tag in the
Require header.  If there's some reason some UAC has 
>to do it, they'll ignore the MUST NOT anyway.  But they should think
long and hard before making that mistake, and 
>someone who buys their product should be able to complain to them that
they don't comply with the RFC.

I don't like must-nots if it doesn't break the protocol. But, I agree we
should strongly recommend against it.

>I'm almost tempted to say we shouldn't even have an option-tag at all
(the Supported lists are getting quite big), but 
>I'm guessing we'll have interop issues without it because some UAC's
will barf on receiving a 199, so the UAS needs to 
>know if it can send it. :(

Yes. And, the solution to long Supported lists is not to stop defining
option tags, at least when there are good reasons to define them.

Regards,

Christer
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip