Subject: [Sipping] FW: I-D ACTION:draft-barnes-sipping-history-info-02.txt

From: "Mary Barnes" <[email-masked]>
Date: Wed, 12 Feb 2003 11:26:46 -0600

Hi all,

This document has had several changes as a result of the feedback on the
mailing list:

- Section 2.1 - corrected the terminology to be consistent with the
capturing of the single targeted-to-URI and corrected the syntax of the
index as highlighted by Paul K. 

- In section 2.3, clarified that History-Info can be included in provisional
responses per John E.'s comment

- Additional normative text around the maintenance of the Index added to
section 2.3.1 and 2.3.3 per Paul K's comment.
 
- Added additional sections to 2.3.3 to further clarify the Request and
Response processing 

- Updated the example in section 2.5 to include the use of the Index

- Added a high level flow to Appendix C, highlighting a scenario whereby
local policy prevents the History-Info from being sent in the Responses.

Per my previous posting on the -01 updates, the Security solution required
for History-Info will be addressed in a separate draft (which hopefully can
be put forth before the deadline) and the call flows (although one
additional one has been added) still do need more work, but again, I'd like
agreement on the syntax before adding too much more. 

One area that perhaps require further consideration is whether the Index
should be mandatory since we are now only capturing the Targeted-to-URI, it
won't be possible to really interpret a series of captured Request URIs
without an Index.  Right now, the inclusion of an Index is a SHOULD, with
the caveat that if there is no History-Info in a request received by a
Proxy, that it adds an entry based upon the received Request before it
retargets.  For this scenario, an INDEX MUST not be added because there's no
way to know what it should be AND the lack of an index highlights a missing
entry, which might be useful to an end application.  

Please do review and provide feedback.

Regards,
Mary H. Barnes
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 12, 2003 8:20 AM
Subject: I-D ACTION:draft-barnes-sipping-history-info-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: An Extension to the Session Initiation Protocol 
			  for Request History Information
	Author(s)	: M. Barnes, M. Watson
	Filename	: draft-barnes-sipping-history-info-02.txt
	Pages		: 20
	Date		: 2003-2-11
	
This draft defines a standard mechanism for capturing the history 
information associated with a SIP request.  This capability enables 
many enhanced services by providing the information as to how and 
why a call arrives at a specific application or user.  This draft 
defines a new optional SIP header, History-Info, for capturing the 
history information in requests. A new option tag, HistInfo, to be 
included in the Supported header is defined to allow UAs to 
indicate whether the HistInfo should be returned in responses to a 
request which has captured the history information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-sipping-history-info-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-barnes-sipping-history-info-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-barnes-sipping-history-info-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Wed, 12 Feb 2003 09:25:18 -0600