Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-answermode-06.txt

From: "Sumit Garg" <[email-masked]>
Date: Tue, 18 Mar 2008 08:34:34 -0400

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?

-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: Steve Langstaff [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 10:20 AM
To: [email-masked]
Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-answermode-06.txt 

At the last call of this document I raised the following issues:

SRL> Section 4.3.2 states:
SRL>
SRL>    The Answer-Mode and Priv-Answer-Mode header fields have
equivalent
SRL>    functions, except that Priv-Answer-Mode requests a higher level
of
SRL>    privilege in granting the answering mode specified by the
request.
SRL> 
SRL> Would it not make sense to have a single header that performs both 
SRL> of these equivalent functions, using a parameter (e.g. 'high' or
'level=high') to distinguish between the two?
SRL> 
SRL> This might have the following benefits:
SRL> 
SRL> 1) The document would be smaller.
SRL> 2) The implementation may be simpler.
SRL> 3) If the need for more than just two levels of privilege were
found in the future then this could be easily extended, rather than
following the current pattern of needing another header, e.g.
Really-High-Priv-Answer-Mode:

My questions were answered by Dean, but I now notice the following in
the current draft:

   "4.1.  Procedures at User Agent Clients (UAC)

    4.1.1.  All Requests

       A UA supporting the Answer-Mode and Priv-Answer-Mode header
fields
       SHOULD indicate its support by including an option tag of
       "answermode" in the Supported header field of all requests it
sends."

Other sections also mention this single option tag.
 
Would it not make more sense to use two separate option tags, e.g.
"answer-mode" and "priv-answer-mode"? That would seem to be more
orthogonal to me if this scheme were to be open to extension in the
future? 

_______________________________________________
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
_______________________________________________
Sip mailing list  https://www.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: Dean Willis <[email-masked]>
Date: Tue, 18 Mar 2008 12:03:38 -0500

> 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

---

From: "Sumit Garg" <[email-masked]>
Date: Tue, 18 Mar 2008 14:27:28 -0400

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

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 1:04 PM
To: Sumit Garg
Cc: [email-masked]
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-answermode-06.txt

Sumit Garg wrote:
> Priv-Answer-Mode) headers? Couldn't this have been done by extending 
> the Request-Disposition header as defined in RFC3841 (which this draft

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