Subject: [sipcore] Usage of Allow-Event header field

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 20 Nov 2009 20:48:15 +0100

This header field was defined by RFC 3265.

It was then reused by RFC 3903.

In RFC 3265 it states:

3.3.7. Allow-Events header usage

   The "Allow-Events" header, if present, includes a list of tokens
   which indicates the event packages supported by the client (if sent
   in a request) or server (if sent in a response).  In other words, a
   node sending an "Allow-Events" header is advertising that it can
   process SUBSCRIBE requests and generate NOTIFY requests for all of
   the event packages listed in that header.

   Any node implementing one or more event packages SHOULD include an
   appropriate "Allow-Events" header indicating all supported events in
   all methods which initiate dialogs and their responses (such as
   INVITE) and OPTIONS responses.

   This information is very useful, for example, in allowing user agents
   to render particular interface elements appropriately according to
   whether the events required to implement the features they represent
   are supported by the appropriate nodes.

   Note that "Allow-Events" headers MUST NOT be inserted by proxies.

So is the above text applicable only to event packages where the SUBSCRIBE / NOTIFY methods are used, or is it also applicable to event packages that could exist only be used on the PUBLISH method?

When I turn to RFC 3903 the text regarding Allow-Events is much more limited, and refers to its usage only within the PUBLISH and OPTIONS methods.

   If necessary, clients may probe for the support of PUBLISH using the
   OPTIONS request defined in SIP [4].  The presence of "PUBLISH" in the
   "Allow" header field in a response to an OPTIONS request indicates
   support for the PUBLISH method.  In addition, the "Allow-Events"
   header field indicates the supported event packages.

7.  Processing OPTIONS Requests

   A client may probe the ESC for the support of PUBLISH using the
   OPTIONS request defined in SIP [4].  The ESC processes OPTIONS
   requests as defined in Section 11.2 of RFC 3261 [4].  In the response
   to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list
   of allowed methods in the Allow header field.  Also, it SHOULD list
   the supported event packages in an Allow-Events header field.

Note that if the RFC 3265 text applies, then Allow-Events should also appear in 2xx PUBLISH responses, and this is not specified by RFC 3903.

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 25 Nov 2009 16:47:58 +0100

Does anyone have a response to this (Adam possibly?) before all the experts on that side of the pond start digging into their thanksgiving turkey.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: Friday, November 20, 2009 7:48 PM
> To: [email-masked]
> Subject: [sipcore] Usage of Allow-Event header field
> 
> So is the above text applicable only to event packages where 
> the SUBSCRIBE / NOTIFY methods are used, or is it also 
> applicable to event packages that could exist only be used on 
> the PUBLISH method?
> 
> When I turn to RFC 3903 the text regarding Allow-Events is 
> much more limited, and refers to its usage only within the 
> PUBLISH and OPTIONS methods.
> 
> Note that if the RFC 3265 text applies, then Allow-Events 
> should also appear in 2xx PUBLISH responses, and this is not 
> specified by RFC 3903.
> 
> regards
> 
> Keith
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>