Francois, "If a UAS receives a request with the sips option-tag in a Supported or Require header field and it accepts the registration, it MUST include the sips option-tag in Supported or Require header in a 200 (OK) response." A UAS should not receive a REGISTER request - only a registrar should receive such a request.
"it MUST include the sips option-tag in Supported or Require header in a 200 (OK) response." What is the meaning of a Require header field in a response? "If a UAC sent a request with a sips option-tag in a Supported header, and the 200 (OK) did not include a sips option-tag in a Require or Supported header," Same comment. John > -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: 16 April 2007 23:27 > To: [email protected] > Subject: [Sip] draft-ietf-sip-sips-03.txt > > Hi all, > > I have submitted draft-ietf-sip-sips-03. > > I have integrated all the agreements of the Prague meeting. Including > the change to Standards Track draft, and the RFC 2119 wording changes, > as well as the restructure of the document with Normative requirements > for UA and Proxy separated. Also the deprecation of the last hop > exception. > > I also have attempted to capture the suggestions for improvements > and consensus from the mailing list. > > There are two remaining issues that I have documented in Annex C. > > Those 2 issues are what we need to focus on: > > 1. Do we deprecate the "last hop retarget upgrade exception"? The > document currently assumes that it IS deprecated, as > this is the > preference of the author. > > 2. Do we need the sips option tag? The current document > assumes that > we do use the option tag, and that is the preference of the > author. > (There is at least one dissenting voice on that one: Hisham). > > Please comment on those two open issues, and use a proper Subject for > the > topic. > > If you have other comments, please use appropriate Subject fields to > make > the thread easier to follow. > > Please also not repeat topics that have been beaten to death already. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 16, 2007 12:50 > > To: [EMAIL PROTECTED] > > Cc: [email protected] > > Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-03.txt > > > > 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 : The use of the SIPS URI Scheme in the > > Session Initiation Protocol (SIP) > > Author(s) : F. Audet > > Filename : draft-ietf-sip-sips-03.txt > > Pages : 54 > > Date : 2007-4-16 > > > > This document provides clarifications and guidelines concerning the > > use of SIPS URI scheme in the Session Initiation Protocol > > (SIP). It > > also makes normative changes to SIP. This document also > provides a > > discussion of possible future steps in specification. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt > > > > To remove yourself from the I-D Announcement list, send a > > message to [EMAIL PROTECTED] 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-03.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 PROTECTED] > > In the body type: > > "FILE /internet-drafts/draft-ietf-sip-sips-03.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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
