Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-01.txt

From: [email-masked]
Date: Thu, 08 Feb 2007 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
	Author(s)	: F. Audet
	Filename	: draft-ietf-sip-sips-01.txt
	Pages		: 48
	Date		: 2007-2-8
	
This document providing clarifications and guidelines concerning the
   use of SIPS URI scheme in the Session Initiation Protocol (SIP).  It
   does not make normative changes to SIP.  This document also provides
   discussion of possible future steps in specification, and the pros
   and cons of making such changes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-01.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-ietf-sip-sips-01.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-ietf-sip-sips-01.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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 9 Feb 2007 16:42:37 -0600

I want to draw attention to the up-issue of the sips draft.
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-01.txt

Here is a summary of the main changes changes:

- More clarification on using TLS with SIP instead of SIPS. Added a call
  flow 9.3 to illustrate it.

- In -00, if an endpoint registed with a SIP Contact or a SIPS Contact,
the proxy
  would forward incoming request to that UAS using the scheme of the
contact
  as opposed to preserve the scheme used in the request. In other words,
it
  "upgraded" or "downgraded" the scheme based on what was used in
Registration in
  the Contact. That introduced a whole bunch of issues with mid-dialog
requests. For
  example, if an Endpoint registered with a SIPS contact, an incoming
request
  sent using a SIP Request-URI would be upgraded to SIPS by the
terminating proxy.
  Upon accepting the request, the UAS would then have to use a SIPS
contact (as per
  RFC 3261) which would most likely not be understood by the
  other side, and would create problem with sending mid-dialog requests
such
  as ACK. In -01, the proxy is expected to leave the Request-URI scheme
intact when
  delivering the request. This will fix the problem described above.
Also, it
  correctly indicates to the UAS that the request was NOT sent using
SIPS on every
  hop. Please review carefully this change, and the implications on the 
  call flows in section 9 to ensure that it is correct. This change
fixes
  lots of problems with -00.

- When a request is rejected, a 403 Forbidden is used instead of 416
"Unrecognized
  URI scheme". The rationale is that RFC 3261 says that when you get a
416, you
  should retry with SIP URI scheme which would then loop. If anybody
believes a
  different error response should be used, please speak up.

- I cleaned up the description of loose routing implications of sips.
The -00 draft
  was saying that SIPS meant TLS for loose routes, but the -01 explains
that it really
  means, well, SIPS.

- Corrected a bunch of mistakes in the call flows.

The To-be-done section contains a bunch of open issues.

- One open issue regards how to deal with SIP URIs in REFER and 3rd
party call
  control. I'm not convinced that writing very detailed procedures makes
much sense 
  as it could get overly complicated. Somehow, I think we need some
high-level 
  statement about not allowing "derived connections" (such as one
obtained when
  REFER or 3rd-party call control) to effectively downgrade from SIPS to
SIP.
  Anyboy has any toughts on the issue?

- The other open issue is about GRUU.  How should the UAC react if the
returned 
  GRUU is SIP but	the To was SIPS? How should the UAC react if the
returned 
  GRUU is SIPS but the To was SIP? Any ideas? (Maybe we can be a bit
more
  prescriptive here).

A detailed diff can be found at:
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.
org/id/draft-ietf-sip-sips-00.txt&url2=http://tools.ietf.org/id/draft-ie
tf-sip-sips-01.txt