Subject: RE: [Sip] Header name in draft-willis-sip-path-02.txt, was: I-D A CTION:draft-illis...

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 2 Apr 2002 13:25:57 +0100

I would prefer to keep Path, or at least something shorter that the
mouthfull that is currently proposed.

If you really must change it, then it should at least be hyphenated (twice)
for consistency with the other headers.

Note also that it no longer does the same as Record-Route, as Record-Route
is a bidirectional capability, and it was the same strong suggestions in
Minneapolis that precluded it having that one and same functionality.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Dean Willis[SMTP:[email-masked]]
> Sent: 	01 April 2002 17:43
> To: 	[email-masked]
> Subject: 	[Sip] Header name in draft-willis-sip-path-02.txt, was: I-D
> ACTION:draft-illis...
> 
> 
> Hi all,
> 
> Note that in Minneapolis (after some airing of this draft), I received
> several strong sugestions to change the proposed header name from "Path"
> to "RegisterRecordRoute, short form "RRR". This appears to be related to
> thefact that the main thing the draft does is define RecordRoute for
> REGISTER operations.
> 
> My current plan is to include this change along with any other nits in
> the next rev of the draft, and hopefully to proceed to WGLC from there
> in time to include this material in the "Bundle 3" IETF last call set.
> 
> So please get any comments in ASAP -- I'd like to edit the next rev next
> week.
> 
> --
> Dean
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]
> > Sent: Friday, March 29, 2002 6:03 AM
> > To: IETF-Announce:
> > Cc: [email-masked]
> > Subject: [Sip] I-D ACTION:draft-willis-sip-path-02.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > 
> > 
> > 	Title		: SIP Extension for Registering 
> > Non-Adjacent Contacts
> > 	Author(s)	: D. Willis
> > 	Filename	: draft-willis-sip-path-02.txt
> > 	Pages		: 10
> > 	Date		: 28-Mar-02
> > 	
> > The REGISTER function is used in a SIP system primarily to 
> > associate a temporary contact address with an 
> > address-of-record.  This contact is generally in the form of 
> > a URI, such as Contact: &ltsip:[email-masked]> and is 
> > generally dynamic and associated with the IP address or 
> > hostname of the SIP UA.  The problem is that network topology 
> > may be that there are one or more SIP proxies between the UA 
> > and the registrar, such that any message from the user's home 
> > network to the registered UA must traverse these proxies.  
> > The REGISTER method itself does not give us a mechanism to 
> > discover and record this sequence of proxies in the registrar 
> > for future use.  This document defines an extension header, 
> > 'Path' which provides such a mechanism.
> > 
> > A URL for this Internet-Draft is: 
> > http://www.ietf.org/internet-drafts/draft-willis-sip-path-02.t
> xt
> 
> 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-willis-sip-path-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-willis-sip-path-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.
> 
> 
> _______________________________________________
> 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://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: "Dean Willis" <[email-masked]>
Date: Tue, 2 Apr 2002 08:39:51 -0600

Keith said:

> I would prefer to keep Path, or at least something shorter 
> that the mouthfull that is currently proposed.

I suspect RRR would get used a lot . . .
 
> If you really must change it, then it should at least be 
> hyphenated (twice) for consistency with the other headers.

Register-Record-Route ?
 
> Note also that it no longer does the same as Record-Route, as 
> Record-Route is a bidirectional capability, and it was the 
> same strong suggestions in Minneapolis that precluded it 
> having that one and same functionality.

Actually, Record-Route entries are NOT changed in the response, just
copied back towards the source. That is, they accumulate on the INVITE
message, and are returned to the UA on the 200OK response. I think the
text in "path" now has exactly the same behaviour. If it doesn't, I did
something wrong, so please verify . . .

--
Dean

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 02 Apr 2002 11:45:15 -0500

> I suspect RRR would get used a lot . . .

It's a minor point of course, but I agree with Keith. Also, I suspect 
that for most implementations the decision of whether or not to use the 
short form is not made on a header by header basis, and so you're 
actually quite likely to see the long form most of the time.

Anders

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 2 Apr 2002 10:05:03 -0800

If this type of bandwidth matters to you, then you will compress and with
any half decent compression scheme the representation of the RRR token is
going to be the same no matter how long the uncompressed version is. Given
the length and design of SIP messages, it seems sort of futile to try and
optimize message size by any method other than compression at this point. I
don't care what we call it, but I don't think size matters.

Cullen

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Anders
> Kristensen
> Sent: Tuesday, April 02, 2002 8:45 AM
> To: Dean Willis
> Cc: 'Drage, Keith (Keith)'; [email-masked]
> Subject: Re: [Sip] Header name in draft-willis-sip-path-02.txt, was: I-D
> ACTION:draft-illis...
>
>
>
>
> Dean Willis wrote:
> >
> > Keith said:
> >
> >

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 02 Apr 2002 13:17:53 -0500

I would argue that on the contrary we know that size *does* matter. 
Compression is great but you can't assume it's available everywhere.

Anders