Subject: [Sip] New Event package response code

From: Dan Petrie <[email-masked]>
Date: Wed, 27 Sep 2006 09:17:56 -0700 (PDT)

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.

Cheers,
Dan

SIPez LLC  
SIP VoIP, IM and Presence Consulting  
http:/www.sipez.com  
tel: +1 (617) 273-4000

_______________________________________________
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

---

From: [email-masked]
Date: Thu, 28 Sep 2006 06:18:24 +0200

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

---

From: [email-masked]
Date: Thu, 28 Sep 2006 23:04:40 -0400

> to the SIP list for suggestings and comments.

I'm not fully aware of your application, but as a general rule, one
expects a notifier to ignore parameters on the Event value that it
does not understand.

So is the invalid-event-parameter processing to be activated when a
notifier receives an event parameter whose *name* it does not
understand, or when it receives a *value* that it does not
support/understand on a parmater that it does?

Could the desired effect be achieved by defining a new option-tag to
use in the Require header?  Could it be achieved with an Accept or
Accept-Encoding header?

   From: [email-masked]

Is this use of XCAP accessing a different resource or just a different
method of accessing the "same" resource?

Dale