Subject: Re: [Sipping] Method for URI-List servers to refuse the handling of a URI-List

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 17:11:59 -0500

I don't really understand the motivation for this draft. There are 
countless reasons why a server might not want to process a request. Why 
is it important in this case to communicate the reason back to the UA? 
Why not just send a 400 and be done with it? Is it commonly expected 
that a server will refuse to fan out a request? What remediation to you 
expect the client to take?

-Jonathan R.

Jani Hautakorpi (JO/LMF) wrote:

> Hi all,
> 
> We have written a draft describing a method for URI-list servers to
> refuse the handling of a URI-List. You can find the draft from:
> 
> http://www.ietf.org/internet-drafts/draft-hautakorpi-sipping-uri-list-handling-refused-00.txt 
> 
> 
> The motivation for writing this draft is that currently URI-List servers 
> don't have any explicit method for denying the handling of incoming
> request. This draft describes just that in a form of a new response 
> code, 495 (URI-List Handling Refused).
> 
> I would be very interested in hearing any comments/ideas/thoughts that
> you might have about this draft. So, please send your input to me
> ([email-masked]).
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 02 Nov 2006 08:22:34 +0200

Hi Jonathan,

in addition to the response code you refer to, the draft defines a way 
to inform the client about which entries in the URI-list the server did 
not like, because those entries were lists themselves, and provide the 
individual members of those lists.

For example, a server receives the following URI-list in a request:

[email-masked]
[email-masked]

The second URI in the list is a URI-list that needs to be "exploded" at 
a different server. But our server cannot know that just by looking at 
the URI. It sends a request to each of the URIs and gets an error 
response (the one defined in the draft) and a list with the individual 
members of [email-masked]. The original server then 
sends requests to those URIs.

This is basically an OMA dependency for PoC. The server receiving the 
original request is the controlling PoC server of an ad-hoc PoC session, 
which is created by a request that contains URIs that represent PoC 
sessions at a different PoC server. Any given PoC session can only have 
a single controlling PoC server.

So, the debate here is whether this is general enough to be a regular 
header field or whether a P-header using an existing error code is more 
appropriate.

I believe that the ability to point out which URIs in a URI-list caused 
a server to refuse the request is general enough and, thus, a regular 
header field is the way to go. However, OMA will most likely be equally 
happy if we add the "P-" prefix to such header.

Cheers,

Gonzalo

Jonathan Rosenberg wrote:
>> The motivation for writing this draft is that currently URI-List 
>> servers don't have any explicit method for denying the handling of 
>> incoming