Thanks...I wasn't exactly convinced but I finally found the answer in Section 9.1 of 3841, which put all my (further) questions to rest:
The set of request disposition directives is not extensible on purpose. This is to avoid a proliferation of new extensions to SIP that are "tunneled" through this header field. -Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -----Original Message----- From: Dean Willis [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 1:04 PM To: Sumit Garg Cc: [email protected] Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-answermode-06.txt Sumit Garg wrote: > > Why exactly do we require these additional (Answer-Mode and > Priv-Answer-Mode) headers? Couldn't this have been done by extending > the Request-Disposition header as defined in RFC3841 (which this draft > references..). Are there any specific advantages of having new headers > rather than additional directives for Request-Disposition? It seemed to many of us that RFC 3841's Request-Disposition header was about request routing in a proxy, not feature-invocation at a user agent. This position is supported by the following excerpt from RFC 3841: 4. Overview of Operation When a caller sends a request, it can optionally include new header fields which request certain handling at a server. These preferences fall into two categories. The first category, called request handling preferences, is carried in the Request-Disposition header field. It describes specific behavior that is desired at a server. Request handling preferences include whether the caller wishes the server to proxy or redirect, and whether sequential or parallel search is desired. These preferences can be applied at every proxy or redirect server on the call signaling path. That said, there are myriad ways that the functionality of Answer-Mode could be encoded in a SIP request. At the heart of the question lies the "What is (or are) the extension model(s) of SIP? And if there are more than one, how do we know which to use to provide some desired behavior? The approach taken by Answer-Mode treats SIP as an application protocol, where knowlegde of the application's state or function is encoded directly into the protocol, and new application function requires a protocol extension. This may or may not be "right", but it is the oldest of the extension modalities I have observed being used in SIP. Request-Disposition is arguably eitehr another application of this extension model, or is perhaps yet another category -- a change to SIP that impacts the core operation of the protocol at a level below that of the application. As documented, Request-Disposition actually impacts the request-routing logic in a matter that seems to be completely independent of the application usage. Another alternative, using the "SIP as transport" modality, would have been to put the Answer-Mode function into the SDP. The third modality, "SIP as a session control protocol", is ruled out because in typical use, the alerting phase occurs BEFORE the SIP-initiated-session is established. So unless we want to change the alerting process to be post session-establishment, we can't affect alerting by changing the session protocol. -- Dena _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
