Subject: [Sipping] Config framework - reporting unsupported event parameters

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Jul 2006 10:01:47 -0400

In the session today there was some discussion of how to report an error 
when a server doesn't a particular parameter on an event package 
subscription. There was suggestion that there be a new response code for 
this (instead of 489 Bad Event), and a new header to report something 
about the parameter.

This is a little clumsy because event types and their parameters are 
carried in a single header:

    Event             =  ( "Event" / "o" ) HCOLON event-type
                         *( SEMI event-param )

But in the existing header to show support, there is no provision for 
parameters:

    Allow-Events =  ( "Allow-Events" / "u" ) HCOLON event-type
                    *(COMMA event-type)

I think the clean way to address the new need would be to extend the 
Allow-Events to include the supported parameters:

    Allow-Events =  ( "Event" / "o" ) HCOLON event-type
                         *( SEMI event-param )

If this were done, then the existing 489 response code would be ok. If a 
request used an unsupported parameter for a supported event, then the 
489 response would contain an Allow-Events that mentioned the event type 
but also the allowed parameters while omitting the unsupported parameters.

There seem to be two problems with the above:
- its not backward compatible
- Allow-Events would have to always mention all supported
   parameters for each mentioned event, which might be
   rather verbose

An alternative might be to still define another header:

    Allow-Event-Params =  ( "Event" / "o" ) HCOLON event-type
                         *( SEMI event-param )

Then, Allow-Events would be making no assertion about what parameters 
are supported. Allow-Event-Params would be making no assertion that the 
list of events mentioned is complete, but would assert that the list of 
parameters is complete for the events mentioned.

I think this could be used without adding another response type. Its 
just that the 489 response would have both an Allow-Events and 
Allow-Event-Params header.

This still has limitations in what it can represent: it can't represent 
dependencies or mutual exclusivity among parameters. But maybe we can do 
without that.

	Paul

_______________________________________________
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