Subject: [Sipping] Reason Header and draft-koshiko-sipping-reason-indicating-locatio ns-00.txt

From: "Mary Barnes" <[email-masked]>
Date: Fri, 11 Feb 2005 11:12:46 -0500

Hi all, 

While the discussion of extensions to the Reason header still seems to be
ongoing, I thought it topical to introduce a brief discussion of the
draft-koshiko-sipping-reason-indicating-locations-00 (listed below), that
had been on my "to do" list since Dean had mentioned a while ago that he
thought it might have applicability to History-Info. First, before we get
GEOPRIV folks involved in this discussion, let me note that the use of
"location" in this draft is a bit of a misnomer, as it's not geographic
location, but rather the entity that originates a specific message that's
considered "location", so it's really more "source" than "location".  This
draft proposes an extension to the Reason header for that purpose.  

After reviewing the draft, I don't think the extension to Reason header is
the best way to achieve the desired functionality.  I think that the use of
History-Info (including the capturing of the Reason header) would provide
the necessary information that the client can use to derive the "source" of
a specific Response code or Request (e.g. CANCEL).   The draft clearly
states that the desired information is the "how and why a SIP messages
arrives at a specific application" and that's clearly the intent of
History-Info. Record-Route might also be useful in some of the scenarios.  

That all said, the extension to the Reason header that is proposed in the
draft-elwell-sipping-redirection-reason-01.txt might also be useful in the
context put forth in this draft in terms of providing additional information
for some of the interworking scenarios.  Here again, I think the Q.732
approach might be sufficient. 

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, November 12, 2004 2:06 PM
To: [email-masked]
Subject: I-D ACTION:draft-koshiko-sipping-reason-indicating-locations-00.txt

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

	Title		: Extending the Session Initiation Protocol Reason
Header for Indicating Locations
	Author(s)	: J. Koshiko
	Filename	:
draft-koshiko-sipping-reason-indicating-locations-00.txt
	Pages		: 14
	Date		: 2004-11-12
	
This document proposes an IANA Registration extension to the Session
   Initiation Protocol (SIP) Reason Header to indicate the location of 
   the SIP element which issued a certain SIP message. This capability
   enables many enhanced services by providing the information as to how
   and why a SIP message arrives at a specific application, user, or
   proxy server. This draft defines new reason-params for the protocol
   field of the Reason header field in RFC3326 [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-koshiko-sipping-reason-indicating-
locations-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-koshiko-sipping-reason-indicating-locations-00.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-koshiko-sipping-reason-indicating-locations-00.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.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP