Subject: [Sip] Optionality for History-Info

From: "Mary Barnes" <[email-masked]>
Date: Thu, 5 Feb 2004 08:39:25 -0600

I'm in the process of updating History Info
(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-01.txt)
based upon a few comments I've received and merging the requirements into
the solution document.  However, I really need more feedback from the
working group to address the primary point raised during the discussion in
Minneapolis on the optionality.  Initial analysis way long ago resulted in
the decision that Local Policy was the best approach to the optionality,
since it didn't seem reasonable to use Require for an optional header and
lack of the header should not prevent a basic request from being processed.
However, a concern has been raised that Local Policy isn't sufficient as it
requires coordination between clients and proxies (i.e. there's no aspect of
the protocol that allows a client to define or discover that the Proxy will
add the header).  Supported, of course, is used to let the Proxy know that
the information, if available, should be included in the responses.  

In taking a few steps back and re-evaluating all the possibilities for
making the optionality more under the control of the protocol and I came up
with the following list of possibilities. It may not be complete, nor are
the list of pros and cons intended to be exhaustive, but I think it serves
as a useful basis for discussion.

1) Use Require 
Pros: 
- Puts the use of the header explicitly under control of the client
initiating the request. 

Cons: 
- Seems extremely restrictive and functionally limiting, although it would
depend upon the application at the end client that wants to make use of the
information as to how detrimental this might be. 
- Doesn't make sense since the applicability of History-Info isn't
restricted to the initiator of the request. 

2) Make use of the Request-Disposition header field as defined in the caller
preferences draft to explicit request History-Info be included:
history-directive

Pros: 
- Consistent with the intent of that header in that it's a mechanism for a
client to request how a server/proxy should handle a request 

Cons:
- that field isn't extensible 
- doesn't really accomplish more than what can be implied by the Supported
header (i.e. if the client wants the information in a response, then if a
server is capable of adding the header, it SHOULD). 

3) Make use of or define something similar to the Session specific policy,
whereby the client "authorizes" a proxy to capture History-Info and that
it's only captured in that case.   

Pros:
- Explicit.

Cons:
- Seems like a lot of overhead, with little advantage. 

4) Follow the approach of existing optional SIP headers added by
intermediaries (e.g. Path and Reason), which is that it's purely a local
policy decision and doesn't require any coordination with the UA as to
whether it should or shouldn't be added. 

Pros: 
- It's fairly straightforward and consistent with the intent of optional
headers.

Cons: 
- Does require some guidelines to ensure that applications that might use
the optional information are robust enough to handle the lack of
information. 

Feedback on these proposals is appreciated and hopefully this discussion
will allow us to reach a final, constructive conclusion.  

Obviously, my preference is the 4th option and perhaps one reason why we've
gotten so stuck on this point is that the guidelines for applications on the
usage of the header are perhaps not obvious.  So, it might be useful to add
an additional section to the document (or perhaps include additional
information for each of the scenarios in the appendix) on application
guidelines around the usage of the information and default behavior if the
information is not available.

Regards, 
Mary H. Barnes
[email-masked]
972-684-5432

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Fri, 06 Feb 2004 11:09:36 +0000

Mary,

I too am happy with option 4.

Regards,

John ([email-masked])

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 05 February 2004 14:39
> To: [email-masked]'
> Subject: [Sip] Optionality for History-Info
> 
>

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 11 Feb 2004 14:12:57 +0100

Mary,
I'm also happy with option 4.

Best Regards

Roland

-----Ursprungliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]Im Auftrag von Mary
Barnes
Gesendet: Donnerstag, 5. Februar 2004 15:39
An: [email-masked]'
Betreff: [Sip] Optionality for History-Info

1) Use Require 
Pros: 

Cons: 

Pros: 

Cons:

Pros:
- Explicit.

Cons:

Pros: 

Cons: 

Regards, 
Mary H. Barnes