Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt

[Paul Kyzivat <[e-mail]>]

Paul J,

I see two alternatives here, but you seem to be straddling them.

1) you can leave the behavior of OPTIONS alone.
    Document a set of practices for how a UAC can use
    OPTIONS to accomplish a ping. In this case, the
    UAS never knows whether an OPTIONS it receives
    is intended as a capability query or a ping.

    + this is relatively quick to accomplish because
      it doesn't require standards action

    + this is relatively quick to deploy, because
      only the UACs that want to ping need be updated.

    - the benefit is limited because you are stuck
      with the way OPTIONS currently works, and with
      the variations in behavior that it allows.

    - pinging this way may be more costly than
      necessary because of the extra work of applying
      policy, including capabilities, and the extra
      size of the message to carry the capabilities

2) define new standardized behavior for pinging,
    with roles for both the UAC and UAS, that is
    different from what OPTIONS does today.

    + the behavior is not constrained by the existing
      definition of OPTIONS. It can be defined
      precisely for the purpose.

    + the implementation can be optimized.
      the server can "fast path" it, and policy
      application can be simplified because little
      is disclosed.

    - it will take longer to get specified because it
      must be standards track. (Note that this will be
      pretty much the same regardless of whether it is
      defined as new optional behavior of OPTIONS, or
      as a new method.)

    - it will take longer to deploy because both
      UAC and UAS must support it.

I guess there is a possible variant on (1):
also do a *clarification* of OPTIONS behavior in cases where there is 
some ambiguity about what response code should be returned in particular 
circumstances. I would be ok with that *if* the clarification applied to 
all uses of OPTIONS. But once you start to do that you start to pick up 
the negatives of (2).

It would also be possible to do a combination of (1) and (2), where (2) 
is preferred if both UAS supports it, with fallback to (1) for those 
that don't.

What I don't see is a way to avoid standards action and yet define 
special optional behavior by the UAS that the UAC can request and know 
was provided. This seems to be what you are seeking.

	Thanks,
	Paul K

Paul E. Jones wrote:
> Paul,
> 
> I don't see it quite the same way.  I don't want to entirely change OPTIONS,
> but I do want to define procedures that devices should follow if they
> implement an OPTIONS "ping" procedure.  This is achieved with a new header
> or targeting a specific address.  It also means that devices that do not
> implement the resulting RFC will still function as they do today.
> 
> If we go the route of introducing a whole new method, it would be years
> before it gets introduced into the market.  We still need to keep the
> OPTIONS "ping" around, because that's what virtually everybody is doing.
> 
> The only thing we proposed in the initial draft was some consistency with
> respect to the way responses were given, etc.  We're not calling for drastic
> changes in the behavior of OPTIONS.  In fact, if a device wanted to return a
> complete response with all of the features it supports, that'd be fine with
> me.  When used as a "ping", it's primarily the response code the peer is
> looking for.  The only negative side effect is a bit more bandwidth on the
> wire, which is likely inconsequential as compared to everything else.
> 
> Paul
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Wednesday, April 28, 2010 10:37 PM
>> To: Paul E. Jones
>> Cc: 'Dean Willis'; 'Michael Miller'; [e-mail]; 'Hadriel Kaplan'
>> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-
>> 00.txt
>>
>> Now that we have established the goal is devising some options/headers
>> to entirely change the behavior of OPTIONS, I would rather see a new
>> method: PING. Given the assumptions being made I can see few if any
>> downsides to this, and definite upsides.
>>
>> IMO the value of using OPTIONS for ping is in those cases where the
>> device being pinged doesn't know that it is being pinged.
>>
>> 	Thanks,
>> 	Paul
>>
>> Paul E. Jones wrote:
>>> Dean,
>>>
>>>> So for example, a new header field "Options-mode" with a value of
>>>> "ping" means "If you support this extension, do not proxy this
>>>> request, just send an immediate 200 OK response  and do not bother
>>>> populating the Supported header field of the 200 OK response."
>>>> Somebody who didn't recognize the header field would just send a
>>>> conventional 200 OK response.
>>> Not objecting to the header, but I think we would have failed in our
>> effort
>>> if the message might possibly be proxied.  The intent was for this to
>> be
>>> peer-to-peer.
>>>
>>>> And perhaps an option tag of "optionsmodeping". That way we can add
>>>> further options-modes, and option tags for them in the future as
>> (and
>>>> if) needed.
>>> So, you want a head like this:
>>>
>>>   Options-Mode: ping
>>>
>>> Or this:
>>>
>>>   Require: optionsmodeping
>>>
>>>> You could basically cut-and-paste the answer-mode draft and be done
>>>> writing in an hour.
>>> Oh, I'll be happy to plagiarize your work ... but not sure exactly
>> what you
>>> want me to copy :-)
>>>
>>> Paul
>>>
>>>
>>>
> 
> 
>