Subject: RE: [SIP] Removing 409 to conflicting action params

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 03:34:49 -0500

It seems this issue is still open. Comments below.

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2001 4:33 AM
> To: Jonathan Rosenberg
> Cc: Robert Sparks; [email-masked]
> Subject: Re: [SIP] Removing 409 to conflicting action params
> 
> 
> Jonathan Rosenberg wrote:
> >  
> > > -----Original Message-----
> > > From: Neil Deason [mailto:[email-masked]]
> > > Sent: Friday, February 09, 2001 8:35 AM
> > > To: Jonathan Rosenberg
> > > Cc: Robert Sparks; [email-masked]
> > > Subject: Re: [SIP] Removing 409 to conflicting action params
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > The reason it was there is that if the proxy DOES want to
> > > follow it, it
> > > > becomes meaningless to have some URLS with redirect, and
> > > some with proxy.
> > > > What does the proxy do?
> > >
> > > I am not asking that Proxy/Registrars be forbidden from
> > > responding
> > > 409 just that they be free to choose not to. Presently a
> > > registrar
> > > MUST respond 409 to conflicting action params. I don't want to
> > > be forced to respond 409 when somebody has their mailto URL
> > > registered
> > > with an redirect action and then wants to add a SIP URL which
> > > they want requests proxied to.
> > 
> > It is not that simple. If you allow proxies to accept these 
> kinds of things,
> > that means you allow clients to send them. Once you do 
> that, you must define
> > concrete processing rules associated with registrations of 
> this type.
> > Otherwise, a UA now has no way of knowing the
> > processing a proxy will apply to a set of registered 
> Contacts, or worse,
> > what the
> > behavior they're requesting actually is.
> > 
> > As an example, a UA believes it wants a service whereby the 
> proxy server
> > forwards the request to A, and if it fails, redirects to B. 
> So, it registers
> > a contact URL with proxy action as high q value, and a 
> separate contact as
> > redirect action as a lower proxy. It assumes that a proxy 
> server will do
> > this service as a result. THe proxy might accept this, and 
> provide this
> > interpretation, or it might accept it, and provide a different
> > interpretation, or it might reject it. If it rejects it, 
> what does the
> > client do then? Must it alert the user to redefine the parameters? I
> > wouldn't want to handle this customer service call.
> > 
> > However, as defined now, the meaning of a set of registered 
> contacts is
> > CLEAR. If you want more complex behaviors, you send a CPL 
> (and indeed, the
> > above service is readily representable in a clear and 
> unambigous way using
> > CPL). By removing this restriction, and as a consequence, 
> allowing clients
> > to send all kinds of weird stuff, the end result will not 
> be what users
> > expect.
> 
> I think this example is slightly bogus as we both agree 
> this should and will be done by CPL. If anything this example 
> shows how redundant action params are. As things stand both 
> contacts must have been registered with the same action 
> param, either proxy or redirect, and then one of them 
> overridden by CPL. 
> 
> The point isn't to promote action params + q params as an 
> alternative to CPL etc it is more about moving towards 
> deprecating action params. What users really care about is 
> that requests reach them. Whether they do so via an 
> intermediate server redirecting or proxying is of considerably 
> less interest. So removing a servers compulsion to 409 contacts 
> with a mixture of actions is ihmo user friendly.

No, it isn't. The user doesn't know what the behavior of the server will be
if the request is obeyed. How is that user friendly?

> 
> I would also argue that there is little clarity in the status
> quo as presently the only thing specified is that you cannot 
> have a mix of action params. You could register all your 
> contacts with an action of proxy but a server's local 
> config cause it to redirect. Note q params don't come into 
> things as they are already ignored in the basic case. 

But its clear what the user is requesting, to both the user and the proxy. 

> 
> To better define things we could say is something 
> like ...
> 
> Clients MAY use the action parameter within registrations
> as a hint to a server as to how requests to their contacts be 
> handled. Users that want to control a servers action when routing
> requests sent to them should use CPL or SIP-CGI. Servers not 
> wishing to accept registrations with differing action parameters 
> MAY reject them with a status of 409. 
> 
> We could go further defining how servers handle mixed action
> params if it really bothers people. I think it is a bit of a non
> issue - like whether the de facto local server policy is redirect 
> or proxy. I just want requests to find me, for greater control I 
> use CPL.

IMHO, there is really not a bug here, and I think that removing the
restriction will make the behavior unpredictable. So, my recommendation
still stands to keep the text as is. I've marked it as an item to discuss at
IETF if we can't close this before then.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.