On 5/23/12 6:48 PM, Henry Peter wrote:
> Dale,
>
>>> and (2) Nobody has volunteered to write this draft. (Are you
>>> volunteering to do so?)
>
> There is a draft http://tools.ietf.org/html/draft-jones-sip-options-ping-02
> which has more specifics and would have been nice if this were an RFC.
> Perhaps it can undergo certain reviews before it can become an RFC but at
> least we have a good start already. Do you think you can help get this
> moving towards an RFC? I know you have been involved with the IETF for quite
> a long time and have good influence. Let me know how I can be of help in any
> regard related to this. Thanks Dale.
There *was* such a draft.
It expired two years ago. It wasn't going anywhere.
Thanks,
Paul
> Best Regards,
> Henry Peter
> Henry Peter | Dialogic Inc. | [email protected]
> 209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2
>
> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:[email protected]]
> Sent: Wednesday, May 23, 2012 12:56 PM
> To: Henry Peter
> Cc: [email protected]
> Subject: RE: [Sip-implementors] [dispatch] Need a resolution on the usage of
> SIP OPTIONS -b4-
>
>> From: Henry Peter [[email protected]]
>>
>>> From: Worley, Dale R (Dale) [mailto:[email protected]]
>>>
>>> The practice is fairly well standardized, but not exactly as described
>>> (or at least implied) by RFC 3261.
>>
>> [Henry Peter] If it were standardized so I would not have the
>> situation I am facing where I am hearing from a vendor that 70 is
>> expected in an OPTION no matter where the req-uri points to (in fact
>> it does precisely to the IP and Port and hence no forwarding
>> expected and even if one does that is a different matter of
>> initiating a new OPTION; from the sender point of view, the OPTION
>> is strictly to the next hop and expects a response or not.
>>
>> Worse yet the reference for 70 is being given to RFC 3261! The
>> Max-Forwards cannot stand by itself...it needs a context such as the
>> OPTIONS and where the req-uri points to ...these are not clearly
>> stated...
>
> The reference is not relevant because: (1) As Paul pointed out, 3261
> says SHOULD not MUST, so UACs are allowed to use different values, and
> (2) After a request has passed through one or more proxies,
> Max-Forwards will have been decremented before it reaches the UAS, so
> RFC 3261-conforming devices must accept requests with Max-Forwards
> values smaller than 70.
>
>> Only reason that we may not hear much problems about SIP OPTIONS is
>> because probably everywhere 70 is used...but does it make it right? )
>
> Actually, the value 20 is commonly used. Many vendors decided early
> on that 70 was much higher than was needed for practical
> implementations.
>
>> [Henry Peter] Dale, you can see that you had to make so many
>> statements to clarify and this is precisely expected in an RFC for
>> standard-practice or related. Why is it not that the draft that
>> already exists on this moving towards an RFC?
>
> Because (1) The deviations from RFC 3261 are small (i.e., a UA can
> respond 200 to an OPTIONS even if it cannot accept an incoming
> INVITE), and (2) Nobody has volunteered to write this draft. (Are you
> volunteering to do so?)
>
> Dale
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
