Subject: Re: [Sip] New Event package response code

From: Dean Willis <[email-masked]>
Date: Wed, 4 Oct 2006 10:59:19 -0500

I'm confused. I thought we had a rough consensus here.

Somebody please hit me with a clue bat. Is the issue Jeroen  
identifies here a show-stopper?

--
Dean

On Sep 27, 2006, at 11:18 PM, [email-masked] wrote:

> Dan,
>
> The basic model in RFC3265 (and SIP/HTTP in general) is that the R- 
> URI contains sufficient information to identify the resource.  
> Adding parameters to the Event header as you propose would break  
> this model: the resource would be a function of the R-URI and these  
> parameters. So the choice is between fundamentally changing SIP or  
> rethinking your draft / solution
>
> Cleanest would perhaps be SUBSCRIBE http://xcap.example.com/root/ 
> resource-lists/users/joe, but the problem is that most SIP proxies  
> won't route such a request. The next best thing would probably be a  
> new URI parameter, e.g. SUBSCRIBE sip:xcap- 
> server.provider.com;document=http%3a//xcap.example.com/root/ 
> resource-lists/users/joe or an embedding in the user part, i.e.  
> SUBSCRIBE sip:http%3a//xcap.example.com/root/resource-lists/users/ 
> [email-masked]
>
> 404 Not found would be the error response when the server does not  
> support this
>
> Regards,
>
> Jeroen
>
>> At the Montreal IETF we identified one problem with the config  
>> package
>> usage with XCAP.  XCAP is not manditory to be supported by the  
>> profile
>> delivery server.  The problem was how does the server indicate  
>> that it
>> does not support XCAP.  We agreed to use the Event header profile- 
>> type
>> as the indication that XCAP is required (i.e.
>> profile-type="application").  We also agreed that an error  
>> response was
>> required if the server does not support XCAP.
>>
>> I propose that we create a new error code that extends RFC 3265.  The
>> error code is to indicate that an Event header has an invalid or
>> unsupported value.  I also propose that we create a new header field
>> that contains the event header parameter(s) and unsupported values 
>> (s).
>>
>>
>> E.g. Invalid-Event-Parameters: profile-type="application"
>>
>> I think that it is generally useful for 3265 implementation that have
>> Event header parameters with enumerated values (tokens or strings).
>> That is to indicate that the Event header parameter value is not  
>> valid
>> or supported.  As this is a protocol change issue, I am submitting  
>> this
>> to the SIP list for suggestings and comments.
>>

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