Subject: [sipcore] OPTIONS, except not (was Re: [RAI] Option-tag registration)

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 22:20:31 -0500

[as participant]

Moving this conversation from RAI to SIPCORE, since it seems more 
appropriate over here now.

On 4/27/10 21:30, Apr 27, Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: Adam Roach [mailto:[email-masked]]
>> Sent: Tuesday, April 27, 2010 10:01 PM
>> To: Dean Willis
>>
>> This is really, really starting to sound like a new method.
>>      
> Why?  Creating a new method doesn't avoid the issue of intended target routing. (a legacy proxy would forward it like any other unknown method)
>    

It's not just the target routing. Taken in aggregate, this thread has 
basically taken the position that it "works just like OPTIONS, except 
for everything." The removal of OPTIONS' actual raison d'être -- the 
querying of capabilities -- is clearly a last straw.

I know that OPTIONS has the benefit of being one of the Fourteen True 
Methods handed down to Moses on Mount Sinai, but if we're really looking 
at something intended as a liveness check -- as opposed to a 
capabilities query -- let's go ahead and do it correctly.

This is a new thing, let's make it a new thing.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 23:49:45 -0400

> Sent: Tuesday, April 27, 2010 11:21 PM
> To: Hadriel Kaplan
> 

But really the capabilities piece is the "everything" part of a "except for everything".  I mean the rest of it (status codes, max-forwards, etc.) was actually stuff rfc3261 talked about applying to OPTIONS.  So except for the capabilities piece, Paul's draft is just trying to be more explicit about what OPTIONS already legitimately does I think.  No?

But I do think it should query capabilities.  It just may be the capabilities of the target are very, very limited. :)

-hadriel