From daemon@optimus.ietf.org Wed May 1 01:30:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22439 for ; Wed, 1 May 2002 01:30:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28158 for sip-archive@odin.ietf.org; Wed, 1 May 2002 01:30:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19095; Wed, 1 May 2002 01:04:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19065 for ; Wed, 1 May 2002 01:04:13 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22099 for ; Wed, 1 May 2002 01:04:11 -0400 (EDT) Received: (qmail 13009 invoked from network); 1 May 2002 06:05:21 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.4) by nghmail with SMTP; 1 May 2002 06:05:21 -0000 Message-ID: <003201c1f0ce$362c80e0$5601a8c0@knowsys.net> From: "vishal" To: Cc: Date: Wed, 1 May 2002 10:38:08 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C1F0FC.48C0BC20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sip] capability exchange in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C1F0FC.48C0BC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , I have following questions=20 1. Does SIP provides capabiltiy to choose different codecs available at = endpoints =20 for call? 2. How can bandwidth be controlled by external entity for SIP based call = ?=20 regards, vishal ------=_NextPart_000_002F_01C1F0FC.48C0BC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ,
   I have following questions =
 
1. Does SIP provides capabiltiy to = choose different=20 codecs available at endpoints  
    for = call?
 
2. How can bandwidth be controlled by = external=20 entity for SIP based call ?
 
regards, vishal
 
 
 
 
 
------=_NextPart_000_002F_01C1F0FC.48C0BC20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 02:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15790 for ; Wed, 1 May 2002 02:47:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14682 for sip-archive@odin.ietf.org; Wed, 1 May 2002 02:47:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00237; Wed, 1 May 2002 02:13:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00208 for ; Wed, 1 May 2002 02:12:57 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01227 for ; Wed, 1 May 2002 02:12:54 -0400 (EDT) Received: (qmail 22301 invoked from network); 1 May 2002 07:14:03 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.4) by nghmail with SMTP; 1 May 2002 07:14:03 -0000 Message-ID: <005801c1f0d7$cf2aad40$5601a8c0@knowsys.net> From: "vishal" To: Date: Wed, 1 May 2002 11:46:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C1F105.E46F1460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sip] request/response over different transport Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C1F105.E46F1460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , It should be possible to receive request sent over UDP and send = response over TCP because in some cases when UDP message size is greater = than MTU size ,then message sending will not succeed . Reverse of this should not be allowed i.e receive over TCP and = send response over UDP . Possible scenario can be endpoint received query for cappability set = over UDP but response message is bigger than MTU size ... regards, vishal=20 =20 ------=_NextPart_000_0055_01C1F105.E46F1460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ,
      It = should be=20 possible to receive request sent over UDP and send response over TCP = because in=20 some cases when UDP message size is greater than MTU size ,then message = sending=20 will not succeed .
        Reverse=20 of this should not be allowed i.e receive over TCP and send = response over=20 UDP .
 
Possible scenario can be  endpoint = received  query for cappability set over UDP but response = message=20 is  bigger than MTU size ...
 
regards, vishal
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
       =20
 
------=_NextPart_000_0055_01C1F105.E46F1460-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 03:19:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01463 for ; Wed, 1 May 2002 03:19:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16071 for sip-archive@odin.ietf.org; Wed, 1 May 2002 03:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14849; Wed, 1 May 2002 02:53:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14818 for ; Wed, 1 May 2002 02:53:45 -0400 (EDT) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15877 for ; Wed, 1 May 2002 02:53:42 -0400 (EDT) Received: from obsoft.com (localhost.localdomain [127.0.0.1]) by obsoft.com (8.11.6/8.11.6) with ESMTP id g416wIt25999; Tue, 30 Apr 2002 23:58:18 -0700 Message-ID: <3CCF9209.50FDA3B1@obsoft.com> Date: Tue, 30 Apr 2002 23:58:17 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: vishal CC: sip@ietf.org Subject: Re: [Sip] request/response over different transport References: <005801c1f0d7$cf2aad40$5601a8c0@knowsys.net> Content-Type: multipart/alternative; boundary="------------EAA71B19208A54ED52F31A71" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------EAA71B19208A54ED52F31A71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The scenario you have described requires the UAS to decide whether to transport via TCP or UDP, depending on the request and the response. If the response size is less than path MTU then I am not sure why can't we use UDP for response. regards, Bobby Sardana. sardana@obsoft.com vishal wrote: > Hi , It should be possible to receive request sent over UDP and > send response over TCP because in some cases when UDP message size is > greater than MTU size ,then message sending will not succeed . > Reverse of this should not be allowed i.e receive over TCP and send > response over UDP . Possible scenario can be endpoint received query > for cappability set over UDP but response message is bigger than MTU > size ... > regards, vishal --------------EAA71B19208A54ED52F31A71 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The scenario you have described requires the UAS to decide whether to transport via TCP or UDP, depending on the request and the response. If the response size is less than path MTU then I am not sure why can't we use UDP for response.

regards,

Bobby Sardana.
sardana@obsoft.com

vishal wrote:

Hi ,      It should be possible to receive request sent over UDP and send response over TCP because in some cases when UDP message size is greater than MTU size ,then message sending will not succeed .        Reverse of this should not be allowed i.e receive over TCP and send response over UDP . Possible scenario can be  endpoint received  query for cappability set over UDP but response message is  bigger than MTU size ...
  regards, vishal                 
--------------EAA71B19208A54ED52F31A71-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 03:57:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04483 for ; Wed, 1 May 2002 03:57:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17740 for sip-archive@odin.ietf.org; Wed, 1 May 2002 03:57:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16523; Wed, 1 May 2002 03:30:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16465 for ; Wed, 1 May 2002 03:30:14 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02432 for ; Wed, 1 May 2002 03:30:11 -0400 (EDT) Received: (qmail 1397 invoked from network); 1 May 2002 08:31:22 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.4) by nghmail with SMTP; 1 May 2002 08:31:22 -0000 Message-ID: <009c01c1f0e2$9c0912c0$5601a8c0@knowsys.net> From: "vishal" To: "Bobby Sardana" Cc: References: <005801c1f0d7$cf2aad40$5601a8c0@knowsys.net> <3CCF9209.50FDA3B1@obsoft.com> Subject: Re: [Sip] request/response over different transport Date: Wed, 1 May 2002 13:04:14 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C1F110.B1C2F800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C1F110.B1C2F800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bobby, you are correct if message size is less than MTU size then = response must be over UDP ..... some other problems are : when proxy forwards INVITE requests .It adds "Via:" field into it along = with appropriate parametres ....if message is forwarded by many proxies = then this message may become greater than MTU size in particular network = ....how this case should be handled ?=20 should next proxy establish TCP connection and then forward it OR = reject this message? If proxy forwards this message using TCP and UAS receives INVITE over = TCP then UAS response will be sent over TCP and UAC should be prepared = to receive response over TCP or UDP for its previous INVITE over UDP = request. regards, vishal Vishal , Knowledge Systems Pvt Ltd ,INDIA 470, East End Main Road =20 9th Block Jayanagar=20 Bangalore =20 ----- Original Message -----=20 From: Bobby Sardana=20 To: vishal=20 Cc: sip@ietf.org=20 Sent: Wednesday, May 01, 2002 12:28 PM Subject: Re: [Sip] request/response over different transport The scenario you have described requires the UAS to decide whether to = transport via TCP or UDP, depending on the request and the response. If = the response size is less than path MTU then I am not sure why can't we = use UDP for response.=20 regards,=20 Bobby Sardana.=20 sardana@obsoft.com=20 vishal wrote:=20 Hi , It should be possible to receive request sent over UDP and = send response over TCP because in some cases when UDP message size is = greater than MTU size ,then message sending will not succeed . = Reverse of this should not be allowed i.e receive over TCP and send = response over UDP . Possible scenario can be endpoint received query = for cappability set over UDP but response message is bigger than MTU = size ...=20 regards, vishal =20 ------=_NextPart_000_0099_01C1F110.B1C2F800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bobby,
      you = are correct=20 if message size is less than MTU size then response must be = over UDP=20 .....
 
some other problems are :
 
 when proxy forwards INVITE = requests .It adds=20 "Via:" field into it along with appropriate parametres ....if = message is=20 forwarded by many proxies then this message may become greater than MTU = size in=20 particular network ....how this  case should be handled ? =
    should next proxy = establish TCP=20 connection and then forward it OR reject this message?
 
If proxy forwards this message using = TCP and UAS=20 receives INVITE over TCP then UAS response will be sent over TCP  = and UAC=20 should be prepared to receive response over TCP or UDP  for its = previous=20 INVITE over UDP request.
 
regards, vishal
 
Vishal ,
Knowledge = Systems Pvt=20 Ltd  ,INDIA
470, East End Main Road 
9th Block = Jayanagar=20
Bangalore
      =
----- Original Message -----
From:=20 Bobby = Sardana=20
To: vishal
Sent: Wednesday, May 01, 2002 = 12:28=20 PM
Subject: Re: [Sip] = request/response over=20 different transport

The scenario you have described requires the UAS to = decide=20 whether to transport via TCP or UDP, depending on the request and the=20 response. If the response size is less than path MTU then I am not = sure why=20 can't we use UDP for response.=20

regards,=20

Bobby Sardana.
sardana@obsoft.com=20

vishal wrote:=20

Hi ,      It should be possible to = receive=20 request sent over UDP and send response over TCP because in some = cases when=20 UDP message size is greater than MTU size ,then message sending will = not=20 succeed .        Reverse of this = should=20 not be allowed i.e receive over TCP and send response over UDP=20 . Possible = scenario can=20 be  endpoint received  query for cappability set over UDP = but=20 response message is  bigger than MTU size ... =
  regards,=20 = vishal         = ;        
------=_NextPart_000_0099_01C1F110.B1C2F800-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 07:46:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22238 for ; Wed, 1 May 2002 07:46:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA02644 for sip-archive@odin.ietf.org; Wed, 1 May 2002 07:46:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24891; Wed, 1 May 2002 07:26:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24689 for ; Wed, 1 May 2002 07:25:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20103; Wed, 1 May 2002 07:25:40 -0400 (EDT) Message-Id: <200205011125.HAA20103@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 01 May 2002 07:25:39 -0400 Subject: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private SIP Extension for Original Dialog Identifier Author(s) : E. Henrikson Filename : draft-henrikson-sip-original-dialog-id-00.txt Pages : 7 Date : 30-Apr-02 This document proposes a private SIP extension header used in conjunction with INVITE requests to provide a mechanism by which a stateful proxy may associate an INVITE request processed earlier with the INVITE request that is being currently processed. The association is needed by the Serving Call Session Control Function (S-CSCF) from the Third Generation Partnership Project (3GPP) architecture to ensure proper routing of an INVITE request with 3GPP Application Servers (AS). A S-CSCF may route an INVITE request to multiple AS, as indicated by a subscriber profile, and each AS may be a B2BUA. The S-CSCF needs to keep track of each AS contacted and know that an incoming INVITE request is related to a previous outgoing INVITE request such that each AS may receive the INVITE request before it is sent on towards the intended destination. When a B2BUA AS is involved, there is currently not a way to associate the incoming INVITE request with the previously sent INVITE request at the S-CSCF. The P-Original-Dialog-ID header provides a way to accomplish this association. The same mechanism may be applied to any SIP method that is used to initiate a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-00.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-henrikson-sip-original-dialog-id-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020430135712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-henrikson-sip-original-dialog-id-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020430135712.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 07:56:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23361 for ; Wed, 1 May 2002 07:56:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08625 for sip-archive@odin.ietf.org; Wed, 1 May 2002 07:56:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24701; Wed, 1 May 2002 07:25:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24587 for ; Wed, 1 May 2002 07:25:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20039; Wed, 1 May 2002 07:25:33 -0400 (EDT) Message-Id: <200205011125.HAA20039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 01 May 2002 07:25:33 -0400 Subject: [Sip] I-D ACTION:draft-henrikson-sip-charging-information-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private SIP Extension for Mobile Charging Information Author(s) : E. Henrikson Filename : draft-henrikson-sip-charging-information-00.txt Pages : 6 Date : 30-Apr-02 This document proposes a private SIP extension header P-Charging- Function-Addresses used to pass the addresses of entities that provide a charging function. There is a need in the Third Generation Partnership Project (3GPP) for entities that process charging information. For a particular dialog or standalone transaction, a proxy (or UA within the network, e.g. a gateway) may need to pass information to one or more charging entities. The affected UAs and proxies associated with the dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. This document also proposes a private SIP extension header P- Charging-Vector to pass correlation information for charging purposes. The network entities in the 3GPP architecture share correlation information to ensure that charging activities are coordinated. The need applies for any SIP method used to initiate a dialog, standalone messages and some response messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-information-00.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-henrikson-sip-charging-information-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-henrikson-sip-charging-information-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020430135701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-henrikson-sip-charging-information-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-henrikson-sip-charging-information-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020430135701.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 08:10:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23855 for ; Wed, 1 May 2002 08:10:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09578 for sip-archive@odin.ietf.org; Wed, 1 May 2002 08:10:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02444; Wed, 1 May 2002 07:45:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20195 for ; Wed, 1 May 2002 04:58:06 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09788 for ; Wed, 1 May 2002 04:58:04 -0400 (EDT) Received: from jku2.dynamicsoft.com (port-213-20-228-162.reverse.qdsl-home.de [213.20.228.162]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g418xaK00442; Wed, 1 May 2002 10:59:37 +0200 Message-Id: <5.1.0.14.0.20020501104513.0178da88@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 10:57:10 +0200 To: "Dean Willis" , "'chen Zhang'" , From: Jiri Kuthan Subject: RE: [Sip] SIP and MPLS In-Reply-To: <028101c1f091$10af90b0$1c2e713f@TXDWILLIS2> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There was a VoMPLS BoF in IETF 47th (adelaide), http://www.ietf.org/proceedings/00mar/47th-ietf-00mar-152.html#TopOfPage Its advocates had hard time to explain why shall we not have FTPoMPLS as well. There was little willingness to commit layer violation (e.a., teach apps L2). If whoever is interested in implementing foo-over-MPLS, I can wholeheartly recommend RFC3251, which provides an excellent template. -Jiri At 11:50 PM 4/30/2002, Dean Willis wrote: >I believe Jon Crowcroft and Mark Gibson suggested something like this at >IETF 46 and barely escaped afterwards. So it's definitely a possibility. >However, it didn't appear at the time that there was much interest in >pursuing it at the IETF. > >The slides from their presentation should be at: > >http://www.softarmor.com/sipwg/meets/ietf46/slides/pres-gibson-sip-qos-r >esv-sip-46.PDF > >And the related draft is probably still in the draft "morgue" on that >site. > >-- >Dean Willis > > >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On >> Behalf Of chen Zhang >> Sent: Tuesday, April 30, 2002 11:05 AM >> To: sip@ietf.org >> Subject: [Sip] SIP and MPLS >> >> >> Hi, >> SIP is an application layer protocol and origins as a large >> scale multiparty >> conferencing protocol. >> MPLS is an advanced forwarding scheme. >> >> Is it possible to join the SIP and MPLS? If it is, we can get >> following benefits: 1. using SIP to set up the LSP. 2. >> providing the higher quality in the Internet. >> >> IF you have any comments about that, Please let me know. >> >> Thank you for your attention >> >> Best regards >> >> Chen >> >> >> >> _________________________________________________________________ >> Send and receive Hotmail on your mobile device: http://mobile.msn.com >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current >> sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 10:07:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28534 for ; Wed, 1 May 2002 10:07:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16117 for sip-archive@odin.ietf.org; Wed, 1 May 2002 10:07:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14236; Wed, 1 May 2002 09:39:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14169 for ; Wed, 1 May 2002 09:38:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26940 for ; Wed, 1 May 2002 09:38:57 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g41Dc0d25867; Wed, 1 May 2002 08:38:00 -0500 From: "Dean Willis" To: Cc: , , , "'Allison Mankin'" , "Keith Drage" , "Henrikson, Eric H \(Eric\)" Date: Wed, 1 May 2002 08:37:37 -0500 Message-ID: <000001c1f115$5df30760$1c2e713f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200205011125.HAA20103@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The SIP working group has been asked to provide expert review of draft-henrikson-sip-original-dialog-id. This documents a P-header used in 3GPP to associate dialogs across a 3GPP application server acting as a back-to-back user agent. We'd like to complete expert review by May 10, 2002. Please copy your comments to the list and to Keith Drage and Eric Henrikson, who will coordinate responses and edit the draft apporpriately. Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 10:08:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28574 for ; Wed, 1 May 2002 10:08:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16145 for sip-archive@odin.ietf.org; Wed, 1 May 2002 10:08:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14206; Wed, 1 May 2002 09:39:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14161 for ; Wed, 1 May 2002 09:38:57 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26938 for ; Wed, 1 May 2002 09:38:54 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g41Dc3d25872; Wed, 1 May 2002 08:38:03 -0500 From: "Dean Willis" To: Cc: , "'Allison Mankin'" , , , "Keith Drage" , "Henrikson, Eric H \(Eric\)" Date: Wed, 1 May 2002 08:37:37 -0500 Message-ID: <000101c1f115$5eb9b2c0$1c2e713f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200205011125.HAA20039@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Expert Review: draft-henrikson-sip-charging-information-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The SIP Working Group has been requested to provide expert review of draft-henrikson-sip-charging-information. This draft documents P-headers used to interact with the accounting system in 3GPP. We'd like to complete review by May 10, 2002. http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-informa tion-00.txt Thanks! -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 11:46:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04415 for ; Wed, 1 May 2002 11:46:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22177 for sip-archive@odin.ietf.org; Wed, 1 May 2002 11:46:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16534; Wed, 1 May 2002 10:17:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15100 for ; Wed, 1 May 2002 09:57:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27828; Wed, 1 May 2002 09:57:18 -0400 (EDT) Message-Id: <200205011357.JAA27828@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 01 May 2002 09:57:18 -0400 Subject: [Sip] Last Call: The Session Initiation Protocol UPDATE Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider publication of the following two I-Ds as Proposed Standards: o The Session Initiation Protocol UPDATE Method o Integration of Resource Management and SIP The WG also asked the IESG to consider publication of the following two I-Ds as Informational RFCs: o HTTP Digest Authentication Using AKA o SIP Extensions for Media Authorization The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 15, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-update-02.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-07.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-04.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 12:08:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05672 for ; Wed, 1 May 2002 12:08:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23719 for sip-archive@odin.ietf.org; Wed, 1 May 2002 12:08:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20823; Wed, 1 May 2002 11:30:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20775 for ; Wed, 1 May 2002 11:30:26 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03250 for ; Wed, 1 May 2002 11:30:23 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g41FUH6v022801; Wed, 1 May 2002 08:30:18 -0700 (PDT) Received: from MAHENDRA.qualcomm.com (mahendra.qualcomm.com [129.46.75.104]) by magus.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g41FUGVl017349; Wed, 1 May 2002 08:30:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20020501082045.02932360@clea.qualcomm.com> X-Sender: mahendra@clea.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 08:30:15 -0700 To: sip@ietf.org From: AC Mahendran Subject: Re: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-00.txt Cc: ehenrikson@lucent.com In-Reply-To: <200205011125.HAA20103@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Eric: Comments... 1) In Section 5.4, Order of "Via" header is incorrect in transactions F2, F3, F5. Also, the branch values in these headers are not following the convention of 2543-bis. 2) In section 5.4 (in F2 & F3 transactions), the tag values in "P-Original-Dialog-ID" header don't match the definition of the header i.e the tags should be "od-from-tag", "od-to-tag", "od-call-id" instead of "tag". 3) In section 5.4, the text says the following: "This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P2 is an outbound proxy for UA1 which routes the request to an Application Server P2. " In the second line, the first occurrence of P2 should be replaced with P1. thanks, AC At 07:25 AM 5/1/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Private SIP Extension for Original Dialog > Identifier > Author(s) : E. Henrikson > Filename : draft-henrikson-sip-original-dialog-id-00.txt > Pages : 7 > Date : 30-Apr-02 > >This document proposes a private SIP extension header used in >conjunction with INVITE requests to provide a mechanism by which a >stateful proxy may associate an INVITE request processed earlier >with the INVITE request that is being currently processed. The >association is needed by the Serving Call Session Control Function >(S-CSCF) from the Third Generation Partnership Project (3GPP) >architecture to ensure proper routing of an INVITE request with >3GPP Application Servers (AS). A S-CSCF may route an INVITE request >to multiple AS, as indicated by a subscriber profile, and each AS >may be a B2BUA. The S-CSCF needs to keep track of each AS contacted >and know that an incoming INVITE request is related to a previous >outgoing INVITE request such that each AS may receive the INVITE >request before it is sent on towards the intended destination. When >a B2BUA AS is involved, there is currently not a way to associate >the incoming INVITE request with the previously sent INVITE request >at the S-CSCF. The P-Original-Dialog-ID header provides a way to >accomplish this association. The same mechanism may be applied to >any SIP method that is used to initiate a dialog. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-00.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-henrikson-sip-original-dialog-id-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: > mailserv@ietf.org. >In the body type: > "FILE > /internet-drafts/draft-henrikson-sip-original-dialog-id-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. >Content-Type: text/plain >Content-ID: <20020430135712.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 12:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08189 for ; Wed, 1 May 2002 12:52:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26652 for sip-archive@odin.ietf.org; Wed, 1 May 2002 12:53:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24422; Wed, 1 May 2002 12:22:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24381 for ; Wed, 1 May 2002 12:21:57 -0400 (EDT) Received: from odin.isw.intel.com (swfdns01.isw.intel.com [192.55.37.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06569 for ; Wed, 1 May 2002 12:21:54 -0400 (EDT) Received: from swsmsxvs01.isw.intel.com (swsmsxvs01.isw.intel.com [172.28.130.22]) by odin.isw.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.35 2002/04/27 00:24:14 root Exp $) with SMTP id g41GLPK08615 for ; Wed, 1 May 2002 16:21:25 GMT Received: from swsmsx17.isw.intel.com ([172.28.130.21]) by swsmsxvs01.isw.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050117183227791 ; Wed, 01 May 2002 17:18:32 +0100 Received: by swsmsx17.isw.intel.com with Internet Mail Service (5.5.2653.19) id <2645Q6CG>; Wed, 1 May 2002 17:24:33 +0100 Message-ID: <9985493A802AD5118C4E009027462753015CF89B@swsmsx34.isw.intel.com> From: "Finnie, Donald" To: "'sip@ietf.org'" Cc: "'dwillis@dynamicsoft.com'" , "'bernhard.honeisen@nokia.com'" Date: Wed, 1 May 2002 17:25:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Comments on draft-willis-sip-path-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Section 2. "Applicability Statement" seems to have some ambiguous wording in my opinion. 2.2 says "One or more of the intermediate proxies MUST be visited by messages between REGISTRAR and UA." The use of the words "between" and "messages" seem ambiguous. I assume this refers only to dialog-initiating messages sent *from* REGISTRAR *to* UA? If my understanding of the Path mechanism is correct, it does not effect INVITE messages, for example, sent from UA to some target via REGISTRAR/home service proxy. Nor does it imply Record-Routing at intermediate proxies so they will only remain in the signalling path if they choose to Record-Route. 2.2 says "The same set of proxies must be visited by messages between a home service proxy and UA. That is, the proxy route between the UA and its home service proxy is identical to the proxy route between the UA and its registrar." The Path mechanism only forces this situation for incoming messages arriving at the registrar/home service proxy destined to the UA. Correct? Regards Donald Finnie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 1 13:24:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09700 for ; Wed, 1 May 2002 13:24:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28683 for sip-archive@odin.ietf.org; Wed, 1 May 2002 13:24:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26944; Wed, 1 May 2002 12:56:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25986 for ; Wed, 1 May 2002 12:35:30 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07481 for ; Wed, 1 May 2002 12:35:28 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail1.firewall.lucent.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g41GYxG01374 for ; Wed, 1 May 2002 12:34:59 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 May 2002 11:34:59 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C023E9F38@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: "'AC Mahendran'" , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-00.tx t Date: Wed, 1 May 2002 11:34:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thank you for your comments AC. I will make the changes as you suggested. Eric -----Original Message----- From: AC Mahendran [mailto:mahendra@qualcomm.com] Sent: Wednesday, May 01, 2002 8:30 AM To: sip@ietf.org Cc: Henrikson, Eric H (Eric) Subject: Re: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-00.txt Eric: Comments... 1) In Section 5.4, Order of "Via" header is incorrect in transactions F2, F3, F5. Also, the branch values in these headers are not following the convention of 2543-bis. 2) In section 5.4 (in F2 & F3 transactions), the tag values in "P-Original-Dialog-ID" header don't match the definition of the header i.e the tags should be "od-from-tag", "od-to-tag", "od-call-id" instead of "tag". 3) In section 5.4, the text says the following: "This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P2 is an outbound proxy for UA1 which routes the request to an Application Server P2. " In the second line, the first occurrence of P2 should be replaced with P1. thanks, AC At 07:25 AM 5/1/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Private SIP Extension for Original Dialog > Identifier > Author(s) : E. Henrikson > Filename : draft-henrikson-sip-original-dialog-id-00.txt > Pages : 7 > Date : 30-Apr-02 > >This document proposes a private SIP extension header used in >conjunction with INVITE requests to provide a mechanism by which a >stateful proxy may associate an INVITE request processed earlier >with the INVITE request that is being currently processed. The >association is needed by the Serving Call Session Control Function >(S-CSCF) from the Third Generation Partnership Project (3GPP) >architecture to ensure proper routing of an INVITE request with >3GPP Application Servers (AS). A S-CSCF may route an INVITE request >to multiple AS, as indicated by a subscriber profile, and each AS >may be a B2BUA. The S-CSCF needs to keep track of each AS contacted >and know that an incoming INVITE request is related to a previous >outgoing INVITE request such that each AS may receive the INVITE >request before it is sent on towards the intended destination. When >a B2BUA AS is involved, there is currently not a way to associate >the incoming INVITE request with the previously sent INVITE request >at the S-CSCF. The P-Original-Dialog-ID header provides a way to >accomplish this association. The same mechanism may be applied to >any SIP method that is used to initiate a dialog. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id- 00.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-henrikson-sip-original-dialog-id-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: > mailserv@ietf.org. >In the body type: > "FILE > /internet-drafts/draft-henrikson-sip-original-dialog-id-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. >Content-Type: text/plain >Content-ID: <20020430135712.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 1 17:47:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07653 for ; Wed, 1 May 2002 17:47:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11611 for sip-archive@odin.ietf.org; Wed, 1 May 2002 17:47:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10052; Wed, 1 May 2002 17:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10024 for ; Wed, 1 May 2002 17:13:04 -0400 (EDT) Received: from broadsoft.com (broadsoft.com [198.104.184.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02584 for ; Wed, 1 May 2002 17:13:01 -0400 (EDT) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id g41LD3L08110; Wed, 1 May 2002 17:13:03 -0400 (EDT) Reply-To: From: "Brett Tate" To: Date: Wed, 1 May 2002 17:13:31 -0400 Message-ID: <000901c1f155$0c972230$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] refusing early media Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit What draft reflects the "accepted" working group solution for early media? There were various discussions and drafts attempting to resolve the forking issues related to two devices attempting to provide early media. I cannot recall or find which solution/message-flow was finally chosen. Thanks in advance. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 1 18:33:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12720 for ; Wed, 1 May 2002 18:33:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA13829 for sip-archive@odin.ietf.org; Wed, 1 May 2002 18:33:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12345; Wed, 1 May 2002 18:01:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12303 for ; Wed, 1 May 2002 18:00:55 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09454 for ; Wed, 1 May 2002 18:00:51 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g41M0Rx00401; Wed, 1 May 2002 17:00:27 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 17:00:23 -0500 Message-ID: From: "Sriram Parameswar" To: sip@ietf.org, "'rohan@cisco.com'" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-replaces-01.txt Date: Wed, 1 May 2002 17:00:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F15B.966BCE10" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F15B.966BCE10 Content-Type: text/plain; charset="iso-8859-1" Rohan, Some comments: (1)Section 4.1 says "In other words the to-tag is compared to the local tag, and the from-tag is compared to the remote tag." However in section 5.2 INV/200 estalish from-tag (operator) = 7743 and to-tag (Call Center) = 6472. However the call from the customer to Call Center has Replaces:425928@dhcp23311.acme.com;to-tag=7743;from-tag=6472, thus the Call Center will _not_ be able to match correctly based on sections 4.1 rule. (2) Section 5.2 the NOTIFY sent to from Customer to Operator when the Customer receives 182 (Queued). Then this transaction is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to Operator as shown - it will result in a 481. (3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he BYE's the call with Alice. Then at the bottom of call Flow, Alice tries to send a NOTIFY for the REFER, this will result in a 481. (3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to C2. (4) Section 5.6, just for grins, how does Alice get the Replaces information to replace the dialog between Bob and Old Timer :). Thats what I have from my initial reading. Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C1F15B.966BCE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] I-D ACTION:draft-ietf-sip-replaces-01.txt

Rohan,

Some comments:

(1)Section 4.1 says "In other words the to-tag = is compared to the local tag, and the from-tag is compared to the = remote tag." However in section 5.2 INV/200 estalish from-tag = (operator) =3D 7743 and to-tag (Call Center) =3D 6472. However the call = from the customer to Call Center has = Replaces:425928@dhcp23311.acme.com;to-tag=3D7743;from-tag=3D6472, thus = the Call Center will _not_ be able to match correctly based on sections = 4.1 rule.

(2) Section 5.2 the NOTIFY sent to from Customer to = Operator when the Customer receives 182 (Queued). Then this transaction = is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to = Operator as shown - it will result in a 481.

(3) Same for section 5.7 (and section 5.8) - once Bob = gets a 687, he BYE's the call with Alice. Then at the bottom of call = Flow, Alice tries to send a NOTIFY for the REFER, this will result in a = 481.

(3) Section 5.8 Invite from Proxy (forking Alice) = INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to = C2.

(4) Section 5.6, just for grins, how does Alice get = the Replaces information to replace the dialog between Bob and Old = Timer :).

Thats what I have from my initial reading.

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C1F15B.966BCE10-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 1 19:43:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21481 for ; Wed, 1 May 2002 19:43:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17075 for sip-archive@odin.ietf.org; Wed, 1 May 2002 19:43:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15600; Wed, 1 May 2002 19:14:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15557 for ; Wed, 1 May 2002 19:14:24 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18241 for ; Wed, 1 May 2002 19:14:20 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g41NDrp6029831; Wed, 1 May 2002 16:13:53 -0700 (PDT) Received: from dhcp-128-107-142-136.cisco.com (dhcp-128-107-142-136.cisco.com [128.107.142.136]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAC55618; Wed, 1 May 2002 16:13:52 -0700 (PDT) Date: Wed, 1 May 2002 16:10:41 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org, Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] interim agenda (redux) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org OK, Hopefully the last interim agenda I will send out, also available at: http://www.softarmor.com/sipwg/meets/interim-may-02/agenda2.html thanks, -rohan Rohan Mahy SIPPING co-chair -------------- SIP/SIPPING WG Agenda, Interim Meeting, May 6 and 7, 2002 Room S225 (2nd Floor of South Hall) Las Vegas Convention Center 3150 Paradise Road at Convention Center Drive Las Vegas, Nevada, USA -------------------------------------------------------------------------------- Monday, May 6 08:30 Welcome, Logistics, Agenda Bashing -- Rohan Mahy 09:00 Multiparty Apps Framework and Conferencing Requirements -- Dan Petrie or Orit Levin draft-ietf-sipping-cc-framework-00.txt draft-levin-sipping-conferencing-requirements-00.txt 10:30 REFER / Replaces / cc-transfer / service examples -- Robert Sparks, Rohan Mahy, Alan Johnston draft-ietf-sip-refer-02.txt draft-sparks-sip-refer-split-00.txt draft-sparks-sip-referredby-split-00.txt draft-sparks-sip-sec-options-00.txt draft-sparks-sip-mimetypes-03.txt draft-ietf-sip-replaces-01.txt draft-ietf-sip-cc-transfer-05.txt draft-ietf-sipping-service-examples-01.txt 13:00 Lunch 14:00 The call-info and conference-info packages -- Jonathan Rosenberg draft-rosenberg-sip-call-package-01.txt 15:30 Request History (Requirements) -- Mary Barnes and Mark Watson draft-watson-sipping-req-history-01.txt 16:15 URI as service indicator -- Eric Burger RFC 3087 - Service Context using SIP URIs 17:00 Binding Published data to SIP -- Ben Campbell very long mailing list thread 18:00 Wrap Tuesday, May 7 08:30 AAA requirements (Requirements) -- John Loughney and Gonzalo Camarillo draft-calhoun-sip-aaa-reqs-04.txt draft-loughney-sip-aaa-req-00.txt 10:30 Content Indirection draft-olson-sipping-content-indirect-00.txt 11:15 Key Events/ Stimulus Markup -- Jonathan Rosenberg draft-culpepper-sipping-app-interact-reqs-01.txt draft-rosenberg-sipping-markup-00.txt 12:00 Lunch 13:00 Privacy and Network Asserted Identity (Direction Forward) -- Cullen Jennings draft-watson-sipping-nai-reqs-00.txt draft-ietf-sip-privacy-04.txt draft-peterson-sip-privacy-longterm-00.txt draft-peterson-sip-identity-00.txt 16:30 Future Security Needs (Discussion) draft-ietf-sip-sec-agree-00.txt draft-undery-sip-auth-00.txt draft-thomas-sip-sec-req-00.txt 18:00 Wrap _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 1 20:16:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27059 for ; Wed, 1 May 2002 20:16:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA18687 for sip-archive@odin.ietf.org; Wed, 1 May 2002 20:16:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17397; Wed, 1 May 2002 19:51:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17367 for ; Wed, 1 May 2002 19:51:00 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22456 for ; Wed, 1 May 2002 19:50:56 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g41NpmLC011406; Wed, 1 May 2002 19:51:49 -0400 (EDT) Message-ID: <3CD07F3D.614E2687@dynamicsoft.com> Date: Wed, 01 May 2002 19:50:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vishal CC: Bobby Sardana , sip@ietf.org Subject: Re: [Sip] request/response over different transport References: <009c01c1f0e2$9c0912c0$5601a8c0@knowsys.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We thought about this problem a great deal for bis. The conclusion was that sending the response over a different transport was too complex and broke too many sip assumptions that exist throughout the spec. Instead, the spec mandates the use of TCP when you are within a few hundred bytes of the MTU. The few hundred byte headroom exists to handle the majority of the cases Record-Route will cause an increase in the response size. This doesn't guarantee that you won't get a response that exceeds the MTU, but it reduces its probability. more below. vishal wrote: > > Hi Bobby, > you are correct if message size is less than MTU size then > response must be over UDP ..... > > some other problems are : > > when proxy forwards INVITE requests .It adds "Via:" field into it along > with appropriate parametres ....if message is forwarded by many proxies > then this message may become greater than MTU size in particular network > ....how this case should be handled ? > should next proxy establish TCP connection and then forward it OR > reject this message? Establish a TCP connection. This is discussed in Section 18 of bis. > > If proxy forwards this message using TCP and UAS receives INVITE over > TCP then UAS response will be sent over TCP and UAC should be prepared > to receive response over TCP or UDP for its previous INVITE over UDP > request. UDP. There is a proxy that straddles UDP/TCP. It will receive the resposne over TCP, and forward it towards the UAC over UDP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 1 20:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29490 for ; Wed, 1 May 2002 20:30:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA18672 for sip-archive@odin.ietf.org; Wed, 1 May 2002 20:15:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17145; Wed, 1 May 2002 19:45:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17116 for ; Wed, 1 May 2002 19:45:21 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21738 for ; Wed, 1 May 2002 19:45:17 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g41NkBLC011402; Wed, 1 May 2002 19:46:12 -0400 (EDT) Message-ID: <3CD07DEC.59408507@dynamicsoft.com> Date: Wed, 01 May 2002 19:44:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] refusing early media References: <000901c1f155$0c972230$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brett Tate wrote: > > What draft reflects the "accepted" working > group solution for early media? There is no current document that explicitly addresses early media (and is current). The consensus was that the UNIFY proposal (draft-rosenberg-sip-unify) provided the framework we would move forward with. In that framework, the session state is totally decoupled from the dialog state. The offer/answer exchange affects session state, and those exchanges could be mapped into several sip message sequences. By mapping them into messages exchanged before the sip invite completes (inv/183) you get early media. Aspects of this were incorporated into bis, therefore allowing early media to be provided with bis + 100rel. However, bis+100rel alone is not sufficient, since you will need to modify aspects of the session before the call is answered (to handle forking, for example). That is the reason for the UPDATE draft (draft-ietf-sip-update) now in IETF last call. The UPDATE draft actually has a flow that shows early media. I do think it would be valuable to have some more early media specific call flows, as supported by bis and update. I am not sure we need a separate document on early media per se. Perhaps just some example call flows in the call flows or service examples doc would be sufficient. -Jonathan R. > > There were various discussions and drafts > attempting to resolve the forking issues > related to two devices attempting to provide > early media. I cannot recall or find which > solution/message-flow was finally chosen. > > Thanks in advance. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 00:59:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05357 for ; Thu, 2 May 2002 00:59:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA01048 for sip-archive@odin.ietf.org; Thu, 2 May 2002 00:59:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28912; Thu, 2 May 2002 00:15:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28846 for ; Thu, 2 May 2002 00:15:28 -0400 (EDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00707 for ; Thu, 2 May 2002 00:15:25 -0400 (EDT) Received: (qmail 25020 invoked from network); 2 May 2002 04:15:25 -0000 Received: from unknown (HELO dexceldesigns.com) (202.131.154.196) by relay1.pair.com with SMTP; 2 May 2002 04:15:25 -0000 X-pair-Authenticated: 202.131.154.196 Message-ID: <001401c1f0da$49ed26a0$0c010a64@DOMAIN> From: Muruganantham D To: , Date: Wed, 1 May 2002 12:04:46 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C1F108.63284360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Mailserver: Sent using PostMaster (v4.1.11) Subject: [Sip] Sip with Qsig Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1F108.63284360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! We are developing SIP application with QSIG Protocol, we are following = those thing s specified in RFC 3204.Plz go through the=20 below things and guide us in the right direction. =20 INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 Via: SIP/2.0/UDP sc10.nortelnetworks.com From: sip:14085655675@sc10.nortelnetworks.com To: sip:14084955072@sc1.nortelnetworks.com Call-ID: 1231999021712095500999@sc12.nortelnetworks.com CSeq: 1234 INVITE Contact: Content-Length: 358 Content-Type: multipart/mixed; boundary=3Dunique-boundary-1 MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=3DISO-10646 v=3D0 o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 s=3DSDP seminar c=3DIN IP4 MG141.nortelnetworks.com t=3D 2873397496 2873404696 m=3Daudio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/QSIG; version=3Diso 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 --unique-boundary-1-- How to proceed with these kind of messages? For 1xx no content just with sip messages, For 200 OKwith SDP part like = the above things, Is it correct or not? Thanks in advance, Regards, D.Murugananth *************************************************************************= ************************* Muruganantham.D., Dexcel Electronics Designs pvt Ltd., Airport road, = Bangalore-8 ------=_NextPart_000_0011_01C1F108.63284360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
 We are developing SIP application = with QSIG=20 Protocol, we are following those thing s specified in RFC 3204.Plz = go=20 through the
below things and guide us in the right=20 direction.
 

INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=3DISO-10646

v=3D0

o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=3DSDP seminar

c=3DIN IP4 MG141.nortelnetworks.com

t=3D 2873397496 2873404696

m=3Daudio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=3Diso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

How to proceed with these kind of=20 messages?
For 1xx no content just with sip = messages, For 200=20 OKwith SDP part like the above things, Is it correct or = not?
 
Thanks in advance,
Regards,
D.Murugananth
 
 
****************************************************************= **********************************
Muruganantham.D.,=20 Dexcel Electronics Designs pvt Ltd., Airport road,=20 Bangalore-8

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0011_01C1F108.63284360-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 00:59:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05429 for ; Thu, 2 May 2002 00:59:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA01062 for sip-archive@odin.ietf.org; Thu, 2 May 2002 00:59:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29064; Thu, 2 May 2002 00:15:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28869 for ; Thu, 2 May 2002 00:15:30 -0400 (EDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00724 for ; Thu, 2 May 2002 00:15:27 -0400 (EDT) Received: (qmail 25030 invoked from network); 2 May 2002 04:15:27 -0000 Received: from unknown (HELO dexceldesigns.com) (202.131.154.196) by relay1.pair.com with SMTP; 2 May 2002 04:15:27 -0000 X-pair-Authenticated: 202.131.154.196 Message-ID: <001401c1f0da$49ed26a0$0c010a64@DOMAIN> From: Muruganantham D To: , Date: Wed, 1 May 2002 12:04:46 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C1F108.63284360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Mailserver: Sent using PostMaster (v4.1.11) Subject: [Sip] Sip with Qsig Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1F108.63284360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! We are developing SIP application with QSIG Protocol, we are following = those thing s specified in RFC 3204.Plz go through the=20 below things and guide us in the right direction. =20 INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 Via: SIP/2.0/UDP sc10.nortelnetworks.com From: sip:14085655675@sc10.nortelnetworks.com To: sip:14084955072@sc1.nortelnetworks.com Call-ID: 1231999021712095500999@sc12.nortelnetworks.com CSeq: 1234 INVITE Contact: Content-Length: 358 Content-Type: multipart/mixed; boundary=3Dunique-boundary-1 MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=3DISO-10646 v=3D0 o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 s=3DSDP seminar c=3DIN IP4 MG141.nortelnetworks.com t=3D 2873397496 2873404696 m=3Daudio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/QSIG; version=3Diso 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 --unique-boundary-1-- How to proceed with these kind of messages? For 1xx no content just with sip messages, For 200 OKwith SDP part like = the above things, Is it correct or not? Thanks in advance, Regards, D.Murugananth *************************************************************************= ************************* Muruganantham.D., Dexcel Electronics Designs pvt Ltd., Airport road, = Bangalore-8 ------=_NextPart_000_0011_01C1F108.63284360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
 We are developing SIP application = with QSIG=20 Protocol, we are following those thing s specified in RFC 3204.Plz = go=20 through the
below things and guide us in the right=20 direction.
 

INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=3DISO-10646

v=3D0

o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=3DSDP seminar

c=3DIN IP4 MG141.nortelnetworks.com

t=3D 2873397496 2873404696

m=3Daudio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=3Diso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

How to proceed with these kind of=20 messages?
For 1xx no content just with sip = messages, For 200=20 OKwith SDP part like the above things, Is it correct or = not?
 
Thanks in advance,
Regards,
D.Murugananth
 
 
****************************************************************= **********************************
Muruganantham.D.,=20 Dexcel Electronics Designs pvt Ltd., Airport road,=20 Bangalore-8

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0011_01C1F108.63284360-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 01:04:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05883 for ; Thu, 2 May 2002 01:04:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA01632 for sip-archive@odin.ietf.org; Thu, 2 May 2002 01:04:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29015; Thu, 2 May 2002 00:15:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28851 for ; Thu, 2 May 2002 00:15:29 -0400 (EDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00717 for ; Thu, 2 May 2002 00:15:26 -0400 (EDT) Received: (qmail 25027 invoked from network); 2 May 2002 04:15:26 -0000 Received: from unknown (HELO dexceldesigns.com) (202.131.154.196) by relay1.pair.com with SMTP; 2 May 2002 04:15:26 -0000 X-pair-Authenticated: 202.131.154.196 Message-ID: <001401c1f0da$49ed26a0$0c010a64@DOMAIN> From: Muruganantham D To: , Date: Wed, 1 May 2002 12:04:46 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C1F108.63284360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Mailserver: Sent using PostMaster (v4.1.11) Subject: [Sip] Sip with Qsig Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1F108.63284360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! We are developing SIP application with QSIG Protocol, we are following = those thing s specified in RFC 3204.Plz go through the=20 below things and guide us in the right direction. =20 INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 Via: SIP/2.0/UDP sc10.nortelnetworks.com From: sip:14085655675@sc10.nortelnetworks.com To: sip:14084955072@sc1.nortelnetworks.com Call-ID: 1231999021712095500999@sc12.nortelnetworks.com CSeq: 1234 INVITE Contact: Content-Length: 358 Content-Type: multipart/mixed; boundary=3Dunique-boundary-1 MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=3DISO-10646 v=3D0 o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 s=3DSDP seminar c=3DIN IP4 MG141.nortelnetworks.com t=3D 2873397496 2873404696 m=3Daudio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/QSIG; version=3Diso 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 --unique-boundary-1-- How to proceed with these kind of messages? For 1xx no content just with sip messages, For 200 OKwith SDP part like = the above things, Is it correct or not? Thanks in advance, Regards, D.Murugananth *************************************************************************= ************************* Muruganantham.D., Dexcel Electronics Designs pvt Ltd., Airport road, = Bangalore-8 ------=_NextPart_000_0011_01C1F108.63284360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
 We are developing SIP application = with QSIG=20 Protocol, we are following those thing s specified in RFC 3204.Plz = go=20 through the
below things and guide us in the right=20 direction.
 

INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=3DISO-10646

v=3D0

o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=3DSDP seminar

c=3DIN IP4 MG141.nortelnetworks.com

t=3D 2873397496 2873404696

m=3Daudio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=3Diso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

How to proceed with these kind of=20 messages?
For 1xx no content just with sip = messages, For 200=20 OKwith SDP part like the above things, Is it correct or = not?
 
Thanks in advance,
Regards,
D.Murugananth
 
 
****************************************************************= **********************************
Muruganantham.D.,=20 Dexcel Electronics Designs pvt Ltd., Airport road,=20 Bangalore-8

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0011_01C1F108.63284360-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 2 05:09:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03039 for ; Thu, 2 May 2002 05:09:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21337 for sip-archive@odin.ietf.org; Thu, 2 May 2002 05:09:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18979; Thu, 2 May 2002 04:30:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18867 for ; Thu, 2 May 2002 04:29:58 -0400 (EDT) Received: from gw-nl3.philips.com (gw-nl3.philips.com [212.153.190.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01243; Thu, 2 May 2002 04:29:55 -0400 (EDT) From: frank.derks@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id 9AFB43B255; Thu, 2 May 2002 10:29:26 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA13093; Thu, 2 May 2002 10:29:26 +0200 (MET DST) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA04200; Thu, 2 May 2002 10:29:25 +0200 (MET DST) To: Muruganantham D Cc: sip@ietf.org, sipping@ietf.org, sipping-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 2 May 2002 10:27:56 +0200 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 02/05/2002 10:30:24, Serialize complete at 02/05/2002 10:30:24 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 002EA137C1256BAD_=" Subject: [Sip] Re: [Sipping] Sip with Qsig Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 002EA137C1256BAD_= Content-Type: text/plain; charset="us-ascii" Check out the following: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between SIP and QSIG Author(s) : J. Elwell Filename : draft-elwell-sipping-qsig2sip-00.txt Pages : 43 Date : 25-Apr-02 This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate networks. SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit- switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.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-elwell-sipping-qsig2sip-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-elwell-sipping-qsig2sip-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.txt --=_alternative 002EA137C1256BAD_= Content-Type: text/html; charset="us-ascii"
Check out the following:

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


                Title                                  : Interworking between SIP and QSIG
                Author(s)                 : J. Elwell
                Filename                 : draft-elwell-sipping-qsig2sip-00.txt
                Pages                                  : 43
                Date                                  : 25-Apr-02
               
This document specifies interworking between the Session Initiation
Protocol (SIP) and QSIG within corporate networks. SIP is an Internet
application-layer control (signalling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include, in particular, telephone calls. QSIG is a
signalling protocol for creating, modifying and terminating circuit-
switched calls, in particular telephone calls, within Private
Integrated Services Networks (PISNs). QSIG is specified in a number
of ECMA Standards and published also as ISO/IEC standards.
As the support of telephony within corporate networks evolves from
circuit-switched technology to Internet technology, the two
technologies will co-exist in many networks for a period, perhaps
several years. Therefore there is a need to be able to establish,
modify and terminate sessions involving a participant in the SIP
network and a participant in the QSIG network. Such calls are
supported by gateways that perform interworking between SIP and QSIG.
This document is a product of the authors' activities in ECMA
(www.ecma.ch) on interoperability of QSIG with IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.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-elwell-sipping-qsig2sip-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:
                mailserv@ietf.org.
In the body type:
                "FILE /internet-drafts/draft-elwell-sipping-qsig2sip-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.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.txt

 --=_alternative 002EA137C1256BAD_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 2 06:36:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09442 for ; Thu, 2 May 2002 06:36:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26225 for sip-archive@odin.ietf.org; Thu, 2 May 2002 06:36:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24439; Thu, 2 May 2002 06:05:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24382 for ; Thu, 2 May 2002 06:05:35 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06441; Thu, 2 May 2002 06:05:31 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g42A5V0E006430; Thu, 2 May 2002 12:05:31 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g42A5Ukw028902; Thu, 2 May 2002 13:05:30 +0300 (EET DST) Message-ID: <3CD10F64.D62B1E78@lmf.ericsson.se> Date: Thu, 02 May 2002 13:05:24 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip , rohc References: <3CC7D4B6.4480B8AA@lmf.ericsson.se> <3CC80CEA.7341993D@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, thanks for the comments. Answers inline: Jonathan Rosenberg wrote: > * Section 3 leaves out an important means for obtaining the URI - > configuration. I actually listed confirguation in the second set of bullets. The ones that deal with URIs without comp=sigcomp. However, in another of your comments you propose to get rid of that list. I will remove the second list and add "configuration" as a bullet here. > * I think a client MUST NOT send a sigcomp request to a server if it > doesn't know whether it supports compression. Section 3 provides cases > in which you can sort of guess whether it does. I don't like that. The > guesses are just that - guesses, and may be wrong. Yes, I agree. I will turn the SHOULD NOT into a MUST NOT and remove these bullets. > * I think its worth noting a few things about this approach. First, a > proxy that gets a request uncompressed, and wants to get it compressed > in subsequent requests, can return a 301 with a contact header that has > the comp parameter. This will result in a caching of the binding in the > client that sent the request. Yes. I believe this is already covered with the bullet below: \item The URI was obtained from a \header{Contact} header field in a 3xx or 485 response to the request. > Secondly, a SIP element that implements > this will need to be prepared to receive compressed or uncompressed > messages on the same port, and thus will need to look at the cookie in > the topmost bits to demux. Yes, this is the basic idea behind this approach. I have added the following text: "A SIP element that supports compression will need to be prepared to receive compressed and uncompressed messages on the same port. It will perform demultiplexing based on the cookie in the topmost bits of every compressed message." > > > A response is sent to the host in the sent-by parameter of the Via > > header field. If the topmost Via header field contains the parameter > > comp=sigcomp, the response SHOULD be compressed. Otherwise, the > > response SHOULD NOT be compressed. > > I would say MUST NOT be compressed. The criteria is - will things work > if you violate this? If I send a compressed response to something which > doesn't support it, the response is discarded. The result is total > failure of the transaction. There is no recovrey. So, it should be MUST > NOT. OK, it will be a MUST NOT. > > A proxy performing Record-Route inspects the Record-Route and the > > Contact header fields in the response. It looks for the URI of the > > next upstream (closer to the user agent client) hop in the route set. > > If this URI contains the parameter comp=sigcomp, the proxy SHOULD add > > comp=sigcomp to its entry in the Record-Route header field. > > Why? If the upstream element doesn't support this extension, the sigcomp > parameter is ignored, and the message is sent uncompressed. Thats what > you want. The decision about whether to insert a URI with the comp > parameter should be entirely a local one. This covers the following scenario: UAC----P1-----P2-----UAS The UAC sends an INITE to UAS. P2 records route, but P1 does not. When the 200 OK for the INVITE reaches P2, the contact and RR header fields will look like this: Contact: UAS@domain.com;comp=sigcomp RR: P2 If P2 does not add comp=sigcomp to his entry in the RR, UAC will be able to receive compressed traffic (the contact has comp=sigcomp), but will be unable to send compress traffic (the RR entry for P2 does not have it). Making P2 add comp=sigcomp resolves this asymmetry Thanks for the comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 2 07:32:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13651 for ; Thu, 2 May 2002 07:32:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29343 for sip-archive@odin.ietf.org; Thu, 2 May 2002 07:32:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26938; Thu, 2 May 2002 06:58:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26906 for ; Thu, 2 May 2002 06:58:53 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11066 for ; Thu, 2 May 2002 06:58:49 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g42Awm0E003774; Thu, 2 May 2002 12:58:48 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g42Awlkw002845; Thu, 2 May 2002 13:58:47 +0300 (EET DST) Message-ID: <3CD11BE0.36D305A7@lmf.ericsson.se> Date: Thu, 02 May 2002 13:58:40 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: sip@ietf.org Subject: Re: [Sip] Quick WGLC, Reason draft References: <019801c1edd5$d541f0d0$1101a8c0@TXDWILLIS2> <3CCD57A9.6070706@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijay, Thanks for the comments. Answers inline: > Non-nits comments > ----------------- > 1) The I-D says that: > "Initially, the Reason header field defined here appears to be > most useful for BYE and CANCEL requests, but it can appear in > any request" > > I seem to recall on the list that the Reason header field was limited > to requests within a dialog only. Is this restriction no longer > applicable. Yes, it is still applicable. the paragraph now reads as follows: "Initially, the \header{Reason} header field defined here appears to be most useful for {\BYE} and {\CANCEL} requests, but it can appear in any request within a dialog, in any {\CANCEL} request and in 155 (Update Requested) responses." > 2) If I am not mistaken, the ABNF restricts the Reason field to appear > only once. Since it can appear multiple times in a SIP message (and > be separable by commas), we should change the ABNF to reflect this. Yes, I had already received this comment. the BNF now reads: Reason & = & "Reason" HCOLON reason-value *(COMMA reason-value)\\ reason-value & = & protocol *(SEMI reason-params)\\ protocol & = & SIP $/$ Q.850 $/$ token\\ [...] > > Nits comments > ------------- > 1) The ABNF of Reason sets the Protocol field to: > Protocol = SIP / Q.850 / token > but the paragraph under the ABNF states that the value "SIP/2.0" has > been defined for a SIP status code. This was a copy/paste error. Now it is fixed: SIP is used (rather than SIP/2.0). > 2) The following paragraph appears run-on: > "When an INVITE is rejected, not because the call is declined, > but because some aspect of the request was not acceptable, if > the INVITE was forked, the error response is not forwarded > towards the UAC by the forking proxy. This problem is known > as..." > Suggested modifications: > "An INVITE can sometimes be rejected not because the session > initiation was declined, but becuause some aspect of the request > was not acceptable; for instance, if the INVITE forked and > resulted in a rejection, which may never be forwarded to the > client unless all the other branches also reject the request. > This problem is known as ..." Now it reads as follows: "An INVITE can sometimes be rejected not because the session initiation was declined, but because some aspect of the request was not acceptable. If the INVITE forked and resulted in a rejection, the error response may never be forwarded to the client unless all the other branches also reject the request. This problem is known... " > > 3) The four examples in Section 2 correspond roughly to the examples > of section 3. Maybe they should be repeated (or presented for > the first time) in the relevant sub-sections of Section 3. I believe it is alright as it is. It is good to provide examples about the syntax right after the BNF. The rest of the examples are just call flows that illustrate a bunch of possible scenarios. Thanks for your comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 2 08:49:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20107 for ; Thu, 2 May 2002 08:49:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03800 for sip-archive@odin.ietf.org; Thu, 2 May 2002 08:49:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01824; Thu, 2 May 2002 08:18:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01740 for ; Thu, 2 May 2002 08:18:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17263; Thu, 2 May 2002 08:18:16 -0400 (EDT) Message-Id: <200205021218.IAA17263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 02 May 2002 08:18:16 -0400 Subject: [Sip] I-D ACTION:draft-loughney-sip-aaa-req-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP-AAA Requirements Author(s) : J. Loughney, G. Camarillo Filename : draft-loughney-sip-aaa-req-00.txt Pages : 8 Date : 01-May-02 As SIP services are deployed on the Internet, there is a need for authentication, authorization and accounting of SIP sessions. This document sets out the basic requirements for this work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-loughney-sip-aaa-req-00.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-loughney-sip-aaa-req-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-loughney-sip-aaa-req-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-loughney-sip-aaa-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-loughney-sip-aaa-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141411.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 2 08:49:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20125 for ; Thu, 2 May 2002 08:49:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03814 for sip-archive@odin.ietf.org; Thu, 2 May 2002 08:49:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01927; Thu, 2 May 2002 08:18:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01879 for ; Thu, 2 May 2002 08:18:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17399; Thu, 2 May 2002 08:18:43 -0400 (EDT) Message-Id: <200205021218.IAA17399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 02 May 2002 08:18:43 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-update-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 Session Initiation Protocol UPDATE Method Author(s) : J. Rosenberg Filename : draft-ietf-sip-update-02.txt Pages : 12 Date : 01-May-02 This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but can be sent before the initial INVITE has completed. This makes it very useful for updating session parameters within early dialogs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-update-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-ietf-sip-update-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-update-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141502.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 17:54:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12071 for ; Thu, 2 May 2002 17:54:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11368 for sip-archive@odin.ietf.org; Thu, 2 May 2002 17:54:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10254; Thu, 2 May 2002 17:33:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10173 for ; Thu, 2 May 2002 17:33:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10485; Thu, 2 May 2002 17:33:29 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23018; Thu, 2 May 2002 17:32:59 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27098; Thu, 2 May 2002 17:33:01 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 May 2002 17:33:00 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B528B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" , "'sipping@ietf.org'" Date: Thu, 2 May 2002 17:32:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] SIP/SIPPING Mail list service may be briefly interrupted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org They tell me that an upgrade of the software that runs the list is going to get upgraded. The current ETA is Tuesday, May 7 from 1 to 3. Expect a "brief" interruption of service around that time. Hopefully, brief will be measured in hours, not days :) Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 18:50:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17097 for ; Thu, 2 May 2002 18:50:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14553 for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:50:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13869; Thu, 2 May 2002 18:33:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13799 for ; Thu, 2 May 2002 18:33:03 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16747 for ; Thu, 2 May 2002 18:32:59 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW7d04861; Thu, 2 May 2002 17:32:07 -0500 From: "Dean Willis" To: Cc: "'Rohan Mahy'" , , , "'Allison Mankin'" Date: Thu, 2 May 2002 17:31:41 -0500 Message-ID: <00ae01c1f229$21b70cf0$1e036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for Replaces header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request Working Group Last Call for the Replaces header. The current vesion is availabe at: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-01.txt Or http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-01.txt We'd like to clos WGLC by about May 21. Please copy responses to the list and to Rohan Mahy, who will coordinate further edits. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 18:58:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18505 for ; Thu, 2 May 2002 18:58:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14830 for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:58:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13944; Thu, 2 May 2002 18:33:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13854 for ; Thu, 2 May 2002 18:33:08 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16752 for ; Thu, 2 May 2002 18:33:02 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW8d04869; Thu, 2 May 2002 17:32:08 -0500 From: "Dean Willis" To: Cc: "'Rohan Mahy'" , "'Allison Mankin'" , , , Date: Thu, 2 May 2002 17:31:41 -0500 Message-ID: <00b101c1f229$22ae8c50$1e036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for Refer Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request Working Group Last Call for the REFER method. The current version is availabe as: http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-split-00.tx t Or http://search.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.t xt We need to close this by app May 21, so get your comments in. Please copy the list AND Rober tSparks, who will consolidate responses. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 18:58:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18548 for ; Thu, 2 May 2002 18:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14859 for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:58:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13832; Thu, 2 May 2002 18:33:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13790 for ; Thu, 2 May 2002 18:33:02 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16745 for ; Thu, 2 May 2002 18:32:58 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW7d04866; Thu, 2 May 2002 17:32:07 -0500 From: "Dean Willis" To: Cc: "'Allison Mankin'" , "'Rohan Mahy'" , "'Brian Rosen'" , , "BECKMANN MARK" Date: Thu, 2 May 2002 17:31:41 -0500 Message-ID: <00b001c1f229$222fbf60$1e036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Expert Review of draft-beckmann-sip-event Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The SIP Working Group has been requested to provide Expert Review of an events package for registration state. The current version is available at: http://www.softarmor.com/sipwg/drafts/draft-beckmann-sip-reg-event-00.tx t Or http://search.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-00.t xt Please copy responses to the list and to Mark Beckmann, who will coordinate needed edits. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 18:58:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18531 for ; Thu, 2 May 2002 18:58:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14845 for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:58:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13910; Thu, 2 May 2002 18:33:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13831 for ; Thu, 2 May 2002 18:33:06 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16751 for ; Thu, 2 May 2002 18:33:01 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW7d04860; Thu, 2 May 2002 17:32:07 -0500 From: "Dean Willis" To: Cc: "'Rohan Mahy'" , , "'Allison Mankin'" , , Date: Thu, 2 May 2002 17:31:41 -0500 Message-ID: <00af01c1f229$21c1bb50$1e036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC SIP MME Types Registration Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request WGLC of the SIP MIME type registration draft. The current version can be found at: http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt Or http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt We'd like to close WGLC by about May 21. Please copy comments to the list and to Robert Sparks, who will coordinate further efforts. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 2 22:07:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22074 for ; Thu, 2 May 2002 22:07:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA23069 for sip-archive@odin.ietf.org; Thu, 2 May 2002 22:07:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22140; Thu, 2 May 2002 21:49:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22109 for ; Thu, 2 May 2002 21:49:23 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21893 for ; Thu, 2 May 2002 21:49:17 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g431mld05926; Thu, 2 May 2002 20:48:47 -0500 Message-ID: <005101c1f244$a928dd10$133fed0c@C1893415A> From: "Dean Willis" To: Cc: "Rohan Mahy" , , , , "Henning Schulzrinne" Date: Thu, 2 May 2002 20:48:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC draft-ietf>-sip-dhcpv6 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request a working group last call on the DHCP for SIP with IPv6. The current version of the draft is available at: http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt or http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-dhcpv6-00.txt We should try and conclude this by about May 22. There should be a concurrent last call in the DHC working group. Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 3 01:30:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26552 for ; Fri, 3 May 2002 01:30:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10234 for sip-archive@odin.ietf.org; Fri, 3 May 2002 01:30:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08528; Fri, 3 May 2002 01:12:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08446 for ; Fri, 3 May 2002 01:12:35 -0400 (EDT) Received: from mailnpd.hcltech.com ([203.197.145.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26383 for ; Fri, 3 May 2002 01:12:20 -0400 (EDT) Received: from kowsalyapc (kowsalya-pc.hcltech.com [192.168.100.111]) by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id g434uQ905388; Fri, 3 May 2002 10:26:28 +0530 Message-ID: <16ee01c1f260$d51a0900$6f64a8c0@hcltech.com> From: "Kowsalya Subramanian" To: "Jonathan Rosenberg" , References: <3CCF3672.7211E6EF@dynamicsoft.com> Subject: Re: [Sip] update to UPDATE Date: Fri, 3 May 2002 10:40:21 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, > The changes: > > * excised 155, herfp, reason stuff I understand that now UPDATE can only be used to update session parameters. But If the "155 - Update Requested" contains reason-code as one of 401, 416, 420, 423,how will that be handled? Thanks Kowsalya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 3 08:00:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10521 for ; Fri, 3 May 2002 08:00:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01031 for sip-archive@odin.ietf.org; Fri, 3 May 2002 08:00:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28969; Fri, 3 May 2002 07:28:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28938 for ; Fri, 3 May 2002 07:28:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09650; Fri, 3 May 2002 07:28:29 -0400 (EDT) Message-Id: <200205031128.HAA09650@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 May 2002 07:28:29 -0400 Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Access Network Info header Author(s) : D. Mills Filename : draft-mills-sip-access-network-info-01.txt Pages : 5 Date : 02-May-02 This document defines the private SIP extension header P-Access-Network-Info. This mechanism is useful in SIP networks that are partitioned, such as 3G wireless networks which are partitioned at the SIP layer into 'access' and 'home' networks. SIP User Agents may use this header to relay information about the access network to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-01.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-mills-sip-access-network-info-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mills-sip-access-network-info-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020502131627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mills-sip-access-network-info-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mills-sip-access-network-info-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502131627.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 3 08:06:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10639 for ; Fri, 3 May 2002 08:06:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01473 for sip-archive@odin.ietf.org; Fri, 3 May 2002 08:06:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28880; Fri, 3 May 2002 07:27:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28796 for ; Fri, 3 May 2002 07:27:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09494; Fri, 3 May 2002 07:27:47 -0400 (EDT) Message-Id: <200205031127.HAA09494@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 May 2002 07:27:47 -0400 Subject: [Sip] I-D ACTION:draft-jennings-sipping-nai-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks Author(s) : C. Jennings Filename : draft-jennings-sipping-nai-00.txt Pages : 14 Date : 02-May-02 This document describes extensions to SIP that enable a network of trusted SIP servers to assert the identity of end users or end systems, and to convey indications of end-user requested privacy. The use of these extensions are only applicable inside an administrative domain, or among federations of administrative domains with previously agreed-upon policies for usage of such information. This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-sipping-nai-00.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-jennings-sipping-nai-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jennings-sipping-nai-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020502130900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jennings-sipping-nai-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jennings-sipping-nai-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502130900.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 3 14:47:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24180 for ; Fri, 3 May 2002 14:47:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25137 for sip-archive@odin.ietf.org; Fri, 3 May 2002 14:47:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23918; Fri, 3 May 2002 14:16:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23876 for ; Fri, 3 May 2002 14:16:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23086; Fri, 3 May 2002 14:16:15 -0400 (EDT) Message-Id: <200205031816.OAA23086@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 03 May 2002 14:16:15 -0400 Subject: [Sip] Last Call: Security Mechanism Agreement for SIP Sessions to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider Security Mechanism Agreement for SIP Sessions as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 4 04:34:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20669 for ; Sat, 4 May 2002 04:34:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09453 for sip-archive@odin.ietf.org; Sat, 4 May 2002 04:34:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08469; Sat, 4 May 2002 04:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08436 for ; Sat, 4 May 2002 04:15:20 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20427 for ; Sat, 4 May 2002 04:15:15 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g448FI0E015277; Sat, 4 May 2002 10:15:18 +0200 (MEST) Received: from ericsson.com (ppp26.lmf.ericsson.se [131.160.102.26]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g448F9kw011197; Sat, 4 May 2002 11:15:16 +0300 (EET DST) Message-ID: <3CD392C7.2E718D6@ericsson.com> Date: Sat, 04 May 2002 10:50:31 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: "'Rohan Mahy'" CC: sip@ietf.org References: <00ae01c1f229$21b70cf0$1e036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Syntax in Replaces Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I've been taking a look at the Replaces-01, and I have a question regarding the formal syntax. The syntax is defined as: Replaces = "Replaces" HCOLON replaces-values *(COMMA replaces-values) replaces-values = callid *( SEMI replaces-param ) callid = token [ "@" token ] replaces-param = to-tag | from-tag | extension-param to-tag = "to-tag" EQUAL ( UUID | "*" ) from-tag = "from-tag" EQUAL UUID extension-param = token [ EQUAL ( token | quoted-string ) ] The question is where is defined the "UUID" that appears in the to-tag and the from-tag??? I didn't find it in either RFC 2234 nor in RFC 3261? I guess they should be replaces by a "token". On the other hand, you seem to re-define "callid", which is already defined in RFC 3261. For some reason this I-D does not see RFC 3261 when expanding the ABNF, so I would suggest the following text: 3.2 Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [4] and the Augemented BNF extensions defined in section 25 of RFC 3261 [1]. Replaces = "Replaces" HCOLON replaces-values *(COMMA replaces-values) replaces-values = callid *( SEMI replaces-param ) replaces-param = to-tag | from-tag | extension-param to-tag = "to-tag" EQUAL ( token| "*" ) from-tag = "from-tag" EQUAL token extension-param = token [ EQUAL ( token | quoted-string ) ] As you can see, there is not definition of callid (it is in RFC 3261) and the to-tag and from-tag are now tokens. /Miguel Dean Willis wrote: > > I'd like to request Working Group Last Call for the Replaces header. > > The current vesion is availabe at: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-01.txt > > Or > > http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-01.txt > > We'd like to clos WGLC by about May 21. > > Please copy responses to the list and to Rohan Mahy, who will coordinate > further edits. > > -- > Dean Willis > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 4 04:35:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20702 for ; Sat, 4 May 2002 04:35:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09469 for sip-archive@odin.ietf.org; Sat, 4 May 2002 04:35:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08507; Sat, 4 May 2002 04:15:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08478 for ; Sat, 4 May 2002 04:15:54 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20430 for ; Sat, 4 May 2002 04:15:49 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g448Fos7006659; Sat, 4 May 2002 10:15:50 +0200 (MEST) Received: from ericsson.com (ppp26.lmf.ericsson.se [131.160.102.26]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g448FQkw011206; Sat, 4 May 2002 11:15:32 +0300 (EET DST) Message-ID: <3CD39546.EDE95A68@ericsson.com> Date: Sat, 04 May 2002 11:01:10 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org, Rohan Mahy , ehenrikson@LUCENT.COM, Keith Drage Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Dialog-ID and Replaces reconciliation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric, Rohan: The SIP Replaces header and the P-Original-Dialog-ID header seem to have some common parts. For instance, both define mechanisms to transport the to-tag and the from-tag in the header value. I was wondering if it would be possible to re-use as much as possible from the other. For instance, Replaces defines "to-tag" and "from-tag", whereas P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think it would be much better if P-Original-Dialog-ID defines "to-tag" and "from-tag". The "original-dialog" meaning is implicitely carried in the header name and syntax. This would allow easier definition of the SIP dictionary used in compression, because we don't need different entries in the dictionary. It would also allow to reuse as much as possible the software code in an implementation. On the other hand, Replaces seems to lack a "call-id=" string. P-Original-Dialog-ID has it, and it is certainly needed. Is there a way to synchronize these two?? I hope you can take my comments onboard. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 5 10:37:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19325 for ; Sun, 5 May 2002 10:37:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19041 for sip-archive@odin.ietf.org; Sun, 5 May 2002 10:37:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18127; Sun, 5 May 2002 10:04:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18097 for ; Sun, 5 May 2002 10:04:29 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18629 for ; Sun, 5 May 2002 10:04:24 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g45E3wp6005837; Sun, 5 May 2002 07:03:58 -0700 (PDT) Received: from OranLT ([161.44.238.38]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACV45792; Sun, 5 May 2002 07:04:10 -0700 (PDT) From: "David R. Oran" To: "'Drage, Keith \(Keith\)'" , "'Mark Watson'" , "'Dean Willis'" , "'William Marshall'" , Subject: RE: [Sip] z9hG4bK forever ??? Date: Sun, 5 May 2002 10:03:02 -0400 Organization: Cisco Systems Message-ID: <017c01c1f43d$9319f9a0$0100a8c0@OranLT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439E994@en0033exch001u.uk.lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A light bulb went on... > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Drage, Keith (Keith) > Sent: Monday, April 29, 2002 5:26 AM > To: 'Mark Watson'; 'Dean Willis'; 'William Marshall'; 'sip@ietf.org' > Subject: RE: [Sip] z9hG4bK forever ??? > > > The special arragement option depends on how the network > operator deals with providing it. > > If the network operator gives it to all and everyone, then it > is as you say. Essentially as the From field. This requires > no further consideration. > > When it was specified however, one major use was identified > as being from enterprise networks, in fact they were the main > proponents of such a usage. If one follows the private > network ISDN signalling specifications (ISO PSS1 and ECMA > QSIG) then enterprise delivered values are screened in the > enterprise network, thus as far as the enterprise network is > concerned, they are regarded as network asserted rather than > as user asserted. The only reason for the special arrangement > coding (user provided unscreened) in this case is that the > public network operators wanted a distinction between public > network asserted identities and private network asserted identities. > > So far the point is therefore that while enterprise networks > can and do assert identities, they may not be fully trusted. > In the ISDN, it is trusted sufficiently in order to deliver > the CLIP service to the remote user, but is not trusted > sufficiently for malicious call identification. If we are to > achieve 100% mapping to the ISDN/PSTN, then we may need to > reflect this distinction. > Yes, but the ISDN is missing what I believe is a crucial distinction - whether the NAI was asserted by you (the carrier looking at the SIP message), or another carrier. The tacit assumption is that the "pubic networks" comprise a single homogenous trust domain, and everything else is a "private network" and hence in a different trust domain. There is no capability for finer granularity nor control of transitivity. If we simply provide the ability to authenticate the source domain of the NAI, and to scrub NAI at any boundary between domains, we can duplicate, as well as improve on the ISDN functionality. If one maps to ISDN itself, there is clearly some loss of information, as there is with any mapping function, but this loss is no worse than connecting anything different to ISDN in the first place. > I certainly do not believe that we should treat the > unscreened coding in all cases as mapping to the From header, > as this will not give a 100% mapping in the reverse > direction. However, in the longer term, providing some values > indicating who provided the assertion may resolve this > problem. I do not believe anything less than a digitally signed authenticator is of much use in the world of IP. The attacks are mountable in just about any envrironment that is not encased in bulletproof walls. > In this case dummy values such as "non-public > network operator" could be used as the asserting identity > when such values are mapped. > I am more than a little nervous about introducing native identifiers to SIP which state nothing meaningful globally from a policy standpoint. I certainly trust a non-public network operator in the UK to preserve my privacy more than a pubic network in North Korea. Telling me that an identity was asserted by a "public network operator" without a digital signature proving which one it is, does me absolutely no good at all. I might as well ask for code points like "carrier not cited in last year's Amnesty International human rights report". > In the short term, as a large number of public network > operators do not allow the special arrangement to exist, it > may be best to ignore the special arrangement, or at least > the finer details of the mapping. > > Keith > > > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: 18 April 2002 12:00 > To: 'Dean Willis'; William Marshall; sip@ietf.org > Subject: RE: [Sip] z9hG4bK forever ??? > > > > I think we're about at the end of this one. > > Two final points from me: > 1) Dean's desire to avoid having the From: field > mangled unless he has specifically requested it is > reasonable. I still think that the subscriber's wishes could > overrule this though. > > This is no different from the ISDN 'Special > Arrangement' where the user inserts any number they like in > the Calling Party Number field. The network passes it though > with no checking, changing, nothing - I think this is > analogous to what Dean wants for the From field. > > But the network still removes this information if the > subscriber wants anonymity. The stated purpose of the field > is user identity, which implies Personal Data of the > subscriber. This is enough to argue that the network must > remove it if privacy is required, and this is certainly the > application of current legislation to ISDN. > > What is the stated purpose of the From field - I do not > think it is sufficiently different for us to be _sure_ that > we can avoid the requirement. > > So, the munging may still be required, but I certainly > agree it should be avoided wherever possible. > > 2) In formal terms, 'B2BUA == NOT Proxy'. We all know > there will be/are devices which behave very much like a > proxy, but perform some additional functions, such as these > privacy services. This is fine. Everyone should be aware that > with only two terms defined 'B2BUA' and 'Proxy', such devices > fall into the B2BUA category. > > ...Mark > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 17 April 2002 17:36 > > To: William Marshall; sip@ietf.org > > Subject: Re: [Sip] z9hG4bK forever ??? > > > > > > Baill said: > > > All this discussion of proxy modification of the From and > > To headers, > > > and the need for a B2BUA, seems to me to be a short-term > > problem only. > > > > > > RFC3261 (2543bis-09) specifies matching of > dialog-ids based only > > > on Call-ID and tags, not on display-name or on > addr-spec. So > > > when all endpoints are compliant with RFC3261, > there will be no > > > problem with a proxy modifying the display-name or > addr-spec in > > > the From header. > > > > I disagree. I don't want the network mangling my > user-to-user headers > > unless I've specifically requested it to do so. > Specifically, the > > non-authenticated, non-mangled, non-protected From: field > > offers utility > > which is DIFFERENT than that provided by network > authenticated calling > > party ID, and I don't want to sacrifice that utility > just because this > > is a capability the widely-deployed PSTN (as opposed > to say Q.SIG) > > didn't have . . . > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 5 13:09:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21221 for ; Sun, 5 May 2002 13:09:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25024 for sip-archive@odin.ietf.org; Sun, 5 May 2002 13:09:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24196; Sun, 5 May 2002 12:49:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24160 for ; Sun, 5 May 2002 12:49:16 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21089 for ; Sun, 5 May 2002 12:49:09 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g45Gmjp6011498 for ; Sun, 5 May 2002 09:48:45 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACV46303; Sun, 5 May 2002 09:48:58 -0700 (PDT) From: "Cullen Jennings" To: Date: Sun, 5 May 2002 09:48:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Digest auth-int in bis9 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I interpret lines 4997-5001 in bis9 say that a bis 9 proxy must set the qop parameter in a challenge and a bis 9 compliant UA must also set them in the reply to the challenge. It is not clear if the proxy or UA must do auth or auth-int. The example shows the proxy being able to do both and the UA selecting just auth. I think we should make it clear what the preferred thing for a UA to do. The point I am getting to is, if the UA selects auth-int and sends it through a SIP ALG firewall/nat, odd are good that the SDP gets modified and when the proxy gets the message it will fail the auth-int check. I don't know if this is a feature or a bug but it seems worth explicitly discussing. When we want to protect bodies, I think there are much better approaches than Digest auth-int. My proposal is that User Agents are RECOMMENDED NOT to use auth-int and that Proxies MAY support auth-int but MUST support auth. Thoughts? Cullen PS. Is there any reason why RFC 2617 has auth quoted in WWW-Authenticate header but not quoted in a Authorization header? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 5 15:33:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22549 for ; Sun, 5 May 2002 15:33:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00138 for sip-archive@odin.ietf.org; Sun, 5 May 2002 15:33:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29277; Sun, 5 May 2002 15:13:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29248 for ; Sun, 5 May 2002 15:13:24 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22383 for ; Sun, 5 May 2002 15:13:18 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g45JDgn19371 for ; Sun, 5 May 2002 22:13:42 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 5 May 2002 22:13:21 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sun, 5 May 2002 22:13:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Digest auth-int in bis9 Date: Sun, 5 May 2002 22:13:21 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECF9@esebe013.NOE.Nokia.com> Thread-Topic: [Sip] Digest auth-int in bis9 Thread-Index: AcH0VOX82qNkS8yBQUu2oA2C0fQ/RgAEeRiw To: Cc: X-OriginalArrivalTime: 05 May 2002 19:13:21.0815 (UTC) FILETIME=[EC1C7A70:01C1F468] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA29249 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Cullen, > I interpret lines 4997-5001 in bis9 say that a bis 9 proxy > must set the qop > parameter in a challenge and a bis 9 compliant UA must also > set them in the > reply to the challenge. I assume that the reason for this is that bis-9 compatible proxies and UAs need not be RFC2069 compatible, which is why in RFC2617, the qop is optional. > It is not clear if the proxy or UA must do auth or auth-int. > The example > shows the proxy being able to do both and the UA selecting > just auth. I > think we should make it clear what the preferred thing for a UA to do. This depends on the application, so I don't think such an explicit preference exists. For example, to a REGISTER or MESSAGE, auth-int could make more sense than when proxy-authenticating an INVITE... > The point I am getting to is, if the UA selects auth-int and sends it > through a SIP ALG firewall/nat, odd are good that the SDP > gets modified and > when the proxy gets the message it will fail the auth-int > check. I don't > know if this is a feature or a bug but it seems worth > explicitly discussing. > When we want to protect bodies, I think there are much better > approaches > than Digest auth-int. Auth-int seems like a very easy and inexpensive way to protect bodies, and headers as well by using sip-frag. You are right that an ALG that modifies the SDP will fail the auth-int authentication. But it will also fail S/MIME or any other integrity protection on the body. > > My proposal is that User Agents are RECOMMENDED NOT to use > auth-int and that > Proxies MAY support auth-int but MUST support auth. > > Thoughts? I don't agree. Auth-int is useful in some authentication scenarios, just not when there is a firewall/NAT that modifies the message bodies. > PS. Is there any reason why RFC 2617 has auth quoted in > WWW-Authenticate > header but not quoted in a Authorization header? In WWW-Authenticate, its a comma separated list, whereas in Authorization it's a token. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 5 16:38:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23200 for ; Sun, 5 May 2002 16:38:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02083 for sip-archive@odin.ietf.org; Sun, 5 May 2002 16:38:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01224; Sun, 5 May 2002 16:12:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01193 for ; Sun, 5 May 2002 16:12:12 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23051 for ; Sun, 5 May 2002 16:12:06 -0400 (EDT) Received: from there (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.11.6/8.11.6) with SMTP id g45KBFn09583; Sun, 5 May 2002 15:11:16 -0500 Message-Id: <200205052011.g45KBFn09583@kevlar.softarmor.com> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: "Tan Ya-Ching ICM N PG U ID A 1" , "'Dean Willis'" , , "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR> Subject: Re: [Sip] Revised Path draft (-04) submitted Date: Sun, 5 May 2002 15:11:15 -0500 X-Mailer: KMail [version 1.3.2] Cc: , , "'Rohan Mahy'" , , References: <5B4D0C5BA65ECA46969C1419122317E6E74D80@mchh161e> In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E6E74D80@mchh161e> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 30 April 2002 04:19 am, Tan Ya-Ching ICM N PG U ID A 1 wrote: > Dean, > > Just nits: > > - The first line of Path in Table 3 should have a "o" under REG. Once again, I find these tables confusing. The bis draft says: "Optional" means that a UA MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). A "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request. A mandatory response header field MUST be present in the response, and the header field MUST be understood by the UAC processing the response. "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request. Similarly, a header field labeled "not applicable" for a response means that the UAS MUST NOT place the header field in the response, and the UAC MUST ignore the header field in the response. I think you're suggesting that the Table 2/3 entry for Path should have an O for the value representing its applicability in a registration request as generated by the UA. At least, that's what I think putting an O there means. I don't believe this is what we want. The UA MUST NOT insert a Path header in its registration request. Proxies may add one or append to one inserted by another proxy. So how do the rest of you read this table? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 5 16:38:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23217 for ; Sun, 5 May 2002 16:38:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02097 for sip-archive@odin.ietf.org; Sun, 5 May 2002 16:38:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01411; Sun, 5 May 2002 16:22:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01382 for ; Sun, 5 May 2002 16:22:32 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23100 for ; Sun, 5 May 2002 16:22:26 -0400 (EDT) Received: from there (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.11.6/8.11.6) with SMTP id g45KLwn09616; Sun, 5 May 2002 15:21:58 -0500 Message-Id: <200205052021.g45KLwn09616@kevlar.softarmor.com> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: "Finnie, Donald" , Date: Sun, 5 May 2002 15:21:57 -0500 X-Mailer: KMail [version 1.3.2] Cc: , References: <9985493A802AD5118C4E009027462753015CF89B@swsmsx34.isw.intel.com> In-Reply-To: <9985493A802AD5118C4E009027462753015CF89B@swsmsx34.isw.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Re: Comments on draft-willis-sip-path-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Wednesday 01 May 2002 11:25 am, Finnie, Donald wrote: > Section 2. "Applicability Statement" seems to have some ambiguous wording > in > my opinion. > > 2.2 says "One or more of the intermediate proxies MUST be visited by > messages between REGISTRAR and UA." > > The use of the words "between" and "messages" seem ambiguous. I assume > this > refers only to dialog-initiating messages sent *from* REGISTRAR *to* UA? > If > my understanding of the Path mechanism is correct, it does not effect > INVITE > messages, for example, sent from UA to some target via REGISTRAR/home > service proxy. Nor does it imply Record-Routing at intermediate proxies > so > they will only remain in the signalling path if they choose to > Record-Route. The applicability statement says messages because it means" all messages, not just dialog-inititaing messages and replies". SIP gives us mechanisms (Via and Record-Route) to force replies subsequent messages in a dialog to traverse the route of the original message. We also have a mechanism (the preloaded Route) which allows us to force an out-of-dialog request to visit certain nodes. What we don't have is a way to tell the UA what Route to pre-load (P-Service-Route) or a way to tell a retargeting proxy what Route to add in order to reach a Contact that once must reach through a specific route. Specifically, Path is applied to any SIP request (not just a dialog initiating message) originating at or traversing the retargetting proxy associated with the registrar. I'll see if I can clarify this slightly in the next revision. > > > 2.2 says "The same set of proxies must be visited by messages between a > home > service proxy and UA. That is, the proxy route between the UA and its > home service proxy is identical to the proxy route between the UA and its > registrar." > > The Path mechanism only forces this situation for incoming messages > arriving > at the registrar/home service proxy destined to the UA. Correct? Yes. Other techniques meet other requirements in the applicability statement. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 5 17:23:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23770 for ; Sun, 5 May 2002 17:23:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03963 for sip-archive@odin.ietf.org; Sun, 5 May 2002 17:23:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03736; Sun, 5 May 2002 17:07:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03705 for ; Sun, 5 May 2002 17:07:34 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23611 for ; Sun, 5 May 2002 17:07:27 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g45L72d01951; Sun, 5 May 2002 16:07:02 -0500 Message-ID: <002301c1f478$b385d570$133fed0c@C1893415A> From: "Dean Willis" To: Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , "Rohan Mahy" , , Date: Sun, 5 May 2002 16:06:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for draft-willis-sip-path-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request Working Group Last Call for draft-willis-sip-path. This will need to close by about 11May. Version -05 draft has been submitted to internet-drafts and shoudl be available. in the meantime use: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt or http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 6 03:04:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09072 for ; Mon, 6 May 2002 03:04:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA01493 for sip-archive@odin.ietf.org; Mon, 6 May 2002 03:04:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00302; Mon, 6 May 2002 02:35:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00266 for ; Mon, 6 May 2002 02:35:46 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08768 for ; Mon, 6 May 2002 02:35:39 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g466Za0E010396; Mon, 6 May 2002 08:35:37 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g466Za9q025210; Mon, 6 May 2002 09:35:36 +0300 (EET DST) Message-ID: <3CD62433.C1714CB@ericsson.com> Date: Mon, 06 May 2002 09:35:31 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Dean Willis CC: 3GPP_TSG_CN_WG1@LIST.ETSI.FR, sip@ietf.org, bernhard.honeisen@nokia.com References: <002301c1f478$b385d570$133fed0c@C1893415A> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: WGLC for draft-willis-sip-path-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean, Bernie: Some comments to the Path header, mostly NITS. 1) Regarding the tag option "Path" for the Supported header, as far as I have seen before, most of the other option tags are defined in lowercase. I would suggest to follow the same approach for consistency, that is, define "path". 2) The syntax defined at the end of section 3 does not allow the Path header to be part of the request, only to the response. I suspect this is an error. Suggestion: Header field where proxy ACK BYE CAN INV OPT REG PRA _______________________________________________________________ Path R ar - - - - - o - Path 2xx - - - - - - o - 3) The last sentence in section 4.1 reads: "The UA should include the option tag 'Path' in any Supported headers". I suspect this inclusion affects all the instances of Supported, including those in an INVITE. Can you confirm this? 4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be replaced by reference [2] (bis-09). 5) In section 4.7, the Via in the examples do not begin with "z9hG4bK" as required by bis-09. Thanks a lot, Miguel Dean Willis wrote: > > I'd like to request Working Group Last Call for draft-willis-sip-path. > This will need to close by about 11May. > > Version -05 draft has been submitted to internet-drafts and shoudl be > available. > > in the meantime use: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt > > or > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html > > -- > Dean -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 6 04:44:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09914 for ; Mon, 6 May 2002 04:44:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05499 for sip-archive@odin.ietf.org; Mon, 6 May 2002 04:44:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03713; Mon, 6 May 2002 04:03:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03682 for ; Mon, 6 May 2002 04:03:37 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09589 for ; Mon, 6 May 2002 04:03:31 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4684PLC014055; Mon, 6 May 2002 04:04:27 -0400 (EDT) Message-ID: <3CD638B2.77B305B7@dynamicsoft.com> Date: Mon, 06 May 2002 04:02:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kowsalya Subramanian CC: sip@ietf.org Subject: Re: [Sip] update to UPDATE References: <16ee01c1f260$d51a0900$6f64a8c0@hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Kowsalya Subramanian wrote: > > Jonathan, > > > The changes: > > > > * excised 155, herfp, reason stuff > > I understand that now UPDATE can only be used to update session > parameters. > But If the "155 - Update Requested" contains reason-code as one of 401, > 416, > 420, 423,how will that be handled? An extension will specify how to use UPDATE to handle this case. That extension will define the 155 response code as well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 6 04:45:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09948 for ; Mon, 6 May 2002 04:45:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05545 for sip-archive@odin.ietf.org; Mon, 6 May 2002 04:45:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03826; Mon, 6 May 2002 04:06:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03794 for ; Mon, 6 May 2002 04:06:26 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09596 for ; Mon, 6 May 2002 04:06:20 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 174dVb-00085s-00; Mon, 06 May 2002 11:06:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15574.14707.901024.844778@harjus.eng.song.fi> Date: Mon, 6 May 2002 11:06:11 +0300 To: "Dean Willis" Cc: , "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , "Rohan Mahy" , , Subject: [Sip] WGLC for draft-willis-sip-path-05 In-Reply-To: <002301c1f478$b385d570$133fed0c@C1893415A> References: <002301c1f478$b385d570$133fed0c@C1893415A> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit below are my comments: - i thought that it was agreed to use name rrr instead of path for this header. the reason is that this header is both semantically and syntactically very close to record-route. also, name path is not at all descriptive, what path? - this paragraph should be moved, since somebody's suggestions regarding things that are outside the scope of the i-d should not be part of the normative text: It has been suggested that the UA MAY choose to store the contents of the Path header for future use as a preloaded Route for use when the UA wishes to send a SIP message that, for reasons of acquiring services in the home network, need to transit the service proxies in the home network. Such usage is explicitly outside the scope of this document. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 6 07:50:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13726 for ; Mon, 6 May 2002 07:50:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13994 for sip-archive@odin.ietf.org; Mon, 6 May 2002 07:50:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12731; Mon, 6 May 2002 07:26:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12700 for ; Mon, 6 May 2002 07:26:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12977; Mon, 6 May 2002 07:25:55 -0400 (EDT) Message-Id: <200205061125.HAA12977@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 06 May 2002 07:25:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-call-auth-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP Extensions for Media Authorization Author(s) : W. Marshall, F. Andreasen, D. Evans Filename : draft-ietf-sip-call-auth-05.txt Pages : 13 Date : 03-May-02 This document describes the need for QoS and media authorization and defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-05.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-ietf-sip-call-auth-05.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-call-auth-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020503122105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-auth-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-auth-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020503122105.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 11:56:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24536 for ; Mon, 6 May 2002 11:56:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00314 for sip-archive@odin.ietf.org; Mon, 6 May 2002 11:56:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28280; Mon, 6 May 2002 11:21:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28249 for ; Mon, 6 May 2002 11:21:45 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23520 for ; Mon, 6 May 2002 11:21:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g46FLRs7024166; Mon, 6 May 2002 17:21:27 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g46FLQ9q000963; Mon, 6 May 2002 18:21:26 +0300 (EET DST) Message-ID: <3CD69F6F.A1F17163@ericsson.com> Date: Mon, 06 May 2002 18:21:19 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Dean Willis , sip@ietf.org, 3GPP_TSG_CN_WG1 <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, bernhard.honeisen@nokia.com, Rohan Mahy , brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] WGLC for draft-willis-sip-path-05 References: <002301c1f478$b385d570$133fed0c@C1893415A> <15574.14707.901024.844778@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha: I believe the name of the header should be related as much as possible to the semantics, not to the relation with other headers and how to build it. Therefore, having a name of a header "rrr" sounds to me like coding ISUP. I would prefer to keep the name Path as it is suggested in the draft. /Miguel jh@lohi.eng.song.fi wrote: > > below are my comments: > > - i thought that it was agreed to use name rrr instead of path for this > header. the reason is that this header is both semantically and > syntactically very close to record-route. also, name path is not at > all descriptive, what path? > > - this paragraph should be moved, since somebody's suggestions regarding > things that are outside the scope of the i-d should not be part of > the normative text: > > It has been suggested that the UA MAY choose to store the contents of > the Path header for future use as a preloaded Route for use when the > UA wishes to send a SIP message that, for reasons of acquiring > services in the home network, need to transit the service proxies in > the home network. Such usage is explicitly outside the scope of this > document. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 12:16:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25278 for ; Mon, 6 May 2002 12:16:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02753 for sip-archive@odin.ietf.org; Mon, 6 May 2002 12:16:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29871; Mon, 6 May 2002 11:46:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29840 for ; Mon, 6 May 2002 11:46:20 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24293 for ; Mon, 6 May 2002 11:46:13 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g46FjmL16519; Mon, 6 May 2002 11:45:48 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA13569; Mon, 6 May 2002 10:45:48 -0500 (CDT) Message-ID: <3CD6A51F.1020600@lucent.com> Date: Mon, 06 May 2002 10:45:35 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] WGLC for draft-willis-sip-path-05 References: <002301c1f478$b385d570$133fed0c@C1893415A> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > I'd like to request Working Group Last Call for draft-willis-sip-path. > This will need to close by about 11May. > > Version -05 draft has been submitted to internet-drafts and shoudl be > available. [...] Dean: New comments based on -05 I-D: Section 4.2, first paragraph: s/future transmissions/future transactions Old comments, persisting from -04 I-D: Section 1, "UA" still remains in the figure, although the succeeding text refers to "UA1". To remain consistent with later figures, change "UA" in Section 1 figure to "UA1". I also made a general comment in the last review round, which may have escaped your attention; I reproduce the comment here (full context can be found at http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04979.html) vkg> Generally speaking, in many places where you use "message", I vkg> believe you mean "requests". If so, can we substitute the vkg> term request, since a "message" may be a response, for vkg> instance, which will follow the Via paths. dean>Reasonable. vkg> In Section 4.6, the requests from P1->P2 show P1 adding vkg> itself to the Path list (initially set to null). The branch vkg> of P1 does NOT contain the "magic cookie" (z9hG4bK). vkg> Likewise for P3->REGISTRAR. Since P1 and P3 supports "lr", it vkg> is a good bet that they also support the Via "magic cookie". vkg> Of course, this is an obscure nit, but all the same... dean> Good point. It appears that you have added the magic cookie to in the UA1->P1 INVITE request, which is okay, since UA1 supports lr, so there- fore it also supports the new Via "magic cookie". But so do proxies P1 and P3; however, the Vias for P1 and P3 do not contain the magic cookie. Again, this is a pedantic nit, so I will leave it at your discretion on what to do. I resurrect this here based solely on your modification of the UA1->P1 INVITE request to add the magic cookie. That's all! Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 15:07:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03274 for ; Mon, 6 May 2002 15:07:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13515 for sip-archive@odin.ietf.org; Mon, 6 May 2002 15:07:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11726; Mon, 6 May 2002 14:37:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11689 for ; Mon, 6 May 2002 14:37:18 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02030 for ; Mon, 6 May 2002 14:37:10 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-213-20-128-170.reverse.qdsl-home.de [213.20.128.170]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g46Id7W05957 for ; Mon, 6 May 2002 20:39:07 +0200 Message-Id: <5.1.0.14.0.20020506145829.01fa7170@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 May 2002 15:00:50 +0200 To: sip@ietf.org From: Jiri Kuthan Subject: Interop Issue (was Fwd: [Sip] REGISTER Processing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org [Resent -- this was a bis-09 interop issue at the last sip-it and I am surprised not to have seen any reply on it from any of bis authors.] >There seems to be insufficient guidance in bis-09 on usage of Call-ID >in REGISTERs. The only thing which I found there is in 10.2.4: > > "A UA SHOULD use the same Call-ID for all registrations during a > single boot cycle. " > >I think that does NOT require Call-ID to change across reboots. UAs >with no memory are not explicitely mandated to change Call-ID (ignoring >that bis asks to deny REGISTERs with Call-ID== and CSeq <= values in registrar's >bindings). If the UACs actually do not change Call-ID, REGISTERs after reboots >with low CSeq will be ignored. > >Which actually happened during two tests in SIPIt. > >Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if >not doing so does not break things, which is not the case here. > >-- > >Other confusing thing is which SIP reply a request failure for out-of-order REGISTERs >in line 1740 implies. I could connect it to the next paragraph "....if binding >update fails...the request MUST fail with 500..." but I am not sure that 500 is >a good choice. > >-- > >Yet anothet thing, which Jan pointed out, is that handling of out-or-order >in lines 1738-40 also includes retransmissions (CSeq and CallID in request and >bindings equal). Sending some negative reply upstream would in that case >cause the upstream UAC to consider registration failed. > >-Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 15:26:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03643 for ; Mon, 6 May 2002 15:26:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14139 for sip-archive@odin.ietf.org; Mon, 6 May 2002 15:26:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12450; Mon, 6 May 2002 14:53:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12418 for ; Mon, 6 May 2002 14:52:58 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02790 for ; Mon, 6 May 2002 14:52:50 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g46Iptq05697; Mon, 6 May 2002 13:51:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 13:52:03 -0500 Message-ID: From: "Sriram Parameswar" To: "'Miguel A. Garcia'" , Dean Willis Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR, sip@ietf.org, bernhard.honeisen@nokia.com Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Mon, 6 May 2002 13:51:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F52F.191B1D80" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F52F.191B1D80 Content-Type: text/plain; charset="iso-8859-1" Dean, Bernie, One more recommendation: ** Since the draft adds an option tag "path". I would highly recommend that put "Supported:path,...." in all REGISTER's shown in the draft. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Monday, May 06, 2002 1:36 AM To: Dean Willis Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; bernhard.honeisen@nokia.com Subject: [Sip] Re: WGLC for draft-willis-sip-path-05 Dean, Bernie: Some comments to the Path header, mostly NITS. 1) Regarding the tag option "Path" for the Supported header, as far as I have seen before, most of the other option tags are defined in lowercase. I would suggest to follow the same approach for consistency, that is, define "path". 2) The syntax defined at the end of section 3 does not allow the Path header to be part of the request, only to the response. I suspect this is an error. Suggestion: Header field where proxy ACK BYE CAN INV OPT REG PRA _______________________________________________________________ Path R ar - - - - - o - Path 2xx - - - - - - o - 3) The last sentence in section 4.1 reads: "The UA should include the option tag 'Path' in any Supported headers". I suspect this inclusion affects all the instances of Supported, including those in an INVITE. Can you confirm this? 4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be replaced by reference [2] (bis-09). 5) In section 4.7, the Via in the examples do not begin with "z9hG4bK" as required by bis-09. Thanks a lot, Miguel Dean Willis wrote: > > I'd like to request Working Group Last Call for draft-willis-sip-path. > This will need to close by about 11May. > > Version -05 draft has been submitted to internet-drafts and shoudl be > available. > > in the meantime use: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt > > or > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html > > -- > Dean -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C1F52F.191B1D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Re: WGLC for draft-willis-sip-path-05

Dean, Bernie,

One more recommendation:

** Since the draft adds an option tag = "path". I would highly recommend that put = "Supported:path,...." in all REGISTER's shown in the = draft.

Thanks,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
Sent: Monday, May 06, 2002 1:36 AM
To: Dean Willis
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; = sip@ietf.org;
bernhard.honeisen@nokia.com
Subject: [Sip] Re: WGLC for = draft-willis-sip-path-05


Dean, Bernie:

Some comments to the Path header, mostly NITS.

1) Regarding the tag option "Path" for the = Supported header, as far as
   I have seen before, most of the other = option tags are defined in
   lowercase. I would suggest to follow = the same approach for consistency,
   that is, define = "path".

2) The syntax defined at the end of section 3 does = not allow the Path
   header to be part of the request, only = to the response. I suspect
   this is an error. Suggestion:

         = Header field          = where   proxy ACK BYE CAN INV OPT REG PRA
         = _______________________________________________________________
         = Path           &n= bsp;        = R       ar   -   = -   -   -   -   o   = -
         = Path           &n= bsp;       = 2xx       -   -   = -   -   -   -   o   = -

3) The last sentence in section 4.1 reads: "The = UA should include the
   option tag 'Path' in any Supported = headers". I suspect this inclusion
   affects all the instances of Supported, = including those in an INVITE.
   Can you confirm this?

4) Reference 1 (RFC 2543) and to "the = binding" (section 4.3) should be
   replaced by reference [2] = (bis-09).

5) In section 4.7, the Via in the examples do not = begin with "z9hG4bK"
   as required by bis-09.

Thanks a lot,

       Miguel


Dean Willis wrote:
>
> I'd like to request Working Group Last Call for = draft-willis-sip-path.
> This will need to close by about 11May.
>
> Version -05 draft has been submitted to = internet-drafts and shoudl be
> available.
>
> in the meantime use:
>
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip= -path-05.txt
>
> or
>
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip= -path-05.html
>
> --
> Dean

--
Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
          &nb= sp;           &nb= sp;           &nb= sp;     Jorvas, Finland
mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = Protocol
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sipping@ietf.org for new developments on the = application of sip

------_=_NextPart_001_01C1F52F.191B1D80-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 21:41:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13319 for ; Mon, 6 May 2002 21:41:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09076 for sip-archive@odin.ietf.org; Mon, 6 May 2002 21:41:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07611; Mon, 6 May 2002 21:20:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21483 for ; Sun, 5 May 2002 11:42:24 -0400 (EDT) Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20300 for ; Sun, 5 May 2002 11:42:17 -0400 (EDT) Received: from nt-mail.radvision.com ([212.143.185.30]) by mxout1.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GVN00854A9KMO@mxout1.netvision.net.il> for sip@ietf.org; Sun, 05 May 2002 18:41:44 +0300 (IDT) Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2650.21) id ; Sun, 05 May 2002 18:40:13 +0300 Content-return: allowed Date: Sun, 05 May 2002 18:40:12 +0300 From: Itamar Gilad To: SIP list Cc: Adi Even-Tzur Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=WINDOWS-1255 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sip] To-tag in REGISTER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT This is question we ran into in the last SIPit. How should an incoming REGISTER request be handled if it has a To tag: 1. Reject the request with a 4xx response code (Invalid Registration) or 2. Accept the request but ignore the To tag at the address-of-record stored at the location DB (the record is stored without the tag). Thanks in advance Itamar Gilad RADVISION _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 21:41:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13356 for ; Mon, 6 May 2002 21:41:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09091 for sip-archive@odin.ietf.org; Mon, 6 May 2002 21:41:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07615; Mon, 6 May 2002 21:20:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03554 for ; Sun, 5 May 2002 17:01:21 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23546 for ; Sun, 5 May 2002 17:01:14 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g45L0nd01807; Sun, 5 May 2002 16:00:50 -0500 Message-ID: <001101c1f477$d52a0170$133fed0c@C1893415A> From: "Dean Willis" To: Cc: , "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR> Date: Sun, 5 May 2002 16:00:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-willis-sip-svcrtdisco-03 now available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This draft has been submitted to internet-drafts and should appear shortly. In the meantime, use: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-03.txt OR http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-03.htm l Please recall that this draft is cureently under Expert Review. Get those comments in please! -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon May 6 21:46:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14498 for ; Mon, 6 May 2002 21:46:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10013 for sip-archive@odin.ietf.org; Mon, 6 May 2002 21:46:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07642; Mon, 6 May 2002 21:20:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08654 for ; Mon, 6 May 2002 13:56:17 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29684 for ; Mon, 6 May 2002 13:56:10 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g46Htkk12203 for ; Mon, 6 May 2002 13:55:46 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 May 2002 12:55:45 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C026055B5@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: "Miguel A. Garcia" , sip@ietf.org, Rohan Mahy , "Drage, Keith (Keith)" Date: Mon, 6 May 2002 12:55:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] RE: Dialog-ID and Replaces reconciliation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Miguel, Rohan, I took a look at the Replaces header and I see some similarities. However, I don't think I'm going to have time today to rework the syntax and submit all my 3GPP contributions. So I think this will have to wait until later this week. Eric -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Saturday, May 04, 2002 1:01 AM To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith (Keith) Subject: Dialog-ID and Replaces reconciliation Eric, Rohan: The SIP Replaces header and the P-Original-Dialog-ID header seem to have some common parts. For instance, both define mechanisms to transport the to-tag and the from-tag in the header value. I was wondering if it would be possible to re-use as much as possible from the other. For instance, Replaces defines "to-tag" and "from-tag", whereas P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think it would be much better if P-Original-Dialog-ID defines "to-tag" and "from-tag". The "original-dialog" meaning is implicitely carried in the header name and syntax. This would allow easier definition of the SIP dictionary used in compression, because we don't need different entries in the dictionary. It would also allow to reuse as much as possible the software code in an implementation. On the other hand, Replaces seems to lack a "call-id=" string. P-Original-Dialog-ID has it, and it is certainly needed. Is there a way to synchronize these two?? I hope you can take my comments onboard. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 01:41:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19535 for ; Tue, 7 May 2002 01:41:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29604 for sip-archive@odin.ietf.org; Tue, 7 May 2002 01:41:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28567; Tue, 7 May 2002 01:18:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28536 for ; Tue, 7 May 2002 01:18:04 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19342 for ; Tue, 7 May 2002 01:17:54 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g475Hw0E004519; Tue, 7 May 2002 07:17:58 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g475Hv9q027981; Tue, 7 May 2002 08:17:57 +0300 (EET DST) Message-ID: <3CD76380.B3D8A024@ericsson.com> Date: Tue, 07 May 2002 08:17:52 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: "Henrikson, Eric H (Eric)" CC: sip@ietf.org, Rohan Mahy , "Drage, Keith (Keith)" References: <47AF9FA8BB0DD611A75C00A0C9AA883C026055B5@il0015exch004u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Dialog-ID and Replaces reconciliation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric, Rohan, Keith: No rush. I think the important thing is to synchronize both headers. My suggestion for both is to use the following syntax. P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON dialog-value dialog-value = call-id COMMA to-tag COMMA from-tag [COMMA extension-param] call-id = "call-id" EQUAL callid to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token extension-param = token [EQUAL (token | quoted-string)] Example: P-Original-Dialog-ID: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983 And for Replaces: Replaces = "Replaces" HCOLON replaces-values *(COMMA replaces-values) replaces-values = call-id *( SEMI replaces-param ) call-id = "call-id" EQUAL callid replaces-param = to-tag | from-tag | extension-param to-tag = "to-tag" EQUAL ( token | "*" ) from-tag = "from-tag" EQUAL token extension-param = token [ EQUAL ( token | quoted-string ) ] Example: Replaces: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983 Is this acceptable??? /Miguel "Henrikson, Eric H (Eric)" wrote: > > Miguel, Rohan, > > I took a look at the Replaces header and I see some similarities. However, > I don't think I'm going to have time today to rework the syntax and submit > all my 3GPP contributions. So I think this will have to wait until later > this week. > > Eric > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Saturday, May 04, 2002 1:01 AM > To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith > (Keith) > Subject: Dialog-ID and Replaces reconciliation > > Eric, Rohan: > > The SIP Replaces header and the P-Original-Dialog-ID header seem to > have some common parts. For instance, both define mechanisms to > transport the to-tag and the from-tag in the header value. > > I was wondering if it would be possible to re-use as much as possible > from the other. > > For instance, Replaces defines "to-tag" and "from-tag", whereas > P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think > it would be much better if P-Original-Dialog-ID defines "to-tag" and > "from-tag". The "original-dialog" meaning is implicitely carried > in the header name and syntax. > > This would allow easier definition of the SIP dictionary used in > compression, because we don't need different entries in the > dictionary. It would also allow to reuse as much as possible the > software code in an implementation. > > On the other hand, Replaces seems to lack a "call-id=" string. > P-Original-Dialog-ID has it, and it is certainly needed. Is there > a way to synchronize these two?? > > I hope you can take my comments onboard. > > /Miguel > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 03:40:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29500 for ; Tue, 7 May 2002 03:40:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04928 for sip-archive@odin.ietf.org; Tue, 7 May 2002 03:40:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03808; Tue, 7 May 2002 03:15:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03774 for ; Tue, 7 May 2002 03:15:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29248 for ; Tue, 7 May 2002 03:15:34 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g477G0n04082 for ; Tue, 7 May 2002 10:16:01 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 May 2002 10:15:36 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 10:15:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F596.FDF5CA50" Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 10:15:39 +0300 Message-ID: Thread-Topic: [Sip] Re: WGLC for draft-willis-sip-path-05 Thread-Index: AcH1MmGUbLz/n2oeTcGM3jLVEOUv5gAZBdqA To: , , Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, X-OriginalArrivalTime: 07 May 2002 07:15:40.0362 (UTC) FILETIME=[FE4FB2A0:01C1F596] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1F596.FDF5CA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sriram ! =20 Will be fixed in the next version. Thanks for pointing this out. =20 cheers, Bernie -----Original Message----- From: ext Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: 06 May, 2002 21:52 To: 'Miguel A. Garcia'; Dean Willis Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard = (NET/Helsinki) Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Dean, Bernie,=20 One more recommendation:=20 ** Since the draft adds an option tag "path". I would highly recommend = that put "Supported:path,...." in all REGISTER's shown in the draft. Thanks,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-684-3986=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message-----=20 From: Miguel A. Garcia [ mailto:Miguel.A.Garcia@ericsson.com]=20 Sent: Monday, May 06, 2002 1:36 AM=20 To: Dean Willis=20 Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;=20 bernhard.honeisen@nokia.com=20 Subject: [Sip] Re: WGLC for draft-willis-sip-path-05=20 Dean, Bernie:=20 Some comments to the Path header, mostly NITS.=20 1) Regarding the tag option "Path" for the Supported header, as far as=20 I have seen before, most of the other option tags are defined in=20 lowercase. I would suggest to follow the same approach for = consistency,=20 that is, define "path".=20 2) The syntax defined at the end of section 3 does not allow the Path=20 header to be part of the request, only to the response. I suspect=20 this is an error. Suggestion:=20 Header field where proxy ACK BYE CAN INV OPT REG PRA = _______________________________________________________________ = Path R ar - - - - - o -=20 Path 2xx - - - - - - o -=20 3) The last sentence in section 4.1 reads: "The UA should include the=20 option tag 'Path' in any Supported headers". I suspect this inclusion = affects all the instances of Supported, including those in an INVITE. = Can you confirm this?=20 4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be=20 replaced by reference [2] (bis-09).=20 5) In section 4.7, the Via in the examples do not begin with "z9hG4bK"=20 as required by bis-09.=20 Thanks a lot,=20 Miguel=20 Dean Willis wrote:=20 >=20 > I'd like to request Working Group Last Call for draft-willis-sip-path. = > This will need to close by about 11May.=20 >=20 > Version -05 draft has been submitted to internet-drafts and shoudl be=20 > available.=20 >=20 > in the meantime use:=20 >=20 > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt=20 >=20 > or=20 >=20 > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html=20 >=20 > --=20 > Dean=20 --=20 Miguel-Angel Garcia Oy LM Ericsson AB=20 Jorvas, Finland=20 mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553=20 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002=20 _______________________________________________=20 Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip=20 ------_=_NextPart_001_01C1F596.FDF5CA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Hi=20 Sriram !
 
Will=20 be fixed in the next version.
Thanks for pointing this=20 out.
 
cheers,
 Bernie
-----Original Message-----
From: ext Sriram = Parameswar=20 [mailto:sriramp@nortelnetworks.com]
Sent: 06 May, 2002=20 21:52
To: 'Miguel A. Garcia'; Dean Willis
Cc:=20 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard=20 (NET/Helsinki)
Subject: RE: [Sip] Re: WGLC for=20 draft-willis-sip-path-05

Dean, Bernie,

One more recommendation:

** Since the draft adds an option tag "path". I = would highly=20 recommend that put "Supported:path,...." in all REGISTER's shown in = the=20 draft.

Thanks,

Sriram
__________________________________________
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia = Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson=20 USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From:=20 Miguel A. Garcia [mailto:Miguel.A.Garcia@erics= son.com]=20
Sent: Monday, May 06, 2002 1:36 AM
To: Dean Willis
Cc:=20 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;
bernhard.honeisen@nokia.com
Subject: [Sip] Re:=20 WGLC for draft-willis-sip-path-05


Dean, Bernie:

Some comments to the Path header, mostly = NITS.

1) Regarding the tag option "Path" for the Supported = header,=20 as far as
   I have seen before, = most of the=20 other option tags are defined in
  =20 lowercase. I would suggest to follow the same approach for = consistency,=20
   that is, define "path".

2) The syntax defined at the end of section 3 does = not allow=20 the Path
   header to be part of = the=20 request, only to the response. I suspect
  =20 this is an error. Suggestion:

         = Header=20 field          = where  =20 proxy ACK BYE CAN INV OPT REG PRA
        =20 _______________________________________________________________ =
        =20 = Path           &nb= sp;       =20 R       ar   -  =20 -   -   -   -   o   = -=20
        =20 = Path           &nb= sp;      =20 2xx       -   -  =20 -   -   -   -   o   = -=20

3) The last sentence in section 4.1 reads: "The UA = should=20 include the
   option tag 'Path' = in any=20 Supported headers". I suspect this inclusion
   affects all the instances of Supported, = including those in=20 an INVITE.
   Can you confirm = this?=20

4) Reference 1 (RFC 2543) and to "the binding" = (section 4.3)=20 should be
   replaced by reference = [2]=20 (bis-09).

5) In section 4.7, the Via in the examples do not = begin with=20 "z9hG4bK"
   as required by = bis-09.=20

Thanks a lot,

       Miguel =


Dean Willis wrote:
>=20
> I'd like to request Working Group Last = Call for=20 draft-willis-sip-path.
> This will need = to close by=20 about 11May.
>
> Version=20 -05 draft has been submitted to internet-drafts and shoudl be =
> available.
> =
> in the meantime use:
> =
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt= =20
>
> or =
>
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html=20
>
> -- =
> Dean

--
Miguel-Angel=20 = Garcia           &= nbsp;        =20 Oy LM Ericsson AB
          &nbs= p;            = ;            =     =20 Jorvas, Finland
mailto:Miguel.A.Garcia@erics= son.com    =20 Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.ne= t       =20 Mobile: +358 40 5140002

_______________________________________________=20
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip=20
This list is for NEW development of the core SIP=20 Protocol
Use = sip-implementors@cs.columbia.edu for=20 questions on current sip
Use = sipping@ietf.org for new=20 developments on the application of sip =

------_=_NextPart_001_01C1F596.FDF5CA50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 03:40:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29517 for ; Tue, 7 May 2002 03:40:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04942 for sip-archive@odin.ietf.org; Tue, 7 May 2002 03:40:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03882; Tue, 7 May 2002 03:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03851 for ; Tue, 7 May 2002 03:17:42 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29266 for ; Tue, 7 May 2002 03:17:32 -0400 (EDT) Received: (qmail 32368 invoked from network); 7 May 2002 08:16:58 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.93) by nghmail with SMTP; 7 May 2002 08:16:58 -0000 Message-ID: <001a01c1f531$f5863320$5601a8c0@knowsys.net> From: "vishal" To: Cc: Date: Tue, 7 May 2002 00:40:35 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C1F55F.CD36BF60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sip] comments for UPDATE method Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C1F55F.CD36BF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , I have following comments regards, vishal comments: 1. Timer handling section should be included. UPDATE response timer must = be less than initial INVITE timer.Every time new UPDATE command is = issued in early dialog,wait timer (of initial INVITE response) must be = adjusted .=20 2. UPDATE response is sent without prompting remote user .It requires = UPDATE can be issued only from trusted party .It means user issuing = UPDATE command MUST send authentication info along with UPDATE command . 3. In section 5.3 "Processing the UPDATE Response" It is written that "If a UA receives a non-2xx final response to a UPDATE, the session = parameters MUST remain unchanged, as if no UPDATE had been issued.Note = that, as stated in Section 12.2.1 of RFC BBBB [1], if the non-2xx final = response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request = Timeout), or no response at all is received for the UPDATE (that is, a = timeout is returned by the UPDATE client transaction), the UAC will = terminate the dialog." In case no response received for UPDATE then UAC SHOULD not terminate = the dialog.Response to UPDATE may be delayed,lost,currupted due to many = reasons for ex. message was routed through many proxies OR UAS,proxy took more = time in processing of authentication,locating user etc .Response to = UPDATE received after timer expiry SHOULD be rejected and session = parametre SHOULD remain unchanged .Dialog SHOULD not be terminated . UPDATE failure MUST not affect ongoing dialog. queries: 1. Can UPDATE be over TCP when initial INVITE was over UDP ,so that more = UPDATEs can be sent over same TCP connection? 2. Can UPDATE be issued only for SDP modification purposes or it can be = issued to modify contact info,call-id,allow fields etc.? 3. Can UPDATE be generated by other SIP entities(redirect server,proxies = etc) if they want to enforce particular session parametres based = dialog.? SUGGESTION=20 UPDATE should be used only for early dialogs .For confirmed dialogs = ,re-INVITE MUST be used to avoid inconsistancy Vishal , Knowledge Systems Pvt Ltd ,INDIA 470, East End Main Road =20 9th Block Jayanagar , Bangalore 560 069 =20 Telephone: +91-80-6545252 ------=_NextPart_000_000F_01C1F55F.CD36BF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi ,

 I have following comments

regards, vishal

comments:

1. Timer handling section should be included. = UPDATE=20 response timer must be less than initial = INVITE=20 timer.Every time new UPDATE command is issued = in early=20 dialog,wait timer (of initial INVITE response) = must be=20 adjusted .

2. UPDATE response is sent without prompting = remote user .It=20 requires UPDATE can be issued only from = trusted party=20 .It means user issuing UPDATE command MUST = send=20 authentication info along with UPDATE command .

3. In section 5.3 "Processing the UPDATE=20 Response"

It is written that

"If a UA receives a non-2xx final response to a = UPDATE, the=20 session parameters MUST remain unchanged, as = if no=20 UPDATE had been issued.Note that, as stated in = Section=20 12.2.1 of RFC BBBB [1], if the non-2xx final = response is=20 a 481 (Call/Transaction Does Not Exist), or a 408=20 (Request Timeout), or no response at all is received for the = UPDATE (that is, a timeout is returned by the UPDATE client = transaction), the UAC will terminate the=20 dialog."

In case no response received for UPDATE then UAC = SHOULD not=20 terminate the dialog.Response to UPDATE may be = delayed,lost,currupted due to many reasons

for ex. message was routed through many proxies OR UAS,proxy took more time in processing of=20 authentication,locating user etc .Response to = UPDATE=20 received after timer expiry SHOULD be rejected and session parametre SHOULD remain unchanged = .Dialog SHOULD not be=20 terminated .

UPDATE failure MUST not affect ongoing = dialog.

queries:

1. Can UPDATE be over TCP when initial INVITE was = over UDP=20 ,so that more UPDATEs can be sent over same = TCP=20 connection?

2. Can UPDATE be issued only for SDP modification = purposes=20 or it can be issued to modify contact = info,call-id,allow=20 fields etc.?

3. Can UPDATE be generated by other SIP = entities(redirect=20 server,proxies etc) if they want to enforce = particular=20 session parametres based dialog.?

SUGGESTION

UPDATE should be used only for early dialogs .For = confirmed=20 dialogs ,re-INVITE MUST be used to avoid=20 inconsistancy

 
 
 
Vishal ,
Knowledge Systems Pvt = Ltd =20 ,INDIA
470, East End Main Road 
9th Block Jayanagar = ,
Bangalore=20 560 069 
Telephone: +91-80-6545252
------=_NextPart_000_000F_01C1F55F.CD36BF60-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 08:01:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03830 for ; Tue, 7 May 2002 08:01:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19423 for sip-archive@odin.ietf.org; Tue, 7 May 2002 08:01:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16910; Tue, 7 May 2002 07:35:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16846 for ; Tue, 7 May 2002 07:35:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02763; Tue, 7 May 2002 07:35:07 -0400 (EDT) Message-Id: <200205071135.HAA02763@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 May 2002 07:35:06 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-path-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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, B. Hoeneisen Filename : draft-willis-sip-path-05.txt Pages : 16 Date : 06-May-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: 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 does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-path-05.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-willis-sip-path-05.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-path-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020506144228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-path-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-path-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020506144228.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 08:01:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03864 for ; Tue, 7 May 2002 08:01:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19507 for sip-archive@odin.ietf.org; Tue, 7 May 2002 08:01:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16897; Tue, 7 May 2002 07:35:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16848 for ; Tue, 7 May 2002 07:35:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02747; Tue, 7 May 2002 07:35:03 -0400 (EDT) Message-Id: <200205071135.HAA02747@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 May 2002 07:35:01 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Extension Header for Service Route Discovery in Private Networks Author(s) : D. Willis, B. Hoeneisen Filename : draft-willis-sip-scvrtdisco-03.txt Pages : 15 Date : 06-May-02 This document proposes a private SIP extension header used in conjunction with responses to REGISTER messages to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-03.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-willis-sip-scvrtdisco-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-scvrtdisco-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020506144219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-scvrtdisco-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-scvrtdisco-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020506144219.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 11:27:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12317 for ; Tue, 7 May 2002 11:27:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04258 for sip-archive@odin.ietf.org; Tue, 7 May 2002 11:27:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01960; Tue, 7 May 2002 10:59:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01931 for ; Tue, 7 May 2002 10:59:22 -0400 (EDT) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11098 for ; Tue, 7 May 2002 10:59:15 -0400 (EDT) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Sun, 7 May 2000 17:12:37 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <3915A405.16258.6C13F04@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Subject: [Sip] forking dialogs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, can there be any other reason different to parallel forking, that could lead a call to consist of several dialogs? thanks, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 12:10:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14087 for ; Tue, 7 May 2002 12:10:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08685 for sip-archive@odin.ietf.org; Tue, 7 May 2002 12:10:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06144; Tue, 7 May 2002 11:45:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06112 for ; Tue, 7 May 2002 11:45:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13326 for ; Tue, 7 May 2002 11:45:23 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g47Fixp6008708; Tue, 7 May 2002 08:45:00 -0700 (PDT) Received: from ARUNVENKW2Kl (arunvenk-w2kl-1.cisco.com [64.101.164.76]) by sponge.cisco.com (Mirapoint) with SMTP id AAU75574; Tue, 7 May 2002 10:44:58 -0500 (CDT) From: "Arunachalam Venkatraman" To: , Subject: RE: [Sip] forking dialogs Date: Tue, 7 May 2002 10:44:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3915A405.16258.6C13F04@localhost> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Redirection(3xx response to INVITE) results in multiple dialogs which are not simultaneous. Call Transfer using Refer can result in a new dialog if the transferred call leg uses the same call id for the new call(dialog). In this case, both dialogs are simultaenous. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Salva Rey Calatayud Sent: Sunday, May 07, 2000 10:13 AM To: sip@ietf.org Subject: [Sip] forking dialogs Hi, can there be any other reason different to parallel forking, that could lead a call to consist of several dialogs? thanks, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 13:38:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17586 for ; Tue, 7 May 2002 13:38:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14361 for sip-archive@odin.ietf.org; Tue, 7 May 2002 13:38:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12421; Tue, 7 May 2002 13:07:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12389 for ; Tue, 7 May 2002 13:07:54 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16258 for ; Tue, 7 May 2002 13:07:47 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A9E4489400FC; Tue, 07 May 2002 13:07:48 -0400 Message-ID: <00b601c1f5e9$0e6268c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , References: <002301c1f478$b385d570$133fed0c@C1893415A> <3CD62433.C1714CB@ericsson.com> Date: Tue, 7 May 2002 13:03:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for draft-willis-sip-path-05: Require:path needed? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Dean, Maybe I am missing something, but how do we make sure the registrar can support the Path header? The UA probably does not care, but the intervening proxies probably need to know that the "Path" cannot honored by the registrar. I suppose the proxy could insert Require:path if it saw the Supported:path in the request. I think the spec should say that UAs that want to allow a Path to be inserted MUST add Supported:path to the REGISTER request and that a proxy MUST NOT add a Path header if Supported:path is not present. The proxy inserting a Path header SHOULD add Require:path to guarantee that the registrar supports Path. If the request is rejected with 420, the UA SHOULD resubmit without Supported:path. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 13:50:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18187 for ; Tue, 7 May 2002 13:50:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15124 for sip-archive@odin.ietf.org; Tue, 7 May 2002 13:50:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13260; Tue, 7 May 2002 13:19:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13236 for ; Tue, 7 May 2002 13:19:56 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16796 for ; Tue, 7 May 2002 13:19:46 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id ACB6D05200D8; Tue, 07 May 2002 13:19:50 -0400 Message-ID: <00b901c1f5ea$bb9d86e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Miguel A. Garcia" , "Dean Willis" Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , References: <002301c1f478$b385d570$133fed0c@C1893415A> <3CD62433.C1714CB@ericsson.com> Subject: Re: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 13:15:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit see below ----- Original Message ----- From: "Miguel A. Garcia" > Dean, Bernie: > > Some comments to the Path header, mostly NITS. > > 1) Regarding the tag option "Path" for the Supported header, as far as > I have seen before, most of the other option tags are defined in > lowercase. I would suggest to follow the same approach for consistency, > that is, define "path". I also think it should be "path". > > 2) The syntax defined at the end of section 3 does not allow the Path > header to be part of the request, only to the response. I suspect > this is an error. Suggestion: > > Header field where proxy ACK BYE CAN INV OPT REG PRA > _______________________________________________________________ > Path R ar - - - - - o - > Path 2xx - - - - - - o - A prior e-mail said that a UA was not allowed include a Path header. Is there a particular reason we want to prohibit the UA from contributing to the path? I can't think of a particular example, but a UA could know that a specific element needs to be on the inbound path, and that element may not be in the register path (just like a proxy adding "a Path element referencing another node" as described in section 4.2). > > 3) The last sentence in section 4.1 reads: "The UA should include the > option tag 'Path' in any Supported headers". I suspect this inclusion > affects all the instances of Supported, including those in an INVITE. > Can you confirm this? The Supported:path is only needed in the REGISTER request. Why would the UA need to include it in INVITEs it sends? And how would a Calling UA know to include it? I don't think the Calling party needs to consent to the Called party's registered Path. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 13:56:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18452 for ; Tue, 7 May 2002 13:56:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15450 for sip-archive@odin.ietf.org; Tue, 7 May 2002 13:56:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14540; Tue, 7 May 2002 13:40:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14509 for ; Tue, 7 May 2002 13:40:50 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17650 for ; Tue, 7 May 2002 13:40:42 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47HdNd18545; Tue, 7 May 2002 12:39:23 -0500 From: "Dean Willis" To: Cc: , "'3GPP_TSG_CN_WG1'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , "'Rohan Mahy'" , , Subject: RE: [Sip] WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 12:39:20 -0500 Message-ID: <014401c1f5ee$1f8f9690$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15574.14707.901024.844778@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of jh@lohi.eng.song.fi > Sent: Monday, May 06, 2002 3:06 AM > To: Dean Willis > Cc: sip@ietf.org; 3GPP_TSG_CN_WG1; > bernhard.honeisen@nokia.com; Rohan Mahy; > brian.rosen@marconi.com; jo@ipdialog.com > Subject: [Sip] WGLC for draft-willis-sip-path-05 > > > below are my comments: > > - i thought that it was agreed to use name rrr instead of > path for this > header. the reason is that this header is both semantically and > syntactically very close to record-route. also, name path is not at > all descriptive, what path? I polled the list on April 1, and received about a dozen responses indicating a preference for Path. Nobody responded in favor of RRR. > - this paragraph should be moved, since somebody's > suggestions regarding > things that are outside the scope of the i-d should not be part of > the normative text: > > It has been suggested that the UA MAY choose to store the > contents of > the Path header for future use as a preloaded Route for use when the > UA wishes to send a SIP message that, for reasons of acquiring > services in the home network, need to transit the service proxies in > the home network. Such usage is explicitly outside the > scope of this > document. > This seems reasonable, and unless there are objections I intend to delete in next revision. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 16:06:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22850 for ; Tue, 7 May 2002 16:06:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16835 for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:07:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14720; Tue, 7 May 2002 15:41:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14435 for ; Tue, 7 May 2002 15:41:33 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20121 for ; Tue, 7 May 2002 14:47:16 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47Ikld21627; Tue, 7 May 2002 13:46:47 -0500 From: "Dean Willis" To: "'Bob Penfield'" Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , Date: Tue, 7 May 2002 13:46:37 -0500 Message-ID: <016b01c1f5f7$895c7670$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00b601c1f5e9$0e6268c0$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob said: > Maybe I am missing something, but how do we make sure the > registrar can support the Path header? The UA probably does > not care, but the intervening proxies probably need to know > that the "Path" cannot honored by the registrar. I suppose > the proxy could insert Require:path if it saw the > Supported:path in the request. > > I think the spec should say that UAs that want to allow a > Path to be inserted MUST add Supported:path to the REGISTER > request and that a proxy MUST NOT add a Path header if > Supported:path is not present. The proxy inserting a Path > header SHOULD add Require:path to guarantee that the > registrar supports Path. If the request is rejected with 420, > the UA SHOULD resubmit without Supported:path. I think this works. It does have the side effect that a UA that doesn't know about Path can't be served by a proxy network that requires it even though there are no functional changes needed in the UA. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 16:07:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22898 for ; Tue, 7 May 2002 16:07:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16850 for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:07:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14788; Tue, 7 May 2002 15:41:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14492 for ; Tue, 7 May 2002 15:41:36 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18782 for ; Tue, 7 May 2002 14:07:55 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47I7Od19915; Tue, 7 May 2002 13:07:24 -0500 From: "Dean Willis" To: "'Bob Penfield'" , "'Miguel A. Garcia'" Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 13:07:21 -0500 Message-ID: <014801c1f5f2$08f85df0$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00b901c1f5ea$bb9d86e0$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob asked: > A prior e-mail said that a UA was not allowed include a Path > header. Is there a particular reason we want to prohibit the > UA from contributing to the path? I can't think of a > particular example, but a UA could know that a specific > element needs to be on the inbound path, and that element may > not be in the register path (just like a proxy adding "a Path > element referencing another node" as described in section 4.2). That's a reasonable question. It's not consistent with the original intent, but on first analysis, I can't think of a real reason that this COULDN'T be done. Anybody else out there have an opinion? > > > 3) The last sentence in section 4.1 reads: "The UA should > include the > > option tag 'Path' in any Supported headers". I suspect > this inclusion > > affects all the instances of Supported, including those > in an INVITE. > > Can you confirm this? > > The Supported:path is only needed in the REGISTER request. > Why would the UA need to include it in INVITEs it sends? And > how would a Calling UA know to include it? I don't think the > Calling party needs to consent to the Called party's registered Path. The Supported mechanism is not method specific. This is part of why option tags may not be such a good idea. The UA is supposed to include an option tag for EVERY extension it supports in EVERY case in which it sends a Supported header. >From bis: 20.37 Supported 4429 The Supported header field enumerates all the extensions supported by the UAC or UAS. 4430 The Supported header field contains a list of option tags, described in Section 19.2, that are understood 4431 by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to 4432 standards-track RFCs. If empty, it means that no extensions are supported. It doesn't really matter whether the calling UA understands Path or not -- it is applied by the called party's proxy. Conversely, I'm not sure that it matters all that much whether the registering UA understands Path. If it doesn't, it can't sanity-check the response in 200Ok, but that doesn't keep the path mechanism from working. One possibility (and I believe this is the justification for Supported in this case) is that the UA knows whether its registrar supports Path, and that intermediate proxies can use the presence of a Supported header for path as hint to decide whether they may safely include Path headers. One could for example use this mechanism to allow a proxy to reject a registration when the proxy knows that it requires Path functionality, and the UA doesn't indicate support for the header. This seems like a slight stretching of the Supported functionality, but should work. What we don't have is a way to have perfect forward knowledge in the proxy which inserts Path that the registrar processing the registration understands Path. Perhaps there's a way to get this using Require? For example, the UA could do a Require: path if it thinks that there's any chance that intermediate proxies will need it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 16:07:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22937 for ; Tue, 7 May 2002 16:07:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16924 for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:07:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14795; Tue, 7 May 2002 15:41:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14519 for ; Tue, 7 May 2002 15:41:37 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18780 for ; Tue, 7 May 2002 14:07:52 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47I7Pd19920; Tue, 7 May 2002 13:07:25 -0500 From: "Dean Willis" To: "'Sriram Parameswar'" , "'Miguel A. Garcia'" Cc: , Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 13:07:21 -0500 Message-ID: <014901c1f5f2$09b76830$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014A_01C1F5C8.20E16030" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_014A_01C1F5C8.20E16030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit excellent suggestion. -- dean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Sriram Parameswar Sent: Monday, May 06, 2002 1:52 PM To: 'Miguel A. Garcia'; Dean Willis Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; bernhard.honeisen@nokia.com Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Dean, Bernie, One more recommendation: ** Since the draft adds an option tag "path". I would highly recommend that put "Supported:path,...." in all REGISTER's shown in the draft. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Monday, May 06, 2002 1:36 AM To: Dean Willis Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; bernhard.honeisen@nokia.com Subject: [Sip] Re: WGLC for draft-willis-sip-path-05 Dean, Bernie: Some comments to the Path header, mostly NITS. 1) Regarding the tag option "Path" for the Supported header, as far as I have seen before, most of the other option tags are defined in lowercase. I would suggest to follow the same approach for consistency, that is, define "path". 2) The syntax defined at the end of section 3 does not allow the Path header to be part of the request, only to the response. I suspect this is an error. Suggestion: Header field where proxy ACK BYE CAN INV OPT REG PRA _______________________________________________________________ Path R ar - - - - - o - Path 2xx - - - - - - o - 3) The last sentence in section 4.1 reads: "The UA should include the option tag 'Path' in any Supported headers". I suspect this inclusion affects all the instances of Supported, including those in an INVITE. Can you confirm this? 4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be replaced by reference [2] (bis-09). 5) In section 4.7, the Via in the examples do not begin with "z9hG4bK" as required by bis-09. Thanks a lot, Miguel Dean Willis wrote: > > I'd like to request Working Group Last Call for draft-willis-sip-path. > This will need to close by about 11May. > > Version -05 draft has been submitted to internet-drafts and shoudl be > available. > > in the meantime use: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt > > or > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html > > -- > Dean -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_014A_01C1F5C8.20E16030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
excellent suggestion.
 
--
dean
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Sriram=20 Parameswar
Sent: Monday, May 06, 2002 1:52 PM
To: = 'Miguel=20 A. Garcia'; Dean Willis
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR;=20 sip@ietf.org; bernhard.honeisen@nokia.com
Subject: RE: [Sip] = Re:=20 WGLC for draft-willis-sip-path-05

Dean, Bernie,

One more recommendation:

** Since the draft adds an option tag "path". I = would highly=20 recommend that put "Supported:path,...." in all REGISTER's shown in = the=20 draft.

Thanks,

Sriram
__________________________________________
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia = Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson=20 USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From:=20 Miguel A. Garcia [mailto:Miguel.A.Garcia@erics= son.com]=20
Sent: Monday, May 06, 2002 1:36 AM
To: Dean Willis
Cc:=20 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;
bernhard.honeisen@nokia.com
Subject: [Sip] Re:=20 WGLC for draft-willis-sip-path-05


Dean, Bernie:

Some comments to the Path header, mostly = NITS.

1) Regarding the tag option "Path" for the Supported = header,=20 as far as
   I have seen before, = most of the=20 other option tags are defined in
  =20 lowercase. I would suggest to follow the same approach for = consistency,=20
   that is, define "path".

2) The syntax defined at the end of section 3 does = not allow=20 the Path
   header to be part of = the=20 request, only to the response. I suspect
  =20 this is an error. Suggestion:

         = Header=20 field          = where  =20 proxy ACK BYE CAN INV OPT REG PRA
        =20 _______________________________________________________________ =
        =20 = Path           &nb= sp;       =20 R       ar   -  =20 -   -   -   -   o   = -=20
        =20 = Path           &nb= sp;      =20 2xx       -   -  =20 -   -   -   -   o   = -=20

3) The last sentence in section 4.1 reads: "The UA = should=20 include the
   option tag 'Path' = in any=20 Supported headers". I suspect this inclusion
   affects all the instances of Supported, = including those in=20 an INVITE.
   Can you confirm = this?=20

4) Reference 1 (RFC 2543) and to "the binding" = (section 4.3)=20 should be
   replaced by reference = [2]=20 (bis-09).

5) In section 4.7, the Via in the examples do not = begin with=20 "z9hG4bK"
   as required by = bis-09.=20

Thanks a lot,

       Miguel =


Dean Willis wrote:
>=20
> I'd like to request Working Group Last = Call for=20 draft-willis-sip-path.
> This will need = to close by=20 about 11May.
>
> Version=20 -05 draft has been submitted to internet-drafts and shoudl be =
> available.
> =
> in the meantime use:
> =
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-pa= th-05.txt=20
>
> or =
>
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-pa= th-05.html=20
>
> -- =
> Dean

--
Miguel-Angel=20 = Garcia           &= nbsp;        =20 Oy LM Ericsson AB
          &nbs= p;            = ;            =     =20 Jorvas, Finland
mailto:Miguel.A.Garcia@erics= son.com    =20 Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.ne= t       =20 Mobile: +358 40 5140002

_______________________________________________=20
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip =
This list is for NEW development of the core SIP = Protocol=20
Use sip-implementors@cs.columbia.edu for questions = on current=20 sip
Use sipping@ietf.org for new = developments on the=20 application of sip

------=_NextPart_000_014A_01C1F5C8.20E16030-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 16:12:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23052 for ; Tue, 7 May 2002 16:12:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17165 for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:12:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13338; Tue, 7 May 2002 15:30:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12996 for ; Tue, 7 May 2002 15:29:53 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19364 for ; Tue, 7 May 2002 14:29:31 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AD0FE503010E; Tue, 07 May 2002 14:29:35 -0400 Message-ID: <001301c1f5f4$6f650000$2300000a@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" , "'Miguel A. Garcia'" Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , References: <014801c1f5f2$08f85df0$4a010114@TXDWILLIS2> Subject: Re: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 14:24:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dean Willis" > > > 3) The last sentence in section 4.1 reads: "The UA should > > include the > > > option tag 'Path' in any Supported headers". I suspect > > this inclusion > > > affects all the instances of Supported, including those > > in an INVITE. > > > Can you confirm this? > > > > The Supported:path is only needed in the REGISTER request. > > Why would the UA need to include it in INVITEs it sends? And > > how would a Calling UA know to include it? I don't think the > > Calling party needs to consent to the Called party's registered Path. > > The Supported mechanism is not method specific. This is part of why > option tags may not be such a good idea. The UA is supposed to include > an option tag for EVERY extension it supports in EVERY case in which it > sends a Supported header. > OK. But surely the UA is allowed to exclude features (option tags) it does not want used for a given request. > It doesn't really matter whether the calling UA understands Path or not > -- it is applied by the called party's proxy. > > Conversely, I'm not sure that it matters all that much whether the > registering UA understands Path. If it doesn't, it can't sanity-check > the response in 200Ok, but that doesn't keep the path mechanism from > working. I almost see the UA's inclusion of "Supported:path" as 'permission' for the intervening elements to insert Path headers (you know all that stuff about the knowledge and consent of the user). That's why I think proxies should be forbidden from adding Path headers if Supported:path is not present. > > One possibility (and I believe this is the justification for Supported > in this case) is that the UA knows whether its registrar supports Path, > and that intermediate proxies can use the presence of a Supported header > for path as hint to decide whether they may safely include Path headers. > One could for example use this mechanism to allow a proxy to reject a > registration when the proxy knows that it requires Path functionality, > and the UA doesn't indicate support for the header. This seems like a > slight stretching of the Supported functionality, but should work. > > What we don't have is a way to have perfect forward knowledge in the > proxy which inserts Path that the registrar processing the registration > understands Path. Perhaps there's a way to get this using Require? > > For example, the UA could do a Require: path if it thinks that there's > any chance that intermediate proxies will need it. By having the proxy that is inserting a Path header add the Require:path, you eliminate the rejection of the request by a registrar that does not support 'path' when no Path headers have been added. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 17:36:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24836 for ; Tue, 7 May 2002 17:36:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22856 for sip-archive@odin.ietf.org; Tue, 7 May 2002 17:36:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14444; Tue, 7 May 2002 13:40:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14413 for ; Tue, 7 May 2002 13:40:02 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17642 for ; Tue, 7 May 2002 13:39:55 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47HdPd18548; Tue, 7 May 2002 12:39:26 -0500 From: "Dean Willis" To: "'Miguel A. Garcia'" Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, , Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Tue, 7 May 2002 12:39:20 -0500 Message-ID: <014501c1f5ee$20502770$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CD62433.C1714CB@ericsson.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Miguel wrote: > 1) Regarding the tag option "Path" for the Supported header, > as far as > I have seen before, most of the other option tags are defined in > lowercase. I would suggest to follow the same approach for > consistency, > that is, define "path". Works for me. > 2) The syntax defined at the end of section 3 does not allow the Path > header to be part of the request, only to the response. I suspect > this is an error. Suggestion: > > Header field where proxy ACK BYE CAN INV > OPT REG PRA > > _______________________________________________________________ > Path R ar - - - - > - o - > Path 2xx - - - - - > - o - I'm busy arguing with Jonathan about the meaning of stuff in table 2. As I read it, the formulation I've given says that the UA (see bis line 4036) MUST NOT insert a Path header in a request, but that a proxy MAY add a Path header, or add to an existing Path header inserted by another proxy. The registrar, which is a UA, MAY (support for Path is optional) insert a Path header in the 2xx response to the request, and proxies MUST NOT modify or delete that header from the response. However, Jonathan has now decided that the text around 4036 is an error, and there's no way to actually describe the logic above in table 2/3. This furthers the arguments that tables 2/3 need to be either deleted or replaced. Jonathan suggests we follow the example of Record-Route and Proxy-Authenticate, which according to Table 2/3 is allowed in a message from a UA even though it makes no sense at all. In short, anybody who's relying on Table 2/3 to provide a truth table for their implementation is likely to be sorely disappointed. > 3) The last sentence in section 4.1 reads: "The UA should include the > option tag 'Path' in any Supported headers". I suspect > this inclusion > affects all the instances of Supported, including those in > an INVITE. > Can you confirm this? Yes, "path" should be included in any Supported headers sent by the UA. At least that's my understanding of the Supported mechanism. It seems to make sense only in REGISTER, but (and I just verified with Jonathan) the Supported mechanism is not method specific, so it goes in any Supported header. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 20:09:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27578 for ; Tue, 7 May 2002 20:09:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29991 for sip-archive@odin.ietf.org; Tue, 7 May 2002 20:09:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28588; Tue, 7 May 2002 19:48:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28559 for ; Tue, 7 May 2002 19:48:27 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27218 for ; Tue, 7 May 2002 19:48:19 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47NlpE26147; Tue, 7 May 2002 18:47:51 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 18:48:04 -0500 Message-ID: From: "Sriram Parameswar" To: "'Dean Willis'" , sip@ietf.org, rsparks@dynamicsoft.com Subject: RE: [Sip] WGLC SIP MIME Types Registration Draft Date: Tue, 7 May 2002 18:47:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F621.9D6F3830" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F621.9D6F3830 Content-Type: text/plain; charset="iso-8859-1" Hi: Quoting section 1 "If the message/sipfrag part contains a body, it must also contain a Content-Length header and the null-line separating headers from the body." I think it would be a good idea to include the Content-Type and possibly other Content related headers (Content-Encoding, Content-Language etc.) - as a SHOULD strength. I am not sure what good it would do, to get a body without the requisite information to extract its true meaning. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Dean Willis [mailto:dwillis@dynamicsoft.com] Sent: Thursday, May 02, 2002 5:32 PM To: sip@ietf.org Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison Mankin'; jo@ipdialog.com; rsparks@dynamicsoft.com Subject: [Sip] WGLC SIP MME Types Registration Draft I'd like to request WGLC of the SIP MIME type registration draft. The current version can be found at: http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt Or http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt We'd like to close WGLC by about May 21. Please copy comments to the list and to Robert Sparks, who will coordinate further efforts. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C1F621.9D6F3830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] WGLC SIP MIME Types Registration Draft

Hi:

Quoting section 1 "If the message/sipfrag part = contains a body, it must also contain a Content-Length header and the = null-line separating headers from the body."

I think it would be a good idea to include the = Content-Type and possibly other Content related headers = (Content-Encoding, Content-Language etc.) - as a SHOULD strength. I am = not sure what good it would do, to get a body without the requisite = information to extract its true meaning.

Thanks,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Dean Willis [mailto:dwillis@dynamicsoft.com]
Sent: Thursday, May 02, 2002 5:32 PM
To: sip@ietf.org
Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison = Mankin';
jo@ipdialog.com; rsparks@dynamicsoft.com
Subject: [Sip] WGLC SIP MME Types Registration = Draft


I'd like to request WGLC of the SIP MIME type = registration draft.

The current version can be found at:

http://www.softarmor.com/sipwg/drafts/draft-sparks-sip= -mimetypes-03.txt

Or

http://search.ietf.org/internet-drafts/draft-sparks-si= p-mimetypes-03.txt



We'd like to close WGLC by about May 21.

Please copy comments to the list and to Robert = Sparks, who will
coordinate further efforts.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = Protocol
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sipping@ietf.org for new developments on the = application of sip

------_=_NextPart_001_01C1F621.9D6F3830-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 7 21:11:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28310 for ; Tue, 7 May 2002 21:11:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03125 for sip-archive@odin.ietf.org; Tue, 7 May 2002 21:11:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01630; Tue, 7 May 2002 20:45:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01602 for ; Tue, 7 May 2002 20:45:28 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27970 for ; Tue, 7 May 2002 20:45:19 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g480mmV23610; Tue, 7 May 2002 19:48:49 -0500 Subject: RE: [Sip] WGLC SIP MIME Types Registration Draft From: Robert Sparks To: Sriram Parameswar Cc: "'Dean Willis'" , sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 07 May 2002 17:37:28 -0700 Message-Id: <1020818249.1320.53.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok. The right way to say this is to call to section 7.4.1 of bis-09/rfc3261 for what is required if a body is present. I'll make that change. RjS On Tue, 2002-05-07 at 16:47, Sriram Parameswar wrote: > Hi: > > Quoting section 1 "If the message/sipfrag part contains a body, it must > also contain a Content-Length header and the null-line separating > headers from the body." > > I think it would be a good idea to include the Content-Type and possibly > other Content related headers (Content-Encoding, Content-Language etc.) > - as a SHOULD strength. I am not sure what good it would do, to get a > body without the requisite information to extract its true meaning. > > Thanks, > > Sriram > > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > -----Original Message----- > From: Dean Willis [ mailto:dwillis@dynamicsoft.com > ] > Sent: Thursday, May 02, 2002 5:32 PM > To: sip@ietf.org > Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison Mankin'; > jo@ipdialog.com; rsparks@dynamicsoft.com > Subject: [Sip] WGLC SIP MME Types Registration Draft > > > I'd like to request WGLC of the SIP MIME type registration draft. > > The current version can be found at: > > http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt > > > > Or > > http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt > t> > > > > We'd like to close WGLC by about May 21. > > Please copy comments to the list and to Robert Sparks, who will > coordinate further efforts. > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 03:37:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28146 for ; Wed, 8 May 2002 03:37:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA10004 for sip-archive@odin.ietf.org; Wed, 8 May 2002 03:37:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08945; Wed, 8 May 2002 03:13:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08914 for ; Wed, 8 May 2002 03:13:17 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27912 for ; Wed, 8 May 2002 03:13:10 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g487DHD00862 for ; Wed, 8 May 2002 09:13:17 +0200 (MEST) Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g487DGM25064 for ; Wed, 8 May 2002 09:13:17 +0200 (MEST) Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 09:13:17 +0200 Message-ID: From: BECKMANN MARK To: sip@ietf.org Date: Wed, 8 May 2002 09:13:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Expert Review of draft-beckmann-sip-event Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have just submitted an update of the informational draft on the registration-state event package (draft-beckmann-sip-reg-event-01). It should come up on the SIP list, soon. Please use this version for the expert review. This update mainly adds a request for registration of the event package in section 4 "IANA considerations". Additionally it aligns the draft with the latest version of the CPIM Presence format draft draft-ietf-impp-cpim-pidf-03. Mark Mark Beckmann Siemens AG ICM MP PO8 SA 82 P.O.Box 100702 phone: +49 (5341) 906 1814 D-38228 Salzgitter fax: +49 (5341) 906 2010 mailto: Mark.Beckmann@siemens.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, May 03, 2002 12:32 AM > To: sip@ietf.org > Cc: 'Allison Mankin'; 'Rohan Mahy'; 'Brian Rosen'; jo@ipdialog.com; > BECKMANN MARK > Subject: Expert Review of draft-beckmann-sip-event > Importance: High > > > > The SIP Working Group has been requested to provide Expert > Review of an > events package for registration state. > > The current version is available at: > > http://www.softarmor.com/sipwg/drafts/draft-beckmann-sip-reg-e vent-00.tx t Or http://search.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-00.t xt Please copy responses to the list and to Mark Beckmann, who will coordinate needed edits. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 04:36:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28945 for ; Wed, 8 May 2002 04:36:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12361 for sip-archive@odin.ietf.org; Wed, 8 May 2002 04:36:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10444; Wed, 8 May 2002 03:56:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10413 for ; Wed, 8 May 2002 03:56:02 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28368 for ; Wed, 8 May 2002 03:55:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g487tw0E010050; Wed, 8 May 2002 09:55:58 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g487tv9q009451; Wed, 8 May 2002 10:55:57 +0300 (EET DST) Message-ID: <3CD8DA07.37ADA947@ericsson.com> Date: Wed, 08 May 2002 10:55:51 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: "Henrikson, Eric H (Eric)" CC: sip@ietf.org, Rohan Mahy , "Drage, Keith (Keith)" References: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EE7@il0015exch004u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Dialog-ID and Replaces reconciliation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Eric: The to-tag will be different only because Replaces will allow a star "*". But if you consider that a star is a token, then it is exacltly the same definition. Rohan, any views on the proposed change to Replaces? /Miguel "Henrikson, Eric H (Eric)" wrote: > > Miguel, > > What you proposed looks fine. I'm not certain about one thing though. If > the intent is to have the same definition for call-id, from-tag and to-tag, > then there is still a difference with the proposed definitions of to-tag. > Does this mean that only the Replaces header version of to-tag would apply > if both headers are eventually adopted as standard headers? > To put it another way, is it allowed to have multiple definitions of to-tag > if both headers are adopted? > > Eric > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Monday, May 06, 2002 10:18 PM > To: Henrikson, Eric H (Eric) > Cc: sip@ietf.org; Rohan Mahy; Drage, Keith (Keith) > Subject: Re: Dialog-ID and Replaces reconciliation > > Eric, Rohan, Keith: > > No rush. I think the important thing is to synchronize both headers. > > My suggestion for both is to use the following syntax. > > P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON dialog-value > dialog-value = call-id COMMA to-tag COMMA from-tag > [COMMA extension-param] > call-id = "call-id" EQUAL callid > to-tag = "to-tag" EQUAL token > from-tag = "from-tag" EQUAL token > extension-param = token [EQUAL (token | quoted-string)] > > Example: > > P-Original-Dialog-ID: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983 > > And for Replaces: > Replaces = "Replaces" HCOLON replaces-values > *(COMMA replaces-values) > > replaces-values = call-id *( SEMI replaces-param ) > call-id = "call-id" EQUAL callid > replaces-param = to-tag | from-tag | extension-param > to-tag = "to-tag" EQUAL ( token | "*" ) > from-tag = "from-tag" EQUAL token > extension-param = token [ EQUAL ( token | quoted-string ) ] > > Example: > > Replaces: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983 > > Is this acceptable??? > > /Miguel > > "Henrikson, Eric H (Eric)" wrote: > > > > Miguel, Rohan, > > > > I took a look at the Replaces header and I see some similarities. > However, > > I don't think I'm going to have time today to rework the syntax and submit > > all my 3GPP contributions. So I think this will have to wait until later > > this week. > > > > Eric > > > > -----Original Message----- > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > Sent: Saturday, May 04, 2002 1:01 AM > > To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith > > (Keith) > > Subject: Dialog-ID and Replaces reconciliation > > > > Eric, Rohan: > > > > The SIP Replaces header and the P-Original-Dialog-ID header seem to > > have some common parts. For instance, both define mechanisms to > > transport the to-tag and the from-tag in the header value. > > > > I was wondering if it would be possible to re-use as much as possible > > from the other. > > > > For instance, Replaces defines "to-tag" and "from-tag", whereas > > P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think > > it would be much better if P-Original-Dialog-ID defines "to-tag" and > > "from-tag". The "original-dialog" meaning is implicitely carried > > in the header name and syntax. > > > > This would allow easier definition of the SIP dictionary used in > > compression, because we don't need different entries in the > > dictionary. It would also allow to reuse as much as possible the > > software code in an implementation. > > > > On the other hand, Replaces seems to lack a "call-id=" string. > > P-Original-Dialog-ID has it, and it is certainly needed. Is there > > a way to synchronize these two?? > > > > I hope you can take my comments onboard. > > > > /Miguel > > > > -- > > Miguel-Angel Garcia Oy LM Ericsson AB > > Jorvas, Finland > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 07:08:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00491 for ; Wed, 8 May 2002 07:08:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19201 for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:08:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17613; Wed, 8 May 2002 06:33:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17586 for ; Wed, 8 May 2002 06:33:43 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00042 for ; Wed, 8 May 2002 06:33:35 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g48AXpk29120 for ; Wed, 8 May 2002 13:33:51 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 May 2002 13:33:29 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 8 May 2002 13:33:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 May 2002 13:33:28 +0300 Message-ID: Thread-Topic: WGLC for draft-willis-sip-path-05: Require:path needed? Thread-Index: AcH1944mM8TlXyXOSsKsfep6ee8gkAAc1vhA To: , Cc: X-OriginalArrivalTime: 08 May 2002 10:33:29.0164 (UTC) FILETIME=[CB14E8C0:01C1F67B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA17587 Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 07 May, 2002 21:47 > To: 'Bob Penfield' > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard > (NET/Helsinki) > Subject: RE: WGLC for draft-willis-sip-path-05: Require:path needed? > > > Bob said: > > Maybe I am missing something, but how do we make sure the > > registrar can support the Path header? The UA probably does > > not care, but the intervening proxies probably need to know > > that the "Path" cannot honored by the registrar. I suppose > > the proxy could insert Require:path if it saw the > > Supported:path in the request. > > > > I think the spec should say that UAs that want to allow a > > Path to be inserted MUST add Supported:path to the REGISTER > > request and that a proxy MUST NOT add a Path header if > > Supported:path is not present. The proxy inserting a Path > > header SHOULD add Require:path to guarantee that the > > registrar supports Path. If the request is rejected with 420, > > the UA SHOULD resubmit without Supported:path. > > I think this works. It does have the side effect that a UA > that doesn't > know about Path can't be served by a proxy network that > requires it even > though there are no functional changes needed in the UA. Do we really want, that the proxies can just insert Paths without the consent of the user? This is related to the first item in the Security considerations section. As the Supported header field can be integrity protected, the registrar has means, to see, whether the UA really knows, what is going on with Path. Besides this, an implementation of the Path to the UA seams fairly easy. My proposal is similar as Bob's: The registrar ignores any Path header if the Supported:path is not present in that REGISTER request. A proxy, which inserts a Path header and really wants to stay on the route for incoming calls, inserts also a Require:path (if not yet present). The registrar decides then based on these two headers, what to do: - The Require:path has the normal meaning: -> send 420 response, if registrar does not understood path - If Supported:path is present in the REGISTER request --> use path as described in the I/D. - If Supported:path is _not_ present in the REGISTER request --> _ignore_ any Path, regardless of any possible Require:path present The only problem I see lasting is, that proxies could prevent a user from registering by just inserting a Require:path. This looks like a more general problem as this can be done with any option tag. Solution: -> after a 420 the UA tries to send the request without Supported:path. -> Proxies MUST NOT insert a Require:path, if no Supported:path was present in the request. Comments? cheers, Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 07:44:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01707 for ; Wed, 8 May 2002 07:44:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA21322 for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:44:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20008; Wed, 8 May 2002 07:29:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19887 for ; Wed, 8 May 2002 07:29:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01138; Wed, 8 May 2002 07:29:00 -0400 (EDT) Message-Id: <200205081129.HAA01138@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 May 2002 07:28:59 -0400 Subject: [Sip] I-D ACTION:draft-henrikson-sip-charging-information-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private SIP Extension for Mobile Charging Information Author(s) : E. Henrikson Filename : draft-henrikson-sip-charging-information-01.txt Pages : 7 Date : 07-May-02 This document proposes a private SIP extension header P-Charging- Function-Addresses used to pass the addresses of entities that provide a charging function. There is a need in the Third Generation Partnership Project (3GPP) for entities that process charging information. For a particular dialog or standalone transaction, a proxy (or UA within the network, e.g. a gateway) may need to pass information to one or more charging entities. The affected UAs and proxies associated with the dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. This document also proposes a private SIP extension header P-Charging-Vector to pass correlation information for charging purposes. The network entities in the 3GPP architecture share correlation information to ensure that charging activities are coordinated. The need applies for any SIP method used to initiate a dialog, standalone messages and some response messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-information-01.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-henrikson-sip-charging-information-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-henrikson-sip-charging-information-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507133254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-henrikson-sip-charging-information-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-henrikson-sip-charging-information-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507133254.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 07:45:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01740 for ; Wed, 8 May 2002 07:45:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA21360 for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:45:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19858; Wed, 8 May 2002 07:29:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19814 for ; Wed, 8 May 2002 07:28:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01082; Wed, 8 May 2002 07:28:47 -0400 (EDT) Message-Id: <200205081128.HAA01082@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 May 2002 07:28:46 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-message-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-04.txt Pages : 20 Date : 07-May-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.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-ietf-sip-message-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-message-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507130225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507130225.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 07:47:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01811 for ; Wed, 8 May 2002 07:47:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA21416 for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:47:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20029; Wed, 8 May 2002 07:29:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19889 for ; Wed, 8 May 2002 07:29:14 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01162; Wed, 8 May 2002 07:29:04 -0400 (EDT) Message-Id: <200205081129.HAA01162@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 May 2002 07:29:04 -0400 Subject: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private SIP Extension for Original Dialog Identifier Author(s) : E. Henrikson Filename : draft-henrikson-sip-original-dialog-id-01.txt Pages : 8 Date : 07-May-02 This document proposes a private SIP extension header used in conjunction with INVITE requests to provide a mechanism by which a stateful proxy may associate an INVITE request processed earlier with the INVITE request that is being currently processed. The association is needed by the Serving Call Session Control Function (S-CSCF) from the Third Generation Partnership Project (3GPP) architecture to ensure proper routing of an INVITE request with 3GPP Application Servers (AS). A S-CSCF may route an INVITE request to multiple AS, as indicated by a subscriber profile, and each AS may be a B2BUA. The S-CSCF needs to keep track of each AS contacted and know that an incoming INVITE request is related to a previous outgoing INVITE request such that each AS may receive the INVITE request before it is sent on towards the intended destination. When a B2BUA AS is involved, there is currently not a way to associate the incoming INVITE request with the previously sent INVITE request at the S-CSCF. The P-Original-Dialog-ID header provides a way to accomplish this association. The same mechanism may be applied to any SIP method that is used to initiate a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-01.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-henrikson-sip-original-dialog-id-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507133305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-henrikson-sip-original-dialog-id-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507133305.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 09:32:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05541 for ; Wed, 8 May 2002 09:32:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27521 for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:33:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25778; Wed, 8 May 2002 09:02:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11059 for ; Tue, 7 May 2002 12:55:18 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15535 for ; Tue, 7 May 2002 12:55:10 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g47Gskw07442 for ; Tue, 7 May 2002 12:54:46 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 May 2002 11:54:46 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EBB@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: Dean Willis , sip@ietf.org Cc: jo@ipdialog.com, brian.rosen@marconi.com, Rohan@cicso.com, "'Allison Mankin'" , "Drage, Keith (Keith)" Date: Tue, 7 May 2002 11:54:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F5E7.DD98BE70" Subject: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1F5E7.DD98BE70 Content-Type: text/plain Attached is revision 01 of the original-dialog-id draft. Please return comments by May 10, 2002. Thank you. Eric Henrikson -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, May 01, 2002 6:38 AM To: sip@ietf.org Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric) Subject: Expert Review: draft-henrikson-sip-original-dialog-id-00.txt The SIP working group has been asked to provide expert review of draft-henrikson-sip-original-dialog-id. This documents a P-header used in 3GPP to associate dialogs across a 3GPP application server acting as a back-to-back user agent. We'd like to complete expert review by May 10, 2002. Please copy your comments to the list and to Keith Drage and Eric Henrikson, who will coordinate responses and edit the draft apporpriately. Thanks, -- Dean Willis ------_=_NextPart_000_01C1F5E7.DD98BE70 Content-Type: text/plain; name="draft-henrikson-sip-original-dialog-id-01.txt" Content-Disposition: attachment; filename="draft-henrikson-sip-original-dialog-id-01.txt" Content-Transfer-Encoding: quoted-printable Internet Draft E. Henrikson = Document: draft-henrikson-sip-original-dialog-id-01 Lucent = Expires: November 2002 Technologies = Category: Informational = May 2002 = =20 Private SIP Extension for Original Dialog Identifier=20 draft-henrikson-sip-original-dialog-id-01=20 =20 Status of this Memo =20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed at =20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html. =20 =20 Abstract =20 =20 This document proposes a private SIP extension header used in=20 conjunction with INVITE requests to provide a mechanism by which a=20 stateful proxy may associate an INVITE request processed earlier=20 with the INVITE request that is being currently processed. The=20 association is needed by the Serving Call Session Control Function=20 (S-CSCF) from the Third Generation Partnership Project (3GPP)=20 architecture to ensure proper routing of an INVITE request with=20 3GPP Application Servers (AS). A S-CSCF may route an INVITE request = to multiple AS, as indicated by a subscriber profile, and each AS=20 may be a B2BUA. The S-CSCF needs to keep track of each AS contacted = and know that an incoming INVITE request is related to a previous=20 outgoing INVITE request such that each AS may receive the INVITE=20 request before it is sent on towards the intended destination. When = a B2BUA AS is involved, there is currently not a way to associate=20 the incoming INVITE request with the previously sent INVITE request = at the S-CSCF. The P-Original-Dialog-ID header provides a way to=20 accomplish this association. The same mechanism may be applied to=20 any SIP method that is used to initiate a dialog.=20 =20 =20 Henrikson Expires - November 2002 [Page 1]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 =20 Table of Contents=20 =20 1. Background....................................................2=20 2. Discussion of Mechanism.......................................3=20 3. Applicability Statement.......................................3=20 4. Syntax........................................................3=20 5. Usage.........................................................4=20 5.1 Procedures at the UA......................................4=20 5.2 Procedures at the Proxy...................................4=20 5.3 Procedures at the Back to Back UA.........................5=20 5.4 Examples of Usage.........................................5=20 6. Security Considerations.......................................6=20 7. IANA Considerations...........................................7=20 8. Normative References..........................................7=20 9. Non-Normative References......................................7=20 Author's Addresses...............................................7=20 =20 1. Background =20 =20 3GPP has defined a mechanism for the S-CSCF (a SIP proxy with=20 additional functionality, which acts as the SIP serving proxy, see=20 draft-garcia-sipping-3gpp-reqs [3]) to contact multiple Application = Servers (AS) when certain SIP events occur, e.g. receiving an=20 INVITE request. These events are also known as Service Points of=20 Interest (SPI). The HSS (database entity) provides the S-CSCF with=20 the list of events and relative priorities of the Application=20 Servers to contact per event (and other information). The data=20 from the HSS is also known as Filter Criteria. =20 =20 When an event occurs that matches an SPI from the Filter Criteria,=20 the SIP serving proxy needs to contact each AS that is matched=20 before sending the message on towards the final destination. Each=20 AS may alter the message in some way before returning the message=20 to the SIP serving proxy. Since the message may have been changed=20 by the AS, including the components of the dialog identifier, the=20 SIP serving proxy needs some way to determine that the received=20 message is related to the original message that it sent to the AS. = This will always be needed when an AS is acting as a B2BUA, which=20 starts a new dialog.=20 =20 The solution provided is to include the original dialog id in the=20 message sent to the AS and to have the AS return the same original=20 dialog id in the message sent back to the SIP serving proxy. Then=20 the SIP serving proxy can make the association between the two=20 messages and know that the incoming message is related to the=20 previous outgoing message, which is part of the sequence to contact = each AS that matched the Filter Criteria.=20 =20 =20 =20 Henrikson Expires - November 2002 [Page 2]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 2. Discussion of Mechanism=20 =20 The provided mechanism uses a private header "P-Original-Dialog-ID" = in an INVITE request forwarded from a proxy. The same mechanism may = be applied to other methods that initiate dialogs. The mechanism=20 only makes sense for stateful proxies that also employ some=20 application specific logic.=20 =20 When a stateful proxy receives an INVITE that does not contain a P- Original-Dialog-ID header, then it may choose to insert a P- Original-Dialog-ID header into an INVITE request prior to=20 forwarding the request. If so, it will populate the contents with=20 the dialog identification fields from the received request: Call- ID, From tag and To tag. If there was no To tag in the received=20 request, then a value of zero will be used for the To parameter in=20 the P-Original-Dialog-ID header.=20 =20 When a stateful proxy receives an INVITE that already contains a P- Original-Dialog-ID header, then it may use this information to look = for a match with a previously handled dialog. If no match is found, = then the message is simply forwarded to the next destination. If a=20 match is found, then depending on the application specific logic=20 that may reside with the proxy, the P-Original-Dialog-ID header may = be removed from the outbound message.=20 =20 3. Applicability Statement=20 =20 This mechanism is suitable when forwarding an initial request for a = dialog, or a standalone transaction, to an AS that may act as a=20 B2BUA, and the request is expected to return to the proxy with a=20 need to correlate the original request and the forwarded request=20 for the transaction or the dialog.=20 =20 =20 4. Syntax=20 =20 All of the mechanisms specified in this document are described in=20 both prose and an augmented Backus-Naur Form (BNF) defined in RFC=20 2234 [2]. Further, the BNF definitions from RFC 3261 [1] are=20 inherited for the P-Original-Dialog-ID header and are not repeated=20 here. Implementers need to need to be familiar with the notation=20 and content of RFC 3261 [1] and RFC 2234 [2] to understand this=20 document.=20 =20 The syntax for the P-Original-Dialog-ID header is:=20 =20 P-Original-Dialog-ID =3D "P-Original-Dialog-ID" HCOLON=20 ( "od-from-tag" EQUAL od-from-tag )=20 ( COMMA "od-to-tag" EQUAL od-to-tag )=20 =20 =20 Henrikson Expires - November 2002 [Page 3]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 ( COMMA "od-call-id" EQUAL od-call-id )=20 =20 od-from-tag =3D token=20 =20 od-to-tag =3D token=20 =20 od-call-id =3D callid=20 =20 The allowable usage of headers is described in Table 2 of SIP [1].=20 The following additions to this table are needed for the P- Original-Dialog-ID header.=20 =20 Addition of P-Original-Dialog-ID to SIP Table 2:=20 =20 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT = ------------------------------------------------------------------- = P-Original-Dialog-ID R ard - - - o o o - o -=20 =20 5. Usage=20 5.1 Procedures at the UA =20 =20 The UAC and UAS (originating and terminating UA) behave as usual.=20 They are not required to understand the P-Original-Dialog-ID=20 header, but may retrieve the information if received.=20 =20 5.2 Procedures at the Proxy =20 =20 The P-Original-Dialog-ID header is treated like any other unknown=20 header by intermediate proxies. They simply forward it on towards=20 the destination.=20 =20 If a proxy that supports this extension receives a dialog request=20 without the P-Original-Dialog-ID header, it may insert a P- Original-Dialog-ID header prior to forwarding the message. The od- from-tag parameter will be populated with the received From tag=20 value. The od-to-tag parameter will be populated with the received=20 To tag value or the value of zero if there was no To tag present.=20 The od-call-id parameter will be populated with the received Call- id value.=20 =20 If a proxy that supports this extension receives a dialog request=20 with the P-Original-Dialog-ID header, it may retrieve the=20 information from the header to use with application specific logic. = The proxy should retain the P-Original-Dialog-ID header in the=20 outbound message. If the next hop for the message is outside the=20 network of the proxy, then the proxy may remove the P-Original- Dialog-ID header from the message.=20 =20 =20 =20 Henrikson Expires - November 2002 [Page 4]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 The P-Original-Dialog-ID header carries only tag information, and=20 therefore does not reveal information that may affect the privacy=20 of the remote users; however the information contained is of no=20 relevance to the end UAs and therefore may be removed as defined=20 above for reasons of protocol efficiency which may be of concern in = a radio environment.=20 =20 5.3 Procedures at the Back to Back UA =20 =20 If a B2BUA that understands the P-Original-Dialog-ID header=20 receives a dialog request with the P-Original-Dialog-ID header, the = B2BUA should copy it from the receiving side UA to the sending side = UA.=20 =20 5.4 Examples of Usage=20 =20 We present example in the context of the scenario presented in the=20 Background section earlier in this document. The network diagram=20 is replicated below:=20 =20 Scenario=20 =20 =20 =20 UA1----P1-----P2-----P1-----P3-----UA2=20 =20 =20 =20 This example shows the message sequence for an INVITE transaction=20 originating from UA1 eventually arriving at UA2. P1 is an outbound=20 proxy for UA1 which routes the request to an Application Server P2. = In this case the Application Server acts as a proxy, but it could=20 equally act as a B2BUA independent of any knowledge of P1. P2=20 routes the request back to P1 using SIP routeing mechanisms that=20 are not detailed in this example. P1 correlates the original=20 request with the returned request. P1 then routes the call via P3=20 to UA2.=20 =20 Message sequence for INVITE using P-Original-Dialog-ID:=20 =20 F1 INVITE UA1 -> P1=20 INVITE sip:joe SIP/2.0=20 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20 To: Joe =20 From: UA@HOMEDOMAIN ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 18 INVITE=20 Contact: =20 . . .=20 =20 =20 Henrikson Expires - November 2002 [Page 5]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 =20 F2 INVITE P1 -> P2=20 INVITE sip:joe SIP/2.0=20 Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20 To: Joe =20 From: UA@HOMEDOMAIN ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 18 INVITE=20 Contact: =20 P-Original-Dialog-ID: od-from-tag=3D456248,od-to-tag=3D0,=20 od-call-id=3D843817637684230@998sdasdh09=20 . . .=20 =20 F3 INVITE P2 -> P1=20 INVITE sip:joe SIP/2.0=20 Via: SIP/2.0/UDP P2:5060;branch=3Dz9hG4bKiokioukju908=20 Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20 To: Joe =20 From: UA@HOMEDOMAIN ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 18 INVITE=20 Contact: =20 P-Original-Dialog-ID: od-from-tag=3D456248,od-to-tag=3D0,=20 od-call-id=3D843817637684230@998sdasdh09=20 . . .=20 =20 P2 removes the P-Original-Dialog-ID header=20 =20 F5 INVITE P1->P3=20 INVITE sip:joe@UA2=20 Via: SIP/2.0/USP P1:5060;branch=3Dz9hG4bKHSP10120323=20 Via: SIP/2.0/UDP P2:5060;branch=3Dz9hG4bKiokioukju908=20 Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20 To: Joe =20 From: UA@HOMEDOMAIN ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 18 INVITE=20 Contact: =20 . . .=20 =20 INVITE propagates toward UA2 as usual.=20 =20 6. Security Considerations =20 =20 It is possible for proxies between the originating UA and the=20 terminating UA to modify the value of P-Original-Dialog-ID or to=20 =20 =20 Henrikson Expires - November 2002 [Page 6]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 insert a P-Original-Dialog-ID into a request for a dialog, e.g.=20 INVITE request. It is also possible for proxies on the INVITE path = to execute many different attacks. It is therefore desirable to=20 apply transitive mutual authentication using sips: or other=20 available mechanisms in order to prevent such attacks. =20 =20 The information contained is tag information from the original=20 request, and therefore knowledge of the contents of this header=20 does not compromise the privacy of the UA or any of the involved=20 proxies.=20 =20 7. IANA Considerations =20 =20 This document defines the SIP extension header "P-Original-Dialog- ID" which should be included in the registry of SIP headers defined = in SIP [1]. As required by the SIP change process draft-tsvarea- sipchange [4] the SIP extension header name "Original-Dialog-ID"=20 should also be registered in association with this extension.=20 =20 8. Normative References =20 =20 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,=20 Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session=20 Initiation Protocol, RFC 3261", March 2002.=20 =20 [2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax=20 specifications: ABNF," RFC 2234, Internet Engineering Task Force,=20 November 1997.=20 =20 9. Non-Normative References=20 =20 [3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia- sipping-3gpp-reqs-03.txt", March 2002.=20 =20 [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange",=20 March 2002.=20 =20 Author's Addresses =20 =20 Eric Henrikson=20 Lucent Technologies=20 11601 Willows Rd=20 Suite 100=20 Redmond, WA 98052=20 US=20 =20 Phone: +1 425 497 2442=20 EMail: ehenrikson@lucent.com=20 URI: http://www.lucent.com/=20 =20 =20 Henrikson Expires - November 2002 [Page 7]=20 =0C Private SIP Extension for Original Dialog Identifier May 2002=20 =20 =20 =20 =20 =20 =20 =20 Henrikson Expires - November 2002 [Page 8]=20 =0C ------_=_NextPart_000_01C1F5E7.DD98BE70-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 09:36:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05733 for ; Wed, 8 May 2002 09:36:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27751 for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:36:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25745; Wed, 8 May 2002 09:02:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12480 for ; Tue, 7 May 2002 13:08:28 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16264 for ; Tue, 7 May 2002 13:08:20 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g47H7uQ14229 for ; Tue, 7 May 2002 13:07:56 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 May 2002 12:07:56 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EE7@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: "Miguel A. Garcia" Cc: sip@ietf.org, Rohan Mahy , "Drage, Keith (Keith)" Date: Tue, 7 May 2002 12:07:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] RE: Dialog-ID and Replaces reconciliation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Miguel, What you proposed looks fine. I'm not certain about one thing though. If the intent is to have the same definition for call-id, from-tag and to-tag, then there is still a difference with the proposed definitions of to-tag. Does this mean that only the Replaces header version of to-tag would apply if both headers are eventually adopted as standard headers? To put it another way, is it allowed to have multiple definitions of to-tag if both headers are adopted? Eric -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Monday, May 06, 2002 10:18 PM To: Henrikson, Eric H (Eric) Cc: sip@ietf.org; Rohan Mahy; Drage, Keith (Keith) Subject: Re: Dialog-ID and Replaces reconciliation Eric, Rohan, Keith: No rush. I think the important thing is to synchronize both headers. My suggestion for both is to use the following syntax. P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON dialog-value dialog-value = call-id COMMA to-tag COMMA from-tag [COMMA extension-param] call-id = "call-id" EQUAL callid to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token extension-param = token [EQUAL (token | quoted-string)] Example: P-Original-Dialog-ID: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983 And for Replaces: Replaces = "Replaces" HCOLON replaces-values *(COMMA replaces-values) replaces-values = call-id *( SEMI replaces-param ) call-id = "call-id" EQUAL callid replaces-param = to-tag | from-tag | extension-param to-tag = "to-tag" EQUAL ( token | "*" ) from-tag = "from-tag" EQUAL token extension-param = token [ EQUAL ( token | quoted-string ) ] Example: Replaces: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983 Is this acceptable??? /Miguel "Henrikson, Eric H (Eric)" wrote: > > Miguel, Rohan, > > I took a look at the Replaces header and I see some similarities. However, > I don't think I'm going to have time today to rework the syntax and submit > all my 3GPP contributions. So I think this will have to wait until later > this week. > > Eric > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Saturday, May 04, 2002 1:01 AM > To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith > (Keith) > Subject: Dialog-ID and Replaces reconciliation > > Eric, Rohan: > > The SIP Replaces header and the P-Original-Dialog-ID header seem to > have some common parts. For instance, both define mechanisms to > transport the to-tag and the from-tag in the header value. > > I was wondering if it would be possible to re-use as much as possible > from the other. > > For instance, Replaces defines "to-tag" and "from-tag", whereas > P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think > it would be much better if P-Original-Dialog-ID defines "to-tag" and > "from-tag". The "original-dialog" meaning is implicitely carried > in the header name and syntax. > > This would allow easier definition of the SIP dictionary used in > compression, because we don't need different entries in the > dictionary. It would also allow to reuse as much as possible the > software code in an implementation. > > On the other hand, Replaces seems to lack a "call-id=" string. > P-Original-Dialog-ID has it, and it is certainly needed. Is there > a way to synchronize these two?? > > I hope you can take my comments onboard. > > /Miguel > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 09:37:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05761 for ; Wed, 8 May 2002 09:37:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27774 for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:37:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25824; Wed, 8 May 2002 09:02:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11158 for ; Tue, 7 May 2002 12:56:03 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15564 for ; Tue, 7 May 2002 12:55:55 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g47GtVw07794 for ; Tue, 7 May 2002 12:55:31 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 May 2002 11:55:30 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EBD@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: Dean Willis , sip@ietf.org Cc: Rohan@cicso.com, "'Allison Mankin'" , jo@ipdialog.com, brian.rosen@marconi.com, "Drage, Keith (Keith)" Date: Tue, 7 May 2002 11:55:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F5E7.FA990F70" Subject: [Sip] Expert Review: draft-henrikson-sip-charging-information-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1F5E7.FA990F70 Content-Type: text/plain Attached is revision 01 of the charging-information draft. Please return comments by May 10, 2002. Thank you. Eric Henrikson -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, May 01, 2002 6:38 AM To: sip@ietf.org Cc: Rohan@cicso.com; 'Allison Mankin'; jo@ipdialog.com; brian.rosen@marconi.com; Drage, Keith (Keith); Henrikson, Eric H (Eric) Subject: Expert Review: draft-henrikson-sip-charging-information-00.txt The SIP Working Group has been requested to provide expert review of draft-henrikson-sip-charging-information. This draft documents P-headers used to interact with the accounting system in 3GPP. We'd like to complete review by May 10, 2002. http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-informa tion-00.txt Thanks! -- Dean Willis ------_=_NextPart_000_01C1F5E7.FA990F70 Content-Type: text/plain; name="draft-henrikson-sip-charging-information-01.txt" Content-Disposition: attachment; filename="draft-henrikson-sip-charging-information-01.txt" Content-Transfer-Encoding: quoted-printable Internet Draft E. Henrikson = Document: draft-henrikson-sip-charging-information- Lucent = Expires: November 2002 Technologies = Category: Informational = May 2002 = =20 Private SIP Extension for Mobile Charging Information=20 draft-henrikson-sip-charging-information-01=20 =20 Status of this Memo =20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed at =20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html. =20 =20 Abstract =20 =20 This document proposes a private SIP extension header P-Charging- Function-Addresses used to pass the addresses of entities that=20 provide a charging function. There is a need in the Third=20 Generation Partnership Project (3GPP) for entities that process=20 charging information. For a particular dialog or standalone=20 transaction, a proxy (or UA within the network, e.g. a gateway) may = need to pass information to one or more charging entities. The=20 affected UAs and proxies associated with the dialog or standalone=20 transaction need to know the identities or addresses of the=20 appropriate charging entities. This document also proposes a=20 private SIP extension header P-Charging-Vector to pass correlation=20 information for charging purposes. The network entities in the 3GPP = architecture share correlation information to ensure that charging=20 activities are coordinated. The need applies for any SIP method=20 used to initiate a dialog, standalone messages and some response=20 messages. =20 =20 =20 =20 Henrikson Expires - November 2002 [Page 1]=20 =0C Private SIP Extension for Mobile Charging Information=20 May 2002=20 =20 =20 Table of Contents=20 =20 1. Background....................................................2=20 2. Discussion of Mechanism.......................................3=20 3. Applicability Statement.......................................3=20 4. Syntax........................................................3=20 5. Usage.........................................................4=20 5.1 Procedures at the UA......................................4=20 5.2 Procedures at the Proxy...................................5=20 5.3 Procedures at the Back to Back UA.........................5=20 5.4 Examples of Usage.........................................5=20 6. Security Considerations.......................................6=20 7. IANA Considerations...........................................6=20 8. Normative References..........................................7=20 9. Non-Normative References......................................7=20 Author's Addresses...............................................7=20 =20 1. Background =20 =20 3GPP has defined a distributed architecture that results in=20 multiple network entities becoming involved in providing access and = service. Operators need the ability and flexibility to charge for=20 the access and services as they see fit. This requires=20 coordination among the network entities, which includes correlating = charging records generated from different entities that are related = to the same session. There is a need to inform each network entity = involved about common charging functions to receive the generated=20 records.=20 =20 The solution provided by 3GPP is to define a two types of charging=20 functions: Charging Collection Function (CCF) and Event Charging=20 Function (ECF). CCF is used for off-line charging and ECF is used=20 for on-line charging. There may be a primary and secondary CCF and=20 ECF, for redundancy purposes. The CCF and ECF addresses may be=20 passed during the establishment of a dialog or standalone=20 transaction. The details are specified in the 3GPP documents, see=20 3GPP TS 32.200 [6].=20 =20 Additionally, a charging vector is defined that may be filled in=20 during the establishment of a dialog or standalone transaction. =20 The information inside the charging vector may be filled in by=20 multiple network entities and retrieved by multiple network=20 entities. There are three types of correlation information to be=20 passed: IMS Charging ID (ICID), Inter Operator Identifiers (IOI)=20 and access network charging information. ICID is a globally unique=20 value that may be used to correlate charging records. There may an=20 IOI generated from each side of the dialog to identify the network=20 associated with each side. The access network charging information=20 =20 =20 Henrikson Expires - November 2002 [Page 2]=20 =0C Private SIP Extension for Mobile Charging Information=20 May 2002=20 =20 =20 consists of network specific identifiers for the access level (e.g. = 3GPP radio access network or IEEE 802.11b). =20 =20 2. Discussion of Mechanism =20 =20 The provided mechanism uses private headers "P-Charging-Function- Addresses" and "P-Charging-Vector" in either the initial request or = subsequent response for a dialog or standalone transaction. Only=20 one instance of each header is allowed in a particular request or=20 response.=20 =20 The mechanisms by which an entity determines which values to=20 populate in the P-Charging-Function-Addresses and P-Charging-Vector = headers are specific to the local implementation and outside the=20 scope of this document. =20 =20 3. Applicability Statement =20 =20 The P-Charging-Function-Addresses and P-Charging-Vector headers are = applicable within a single network where coordination of charging=20 is required according to the architecture specified in 3GPP TS=20 32.100 [6]. The P-Charging-Vector header is also applicable=20 between networks.=20 =20 =20 4. Syntax =20 =20 All of the mechanisms specified in this document are described in=20 both prose and an augmented Backus-Naur Form (BNF) defined in RFC=20 2234 [2]. Further, the BNF definitions from RFC 3261 [1] are=20 inherited for the P-Charging-Function-Addresses header and are not=20 repeated here. Implementers need to need to be familiar with the=20 notation and content of RFC 3261 [2] and RFC 2234 [2] to understand = this document.=20 =20 The syntax for the P-Charging-Function-Addresses header is:=20 =20 P-Charging-Function-Addresses =3D =20 "P-Charging-Function-Addresses" HCOLON =20 ( "primary-ccf" EQUAL primary-ccf )=20 [COMMA "secondary-ccf" EQUAL secondary-ccf]=20 [COMMA "primary-ecf" EQUAL primary-ecf]=20 [COMMA "secondary-ecf" EQUAL secondary-ecf]=20 =20 primary-ccf =3D gen-value=20 =20 secondary-ccf =3D gen-value=20 =20 =20 =20 Henrikson Expires - November 2002 [Page 3]=20 =0C Private SIP Extension for Mobile Charging Information May 2002=20 =20 =20 primary-ecf =3D gen-value=20 =20 secondary-ecf =3D gen-value=20 =20 The syntax for the P-Charging-Vector header is:=20 =20 P-Charging-Vector =3D "P-Charging-Vector" HCOLON=20 ( "icid" EQUAL icid )=20 [COMMA "ioi-originating" EQUAL ioi-originating]=20 [COMMA "ioi-terminating" EQUAL ioi-terminating]=20 [COMMA "access-network-charging-info" EQUAL =20 access-network-charging-info]=20 =20 icid =3D gen-value=20 =20 ioi-originating =3D gen-value=20 =20 ioi-terminating =3D gen-value=20 =20 access-network-charging-info =3D gen-value=20 =20 The allowable usage of headers is described in Table 2 of SIP [1].=20 The following additions to this table are needed for the P- Charging-Function-Addresses and P-Charging-Vector headers.=20 =20 Addition of P-Charging-Function-Addresses and P-Charging-Vector to=20 SIP Table 2:=20 =20 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT = ------------------------------------------------------------------- = P-Charging-Function=20 -Addresses ard - o - o o o o o o=20 P-Charging-Vector ard - o - o o o o o o=20 =20 =20 5. Usage =20 =20 5.1 Procedures at the UA =20 =20 The UAC and UAS (originating and terminating UA) behave as usual.=20 They are not required to understand the P-Charging-Function- Addresses header, but may retrieve the information if received.=20 =20 The UAC and UAS (originating and terminating UA) behave as usual.=20 They are not required to understand the P-Charging-Vector header,=20 but may retrieve the information if received.=20 =20 =20 =20 Henrikson Expires - November 2002 [Page 4]=20 =0C Private SIP Extension for Mobile Charging Information=20 May 2002=20 =20 =20 5.2 Procedures at the Proxy =20 =20 The P-Charging-Function-Addresses and P-Charging-Vector headers are = treated like any other unknown header by intermediate proxies. =20 They simply forward it on towards the destination.=20 =20 If a proxy that supports this extension receives a request or=20 response without the P-Charging-Function-Addresses or P-Charging- Vector header, it may insert a P-Charging-Function-Addresses or P- Charging-Vector header prior to forwarding the message.=20 =20 If a proxy that supports this extension receives a request or=20 response with the P-Charging-Function-Addresses or P-Charging- Vector header, it may retrieve the information from the header to=20 use with application specific logic, i.e. charging. The proxy=20 should retain the P-Charging-Function-Addresses or P-Charging- Vector header in the outbound message. If the next hop for the=20 message is outside the closed network of the proxy, then the proxy=20 shall remove the P-Charging-Function-Addresses and P-Charging- Vector headers from the message. =20 =20 5.3 Procedures at the Back to Back UA =20 =20 If a B2BUA that understands the P-Charging-Function-Addresses=20 header or P-Charging-Vector header receives a request/response with = the P-Charging-Function-Addresses or P-Charging-Vector header, the=20 B2BUA should copy them from the receiving side UA to the sending=20 side UA. =20 =20 5.4 Examples of Usage =20 =20 We present example in the context of the scenario presented in the=20 Background section earlier in this document. The network diagram=20 is replicated below:=20 =20 Scenario=20 =20 =20 =20 UA1----P1-----P2-----UA2=20 =20 =20 =20 This example shows the message sequence for an INVITE transaction=20 originating from UA1 eventually arriving at UA2. P1 is an outbound=20 proxy for UA1. In this case P1 also inserts charging information.=20 P1 then routes the call via P2 to UA2.=20 =20 =20 =20 Henrikson Expires - November 2002 [Page 5]=20 =0C Private SIP Extension for Mobile Charging Information=20 May 2002=20 =20 =20 Message sequence for INVITE using P-Charging-Function-Addresses and = P-Charging-Vector:=20 =20 F1 INVITE UA1 -> P1=20 INVITE sip:joe SIP/2.0=20 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20 To: Joe =20 From: UA@HOMEDOMAIN ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 18 INVITE=20 Contact: =20 . . .=20 =20 F2 INVITE P1 -> P2=20 INVITE sip:joe SIP/2.0=20 Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20 To: Joe =20 From: UA@HOMEDOMAIN ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 18 INVITE=20 Contact: =20 P-Charging-Function-Addresses:=20 primary-ccf=3Dchoice1@HOMEDOMAIN,=20 secondary-ccf=3Dchoice2@HOMEDOMAIN=20 P-Charging-Vector:icid=3D1234bc9876e,=20 ioi-originating=3DACCESSDOMAIN=20 access-network-charging-info=3DNETWORK-DATA=20 . . .=20 =20 6. Security Considerations =20 =20 It is possible for proxies and B2BUAs within a closed network to=20 modify the value of P-Charging-Function-Addresses and P-Charging- Vector or to insert these headers into a request for a dialog, e.g. = INVITE request (or other request or response). It is also possible = for proxies on the INVITE path to execute many different attacks. =20 It is therefore critical to apply transitive mutual authentication=20 between entities in the closed network, using sips: or other=20 available mechanisms in order to prevent such attacks. =20 =20 7. IANA Considerations =20 =20 This document defines the SIP extension headers "P-Charging- Function-Addresses" and "P-Charging-Vector" which should be=20 included in the registry of SIP headers defined in SIP [1]. As=20 required by the SIP change process draft-tsvarea-sipchange [4] the=20 SIP extension header name "Charging-Function-Addresses" and=20 =20 =20 Henrikson Expires - November 2002 [Page 6]=20 =0C Private SIP Extension for Mobile Charging Information=20 May 2002=20 =20 =20 "Charging-Vector" should also be registered in association with=20 this extension.=20 =20 8. Normative References =20 =20 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,=20 Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session=20 Initiation Protocol, RFC 3261", March 2002.=20 =20 [2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax=20 specifications: ABNF," RFC 2234, Internet Engineering Task Force,=20 November 1997.=20 =20 9. Non-Normative References =20 =20 [3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia- sipping-3gpp-reqs-03.txt", March 2002.=20 =20 [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange",=20 March 2002.=20 =20 [5] 3GPP TS 32.200, Version 5, "Telecommunication Management;=20 Charging management; Charging principles".=20 =20 Author's Addresses =20 =20 Eric Henrikson=20 Lucent Technologies=20 11601 Willows Rd=20 Suite 100=20 Redmond, WA 98052=20 US=20 =20 Phone: +1 425 497 2442=20 EMail: ehenrikson@lucent.com=20 URI: http://www.lucent.com/=20 =20 =20 =20 =20 =20 =20 Henrikson Expires - November 2002 [Page 7]=20 =0C ------_=_NextPart_000_01C1F5E7.FA990F70-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 09:42:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06079 for ; Wed, 8 May 2002 09:42:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27992 for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:42:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26069; Wed, 8 May 2002 09:11:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26043 for ; Wed, 8 May 2002 09:11:05 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04659 for ; Wed, 8 May 2002 09:10:56 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g48DA0Y05406 for ; Wed, 8 May 2002 16:10:01 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 May 2002 16:11:03 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 8 May 2002 16:11:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Wed, 8 May 2002 16:11:02 +0300 Message-ID: Thread-Topic: WGLC for draft-willis-sip-path-05: Require:path needed? Thread-Index: AcH1944mM8TlXyXOSsKsfep6ee8gkAAc1vhAAAYg12AAARtQgA== To: , , Cc: X-OriginalArrivalTime: 08 May 2002 13:11:03.0137 (UTC) FILETIME=[CE16B510:01C1F691] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA26044 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Khartabil Hisham (NMP/Helsinki) > Sent: 08 May, 2002 14:39 > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com; > bpenfield@acmepacket.com > Cc: sip@ietf.org > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > needed? > > > > > > -----Original Message----- > > From: Honeisen Bernhard (NET/Helsinki) > > Sent: Wednesday, May 08, 2002 1:33 PM > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com > > Cc: sip@ietf.org > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > > needed? > > > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 07 May, 2002 21:47 > > > To: 'Bob Penfield' > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard > > > (NET/Helsinki) > > > Subject: RE: WGLC for draft-willis-sip-path-05: > Require:path needed? > > > > > > > > > Bob said: > > > > Maybe I am missing something, but how do we make sure the > > > > registrar can support the Path header? The UA probably does > > > > not care, but the intervening proxies probably need to know > > > > that the "Path" cannot honored by the registrar. I suppose > > > > the proxy could insert Require:path if it saw the > > > > Supported:path in the request. > > > > > > > > I think the spec should say that UAs that want to allow a > > > > Path to be inserted MUST add Supported:path to the REGISTER > > > > request and that a proxy MUST NOT add a Path header if > > > > Supported:path is not present. The proxy inserting a Path > > > > header SHOULD add Require:path to guarantee that the > > > > registrar supports Path. If the request is rejected with 420, > > > > the UA SHOULD resubmit without Supported:path. > > > > > > I think this works. It does have the side effect that a UA > > > that doesn't > > > know about Path can't be served by a proxy network that > > > requires it even > > > though there are no functional changes needed in the UA. > > > > Do we really want, that the proxies can just insert Paths without > > the consent of the user? This is related to the first item > > in the Security considerations section. > > As the Supported header field can be integrity protected, > > the registrar has means, to see, whether the UA really > > knows, what is going on with Path. > > > > Besides this, an implementation of the Path to the UA > > seams fairly easy. > > > > > > My proposal is similar as Bob's: > > > > The registrar ignores any Path header if the Supported:path > > is not present in that REGISTER request. > > > > A proxy, which inserts a Path header and really wants to stay > > on the route for incoming calls, inserts also a Require:path > > (if not yet present). > > > > The registrar decides then based on these two headers, what to do: > > > > - The Require:path has the normal meaning: > > -> send 420 response, if registrar does not understood path > > > > - If Supported:path is present in the REGISTER request > > --> use path as described in the I/D. > > > > - If Supported:path is _not_ present in the REGISTER request > > --> _ignore_ any Path, > > regardless of any possible Require:path present > > > > > > The only problem I see lasting is, that proxies could prevent > > a user from registering by just inserting a Require:path. > > This looks like a more general problem as this can be > > done with any option tag. > > > > Solution: > > > > -> after a 420 the UA tries to send the request without > > Supported:path. > > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > > was present in the request. > > > > Are you suggesting that a proxy must remember requests that > it processed earlier? No, not at all. Why do you think it has to remember? > First you mention that a proxy can insert a path-header > without a supported-header (or that is what it sounded like > at least). If it does, the registrar will ignore any Path header, as no Supported:path is present in the REGISTER request in question. Such behaviour would allow easier implementation of proxies. (But I don't argue, if people think it's better, if proxies must not insert any Path stuff, if there is no Supported header in the REGISTER request in question.) My proposal is just, that the proxy just MUST NOT insert any Require:path, if Supported:path was not present. > Then you say that if a 420 is returned to TU, a TU ??? > proxy can't insert a path-header in the newly generated > request unless a Supported:path is present. The proxy makes its decision on whether to insert a Require:path based on the presence of the Supported:path . > I vote for the supported header to be there from the first > REGISTER sent. What do you mean here? Do you mean, Supported:path present in first REGISTER attempt, or do you mean Supported:path present in every REGISTER request? cheers, Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 11:09:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11252 for ; Wed, 8 May 2002 11:09:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04434 for sip-archive@odin.ietf.org; Wed, 8 May 2002 11:09:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02027; Wed, 8 May 2002 10:43:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01931 for ; Wed, 8 May 2002 10:43:42 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09720 for ; Wed, 8 May 2002 10:43:32 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g48Ei2k23766 for ; Wed, 8 May 2002 17:44:02 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 May 2002 17:43:34 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 8 May 2002 17:43:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Wed, 8 May 2002 17:43:39 +0300 Message-ID: Thread-Topic: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Thread-Index: AcH2nPq53FaSMKJ0RyK0CwgrQfVT5AAAPtTw To: , , Cc: X-OriginalArrivalTime: 08 May 2002 14:43:40.0345 (UTC) FILETIME=[BE715A90:01C1F69E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA01932 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Bob! Fair summary. However, I have a slighly different proposal. Comments inline cheers, Bernie > -----Original Message----- > From: ext Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: 08 May, 2002 17:28 > To: Honeisen Bernhard (NET/Helsinki); Khartabil Hisham (NMP/Helsinki); > dean.willis@softarmor.com > Cc: sip@ietf.org > Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > needed? > > > I think I agree with Bernie's proposal, but let me summarize > the normative > stuff for clarity. > > 1) A UA that is willing to have Path headers inserted by intervening > elements(proxies) MUST include Supported:path in the REGISTER request. > > 2) An intervening element MUST NOT add a Path header if > Supported:path is > not present. What about: 2) An intervening element MUST NOT add a Require:path header and SHOULD NOT add a Path header if Supported:path is not present. > 3) An intervening element that adds a Path (only when > Supported:path is > present) SHOULD insert Require:path (if it is not already present) to > guarantee that registrar supports 'path'. What about: 3) An intervening element that adds a Path only when Supported:path is present) MAY insert Require:path (if it is not already present) to guarantee that registrar supports 'path'. > 4) A registrar that receives a request with Path headers but does not > include Supported:path MUST ignore the Path headers. If the registrar > generated an error response in this case, there would be no > way for the UA > to successfully register assuming that element that illegally > added the Path > header would do it on every REGISTER attempt. > > 5) If a UA gets a 420 response to the REGISTER request with > Unsupported:path, then it SHOULD re-submit the REGISTER without > Supported:path. This will prevent any intervening element > from adding a path > or a Require:path (given rule 2) allowing the request to succeed at a > registrar that does not support 'path'. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: > To: ; ; > > Cc: > Sent: Wednesday, May 08, 2002 9:11 AM > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > needed? > > > > > > -----Original Message----- > > From: Khartabil Hisham (NMP/Helsinki) > > Sent: 08 May, 2002 14:39 > > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com; > > bpenfield@acmepacket.com > > Cc: sip@ietf.org > > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: > Require:path > > needed? > > > > > > > > > > > -----Original Message----- > > > From: Honeisen Bernhard (NET/Helsinki) > > > Sent: Wednesday, May 08, 2002 1:33 PM > > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com > > > Cc: sip@ietf.org > > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > > > needed? > > > > > > > > > > -----Original Message----- > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: 07 May, 2002 21:47 > > > > To: 'Bob Penfield' > > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; > Honeisen Bernhard > > > > (NET/Helsinki) > > > > Subject: RE: WGLC for draft-willis-sip-path-05: > > Require:path needed? > > > > > > > > > > > > Bob said: > > > > > Maybe I am missing something, but how do we make sure the > > > > > registrar can support the Path header? The UA probably does > > > > > not care, but the intervening proxies probably need to know > > > > > that the "Path" cannot honored by the registrar. I suppose > > > > > the proxy could insert Require:path if it saw the > > > > > Supported:path in the request. > > > > > > > > > > I think the spec should say that UAs that want to allow a > > > > > Path to be inserted MUST add Supported:path to the REGISTER > > > > > request and that a proxy MUST NOT add a Path header if > > > > > Supported:path is not present. The proxy inserting a Path > > > > > header SHOULD add Require:path to guarantee that the > > > > > registrar supports Path. If the request is rejected with 420, > > > > > the UA SHOULD resubmit without Supported:path. > > > > > > > > I think this works. It does have the side effect that a UA > > > > that doesn't > > > > know about Path can't be served by a proxy network that > > > > requires it even > > > > though there are no functional changes needed in the UA. > > > > > > Do we really want, that the proxies can just insert Paths without > > > the consent of the user? This is related to the first item > > > in the Security considerations section. > > > As the Supported header field can be integrity protected, > > > the registrar has means, to see, whether the UA really > > > knows, what is going on with Path. > > > > > > Besides this, an implementation of the Path to the UA > > > seams fairly easy. > > > > > > > > > My proposal is similar as Bob's: > > > > > > The registrar ignores any Path header if the Supported:path > > > is not present in that REGISTER request. > > > > > > A proxy, which inserts a Path header and really wants to stay > > > on the route for incoming calls, inserts also a Require:path > > > (if not yet present). > > > > > > The registrar decides then based on these two headers, what to do: > > > > > > - The Require:path has the normal meaning: > > > -> send 420 response, if registrar does not understood path > > > > > > - If Supported:path is present in the REGISTER request > > > --> use path as described in the I/D. > > > > > > - If Supported:path is _not_ present in the REGISTER request > > > --> _ignore_ any Path, > > > regardless of any possible Require:path present > > > > > > > > > The only problem I see lasting is, that proxies could prevent > > > a user from registering by just inserting a Require:path. > > > This looks like a more general problem as this can be > > > done with any option tag. > > > > > > Solution: > > > > > > -> after a 420 the UA tries to send the request without > > > Supported:path. > > > > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > > > was present in the request. > > > > > > > > Are you suggesting that a proxy must remember requests that > > it processed earlier? > > No, not at all. Why do you think it has to remember? > > > First you mention that a proxy can insert a path-header > > without a supported-header (or that is what it sounded like > > at least). > > If it does, the registrar will ignore any Path header, as > no Supported:path is present in the REGISTER request in > question. Such behaviour would allow easier implementation > of proxies. (But I don't argue, if people think it's better, > if proxies must not insert any Path stuff, if there is > no Supported header in the REGISTER request in question.) > My proposal is just, that the proxy just MUST NOT insert > any Require:path, if Supported:path was not present. > > > Then you say that if a 420 is returned to TU, a > > TU ??? > > > proxy can't insert a path-header in the newly generated > > request unless a Supported:path is present. > > The proxy makes its decision on whether to insert a > Require:path based on the presence of the Supported:path . > > > I vote for the supported header to be there from the first > > REGISTER sent. > > What do you mean here? > Do you mean, Supported:path present in first REGISTER attempt, > or do you mean Supported:path present in every REGISTER request? > > cheers, > Bernie > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 11:24:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12332 for ; Wed, 8 May 2002 11:24:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05898 for sip-archive@odin.ietf.org; Wed, 8 May 2002 11:24:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00837; Wed, 8 May 2002 10:31:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00795 for ; Wed, 8 May 2002 10:30:56 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09130 for ; Wed, 8 May 2002 10:30:47 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A69FF76C00D8; Wed, 08 May 2002 10:30:55 -0400 Message-ID: <004701c1f69c$8039fea0$2300000a@acmepacket.com> From: "Bob Penfield" To: , , Cc: References: Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Wed, 8 May 2002 10:27:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think I agree with Bernie's proposal, but let me summarize the normative stuff for clarity. 1) A UA that is willing to have Path headers inserted by intervening elements(proxies) MUST include Supported:path in the REGISTER request. 2) An intervening element MUST NOT add a Path header if Supported:path is not present. 3) An intervening element that adds a Path (only when Supported:path is present) SHOULD insert Require:path (if it is not already present) to guarantee that registrar supports 'path'. 4) A registrar that receives a request with Path headers but does not include Supported:path MUST ignore the Path headers. If the registrar generated an error response in this case, there would be no way for the UA to successfully register assuming that element that illegally added the Path header would do it on every REGISTER attempt. 5) If a UA gets a 420 response to the REGISTER request with Unsupported:path, then it SHOULD re-submit the REGISTER without Supported:path. This will prevent any intervening element from adding a path or a Require:path (given rule 2) allowing the request to succeed at a registrar that does not support 'path'. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: To: ; ; Cc: Sent: Wednesday, May 08, 2002 9:11 AM Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? > -----Original Message----- > From: Khartabil Hisham (NMP/Helsinki) > Sent: 08 May, 2002 14:39 > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com; > bpenfield@acmepacket.com > Cc: sip@ietf.org > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > needed? > > > > > > -----Original Message----- > > From: Honeisen Bernhard (NET/Helsinki) > > Sent: Wednesday, May 08, 2002 1:33 PM > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com > > Cc: sip@ietf.org > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > > needed? > > > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 07 May, 2002 21:47 > > > To: 'Bob Penfield' > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard > > > (NET/Helsinki) > > > Subject: RE: WGLC for draft-willis-sip-path-05: > Require:path needed? > > > > > > > > > Bob said: > > > > Maybe I am missing something, but how do we make sure the > > > > registrar can support the Path header? The UA probably does > > > > not care, but the intervening proxies probably need to know > > > > that the "Path" cannot honored by the registrar. I suppose > > > > the proxy could insert Require:path if it saw the > > > > Supported:path in the request. > > > > > > > > I think the spec should say that UAs that want to allow a > > > > Path to be inserted MUST add Supported:path to the REGISTER > > > > request and that a proxy MUST NOT add a Path header if > > > > Supported:path is not present. The proxy inserting a Path > > > > header SHOULD add Require:path to guarantee that the > > > > registrar supports Path. If the request is rejected with 420, > > > > the UA SHOULD resubmit without Supported:path. > > > > > > I think this works. It does have the side effect that a UA > > > that doesn't > > > know about Path can't be served by a proxy network that > > > requires it even > > > though there are no functional changes needed in the UA. > > > > Do we really want, that the proxies can just insert Paths without > > the consent of the user? This is related to the first item > > in the Security considerations section. > > As the Supported header field can be integrity protected, > > the registrar has means, to see, whether the UA really > > knows, what is going on with Path. > > > > Besides this, an implementation of the Path to the UA > > seams fairly easy. > > > > > > My proposal is similar as Bob's: > > > > The registrar ignores any Path header if the Supported:path > > is not present in that REGISTER request. > > > > A proxy, which inserts a Path header and really wants to stay > > on the route for incoming calls, inserts also a Require:path > > (if not yet present). > > > > The registrar decides then based on these two headers, what to do: > > > > - The Require:path has the normal meaning: > > -> send 420 response, if registrar does not understood path > > > > - If Supported:path is present in the REGISTER request > > --> use path as described in the I/D. > > > > - If Supported:path is _not_ present in the REGISTER request > > --> _ignore_ any Path, > > regardless of any possible Require:path present > > > > > > The only problem I see lasting is, that proxies could prevent > > a user from registering by just inserting a Require:path. > > This looks like a more general problem as this can be > > done with any option tag. > > > > Solution: > > > > -> after a 420 the UA tries to send the request without > > Supported:path. > > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > > was present in the request. > > > > Are you suggesting that a proxy must remember requests that > it processed earlier? No, not at all. Why do you think it has to remember? > First you mention that a proxy can insert a path-header > without a supported-header (or that is what it sounded like > at least). If it does, the registrar will ignore any Path header, as no Supported:path is present in the REGISTER request in question. Such behaviour would allow easier implementation of proxies. (But I don't argue, if people think it's better, if proxies must not insert any Path stuff, if there is no Supported header in the REGISTER request in question.) My proposal is just, that the proxy just MUST NOT insert any Require:path, if Supported:path was not present. > Then you say that if a 420 is returned to TU, a TU ??? > proxy can't insert a path-header in the newly generated > request unless a Supported:path is present. The proxy makes its decision on whether to insert a Require:path based on the presence of the Supported:path . > I vote for the supported header to be there from the first > REGISTER sent. What do you mean here? Do you mean, Supported:path present in first REGISTER attempt, or do you mean Supported:path present in every REGISTER request? cheers, Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 12:04:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14465 for ; Wed, 8 May 2002 12:04:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10515 for sip-archive@odin.ietf.org; Wed, 8 May 2002 12:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05865; Wed, 8 May 2002 11:23:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05834 for ; Wed, 8 May 2002 11:23:44 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12289 for ; Wed, 8 May 2002 11:23:37 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A2FFAC070110; Wed, 08 May 2002 11:23:43 -0400 Message-ID: <007b01c1f6a3$e0667e00$2300000a@acmepacket.com> From: "Bob Penfield" To: , , Cc: References: Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Wed, 8 May 2002 11:20:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > ----- Original Message ----- > From: > > > -----Original Message----- > > From: ext Bob Penfield [mailto:bpenfield@acmepacket.com] > > > 2) An intervening element MUST NOT add a Path header if > > Supported:path is > > not present. > > What about: > 2) An intervening element MUST NOT add a Require:path header and SHOULD > NOT add a Path header if Supported:path is not present. Given rule 4, any Path header inserted by the proxy will be ignored by the registrar. I see no reason to make this a SHOULD NOT instead of a MUST NOT. It all goes back to the "knowledge and consent of the user" requirements. > > > 3) An intervening element that adds a Path (only when > > Supported:path is > > present) SHOULD insert Require:path (if it is not already present) to > > guarantee that registrar supports 'path'. > > What about: > 3) An intervening element that adds a Path only when Supported:path > is present) MAY insert Require:path (if it is not already present) to > guarantee that registrar supports 'path'. The only reason you would not include it is if you were sure that the registrar supported it or you did not care. For an implementation requirement, I think SHOULD is appropriate. Certainly an implementation can have a configuration option to prevent the addition of Require:path. Maybe you could include a recommendation that it be configurable. > > > 4) A registrar that receives a request with Path headers but does not > > include Supported:path MUST ignore the Path headers. If the registrar > > generated an error response in this case, there would be no > > way for the UA > > to successfully register assuming that element that illegally > > added the Path > > header would do it on every REGISTER attempt. > > > > 5) If a UA gets a 420 response to the REGISTER request with > > Unsupported:path, then it SHOULD re-submit the REGISTER without > > Supported:path. This will prevent any intervening element > > from adding a path > > or a Require:path (given rule 2) allowing the request to succeed at a > > registrar that does not support 'path'. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 12:44:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16070 for ; Wed, 8 May 2002 12:44:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13422 for sip-archive@odin.ietf.org; Wed, 8 May 2002 12:44:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08750; Wed, 8 May 2002 11:53:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08723 for ; Wed, 8 May 2002 11:53:38 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14138 for ; Wed, 8 May 2002 11:53:30 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g48FquP00910 for ; Wed, 8 May 2002 11:52:56 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA26208; Wed, 8 May 2002 10:52:55 -0500 (CDT) Message-ID: <3CD949D5.7080907@lucent.com> Date: Wed, 08 May 2002 10:52:53 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP LIST Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Repost: Timer C, Timer B and Spiraling Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Since most people were busy with the interim SIP WG meeting, I did not hear from anyone on the list, I will send this out again... Some comments on -09bis on Timers C, B, and spiraling: 1) In SIP, proxies can fork either in serial or in parallel. Consider serial forking for this discussion. Normally, in the presence of multiple Contact headers to an address-of-record, a proxy will sort the Contacts based on their q value and fork serially to each Contact. If Contact 1 did not elicit a final response within a certain time, Contact 2 will be tried, and so on. Problem is, what exactly is the time for a proxy to give up on the current Contact and try the next one? Reading -09bis, it appears that timer C can serve this function. But the initial value of timer C is too high (3 minutes, and it is a MUST to set it to at least 3 mins), so that will not work. Another possible candidate is the transaction timeout; if a proxy allows a client transaction to continue (T1*64 seconds = 32 seconds) until it times out, the time between trying the next Contact (32 seconds) is too large for the caller to keep holding. So, this does not work either. Should -09bis provide some guidance on timers to use in proxy cores if serial forking is being used and > 1 Contact header is present, or should this be left upto the implementer? 2) Timer B controls transaction timeouts in INVITE client trans- actions. The state diagram in Figure 5 is silent on what to do if Timer B fires while control is in "Proceeding" state; i.e. received a 180, but no final response. The correct behavior should be to sent a CANCEL and enter "Terminated" state. 3) Regarding finding the spiraled R-R on responses in order to modify it (section 16.7, step 8), won't it be the case that the first R-R in a response corresponds to the inner-most spiral? Since the inner-most spiral will generate the first response, can't we just get the first R-R header on a response in order to modify it? If I mis-represented something and the solution is in -09bis, please let me know. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 12:55:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16338 for ; Wed, 8 May 2002 12:55:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14241 for sip-archive@odin.ietf.org; Wed, 8 May 2002 12:55:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11685; Wed, 8 May 2002 12:16:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11654 for ; Wed, 8 May 2002 12:16:26 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15160 for ; Wed, 8 May 2002 12:16:18 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g48GFod29654; Wed, 8 May 2002 11:15:50 -0500 From: "Dean Willis" To: "'Bob Penfield'" , , Cc: Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Wed, 8 May 2002 11:15:40 -0500 Message-ID: <005201c1f6ab$99ab5eb0$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <004701c1f69c$8039fea0$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The only problem with this is that there may well be proxies that know that if Path isn't used, then registering through that proxy will fail. It seems that these proxies legitimately REQUIRE the Path extension, since if it is not supported, they will not function. So if a UA tries to register without Supported:path through such a proxy, we need to be able to reject it. -- Dean > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Wednesday, May 08, 2002 9:28 AM > To: bernhard.honeisen@nokia.com; hisham.khartabil@nokia.com; > dean.willis@softarmor.com > Cc: sip@ietf.org > Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: > Require:path needed? > > > I think I agree with Bernie's proposal, but let me summarize > the normative stuff for clarity. > > 1) A UA that is willing to have Path headers inserted by intervening > elements(proxies) MUST include Supported:path in the REGISTER request. > > 2) An intervening element MUST NOT add a Path header if > Supported:path is not present. > > 3) An intervening element that adds a Path (only when > Supported:path is > present) SHOULD insert Require:path (if it is not already > present) to guarantee that registrar supports 'path'. > > 4) A registrar that receives a request with Path headers but > does not include Supported:path MUST ignore the Path headers. > If the registrar generated an error response in this case, > there would be no way for the UA to successfully register > assuming that element that illegally added the Path header > would do it on every REGISTER attempt. > > 5) If a UA gets a 420 response to the REGISTER request with > Unsupported:path, then it SHOULD re-submit the REGISTER > without Supported:path. This will prevent any intervening > element from adding a path or a Require:path (given rule 2) > allowing the request to succeed at a registrar that does not > support 'path'. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: > To: ; > ; > Cc: > Sent: Wednesday, May 08, 2002 9:11 AM > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: > Require:path needed? > > > > > > -----Original Message----- > > From: Khartabil Hisham (NMP/Helsinki) > > Sent: 08 May, 2002 14:39 > > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com; > > bpenfield@acmepacket.com > > Cc: sip@ietf.org > > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: > Require:path > > needed? > > > > > > > > > > > -----Original Message----- > > > From: Honeisen Bernhard (NET/Helsinki) > > > Sent: Wednesday, May 08, 2002 1:33 PM > > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com > > > Cc: sip@ietf.org > > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: > Require:path > > > needed? > > > > > > > > > > -----Original Message----- > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: 07 May, 2002 21:47 > > > > To: 'Bob Penfield' > > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; > Honeisen Bernhard > > > > (NET/Helsinki) > > > > Subject: RE: WGLC for draft-willis-sip-path-05: > > Require:path needed? > > > > > > > > > > > > Bob said: > > > > > Maybe I am missing something, but how do we make sure the > > > > > registrar can support the Path header? The UA > probably does not > > > > > care, but the intervening proxies probably need to > know that the > > > > > "Path" cannot honored by the registrar. I suppose the proxy > > > > > could insert Require:path if it saw the Supported:path in the > > > > > request. > > > > > > > > > > I think the spec should say that UAs that want to > allow a Path > > > > > to be inserted MUST add Supported:path to the > REGISTER request > > > > > and that a proxy MUST NOT add a Path header if > Supported:path is > > > > > not present. The proxy inserting a Path header SHOULD add > > > > > Require:path to guarantee that the registrar supports > Path. If > > > > > the request is rejected with 420, the UA SHOULD > resubmit without > > > > > Supported:path. > > > > > > > > I think this works. It does have the side effect that a UA that > > > > doesn't know about Path can't be served by a proxy network that > > > > requires it even > > > > though there are no functional changes needed in the UA. > > > > > > Do we really want, that the proxies can just insert Paths without > > > the consent of the user? This is related to the first item in the > > > Security considerations section. As the Supported header > field can > > > be integrity protected, the registrar has means, to see, > whether the > > > UA really knows, what is going on with Path. > > > > > > Besides this, an implementation of the Path to the UA > > > seams fairly easy. > > > > > > > > > My proposal is similar as Bob's: > > > > > > The registrar ignores any Path header if the > Supported:path is not > > > present in that REGISTER request. > > > > > > A proxy, which inserts a Path header and really wants to > stay on the > > > route for incoming calls, inserts also a Require:path (if not yet > > > present). > > > > > > The registrar decides then based on these two headers, what to do: > > > > > > - The Require:path has the normal meaning: > > > -> send 420 response, if registrar does not understood path > > > > > > - If Supported:path is present in the REGISTER request > > > --> use path as described in the I/D. > > > > > > - If Supported:path is _not_ present in the REGISTER request > > > --> _ignore_ any Path, > > > regardless of any possible Require:path present > > > > > > > > > The only problem I see lasting is, that proxies could > prevent a user > > > from registering by just inserting a Require:path. This > looks like a > > > more general problem as this can be done with any option tag. > > > > > > Solution: > > > > > > -> after a 420 the UA tries to send the request without > > > Supported:path. > > > > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > > > was present in the request. > > > > > > > > Are you suggesting that a proxy must remember requests that it > > processed earlier? > > No, not at all. Why do you think it has to remember? > > > First you mention that a proxy can insert a path-header without a > > supported-header (or that is what it sounded like at least). > > If it does, the registrar will ignore any Path header, as > no Supported:path is present in the REGISTER request in > question. Such behaviour would allow easier implementation of > proxies. (But I don't argue, if people think it's better, if > proxies must not insert any Path stuff, if there is no > Supported header in the REGISTER request in question.) My > proposal is just, that the proxy just MUST NOT insert any > Require:path, if Supported:path was not present. > > > Then you say that if a 420 is returned to TU, a > > TU ??? > > > proxy can't insert a path-header in the newly generated > request unless > > a Supported:path is present. > > The proxy makes its decision on whether to insert a > Require:path based on the presence of the Supported:path . > > > I vote for the supported header to be there from the first REGISTER > > sent. > > What do you mean here? > Do you mean, Supported:path present in first REGISTER > attempt, or do you mean Supported:path present in every > REGISTER request? > > cheers, > Bernie > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 13:05:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16606 for ; Wed, 8 May 2002 13:05:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15163 for sip-archive@odin.ietf.org; Wed, 8 May 2002 13:05:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10649; Wed, 8 May 2002 12:06:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10618 for ; Wed, 8 May 2002 12:06:47 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14571 for ; Wed, 8 May 2002 12:06:39 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g48G6Cd29576; Wed, 8 May 2002 11:06:12 -0500 From: "Dean Willis" To: , Cc: Date: Wed, 8 May 2002 11:06:00 -0500 Message-ID: <003601c1f6aa$40baed30$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > My proposal is similar as Bob's: > > The registrar ignores any Path header if the Supported:path > is not present in that REGISTER request. > > A proxy, which inserts a Path header and really wants to stay > on the route for incoming calls, inserts also a Require:path > (if not yet present). > > The registrar decides then based on these two headers, what to do: > > - The Require:path has the normal meaning: > -> send 420 response, if registrar does not understood path > > - If Supported:path is present in the REGISTER request > --> use path as described in the I/D. > > - If Supported:path is _not_ present in the REGISTER request > --> _ignore_ any Path, > regardless of any possible Require:path present > > > The only problem I see lasting is, that proxies could prevent > a user from registering by just inserting a Require:path. > This looks like a more general problem as this can be > done with any option tag. > > Solution: > > -> after a 420 the UA tries to send the request without > Supported:path. > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > was present in the request. > > > Comments? > > cheers, > Bernie > I believe this works. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 13:45:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18255 for ; Wed, 8 May 2002 13:45:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17635 for sip-archive@odin.ietf.org; Wed, 8 May 2002 13:46:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15151; Wed, 8 May 2002 13:05:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15119 for ; Wed, 8 May 2002 13:05:07 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16597 for ; Wed, 8 May 2002 13:04:55 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 May 2002 12:04:27 -0500 Message-ID: Thread-Topic: Question regarding draft-ietf-sip-cc-transfer-05 thread-index: AcH2smcK2WEwQgilQnKOWwcp54sJAA== From: "Chiou, Mark" To: Cc: , "Sridhar Kuppanna" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15120 Subject: [Sip] Question regarding draft-ietf-sip-cc-transfer-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, This is a question regarding Call transfer successful scenario. In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back. In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." The questions are : 1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources. 2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.) 3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee." By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session. Regards, Mark Chiou _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 14:36:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19831 for ; Wed, 8 May 2002 14:36:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20554 for sip-archive@odin.ietf.org; Wed, 8 May 2002 14:36:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19057; Wed, 8 May 2002 14:08:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19028 for ; Wed, 8 May 2002 14:08:34 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19155 for ; Wed, 8 May 2002 14:08:25 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A99DF89A0110; Wed, 08 May 2002 14:08:29 -0400 Message-ID: <003901c1f6ba$e1c33060$2300000a@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" , , Cc: References: <005201c1f6ab$99ab5eb0$4a010114@TXDWILLIS2> Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Wed, 8 May 2002 14:05:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dean Willis" > > The only problem with this is that there may well be proxies that know > that if Path isn't used, then registering through that proxy will fail. > It seems that these proxies legitimately REQUIRE the Path extension, > since if it is not supported, they will not function. > > So if a UA tries to register without Supported:path through such a > proxy, we need to be able to reject it. Absolutely. Rule #2 does not require the proxy to pass on the request. But it should be modified to say that the proxy can reject the request with 421 and Require:path if it instists on being in the path. > -- > Dean > > > -----Original Message----- > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Sent: Wednesday, May 08, 2002 9:28 AM > > To: bernhard.honeisen@nokia.com; hisham.khartabil@nokia.com; > > dean.willis@softarmor.com > > Cc: sip@ietf.org > > Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: > > Require:path needed? > > > > > > I think I agree with Bernie's proposal, but let me summarize > > the normative stuff for clarity. > > > > 1) A UA that is willing to have Path headers inserted by intervening > > elements(proxies) MUST include Supported:path in the REGISTER request. > > > > 2) An intervening element MUST NOT add a Path header if > > Supported:path is not present. > > > > 3) An intervening element that adds a Path (only when > > Supported:path is > > present) SHOULD insert Require:path (if it is not already > > present) to guarantee that registrar supports 'path'. > > > > 4) A registrar that receives a request with Path headers but > > does not include Supported:path MUST ignore the Path headers. > > If the registrar generated an error response in this case, > > there would be no way for the UA to successfully register > > assuming that element that illegally added the Path header > > would do it on every REGISTER attempt. > > > > 5) If a UA gets a 420 response to the REGISTER request with > > Unsupported:path, then it SHOULD re-submit the REGISTER > > without Supported:path. This will prevent any intervening > > element from adding a path or a Require:path (given rule 2) > > allowing the request to succeed at a registrar that does not > > support 'path'. > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > ----- Original Message ----- > > From: > > To: ; > > ; > > Cc: > > Sent: Wednesday, May 08, 2002 9:11 AM > > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: > > Require:path needed? > > > > > > > > > > > -----Original Message----- > > > From: Khartabil Hisham (NMP/Helsinki) > > > Sent: 08 May, 2002 14:39 > > > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com; > > > bpenfield@acmepacket.com > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: > > Require:path > > > needed? > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Honeisen Bernhard (NET/Helsinki) > > > > Sent: Wednesday, May 08, 2002 1:33 PM > > > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com > > > > Cc: sip@ietf.org > > > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: > > Require:path > > > > needed? > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: 07 May, 2002 21:47 > > > > > To: 'Bob Penfield' > > > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; > > Honeisen Bernhard > > > > > (NET/Helsinki) > > > > > Subject: RE: WGLC for draft-willis-sip-path-05: > > > Require:path needed? > > > > > > > > > > > > > > > Bob said: > > > > > > Maybe I am missing something, but how do we make sure the > > > > > > registrar can support the Path header? The UA > > probably does not > > > > > > care, but the intervening proxies probably need to > > know that the > > > > > > "Path" cannot honored by the registrar. I suppose the proxy > > > > > > could insert Require:path if it saw the Supported:path in the > > > > > > request. > > > > > > > > > > > > I think the spec should say that UAs that want to > > allow a Path > > > > > > to be inserted MUST add Supported:path to the > > REGISTER request > > > > > > and that a proxy MUST NOT add a Path header if > > Supported:path is > > > > > > not present. The proxy inserting a Path header SHOULD add > > > > > > Require:path to guarantee that the registrar supports > > Path. If > > > > > > the request is rejected with 420, the UA SHOULD > > resubmit without > > > > > > Supported:path. > > > > > > > > > > I think this works. It does have the side effect that a UA that > > > > > doesn't know about Path can't be served by a proxy network that > > > > > requires it even > > > > > though there are no functional changes needed in the UA. > > > > > > > > Do we really want, that the proxies can just insert Paths without > > > > the consent of the user? This is related to the first item in the > > > > Security considerations section. As the Supported header > > field can > > > > be integrity protected, the registrar has means, to see, > > whether the > > > > UA really knows, what is going on with Path. > > > > > > > > Besides this, an implementation of the Path to the UA > > > > seams fairly easy. > > > > > > > > > > > > My proposal is similar as Bob's: > > > > > > > > The registrar ignores any Path header if the > > Supported:path is not > > > > present in that REGISTER request. > > > > > > > > A proxy, which inserts a Path header and really wants to > > stay on the > > > > route for incoming calls, inserts also a Require:path (if not yet > > > > present). > > > > > > > > The registrar decides then based on these two headers, what to do: > > > > > > > > - The Require:path has the normal meaning: > > > > -> send 420 response, if registrar does not understood path > > > > > > > > - If Supported:path is present in the REGISTER request > > > > --> use path as described in the I/D. > > > > > > > > - If Supported:path is _not_ present in the REGISTER request > > > > --> _ignore_ any Path, > > > > regardless of any possible Require:path present > > > > > > > > > > > > The only problem I see lasting is, that proxies could > > prevent a user > > > > from registering by just inserting a Require:path. This > > looks like a > > > > more general problem as this can be done with any option tag. > > > > > > > > Solution: > > > > > > > > -> after a 420 the UA tries to send the request without > > > > Supported:path. > > > > > > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > > > > was present in the request. > > > > > > > > > > > > Are you suggesting that a proxy must remember requests that it > > > processed earlier? > > > > No, not at all. Why do you think it has to remember? > > > > > First you mention that a proxy can insert a path-header without a > > > supported-header (or that is what it sounded like at least). > > > > If it does, the registrar will ignore any Path header, as > > no Supported:path is present in the REGISTER request in > > question. Such behaviour would allow easier implementation of > > proxies. (But I don't argue, if people think it's better, if > > proxies must not insert any Path stuff, if there is no > > Supported header in the REGISTER request in question.) My > > proposal is just, that the proxy just MUST NOT insert any > > Require:path, if Supported:path was not present. > > > > > Then you say that if a 420 is returned to TU, a > > > > TU ??? > > > > > proxy can't insert a path-header in the newly generated > > request unless > > > a Supported:path is present. > > > > The proxy makes its decision on whether to insert a > > Require:path based on the presence of the Supported:path . > > > > > I vote for the supported header to be there from the first REGISTER > > > sent. > > > > What do you mean here? > > Do you mean, Supported:path present in first REGISTER > > attempt, or do you mean Supported:path present in every > > REGISTER request? > > > > cheers, > > Bernie > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 8 21:13:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27795 for ; Wed, 8 May 2002 21:13:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10148 for sip-archive@odin.ietf.org; Wed, 8 May 2002 21:13:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07709; Wed, 8 May 2002 20:25:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07683 for ; Wed, 8 May 2002 20:25:32 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27043; Wed, 8 May 2002 20:25:22 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g490Oxd32314; Wed, 8 May 2002 19:24:59 -0500 From: "Dean Willis" To: Cc: Date: Wed, 8 May 2002 19:24:43 -0500 Message-ID: <002601c1f6ef$ebb0be50$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Notes from SIP Working Group Interim Meeting, May 6-7, 2002 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've posted the various notes I received at: http://www.softarmor.com/sipwg/meets/interim-may-02/notes/ If you want your slides posted, please send them to me. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 07:33:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16004 for ; Thu, 9 May 2002 07:33:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19234 for sip-archive@odin.ietf.org; Thu, 9 May 2002 07:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18098; Thu, 9 May 2002 07:14:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18071 for ; Thu, 9 May 2002 07:14:42 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15785 for ; Thu, 9 May 2002 07:14:33 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g49BEaA26197 for ; Thu, 9 May 2002 07:14:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 12:14:35 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB004FE92C8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Dean Willis , jh@lohi.eng.song.fi Cc: sip@ietf.org, "'3GPP_TSG_CN_WG1'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, bernhard.honeisen@nokia.com, "'Rohan Mahy'" , brian.rosen@marconi.com, jo@ipdialog.com Subject: RE: [Sip] WGLC for draft-willis-sip-path-05 Date: Thu, 9 May 2002 12:14:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I not not sure that deletion solves the problem. We still need to retain text that the usage of this information from the REGISTER response in the UA is outside the scope of the specification. Or is that recorded somewhere else? Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 07 May 2002 18:39 > To: jh@lohi.eng.song.fi > Cc: sip@ietf.org; '3GPP_TSG_CN_WG1'; > bernhard.honeisen@nokia.com; 'Rohan > Mahy'; brian.rosen@marconi.com; jo@ipdialog.com > Subject: RE: [Sip] WGLC for draft-willis-sip-path-05 > > > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of jh@lohi.eng.song.fi > > Sent: Monday, May 06, 2002 3:06 AM > > To: Dean Willis > > Cc: sip@ietf.org; 3GPP_TSG_CN_WG1; > > bernhard.honeisen@nokia.com; Rohan Mahy; > > brian.rosen@marconi.com; jo@ipdialog.com > > Subject: [Sip] WGLC for draft-willis-sip-path-05 > > > > > > below are my comments: > > > > - i thought that it was agreed to use name rrr instead of > > path for this > > header. the reason is that this header is both semantically and > > syntactically very close to record-route. also, name > path is not at > > all descriptive, what path? > > I polled the list on April 1, and received about a dozen responses > indicating a preference for Path. Nobody responded in favor of RRR. > > > > - this paragraph should be moved, since somebody's > > suggestions regarding > > things that are outside the scope of the i-d should not be part of > > the normative text: > > > > It has been suggested that the UA MAY choose to store the > > contents of > > the Path header for future use as a preloaded Route for > use when the > > UA wishes to send a SIP message that, for reasons of acquiring > > services in the home network, need to transit the service > proxies in > > the home network. Such usage is explicitly outside the > > scope of this > > document. > > > > This seems reasonable, and unless there are objections I intend to > delete in next revision. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 07:52:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16228 for ; Thu, 9 May 2002 07:52:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19803 for sip-archive@odin.ietf.org; Thu, 9 May 2002 07:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18649; Thu, 9 May 2002 07:29:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18618 for ; Thu, 9 May 2002 07:29:47 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15934 for ; Thu, 9 May 2002 07:29:38 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 175m4B-0000jx-00; Thu, 09 May 2002 14:26:35 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15578.23787.346977.576225@harjus.eng.song.fi> Date: Thu, 9 May 2002 14:26:35 +0300 To: "Drage, Keith (Keith)" Cc: Dean Willis , sip@ietf.org, "'3GPP_TSG_CN_WG1'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, bernhard.honeisen@nokia.com, "'Rohan Mahy'" , brian.rosen@marconi.com, jo@ipdialog.com Subject: RE: [Sip] WGLC for draft-willis-sip-path-05 In-Reply-To: <475FF955A05DD411980D00508B6D5FB004FE92C8@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB004FE92C8@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Drage, Keith (Keith) writes: > I not not sure that deletion solves the problem. We still need to retain > text that the usage of this information from the REGISTER response in the UA > is outside the scope of the specification. > > Or is that recorded somewhere else? yes, that has already been said in section 3: The originating UA is therefore informed of the inclusion of nodes on its registered Path, and MAY use that information in other capacities outside the scope of this document. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 10:19:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23353 for ; Thu, 9 May 2002 10:19:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29279 for sip-archive@odin.ietf.org; Thu, 9 May 2002 10:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27438; Thu, 9 May 2002 09:58:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27411 for ; Thu, 9 May 2002 09:58:49 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21954 for ; Thu, 9 May 2002 09:58:39 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g49E2GV29548; Thu, 9 May 2002 09:02:16 -0500 From: Robert Sparks To: "Chiou, Mark" Cc: sip@ietf.org, Sridhar Kuppanna In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 May 2002 08:58:07 -0500 Message-Id: <1020952687.1614.18.camel@dhcp152.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Question regarding draft-ietf-sip-cc-transfer-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2002-05-08 at 12:04, Chiou, Mark wrote: > Hi Robert, > > This is a question regarding Call transfer successful scenario. > > In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back. > > In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." > > The questions are : > > 1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources. The draft does not place a requirement for there to be a physical action on the part of either party in order for the BYE to be sent. Is it only the sentence above that gave you that impression or was there something else? It is very important that the REFER itself not tear down a dialog - that has to happen with a BYE. The BYE can (and usually will) be sent as part of the transfer application once the REFER association compeletes (the REFERor sees a NOTIFY with a sufficient final response, or decides it doesn't care anymore). > > 2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.) And this is a very good thing. If our goal is only to reproduce the PSTN, we're wasting our time - we've already got a PSTN that does that. We must do more. > > 3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? Not without extra mechanism. For the scenario you are thinking about, the transferee would end up in two distinct dialogs with thier own sessions (and would have to use whatever interface motif it has available for multiple calls). When the conferencing work ripens a little more, we'll see that the REFER could be to a conference that the transferor and transferee were already in. The conferencing mechanisms would have to recognize the reinvite reactivated a leg in the same conference. > > Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee." No - it needs to be MAY for both. > > By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session. > > Regards, > > Mark Chiou _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 11:37:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25959 for ; Thu, 9 May 2002 11:37:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04114 for sip-archive@odin.ietf.org; Thu, 9 May 2002 11:37:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02407; Thu, 9 May 2002 11:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02378 for ; Thu, 9 May 2002 11:06:04 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25126 for ; Thu, 9 May 2002 11:05:53 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 9 May 2002 10:05:22 -0500 Message-ID: Thread-Topic: Question regarding draft-ietf-sip-cc-transfer-05 thread-index: AcH3YZNB/HP3nl9RQFWf9ErgmHRAugACGbAA From: "Chiou, Mark" To: "Robert Sparks" Cc: , "Sridhar Kuppanna" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA02379 Subject: [Sip] RE: Question regarding draft-ietf-sip-cc-transfer-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, Thanks for clarification. I agree the REFER should not tear down the session between the transferor and the transferee. But the Call Transfer application SHOULD tear down the session between the transferor and the transferee for successful case. Thanks again, Mark -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Thursday, May 09, 2002 8:58 AM To: Chiou, Mark Cc: sip@ietf.org; Sridhar Kuppanna Subject: Re: Question regarding draft-ietf-sip-cc-transfer-05 On Wed, 2002-05-08 at 12:04, Chiou, Mark wrote: > Hi Robert, > > This is a question regarding Call transfer successful scenario. > > In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back. > > In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." > > The questions are : > > 1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources. The draft does not place a requirement for there to be a physical action on the part of either party in order for the BYE to be sent. Is it only the sentence above that gave you that impression or was there something else? It is very important that the REFER itself not tear down a dialog - that has to happen with a BYE. The BYE can (and usually will) be sent as part of the transfer application once the REFER association compeletes (the REFERor sees a NOTIFY with a sufficient final response, or decides it doesn't care anymore). > > 2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.) And this is a very good thing. If our goal is only to reproduce the PSTN, we're wasting our time - we've already got a PSTN that does that. We must do more. > > 3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? Not without extra mechanism. For the scenario you are thinking about, the transferee would end up in two distinct dialogs with thier own sessions (and would have to use whatever interface motif it has available for multiple calls). When the conferencing work ripens a little more, we'll see that the REFER could be to a conference that the transferor and transferee were already in. The conferencing mechanisms would have to recognize the reinvite reactivated a leg in the same conference. > > Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee." No - it needs to be MAY for both. > > By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session. > > Regards, > > Mark Chiou _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 13:15:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01115 for ; Thu, 9 May 2002 13:15:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10865 for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:15:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08085; Thu, 9 May 2002 12:42:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08033 for ; Thu, 9 May 2002 12:42:36 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28898 for ; Thu, 9 May 2002 12:42:27 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49GfvY15444 for ; Thu, 9 May 2002 18:41:57 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49GfD300975 for ; Thu, 9 May 2002 17:41:13 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 17:42:27 +0100 Message-ID: From: "Mark Watson" To: "'sip@ietf.org'" Date: Thu, 9 May 2002 17:42:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F778.7CE2787C" Subject: [Sip] Network Asserted Identity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F778.7CE2787C Content-Type: text/plain; charset="iso-8859-1" All, Revision of the requirements draft coming soon. In the meantime there are two issues which we did not completely bottom out at the meeting. It would be good if we could conclude on these asap, particularly as 3GPP has a meeting next week at which I hope they will incorporate this new IETF work into their spec. > 1) Name of the identity header > The following have been suggested: Network-Asserted-ID: Authenticated-Identity: NA-From: Network-From: Asserted-Identity: others ? Comments on these are: Network-Asserted-ID has an acronym clash with Network Access Identity from AAA. Authenticated-Identity is not appropriate use of the term 'Authenticated' as the identity is not actually accompanied by a signature Asserted-Identity: what is an 'unasserted' identity ? Suggestions & votes please! (If you vote in order of preference I can do a Single Transferable Vote election). > 2) UA 'hint' to authenticating proxy > One of the 3GPP requirements was for the UA to be able to supply a 'hint' to the Authenticating Proxy in the case that the UA has several identities. i.e. the UA could choose from several possible NAIs. Cullen's draft proposes that the same header be used for this purpose. If there are objections to this please speak now!! The alternative would presumably be a P-Header for this. > Regards...Mark > > > > > > > ------_=_NextPart_001_01C1F778.7CE2787C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Network Asserted Identity

All,

Revision of the = requirements draft coming soon.

In the meantime = there are two issues which we did not completely bottom out at the = meeting. It would be good if we could conclude on these asap, = particularly as 3GPP has a meeting next week at which I hope they will = incorporate this new IETF work into their spec.

1) Name of the = identity header

The following have = been suggested:

    Network-Asserted-ID:
    Authenticated-Identity:
    NA-From:
    Network-From:
    Asserted-Identity:
    others ?

Comments on these = are:

    Network-Asserted-ID has an acronym clash with Network = Access Identity from AAA.
    Authenticated-Identity is not appropriate use of the = term 'Authenticated' as the identity is not actually accompanied by a = signature

    Asserted-Identity: = what is an 'unasserted' identity ?

Suggestions & = votes please! (If you vote in order of preference I can do a Single = Transferable Vote election).

2) UA 'hint' to = authenticating proxy

One of the 3GPP = requirements was for the UA to be able to supply a 'hint' to the = Authenticating Proxy in the case that the UA has several identities. = i.e. the UA could choose from several possible NAIs. Cullen's draft = proposes that the same header be used for this purpose. If there are = objections to this please speak now!! The alternative would presumably = be a P-Header for this.

Regards...Mark







------_=_NextPart_001_01C1F778.7CE2787C-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 13:26:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01545 for ; Thu, 9 May 2002 13:26:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11252 for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:26:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10240; Thu, 9 May 2002 13:05:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10211 for ; Thu, 9 May 2002 13:05:09 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00402 for ; Thu, 9 May 2002 13:05:00 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g49H4c5M016147 for ; Thu, 9 May 2002 10:04:38 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAD39228; Thu, 9 May 2002 10:04:38 -0700 (PDT) Date: Thu, 9 May 2002 10:01:18 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Proposal to move forward on privacy and network identity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Folks, We reached a proto-consensus at the interim meeting. I wanted to poll the list for consensus on this proposal. Proposal: Adopt draft-watson-sipping-nai-reqs as a WG item in SIPPING (short-term requirements for network asserted ID) (I sent a separate mail to SIPPING on this). Adopt draft-peterson-sip-privacy-longterm as a WG item in SIP for generic privacy. Replace draft-ietf-sip-privacy-04.txt with draft-jennings-sipping-nai-00.txt as a reduced-scope solution for network asserted ID in trusted networks. Adopt draft-peterson-sip-identity as a WG item in SIP for a generic solution to 3rd-party cryptographic assertions of identity. Jon Peterson, Mark Watson, and Cullen Jennings work to document a mechanism to provide for a gateway between the "trusted network" and "cryptographically signed" models of network asserted identity. Both mechanisms would use a "Network-Asserted-ID" header. Comments? thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 13:58:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02639 for ; Thu, 9 May 2002 13:58:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13448 for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:58:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12541; Thu, 9 May 2002 13:40:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12510 for ; Thu, 9 May 2002 13:40:29 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02146 for ; Thu, 9 May 2002 13:40:17 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 175rtv-0000n3-00; Thu, 09 May 2002 20:40:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15578.46214.978436.188750@harjus.eng.song.fi> Date: Thu, 9 May 2002 20:40:22 +0300 To: "Mark Watson" Cc: "'sip@ietf.org'" Subject: [Sip] Network Asserted Identity In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > One of the 3GPP requirements was for the UA to be able to supply a 'hint' to > the Authenticating Proxy in the case that the UA has several identities. > i.e. the UA could choose from several possible NAIs. Cullen's draft proposes > that the same header be used for this purpose. If there are objections to > this please speak now!! The alternative would presumably be a P-Header for > this. the same header is fine with me, but i made several comments on the procedures at the proxy regarding the hint and i only got feedback privately. my main point was that if the user has several valid from identities, it MUST give a hint, because the proxy has no way to know which one it should pick. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 13:59:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02698 for ; Thu, 9 May 2002 13:59:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13472 for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:59:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11856; Thu, 9 May 2002 13:31:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11825 for ; Thu, 9 May 2002 13:31:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01697 for ; Thu, 9 May 2002 13:31:39 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28332; Thu, 9 May 2002 13:31:09 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22040; Thu, 9 May 2002 13:31:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 May 2002 13:31:08 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mark Watson'" , "'sip@ietf.org'" Subject: RE: [Sip] Network Asserted Identity Date: Thu, 9 May 2002 13:31:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I like Network Asserted ID best NA From is okay, but if we DO decide to allow an NAI on a Reply To, for example, we would need an NA-Reply-To, which has it's plusses and minuses Network-From has the same problem Asserted-Indentity is okay, but not as nice a Network Asserted ID On the hint, I don't understand why From isn't the hint. Could you explain? Assuming there is a good reason, I'd use the same header name. That kind of makes Asserted-Identity a better choice. Brian -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, May 09, 2002 12:42 PM To: 'sip@ietf.org' Subject: [Sip] Network Asserted Identity All, Revision of the requirements draft coming soon. In the meantime there are two issues which we did not completely bottom out at the meeting. It would be good if we could conclude on these asap, particularly as 3GPP has a meeting next week at which I hope they will incorporate this new IETF work into their spec. 1) Name of the identity header The following have been suggested: Network-Asserted-ID: Authenticated-Identity: NA-From: Network-From: Asserted-Identity: others ? Comments on these are: Network-Asserted-ID has an acronym clash with Network Access Identity from AAA. Authenticated-Identity is not appropriate use of the term 'Authenticated' as the identity is not actually accompanied by a signature Asserted-Identity: what is an 'unasserted' identity ? Suggestions & votes please! (If you vote in order of preference I can do a Single Transferable Vote election). 2) UA 'hint' to authenticating proxy One of the 3GPP requirements was for the UA to be able to supply a 'hint' to the Authenticating Proxy in the case that the UA has several identities. i.e. the UA could choose from several possible NAIs. Cullen's draft proposes that the same header be used for this purpose. If there are objections to this please speak now!! The alternative would presumably be a P-Header for this. Regards...Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 14:28:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04120 for ; Thu, 9 May 2002 14:28:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15789 for sip-archive@odin.ietf.org; Thu, 9 May 2002 14:29:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14393; Thu, 9 May 2002 14:07:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14368 for ; Thu, 9 May 2002 14:07:16 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03030 for ; Thu, 9 May 2002 14:07:06 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 175sJt-0000nW-00; Thu, 09 May 2002 21:07:13 +0300 To: "Rosen, Brian" Cc: "'Mark Watson'" , "'sip@ietf.org'" Subject: RE: [Sip] Network Asserted Identity In-Reply-To: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Message-Id: Date: Thu, 09 May 2002 21:07:13 +0300 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Rosen, Brian writes: > On the hint, I don't understand why From isn't the hint. Could you explain? > Assuming there is a good reason, I'd use the same header name. > That kind of makes Asserted-Identity a better choice. if the user wants to be anonymous, then from can't contain a hint. if from is not anonymous, then from can and for backwards compatibility reasons SHOULD be considered a hint in the absence of a nai header. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 15:00:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05114 for ; Thu, 9 May 2002 15:00:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17803 for sip-archive@odin.ietf.org; Thu, 9 May 2002 15:00:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16647; Thu, 9 May 2002 14:41:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16616 for ; Thu, 9 May 2002 14:41:04 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04652 for ; Thu, 9 May 2002 14:40:55 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49Ied504085; Thu, 9 May 2002 13:40:39 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 13:40:59 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3ABE@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Rosen, Brian'" , "Mark Watson", "'sip@ietf.org'" Subject: RE: [Sip] Network Asserted Identity Date: Thu, 9 May 2002 13:40:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F789.0FCAE560" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F789.0FCAE560 Content-Type: text/plain; charset="iso-8859-1" Hi all, The only concern I have with NAI is purely wrt potential confusion with the "Network Access Identifier" as defined in RFC 2486. Back in the days that I was working in the mobile IP and AAA space, this was a common term (per RFC 2794). Maybe it's just me, but before I read the draft, I had assumed that it was discussing the use of the RFC 2568 NAI in the SIP world, thus my suggestion would be AI (Asserted-Identity). Mary. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, May 09, 2002 12:31 PM To: Watson, Mark [MDN05:EP10:EXCH]; 'sip@ietf.org' Subject: RE: [Sip] Network Asserted Identity I like Network Asserted ID best NA From is okay, but if we DO decide to allow an NAI on a Reply To, for example, we would need an NA-Reply-To, which has it's plusses and minuses Network-From has the same problem Asserted-Indentity is okay, but not as nice a Network Asserted ID On the hint, I don't understand why From isn't the hint. Could you explain? Assuming there is a good reason, I'd use the same header name. That kind of makes Asserted-Identity a better choice. Brian -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, May 09, 2002 12:42 PM To: 'sip@ietf.org' Subject: [Sip] Network Asserted Identity All, Revision of the requirements draft coming soon. In the meantime there are two issues which we did not completely bottom out at the meeting. It would be good if we could conclude on these asap, particularly as 3GPP has a meeting next week at which I hope they will incorporate this new IETF work into their spec. 1) Name of the identity header The following have been suggested: Network-Asserted-ID: Authenticated-Identity: NA-From: Network-From: Asserted-Identity: others ? Comments on these are: Network-Asserted-ID has an acronym clash with Network Access Identity from AAA. Authenticated-Identity is not appropriate use of the term 'Authenticated' as the identity is not actually accompanied by a signature Asserted-Identity: what is an 'unasserted' identity ? Suggestions & votes please! (If you vote in order of preference I can do a Single Transferable Vote election). 2) UA 'hint' to authenticating proxy One of the 3GPP requirements was for the UA to be able to supply a 'hint' to the Authenticating Proxy in the case that the UA has several identities. i.e. the UA could choose from several possible NAIs. Cullen's draft proposes that the same header be used for this purpose. If there are objections to this please speak now!! The alternative would presumably be a P-Header for this. Regards...Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C1F789.0FCAE560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Network Asserted Identity

Hi all,

The only concern I have with NAI is purely wrt = potential confusion with the "Network Access Identifier" as = defined in RFC 2486.  Back in the days that I was working in the = mobile IP and AAA space, this was a common term (per RFC 2794).  = Maybe it's just me, but before I read the draft, I had assumed that it = was discussing the use of the RFC 2568 NAI in the SIP world, thus my = suggestion would be AI (Asserted-Identity).

Mary.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, May 09, 2002 12:31 PM
To: Watson, Mark [MDN05:EP10:EXCH]; = 'sip@ietf.org'
Subject: RE: [Sip] Network Asserted Identity


I like Network Asserted ID best
NA From is okay, but if we DO decide to allow an NAI = on a Reply To, for
example,
we would need an NA-Reply-To, which has it's plusses = and minuses
Network-From has the same problem Asserted-Indentity = is okay,
but not as nice a Network Asserted ID

On the hint, I don't understand why From isn't the = hint.  Could you explain?
Assuming there is a good reason, I'd use the same = header name. 
That kind of makes Asserted-Identity a better = choice.

Brian
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
Sent: Thursday, May 09, 2002 12:42 PM
To: 'sip@ietf.org'
Subject: [Sip] Network Asserted Identity


All,

Revision of the requirements draft coming soon. =
In the meantime there are two issues which we did = not completely bottom out
at the meeting. It would be good if we could = conclude on these asap,
particularly as 3GPP has a meeting next week at = which I hope they will
incorporate this new IETF work into their = spec.
1) Name of the identity header
The following have been suggested:
Network-Asserted-ID:
Authenticated-Identity:
NA-From:
Network-From:
Asserted-Identity:
others ?
Comments on these are:
Network-Asserted-ID has an acronym clash with = Network Access Identity from
AAA.
Authenticated-Identity is not appropriate use of the = term 'Authenticated' as
the identity is not actually accompanied by a = signature
Asserted-Identity: what is an 'unasserted' identity = ?
Suggestions & votes please! (If you vote in = order of preference I can do a
Single Transferable Vote election).
2) UA 'hint' to authenticating proxy
One of the 3GPP requirements was for the UA to be = able to supply a 'hint' to
the Authenticating Proxy in the case that the UA has = several identities.
i.e. the UA could choose from several possible NAIs. = Cullen's draft proposes
that the same header be used for this purpose. If = there are objections to
this please speak now!! The alternative would = presumably be a P-Header for
this.
Regards...Mark


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = Protocol
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sipping@ietf.org for new developments on the = application of sip

------_=_NextPart_001_01C1F789.0FCAE560-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 15:31:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06292 for ; Thu, 9 May 2002 15:31:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19464 for sip-archive@odin.ietf.org; Thu, 9 May 2002 15:31:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18438; Thu, 9 May 2002 15:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18409 for ; Thu, 9 May 2002 15:09:53 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05480 for ; Thu, 9 May 2002 15:09:43 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g49J99d06493; Thu, 9 May 2002 14:09:09 -0500 From: "Dean Willis" To: "'Rosen, Brian'" , "'Mark Watson'" , Subject: RE: [Sip] Network Asserted Identity Date: Thu, 9 May 2002 14:08:53 -0500 Message-ID: <007f01c1f78c$f63bf090$4a010114@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > On the hint, I don't understand why From isn't the hint. > Could you explain? Assuming there is a good reason, I'd use > the same header name. > That kind of makes Asserted-Identity a better choice. From: isn't the hint because there may need to be network assertion of identity even when there is a privacy request from the user. Unless we want proxies munging From: (insert my many arguments here) then the hint needs to be in another place that CAN be proxy-munged. This leaves the UA responsible for its From: field (sets "anonymous" or equiavelent if privacy required) which is cleaner and has better backward-compatibility. I like "Asserted-Identity", as future techniques lets us say WHO asserted the identity, and it might be "the network", the user, or a third-party authentication service. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 9 19:30:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13875 for ; Thu, 9 May 2002 19:30:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01789 for sip-archive@odin.ietf.org; Thu, 9 May 2002 19:30:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00133; Thu, 9 May 2002 18:55:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00107 for ; Thu, 9 May 2002 18:55:11 -0400 (EDT) Received: from mail1.telefonica.com.ar ([168.226.49.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12705 for ; Thu, 9 May 2002 18:55:01 -0400 (EDT) Received: by MAIL1 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 19:55:03 -0300 Message-ID: <19364262E259D51198BA0008C7E6528E05199474@MSTELEFONICA8> From: De Leo Walter To: "'sip@ietf.org'" Date: Thu, 9 May 2002 19:54:45 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] minor nit in bis-09. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Surely was already noticed but just in case: In page 145 second paragraph it says ....This is only to provide backwards compatibility with RFC2543 compliant implementations that do not support UDP. It should say TCP. Sorry, i dont have the pdf version at hand so i cannot provide line numbers. regards _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 01:24:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28514 for ; Fri, 10 May 2002 01:24:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA23981 for sip-archive@odin.ietf.org; Fri, 10 May 2002 01:24:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14679; Fri, 10 May 2002 00:48:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14643 for ; Fri, 10 May 2002 00:48:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27691 for ; Fri, 10 May 2002 00:48:04 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4A4lhHT028518; Thu, 9 May 2002 21:47:43 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACW57133; Thu, 9 May 2002 21:47:55 -0700 (PDT) From: "Cullen Jennings" To: , "Dean Willis" Cc: "Fluffy" , "Jon Peterson" , "Mark Watson" Date: Thu, 9 May 2002 21:48:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15578.46214.978436.188750@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Subject: [Sip] NAI - Jon/Mark/Cullen Proposal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I promised Dean to capture one bit of the minutes - this is it :-) There was considerable discussion about privacy and identity stuff at the interim meeting. At the time we were using the terms short term and long term to describe the proposals. A better description to separate the two would be cryptographic and non-cryptographic approach. The proposal from Jon, Mark, and I is to go forward by looking at a solution that is something along the lines of: 1) Have a header called something like Asserted-Identity 2) In the non cryptographic solution, this header could appear in the header portion of the message 3) In the cryptographic solution, this header could be used in signed and encrypted sipfrags in the body of the message We need to carefully think about the implications of both the cryptographic and non-cryptographic solution existing and what would happen as messages were passed from a network element using one type to a network element using the other type. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 02:57:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09118 for ; Fri, 10 May 2002 02:57:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28249 for sip-archive@odin.ietf.org; Fri, 10 May 2002 02:57:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27602; Fri, 10 May 2002 02:35:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27573 for ; Fri, 10 May 2002 02:35:03 -0400 (EDT) Received: from blaze.hcltech.com ([203.199.199.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08839 for ; Fri, 10 May 2002 02:34:54 -0400 (EDT) Received: from suryapc (surya-pc.hclt-guindy.co.in [192.168.201.166]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id MAA30147; Fri, 10 May 2002 12:07:23 +0530 Message-ID: <00bb01c1f7e8$cb8244b0$a6c9a8c0@hcltguindy.co.in> From: "Surya Kumar IVG" To: "De Leo Walter" , References: <19364262E259D51198BA0008C7E6528E05199474@MSTELEFONICA8> Subject: Re: [Sip] minor nit in bis-09. Date: Fri, 10 May 2002 11:36:16 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes, I think that is true,as earlier drafts has taken an inclination towards supporting UDP and later versions moved towards TCP ----- Original Message ----- From: "De Leo Walter" To: Sent: Friday, May 10, 2002 4:24 AM Subject: [Sip] minor nit in bis-09. > Surely was already noticed but just in case: > > In page 145 second paragraph it says ....This is only to provide backwards > compatibility with RFC2543 compliant implementations that do not support > UDP. It should say TCP. > > Sorry, i dont have the pdf version at hand so i cannot provide line numbers. > > regards > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 03:13:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09579 for ; Fri, 10 May 2002 03:13:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29314 for sip-archive@odin.ietf.org; Fri, 10 May 2002 03:13:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27807; Fri, 10 May 2002 02:41:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27778 for ; Fri, 10 May 2002 02:41:31 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08888 for ; Fri, 10 May 2002 02:41:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4A6fU0E021464 for ; Fri, 10 May 2002 08:41:30 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4A6fU9q025486 for ; Fri, 10 May 2002 09:41:30 +0300 (EET DST) Message-ID: <3CDB6B99.AE255408@lmf.ericsson.se> Date: Fri, 10 May 2002 09:41:30 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Header comparision Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a small clarification question on To- and From header comparision. Chapter 8.2.6.2 says: "The From field of the response MUST equal the From header field of the request." Later in the chapter it explains the use of tags. However, there is nothing said (not in the URI comparision chapter either) about the "<" and ">" characters, so my question is: If the UAC doesn't include "<" and ">" in the request, and the UAS DOES include them in the response, is it a protocol error? example: Request: To: el.sipo@sipworld.sip Response: To: Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 04:01:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10133 for ; Fri, 10 May 2002 04:01:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01848 for sip-archive@odin.ietf.org; Fri, 10 May 2002 04:01:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00660; Fri, 10 May 2002 03:39:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00629 for ; Fri, 10 May 2002 03:39:11 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09912 for ; Fri, 10 May 2002 03:39:02 -0400 (EDT) Received: (qmail 3426 invoked from network); 10 May 2002 08:39:46 -0000 Received: from unknown (HELO MC24Madhu) (61.11.57.39) by nghmail with SMTP; 10 May 2002 08:39:46 -0000 Message-ID: <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> From: "Madhusudhan" To: , References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> Subject: Re: [Sip] Header comparision Date: Fri, 10 May 2002 13:07:56 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Section 20 of bis09 mentions "The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters" From the above comments, I think it is evident that the two addresses are different. correct me if I am wrong!!! Regards Madhusudhan > > ----- Original Message ----- > From: "Christer Holmberg" > To: > Sent: Friday, May 10, 2002 12:11 PM > Subject: [Sip] Header comparision > > > > > > Hi, > > > > I have a small clarification question on To- and From header > > comparision. > > > > Chapter 8.2.6.2 says: > > > > "The From field of the response MUST equal the From header field of > > the request." > > > > Later in the chapter it explains the use of tags. > > > > However, there is nothing said (not in the URI comparision chapter > > either) about the "<" and ">" characters, so my question is: > > > > If the UAC doesn't include "<" and ">" in the request, and the UAS DOES > > include them in the response, is it a protocol error? > > > > example: > > > > Request: > > > > To: el.sipo@sipworld.sip > > > > Response: > > > > To: > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 04:18:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10461 for ; Fri, 10 May 2002 04:18:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02313 for sip-archive@odin.ietf.org; Fri, 10 May 2002 04:18:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01968; Fri, 10 May 2002 04:05:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01937 for ; Fri, 10 May 2002 04:05:57 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10226 for ; Fri, 10 May 2002 04:05:47 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4A85ss7020433; Fri, 10 May 2002 10:05:54 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4A85s9q029502; Fri, 10 May 2002 11:05:54 +0300 (EET DST) Message-ID: <3CDB7F62.7DE4B42C@lmf.ericsson.se> Date: Fri, 10 May 2002 11:05:54 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Madhusudhan CC: sip@ietf.org Subject: Re: [Sip] Header comparision References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Madhusudhan, Thanks for your comments! However, I think we are talking about two separate issues. Yes, in some cases (as mentioned) the URI MUST be enclosed in angle brackets, but that does NOT mean you aren't allowed to enclose the URI in angle brackets ALSO in other cases. For example: To: ...is allowed from a SIP syntax point of view. However, my question was related to the COMPARISION of headers. Regards, Christer Holmberg Ericsson Finland Madhusudhan wrote: > Hi > > Section 20 of bis09 mentions > > "The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters" > > From the above comments, I think it is evident that the two addresses are > different. > > correct me if I am wrong!!! > > Regards > > Madhusudhan > > > > > ----- Original Message ----- > > From: "Christer Holmberg" > > To: > > Sent: Friday, May 10, 2002 12:11 PM > > Subject: [Sip] Header comparision > > > > > > > > > > Hi, > > > > > > I have a small clarification question on To- and From header > > > comparision. > > > > > > Chapter 8.2.6.2 says: > > > > > > "The From field of the response MUST equal the From header field of > > > the request." > > > > > > Later in the chapter it explains the use of tags. > > > > > > However, there is nothing said (not in the URI comparision chapter > > > either) about the "<" and ">" characters, so my question is: > > > > > > If the UAC doesn't include "<" and ">" in the request, and the UAS DOES > > > include them in the response, is it a protocol error? > > > > > > example: > > > > > > Request: > > > > > > To: el.sipo@sipworld.sip > > > > > > Response: > > > > > > To: > > > > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 04:20:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10533 for ; Fri, 10 May 2002 04:20:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02344 for sip-archive@odin.ietf.org; Fri, 10 May 2002 04:20:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01086; Fri, 10 May 2002 03:53:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01057 for ; Fri, 10 May 2002 03:53:30 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10059 for ; Fri, 10 May 2002 03:53:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.172]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4A7rqYH002776; Fri, 10 May 2002 03:53:53 -0400 (EDT) Message-ID: <3CDB7C37.72E1DB63@dynamicsoft.com> Date: Fri, 10 May 2002 03:52:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Surya Kumar IVG CC: De Leo Walter , sip@ietf.org Subject: Re: [Sip] minor nit in bis-09. References: <00bb01c1f7e8$cb8244b0$a6c9a8c0@hcltguindy.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes, this particular bug has been reported almost half a dozen times now... Thanks! -Jonathan R. Surya Kumar IVG wrote: > > Yes, I think that is true,as earlier drafts has taken an inclination > towards > supporting UDP and later versions moved towards TCP > > ----- Original Message ----- > From: "De Leo Walter" > To: > Sent: Friday, May 10, 2002 4:24 AM > Subject: [Sip] minor nit in bis-09. > > > Surely was already noticed but just in case: > > > > In page 145 second paragraph it says ....This is only to provide > backwards > > compatibility with RFC2543 compliant implementations that do not > support > > UDP. It should say TCP. > > > > Sorry, i dont have the pdf version at hand so i cannot provide line > numbers. > > > > regards > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 05:34:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11297 for ; Fri, 10 May 2002 05:34:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05698 for sip-archive@odin.ietf.org; Fri, 10 May 2002 05:34:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03665; Fri, 10 May 2002 04:52:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03633 for ; Fri, 10 May 2002 04:51:58 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10911 for ; Fri, 10 May 2002 04:51:49 -0400 (EDT) Received: (qmail 16585 invoked from network); 10 May 2002 09:52:30 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.39) by nghmail with SMTP; 10 May 2002 09:52:30 -0000 Message-ID: <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> From: "vishal" To: "Christer Holmberg" , "Madhusudhan" Cc: References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> Subject: Re: [Sip] Header comparision Date: Fri, 10 May 2002 14:21:53 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi christer, From,To,Call-Id ,Cseq fields of sip response MUST exactly match corresponding request.If it does not match exactly ,then it should be protocol error . Reason: you dont require addition checking while copying these fields . case you described , To: el.sipo@sipworld.sip and To: are equivalent ,not equal. please refer to sip bis 09 section 8.2.6.2 below "8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present)" regards, vishal ----- Original Message ----- From: Christer Holmberg To: Madhusudhan Cc: Sent: Friday, May 10, 2002 1:35 PM Subject: Re: [Sip] Header comparision > > Hi Madhusudhan, > > Thanks for your comments! > > However, I think we are talking about two separate issues. > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle brackets, > but that does NOT mean you aren't allowed to enclose the URI in angle brackets > ALSO in other cases. For example: > > To: > > ...is allowed from a SIP syntax point of view. > > However, my question was related to the COMPARISION of headers. > > Regards, > > Christer Holmberg > Ericsson Finland > > > Madhusudhan wrote: > > > Hi > > > > Section 20 of bis09 mentions > > > > "The Contact, From, and To header fields contain a URI. If the URI > > contains a comma, question mark or semicolon, the URI MUST be > > enclosed in angle brackets (< and >). Any URI parameters are > > contained within these brackets. If the URI is not enclosed in angle > > brackets, any semicolon-delimited parameters are header-parameters, > > not URI parameters" > > > > From the above comments, I think it is evident that the two addresses are > > different. > > > > correct me if I am wrong!!! > > > > Regards > > > > Madhusudhan > > > > > > > > ----- Original Message ----- > > > From: "Christer Holmberg" > > > To: > > > Sent: Friday, May 10, 2002 12:11 PM > > > Subject: [Sip] Header comparision > > > > > > > > > > > > > > Hi, > > > > > > > > I have a small clarification question on To- and From header > > > > comparision. > > > > > > > > Chapter 8.2.6.2 says: > > > > > > > > "The From field of the response MUST equal the From header field of > > > > the request." > > > > > > > > Later in the chapter it explains the use of tags. > > > > > > > > However, there is nothing said (not in the URI comparision chapter > > > > either) about the "<" and ">" characters, so my question is: > > > > > > > > If the UAC doesn't include "<" and ">" in the request, and the UAS DOES > > > > include them in the response, is it a protocol error? > > > > > > > > example: > > > > > > > > Request: > > > > > > > > To: el.sipo@sipworld.sip > > > > > > > > Response: > > > > > > > > To: > > > > > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 05:57:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11554 for ; Fri, 10 May 2002 05:57:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA06363 for sip-archive@odin.ietf.org; Fri, 10 May 2002 05:57:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04780; Fri, 10 May 2002 05:18:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04749 for ; Fri, 10 May 2002 05:18:22 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11143 for ; Fri, 10 May 2002 05:18:12 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4A9IJ0E013225; Fri, 10 May 2002 11:18:20 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4A9IJ9q001807; Fri, 10 May 2002 12:18:19 +0300 (EET DST) Message-ID: <3CDB905B.4CA150B7@lmf.ericsson.se> Date: Fri, 10 May 2002 12:18:19 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vishal CC: Madhusudhan , sip@ietf.org Subject: Re: [Sip] Header comparision References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I know what chapter 8.2.6.2 says, but my question was if it really also affects the angle brackets. Another related issue: chapter 19.1.4 says that the uri parameter ordering is not significant for URI comparision, but according to chapter 8.2.6.2 the uri parameter ordering would have to match in a request/response transaction. Also, from a URI comparision point of view, some parts of the URI are case-insensitive. But, does it mean that within a transaction everything is case-sensitive? Regards, Christer Holmberg Ericsson Finland vishal wrote: > Hi christer, > From,To,Call-Id ,Cseq fields of sip response MUST exactly match > corresponding request.If it does not match exactly ,then it should be > protocol error . > > Reason: > you dont require addition checking while copying these fields . > > case you described , > To: el.sipo@sipworld.sip and > To: are equivalent ,not equal. > > please refer to sip bis 09 section 8.2.6.2 below > > "8.2.6.2 Headers and Tags > > The From field of the response MUST equal the From header field of > the request. The Call-ID header field of the response MUST equal the > Call-ID header field of the request. The CSeq header field of the > response MUST equal the CSeq field of the request. The Via header > field values in the response MUST equal the Via header field values > in the request and MUST maintain the same ordering. > > If a request contained a To tag in the request, the To header field > in the response MUST equal that of the request. However, if the To > header field in the request did not contain a tag, the URI in the To > header field in the response MUST equal the URI in the To header > field; additionally, the UAS MUST add a tag to the To header field in > the response (with the exception of the 100 (Trying) response, in > which a tag MAY be present)" > > regards, vishal > > ----- Original Message ----- > From: Christer Holmberg > To: Madhusudhan > Cc: > Sent: Friday, May 10, 2002 1:35 PM > Subject: Re: [Sip] Header comparision > > > > > Hi Madhusudhan, > > > > Thanks for your comments! > > > > However, I think we are talking about two separate issues. > > > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle > brackets, > > but that does NOT mean you aren't allowed to enclose the URI in angle > brackets > > ALSO in other cases. For example: > > > > To: > > > > ...is allowed from a SIP syntax point of view. > > > > However, my question was related to the COMPARISION of headers. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > Madhusudhan wrote: > > > > > Hi > > > > > > Section 20 of bis09 mentions > > > > > > "The Contact, From, and To header fields contain a URI. If the URI > > > contains a comma, question mark or semicolon, the URI MUST be > > > enclosed in angle brackets (< and >). Any URI parameters are > > > contained within these brackets. If the URI is not enclosed in angle > > > brackets, any semicolon-delimited parameters are header-parameters, > > > not URI parameters" > > > > > > From the above comments, I think it is evident that the two addresses > are > > > different. > > > > > > correct me if I am wrong!!! > > > > > > Regards > > > > > > Madhusudhan > > > > > > > > > > > ----- Original Message ----- > > > > From: "Christer Holmberg" > > > > To: > > > > Sent: Friday, May 10, 2002 12:11 PM > > > > Subject: [Sip] Header comparision > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I have a small clarification question on To- and From header > > > > > comparision. > > > > > > > > > > Chapter 8.2.6.2 says: > > > > > > > > > > "The From field of the response MUST equal the From header field of > > > > > the request." > > > > > > > > > > Later in the chapter it explains the use of tags. > > > > > > > > > > However, there is nothing said (not in the URI comparision chapter > > > > > either) about the "<" and ">" characters, so my question is: > > > > > > > > > > If the UAC doesn't include "<" and ">" in the request, and the UAS > DOES > > > > > include them in the response, is it a protocol error? > > > > > > > > > > example: > > > > > > > > > > Request: > > > > > > > > > > To: el.sipo@sipworld.sip > > > > > > > > > > Response: > > > > > > > > > > To: > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 06:04:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11746 for ; Fri, 10 May 2002 06:04:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07123 for sip-archive@odin.ietf.org; Fri, 10 May 2002 06:04:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05139; Fri, 10 May 2002 05:30:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05091 for ; Fri, 10 May 2002 05:30:00 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11254 for ; Fri, 10 May 2002 05:29:51 -0400 (EDT) Received: (qmail 22802 invoked from network); 10 May 2002 10:30:32 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.39) by nghmail with SMTP; 10 May 2002 10:30:32 -0000 Message-ID: <001101c1f805$4a4d7640$5601a8c0@knowsys.net> From: "vishal" To: "Christer Holmberg" Cc: References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> <3CDB905B.4CA150B7@lmf.ericsson.se> Subject: Re: [Sip] Header comparision Date: Fri, 10 May 2002 15:00:07 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi christer , I am trying to say that ....YES IT REALLY MATTERS ,if From field does not exactly matches then it is an error .Another question is ....why UAS will add angular brackets ...and why UAC will further check different syntax available after receiving message sent by UAS?? best solution is to compare From field as was sent in initial request . regards, vishal ----- Original Message ----- From: Christer Holmberg To: vishal Cc: Madhusudhan ; Sent: Friday, May 10, 2002 2:48 PM Subject: Re: [Sip] Header comparision > > Hi, > > I know what chapter 8.2.6.2 says, but my question was if it really also affects > the angle brackets. > > Another related issue: chapter 19.1.4 says that the uri parameter ordering is > not significant for URI comparision, but according to chapter 8.2.6.2 the uri > parameter ordering would have to match in a request/response transaction. > > Also, from a URI comparision point of view, some parts of the URI are > case-insensitive. But, does it mean that within a transaction everything is > case-sensitive? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > vishal wrote: > > > Hi christer, > > From,To,Call-Id ,Cseq fields of sip response MUST exactly match > > corresponding request.If it does not match exactly ,then it should be > > protocol error . > > > > Reason: > > you dont require addition checking while copying these fields . > > > > case you described , > > To: el.sipo@sipworld.sip and > > To: are equivalent ,not equal. > > > > please refer to sip bis 09 section 8.2.6.2 below > > > > "8.2.6.2 Headers and Tags > > > > The From field of the response MUST equal the From header field of > > the request. The Call-ID header field of the response MUST equal the > > Call-ID header field of the request. The CSeq header field of the > > response MUST equal the CSeq field of the request. The Via header > > field values in the response MUST equal the Via header field values > > in the request and MUST maintain the same ordering. > > > > If a request contained a To tag in the request, the To header field > > in the response MUST equal that of the request. However, if the To > > header field in the request did not contain a tag, the URI in the To > > header field in the response MUST equal the URI in the To header > > field; additionally, the UAS MUST add a tag to the To header field in > > the response (with the exception of the 100 (Trying) response, in > > which a tag MAY be present)" > > > > regards, vishal > > > > ----- Original Message ----- > > From: Christer Holmberg > > To: Madhusudhan > > Cc: > > Sent: Friday, May 10, 2002 1:35 PM > > Subject: Re: [Sip] Header comparision > > > > > > > > Hi Madhusudhan, > > > > > > Thanks for your comments! > > > > > > However, I think we are talking about two separate issues. > > > > > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle > > brackets, > > > but that does NOT mean you aren't allowed to enclose the URI in angle > > brackets > > > ALSO in other cases. For example: > > > > > > To: > > > > > > ...is allowed from a SIP syntax point of view. > > > > > > However, my question was related to the COMPARISION of headers. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > Madhusudhan wrote: > > > > > > > Hi > > > > > > > > Section 20 of bis09 mentions > > > > > > > > "The Contact, From, and To header fields contain a URI. If the URI > > > > contains a comma, question mark or semicolon, the URI MUST be > > > > enclosed in angle brackets (< and >). Any URI parameters are > > > > contained within these brackets. If the URI is not enclosed in angle > > > > brackets, any semicolon-delimited parameters are header-parameters, > > > > not URI parameters" > > > > > > > > From the above comments, I think it is evident that the two addresses > > are > > > > different. > > > > > > > > correct me if I am wrong!!! > > > > > > > > Regards > > > > > > > > Madhusudhan > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Christer Holmberg" > > > > > To: > > > > > Sent: Friday, May 10, 2002 12:11 PM > > > > > Subject: [Sip] Header comparision > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I have a small clarification question on To- and From header > > > > > > comparision. > > > > > > > > > > > > Chapter 8.2.6.2 says: > > > > > > > > > > > > "The From field of the response MUST equal the From header field of > > > > > > the request." > > > > > > > > > > > > Later in the chapter it explains the use of tags. > > > > > > > > > > > > However, there is nothing said (not in the URI comparision chapter > > > > > > either) about the "<" and ">" characters, so my question is: > > > > > > > > > > > > If the UAC doesn't include "<" and ">" in the request, and the UAS > > DOES > > > > > > include them in the response, is it a protocol error? > > > > > > > > > > > > example: > > > > > > > > > > > > Request: > > > > > > > > > > > > To: el.sipo@sipworld.sip > > > > > > > > > > > > Response: > > > > > > > > > > > > To: > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 06:39:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12868 for ; Fri, 10 May 2002 06:39:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08799 for sip-archive@odin.ietf.org; Fri, 10 May 2002 06:39:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06286; Fri, 10 May 2002 05:56:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06252 for ; Fri, 10 May 2002 05:56:18 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11534 for ; Fri, 10 May 2002 05:56:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4A9tWk29355 for ; Fri, 10 May 2002 12:56:31 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 May 2002 12:55:11 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 12:55:10 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 10 May 2002 12:55:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed? Date: Fri, 10 May 2002 12:55:09 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777919A@esebe019.NOE.Nokia.com> Thread-Topic: WGLC for draft-willis-sip-path-05: Require:path needed? Thread-Index: AcH1944mM8TlXyXOSsKsfep6ee8gkAAc1vhAAAYg12AAARtQgABgDDcg To: , , Cc: X-OriginalArrivalTime: 10 May 2002 09:55:10.0382 (UTC) FILETIME=[C5BA1CE0:01C1F808] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA06253 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Honeisen Bernhard (NET/Helsinki) > Sent: Wednesday, May 08, 2002 4:11 PM > To: Khartabil Hisham (NMP/Helsinki); 'dean.willis@softarmor.com'; > 'bpenfield@acmepacket.com' > Cc: 'sip@ietf.org' > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path > needed? > > > Solution: > > > > > > -> after a 420 the UA tries to send the request without > > > Supported:path. > > > > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path > > > was present in the request. > > > > > > > > Are you suggesting that a proxy must remember requests that > > it processed earlier? > > No, not at all. Why do you think it has to remember? > > > First you mention that a proxy can insert a path-header > > without a supported-header (or that is what it sounded like > > at least). > > If it does, the registrar will ignore any Path header, as > no Supported:path is present in the REGISTER request in > question. Such behaviour would allow easier implementation > of proxies. (But I don't argue, if people think it's better, > if proxies must not insert any Path stuff, if there is > no Supported header in the REGISTER request in question.) > My proposal is just, that the proxy just MUST NOT insert > any Require:path, if Supported:path was not present. > Ok, now I understand what your saying ;) But what is the point (besides ease of implementation) of allowing proxies to add a path-header for a request (REGISTER) that does not contain a "supported: path" header if the registrar is going to ignore them anyway? The SIP message size gets bigger and bigger for no reason. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 06:39:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12895 for ; Fri, 10 May 2002 06:39:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08814 for sip-archive@odin.ietf.org; Fri, 10 May 2002 06:39:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05982; Fri, 10 May 2002 05:47:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05951 for ; Fri, 10 May 2002 05:46:59 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11436 for ; Fri, 10 May 2002 05:46:47 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4A9kGI18166; Fri, 10 May 2002 11:46:17 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 10:46:51 +0100 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] Network Asserted Identity Date: Fri, 10 May 2002 10:46:45 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So, all votes so far are for 'Asserted-Identity'. To answer the obvious 'asserted by whom ?' question, I suggest some text along the following lines (for Cullen's draft, not the requirements): 'In the absence of other indications, a node receiving an Asserted-Identity header must assume that it is asserted by the node from which it was received (assuming integrity protection on this hop). This does not by itself imply that the sending node has the right to assert the identity, or that the identity has any validity. So, for example, if the nodes are members of the same Trust Domain and the receiving node trusts the node from which the Asserted-Identity was received (in the sense of [nai-reqs]), then the sending node can be assumed to have the right to assert identities on behalf of the Trust Domain. In this case the Asserted-Identity is a Network Asserted Identity as defined in [nai-reqs]. Alternatively, if a proxy receives an Asserted-Identity header from a UA, then the Asserted-Identity represents only the UA's preference as to its identity for Network Asserted Identity purposes. As with any header, in the absence of some integrity protection between the UA and the proxy, there is no guarantee that the identity has not been modified in transit.' I will also update the requirements to include the 'hint' case. Regards, Mark > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 09 May 2002 20:09 > To: 'Rosen, Brian'; Watson, Mark [MDN05:EP10:EXCH]; sip@ietf.org > Subject: RE: [Sip] Network Asserted Identity > > > > On the hint, I don't understand why From isn't the hint. > > Could you explain? Assuming there is a good reason, I'd use > > the same header name. > > That kind of makes Asserted-Identity a better choice. > > From: isn't the hint because there may need to be network assertion of > identity even when there is a privacy request from the user. Unless we > want proxies munging From: (insert my many arguments here) > then the hint > needs to be in another place that CAN be proxy-munged. This leaves the > UA responsible for its From: field (sets "anonymous" or equiavelent if > privacy required) which is cleaner and has better > backward-compatibility. > > I like "Asserted-Identity", as future techniques lets us say WHO > asserted the identity, and it might be "the network", the user, or a > third-party authentication service. > > -- > Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 07:01:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13779 for ; Fri, 10 May 2002 07:01:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09888 for sip-archive@odin.ietf.org; Fri, 10 May 2002 07:01:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07389; Fri, 10 May 2002 06:09:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07292 for ; Fri, 10 May 2002 06:09:39 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11896 for ; Fri, 10 May 2002 06:09:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4AA9b0E000598; Fri, 10 May 2002 12:09:37 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4AA9a9q002988; Fri, 10 May 2002 13:09:37 +0300 (EET DST) Message-ID: <3CDB9C61.3FF7FC4F@lmf.ericsson.se> Date: Fri, 10 May 2002 13:09:37 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vishal CC: sip@ietf.org Subject: Re: [Sip] Header comparision References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> <3CDB905B.4CA150B7@lmf.ericsson.se> <001101c1f805$4a4d7640$5601a8c0@knowsys.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > Hi christer , > I am trying to say that ....YES IT REALLY MATTERS ,if From field does not > exactly matches then it is an error .Another question is ....why UAS will > add angular brackets ...and why UAC will further check different syntax > available after receiving message sent by UAS?? > > best solution is to compare From field as was sent in initial request . Yes, you can do a pure binary comparision, but that also requires the order the uri parameters are the same, there is no case difference etc. Why I would want to do this or that (I didn't even said I would) really doesn't matter. I am just trying to get a clarification on the angle bracket case, the uri parameter order case, and the case sensitivity case, for header mapping within a transaction... Regards, Christer Holmberg Ericsson Finland > > > regards, vishal > > ----- Original Message ----- > From: Christer Holmberg > To: vishal > Cc: Madhusudhan ; > Sent: Friday, May 10, 2002 2:48 PM > Subject: Re: [Sip] Header comparision > > > > > Hi, > > > > I know what chapter 8.2.6.2 says, but my question was if it really also > affects > > the angle brackets. > > > > Another related issue: chapter 19.1.4 says that the uri parameter ordering > is > > not significant for URI comparision, but according to chapter 8.2.6.2 the > uri > > parameter ordering would have to match in a request/response transaction. > > > > Also, from a URI comparision point of view, some parts of the URI are > > case-insensitive. But, does it mean that within a transaction everything > is > > case-sensitive? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > vishal wrote: > > > > > Hi christer, > > > From,To,Call-Id ,Cseq fields of sip response MUST exactly match > > > corresponding request.If it does not match exactly ,then it should be > > > protocol error . > > > > > > Reason: > > > you dont require addition checking while copying these fields . > > > > > > case you described , > > > To: el.sipo@sipworld.sip and > > > To: are equivalent ,not equal. > > > > > > please refer to sip bis 09 section 8.2.6.2 below > > > > > > "8.2.6.2 Headers and Tags > > > > > > The From field of the response MUST equal the From header field of > > > the request. The Call-ID header field of the response MUST equal the > > > Call-ID header field of the request. The CSeq header field of the > > > response MUST equal the CSeq field of the request. The Via header > > > field values in the response MUST equal the Via header field values > > > in the request and MUST maintain the same ordering. > > > > > > If a request contained a To tag in the request, the To header field > > > in the response MUST equal that of the request. However, if the To > > > header field in the request did not contain a tag, the URI in the To > > > header field in the response MUST equal the URI in the To header > > > field; additionally, the UAS MUST add a tag to the To header field in > > > the response (with the exception of the 100 (Trying) response, in > > > which a tag MAY be present)" > > > > > > regards, vishal > > > > > > ----- Original Message ----- > > > From: Christer Holmberg > > > To: Madhusudhan > > > Cc: > > > Sent: Friday, May 10, 2002 1:35 PM > > > Subject: Re: [Sip] Header comparision > > > > > > > > > > > Hi Madhusudhan, > > > > > > > > Thanks for your comments! > > > > > > > > However, I think we are talking about two separate issues. > > > > > > > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle > > > brackets, > > > > but that does NOT mean you aren't allowed to enclose the URI in angle > > > brackets > > > > ALSO in other cases. For example: > > > > > > > > To: > > > > > > > > ...is allowed from a SIP syntax point of view. > > > > > > > > However, my question was related to the COMPARISION of headers. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > Madhusudhan wrote: > > > > > > > > > Hi > > > > > > > > > > Section 20 of bis09 mentions > > > > > > > > > > "The Contact, From, and To header fields contain a URI. If the URI > > > > > contains a comma, question mark or semicolon, the URI MUST be > > > > > enclosed in angle brackets (< and >). Any URI parameters are > > > > > contained within these brackets. If the URI is not enclosed in > angle > > > > > brackets, any semicolon-delimited parameters are > header-parameters, > > > > > not URI parameters" > > > > > > > > > > From the above comments, I think it is evident that the two > addresses > > > are > > > > > different. > > > > > > > > > > correct me if I am wrong!!! > > > > > > > > > > Regards > > > > > > > > > > Madhusudhan > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Christer Holmberg" > > > > > > To: > > > > > > Sent: Friday, May 10, 2002 12:11 PM > > > > > > Subject: [Sip] Header comparision > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I have a small clarification question on To- and From header > > > > > > > comparision. > > > > > > > > > > > > > > Chapter 8.2.6.2 says: > > > > > > > > > > > > > > "The From field of the response MUST equal the From header field > of > > > > > > > the request." > > > > > > > > > > > > > > Later in the chapter it explains the use of tags. > > > > > > > > > > > > > > However, there is nothing said (not in the URI comparision > chapter > > > > > > > either) about the "<" and ">" characters, so my question is: > > > > > > > > > > > > > > If the UAC doesn't include "<" and ">" in the request, and the > UAS > > > DOES > > > > > > > include them in the response, is it a protocol error? > > > > > > > > > > > > > > example: > > > > > > > > > > > > > > Request: > > > > > > > > > > > > > > To: el.sipo@sipworld.sip > > > > > > > > > > > > > > Response: > > > > > > > > > > > > > > To: > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > > Use sip-implementors@cs.columbia.edu for questions on current > sip > > > > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 08:12:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17055 for ; Fri, 10 May 2002 08:12:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12381 for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:12:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11467; Fri, 10 May 2002 07:47:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08913 for ; Fri, 10 May 2002 06:40:20 -0400 (EDT) Received: from hotmail.com (f8.law11.hotmail.com [64.4.17.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12987 for ; Fri, 10 May 2002 06:40:10 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 May 2002 03:39:49 -0700 Received: from 47.234.0.52 by lw11fd.law11.hotmail.msn.com with HTTP; Fri, 10 May 2002 10:39:49 GMT X-Originating-IP: [47.234.0.52] From: "sushanth hegde" To: sip@ietf.org Date: Fri, 10 May 2002 10:39:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 May 2002 10:39:49.0782 (UTC) FILETIME=[02C61B60:01C1F80F] Subject: [Sip] Queries regd sIP in 3G Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Greetings, Few queries regarding SIP in 3GPP. 1. In a 3G architecture where exactly does each component of a SIP Server (i.e Proxy,Registrar etc) fit in? In other words what is the mapping between SIP Server Architecture and 3G Architecture 2. Does the SIP User Agent Reside in the 3G enabled Mobile phone? if not where does a SIP User Agent reside? 3. Any reference sites which gives me more information regarding SIP in 3G. Thank you in Anticipation. Regards, Sushanth _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 08:38:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18290 for ; Fri, 10 May 2002 08:38:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13537 for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:38:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12747; Fri, 10 May 2002 08:26:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12709 for ; Fri, 10 May 2002 08:26:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17664 for ; Fri, 10 May 2002 08:26:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27963 for ; Fri, 10 May 2002 08:25:38 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20332 for ; Fri, 10 May 2002 08:25:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 May 2002 08:25:39 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B52DB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Fri, 10 May 2002 08:25:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] UPDATE and Expires Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This morning, I arrived to find an experimental SIP implementation was "ringing" all night. It's experimental. The UAC that called me died in the middle of the transaction. Still, my end should have given up the call at some point. I go looking for the codesmith. The programmer says "That's correct behavior. Just because the caller died, the UAS got an INVITE, and is waiting for the user to answer before it sends the 200 OK. Since this is user time, there is no good time after which it is okay to abandon the call" I protest "But the UAC died!" And the programmer says "The UAS doesn't know that, as far as it knows, the user at the UAS wants it to keep ringing" And I reach for my copy of bis-09 and say "Ah Ha, why don't we put an Expire header on the Invite, and send 487 if it expires. And CANCEL to boot?" And he says "Sure, but what if the user at the UAC WANTS to wait longer than whatever the Expires says" And I reach for my copy of update-02, ready to say "Send an UPDATE and extend the Expire", but, alas, Expire is not legal on Update. And so I wrote this email Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 08:51:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19102 for ; Fri, 10 May 2002 08:51:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13925 for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:51:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12620; Fri, 10 May 2002 08:23:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12593 for ; Fri, 10 May 2002 08:23:33 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17485 for ; Fri, 10 May 2002 08:23:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4ACKSu2007073; Fri, 10 May 2002 08:20:28 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 08:23:01 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36B4759@DYN-TX-EXCH-001.dynamicsoft.com> From: Andrew Allen To: "'sushanth hegde'" , sip@ietf.org Subject: RE: [Sip] Queries regd sIP in 3G Date: Fri, 10 May 2002 08:22:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org For 3GPP: > -----Original Message----- > From: sushanth hegde [mailto:sushanthh@hotmail.com] > Sent: Friday, May 10, 2002 5:40 AM > To: sip@ietf.org > Subject: [Sip] Queries regd sIP in 3G > > > Greetings, > > Few queries regarding SIP in 3GPP. > > 1. In a 3G architecture where exactly does each component of > a SIP Server > (i.e Proxy,Registrar etc) > fit in? In other words what is the mapping between SIP Server > Architecture and 3G Architecture Best to see TS 24.229 for full explanation http://www.3gpp.org/ftp/specs/latest/Rel-5/24_series/24229-500.zip > > 2. Does the SIP User Agent Reside in the 3G enabled Mobile > phone? if not > where does a SIP User Agent > reside? > Yes a SIP UA resides in the UE (mobile phone) > 3. Any reference sites which gives me more information > regarding SIP in 3G. > Thank you in Anticipation. > Regards, > Sushanth Architecture: http://www.3gpp.org/ftp/specs/latest/Rel-5/23_series/23228-530.zip Call Model: http://www.3gpp.org/ftp/specs/latest/Rel-5/23_series/23218-500.zip Session Flows: http://www.3gpp.org/ftp/specs/latest/Rel-5/24_series/24228-500.zip Protocol: http://www.3gpp.org/ftp/specs/latest/Rel-5/24_series/24229-500.zip Note that the 24 series specs are not yet fully completed and may contain out of date/wrong information and the version numbers (i.e 24229-500) will change after June (to 24.229-510) > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 08:57:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19487 for ; Fri, 10 May 2002 08:57:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA14068 for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:57:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13586; Fri, 10 May 2002 08:38:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13558 for ; Fri, 10 May 2002 08:38:47 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18319 for ; Fri, 10 May 2002 08:38:37 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id NAA30142; Fri, 10 May 2002 13:38:15 +0100 (BST) Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Fri, 10 May 2002 13:37:52 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 10 May 2002 13:38:06 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Fri, 10 May 2002 13:38:06 +0100 Message-Id: To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt Date: Fri, 10 May 2002 13:38:05 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org All, The P-Access-Network-Info header draft (version 01) has been available for some time now, and I have received very few comments related to it. Does this mean there are no problems with the draft? Regards, Duncan -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 03 May 2002 12:28 To: IETF-Announce Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Access Network Info header Author(s) : D. Mills Filename : draft-mills-sip-access-network-info-01.txt Pages : 5 Date : 02-May-02 This document defines the private SIP extension header P-Access-Network-Info. This mechanism is useful in SIP networks that are partitioned, such as 3G wireless networks which are partitioned at the SIP layer into 'access' and 'home' networks. SIP User Agents may use this header to relay information about the access network to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-01.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-mills-sip-access-network-info-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mills-sip-access-network-info-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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 11:21:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28273 for ; Fri, 10 May 2002 11:21:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22517 for sip-archive@odin.ietf.org; Fri, 10 May 2002 11:21:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20795; Fri, 10 May 2002 10:59:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20766 for ; Fri, 10 May 2002 10:59:48 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27009 for ; Fri, 10 May 2002 10:59:38 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AExO813702; Fri, 10 May 2002 09:59:24 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 09:59:47 -0500 Message-ID: From: "Sriram Parameswar" To: "'Rosen, Brian'" , "'sip@ietf.org'" Subject: RE: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 09:59:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F833.4E79CBF0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F833.4E79CBF0 Content-Type: text/plain; charset="iso-8859-1" What if you do not control the UAC - and he does not put an Expires header into the INVITE. Would your UAS then continue to ring for ever? I think the implementation of the UA's will have to perform some sanity timing that is not part of the spec (i.e. Implementation specific). Brian - your point is still valid. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, May 10, 2002 7:26 AM To: 'sip@ietf.org' Subject: [Sip] UPDATE and Expires This morning, I arrived to find an experimental SIP implementation was "ringing" all night. It's experimental. The UAC that called me died in the middle of the transaction. Still, my end should have given up the call at some point. I go looking for the codesmith. The programmer says "That's correct behavior. Just because the caller died, the UAS got an INVITE, and is waiting for the user to answer before it sends the 200 OK. Since this is user time, there is no good time after which it is okay to abandon the call" I protest "But the UAC died!" And the programmer says "The UAS doesn't know that, as far as it knows, the user at the UAS wants it to keep ringing" And I reach for my copy of bis-09 and say "Ah Ha, why don't we put an Expire header on the Invite, and send 487 if it expires. And CANCEL to boot?" And he says "Sure, but what if the user at the UAC WANTS to wait longer than whatever the Expires says" And I reach for my copy of update-02, ready to say "Send an UPDATE and extend the Expire", but, alas, Expire is not legal on Update. And so I wrote this email Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C1F833.4E79CBF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] UPDATE and Expires

What if you do not control the UAC - and he does not = put an Expires header into the INVITE. Would your UAS then continue to = ring for ever? I think the implementation of the UA's will have to = perform some sanity timing that is not part of the spec (i.e. = Implementation specific).

Brian - your point is still valid.

Thanks,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 10, 2002 7:26 AM
To: 'sip@ietf.org'
Subject: [Sip] UPDATE and Expires


This morning, I arrived to find an experimental SIP = implementation
was "ringing" all night.  It's = experimental.  The UAC that called
me died in the middle of the transaction.  = Still, my end should
have given up the call at some point.  I go = looking for the
codesmith.

The programmer says "That's correct = behavior.  Just because the
caller died, the UAS got an INVITE, and is waiting = for the user to
answer before it sends the 200 OK.  Since this = is user time,
there is no good time after which it is okay to = abandon the call"

I protest "But the UAC died!"

And the programmer says "The UAS doesn't know = that, as far as it knows,
the user at the UAS wants it to keep = ringing"

And I reach for my copy of bis-09 and say "Ah = Ha, why don't we put
an Expire header on the Invite, and send 487 if it = expires.  And
CANCEL to boot?"

And he says "Sure, but what if the user at the = UAC WANTS to wait
longer than whatever the Expires says"

And I reach for my copy of update-02, ready to say = "Send an UPDATE
and extend the Expire", but, alas, Expire is = not legal on
Update.

And so I wrote this email

Brian

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = Protocol
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sipping@ietf.org for new developments on the = application of sip

------_=_NextPart_001_01C1F833.4E79CBF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 11:35:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29200 for ; Fri, 10 May 2002 11:35:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24030 for sip-archive@odin.ietf.org; Fri, 10 May 2002 11:36:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22286; Fri, 10 May 2002 11:17:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22255 for ; Fri, 10 May 2002 11:17:45 -0400 (EDT) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28018 for ; Fri, 10 May 2002 11:17:35 -0400 (EDT) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4AFHcX27906; Fri, 10 May 2002 11:17:38 -0400 (EDT) Message-ID: <00cf01c1f835$d2469240$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: "Rosen, Brian" , References: <313680C9A886D511A06000204840E1CF030B52DB@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 11:17:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I would second Brian's suggestion in this case. We should make use of a timer (which can be configured by the user in the UAC -- very much like number of rings in a PSTN phone beforethe control goes to the answering machine) so that the phone doesnt keep ringing all night or for that matter whole month if Brian is vacationing :-) > And he says "Sure, but what if the user at the UAC WANTS to wait > longer than whatever the Expires says" > this doesnt make sense. In a PSTN line you know that if the call is not picked up in 5 rings, then it goes to the answering machine. If the UAC wants to wait longer then he should adjust the timer of the UAC accordingly. > And I reach for my copy of update-02, ready to say "Send an UPDATE > and extend the Expire", but, alas, Expire is not legal on > Update. > is it really neccessary to do this ? think of the overheads in real time scenario. Most of the time this will happen when the user is not on his seat, a very few times he would want to wait longer so why to complicate the matter ? I still feel that a use of a simple counter at the UAC should suffice. Any further thoughts ? Thanx, Prabhas. ----- Original Message ----- From: "Rosen, Brian" To: Sent: Friday, May 10, 2002 8:25 AM Subject: [Sip] UPDATE and Expires > This morning, I arrived to find an experimental SIP implementation > was "ringing" all night. It's experimental. The UAC that called > me died in the middle of the transaction. Still, my end should > have given up the call at some point. I go looking for the > codesmith. > > The programmer says "That's correct behavior. Just because the > caller died, the UAS got an INVITE, and is waiting for the user to > answer before it sends the 200 OK. Since this is user time, > there is no good time after which it is okay to abandon the call" > > I protest "But the UAC died!" > > And the programmer says "The UAS doesn't know that, as far as it knows, > the user at the UAS wants it to keep ringing" > > And I reach for my copy of bis-09 and say "Ah Ha, why don't we put > an Expire header on the Invite, and send 487 if it expires. And > CANCEL to boot?" > > And he says "Sure, but what if the user at the UAC WANTS to wait > longer than whatever the Expires says" > > And I reach for my copy of update-02, ready to say "Send an UPDATE > and extend the Expire", but, alas, Expire is not legal on > Update. > > And so I wrote this email > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 12:31:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02868 for ; Fri, 10 May 2002 12:31:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28128 for sip-archive@odin.ietf.org; Fri, 10 May 2002 12:31:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26600; Fri, 10 May 2002 12:08:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26568 for ; Fri, 10 May 2002 12:08:34 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01255 for ; Fri, 10 May 2002 12:08:23 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4AG83d13632; Fri, 10 May 2002 11:08:03 -0500 From: "Dean Willis" To: "'sushanth hegde'" , Subject: RE: [Sip] Queries regd sIP in 3G Date: Fri, 10 May 2002 11:07:43 -0500 Message-ID: <005c01c1f83c$d16a37d0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of sushanth hegde > Sent: Friday, May 10, 2002 5:40 AM > To: sip@ietf.org > Subject: [Sip] Queries regd sIP in 3G > > > Greetings, > > Few queries regarding SIP in 3GPP. > > 1. In a 3G architecture where exactly does each component of > a SIP Server > (i.e Proxy,Registrar etc) > fit in? In other words what is the mapping between SIP Server > Architecture and 3G Architecture Depends on which 3G architecture. 3GPP and 3GPP2 are slightly different. > > 2. Does the SIP User Agent Reside in the 3G enabled Mobile > phone? if not > where does a SIP User Agent > reside? Yes, for both 3GPP and 3GPP2. Ther MAY also be a UA in other locations. > 3. Any reference sites which gives me more information > regarding SIP in 3G. Thank you in Anticipation. Regards, Sushanth http://www.3gpp.org/ http://www.3gpp2.org/ There should also be a nice tutorial presentation made by Arjun during the SIP Summit earlier this week, available soon at http://www.pulver.com/ -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 12:39:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03554 for ; Fri, 10 May 2002 12:39:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28597 for sip-archive@odin.ietf.org; Fri, 10 May 2002 12:39:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26697; Fri, 10 May 2002 12:09:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26667 for ; Fri, 10 May 2002 12:09:56 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01329 for ; Fri, 10 May 2002 12:09:45 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id LAA02503 for ; Fri, 10 May 2002 11:15:49 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Fri, 10 May 2002 11:05:21 -0500 Received: from bculpepperpc ([151.214.151.115]) by 172.16.16.64; Fri, 10 May 2002 11:09:10 -0500 From: "Bert Culpepper" To: "'Prabhas Sinha'" , "'Rosen, Brian'" , Subject: RE: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 12:08:33 -0400 Message-ID: <006901c1f83c$efc0ca00$7397d697@bculpepperpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <00cf01c1f835$d2469240$743c0198@ecew2k.ncsu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit comment inline... Prabhas Sinha wrote: > > I would second Brian's suggestion in this case. We should > make use of a > timer (which can be configured by the user in the UAC -- very > much like > number of rings in a PSTN phone beforethe control goes to the > answering > machine) so that the phone doesnt keep ringing all night or > for that matter > whole month if Brian is vacationing :-) > > > And he says "Sure, but what if the user at the UAC WANTS to wait > > longer than whatever the Expires says" > > > > this doesnt make sense. In a PSTN line you know that if the > call is not > picked up in 5 rings, then it goes to the answering machine. > If the UAC > wants to wait longer then he should adjust the timer of the > UAC accordingly. I agree, see below. > > > And I reach for my copy of update-02, ready to say "Send an UPDATE > > and extend the Expire", but, alas, Expire is not legal on > > Update. > > > > is it really neccessary to do this ? think of the overheads > in real time > scenario. Most of the time this will happen when the user is > not on his > seat, a very few times he would want to wait longer so why to > complicate the > matter ? I would think the caller will have an idea of how long he/she wants to wait for answer, and set the value of the Expires header accordingly in the INVITE request. However, if the caller's UA doesn't support this and it crashes, then I believe it's an implementation issue for the UAS. Or when the callee answers the call, current defined protocol behavior (no ACK received) will suffice here. Regards, Bert > > I still feel that a use of a simple counter at the UAC should suffice. > > Any further thoughts ? > > Thanx, > Prabhas. > > ----- Original Message ----- > From: "Rosen, Brian" > To: > Sent: Friday, May 10, 2002 8:25 AM > Subject: [Sip] UPDATE and Expires > > > > This morning, I arrived to find an experimental SIP implementation > > was "ringing" all night. It's experimental. The UAC that called > > me died in the middle of the transaction. Still, my end should > > have given up the call at some point. I go looking for the > > codesmith. > > > > The programmer says "That's correct behavior. Just because the > > caller died, the UAS got an INVITE, and is waiting for the user to > > answer before it sends the 200 OK. Since this is user time, > > there is no good time after which it is okay to abandon the call" > > > > I protest "But the UAC died!" > > > > And the programmer says "The UAS doesn't know that, as far > as it knows, > > the user at the UAS wants it to keep ringing" > > > > And I reach for my copy of bis-09 and say "Ah Ha, why don't we put > > an Expire header on the Invite, and send 487 if it expires. And > > CANCEL to boot?" > > > > And he says "Sure, but what if the user at the UAC WANTS to wait > > longer than whatever the Expires says" > > > > And I reach for my copy of update-02, ready to say "Send an UPDATE > > and extend the Expire", but, alas, Expire is not legal on > > Update. > > > > And so I wrote this email > > > > Brian > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 13:33:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06883 for ; Fri, 10 May 2002 13:33:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01955 for sip-archive@odin.ietf.org; Fri, 10 May 2002 13:33:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00051; Fri, 10 May 2002 13:05:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00022 for ; Fri, 10 May 2002 13:05:51 -0400 (EDT) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05183 for ; Fri, 10 May 2002 13:05:41 -0400 (EDT) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4AH5nK23690; Fri, 10 May 2002 13:05:50 -0400 (EDT) Message-ID: <01f301c1f844$ef57fc70$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: "Bert Culpepper" , "'Rosen, Brian'" , References: <006901c1f83c$efc0ca00$7397d697@bculpepperpc> Subject: Re: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 13:05:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I would think the caller will have an idea of how long he/she wants to wait > for answer, and set the value of the Expires header accordingly in the > INVITE request. However, if the caller's UA doesn't support this and it > crashes, then I believe it's an implementation issue for the UAS. Or when > the callee answers the call, current defined protocol behavior (no ACK > received) will suffice here. > > Regards, > Bert > on the contrary, why dont dont we support it from the callee end like PSTN ? If the callee is not at his seat, then why to hold up the resources until caller's "Expire" header? Think of the performance when there are millions of users hitting this bend and blocking the resources for more than actually needed. If I know that I am not available then I can configure my UAC somehow to inform the caller on the very first ring that I am not able to pick up the phone. I am just thinking it on the lines of PSTN operation -- its not the caller who decides how long the call should be presented but its the callee's phone which handles it. If the current bis doesnt support it then we might wanna bring in a minor extension to handle this. Does it sound ok ? Prabhas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 14:02:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08703 for ; Fri, 10 May 2002 14:02:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03607 for sip-archive@odin.ietf.org; Fri, 10 May 2002 14:02:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02215; Fri, 10 May 2002 13:38:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02184 for ; Fri, 10 May 2002 13:38:15 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07272 for ; Fri, 10 May 2002 13:38:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06242; Fri, 10 May 2002 13:37:42 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22669; Fri, 10 May 2002 13:37:43 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 May 2002 13:37:43 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Prabhas Sinha'" , Bert Culpepper , sip@ietf.org Subject: RE: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 13:37:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Pick up your phone and dial a number without a message system. It will ring quite a while (not forever). Mine waits multiple minutes. The problem with making assumptions on how long to time out is that it's the user, not the UAC, that knows how long is long enough. What do you want to do, have him type in a timer length? Yes, you can use a timer on either end, but it needs to be on the order of minutes, not seconds, and it does not express the wishes of either the caller or the callee. It's the system designer (or administrator if it's programmable)'s idea of how long is enough. Note that in SIP, there are no messages passing while you are waiting. Of course, I want there to be a few (UPDATE with Expire), just so that the called party knows the calling party still thinks it ought to be ringing. Then the expiry can be on the order of seconds. Brian > -----Original Message----- > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > Sent: Friday, May 10, 2002 1:06 PM > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org > Subject: Re: [Sip] UPDATE and Expires > > > > I would think the caller will have an idea of how long > he/she wants to > wait > > for answer, and set the value of the Expires header > accordingly in the > > INVITE request. However, if the caller's UA doesn't > support this and it > > crashes, then I believe it's an implementation issue for > the UAS. Or when > > the callee answers the call, current defined protocol > behavior (no ACK > > received) will suffice here. > > > > Regards, > > Bert > > > > on the contrary, why dont dont we support it from the callee > end like PSTN ? > If the callee is not at his seat, then why to hold up the > resources until > caller's "Expire" header? > Think of the performance when there are millions of users > hitting this bend > and blocking the resources for more than actually needed. > If I know that I am not available then I can configure my UAC > somehow to > inform the caller on the very first ring that > I am not able to pick up the phone. I am just thinking it on > the lines of > PSTN operation -- its not the caller who decides how long the > call should be > presented > but its the callee's phone which handles it. If the current bis doesnt > support it then we might wanna bring in a minor extension to > handle this. > > Does it sound ok ? > > Prabhas > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 14:46:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11442 for ; Fri, 10 May 2002 14:46:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05698 for sip-archive@odin.ietf.org; Fri, 10 May 2002 14:46:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04725; Fri, 10 May 2002 14:27:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04170 for ; Fri, 10 May 2002 14:14:53 -0400 (EDT) Received: from dnvrpop4.dnvr.uswest.net (dnvrpop4.dnvr.uswest.net [206.196.128.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09498 for ; Fri, 10 May 2002 14:14:43 -0400 (EDT) Received: (qmail 46681 invoked by uid 0); 10 May 2002 18:14:47 -0000 Received: from unknown (HELO MAYUSKO) (64.19.189.253) by dnvrpop4.dnvr.uswest.net with SMTP; 10 May 2002 18:14:47 -0000 Date: Fri, 10 May 2002 14:14:46 -0400 Message-ID: <000001c1f84e$91ac4bd0$30330a0a@MAYUSKO> From: "Mark J. Yusko" To: sip-admin@ietf.org, "'Prabhas Sinha'" , "'Bert Culpepper'" , sip@ietf.org Reply-To: Subject: RE: [Sip] UPDATE and Expires MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA04171 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] > Sent: Friday, May 10, 2002 1:38 PM > To: 'Prabhas Sinha'; Bert Culpepper; sip@ietf.org > Subject: RE: [Sip] UPDATE and Expires > > Pick up your phone and dial a number without > a message system. > It will ring quite a while (not forever). Mine > waits multiple minutes. I believe some class 4 switches (AT&T) have a 2 minute timeout for ringing. With 1 ring = 6 seconds, that's 20 rings. > The problem with making assumptions on how long to > time out is that it's the user, not the UAC, that > knows how long is long enough. > What do you want to do, have him type in a timer > length? > Yes, you can use a timer on either end, but it needs > to be on the order of minutes, not seconds, and it > does not express the wishes of either the caller or > the callee. It's the system designer (or > administrator if it's programmable)'s idea of how > long is enough. > > Note that in SIP, there are no messages passing > while you are waiting. Of course, I want there to > be a few (UPDATE with Expire), just so that the > called party knows the calling party still thinks it > ought to be ringing. Then the expiry can be on the > order of seconds. > > Brian > > -----Original Message----- > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > Sent: Friday, May 10, 2002 1:06 PM > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org > Subject: Re: [Sip] UPDATE and Expires > > > > I would think the caller will have an idea of how long > he/she wants to > wait > > for answer, and set the value of the Expires header > accordingly in the > > INVITE request. However, if the caller's UA doesn't > support this and it > > crashes, then I believe it's an implementation issue for > the UAS. Or when > > the callee answers the call, current defined protocol > behavior (no ACK > > received) will suffice here. > > > > Regards, > > Bert > > > > on the contrary, why dont dont we support it from the callee > end like PSTN ? > If the callee is not at his seat, then why to hold up the > resources until > caller's "Expire" header? > Think of the performance when there are millions of users > hitting this bend > and blocking the resources for more than actually needed. > If I know that I am not available then I can configure my UAC > somehow to > inform the caller on the very first ring that > I am not able to pick up the phone. I am just thinking it on > the lines of > PSTN operation -- its not the caller who decides how long the > call should be > presented > but its the callee's phone which handles it. If the current bis doesnt > support it then we might wanna bring in a minor extension to > handle this. > > Does it sound ok ? > > Prabhas > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 14:46:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11460 for ; Fri, 10 May 2002 14:46:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05745 for sip-archive@odin.ietf.org; Fri, 10 May 2002 14:47:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04708; Fri, 10 May 2002 14:27:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04673 for ; Fri, 10 May 2002 14:27:35 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10270 for ; Fri, 10 May 2002 14:27:25 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4AIR3x01579 for ; Fri, 10 May 2002 14:27:03 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 19:27:02 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E9D9@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "'Bob Penfield'" , "'Miguel A. Garcia'" Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR, sip@ietf.org, bernhard.honeisen@nokia.com Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 Date: Fri, 10 May 2002 19:27:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The only issue I can think of would concern any responsibility or not for sorting out the best order of visiting this UA inserted proxy versus any others. If I follow the current procedures, then any UA inserted URL would be the last proxy visited on any incoming dialog to the UA. This would be after visiting any proxy inserted URLs. If this meets Bob's requirements then fine, but I do not want to see any proxy requirement or registrar requirement for reordering the Path list. Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 07 May 2002 19:07 > To: 'Bob Penfield'; 'Miguel A. Garcia' > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; > bernhard.honeisen@nokia.com > Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05 > > > Bob asked: > > A prior e-mail said that a UA was not allowed include a Path > > header. Is there a particular reason we want to prohibit the > > UA from contributing to the path? I can't think of a > > particular example, but a UA could know that a specific > > element needs to be on the inbound path, and that element may > > not be in the register path (just like a proxy adding "a Path > > element referencing another node" as described in section 4.2). > > That's a reasonable question. It's not consistent with the original > intent, but on first analysis, I can't think of a real reason > that this > COULDN'T be done. Anybody else out there have an opinion? > > > Remainder snipped as not relevant to this issue. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 15:16:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13045 for ; Fri, 10 May 2002 15:16:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06845 for sip-archive@odin.ietf.org; Fri, 10 May 2002 15:16:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05919; Fri, 10 May 2002 14:52:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05880 for ; Fri, 10 May 2002 14:52:11 -0400 (EDT) Received: from webmail10.rediffmail.com (webmail10.rediffmail.com [202.54.124.179] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11698 for ; Fri, 10 May 2002 14:52:01 -0400 (EDT) Received: (qmail 10931 invoked by uid 510); 10 May 2002 18:52:12 -0000 Date: 10 May 2002 18:52:12 -0000 Message-ID: <20020510185212.10930.qmail@webmail10.rediffmail.com> Received: from unknown (130.245.6.29) by rediffmail.com via HTTP; 10 May 2002 18:52:12 -0000 MIME-Version: 1.0 From: "nitin khosla" Reply-To: "nitin khosla" To: sip@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Sip] SIP transaction machine problem... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello everybody, I have mailed so many times but nobody seems to reply. I am a student and trying to verify SIP protocol. I started with transaction machines and then moving upward. I had some problems regarding the functioning of the same...... what happens if: a) Timer B fires and client goes in termination state. Server is in completed state retransmitting response. Now till now client could not recieve any of responses but just after it(client) terminates, one response reaches client from the server (3xx). What will client do then. It is not specified there in transaction machine. b) One BIGGER problem , what if client is in proceeding state and seerver terminates due to timer H. It just hangs because client keeps on waiting for final response. THERE is NO timeout in client's proceeding state. So it seemed to me a bug. I hope somebody do reply for my problem so that I could model it correctly because nothing is written about it in either INVITE Client - INVITE server transaction machines as far as i know. If it's written please refer me the place too..... thanks nitin _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 16:16:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15524 for ; Fri, 10 May 2002 16:16:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10640 for sip-archive@odin.ietf.org; Fri, 10 May 2002 16:16:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09770; Fri, 10 May 2002 16:01:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09723 for ; Fri, 10 May 2002 16:01:05 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14984 for ; Fri, 10 May 2002 16:00:55 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4AK4VV01769; Fri, 10 May 2002 15:04:31 -0500 From: Robert Sparks To: sip@ietf.org, Jon Peterson Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 10 May 2002 14:58:23 -0500 Message-Id: <1021060703.2011.235.camel@dhcp152.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Comment on sip-identity-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Paragraph 2 of 4.2 binds the username part of credentials (such as DIGEST credentials) to an identity represented as a SIP URI by algorithmically placing that username into the user portion of the URI. This instead should be policy at the authentication service. That service knows how to bind whatever credentials it was given to an identity. Presumably, since it is a SIP identity service, it knows how to express that identity as a SIP URI. Using the algorithm suggested will create problems for existing realms where the username "alice" is owned by someone other than the person who owns "alice@atlanta.com". It also wouldn't work for other credentialing methods where the analog of username isn't syntactically valid for the user portion of a SIP URI. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 16:17:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15559 for ; Fri, 10 May 2002 16:17:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10716 for sip-archive@odin.ietf.org; Fri, 10 May 2002 16:17:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09910; Fri, 10 May 2002 16:01:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09878 for ; Fri, 10 May 2002 16:01:31 -0400 (EDT) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15002 for ; Fri, 10 May 2002 16:01:17 -0400 (EDT) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4AK1PN03734; Fri, 10 May 2002 16:01:25 -0400 (EDT) Message-ID: <048201c1f85d$76ffff20$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: "Rosen, Brian" , "Bert Culpepper" , References: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 16:01:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am not sure if Tom's reply reached all, just sending it for your information. ----- Original Message ----- From: To: Cc: "Prabhas Sinha" Sent: Friday, May 10, 2002 1:13 PM Subject: Re: [Sip] UPDATE and Expires > > CPL provides the functionality that you recommend. Calls can be declined with > reasons given either to everyone or to specific individuals > > ----- Original Message ----- From: "Rosen, Brian" To: "'Prabhas Sinha'" ; "Bert Culpepper" ; Sent: Friday, May 10, 2002 1:37 PM Subject: RE: [Sip] UPDATE and Expires > Pick up your phone and dial a number without a message system. > It will ring quite a while (not forever). Mine waits multiple minutes. > The problem with making assumptions on how long to time out is > that it's the user, not the UAC, that knows how long is long enough. > What do you want to do, have him type in a timer length? > Yes, you can use a timer on either end, but it needs to be on the > order of minutes, not seconds, and it does not express the wishes > of either the caller or the callee. It's the system designer (or > administrator if it's programmable)'s idea of how long is enough. > > Note that in SIP, there are no messages passing while you are > waiting. Of course, I want there to be a few (UPDATE with > Expire), just so that the called party knows the calling party > still thinks it ought to be ringing. Then the expiry can be > on the order of seconds. > > Brian > > > -----Original Message----- > > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > > Sent: Friday, May 10, 2002 1:06 PM > > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org > > Subject: Re: [Sip] UPDATE and Expires > > > > > > > I would think the caller will have an idea of how long > > he/she wants to > > wait > > > for answer, and set the value of the Expires header > > accordingly in the > > > INVITE request. However, if the caller's UA doesn't > > support this and it > > > crashes, then I believe it's an implementation issue for > > the UAS. Or when > > > the callee answers the call, current defined protocol > > behavior (no ACK > > > received) will suffice here. > > > > > > Regards, > > > Bert > > > > > > > on the contrary, why dont dont we support it from the callee > > end like PSTN ? > > If the callee is not at his seat, then why to hold up the > > resources until > > caller's "Expire" header? > > Think of the performance when there are millions of users > > hitting this bend > > and blocking the resources for more than actually needed. > > If I know that I am not available then I can configure my UAC > > somehow to > > inform the caller on the very first ring that > > I am not able to pick up the phone. I am just thinking it on > > the lines of > > PSTN operation -- its not the caller who decides how long the > > call should be > > presented > > but its the callee's phone which handles it. If the current bis doesnt > > support it then we might wanna bring in a minor extension to > > handle this. > > > > Does it sound ok ? > > > > Prabhas > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 16:20:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15658 for ; Fri, 10 May 2002 16:20:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10845 for sip-archive@odin.ietf.org; Fri, 10 May 2002 16:20:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10305; Fri, 10 May 2002 16:07:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10274 for ; Fri, 10 May 2002 16:07:25 -0400 (EDT) Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15256 for ; Fri, 10 May 2002 16:07:15 -0400 (EDT) Received: from ganga ([12.217.176.37]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020510200649.OTXV1219.sccmmhc01.mchsi.com@ganga> for ; Fri, 10 May 2002 20:06:49 +0000 From: "P. Vijay" To: Subject: RE: [Sip] UPDATE and Expires Date: Fri, 10 May 2002 15:06:47 -0500 Message-ID: <000801c1f85e$378ebc40$6601a8c0@mchsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think the solution is either a policy decision implemented at the SIP service provider level or a basic addition to the INVITE/TRYING/RINGING/OK/ACK message flow. I am for using INVITE expires and letting the SP decide on (a) using its internal timer or expires, whichever is lesser and (b) resetting the timer when it receives an UPDATE. The call is cleared when the timer expires. This is based on reasons given below. In the traditional telehpony world, answer timers (the time between start of ringing and a valid answer) are (typically) set to avoid holding up bandwidth for unbillable calls. This is especially true for inband signalling. Even for out-of-band signaling, ISDN/ISUP, etc., the protocol DEFINES timers between the state when the called party acknowledges (180) the call (INVITE) and the state when a valid answer (200)is received. If the timer expires, then the call is cleared by the caller. In reality, the call is cleared by the switch that handles the caller's CPE (even that is a gross simplification, but it will do). In fact, the tandems with the lowest configured answer timers clear the call and propagate the clearing in both directions. The important point here is that this behaviour is a codification of what is seen as good policy (i.e, don't waste resources, etc.), not necessarily essential for call control. In this case, the problem arose because the caller (UAC) died after sending INVITE and UAS did not detect the client death. Can that not be handled at the trasport (tcp timers, heartbeats, etc.) and clear the call? In the case where the UAC is alive and keeps waiting for the 200, either UAS or the called (UAS/UAC) could clear the call as described above. I have seen answer timers cause problems in regular telephony services, so putting in mandatory timers (a-la ISDN or ISUP) would be a hindrance. However, SP's need policies, preferably encoded in RFC's, that allow for both call terminations on ring-no-answer and possibly extending the timer (e.g. via UPDATE). SIP does not have to codify an answer timer, although it may be a good idea to do provide some guidance. Also, the timer can be exchanged in SDP, except it would need to be sent in TRYING or RINGING. In the absence of a timer, the matter of detecting a crashed device needs to addressed. --Vijay-- > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Rosen, > Brian > Sent: Friday, May 10, 2002 12:38 PM > To: 'Prabhas Sinha'; Bert Culpepper; sip@ietf.org > Subject: RE: [Sip] UPDATE and Expires > > > Pick up your phone and dial a number without a message system. > It will ring quite a while (not forever). Mine waits > multiple minutes. > The problem with making assumptions on how long to time out is > that it's the user, not the UAC, that knows how long is long enough. > What do you want to do, have him type in a timer length? > Yes, you can use a timer on either end, but it needs to be on the > order of minutes, not seconds, and it does not express the wishes > of either the caller or the callee. It's the system designer (or > administrator if it's programmable)'s idea of how long is enough. > > Note that in SIP, there are no messages passing while you are > waiting. Of course, I want there to be a few (UPDATE with > Expire), just so that the called party knows the calling party > still thinks it ought to be ringing. Then the expiry can be > on the order of seconds. > > Brian > > > -----Original Message----- > > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > > Sent: Friday, May 10, 2002 1:06 PM > > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org > > Subject: Re: [Sip] UPDATE and Expires > > > > > > > I would think the caller will have an idea of how long > > he/she wants to > > wait > > > for answer, and set the value of the Expires header > > accordingly in the > > > INVITE request. However, if the caller's UA doesn't > > support this and it > > > crashes, then I believe it's an implementation issue for > > the UAS. Or when > > > the callee answers the call, current defined protocol > > behavior (no ACK > > > received) will suffice here. > > > > > > Regards, > > > Bert > > > > > > > on the contrary, why dont dont we support it from the callee > > end like PSTN ? > > If the callee is not at his seat, then why to hold up the > > resources until > > caller's "Expire" header? > > Think of the performance when there are millions of users > > hitting this bend > > and blocking the resources for more than actually needed. > > If I know that I am not available then I can configure my UAC > > somehow to > > inform the caller on the very first ring that > > I am not able to pick up the phone. I am just thinking it on > > the lines of > > PSTN operation -- its not the caller who decides how long the > > call should be > > presented > > but its the callee's phone which handles it. If the current > bis doesnt > > support it then we might wanna bring in a minor extension to > > handle this. > > > > Does it sound ok ? > > > > Prabhas > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 10 17:01:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17500 for ; Fri, 10 May 2002 17:01:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13712 for sip-archive@odin.ietf.org; Fri, 10 May 2002 17:01:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11931; Fri, 10 May 2002 16:37:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11900 for ; Fri, 10 May 2002 16:37:23 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16266 for ; Fri, 10 May 2002 16:37:12 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AF81304E0254; Fri, 10 May 2002 16:37:21 -0400 Message-ID: <007301c1f862$a79926c0$2300000a@acmepacket.com> From: "Bob Penfield" To: , References: Subject: Re: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt Date: Fri, 10 May 2002 16:38:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, 1) The examples given in section 4 (a laptop in an airport or hotel) do not sound like access networks that will provide the "transitive trust" required to protect privacy as described in section 6. Are these really valid examples for usage of this header? Or are you assuming that this would only work for local ISPs and airports that had a business relationship with the home network? How does the UA know if these types of access networks can be trusted? 2) Does this draft need an explicit Applicability Statement? 3) Section 6 says: The serving proxy MUST delete this header before forwarding the message outside of the its domain. but section 7 says: A serving proxy, typically located in the home network, and therefore trusted, SHOULD delete the header when the SIP signaling is forwarded beyond the home network domain and section 8 says: This header SHOULD always be deleted by the serving network prior to forwarding it outside of the home network domain, as described in section 7. Is it MUST or SHOULD? Also, I think it is sufficient to have the MUST or SHOULD once (in the Proxy behavior section) or maybe twice, and then say "...serving proxies will delete..." in other places you need to talk about it. I realize it is very important. 4) The document has weird characters where single quotes (i.e. ') should be. 5) You say "... where the access-type is æ3GPP-GERANÆ, the access-info SHALL be "3GPP-CGI".", but go on to says the mapping of access-type to access-info is defined elsewhere. Can you provide a reference? Also, I don't think you should use the requirements language (SHALL) for an example like this. If there are mapping requirement, they should all be included or you should refer to a document that defines them. 6) The period is missing between 'request' and 'The' in section 7.1 "... SIP message request The UAC SHOULD ..." 7) Section 7.1, 2nd paragraph. Should "the nature or the information" be "the nature *of* the information"? 8) Section 7.2 is labeled "UAS behavior", but talks only about proxy behavior. I don't think there is any UAS behavior for this header. 9) In section 7.2 you say the proxy "MAY use the contents to, e.g., provide ...". I suggest you remove the "e.g." and say something like "... MAY use the contents to provide a different service or apply performance enhancement measures depending on the network through which the UA is accessing the server. For example, ....". cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: To: Sent: Friday, May 10, 2002 8:38 AM Subject: RE: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt > All, > > The P-Access-Network-Info header draft (version 01) has been available for > some time now, and I have received very few comments related to it. > > Does this mean there are no problems with the draft? > > Regards, > > Duncan > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 03 May 2002 12:28 > To: IETF-Announce > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The SIP Access Network Info header > Author(s) : D. Mills > Filename : draft-mills-sip-access-network-info-01.txt > Pages : 5 > Date : 02-May-02 > > This document defines the private SIP extension header > P-Access-Network-Info. This mechanism is useful in SIP networks that > are partitioned, such as 3G wireless networks which are partitioned at > the SIP layer into 'access' and 'home' networks. SIP User Agents may > use this header to relay information about the access network to > serving proxies in their home network. The serving proxy may then use > this information to optimize services for the UA. For example, a 3GPP > terminal uses this header to pass information about the access network > such as radio access technology and cell ID to its home service. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-01.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-mills-sip-access-network-info-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: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mills-sip-access-network-info-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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 11 02:33:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19232 for ; Sat, 11 May 2002 02:33:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12511 for sip-archive@odin.ietf.org; Sat, 11 May 2002 02:33:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11108; Sat, 11 May 2002 01:49:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11083 for ; Sat, 11 May 2002 01:49:14 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09872 for ; Sat, 11 May 2002 01:49:03 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 176PkX-0001Ei-00; Sat, 11 May 2002 08:48:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15580.45257.417255.716250@harjus.eng.song.fi> Date: Sat, 11 May 2002 08:48:57 +0300 To: Robert Sparks Cc: sip@ietf.org, Jon Peterson Subject: [Sip] Comment on sip-identity-00 In-Reply-To: <1021060703.2011.235.camel@dhcp152.dfw.dynamicsoft.com> References: <1021060703.2011.235.camel@dhcp152.dfw.dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit there seems to be lots of confusion about what "authenticated identity" of a sip user is. in our network it is simply the Network Access Identity (NAI) of the user, e.g., foo@bar.com. that same NAI is used for all services the user has subscribed to, e.g., email, remote access, and sip, and thus is not sip specific. the NAI does necessarily have NOTHING to do with the sip uri that the user registers and want to be known by. for example, the user with NAI foo@bar.com may want to register a sip uri sip:+358333983900@bar.com or several sip uris of that or other sort. the user specifically may NOT want to register as sip:foo@bar.com. my conclusion of all this is that the authentication server must verify both the NAI of the user and the sip uri of the user that the user has placed in the from header or, in case of an anonymous call, in some other header of the message. it seems to me that for the other parties to which the message is forwarded to, it is enough that the authenticated sip uri is included in the message. regarding the i-d on the subject line, the distinction between the NAI and sip uris of the user should be clarified before we can go on. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 04:36:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00686 for ; Mon, 13 May 2002 04:36:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17518 for sip-archive@odin.ietf.org; Mon, 13 May 2002 04:36:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15793; Mon, 13 May 2002 04:13:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15762 for ; Mon, 13 May 2002 04:13:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00243 for ; Mon, 13 May 2002 04:12:50 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4D8Cw0E025308; Mon, 13 May 2002 10:12:58 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4D8Cv9q024756; Mon, 13 May 2002 11:12:57 +0300 (EET DST) Message-ID: <3CDF7583.CF7745A7@lmf.ericsson.se> Date: Mon, 13 May 2002 11:12:51 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: vishal , sip@ietf.org Subject: Re: [Sip] Header comparision References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> <3CDB905B.4CA150B7@lmf.ericsson.se> <001101c1f805$4a4d7640$5601a8c0@knowsys.net> <3CDB9C61.3FF7FC4F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer, as you have pointed out, the comparison rules for To and From header felds are not properly defined in bis. You have to perform URI comparison. Therefore, user names and angle brakets do not affect the comparison. This will be clarified in subsequent versions of the spec. Regards, Gonzalo Christer Holmberg wrote: > > Hi, > > > Hi christer , > > I am trying to say that ....YES IT REALLY MATTERS ,if From field does not > > exactly matches then it is an error .Another question is ....why UAS will > > add angular brackets ...and why UAC will further check different syntax > > available after receiving message sent by UAS?? > > > > best solution is to compare From field as was sent in initial request . > > Yes, you can do a pure binary comparision, but that also requires the order the > uri parameters are the same, there is no case difference etc. > > Why I would want to do this or that (I didn't even said I would) really doesn't > matter. I am just trying to get a clarification on the angle bracket case, the > uri parameter order case, and the case sensitivity case, for header mapping > within a transaction... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > regards, vishal > > > > ----- Original Message ----- > > From: Christer Holmberg > > To: vishal > > Cc: Madhusudhan ; > > Sent: Friday, May 10, 2002 2:48 PM > > Subject: Re: [Sip] Header comparision > > > > > > > > Hi, > > > > > > I know what chapter 8.2.6.2 says, but my question was if it really also > > affects > > > the angle brackets. > > > > > > Another related issue: chapter 19.1.4 says that the uri parameter ordering > > is > > > not significant for URI comparision, but according to chapter 8.2.6.2 the > > uri > > > parameter ordering would have to match in a request/response transaction. > > > > > > Also, from a URI comparision point of view, some parts of the URI are > > > case-insensitive. But, does it mean that within a transaction everything > > is > > > case-sensitive? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > > > > vishal wrote: > > > > > > > Hi christer, > > > > From,To,Call-Id ,Cseq fields of sip response MUST exactly match > > > > corresponding request.If it does not match exactly ,then it should be > > > > protocol error . > > > > > > > > Reason: > > > > you dont require addition checking while copying these fields . > > > > > > > > case you described , > > > > To: el.sipo@sipworld.sip and > > > > To: are equivalent ,not equal. > > > > > > > > please refer to sip bis 09 section 8.2.6.2 below > > > > > > > > "8.2.6.2 Headers and Tags > > > > > > > > The From field of the response MUST equal the From header field of > > > > the request. The Call-ID header field of the response MUST equal the > > > > Call-ID header field of the request. The CSeq header field of the > > > > response MUST equal the CSeq field of the request. The Via header > > > > field values in the response MUST equal the Via header field values > > > > in the request and MUST maintain the same ordering. > > > > > > > > If a request contained a To tag in the request, the To header field > > > > in the response MUST equal that of the request. However, if the To > > > > header field in the request did not contain a tag, the URI in the To > > > > header field in the response MUST equal the URI in the To header > > > > field; additionally, the UAS MUST add a tag to the To header field in > > > > the response (with the exception of the 100 (Trying) response, in > > > > which a tag MAY be present)" > > > > > > > > regards, vishal > > > > > > > > ----- Original Message ----- > > > > From: Christer Holmberg > > > > To: Madhusudhan > > > > Cc: > > > > Sent: Friday, May 10, 2002 1:35 PM > > > > Subject: Re: [Sip] Header comparision > > > > > > > > > > > > > > Hi Madhusudhan, > > > > > > > > > > Thanks for your comments! > > > > > > > > > > However, I think we are talking about two separate issues. > > > > > > > > > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle > > > > brackets, > > > > > but that does NOT mean you aren't allowed to enclose the URI in angle > > > > brackets > > > > > ALSO in other cases. For example: > > > > > > > > > > To: > > > > > > > > > > ...is allowed from a SIP syntax point of view. > > > > > > > > > > However, my question was related to the COMPARISION of headers. > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > Madhusudhan wrote: > > > > > > > > > > > Hi > > > > > > > > > > > > Section 20 of bis09 mentions > > > > > > > > > > > > "The Contact, From, and To header fields contain a URI. If the URI > > > > > > contains a comma, question mark or semicolon, the URI MUST be > > > > > > enclosed in angle brackets (< and >). Any URI parameters are > > > > > > contained within these brackets. If the URI is not enclosed in > > angle > > > > > > brackets, any semicolon-delimited parameters are > > header-parameters, > > > > > > not URI parameters" > > > > > > > > > > > > From the above comments, I think it is evident that the two > > addresses > > > > are > > > > > > different. > > > > > > > > > > > > correct me if I am wrong!!! > > > > > > > > > > > > Regards > > > > > > > > > > > > Madhusudhan > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Christer Holmberg" > > > > > > > To: > > > > > > > Sent: Friday, May 10, 2002 12:11 PM > > > > > > > Subject: [Sip] Header comparision > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I have a small clarification question on To- and From header > > > > > > > > comparision. > > > > > > > > > > > > > > > > Chapter 8.2.6.2 says: > > > > > > > > > > > > > > > > "The From field of the response MUST equal the From header field > > of > > > > > > > > the request." > > > > > > > > > > > > > > > > Later in the chapter it explains the use of tags. > > > > > > > > > > > > > > > > However, there is nothing said (not in the URI comparision > > chapter > > > > > > > > either) about the "<" and ">" characters, so my question is: > > > > > > > > > > > > > > > > If the UAC doesn't include "<" and ">" in the request, and the > > UAS > > > > DOES > > > > > > > > include them in the response, is it a protocol error? > > > > > > > > > > > > > > > > example: > > > > > > > > > > > > > > > > Request: > > > > > > > > > > > > > > > > To: el.sipo@sipworld.sip > > > > > > > > > > > > > > > > Response: > > > > > > > > > > > > > > > > To: > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > > > Use sip-implementors@cs.columbia.edu for questions on current > > sip > > > > > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 05:27:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00684 for ; Mon, 13 May 2002 04:36:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17511 for sip-archive@odin.ietf.org; Mon, 13 May 2002 04:36:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15487; Mon, 13 May 2002 04:07:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15451 for ; Mon, 13 May 2002 04:06:50 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00130 for ; Mon, 13 May 2002 04:06:37 -0400 (EDT) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g4D84MH20413 for ; Mon, 13 May 2002 13:34:24 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256BB8.002C8725 ; Mon, 13 May 2002 13:36:21 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256BB8.002C85D5.00@sampark.hss.hns.com> Date: Mon, 13 May 2002 13:36:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Clarity in ACK authentication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Quoting bis-09 (Line 4860-4861) : "UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds." My interpretation of the above is (Correct me if i am wrong): a. The method used to compute the response digest in the ACK request should be "INVITE" and not "ACK". b. The nonce-count in the ACK should be the same as that of INVITE though it is a different request. In other words, is it that servers are not supposed to treat such requests as replay attacks even though a previous request arrived with the exact same nonce-count ? This is fine in case of stateful proxies, but are stateless proxies also expected to maintain such state information to determine whether the ACK credentials are valid ? Thanks in advance, Subhash Nayak U. Hughes Software Systems http://www.hssworld.com This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 12:45:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19264 for ; Mon, 13 May 2002 12:45:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13089 for sip-archive@odin.ietf.org; Mon, 13 May 2002 12:45:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11880; Mon, 13 May 2002 12:24:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11849 for ; Mon, 13 May 2002 12:24:16 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18529 for ; Mon, 13 May 2002 12:24:03 -0400 (EDT) From: Ignacio.Almar@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DGN8Y20883 for ; Mon, 13 May 2002 19:23:09 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 May 2002 19:24:13 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 19:24:13 +0300 Received: from maebe001.NOE.Nokia.com ([10.209.0.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 13 May 2002 19:24:13 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 13 May 2002 18:24:12 +0200 Message-ID: <05C8D36DA4EF684D8BD4E309B1CD5AF166DFC7@maebe001.NOE.Nokia.com> Thread-Topic: Sending SOAP over SIP Thread-Index: AcH6mpYY7FIHkWaUEdaaLQAAhlfbdw== To: X-OriginalArrivalTime: 13 May 2002 16:24:13.0681 (UTC) FILETIME=[9EA81E10:01C1FA9A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11850 Subject: [Sip] Sending SOAP over SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit hi all, Thanks in advance. To send SOAP over HTTP, the tag 'SOAPAction' is sent in the HTTP headers when sending SOAP requests to identify the intent of the request. This header can be used by the Firewalls and Proxies to filter the SOAP Message. In HTTP this field is defined as mandatory, so the client MUST include this field in the HTTP header when sending a SOAP message. SOAP can be sent over HTTP as a ContentType=text/xml, and over SIP with the same content type. In SIP, to allow the appropiate filtering by proxies there should be defined a SOAPAction field as mandatory in the client request. Do you think if there is something defined regarding this ? Another option to let the proxies identify that a SOAP message is inside the SIP message would be to define a ContentType=text/soap+xml, but I think that this is not defined currently in IANA. Note that I am trying to avoid the use of a proprietary format, but I am pointing a general format of sending SOAP over SIP. And also, I am referring to individual sessionless calls, including the SOAP code in a single SIP call, not using a SIP call to establish a session (INVITE) and afterwards send a message using HTTP. Br, Ignacio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 14:47:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25869 for ; Mon, 13 May 2002 14:47:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18700 for sip-archive@odin.ietf.org; Mon, 13 May 2002 14:48:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17767; Mon, 13 May 2002 14:29:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17735 for ; Mon, 13 May 2002 14:29:06 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24878 for ; Mon, 13 May 2002 14:28:52 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4DISXd10382; Mon, 13 May 2002 13:28:34 -0500 Message-ID: <031e01c1faab$feb9ddf0$133fed0c@C1893415A> From: "Dean Willis" To: "Dean Willis" , Cc: "'Rohan Mahy'" , "'Allison Mankin'" , , , Subject: Oops: Closed: Re: [Sip] WGLC for Refer Draft Date: Mon, 13 May 2002 13:28:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ok, I'm a little slow, the final changes are reflected in -03, not -02. -- Dean ----- Original Message ----- From: "Dean Willis" To: "Dean Willis" ; Cc: "'Rohan Mahy'" ; "'Allison Mankin'" ; ; ; Sent: Monday, May 13, 2002 1:23 PM Subject: Closed: Re: [Sip] WGLC for Refer Draft > Ok, we're moving this to IETF last call now. > > Working group comments were addressed and the document reissued as > draft-ietf-sip-refer-02. > > -- > Dean > > ----- Original Message ----- > From: "Dean Willis" > To: > Cc: "'Rohan Mahy'" ; "'Allison Mankin'" > ; ; ; > > Sent: Thursday, May 02, 2002 5:31 PM > Subject: [Sip] WGLC for Refer Draft > > > > > > I'd like to request Working Group Last Call for the REFER method. > > > > The current version is availabe as: > > > > > http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-split-00.tx > > t > > > > Or > > > > > http://search.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.t > > xt > > > > > > We need to close this by app May 21, so get your comments in. Please > > copy the list AND Rober tSparks, who will consolidate responses. > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 14:52:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26113 for ; Mon, 13 May 2002 14:52:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18893 for sip-archive@odin.ietf.org; Mon, 13 May 2002 14:52:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17554; Mon, 13 May 2002 14:23:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17524 for ; Mon, 13 May 2002 14:23:43 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24027 for ; Mon, 13 May 2002 14:23:26 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4DIR7V17230; Mon, 13 May 2002 13:27:07 -0500 From: Robert Sparks To: Robert Sparks Cc: "'Dean Willis'" , sip@ietf.org, Brian Rosen , Joerg Ott In-Reply-To: <1020818249.1320.53.camel@localhost.localdomain> References: <1020818249.1320.53.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 13 May 2002 13:18:49 -0500 Message-Id: <1021313930.1227.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Ending WGLC SIP MIME Types Registration Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There has been only one comment on the MIME types registration draft in the last ten days. As such, I would like to close last call on this document and allow it to proceed to IETF last call. The following change will be incorporated along with comments from IETF last call. RjS On Tue, 2002-05-07 at 19:37, Robert Sparks wrote: > Ok. > > The right way to say this is to call to > section 7.4.1 of bis-09/rfc3261 for what is required > if a body is present. I'll make that change. > > RjS > > On Tue, 2002-05-07 at 16:47, Sriram Parameswar wrote: > > Hi: > > > > Quoting section 1 "If the message/sipfrag part contains a body, it must > > also contain a Content-Length header and the null-line separating > > headers from the body." > > > > I think it would be a good idea to include the Content-Type and possibly > > other Content related headers (Content-Encoding, Content-Language etc.) > > - as a SHOULD strength. I am not sure what good it would do, to get a > > body without the requisite information to extract its true meaning. > > > > Thanks, > > > > Sriram > > > > __________________________________________ > > Sriram Parameswar Phone: 972-685-8540 > > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > > > > -----Original Message----- > > From: Dean Willis [ mailto:dwillis@dynamicsoft.com > > ] > > Sent: Thursday, May 02, 2002 5:32 PM > > To: sip@ietf.org > > Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison Mankin'; > > jo@ipdialog.com; rsparks@dynamicsoft.com > > Subject: [Sip] WGLC SIP MME Types Registration Draft > > > > > > I'd like to request WGLC of the SIP MIME type registration draft. > > > > The current version can be found at: > > > > http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt > > > > > > > > Or > > > > http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt > > > t> > > > > > > > > We'd like to close WGLC by about May 21. > > > > Please copy comments to the list and to Robert Sparks, who will > > coordinate further efforts. > > > > -- > > Dean > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 15:35:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28503 for ; Mon, 13 May 2002 15:35:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21482 for sip-archive@odin.ietf.org; Mon, 13 May 2002 15:36:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20399; Mon, 13 May 2002 15:16:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20370 for ; Mon, 13 May 2002 15:16:42 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27407 for ; Mon, 13 May 2002 15:16:28 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4DJGbX11506; Mon, 13 May 2002 14:16:37 -0500 (CDT) From: "Ben Campbell" To: "Sip" , "Simple" Cc: "Robert Sparks" , "Jon Peterson" , "Dean Willis" , "Brian. Rosen@Marconi. Com" , "Jo@Ipdialog. Com" Date: Mon, 13 May 2002 14:16:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Message draft changes Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, I submitted draft-ietf-sip-message-04 last week. This version contains a few AD requested changes, primarily in the area of congestion control. Specifically: 1) Added an applicability statement clarifying the difference between the pager and session models, and that this draft only defines the pager model. 2) Strengthened the congestion control section: * 1300 byte hard limit for physical payload size for pager model. This applies to the actual payload only, not indirect content. Fragmenting content across multiple requests is prohibited for pager model. * Overlapping MESSAGE requests outside of dialog but to same request-URI are prohibited. * Overlapping MESSAGE requests inside a dialog are prohibited unless every hop of the dialog uses a congestion-controlled transport, in which case the strength is SHOULD NOT. 3) Trimmed the author list and added contributor section. I do not believe we need to do another WGLC for these changes. Any new feedback to 04 can be captured as part of the IETF last call. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt Thanks! Ben. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 16:21:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01031 for ; Mon, 13 May 2002 16:21:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23840 for sip-archive@odin.ietf.org; Mon, 13 May 2002 16:21:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22820; Mon, 13 May 2002 16:04:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22772 for ; Mon, 13 May 2002 16:04:42 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29936 for ; Mon, 13 May 2002 16:04:28 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DK4B816872; Mon, 13 May 2002 15:04:11 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 15:04:46 -0500 Message-ID: From: "Sriram Parameswar" To: "'rohan@cisco.com'" Cc: "'sip@ietf.org'" Date: Mon, 13 May 2002 15:04:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FAB9.62FC4C00" Subject: [Sip] Comments :draft-ietf-sip-replaces-01.txt (Re-post) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FAB9.62FC4C00 Content-Type: text/plain; charset="iso-8859-1" Hi, I had sent these comments prior to the Las Vegas Ad-Hoc, have not seen any of discussion on this draft on the list. Just re-posting one more time. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Nortel Networks Rohan, Some comments: (1)Section 4.1 says "In other words the to-tag is compared to the local tag, and the from-tag is compared to the remote tag." However in section 5.2 INV/200 estalish from-tag (operator) = 7743 and to-tag (Call Center) = 6472. However the call from the customer to Call Center has Replaces:425928@dhcp23311.acme.com;to-tag=7743;from-tag=6472, thus the Call Center will _not_ be able to match correctly based on sections 4.1 rule. (2) Section 5.2 the NOTIFY sent to from Customer to Operator when the Customer receives 182 (Queued). Then this transaction is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to Operator as shown - it will result in a 481. (3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he BYE's the call with Alice. Then at the bottom of call Flow, Alice tries to send a NOTIFY for the REFER, this will result in a 481. (3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to C2. (4) Section 5.6, just for grins, how does Alice get the Replaces information to replace the dialog between Bob and Old Timer :). Thats what I have from my initial reading. Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C1FAB9.62FC4C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments :draft-ietf-sip-replaces-01.txt (Re-post)

Hi,

I had sent these comments prior to the Las Vegas = Ad-Hoc, have not seen any of discussion on this draft on the list. Just = re-posting one more time.

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Nortel Networks

Rohan,

Some comments:

(1)Section 4.1 says "In other words the to-tag = is compared to the local tag, and the from-tag is compared to the = remote tag." However in section 5.2 INV/200 estalish from-tag = (operator) =3D 7743 and to-tag (Call Center) =3D 6472. However the call = from the customer to Call Center has = Replaces:425928@dhcp23311.acme.com;to-tag=3D7743;from-tag=3D6472, thus = the Call Center will _not_ be able to match correctly based on sections = 4.1 rule.

(2) Section 5.2 the NOTIFY sent to from Customer to = Operator when the Customer receives 182 (Queued). Then this transaction = is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to = Operator as shown - it will result in a 481.

(3) Same for section 5.7 (and section 5.8) - once Bob = gets a 687, he BYE's the call with Alice. Then at the bottom of call = Flow, Alice tries to send a NOTIFY for the REFER, this will result in a = 481.

(3) Section 5.8 Invite from Proxy (forking Alice) = INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to = C2.

(4) Section 5.6, just for grins, how does Alice get = the Replaces information to replace the dialog between Bob and Old = Timer :).

Thats what I have from my initial reading.

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C1FAB9.62FC4C00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 19:52:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09828 for ; Mon, 13 May 2002 19:52:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04778 for sip-archive@odin.ietf.org; Mon, 13 May 2002 19:52:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04494; Mon, 13 May 2002 19:36:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04453 for ; Mon, 13 May 2002 19:35:52 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09431 for ; Mon, 13 May 2002 19:35:38 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4DNZId12166; Mon, 13 May 2002 18:35:18 -0500 Message-ID: <004c01c1fad6$da23d010$133fed0c@C1893415A> From: "Dean Willis" To: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, Cc: "Bernhard Honeisen" , "Brian Rosen" , , Date: Mon, 13 May 2002 18:35:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revised draft: draft-willis-sip-path-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bernie and I have revised the Path draft to account (I think) for all comments received during WGLC. The latest version is available at: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.html http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.xml Note: Insertion of this draft into the internet-drafts list should be announced to the SIP working group. Note that one of the big changes was using the term "header field" to refer to what is colloquially called a "header" and "header field value" for an element that might go into a header field. There were also significant enhancement to the security considerations section and general editing to correct typos and use consistent terminology. Thanks for all the feedback, folks. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 21:38:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13434 for ; Mon, 13 May 2002 21:38:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10391 for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:38:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27147; Mon, 13 May 2002 07:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27105 for ; Mon, 13 May 2002 07:49:02 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04391 for ; Mon, 13 May 2002 07:48:44 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DBmGt11274; Mon, 13 May 2002 13:48:16 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DBlQX05613; Mon, 13 May 2002 12:47:30 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 12:48:59 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" , Robert Sparks Cc: sip@ietf.org, Jon Peterson Subject: RE: [Sip] Comment on sip-identity-00 Date: Mon, 13 May 2002 12:48:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FA74.2543D5BC" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FA74.2543D5BC Content-Type: text/plain; charset="iso-8859-1" Before we get too confused, 'Network Asserted Identity' - which we have been discussing for some time and for which draft-ietf-sipping-nai-reqs-00 presents requirements, is a different and in principle unrelated topic from Network Access Identifier in the AAA sense, despite sharing the same acronym. There may of course be local policies of Authentication Services which relate these two, but this is of no importance to us here, which I think is Juha's point below. To avoid such confusion, it he been suggested that we do not use Network-Asserted-Identity: as the header name. 'Asserted-Identity:' is currently top of the poll. If you don't like this header name, 'speak now or forever hold your peace'. ...Mark > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 11 May 2002 06:49 > To: Robert Sparks > Cc: sip@ietf.org; Jon Peterson > Subject: [Sip] Comment on sip-identity-00 > > > there seems to be lots of confusion about what "authenticated > identity" > of a sip user is. in our network it is simply the Network Access > Identity (NAI) of the user, e.g., foo@bar.com. that same NAI is used > for all services the user has subscribed to, e.g., email, > remote access, > and sip, and thus is not sip specific. > > the NAI does necessarily have NOTHING to do with the sip uri that the > user registers and want to be known by. for example, the > user with NAI > foo@bar.com may want to register a sip uri > sip:+358333983900@bar.com or > several sip uris of that or other sort. the user specifically may NOT > want to register as sip:foo@bar.com. > > my conclusion of all this is that the authentication server > must verify > both the NAI of the user and the sip uri of the user that the user has > placed in the from header or, in case of an anonymous call, in some > other header of the message. it seems to me that for the > other parties > to which the message is forwarded to, it is enough that the > authenticated sip uri is included in the message. > > regarding the i-d on the subject line, the distinction between the NAI > and sip uris of the user should be clarified before we can go on. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1FA74.2543D5BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Comment on sip-identity-00

Before we get too confused, 'Network Asserted = Identity' - which we have been discussing for some time and for which = draft-ietf-sipping-nai-reqs-00 presents requirements, is a different = and in principle unrelated topic from Network Access Identifier in the = AAA sense, despite sharing the same acronym.

There may of course be local policies of = Authentication Services which relate these two, but this is of no = importance to us here, which I think is Juha's point below.

To avoid such confusion, it he been suggested that we = do not use Network-Asserted-Identity: as the header name. = 'Asserted-Identity:' is currently top of the poll. If you don't like = this header name, 'speak now or forever hold your peace'.

...Mark



> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 11 May 2002 06:49
> To: Robert Sparks
> Cc: sip@ietf.org; Jon Peterson
> Subject: [Sip] Comment on = sip-identity-00
>
>
> there seems to be lots of confusion about what = "authenticated
> identity"
> of a sip user is.  in our network it is = simply the Network Access
> Identity (NAI) of the user, e.g., = foo@bar.com.  that same NAI is used
> for all services the user has subscribed to, = e.g., email,
> remote access,
> and sip, and thus is not sip specific.
>
> the NAI does necessarily have NOTHING to do = with the sip uri that the
> user registers and want to be known by.  = for example, the
> user with NAI
> foo@bar.com may want to register a sip uri =
> sip:+358333983900@bar.com or
> several sip uris of that or other sort.  = the user specifically may NOT
> want to register as sip:foo@bar.com.
>
> my conclusion of all this is that the = authentication server
> must verify
> both the NAI of the user and the sip uri of the = user that the user has
> placed in the from header or, in case of an = anonymous call, in some
> other header of the message.  it seems to = me that for the
> other parties
> to which the message is forwarded to, it is = enough that the
> authenticated sip uri is included in the = message.
>
> regarding the i-d on the subject line, the = distinction between the NAI
> and sip uris of the user should be clarified = before we can go on.
>
> -- juha
>
>
> _______________________________________________<= /FONT>
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1FA74.2543D5BC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 21:38:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13459 for ; Mon, 13 May 2002 21:38:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10443 for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:39:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17598; Mon, 13 May 2002 14:24:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17567 for ; Mon, 13 May 2002 14:24:17 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24039 for ; Mon, 13 May 2002 14:23:52 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4DINXd10348; Mon, 13 May 2002 13:23:33 -0500 Message-ID: <031801c1faab$4b784790$133fed0c@C1893415A> From: "Dean Willis" To: "Dean Willis" , Cc: "'Rohan Mahy'" , "'Allison Mankin'" , , , References: <00b101c1f229$22ae8c50$1e036e3f@TXDWILLIS2> Subject: Closed: Re: [Sip] WGLC for Refer Draft Date: Mon, 13 May 2002 13:23:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, we're moving this to IETF last call now. Working group comments were addressed and the document reissued as draft-ietf-sip-refer-02. -- Dean ----- Original Message ----- From: "Dean Willis" To: Cc: "'Rohan Mahy'" ; "'Allison Mankin'" ; ; ; Sent: Thursday, May 02, 2002 5:31 PM Subject: [Sip] WGLC for Refer Draft > > I'd like to request Working Group Last Call for the REFER method. > > The current version is availabe as: > > http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-split-00.tx > t > > Or > > http://search.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.t > xt > > > We need to close this by app May 21, so get your comments in. Please > copy the list AND Rober tSparks, who will consolidate responses. > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 21:41:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13543 for ; Mon, 13 May 2002 21:41:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10599 for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:42:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29802; Mon, 13 May 2002 08:42:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29770 for ; Mon, 13 May 2002 08:42:16 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06938 for ; Mon, 13 May 2002 08:42:03 -0400 (EDT) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 177F9J-0001n7-00; Mon, 13 May 2002 15:41:57 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15583.46229.215256.863288@lohi.eng.song.fi> Date: Mon, 13 May 2002 15:41:57 +0300 To: "Mark Watson" Cc: Robert Sparks , sip@ietf.org, Jon Peterson Subject: RE: [Sip] Comment on sip-identity-00 In-Reply-To: References: X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit mark, the point of my message was not the same of the header field, but what you mean by network asserted indetify and how it relates to the any number of sip uris that the user may have. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 13 21:42:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13563 for ; Mon, 13 May 2002 21:42:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10614 for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:42:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11965; Mon, 13 May 2002 12:25:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11906 for ; Mon, 13 May 2002 12:25:12 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18566 for ; Mon, 13 May 2002 12:24:59 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4DGOYI27696; Mon, 13 May 2002 11:24:34 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 11:24:29 -0500 Message-ID: <70565611B164D511957A001083FCDD56018702E0@va02.va.neustar.com> From: "Peterson, Jon" To: "'Robert Sparks'" , sip@ietf.org Date: Mon, 13 May 2002 11:24:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Comment on sip-identity-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org These are good points; throughout the identity draft, I tried to use Digest only as an example, and indeed in plenty of authentication systems the identifier of a user would not be suitable syntactically or semantically for the username portion of a SIP URI. I do think it is not unreasonable, however, in systems like Digest for a user to have an expectation that the username they enter into an authentication dialog (for example) will be the username that appears in their authenticated identity. However, there is as you suggest no need for this to be mandated normatively by the standard. Perhaps we could add some language to 4.2 that would explain some of these issues. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, May 10, 2002 12:58 PM > To: sip@ietf.org; Jon Peterson > Subject: Comment on sip-identity-00 > > > Paragraph 2 of 4.2 binds the username part of > credentials (such as DIGEST credentials) to an > identity represented as a SIP URI by algorithmically > placing that username into the user portion of the URI. > > This instead should be policy at the authentication > service. That service knows how to bind whatever > credentials it was given to an identity. Presumably, > since it is a SIP identity service, it knows how to > express that identity as a SIP URI. > > Using the algorithm suggested will create problems > for existing realms where the username "alice" is > owned by someone other than the person who owns > "alice@atlanta.com". It also wouldn't work for > other credentialing methods where the analog of > username isn't syntactically valid for the user > portion of a SIP URI. > > RjS > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 14 03:44:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07270 for ; Tue, 14 May 2002 03:44:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13677 for sip-archive@odin.ietf.org; Tue, 14 May 2002 03:44:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11162; Tue, 14 May 2002 03:08:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11097 for ; Tue, 14 May 2002 03:07:51 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05540 for ; Tue, 14 May 2002 03:07:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4E77js7023186; Tue, 14 May 2002 09:07:45 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4E77i9q005278; Tue, 14 May 2002 10:07:44 +0300 (EET DST) Message-ID: <3CE0B7C0.C4A1F003@lmf.ericsson.se> Date: Tue, 14 May 2002 10:07:44 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip CC: Sanjoy Sen , "'tao.haukka@nokia.com'" , Jari.Arkko@lmf.ericsson.se, vesa.torvinen@lmf.ericsson.se References: <933FADF5E673D411B8A30002A5608A0E03A63273@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Version 01 of sec-agree just released Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, We have just released a new version of the security agreement draft. Until it appears in the archives, you can fecth it from: http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sec-agree-01.txt We have incorporated all the feedback that we received during the interim meeting in Las Vegas. The syntax has been fixed and now it follows the general syntax for SIP extensions. We have also narrowed down the scope of the draft. Now it only solves the security negotation between the UA and the first-hop proxy. Thanks to this limitation in the scope of the solution, we have been able to remove any URI, host name or IP address in the security header fields (the old and controversial to and from parameters within these header fields). We have also added a couple of examples that illustrate the use of the mechanism described in the draft. As usual, feedback on this document is appreciated. Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 11:08:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22645 for ; Tue, 14 May 2002 11:08:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16357 for sip-archive@odin.ietf.org; Tue, 14 May 2002 11:08:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14308; Tue, 14 May 2002 10:40:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14276 for ; Tue, 14 May 2002 10:40:44 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21630 for ; Tue, 14 May 2002 10:40:29 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4EEeaX94100; Tue, 14 May 2002 09:40:37 -0500 (CDT) From: "Ben Campbell" To: , Subject: RE: [Sip] Message draft changes Date: Tue, 14 May 2002 09:40:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE214@esebe013.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Tuesday, May 14, 2002 4:54 AM > To: sip@ietf.org > Cc: bcampbell@dynamicsoft.com > Subject: RE: [Sip] Message draft changes > > > Hi Ben, > > > I submitted draft-ietf-sip-message-04 last week. This version > > contains a few > > AD requested changes, primarily in the area of congestion control. > > Specifically: > > > > 1) Added an applicability statement clarifying the difference > > between the > > pager and session models, and that this draft only defines > > the pager model. > > > > 2) Strengthened the congestion control section: > > > > * 1300 byte hard limit for physical payload size for pager > > model. This > > applies to the actual payload only, not indirect content. Fragmenting > > content across multiple requests is prohibited for pager model. > > I don't agree with this at all. This sort of hard limit really > hampers the whole IM application. The session mode and paging > mode IM are very different in nature. Session IM is clearly > conversational, whereas paging mode IM much more of a > "shoot-and-forget" type messaging. Now if the selection between > the two is not based on user preference and needs but on payload > size, I don't think this serves the IM users very well. > > Also, 1300 bytes seems awfully little, if I want to send > message/cpim with S/MIME protection. > I understand your concern. The problem is, the IESG is very concerned about the potential for congestion caused by MESSAGE. We initially stated that, if your payload was over 1300 bytes, you must use a congestion-controlled transport. The SIP spec itself says that now, I think. The problem is, outside of a dialog, there is no way to ensure that no hop will traverse UDP. So to allow larger payloads, we would have to solve that problem first. We did not want to make MESSAGE dependent on a solution for that problem. There is work underway to define a mechanism for indirect content. I think we will have to use that for any sort of large content. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 14:46:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00154 for ; Tue, 14 May 2002 14:46:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10271 for sip-archive@odin.ietf.org; Tue, 14 May 2002 14:46:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06835; Tue, 14 May 2002 14:12:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05337 for ; Tue, 14 May 2002 13:45:34 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28112 for ; Tue, 14 May 2002 13:45:20 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AD3C57B200B8; Tue, 14 May 2002 13:45:32 -0400 Message-ID: <001301c1fb6f$4f614180$2300000a@acmepacket.com> From: "Bob Penfield" To: "Robert Sparks" , Date: Tue, 14 May 2002 13:46:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] missing text in draft-ietf-sip-refer-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Robert, Sorry for not reporting this earlier, but I only got a chance to look at the draft today. It appears that a significant chunk of text has been removed from the refer draft that probably needs to be restored: In section 2, immediately after "REFER is a SIP method as defined by RFC3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should" it used to say: contact a third party using the contact information provided in the method. A success response indicates that the recipient was able to contact the third party. Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER MAY be Record-Routed, hence MUST contain a single Contact header. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog. REFERs occurring outside an existing dialog effectively create a new dialog following the behavior of SUBSCRIBE specified [2]. 3.1 The Refer-To Header Refer-To is a request-header as defined by [1]. It may only appear in a REFER request. It provides a URL to reference. The current text makes no sense to me: REFER is a SIP method as defined by RFC3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should be interpreted as if it appeared in Table 3 of RFC 3261. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 14:48:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00277 for ; Tue, 14 May 2002 14:48:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10510 for sip-archive@odin.ietf.org; Tue, 14 May 2002 14:48:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06802; Tue, 14 May 2002 14:12:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05337 for ; Tue, 14 May 2002 13:45:34 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28112 for ; Tue, 14 May 2002 13:45:20 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AD3C57B200B8; Tue, 14 May 2002 13:45:32 -0400 Message-ID: <001301c1fb6f$4f614180$2300000a@acmepacket.com> From: "Bob Penfield" To: "Robert Sparks" , Date: Tue, 14 May 2002 13:46:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] missing text in draft-ietf-sip-refer-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Robert, Sorry for not reporting this earlier, but I only got a chance to look at the draft today. It appears that a significant chunk of text has been removed from the refer draft that probably needs to be restored: In section 2, immediately after "REFER is a SIP method as defined by RFC3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should" it used to say: contact a third party using the contact information provided in the method. A success response indicates that the recipient was able to contact the third party. Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER MAY be Record-Routed, hence MUST contain a single Contact header. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog. REFERs occurring outside an existing dialog effectively create a new dialog following the behavior of SUBSCRIBE specified [2]. 3.1 The Refer-To Header Refer-To is a request-header as defined by [1]. It may only appear in a REFER request. It provides a URL to reference. The current text makes no sense to me: REFER is a SIP method as defined by RFC3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should be interpreted as if it appeared in Table 3 of RFC 3261. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 15:00:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00864 for ; Tue, 14 May 2002 15:00:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11441 for sip-archive@odin.ietf.org; Tue, 14 May 2002 15:00:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09691; Tue, 14 May 2002 14:34:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09657 for ; Tue, 14 May 2002 14:34:31 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29598 for ; Tue, 14 May 2002 14:34:17 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4EIbxV21266 for ; Tue, 14 May 2002 13:37:59 -0500 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 14 May 2002 13:32:29 -0500 Message-Id: <1021401149.1226.10.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] REFER updated to -04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit draft-sparks-sip-refer-split-00 and draft-ietf-sip-refer-03 had a fairly major chunk of text missing. Bob Penfield caught the mistake. I have corrected it have submitted the correction as draft-ietf-sip-refer-04. Until it shows up in the archives, you can get it at http://www.nostrum.com/~rjsparks/draft-ietf-sip-refer-04.txt RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 15:10:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01299 for ; Tue, 14 May 2002 15:10:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12442 for sip-archive@odin.ietf.org; Tue, 14 May 2002 15:10:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10108; Tue, 14 May 2002 14:44:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10077 for ; Tue, 14 May 2002 14:43:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00013; Tue, 14 May 2002 14:43:44 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4EIhQd18638; Tue, 14 May 2002 13:43:26 -0500 Message-ID: <01cb01c1fb77$429f2310$133fed0c@C1893415A> From: "Dean Willis" To: , , Cc: "Bernhard Honeisen" , Date: Tue, 14 May 2002 13:43:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revision of draft-willis-sip-path to version -07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We have previously requested IETF last call on draft-willis-sip-path. Sharp-eyed Vijay found a couple of minor typos that, though previously thought fixed, didn't stay fixed. This annoyed me enough that I fixed them and revved the draft, although there are no technical changes. The version-07 draft can be retrieved from: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.html http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.xml Internet-Drafts -- please post this draft and announce to SIP WG list IESG-Secretary -- please repalce the reference to -06 on the calendar with a reference to -07. Thank you all. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 15:16:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01529 for ; Tue, 14 May 2002 15:16:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12753 for sip-archive@odin.ietf.org; Tue, 14 May 2002 15:16:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11292; Tue, 14 May 2002 14:59:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11261 for ; Tue, 14 May 2002 14:59:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00806; Tue, 14 May 2002 14:59:31 -0400 (EDT) Message-Id: <200205141859.OAA00806@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 14 May 2002 14:59:31 -0400 Subject: [Sip] Last Call: Session Initiation Protocol Extension for Instant Messaging to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider Session Initiation Protocol Extension for Instant Messaging as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 28, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 16:14:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04514 for ; Tue, 14 May 2002 16:14:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20442 for sip-archive@odin.ietf.org; Tue, 14 May 2002 16:14:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16574; Tue, 14 May 2002 15:53:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16546 for ; Tue, 14 May 2002 15:53:37 -0400 (EDT) Received: from smtp6.arnet.com.ar (smtp6.arnet.com.ar [200.45.191.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03313 for ; Tue, 14 May 2002 15:53:21 -0400 (EDT) Received: (qmail 18650 invoked from network); 14 May 2002 19:54:46 -0000 Received: from unknown (HELO arnet.com.ar) (200.45.0.20) by smtp6.arnet.com.ar with SMTP; 14 May 2002 19:54:46 -0000 Received: from mail pickup service by arnet.com.ar with Microsoft SMTPSVC; Tue, 14 May 2002 16:42:45 -0300 Received: from mx2.arnet.com.ar ([200.45.0.3]) by mail2.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Tue, 14 May 2002 16:20:13 -0300 Received: from smtp-mx-02.ti.local ([200.45.48.21]) by mx2.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.357.35); Tue, 14 May 2002 16:20:13 -0300 Received: from loki.ietf.org ([132.151.1.177]) by smtp-mx-02.ti.local with Microsoft SMTPSVC(5.0.2195.4905); Tue, 14 May 2002 16:16:41 -0300 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA11760 for ietf-123-outbound.01@ietf.org; Tue, 14 May 2002 15:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA11633 for ; Tue, 14 May 2002 14:59:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00806; Tue, 14 May 2002 14:59:31 -0400 (EDT) Message-Id: <200205141859.OAA00806@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 14 May 2002 14:59:31 -0400 X-OriginalArrivalTime: 14 May 2002 19:16:42.0093 (UTC) FILETIME=[E13439D0:01C1FB7B] Subject: [Sip] Last Call: Session Initiation Protocol Extension for Instant Messaging to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider Session Initiation Protocol Extension for Instant Messaging as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 28, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 17:47:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08577 for ; Tue, 14 May 2002 17:47:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27315 for sip-archive@odin.ietf.org; Tue, 14 May 2002 17:47:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25755; Tue, 14 May 2002 17:28:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16492 for ; Tue, 14 May 2002 11:09:38 -0400 (EDT) Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22722 for ; Tue, 14 May 2002 11:09:22 -0400 (EDT) Received: from boolard ([10.37.1.56]) by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g4EF9XV15696 for ; Tue, 14 May 2002 16:09:33 +0100 From: "Shane McCormack" To: Date: Tue, 14 May 2002 16:11:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] SCTP and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, Just wondering if there is any active work in the area of SIP and SCTP. I would be interested in hearing of any. Thanks Shane _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 17:49:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08653 for ; Tue, 14 May 2002 17:49:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27397 for sip-archive@odin.ietf.org; Tue, 14 May 2002 17:49:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25041; Tue, 14 May 2002 17:20:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25006 for ; Tue, 14 May 2002 17:20:24 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07371 for ; Tue, 14 May 2002 17:20:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4ELHHne015516; Tue, 14 May 2002 17:17:18 -0400 (EDT) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K8ZHHAXT; Tue, 14 May 2002 17:19:52 -0400 Message-ID: <3CE17F78.4050006@dynamicsoft.com> Date: Tue, 14 May 2002 17:19:52 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Revision of draft-willis-sip-path to version -07 References: <01cb01c1fb77$429f2310$133fed0c@C1893415A> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Dean, You're still missing a couple: Line 190 (txt version): "reuqest" Line 253: "vfield" Other nits... Line 46: Does not compute: "The problem is that network topology may be that..." Line 139: is "service proxy" an established term? Why not just "proxy". Line 141: is "transited" really a real word? Line 147: "The proposed Path extension header field...". When becoming RFC it's no longer a proposal. Line 172: 2. The same set of intervening proxies MUST be visited by requests between a home service proxy and the UA. That is, the proxy route between the home service proxy and the UA is the exact reverse of the proxy route between the UA and its registrar. As the draft points out later, this is not, strictly speaking, a condition for applicability. One might end up with a subset of teh path travelled by the REGISTER and also, a proxy might insert addresses other than its own on the Path. Line 198: The primary difference between Path and Record-Route is that Path applies to REGISTER and 200 OK responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility. I'd say the more important difference is that Record-Route applies to the dialog being set by the request it's used in whereas Path is used to establish a route for subsequent requests. Line 153: The UA should include the option tag "path" as a header vfield value in all Supported header fields, and should include a Supported header field in all requests. This make it sound like the path token is optional if the UA inserts a Supported header. I believe it's the case that a Supported header must always include the tokens for all supported extensions. Line 331: However, the Path mechanism should technically work in the absence of UA support (at some compromise to security) I'm not sure I see how a Supported: path header contributes to making this more secure. That is, unless you also assume S/MIME and what have you. BTW, it seems a little schizofrenic to me to say that a registrar may ignore absence of "Supported: path" but a proxy can't. In fact, since the functioning of the Path header doesn't depend on UA cooperation I'm not sure wht it's required at all. Is it so that you get a measure of assurance that the UA/human sending the REGISTER knows that things have inserted themselves on the path of subsequent requests? Line 347: "home service proxy" - again, I'd prefer just proxy or home proxy. Sorry for the late comments. Anders Dean Willis wrote: > We have previously requested IETF last call on draft-willis-sip-path. > > Sharp-eyed Vijay found a couple of minor typos that, though previously > thought fixed, didn't stay fixed. This annoyed me enough that I fixed > them and revved the draft, although there are no technical changes. > > The version-07 draft can be retrieved from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.txt > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.html > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.xml > > Internet-Drafts -- please post this draft and announce to SIP WG list > IESG-Secretary -- please repalce the reference to -06 on the calendar > with a reference to -07. > > Thank you all. > > -- > Dean Willis > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:06:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09204 for ; Tue, 14 May 2002 18:06:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28302 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:06:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24979; Tue, 14 May 2002 06:18:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24919 for ; Tue, 14 May 2002 06:18:44 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11801 for ; Tue, 14 May 2002 06:18:31 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EAIg0E013264 for ; Tue, 14 May 2002 12:18:42 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4EAIg9q018640 for ; Tue, 14 May 2002 13:18:42 +0300 (EET DST) Message-ID: <3CE0E481.6DC961ED@lmf.ericsson.se> Date: Tue, 14 May 2002 13:18:41 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Reason version 01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I have just released version 01 of the Reason draft. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-reason-01.txt Only minor modifications has been done since version 00. Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:12:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09398 for ; Tue, 14 May 2002 18:12:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28460 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:12:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23135; Tue, 14 May 2002 05:54:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23102 for ; Tue, 14 May 2002 05:54:06 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10979 for ; Tue, 14 May 2002 05:53:53 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4E9tPd26645 for ; Tue, 14 May 2002 12:55:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 May 2002 12:54:03 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 14 May 2002 12:54:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Message draft changes Date: Tue, 14 May 2002 12:54:02 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE214@esebe013.NOE.Nokia.com> Thread-Topic: [Sip] Message draft changes Thread-Index: AcH6sug2uHCL58EmRGGSXoJ6S9ed2AAei/dw To: Cc: X-OriginalArrivalTime: 14 May 2002 09:54:03.0357 (UTC) FILETIME=[476DE8D0:01C1FB2D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA23103 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Ben, > I submitted draft-ietf-sip-message-04 last week. This version > contains a few > AD requested changes, primarily in the area of congestion control. > Specifically: > > 1) Added an applicability statement clarifying the difference > between the > pager and session models, and that this draft only defines > the pager model. > > 2) Strengthened the congestion control section: > > * 1300 byte hard limit for physical payload size for pager > model. This > applies to the actual payload only, not indirect content. Fragmenting > content across multiple requests is prohibited for pager model. I don't agree with this at all. This sort of hard limit really hampers the whole IM application. The session mode and paging mode IM are very different in nature. Session IM is clearly conversational, whereas paging mode IM much more of a "shoot-and-forget" type messaging. Now if the selection between the two is not based on user preference and needs but on payload size, I don't think this serves the IM users very well. Also, 1300 bytes seems awfully little, if I want to send message/cpim with S/MIME protection. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:14:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09468 for ; Tue, 14 May 2002 18:14:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28499 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:14:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01974; Tue, 14 May 2002 08:02:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01902 for ; Tue, 14 May 2002 08:02:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14400; Tue, 14 May 2002 08:01:46 -0400 (EDT) Message-Id: <200205141201.IAA14400@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 May 2002 08:01:46 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 Refer Method Author(s) : R. Sparks Filename : draft-ietf-sip-refer-03.txt Pages : 16 Date : 13-May-02 This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. This can be used to enable many applications, including Call Transfer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-03.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-ietf-sip-refer-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020513150509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513150509.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:28:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09797 for ; Tue, 14 May 2002 18:28:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28927 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:29:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24773; Tue, 14 May 2002 06:17:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24717 for ; Tue, 14 May 2002 06:17:13 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11718 for ; Tue, 14 May 2002 06:17:00 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EAH6s7006920; Tue, 14 May 2002 12:17:06 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4EAH59q018502; Tue, 14 May 2002 13:17:05 +0300 (EET DST) Message-ID: <3CE0E420.1A142D27@lmf.ericsson.se> Date: Tue, 14 May 2002 13:17:04 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ignacio.Almar@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Sending SOAP over SIP References: <05C8D36DA4EF684D8BD4E309B1CD5AF166DFC7@maebe001.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, inline: Ignacio.Almar@nokia.com wrote: > > hi all, > > Thanks in advance. > > To send SOAP over HTTP, the tag 'SOAPAction' is sent in the HTTP headers when sending SOAP requests to identify the intent of the request. This header can be used by the Firewalls and Proxies to filter the SOAP Message. In HTTP this field is defined as mandatory, so the client MUST include this field in the HTTP header when sending a SOAP message. SOAP can be sent over HTTP as a ContentType=text/xml, and over SIP with the same content type. > In SIP, to allow the appropiate filtering by proxies there should be defined a SOAPAction field as mandatory in the client request. Do you think if there is something defined regarding this ? I do not think anybody has defined such a header field. > > Another option to let the proxies identify that a SOAP message is inside the SIP message would be to define a ContentType=text/soap+xml, but I think that this is not defined currently in IANA. I do not think this has been registered either. > > Note that I am trying to avoid the use of a proprietary format, but I am pointing a general format of sending SOAP over SIP. And also, I am referring to individual sessionless calls, including the SOAP code in a single SIP call, not using a SIP call to establish a session (INVITE) and afterwards send a message using HTTP. > could you please elaborate on what you mean by "sessionless calls"? I do not understand the last paragraph, but it seems that you want to use SIP only as a transport, without using any of the existing SIP semantics defined in existing methods. Is that right? Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:29:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09842 for ; Tue, 14 May 2002 18:29:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28986 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:29:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20011; Tue, 14 May 2002 11:37:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19873 for ; Tue, 14 May 2002 11:37:04 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23752 for ; Tue, 14 May 2002 11:36:51 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AF15B1001FE; Tue, 14 May 2002 11:36:53 -0400 Message-ID: <000901c1fb5c$a0dd3860$2300000a@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" , "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, Cc: "Bernhard Honeisen" References: <004c01c1fad6$da23d010$133fed0c@C1893415A> Subject: Re: [Sip] Revised draft: draft-willis-sip-path-06 Date: Tue, 14 May 2002 11:32:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here are some comments on the new path draft. Section 1, 1st paragraph: s/p roxies/proxies/ Section 2: There is an inconsistency between the applicability statement (point 2) and the statement in section 4.2 that the path-vector can be discongruent with the route taken by the REGISTER request. I think the statement in 4.2 is fine, but the applicability statement seems to prohibit it. Section 2: Is the MUST in point 2 of the applicability statement an RFC 2119 MUST? Also, does the document need an RFC 2119 terminology section? Section 3, Last paragraph on page 4: Suggest changing "Support for the Path header field may be indicated by...." to "Support for the Path header *is* indicated by..." (or "is usually") since a UA is suppose to include the Supported header to indicate its wiliness to have a path applied. Section 4.1, 2nd paragraph: Does this need to be a normative statement "The UA SHOULD include the option tag..."? Section 4.1, 2nd paragraph: s/vfield/field/ Section 4.2, last paragraph: s/alterany/alter any/ Section 4.2, last sentence: This implies that proxies may alter Path header values, but the table 3 addition on page 5 does not allow it. Under what circumstances would a proxy alter the path values? RFC 3261 allows a proxy to modify Record-Route in a response (according to table 3 & section 16.7), but only the value that the proxy inserted. Do we need a similar requirement here? Section 4.3, 2nd paragraph: Should this note on the lr parameter be moved to section 4.2 since it applies to the proxy rather than the registrar? Section 4.3, 3rd paragraph: Do we need a normative statement here? Say "The RECOMMENDED policy is for the registrar....". Section 4.3, 3rd paragraph: I says a 420 is sent in the response. Shouldn't this be a 421 (Extension Required) because the UA did not include Supported:path. If it sends 420 with Unsupported: path, the UA won't know what to do if it does not understand the path extension. Based on section 4.2, we are assuming that if there is a Require: path present, that an intermediate proxy inserted it. Sending 420 assumes the UA put in Require:path. If there is no Require:path, then 420 is definitely the wrong response. Section 4.5.1: a nit, but the REGISTER responses in the example do not have a To tag as required by RFC 3261. Section 5.1, last paragraph, next to last line: s/that an intermediate has altered/that an intermediate proxy has altered/ Section 5.2, last paragraph: s/In addtion to/In addition to/ cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:40:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10280 for ; Tue, 14 May 2002 18:40:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29888 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:41:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05472; Tue, 14 May 2002 01:37:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05436 for ; Tue, 14 May 2002 01:37:50 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23598 for ; Tue, 14 May 2002 01:37:38 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4E5b7d14049; Tue, 14 May 2002 00:37:07 -0500 Message-ID: <005c01c1fb09$67e4f460$133fed0c@C1893415A> From: "Dean Willis" To: "Cullen Jennings" , "Henrikson, Eric H \(Eric\)" , References: Subject: Re: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt Date: Tue, 14 May 2002 00:37:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The proxy doesn't correlate it. The billing system correlates, using the "original call ID" For example: Here's an example: You go through an S-CSCF, through an anonymizer AS and out to a partner company (but we still want you to be anonymized from them so they don't send you spam later) for gateway services. The partner company sends charging records back. We want to be able to correlate the charging records (keyed by OrigID) with the records written by the S-CSCF. Actually, I just realized that this anonymization trick would be useful for statistical "blind sampling" of the veracity of a partner's billing system. You heard it first here folks! DCS had a very similar header called the DCS billing ID or something like that. -- Dean ----- Original Message ----- From: "Cullen Jennings" To: "Henrikson, Eric H (Eric)" ; "Dean Willis" ; Sent: Monday, May 13, 2002 10:55 PM Subject: RE: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt > > I don't understand why the proxy, P1, that sent the call to the AS (a > B2BUA), would need to correlate the call that came back from the AS with the > original call that P1 sent to the AS. Are there any requirements of what we > are trying to solve here? > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Henrikson, Eric H (Eric) > > Sent: Tuesday, May 07, 2002 9:55 AM > > To: Dean Willis; sip@ietf.org > > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison > > Mankin'; Drage, Keith (Keith) > > Subject: [Sip] Expert Review: > > draft-henrikson-sip-original-dialog-id-01.txt > > > > > > Attached is revision 01 of the original-dialog-id draft. > > > > Please return comments by May 10, 2002. > > > > > > Thank you. > > Eric Henrikson > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, May 01, 2002 6:38 AM > > To: sip@ietf.org > > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison > > Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric) > > Subject: Expert Review: draft-henrikson-sip-original-dialog-id-00.txt > > > > > > > > The SIP working group has been asked to provide expert review of > > draft-henrikson-sip-original-dialog-id. This documents a P-header used > > in 3GPP to associate dialogs across a 3GPP application server acting as > > a back-to-back user agent. > > > > We'd like to complete expert review by May 10, 2002. > > > > Please copy your comments to the list and to Keith Drage and Eric > > Henrikson, who will coordinate responses and edit the draft > > apporpriately. > > > > Thanks, > > > > -- > > Dean Willis > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:42:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10341 for ; Tue, 14 May 2002 18:42:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29917 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:42:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12920; Tue, 14 May 2002 10:24:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12878 for ; Tue, 14 May 2002 10:24:00 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20892 for ; Tue, 14 May 2002 10:23:46 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EENDs7017024; Tue, 14 May 2002 16:23:13 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4EENC9q005028; Tue, 14 May 2002 17:23:12 +0300 (EET DST) Message-ID: <3CE11DD0.7987A687@lmf.ericsson.se> Date: Tue, 14 May 2002 17:23:12 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Hogg CC: "'sip@ietf.org'" , "'wtm@research.att.com'" , "'Gonzalo.Camarillo@ericsson.com'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Clarification of Manyfolks-07 and "local" pre-conditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, No, it is not a bug in the spec. It is mandated to add two current status *LINES*. If you are only using local preconditions, the remote status lines will NOT have the value mandatory. About the possibility of having multiple preconditions of different types for the same media line, it is mentioned in the spec. The section you are referring to is the explanation of the mechanism, and it is kept simple so that people understand it better. I believe it is better to explain how preconditions of one type work and then say that you can have multiple types than trying to explain everything together from the beginning. Regards, Gonzalo Chris Hogg wrote: > > Hi everyone, > > I've been having a read through of the latest version of Manyfolks > (Manyfolks-07) and would like to clarify a number of parts of the > text. > > From section 5.1.1 "SDP encoding" > > "For the segmented status type, the user agent MUST generate two > current status lines: one with the tag "local" and the other with the > tag "remote". The user agent MUST add one or two desired status lines > per segment (i.e., local and remote)." > > And from section 9 "Unknown Precondition type" > > "A UA that receives an unknown precondition-type > with a "mandatory" strength-tag in an offer MUST refuse the offer > unless the only unknown mandatory preconditions have the "local" tag. > > In this case, the UA does not need to be involved in order to meet > the preconditions. The UA will ask for confirmation of the > preconditions and, when the confirmation arrives, it will resume > session establishment." > > From my understanding I thought that the text in section 9 regarding > the ability of the UAS to accept an offer stating a "local" > pre-condition that it does not understand was added (after agreement > on the list) for the reason that there may be occasions whereby there > are pre-conditions which are local to one end and for which the other > end's UA does not need to understand (and hence asks for > "confirmation" of the precondition status in the answer SDP). > However, the text in section 5.1.1 seems to be mis-aligned with this > since it requires the offerer to include both "local" and "remote" > pre-conditions if the "segmented" status type is being used. This > would mean if a totally local pre-condition was included in the offer > (without any associated "remote") then the text in section 9 would > cause the far-end UA to reject the session with a 580 Pre-condition > unknown response. This is not the way I thought that "local to one > end only with no parallel in the peer acess network" style > pre-conditions were intended to behave. > > I'm assuming that this is just a bug in the spec. > > I've also noticed (normative) text in section 5 which indicates that > only one type of pre-condition can be used in a given media stream > (i.e. either "segmented" or "e2e"). > > "The offerer then decides whether it is going to use the end-to-end > status type or the segmented status type. If the status type of the > > media line will be end-to-end...." > > Once again, from my understanding, the text in section 9 was > introduced because it was agreed there could be some pre-conditions > which may be local to the one end only and for which there was no > parallel in the peer access network. It was my understanding, however, > that given these "local" pre-conditions the SIP network may also > require to use pre-conditions and that these pre-conditions could be > either of type "segmented" or "e2e". > > Comments? > > Regards, > > Chris > > Chris Hogg > Nortel Networks (UK) > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:50:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10607 for ; Tue, 14 May 2002 18:50:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00107 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:51:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05708; Tue, 14 May 2002 01:42:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05673 for ; Tue, 14 May 2002 01:41:49 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23768 for ; Tue, 14 May 2002 01:41:37 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4E5eSd14070; Tue, 14 May 2002 00:40:28 -0500 Message-ID: <006201c1fb09$dff000d0$133fed0c@C1893415A> From: "Dean Willis" To: "Juha Heinanen" , "Mark Watson" Cc: "Robert Sparks" , , "Jon Peterson" References: <15583.46229.215256.863288@lohi.eng.song.fi> Subject: Re: [Sip] Comment on sip-identity-00 Date: Tue, 14 May 2002 00:40:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > mark, > > the point of my message was not the same of the header field, but what > you mean by network asserted indetify and how it relates to the any > number of sip uris that the user may have. > > -- juha > Ahah!. I think Juha is hinting that he wants to talk about hinting -- that is, how the UA tells the "anonymization service" WHICH of the many possible Asserted-Identities it should be asserting, and perhaps about how the anonymization service decides whether the UA authentically represents a user authorized to claim that specific identity. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:52:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10688 for ; Tue, 14 May 2002 18:52:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00174 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:52:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23712; Tue, 14 May 2002 00:35:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23655 for ; Tue, 14 May 2002 00:35:08 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21297 for ; Tue, 14 May 2002 00:34:54 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 177U1g-000208-00; Tue, 14 May 2002 07:35:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15584.37880.831481.941120@harjus.eng.song.fi> Date: Tue, 14 May 2002 07:35:04 +0300 To: "Peterson, Jon" Cc: "'Robert Sparks'" , sip@ietf.org Subject: [Sip] RE: Comment on sip-identity-00 In-Reply-To: <70565611B164D511957A001083FCDD56018702E0@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018702E0@va02.va.neustar.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > These are good points; throughout the identity draft, I tried to use Digest > only as an example, and indeed in plenty of authentication systems the > identifier of a user would not be suitable syntactically or semantically for > the username portion of a SIP URI. I do think it is not unreasonable, > however, in systems like Digest for a user to have an expectation that the > username they enter into an authentication dialog (for example) will be the > username that appears in their authenticated identity. i tried to make this same point. in our case the username used in digest authentication is the general NAI (Network Access Identifier) of the user and the sip network asserted identity i-d cannot that the username used in the digest authentication (or any other authentication scheme) has nothing to do with the sip uris the user may have. the i-d should make this requirement explicitly clear and also clearly explain that what is asserted is the sip uri the user wants to use for this request. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:52:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10705 for ; Tue, 14 May 2002 18:52:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00190 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:53:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21305; Mon, 13 May 2002 23:55:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21265 for ; Mon, 13 May 2002 23:55:19 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19784 for ; Mon, 13 May 2002 23:55:05 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4E3sf5M020471; Mon, 13 May 2002 20:54:41 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACX19063; Mon, 13 May 2002 20:54:53 -0700 (PDT) From: "Cullen Jennings" To: "Henrikson, Eric H \(Eric\)" , "Dean Willis" , Subject: RE: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt Date: Mon, 13 May 2002 20:55:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EBB@il0015exch004u.ih.lucent.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't understand why the proxy, P1, that sent the call to the AS (a B2BUA), would need to correlate the call that came back from the AS with the original call that P1 sent to the AS. Are there any requirements of what we are trying to solve here? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Henrikson, Eric H (Eric) > Sent: Tuesday, May 07, 2002 9:55 AM > To: Dean Willis; sip@ietf.org > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison > Mankin'; Drage, Keith (Keith) > Subject: [Sip] Expert Review: > draft-henrikson-sip-original-dialog-id-01.txt > > > Attached is revision 01 of the original-dialog-id draft. > > Please return comments by May 10, 2002. > > > Thank you. > Eric Henrikson > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, May 01, 2002 6:38 AM > To: sip@ietf.org > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison > Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric) > Subject: Expert Review: draft-henrikson-sip-original-dialog-id-00.txt > > > > The SIP working group has been asked to provide expert review of > draft-henrikson-sip-original-dialog-id. This documents a P-header used > in 3GPP to associate dialogs across a 3GPP application server acting as > a back-to-back user agent. > > We'd like to complete expert review by May 10, 2002. > > Please copy your comments to the list and to Keith Drage and Eric > Henrikson, who will coordinate responses and edit the draft > apporpriately. > > Thanks, > > -- > Dean Willis > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:53:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10731 for ; Tue, 14 May 2002 18:53:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00207 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:53:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12613; Tue, 14 May 2002 10:19:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12573 for ; Tue, 14 May 2002 10:18:52 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20625 for ; Tue, 14 May 2002 10:18:33 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEHIi20120; Tue, 14 May 2002 16:17:18 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEGSp16260; Tue, 14 May 2002 15:16:29 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 15:18:06 +0100 Message-ID: From: "Chris Hogg" To: "'sip@ietf.org'" Cc: "'wtm@research.att.com'" , "'Gonzalo.Camarillo@ericsson.com'" Date: Tue, 14 May 2002 15:18:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB52.27C17266" Subject: [Sip] Clarification of Manyfolks-07 and "local" pre-conditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FB52.27C17266 Content-Type: text/plain; charset="iso-8859-1" Hi everyone, I've been having a read through of the latest version of Manyfolks (Manyfolks-07) and would like to clarify a number of parts of the text. >From section 5.1.1 "SDP encoding" "For the segmented status type, the user agent MUST generate two current status lines: one with the tag "local" and the other with the tag "remote". The user agent MUST add one or two desired status lines per segment (i.e., local and remote)." And from section 9 "Unknown Precondition type" "A UA that receives an unknown precondition-type with a "mandatory" strength-tag in an offer MUST refuse the offer unless the only unknown mandatory preconditions have the "local" tag. In this case, the UA does not need to be involved in order to meet the preconditions. The UA will ask for confirmation of the preconditions and, when the confirmation arrives, it will resume session establishment." >From my understanding I thought that the text in section 9 regarding the ability of the UAS to accept an offer stating a "local" pre-condition that it does not understand was added (after agreement on the list) for the reason that there may be occasions whereby there are pre-conditions which are local to one end and for which the other end's UA does not need to understand (and hence asks for "confirmation" of the precondition status in the answer SDP). However, the text in section 5.1.1 seems to be mis-aligned with this since it requires the offerer to include both "local" and "remote" pre-conditions if the "segmented" status type is being used. This would mean if a totally local pre-condition was included in the offer (without any associated "remote") then the text in section 9 would cause the far-end UA to reject the session with a 580 Pre-condition unknown response. This is not the way I thought that "local to one end only with no parallel in the peer acess network" style pre-conditions were intended to behave. I'm assuming that this is just a bug in the spec. I've also noticed (normative) text in section 5 which indicates that only one type of pre-condition can be used in a given media stream (i.e. either "segmented" or "e2e"). "The offerer then decides whether it is going to use the end-to-end status type or the segmented status type. If the status type of the media line will be end-to-end...." Once again, from my understanding, the text in section 9 was introduced because it was agreed there could be some pre-conditions which may be local to the one end only and for which there was no parallel in the peer access network. It was my understanding, however, that given these "local" pre-conditions the SIP network may also require to use pre-conditions and that these pre-conditions could be either of type "segmented" or "e2e". Comments? Regards, Chris Chris Hogg Nortel Networks (UK) ------_=_NextPart_001_01C1FB52.27C17266 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification of Manyfolks-07 and "local" = pre-conditions

Hi everyone,

I've been having a read through of the latest version = of Manyfolks (Manyfolks-07) and would like to clarify a number of parts = of the text.

From section 5.1.1 "SDP encoding"

"For the segmented status type, the user agent = MUST generate two
current status lines: one with the tag = "local" and the other with the
tag "remote". The user agent MUST add one = or two desired status lines
per segment (i.e., local and remote)."

And from section 9 "Unknown Precondition = type"

"A UA that receives an unknown = precondition-type
 with a "mandatory" strength-tag in = an offer MUST refuse the offer
 unless the only unknown mandatory = preconditions have the "local" tag.
 In this case, the UA does not need to be = involved in order to meet
 the preconditions. The UA will ask for = confirmation of the
 preconditions and, when the confirmation = arrives, it will resume
 session establishment."

From my understanding I thought that the text in = section 9 regarding the ability of the UAS to accept an offer stating a = "local" pre-condition that it does not understand was added = (after agreement on the list) for the reason that there may be = occasions whereby there are pre-conditions which are local to one end = and for which the other end's UA does not need to understand (and hence = asks for "confirmation" of the precondition status in the = answer SDP).  However, the text in section 5.1.1 seems to be = mis-aligned with this since it requires the offerer to include both = "local" and "remote" pre-conditions if the = "segmented" status type is being used.  This would mean = if a totally local pre-condition was included in the offer (without any = associated "remote") then the text in section 9 would cause = the far-end UA to reject the session with a 580 Pre-condition unknown = response.  This is not the way I thought that "local to one = end only with no parallel in the peer acess network" style = pre-conditions were intended to behave.

I'm assuming that this is just a bug in the = spec.

I've also noticed (normative) text in section 5 which = indicates that only one type of pre-condition can be used in a given = media stream (i.e. either "segmented" or "e2e"). =

"The offerer then decides whether it is going to = use the end-to-end
   status type or the segmented status = type. If the status type of the
   media line will be = end-to-end...."

Once again, from my understanding, the text in = section 9 was introduced because it was agreed there could be some = pre-conditions which may be local to the one end only and for which = there was no parallel in the peer access network. It was my = understanding, however, that given these "local" = pre-conditions the SIP network may also require to use pre-conditions = and that these pre-conditions could be either of type = "segmented" or "e2e". 

Comments?

Regards,

Chris

Chris Hogg
Nortel Networks (UK)
 

------_=_NextPart_001_01C1FB52.27C17266-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 18:53:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10770 for ; Tue, 14 May 2002 18:53:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00240 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:54:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15576; Tue, 14 May 2002 11:01:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15441 for ; Tue, 14 May 2002 11:00:38 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22337 for ; Tue, 14 May 2002 11:00:22 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EExii04237; Tue, 14 May 2002 16:59:44 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEwvp24240; Tue, 14 May 2002 15:58:57 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 16:00:35 +0100 Message-ID: From: "Chris Hogg" To: "'Gonzalo Camarillo'" Cc: "'sip@ietf.org'" , "'wtm@research.att.com'" , "'Gonzalo.Camarillo@ericsson.com'" Date: Tue, 14 May 2002 16:00:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB58.16B6FF30" Subject: [Sip] RE: Clarification of Manyfolks-07 and "local" pre-conditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FB58.16B6FF30 Content-Type: text/plain; charset="iso-8859-1" Hi Gonzalo, Thanks for the quick response. Comments in line. Regards, Chris. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 14 May 2002 15:23 To: Hogg, Chris [MDN05:MA01:EXCH] Cc: 'sip@ietf.org'; 'wtm@research.att.com'; 'Gonzalo.Camarillo@ericsson.com' Subject: Re: Clarification of Manyfolks-07 and "local" pre-conditions Hello, >>No, it is not a bug in the spec. It is mandated to add two current >>status *LINES*. If you are only using local preconditions, the remote >>status lines will NOT have the value mandatory. [CH] This was the way I thought the mechanism would work however is it really necessary to mandate that if you have a pre-condition which is completely local to one end (and for which there is no parallel requirement to reserve resources in the peer) to have to include a remote status line with a strength of "none"? I'm thinking that if a pre-condition was totally local to one end then it would be simpler just to send this and not have to include a "dummy" remote pre-condition tag (with strength sent to "none"). >>About the possibility of having multiple preconditions of different >>types for the same media line, it is mentioned in the spec. The section >>you are referring to is the explanation of the mechanism, and it is kept >>simple so that people understand it better. I believe it is better to >>explain how preconditions of one type work and then say that you can >>have multiple types than trying to explain everything together from the >>beginning. [CH] I understand your concerns for simplicity and that the text I'm referring to is normative however, I couldn't find any text anywhere (particularly within the non-normative sections of 5.1.1) saying that, when constructing the offer, (for a given media line) you could include more than 1 pre-condition type and that "segmented" and "e2e" pre-conditions could potentially co-exist within the same media line. I think it would be clearer if it was stated somewhere that this was possible. If I've missed something, I'd be happy for you to point out the text to me. Thanks, Regards, Chris. Regards, Gonzalo Chris Hogg wrote: > > Hi everyone, > > I've been having a read through of the latest version of Manyfolks > (Manyfolks-07) and would like to clarify a number of parts of the > text. > > From section 5.1.1 "SDP encoding" > > "For the segmented status type, the user agent MUST generate two > current status lines: one with the tag "local" and the other with the > tag "remote". The user agent MUST add one or two desired status lines > per segment (i.e., local and remote)." > > And from section 9 "Unknown Precondition type" > > "A UA that receives an unknown precondition-type > with a "mandatory" strength-tag in an offer MUST refuse the offer > unless the only unknown mandatory preconditions have the "local" tag. > > In this case, the UA does not need to be involved in order to meet > the preconditions. The UA will ask for confirmation of the > preconditions and, when the confirmation arrives, it will resume > session establishment." > > From my understanding I thought that the text in section 9 regarding > the ability of the UAS to accept an offer stating a "local" > pre-condition that it does not understand was added (after agreement > on the list) for the reason that there may be occasions whereby there > are pre-conditions which are local to one end and for which the other > end's UA does not need to understand (and hence asks for > "confirmation" of the precondition status in the answer SDP). > However, the text in section 5.1.1 seems to be mis-aligned with this > since it requires the offerer to include both "local" and "remote" > pre-conditions if the "segmented" status type is being used. This > would mean if a totally local pre-condition was included in the offer > (without any associated "remote") then the text in section 9 would > cause the far-end UA to reject the session with a 580 Pre-condition > unknown response. This is not the way I thought that "local to one > end only with no parallel in the peer acess network" style > pre-conditions were intended to behave. > > I'm assuming that this is just a bug in the spec. > > I've also noticed (normative) text in section 5 which indicates that > only one type of pre-condition can be used in a given media stream > (i.e. either "segmented" or "e2e"). > > "The offerer then decides whether it is going to use the end-to-end > status type or the segmented status type. If the status type of the > > media line will be end-to-end...." > > Once again, from my understanding, the text in section 9 was > introduced because it was agreed there could be some pre-conditions > which may be local to the one end only and for which there was no > parallel in the peer access network. It was my understanding, however, > that given these "local" pre-conditions the SIP network may also > require to use pre-conditions and that these pre-conditions could be > either of type "segmented" or "e2e". > > Comments? > > Regards, > > Chris > > Chris Hogg > Nortel Networks (UK) > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo ------_=_NextPart_001_01C1FB58.16B6FF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Clarification of Manyfolks-07 and "local" = pre-conditions

Hi Gonzalo,

Thanks for the quick response. 

Comments in line.

Regards,

Chris.

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
Sent: 14 May 2002 15:23
To: Hogg, Chris [MDN05:MA01:EXCH]
Cc: 'sip@ietf.org'; 'wtm@research.att.com';
'Gonzalo.Camarillo@ericsson.com'
Subject: Re: Clarification of Manyfolks-07 and = "local" pre-conditions


Hello,

>>No, it is not a bug in the spec. It is = mandated to add two current
>>status *LINES*. If you are only using local = preconditions, the remote
>>status lines will NOT have the value = mandatory.

[CH] This was the way I thought the mechanism would = work however is it really necessary to mandate that if you have a = pre-condition which is completely local to one end (and for which there = is no parallel requirement to reserve resources in the peer) to have to = include a remote status line with a strength of "none"?  = I'm thinking that if a pre-condition was totally local to one end then = it would be simpler just to send this and not have to include a = "dummy" remote pre-condition tag (with strength sent to = "none").

>>About the possibility of having multiple = preconditions of different
>>types for the same media line, it is = mentioned in the spec. The section
>>you are referring to is the explanation of = the mechanism, and it is kept
>>simple so that people understand it better. = I believe it is better to
>>explain how preconditions of one type work = and then say that you can
>>have multiple types than trying to explain = everything together from the
>>beginning.

[CH] I understand your concerns for simplicity and = that the text I'm referring to is normative however, I couldn't find = any text anywhere (particularly within the non-normative sections of = 5.1.1) saying that, when constructing the offer, (for a given media = line) you could include more than 1 pre-condition type and that = "segmented" and "e2e" pre-conditions could = potentially co-exist within the same media line. I think it would be = clearer if it was stated somewhere that this was possible.  If = I've missed something, I'd be happy for you to point out the text to = me.

Thanks,
Regards,
Chris.


Regards,

Gonzalo

Chris Hogg wrote:
>
> Hi everyone,
>
> I've been having a read through of the latest = version of Manyfolks
> (Manyfolks-07) and would like to clarify a = number of parts of the
> text.
>
> From section 5.1.1 "SDP = encoding"
>
> "For the segmented status type, the user = agent MUST generate two
> current status lines: one with the tag = "local" and the other with the
> tag "remote". The user agent MUST add = one or two desired status lines
> per segment (i.e., local and = remote)."
>
> And from section 9 "Unknown Precondition = type"
>
> "A UA that receives an unknown = precondition-type
>  with a "mandatory" strength-tag = in an offer MUST refuse the offer
>  unless the only unknown mandatory = preconditions have the "local" tag.
>
>  In this case, the UA does not need to be = involved in order to meet
>  the preconditions. The UA will ask for = confirmation of the
>  preconditions and, when the confirmation = arrives, it will resume
>  session establishment."
>
> From my understanding I thought that the text = in section 9 regarding
> the ability of the UAS to accept an offer = stating a "local"
> pre-condition that it does not understand was = added (after agreement
> on the list) for the reason that there may be = occasions whereby there
> are pre-conditions which are local to one end = and for which the other
> end's UA does not need to understand (and hence = asks for
> "confirmation" of the precondition = status in the answer SDP).
> However, the text in section 5.1.1 seems to be = mis-aligned with this
> since it requires the offerer to include both = "local" and "remote"
> pre-conditions if the "segmented" = status type is being used.  This
> would mean if a totally local pre-condition was = included in the offer
> (without any associated "remote") = then the text in section 9 would
> cause the far-end UA to reject the session with = a 580 Pre-condition
> unknown response.  This is not the way I = thought that "local to one
> end only with no parallel in the peer acess = network" style
> pre-conditions were intended to behave.
>
> I'm assuming that this is just a bug in the = spec.
>
> I've also noticed (normative) text in section 5 = which indicates that
> only one type of pre-condition can be used in a = given media stream
> (i.e. either "segmented" or = "e2e").
>
> "The offerer then decides whether it is = going to use the end-to-end
>    status type or the segmented = status type. If the status type of the
>
>    media line will be = end-to-end...."
>
> Once again, from my understanding, the text in = section 9 was
> introduced because it was agreed there could be = some pre-conditions
> which may be local to the one end only and for = which there was no
> parallel in the peer access network. It was my = understanding, however,
> that given these "local" = pre-conditions the SIP network may also
> require to use pre-conditions and that these = pre-conditions could be
> either of type "segmented" or = "e2e".
>
> Comments?
>
> Regards,
>
> Chris
>
> Chris Hogg
> Nortel Networks (UK)
>

--
Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
Finland         &n= bsp;         http://www.hut.fi/~gonzalo

------_=_NextPart_001_01C1FB58.16B6FF30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 19:27:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10276 for ; Tue, 14 May 2002 18:40:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29875 for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:41:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01944; Tue, 14 May 2002 08:02:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01890 for ; Tue, 14 May 2002 08:01:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14384; Tue, 14 May 2002 08:01:41 -0400 (EDT) Message-Id: <200205141201.IAA14384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 May 2002 08:01:41 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Security Mechanism Agreement for SIP Sessions Author(s) : J. Arkko et al. Filename : draft-ietf-sip-sec-agree-01.txt Pages : 16 Date : 13-May-02 SIP has a number of security mechanisms. Some of them have been built in to the SIP protocol, such as HTTP authentication or secure attachments. These mechanisms have even alternative algorithms and parameters. SIP does not currently provide any mechanism for selecting which security mechanisms to use over a connection. In particular, even if some mechanisms such as OPTIONS were used to make this selection, the selection would be vulnerable against the Bidding-Down attack. This document defines three header fields for negotiating the security mechanisms within SIP between a user agent client and its next hop SIP entity. A SIP entity applying this mechanism must always require some minimum security (i.e. integrity protection) from all communicating parties in order to secure the negotiation, but the negotiation can agree on which specific minimum security is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-01.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-ietf-sip-sec-agree-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sec-agree-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020513142147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-agree-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-agree-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513142147.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 14 21:25:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15095 for ; Tue, 14 May 2002 21:25:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09952 for sip-archive@odin.ietf.org; Tue, 14 May 2002 21:25:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07805; Tue, 14 May 2002 21:04:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07767 for ; Tue, 14 May 2002 21:04:08 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14483 for ; Tue, 14 May 2002 21:03:53 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g4F146123345; Tue, 14 May 2002 21:04:06 -0400 From: "Victor Paulsamy" To: Cc: , "Victor Paulsamy" Date: Tue, 14 May 2002 18:02:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-mahy-sipping-join-and-fork-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In e.g., 6.1 Join accepted for local mixing: B&C are in a session. A sends in an INVITE to B requesting it to add to the existing session (using Join). How did A learn about the on going session? Appreciate any response. Regards, --victor Victor Paulsamy E-mail: victor@zapex.com Senior Software Engineer Phone : 650.930.1339 (Direct) Zapex Technologies, Inc. Phone : 650.930.1300 (Main) Mountain View, CA 94043 Fax : 650.930.1399 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 10:23:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06691 for ; Wed, 15 May 2002 10:23:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24400 for sip-archive@odin.ietf.org; Wed, 15 May 2002 10:23:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21331; Wed, 15 May 2002 09:51:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21293 for ; Wed, 15 May 2002 09:51:26 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04583 for ; Wed, 15 May 2002 09:50:59 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4FDoZ626630; Wed, 15 May 2002 09:50:36 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA08264; Wed, 15 May 2002 08:50:32 -0500 (CDT) Message-ID: <3CE267A9.7030608@lucent.com> Date: Wed, 15 May 2002 08:50:33 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , Jonathan Rosenberg Subject: Re: [Sip] Reason version 01 References: <3CE0E481.6DC961ED@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Folks, > > I have just released version 01 of the Reason draft. Until it appears in > the archives, you can fetch it from: > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-reason-01.txt > > Only minor modifications has been done since version 00. Gonzalo: 155 provisional response has been excised from the UPDATE I-D; the Reason I-D has a now invalid reference which lists the UPDATE I-D for 155 responses. Additionally, HERFP has also been excised from the UPDATE I-D, leaving it mainly as a media negotiation method before the dialog is established. I believe I saw email from Jonathan on the WG list where he declared his intention to publish an extension to UPDATE, which lists the 155 response I-D as well as HERFP. I am wondering if we should define the 155 provisional response code and HERFP in the Reason I-D, since it depends on both as use cases. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 10:38:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07553 for ; Wed, 15 May 2002 10:38:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26856 for sip-archive@odin.ietf.org; Wed, 15 May 2002 10:39:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23524; Wed, 15 May 2002 10:15:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23497 for ; Wed, 15 May 2002 10:15:03 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06028 for ; Wed, 15 May 2002 10:14:48 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4FEESs0010124; Wed, 15 May 2002 07:14:28 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAD89924; Wed, 15 May 2002 07:14:27 -0700 (PDT) Date: Wed, 15 May 2002 07:11:01 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org cc: rohan@cisco.com Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] WGLC summary for Replaces Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Other than minor editorial changes, here is a summary of the requests I have received/changes I have made to replaces. 1) Removed the wildcard to-tag matching and associated proxy behavior. 2) Added authorization behavior to the current UAS behavior section. Currently the only authorization specified is 3) Added a UAC considerations section 4) Removed the allowance for multiple matched dialogs with no tags. 5) Updated the references 6) Cleaned up the Overview section to be less preachy All in all the new version is much simpler, more secure, and more robust than before. I'll resubmit this morning. Please contact me if any of these issues are showstoppers. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 13:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14599 for ; Wed, 15 May 2002 13:27:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14730 for sip-archive@odin.ietf.org; Wed, 15 May 2002 13:27:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12337; Wed, 15 May 2002 12:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12311 for ; Wed, 15 May 2002 12:59:19 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13302 for ; Wed, 15 May 2002 12:59:05 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4FGwdd26812; Wed, 15 May 2002 11:58:40 -0500 From: "Dean Willis" To: "'Anders Kristensen'" Cc: Subject: RE: [Sip] Revision of draft-willis-sip-path to version -07 Date: Wed, 15 May 2002 11:58:12 -0500 Message-ID: <000901c1fc31$b2c05230$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3CE17F78.4050006@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Many good comments elided. They will be incorporated in next rev. Thanks, Anders. > The UA should include the option tag "path" as a header > vfield value > in all Supported header fields, and should include a > Supported header > field in all requests. > > This make it sound like the path token is optional if the UA > inserts a > Supported header. I believe it's the case that a Supported > header must > always include the tokens for all supported extensions. Yes, this is definitely a slightly different usage of Supported. It's the closest thing we could come up with to a hinting mechanism, and probably deserves discussion in its own right. It made Robert Sparks hair stand on end until he thought about it for a while. But it's actually pretty cool. Think about it -- someday we're going to have 1,000 extensions, so every Supported header is going to be like 20kB long. So the suggested semantic is that the UA include only those options it is willing to use for this transaction or any dialog resulting from it, rather than every possibe supported extension. > > Line 331: > > However, the Path > mechanism should technically work in the absence of UA support (at > some compromise to security) > > I'm not sure I see how a Supported: path header contributes to making > this more secure. That is, unless you also assume S/MIME and > what have you. The Security aspect is that a UA that is aware of Path can look at the Path header field in the REGISTER response and see what proxies have attached themselves. This may allow users to detect unwanted proxies that have "latched on" to registrations. If the UA doesn't support Path, it is unlikely to able to do this inspection. So it isn't the Supported header that makes the difference, it's the actual functional support that matters. > > BTW, it seems a little schizofrenic to me to say that a registrar may > ignore absence of "Supported: path" but a proxy can't. In fact, since > the functioning of the Path header doesn't depend on UA > cooperation I'm > not sure wht it's required at all. Is it so that you get a measure of > assurance that the UA/human sending the REGISTER knows that > things have > inserted themselves on the path of subsequent requests? Yes. > Line 347: "home service proxy" - again, I'd prefer just proxy > or home proxy. > > Sorry for the late comments. The critical piece is that the proxy in question is the proxy responsible for the address-of-record. It can be expected to do a retargeting of requests to that AOR by changing the Requist-URI. This distinguishes it from a proxy that simply forwards using forwarding rules. We probably need a distinctive term for such a beast. Please make suggestions. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 13:28:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14661 for ; Wed, 15 May 2002 13:28:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14749 for sip-archive@odin.ietf.org; Wed, 15 May 2002 13:28:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12401; Wed, 15 May 2002 12:59:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27361 for ; Wed, 15 May 2002 10:41:40 -0400 (EDT) Received: from thorium.btinternet.com (thorium.btinternet.com [194.73.73.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07869 for ; Wed, 15 May 2002 10:41:24 -0400 (EDT) From: dunc.mills@btinternet.com Received: from cerium ([194.75.226.98]) by thorium.btinternet.com with esmtp (Exim 3.22 #8) id 177zyD-0006tO-00; Wed, 15 May 2002 15:41:37 +0100 Received: from 193.68.60.25 by cerium ([194.75.226.98]); Wed, 15 May 02 15:41:37 BST Message-ID: <3409234.1021473697235.JavaMail.root@127.0.0.1> Date: Wed, 15 May 2002 15:41:37 +0100 (BST) To: sip@ietf.org, bpenfield@acmepacket.com, duncan.mills@vf.vodafone.co.uk Subject: Re: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-MAILER: talk21.com WAS v2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA27374 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Bob, Many thanks for your comments. It is re-assuring to know that some IETF experts have reviewed my draft. Please consider my comments below. I look forward to your further input, if necessary. Regards, Duncan Hi, 1) The examples given in section 4 (a laptop in an airport or hotel) do not sound like access networks that will provide the "transitive trust" required to protect privacy as described in section 6. Are these really valid examples for usage of this header? Or are you assuming that this would only work for local ISPs and airports that had a business relationship with the home network? How does the UA know if these types of access networks can be trusted? The model I was thinking of is that the user trusts the access network, because his home network provider trusts the access network. This is stated in my draft. 2) Does this draft need an explicit Applicability Statement? I think the draft could be applicable to various systems, but obviously I am writing it primarily with a 3GPP requirement in mind. Do you think I need to add an explicit Applicability Statement? My IETF procedural knowledge is (I'm afraid) limited. 3) Section 6 says: The serving proxy MUST delete this header before forwarding the message outside of the its domain. but section 7 says: A serving proxy, typically located in the home network, and therefore trusted, SHOULD delete the header when the SIP signaling is forwarded beyond the home network domain and section 8 says: This header SHOULD always be deleted by the serving network prior to forwarding it outside of the home network domain, as described in section 7. Is it MUST or SHOULD? Also, I think it is sufficient to have the MUST or SHOULD once (in the Proxy behavior section) or maybe twice, and then say "...serving proxies will delete..." in other places you need to talk about it. I realize it is very important. You are correct, there is inconsistency. I'll correct this. 4) The document has weird characters where single quotes (i.e. ') should be. My version doesn't. I'll check this out. 5) You say "... where the access-type is æ3GPP-GERANÆ, the access-info SHALL be "3GPP-CGI".", but go on to says the mapping of access-type to access-info is defined elsewhere. Can you provide a reference? Also, I don't think you should use the requirements language (SHALL) for an example like this. If there are mapping requirement, they should all be included or you should refer to a document that defines them. Okay, I was told I couldn't refer to a 3GPP document in an RFC. I don't think it matters. The fields specified in the draft are containers that can carry anything anyone defines or doesn't define. It's just that in our 3GPP specifications, we say "we're going to use the access-network-info header, and we're going to put parameter x in the 'Access-Info' field. The receiver knows parameter x will be in that field. I don't want to have this defined in two documents. Maybe I should just remove the statement saying that it is defined elsewhere? 6) The period is missing between 'request' and 'The' in section 7.1 "... SIP message request The UAC SHOULD ..." Thanks. 7) Section 7.1, 2nd paragraph. Should "the nature or the information" be "the nature *of* the information"? Ooops. Thanks. 8) Section 7.2 is labeled "UAS behavior", but talks only about proxy behavior. I don't think there is any UAS behavior for this header. Does 'Proxy behaviour' cover the case of a B2BUA? 9) In section 7.2 you say the proxy "MAY use the contents to, e.g., provide ...". I suggest you remove the "e.g." and say something like "... MAY use the contents to provide a different service or apply performance enhancement measures depending on the network through which the UA is accessing the server. For example, ....". Sounds reasonable, I'll make this change. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 14:35:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17083 for ; Wed, 15 May 2002 14:35:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20090 for sip-archive@odin.ietf.org; Wed, 15 May 2002 14:35:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18184; Wed, 15 May 2002 14:09:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18155 for ; Wed, 15 May 2002 14:09:18 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16299 for ; Wed, 15 May 2002 14:09:03 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4FI8cuF011137 for ; Wed, 15 May 2002 11:08:38 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAD92568; Wed, 15 May 2002 11:08:44 -0700 (PDT) Date: Wed, 15 May 2002 11:05:18 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] revised version of Replaces available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I just submitted a new version of Replaces. Until it appears in the archive it is available in the drafts directory on softarmor http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-02.txt http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-02.html thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 15:20:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18780 for ; Wed, 15 May 2002 15:20:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23264 for sip-archive@odin.ietf.org; Wed, 15 May 2002 15:20:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21843; Wed, 15 May 2002 15:02:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21816 for ; Wed, 15 May 2002 15:02:41 -0400 (EDT) Received: from smtp2.arnet.com.ar (smtp2.arnet.com.ar [200.45.191.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18024 for ; Wed, 15 May 2002 15:02:26 -0400 (EDT) Received: (qmail 678 invoked from network); 15 May 2002 19:01:24 -0000 Received: from unknown (HELO arnet.com.ar) (200.45.0.20) by smtp2.arnet.com.ar with SMTP; 15 May 2002 19:01:24 -0000 Received: from mail pickup service by arnet.com.ar with Microsoft SMTPSVC; Wed, 15 May 2002 15:58:52 -0300 Received: from smtp-mx-01.ti.local ([200.45.48.20]) by mx2.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.357.35); Wed, 15 May 2002 10:09:24 -0300 Received: from loki.ietf.org ([132.151.1.177]) by smtp-mx-01.ti.local with Microsoft SMTPSVC(5.0.2195.4905); Wed, 15 May 2002 10:05:51 -0300 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA01050 for ietf-123-outbound.01@ietf.org; Wed, 15 May 2002 09:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA00061 for ; Wed, 15 May 2002 07:12:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25814; Wed, 15 May 2002 07:12:21 -0400 (EDT) Message-Id: <200205151112.HAA25814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 May 2002 07:12:21 -0400 X-OriginalArrivalTime: 15 May 2002 13:05:51.0390 (UTC) FILETIME=[3D2A23E0:01C1FC11] Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 Refer Method Author(s) : R. Sparks Filename : draft-ietf-sip-refer-04.txt Pages : 16 Date : 14-May-02 This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. This can be used to enable many applications, including Call Transfer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.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-ietf-sip-refer-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020514144207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020514144207.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 15:48:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20216 for ; Wed, 15 May 2002 15:48:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26267 for sip-archive@odin.ietf.org; Wed, 15 May 2002 15:48:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23653; Wed, 15 May 2002 15:26:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23618 for ; Wed, 15 May 2002 15:26:56 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18938 for ; Wed, 15 May 2002 15:26:41 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4FJQr0E023421 for ; Wed, 15 May 2002 21:26:53 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4FJQq9q000136 for ; Wed, 15 May 2002 22:26:52 +0300 (EET DST) Message-ID: <3CE2B67C.11209B4@lmf.ericsson.se> Date: Wed, 15 May 2002 22:26:52 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Possible ABNF bug Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Bis-09 says that the "@" character is not allowed in the SIP-URI (or SIPS-URI) if the userinfo part of the URI is empty (eg "@sip.world.com" is not allowed). However, the ABNF says: SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters [ headers ] userinfo = [ user / telephone-subscriber [ ":" password ]] Now, the first line (defines SIP-URI) does indicate that userinfo, together with @, is optional in the URI. The second line (defines userinfo), however, indicates that user, telephone-subscriber and password ALSO are optional for userinfo, which to my understanding means that an empty value IS a valid value for userinfo. I think the correct syntax should be: userinfo = ( user / telephone-subscriber [ ":" password ]) Also, does the syntax above password to be used together with user, or only together with telephone-subscriber? IF so, then I guess the correct syntax shall be: userinfo = ( user / telephone-subscriber) [ ":" password ] Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 18:35:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24335 for ; Wed, 15 May 2002 18:35:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07773 for sip-archive@odin.ietf.org; Wed, 15 May 2002 18:35:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06684; Wed, 15 May 2002 18:20:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06655 for ; Wed, 15 May 2002 18:20:30 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23952 for ; Wed, 15 May 2002 18:20:14 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4FMJdd28981; Wed, 15 May 2002 17:19:39 -0500 From: "Dean Willis" To: Cc: , , Date: Wed, 15 May 2002 17:19:11 -0500 Message-ID: <013001c1fc5e$89fcdc60$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Termination of WGLC, request of IETF LC for draft-ietf-sip-replaces Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I just asked the IESG to schedule an IETF Last Call for the replaces draft. Version -02 was submitted to the archive today and supposedly reflects all changes requested during WGLC. You can also retrievd it from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-02.txt -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 18:47:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24691 for ; Wed, 15 May 2002 18:47:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08201 for sip-archive@odin.ietf.org; Wed, 15 May 2002 18:48:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07813; Wed, 15 May 2002 18:35:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07785 for ; Wed, 15 May 2002 18:35:36 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24349 for ; Wed, 15 May 2002 18:35:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4FMWSne025620; Wed, 15 May 2002 18:32:28 -0400 (EDT) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K8ZHHFPM; Wed, 15 May 2002 18:35:03 -0400 Message-ID: <3CE2E296.6060007@dynamicsoft.com> Date: Wed, 15 May 2002 18:35:02 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Supported semantics [WAS: Re: [Sip] Revision of draft-willis-sip-path to version -07] References: <000901c1fc31$b2c05230$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: >> The UA should include the option tag "path" as a header >>vfield value >> in all Supported header fields, and should include a >>Supported header >> field in all requests. >> >>This make it sound like the path token is optional if the UA >>inserts a >>Supported header. I believe it's the case that a Supported >>header must >>always include the tokens for all supported extensions. > > > Yes, this is definitely a slightly different usage of Supported. It's > the closest thing we could come up with to a hinting mechanism, and > probably deserves discussion in its own right. It made Robert Sparks > hair stand on end until he thought about it for a while. But it's > actually pretty cool. > > Think about it -- someday we're going to have 1,000 extensions, so every > Supported header is going to be like 20kB long. So the suggested > semantic is that the UA include only those options it is willing to use > for this transaction or any dialog resulting from it, rather than every > possibe supported extension. I think the reason the requirement is there is that if a proxy/UAS cannot tell from a Supported header whether the UAC supports a particular extension it cannot intelligently downgrade the service it provides - does it send a 420 in the hope that the UAC will resend with the extension token or does it proceed without the extension. One idea that was floated at the time was to allow a special Supported token signaling that all supported extensions have been listed. But given that this is not what's in the current or previous specs, servers wouldn't be able to interpret absence of such a special token as guarantee that the UAC didn't send a complete Supported list anyway, so it wouldn't really help now. Anders _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 15 20:09:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26120 for ; Wed, 15 May 2002 20:09:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11601 for sip-archive@odin.ietf.org; Wed, 15 May 2002 20:09:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10603; Wed, 15 May 2002 19:48:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10572 for ; Wed, 15 May 2002 19:48:07 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25679 for ; Wed, 15 May 2002 19:47:52 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4FNlhV14423 for ; Wed, 15 May 2002 18:47:43 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 18:47:35 -0500 Message-ID: From: "Sriram Parameswar" To: "'sip@ietf.org'" Date: Wed, 15 May 2002 18:47:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC6A.E296C870" Subject: [Sip] Comments on 3pcc Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FC6A.E296C870 Content-Type: text/plain; charset="iso-8859-1" Hi All, Additional comments/nits on the 3pcc : 1) Call Flow - Figure 7: ACK missing after (7)-the 200 OK to A. 2) Figure 11 uses the c=0 mid call - I assume that this is the "blackhole SDP" (c= line has an IP address 0.0.0.0). The offer-answer draft allows the use of this type of SDP only in the initial offer quote "However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer." which is not the case here. Should we consider having the controller sending the Called Party an INVITE with a a=inactive SDP attribute for every media stream involved? 3) Figure 8 - is it valid for Party A to offer early media when the INVITE came in with no media lines?? 4) Fig 11: The RTP session (10) should be shown bi-directional. 5) Section 9.2 - Change "This is an instantiation of Flow II" to read "This is an instantiation of Flow I". Remove the need for HTTP and have the Media Server send BYE when its done. 6) Security question on section 11: Given that 3pcc will be used for things like 'click-to-call, when I am browsing the web, how will I configure my UA to have credentials of potentially arbitrary controllers on the Internet. Using Certificates is definitely a better recommendation here. 7) General nits: * section 4.2 "generatea" to "generates" * section 4.3 "A thid flow" to "A third flow" * section 4.4 "manipuldations" to "manipulations" * section 6 "participant instead A call" to "participant instead. A call" * section 8 "Third aty" to "Third party" Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C1FC6A.E296C870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on 3pcc

Hi All,

Additional comments/nits on the = 3pcc :

1) Call Flow - Figure 7: ACK = missing after (7)-the 200 OK to A.

2) Figure 11 uses the c=3D0 mid = call - I assume that this is the "blackhole SDP" (c=3D line = has an IP address 0.0.0.0). The offer-answer draft allows the use of = this type of SDP only in the initial offer quote "However, it can = be useful in an initial offer when the offerer knows it wants to use a = particular set of media streams and formats, but doesn't know the = addresses and ports at the time of the offer." which is not the = case here. Should we consider having the controller sending the Called = Party an INVITE with a a=3Dinactive SDP attribute for every media = stream involved?

3) Figure 8 - is it valid for = Party A to offer early media when the INVITE came in with no media = lines??

4) Fig 11: The RTP session (10) = should be shown bi-directional.

5) Section 9.2 - Change = "This is an instantiation of Flow II" to read "This is = an instantiation of Flow I". Remove the need for HTTP and have the = Media Server send BYE when its done.

6) Security question on section = 11: Given that 3pcc will be used for things like 'click-to-call, when I = am browsing the web, how will I configure my UA to have credentials of = potentially arbitrary controllers on the Internet. Using Certificates = is definitely a better recommendation here.

7) General nits:
        * section 4.2 "generatea" to = "generates"
        * section 4.3 "A thid flow" to "A = third flow"
        * section 4.4 "manipuldations" to = "manipulations"
        * section 6 "participant instead A call" = to "participant instead. A call"
        * section 8 "Third aty" to "Third = party"



Regards,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: = 972-685-8540
Interactive Multimedia Server (IMS) = Fax: 972-684-3986
Nortel Networks, Richardson = USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C1FC6A.E296C870-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 01:28:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05105 for ; Thu, 16 May 2002 01:28:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10599 for sip-archive@odin.ietf.org; Thu, 16 May 2002 01:28:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02216; Thu, 16 May 2002 01:01:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02187 for ; Thu, 16 May 2002 01:01:09 -0400 (EDT) Received: from mail.dascom.com.cn (IDENT:root@[211.100.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04591 for ; Thu, 16 May 2002 01:00:51 -0400 (EDT) Received: from yannote ([192.168.91.226]) by mail.dascom.com.cn (8.9.3/8.9.3) with ESMTP id NAA29190; Thu, 16 May 2002 13:30:04 +0800 Date: Thu, 16 May 2002 12:59:26 +0800 From: Zhicheng Yan To: Sip@ietf.org, Sip-implementors@cs.columbia.edu Reply-To: yanzc@mail.dascom.com.cn Organization: Dascom Technology LTD.(Beijing) Message-Id: <20020516125745.1B82.YANZC@mail.dascom.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.05 (beta3) Content-Transfer-Encoding: 8bit Subject: [Sip] Anyone notices the problerm? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi,Helpers: I am developing SIP stack using JAIN. But when testing, i found that too long a SIP Message sent out using UDP will make itself truncated. It might be the limits of MTU, but how can I extend the MTU (I am testing under Windows and Solaris, in Intranet environment.)? Does JAIN support (or plan to support) such network parameter adjust? Thank you all. -- Sincerely yours Zhicheng Yan(ãÆÖ¾³É) ======================================================================== Zhicheng Yan Dascom Technology, Beijing tel :+86-10-62961199-226 fax: 86-10-62961527 IM: MSN Messenger, .Net Messenger Service. ======================================================================== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 03:28:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16051 for ; Thu, 16 May 2002 03:28:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20515 for sip-archive@odin.ietf.org; Thu, 16 May 2002 03:28:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17324; Thu, 16 May 2002 03:03:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17296 for ; Thu, 16 May 2002 03:03:50 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15241 for ; Thu, 16 May 2002 03:03:33 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4G73k0E022698 for ; Thu, 16 May 2002 09:03:46 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4G73k9q001423 for ; Thu, 16 May 2002 10:03:46 +0300 (EET DST) Message-ID: <3CE359D2.289E76ED@lmf.ericsson.se> Date: Thu, 16 May 2002 10:03:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] URI headers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, URI's may contain headers, using the "?" mechanism as defined in chapter 19.1.1. The chapter says that the hname "body" indicates that the associated hvalue is the message-body of the SIP request. Should it be mentioned, that if "body" is used there MUST also be a "Content-Type" header? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 04:16:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17188 for ; Thu, 16 May 2002 04:16:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA24425 for sip-archive@odin.ietf.org; Thu, 16 May 2002 04:16:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21921; Thu, 16 May 2002 03:36:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21891 for ; Thu, 16 May 2002 03:36:48 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16295 for ; Thu, 16 May 2002 03:36:18 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4G6ewY04998 for ; Thu, 16 May 2002 09:40:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 May 2002 09:42:04 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 16 May 2002 09:42:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Thu, 16 May 2002 09:42:04 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED07@esebe013.NOE.Nokia.com> Thread-Topic: [Sip] Message draft changes Thread-Index: AcH7VXpjs4GewQeVSZmywGRc2fUdywBSbAXQ To: , X-OriginalArrivalTime: 16 May 2002 06:42:04.0548 (UTC) FILETIME=[CA82A440:01C1FCA4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA21892 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Comments inline. > > > I submitted draft-ietf-sip-message-04 last week. This version > > > contains a few > > > AD requested changes, primarily in the area of congestion control. > > > Specifically: > > > > > > 1) Added an applicability statement clarifying the difference > > > between the > > > pager and session models, and that this draft only defines > > > the pager model. > > > > > > 2) Strengthened the congestion control section: > > > > > > * 1300 byte hard limit for physical payload size for pager > > > model. This > > > applies to the actual payload only, not indirect content. > Fragmenting > > > content across multiple requests is prohibited for pager model. > > > > I don't agree with this at all. This sort of hard limit really > > hampers the whole IM application. The session mode and paging > > mode IM are very different in nature. Session IM is clearly > > conversational, whereas paging mode IM much more of a > > "shoot-and-forget" type messaging. Now if the selection between > > the two is not based on user preference and needs but on payload > > size, I don't think this serves the IM users very well. > > > > Also, 1300 bytes seems awfully little, if I want to send > > message/cpim with S/MIME protection. > > > > I understand your concern. The problem is, the IESG is very > concerned about > the potential for congestion caused by MESSAGE. We initially > stated that, if > your payload was over 1300 bytes, you must use a congestion-controlled > transport. The SIP spec itself says that now, I think. The problem is, > outside of a dialog, there is no way to ensure that no hop > will traverse > UDP. So to allow larger payloads, we would have to solve that > problem first. > We did not want to make MESSAGE dependent on a solution for > that problem. Since it is totally possible to send the MESSAGE directly to the recipient (R-URI points to the interface address directly, not the AOR), doesn't the sender in this case have definite knowledge, that the hop will use TCP? The MUST strength forces the UA to *always* follow the fixed 1300 limit. I'm sure there are also other cases, where UDP hops will definitely not exist. I'm wondering if the congestion control could do away with some SHOULD based construct on the size limitation? The MUST really limits the features of IM, in my opinion. > There is work underway to define a mechanism for indirect > content. I think > we will have to use that for any sort of large content. I'm aware of that work. The problem is that it is still in a concept level only. Even though it looks like a trivially solvable problem, discussions on the requirements in the interim meeting suggested that there are some tricky issues to it, too. I'm not buying this argument until there's at least a WG item for a solution. Cheers, Aki > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 04:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17629 for ; Thu, 16 May 2002 04:42:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26246 for sip-archive@odin.ietf.org; Thu, 16 May 2002 04:42:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24883; Thu, 16 May 2002 04:23:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24845 for ; Thu, 16 May 2002 04:23:22 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17400 for ; Thu, 16 May 2002 04:23:08 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4G8NF0E022342; Thu, 16 May 2002 10:23:15 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4G8NE9q006710; Thu, 16 May 2002 11:23:14 +0300 (EET DST) Message-ID: <3CE36C71.7B160EA8@lmf.ericsson.se> Date: Thu, 16 May 2002 11:23:13 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: sip , Jonathan Rosenberg Subject: Re: [Sip] Reason version 01 References: <3CE0E481.6DC961ED@lmf.ericsson.se> <3CE267A9.7030608@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Vijay, Good point. I forgot completely about updating the references. I believe that Jonathan wants to wait for a while before advancing the 155 stuff to RFC (Jonathan, can you confirm this point?). But we have to advance 3pcc and Reason together. However, I do not think we have any problem. The reason draft can speak about 155 responses without referencing any RFC. It is enough that the 155 status code is registered wherever we are registering status codes (is it already in IANA or we still have a temporary repository?). Does anybiody see a problem with this approach? thanks, Gonzalo "Vijay K. Gurbani" wrote: > > Gonzalo Camarillo wrote: > > Folks, > > > > I have just released version 01 of the Reason draft. Until it appears in > > the archives, you can fetch it from: > > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-reason-01.txt > > > > Only minor modifications has been done since version 00. > > Gonzalo: > > 155 provisional response has been excised from the UPDATE I-D; the > Reason I-D has a now invalid reference which lists the UPDATE I-D for > 155 responses. Additionally, HERFP has also been excised from the > UPDATE I-D, leaving it mainly as a media negotiation method before > the dialog is established. > > I believe I saw email from Jonathan on the WG list where he declared > his intention to publish an extension to UPDATE, which lists the 155 > response I-D as well as HERFP. I am wondering if we should define > the 155 provisional response code and HERFP in the Reason I-D, since it > depends on both as use cases. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 09:35:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24360 for ; Thu, 16 May 2002 09:35:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12933 for sip-archive@odin.ietf.org; Thu, 16 May 2002 09:35:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11323; Thu, 16 May 2002 09:09:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02572 for ; Thu, 16 May 2002 06:39:28 -0400 (EDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19512 for ; Thu, 16 May 2002 06:39:13 -0400 (EDT) Received: from nist.gov (stinkbug.antd.nist.gov [129.6.55.9]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4GAdRab012483; Thu, 16 May 2002 06:39:27 -0400 (EDT) Message-ID: <3CE38C5E.8090005@nist.gov> Date: Thu, 16 May 2002 06:39:26 -0400 From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: N.I.S.T. Advanced Networking Technologies Division User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: yanzc@mail.dascom.com.cn CC: Sip@ietf.org, Sip-implementors@cs.columbia.edu References: <20020516125745.1B82.YANZC@mail.dascom.com.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Re: [Sip-implementors] Anyone notices the problerm? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Try using TCP transport. You can specify TCP transport using the transport=tcp on the url parameters. The default is UDP. Ranga. Zhicheng Yan wrote: >Hi,Helpers: > >I am developing SIP stack using JAIN. >But when testing, i found that too long a SIP Message sent out using UDP >will make itself truncated. It might be the limits of MTU, but how can I >extend the MTU (I am testing under Windows and Solaris, in Intranet >environment.)? Does JAIN support (or plan to support) such network >parameter adjust? > >Thank you all. > >-- > Sincerely yours > Zhicheng Yan(ãÆÖ¾³É) >======================================================================== >Zhicheng Yan >Dascom Technology, Beijing >tel :+86-10-62961199-226 >fax: 86-10-62961527 >IM: MSN Messenger, .Net Messenger Service. >======================================================================== > > >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@cs.columbia.edu >http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > -- M. Ranganathan N.I.S.T. Advanced Networking Technologies Division 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899 Tel:301 975 3664; fax:301 590 0932 Advanced Networking Technologies for the people! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 10:18:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25755 for ; Thu, 16 May 2002 10:18:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15071 for sip-archive@odin.ietf.org; Thu, 16 May 2002 10:19:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13546; Thu, 16 May 2002 09:48:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13515 for ; Thu, 16 May 2002 09:48:17 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24889 for ; Thu, 16 May 2002 09:48:00 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GDm1X89876; Thu, 16 May 2002 08:48:02 -0500 (CDT) From: "Ben Campbell" To: , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Thu, 16 May 2002 08:47:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED07@esebe013.NOE.Nokia.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, May 16, 2002 1:42 AM > To: bcampbell@dynamicsoft.com; sip@ietf.org > Subject: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) > [snip] > > > I understand your concern. The problem is, the IESG is very > > concerned about > > the potential for congestion caused by MESSAGE. We initially > > stated that, if > > your payload was over 1300 bytes, you must use a congestion-controlled > > transport. The SIP spec itself says that now, I think. The problem is, > > outside of a dialog, there is no way to ensure that no hop > > will traverse > > UDP. So to allow larger payloads, we would have to solve that > > problem first. > > We did not want to make MESSAGE dependent on a solution for > > that problem. > > Since it is totally possible to send the MESSAGE directly to the > recipient (R-URI points to the interface address directly, not > the AOR), doesn't the sender in this case have definite > knowledge, that the hop will use TCP? The MUST strength forces > the UA to *always* follow the fixed 1300 limit. > > I'm sure there are also other cases, where UDP hops will > definitely not exist. I'm wondering if the congestion control > could do away with some SHOULD based construct on the size > limitation? The MUST really limits the features of IM, in my opinion. We had it as a SHOULD before, and were asked to change it. It might be possible to change it to say you MUST NOT exceed 1300 bytes unless you have affirmative knowledge that no hop along the way will use UDP. But that limits you to some pretty trivial uses in the pager model. > > > There is work underway to define a mechanism for indirect > > content. I think > > we will have to use that for any sort of large content. > > I'm aware of that work. The problem is that it is still in a > concept level only. Even though it looks like a trivially > solvable problem, discussions on the requirements in the interim > meeting suggested that there are some tricky issues to it, too. > I'm not buying this argument until there's at least a WG item for > a solution. I agree it is not trivial, but it is doable. I think we are in process of getting a wg item for this in SIMPLE. We _do_ have a wg item for message sessions in SIMPLE, which would be another possible solution. > > Cheers, > Aki > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 11:08:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27533 for ; Thu, 16 May 2002 11:08:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19148 for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:08:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16828; Thu, 16 May 2002 10:47:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16797 for ; Thu, 16 May 2002 10:47:07 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26667 for ; Thu, 16 May 2002 10:46:47 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4GElHk22566 for ; Thu, 16 May 2002 17:47:17 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 May 2002 17:46:55 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 16 May 2002 17:46:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Thu, 16 May 2002 17:46:55 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED0E@esebe013.NOE.Nokia.com> Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Thread-Index: AcH84FFd0+Lqsdc8SWOJ39DvveOQRAABQFDQ To: , X-OriginalArrivalTime: 16 May 2002 14:46:55.0771 (UTC) FILETIME=[863AFEB0:01C1FCE8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA16798 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Comments inline. > > Since it is totally possible to send the MESSAGE directly to the > > recipient (R-URI points to the interface address directly, not > > the AOR), doesn't the sender in this case have definite > > knowledge, that the hop will use TCP? The MUST strength forces > > the UA to *always* follow the fixed 1300 limit. > > > > I'm sure there are also other cases, where UDP hops will > > definitely not exist. I'm wondering if the congestion control > > could do away with some SHOULD based construct on the size > > limitation? The MUST really limits the features of IM, in > my opinion. > > We had it as a SHOULD before, and were asked to change it. It might be > possible to change it to say you MUST NOT exceed 1300 bytes > unless you have > affirmative knowledge that no hop along the way will use UDP. But that > limits you to some pretty trivial uses in the pager model. I wish I had a piece of text to suggest that would satisfy this, but I don't. I understand that there may be a non-bis09 compatible proxy out there despite the suggestions made about the congestion control in the MESSAGE draft. But still, fixing a maximum size of 1300 bytes for IM seems to me, if you don't mind my saying ;), a hack. Sort of like the one that limited SMSs to be only 160 characters long... > > > There is work underway to define a mechanism for indirect > > > content. I think > > > we will have to use that for any sort of large content. > > > > I'm aware of that work. The problem is that it is still in a > > concept level only. Even though it looks like a trivially > > solvable problem, discussions on the requirements in the interim > > meeting suggested that there are some tricky issues to it, too. > > I'm not buying this argument until there's at least a WG item for > > a solution. > > I agree it is not trivial, but it is doable. I think we are > in process of > getting a wg item for this in SIMPLE. We _do_ have a wg item > for message > sessions in SIMPLE, which would be another possible solution. In my opinion, the message session won't work well enough. The user experience in the session model is inherently different to the paging model. Receiving an INVITE should indicate that there exists a desire to establish a conversation. Likewise, accepting the INVITE should indicate that the party is willing to commit to the conversation, however brief it may end up being. But if the reason for establishing the session was actually to circumvent some transport inefficiency, this user experience factor is lost. Regards, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 11:27:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28363 for ; Thu, 16 May 2002 11:27:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20880 for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:27:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17851; Thu, 16 May 2002 10:59:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17676 for ; Thu, 16 May 2002 10:59:45 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27183 for ; Thu, 16 May 2002 10:59:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4GExmk29853 for ; Thu, 16 May 2002 17:59:49 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 May 2002 17:59:27 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 16 May 2002 17:59:27 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 16 May 2002 17:59:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Message draft changes Date: Thu, 16 May 2002 17:59:25 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791B8@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Message draft changes Thread-Index: AcH7VXmgI1Dz9YmIQ/K/dh0DjDky5wBk5NQw To: , , X-OriginalArrivalTime: 16 May 2002 14:59:26.0355 (UTC) FILETIME=[459D0630:01C1FCEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17677 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit It seems to me that your limitation is on the assumption that Ethernet is the underlying Data Link layer. I admit some UDP implementations also limit the UDP datagram size to a smaller value than 64K. But as it says, its an implementation, and that's why the limitation should be an implementation issue depending on the underlying network, the API, etc. and not restricted by the protocol standard. Regards, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, May 14, 2002 5:40 PM > To: Niemi Aki (NET/Espoo); sip@ietf.org > Subject: RE: [Sip] Message draft changes > > > > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, May 14, 2002 4:54 AM > > To: sip@ietf.org > > Cc: bcampbell@dynamicsoft.com > > Subject: RE: [Sip] Message draft changes > > > > > > Hi Ben, > > > > > I submitted draft-ietf-sip-message-04 last week. This version > > > contains a few > > > AD requested changes, primarily in the area of congestion control. > > > Specifically: > > > > > > 1) Added an applicability statement clarifying the difference > > > between the > > > pager and session models, and that this draft only defines > > > the pager model. > > > > > > 2) Strengthened the congestion control section: > > > > > > * 1300 byte hard limit for physical payload size for pager > > > model. This > > > applies to the actual payload only, not indirect content. > Fragmenting > > > content across multiple requests is prohibited for pager model. > > > > I don't agree with this at all. This sort of hard limit really > > hampers the whole IM application. The session mode and paging > > mode IM are very different in nature. Session IM is clearly > > conversational, whereas paging mode IM much more of a > > "shoot-and-forget" type messaging. Now if the selection between > > the two is not based on user preference and needs but on payload > > size, I don't think this serves the IM users very well. > > > > Also, 1300 bytes seems awfully little, if I want to send > > message/cpim with S/MIME protection. > > > > I understand your concern. The problem is, the IESG is very > concerned about > the potential for congestion caused by MESSAGE. We initially > stated that, if > your payload was over 1300 bytes, you must use a congestion-controlled > transport. The SIP spec itself says that now, I think. The problem is, > outside of a dialog, there is no way to ensure that no hop > will traverse > UDP. So to allow larger payloads, we would have to solve that > problem first. > We did not want to make MESSAGE dependent on a solution for > that problem. > > There is work underway to define a mechanism for indirect > content. I think > we will have to use that for any sort of large content. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 11:28:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28452 for ; Thu, 16 May 2002 11:28:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21176 for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:28:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18940; Thu, 16 May 2002 11:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18910 for ; Thu, 16 May 2002 11:06:05 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27420 for ; Thu, 16 May 2002 11:05:49 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GF5sX96647; Thu, 16 May 2002 10:05:54 -0500 (CDT) From: "Ben Campbell" To: , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Thu, 16 May 2002 10:05:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED0E@esebe013.NOE.Nokia.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, May 16, 2002 9:47 AM > To: bcampbell@dynamicsoft.com; sip@ietf.org > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > {snip} > > I wish I had a piece of text to suggest that would satisfy this, > but I don't. I understand that there may be a non-bis09 > compatible proxy out there despite the suggestions made about the > congestion control in the MESSAGE draft. But still, fixing a > maximum size of 1300 bytes for IM seems to me, if you don't mind > my saying ;), a hack. Sort of like the one that limited SMSs to > be only 160 characters long... I certainly don't mind you saying it :-). The problem is not just pre-bis proxies, btw. If I understand correctly, even a bis proxy can choose to switch to UDP if it cannot reach the next hop via TCP. A general fix might lie there. > > In my opinion, the message session won't work well enough. The > user experience in the session model is inherently different to > the paging model. Receiving an INVITE should indicate that there > exists a desire to establish a conversation. Likewise, accepting > the INVITE should indicate that the party is willing to commit to > the conversation, however brief it may end up being. But if the > reason for establishing the session was actually to circumvent > some transport inefficiency, this user experience factor is lost. If we assume that client software directly exposes the difference between page and session model as part of the user experience, I agree with you. (Yahoo, for example, has an IM and conference model that are clearly different user experiences.) But it is entirely possible to present a page model user experience while still using a session model underneath. (I am withholding judgement as to whether this is a good idea.) Indeed, many people appear to consider session vs. page mode selection as based on content size and congestion issues rather than on user experience. > > Regards, > Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 11:32:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28653 for ; Thu, 16 May 2002 11:32:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21878 for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:32:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19240; Thu, 16 May 2002 11:08:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19209 for ; Thu, 16 May 2002 11:08:46 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27573 for ; Thu, 16 May 2002 11:08:31 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GF8fX96817; Thu, 16 May 2002 10:08:41 -0500 (CDT) From: "Ben Campbell" To: , , Subject: RE: [Sip] Message draft changes Date: Thu, 16 May 2002 10:08:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB77791B8@esebe019.NOE.Nokia.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Actually, I pulled the number out of the bis-09, which says you SHOULD use congestion control if your content-size is >1300. Clearly, that number appears to be chosen there for the reasons you mention. I agree with your statement, but I prefer to keep the number consistent between the message draft and the SIP spec. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, May 16, 2002 9:59 AM > To: bcampbell@dynamicsoft.com; aki.niemi@nokia.com; sip@ietf.org > Subject: RE: [Sip] Message draft changes > > > It seems to me that your limitation is on the assumption that > Ethernet is the underlying Data Link layer. > > I admit some UDP implementations also limit the UDP datagram size > to a smaller value than 64K. But as it says, its an > implementation, and that's why the limitation should be an > implementation issue depending on the underlying network, the > API, etc. and not restricted by the protocol standard. > > Regards, > Hisham > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Tuesday, May 14, 2002 5:40 PM > > To: Niemi Aki (NET/Espoo); sip@ietf.org > > Subject: RE: [Sip] Message draft changes > > > > > > > > > > > -----Original Message----- > > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > > Sent: Tuesday, May 14, 2002 4:54 AM > > > To: sip@ietf.org > > > Cc: bcampbell@dynamicsoft.com > > > Subject: RE: [Sip] Message draft changes > > > > > > > > > Hi Ben, > > > > > > > I submitted draft-ietf-sip-message-04 last week. This version > > > > contains a few > > > > AD requested changes, primarily in the area of congestion control. > > > > Specifically: > > > > > > > > 1) Added an applicability statement clarifying the difference > > > > between the > > > > pager and session models, and that this draft only defines > > > > the pager model. > > > > > > > > 2) Strengthened the congestion control section: > > > > > > > > * 1300 byte hard limit for physical payload size for pager > > > > model. This > > > > applies to the actual payload only, not indirect content. > > Fragmenting > > > > content across multiple requests is prohibited for pager model. > > > > > > I don't agree with this at all. This sort of hard limit really > > > hampers the whole IM application. The session mode and paging > > > mode IM are very different in nature. Session IM is clearly > > > conversational, whereas paging mode IM much more of a > > > "shoot-and-forget" type messaging. Now if the selection between > > > the two is not based on user preference and needs but on payload > > > size, I don't think this serves the IM users very well. > > > > > > Also, 1300 bytes seems awfully little, if I want to send > > > message/cpim with S/MIME protection. > > > > > > > I understand your concern. The problem is, the IESG is very > > concerned about > > the potential for congestion caused by MESSAGE. We initially > > stated that, if > > your payload was over 1300 bytes, you must use a congestion-controlled > > transport. The SIP spec itself says that now, I think. The problem is, > > outside of a dialog, there is no way to ensure that no hop > > will traverse > > UDP. So to allow larger payloads, we would have to solve that > > problem first. > > We did not want to make MESSAGE dependent on a solution for > > that problem. > > > > There is work underway to define a mechanism for indirect > > content. I think > > we will have to use that for any sort of large content. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 11:32:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28687 for ; Thu, 16 May 2002 11:32:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21894 for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:33:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19464; Thu, 16 May 2002 11:11:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19435 for ; Thu, 16 May 2002 11:11:01 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27677 for ; Thu, 16 May 2002 11:10:46 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GFBdYH011118; Thu, 16 May 2002 11:11:40 -0400 (EDT) Message-ID: <3CE3CBCF.A051959F@dynamicsoft.com> Date: Thu, 16 May 2002 11:10:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sriram Parameswar CC: "'sip@ietf.org'" Subject: Re: [Sip] Comments on 3pcc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for your comments. Responses inline. Sriram Parameswar wrote: > > Hi All, > > Additional comments/nits on the 3pcc : > > 1) Call Flow - Figure 7: ACK missing after (7)-the 200 OK to A. Fixed. > > 2) Figure 11 uses the c=0 mid call - I assume that this is the > "blackhole SDP" (c= line has an IP address 0.0.0.0). Yes. > The offer-answer > draft allows the use of this type of SDP only in the initial offer quote > "However, it can be useful in an initial offer when the offerer knows it > wants to use a particular set of media streams and formats, but doesn't > know the addresses and ports at the time of the offer." which is not the > case here. Should we consider having the controller sending the Called > Party an INVITE with a a=inactive SDP attribute for every media stream > involved? No, since it would still end up sending RTCP, which is not what you want. c=0.0.0.0 is the right thing here. The text in offer/answer is not normative; it doesn't forbid its use in other cases. > > 3) Figure 8 - is it valid for Party A to offer early media when the > INVITE came in with no media lines?? It wants to use early media, but can't. Thats why it returns the 183 with no media lines. When the UPDATE comes, it will be able to provide session information for the actual early media. > > 4) Fig 11: The RTP session (10) should be shown bi-directional. Yeah, my tool doesn't do bidirectional arrows.... I'll use ..... > > 5) Section 9.2 - Change "This is an instantiation of Flow II" to read > "This is an instantiation of Flow I". Fixed. > Remove the need for HTTP and have > the Media Server send BYE when its done. I made this change as well, as per my other note. > > 6) Security question on section 11: Given that 3pcc will be used for > things like 'click-to-call, when I am browsing the web, how will I > configure my UA to have credentials of potentially arbitrary controllers > on the Internet. Using Certificates is definitely a better > recommendation here. I must admit that the security considerations section is weak and needs some more work. Generally, the problem is that anything where a third party involved is inherently more complex. Add that to the fact that end user authentication, even for first person calls, is quite hard, and its a nasty problem. It might make more sense to consider the problem as a few sub-cases: Case A: For many applications, the controller and one of the parties in the call are within the same administrative domain. A classic example is click-to-dial. The controller and the customer service rep are both within the domain of the company provided the c2d service. As such, it is not unreasonable for the controller to actually possess a client cert authenticating itself as sip:customer-service@company.com, which is the same thing it would put into the From field of the INVITE to the end user. No shared secrets are needed, and no special configuration at the end user's machine. Thus, there is a pretty good story here. Case B: The controller is an independent entity from either of the parties in the call. I agree its unreasonable to expect that the end users will have shared secrets with the controller, but it depends on the application. I think that ultimately, the identity work being carried out right now might help here. Effectively, this is a case where a trusted third party is trying to deliver a call to some user B, with an identity it asserted (that of user A). In this case, the identity of user A is not determined through sip authentication, but rather, through the fact that this is a 3pcc call and the controller vouches for the fact that the other party is who the controller asserts it to be. Actually, I think this fits very nicely into the identity work. The best I can do here, to avoid dependencies, is to speak generally about asserted identities. So, here is the new text I propose for the security considerations section: \section{Security Considerations} \subsection{Identity} The principal security consideration with third party call control is identity. When the controller initiates the call, what identity does it place in the From field of the INVITE? The controller could indicate that the call is from itself (From: sip:controller@company.com), but the call is really from some user, and is just facilitated by the controller. This impacts on how the call is authenticated by the end users. There are many cases, and the right one depends on the application of 3pcc. In one common scenario, the controller is acting on behalf of one of the participants in the call. A typical example is click-to-dial, where the controller and the customer service representative are run by the same administrative domain. Indeed, for the purposes of identification, the controller can legitimately claim to be the customer service representative. In this scenario, it would be appropriate for the INVITE to the end user to contain a From field identifying the customer service rep, and authenticate the request using S/MIME signed by the key of the customer service rep (which is held by the controller). In other situations, there is no real relationship between the controller and the participants in the call. In these situations, ideally the controller would have a means to assert that the call is from a particular identity (which could be one of the participants, or even a third party, depending on the application), and to validate that assertion with a signature using the key of the controller. \subsection{End-to-End Encryption and Integrity} With third party call control, the controller is actually one of the participants as far as the SIP dialog is concerened. Therefore, encryption and integrity of the SIP messages, as provided by S/MIME, will occur between participants and the controller, rather than directly between participants. > > 7) General nits: > * section 4.2 "generatea" to "generates" > * section 4.3 "A thid flow" to "A third flow" > * section 4.4 "manipuldations" to "manipulations" > * section 6 "participant instead A call" to "participant > instead. A call" > * section 8 "Third aty" to "Third party" All fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 13:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03501 for ; Thu, 16 May 2002 13:38:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01556 for sip-archive@odin.ietf.org; Thu, 16 May 2002 13:38:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29900; Thu, 16 May 2002 13:17:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25482 for ; Thu, 16 May 2002 12:19:33 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00753 for ; Thu, 16 May 2002 12:19:17 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA22623 for ; Thu, 16 May 2002 18:19:18 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA05522 for ; Thu, 16 May 2002 18:19:31 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 18:19:31 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6FDF3DE@mchh161e> From: Heil Franca Marcelo ICM N PG U ID A 2 To: "'sip@ietf.org'" Date: Thu, 16 May 2002 18:19:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] WG: Message draft changes Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I think that the issue of limiting the size of MESSAGE payload is not only related to transport protocols for congestion control but also concerns, as partially mentioned in the draft, the use of the siganlling infrastructure to transfer instant messaging traffic. It can be discussed whether 1300 bytes is the right value, but a size limitation is required. This also enforces congestion control when used in conjunction with the other rules stated in the draft (not fragment contents across multiple MESSAGE requests and not initiate a new MESSAGE transaction as long as there is one pending). Regards, Marcelo -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: 16 May 2002 16:59 To: bcampbell@dynamicsoft.com; aki.niemi@nokia.com; sip@ietf.org Subject: RE: [Sip] Message draft changes It seems to me that your limitation is on the assumption that Ethernet is the underlying Data Link layer. I admit some UDP implementations also limit the UDP datagram size to a smaller value than 64K. But as it says, its an implementation, and that's why the limitation should be an implementation issue depending on the underlying network, the API, etc. and not restricted by the protocol standard. Regards, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, May 14, 2002 5:40 PM > To: Niemi Aki (NET/Espoo); sip@ietf.org > Subject: RE: [Sip] Message draft changes > > > > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, May 14, 2002 4:54 AM > > To: sip@ietf.org > > Cc: bcampbell@dynamicsoft.com > > Subject: RE: [Sip] Message draft changes > > > > > > Hi Ben, > > > > > I submitted draft-ietf-sip-message-04 last week. This version > > > contains a few > > > AD requested changes, primarily in the area of congestion control. > > > Specifically: > > > > > > 1) Added an applicability statement clarifying the difference > > > between the > > > pager and session models, and that this draft only defines > > > the pager model. > > > > > > 2) Strengthened the congestion control section: > > > > > > * 1300 byte hard limit for physical payload size for pager > > > model. This > > > applies to the actual payload only, not indirect content. > Fragmenting > > > content across multiple requests is prohibited for pager model. > > > > I don't agree with this at all. This sort of hard limit really > > hampers the whole IM application. The session mode and paging > > mode IM are very different in nature. Session IM is clearly > > conversational, whereas paging mode IM much more of a > > "shoot-and-forget" type messaging. Now if the selection between > > the two is not based on user preference and needs but on payload > > size, I don't think this serves the IM users very well. > > > > Also, 1300 bytes seems awfully little, if I want to send > > message/cpim with S/MIME protection. > > > > I understand your concern. The problem is, the IESG is very > concerned about > the potential for congestion caused by MESSAGE. We initially > stated that, if > your payload was over 1300 bytes, you must use a congestion-controlled > transport. The SIP spec itself says that now, I think. The problem is, > outside of a dialog, there is no way to ensure that no hop > will traverse > UDP. So to allow larger payloads, we would have to solve that > problem first. > We did not want to make MESSAGE dependent on a solution for > that problem. > > There is work underway to define a mechanism for indirect > content. I think > we will have to use that for any sort of large content. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 14:17:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04980 for ; Thu, 16 May 2002 14:17:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04368 for sip-archive@odin.ietf.org; Thu, 16 May 2002 14:18:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02097; Thu, 16 May 2002 13:50:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02068 for ; Thu, 16 May 2002 13:50:14 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03883 for ; Thu, 16 May 2002 13:50:00 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4GHnbd03063; Thu, 16 May 2002 12:49:37 -0500 From: "Dean Willis" To: "'Anders Kristensen'" Cc: Subject: RE: Supported semantics [WAS: Re: [Sip] Revision of draft-willis-sip-path to version -07] Date: Thu, 16 May 2002 12:49:06 -0500 Message-ID: <006701c1fd01$f96d5090$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CE2E296.6060007@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Anders wrote: > Dean Willis wrote: > >> The UA should include the option tag "path" as a header > >>vfield value > >> in all Supported header fields, and should include a > >>Supported header > >> field in all requests. > >> > >>This make it sound like the path token is optional if the UA > >>inserts a > >>Supported header. I believe it's the case that a Supported > >>header must > >>always include the tokens for all supported extensions. > > > > > > Yes, this is definitely a slightly different usage of > Supported. It's > > the closest thing we could come up with to a hinting mechanism, and > > probably deserves discussion in its own right. It made > Robert Sparks > > hair stand on end until he thought about it for a while. But it's > > actually pretty cool. > > > > Think about it -- someday we're going to have 1,000 extensions, so > > every Supported header is going to be like 20kB long. So > the suggested > > semantic is that the UA include only those options it is willing to > > use for this transaction or any dialog resulting from it, > rather than > > every possibe supported extension. > > I think the reason the requirement is there is that if a proxy/UAS > cannot tell from a Supported header whether the UAC supports a > particular extension it cannot intelligently downgrade the service it > provides - does it send a 420 in the hope that the UAC will > resend with > the extension token or does it proceed without the extension. The assumption has to be that the UA is unwilling to (read WILL NOT) use extensions other than those listed, so the proxy simply proceeds as if the extension is not supported by the UA -- if it's REQUIRED, reject the request. > One idea that was floated at the time was to allow a special > Supported > token signaling that all supported extensions have been listed. But > given that this is not what's in the current or previous > specs, servers > wouldn't be able to interpret absence of such a special token as > guarantee that the UAC didn't send a complete Supported list > anyway, so > it wouldn't really help now. I believe my proposal requires no changes whatsoever to proxy logic. If the proxy requires that a UA support a particular extension not listed, it 420s. If it doesn't, it forwards (optionally adding a Requires). If the UA just happens to offer a different set of options on another transaction, the proxy doesn't really care -- the decisions always happen on a per-transaction basis anyhow. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 15:01:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06586 for ; Thu, 16 May 2002 15:01:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07122 for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:02:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05635; Thu, 16 May 2002 14:35:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05606 for ; Thu, 16 May 2002 14:35:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05629 for ; Thu, 16 May 2002 14:35:11 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GIaKYH011303; Thu, 16 May 2002 14:36:22 -0400 (EDT) Message-ID: <3CE3FBC9.2806605@dynamicsoft.com> Date: Thu, 16 May 2002 14:34:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "P. Vijay" CC: sip@ietf.org Subject: Re: [Sip] UPDATE and Expires References: <000801c1f85e$378ebc40$6601a8c0@mchsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Far as I can tell, the spec already specifies a fix to this problem. Its timer C in the proxies. When an INVITE traverses a proxy, it sets timer C to some value 3 minutes or greater, determined by the service provider. Each time a provisional response is received, the timer is reset. This allows a UAS to extend the timer. However, in the case outlined by Brian, I assume that the UAS doesn't want to explicitly extend the timer. Therefore, after 3 minutes, the timer will fire in a proxy. According to section 16.8, unless the provider wishes to extend the timer, the proxy will generate a CANCEL. This will cause the UAS to cease ringing and generate a 487. That will also terminate the transaction at the UAC, assuming its still alive. It will also clean up state in any proxies along the path. Thus, Brian's problem was due to a proxy which has not implemented timer C as specified in bis. -Jonathan R. "P. Vijay" wrote: > > I think the solution is either a policy decision implemented at > the SIP > service provider level or a basic addition to the > INVITE/TRYING/RINGING/OK/ACK message flow. I am for using INVITE > expires > and letting the SP decide on (a) using its internal timer or expires, > whichever is lesser and (b) resetting the timer when it receives an > UPDATE. > The call is cleared when the timer expires. This is based on reasons > given > below. > > In the traditional telehpony world, answer timers (the time > between start > of ringing and a valid answer) are (typically) set to avoid holding up > bandwidth for unbillable calls. This is especially true for inband > signalling. Even for out-of-band signaling, ISDN/ISUP, etc., the > protocol > DEFINES timers between the state when the called party acknowledges > (180) > the call (INVITE) and the state when a valid answer (200)is received. > If > the timer expires, then the call is cleared by the caller. In reality, > the > call is cleared by the switch that handles the caller's CPE (even that > is a > gross simplification, but it will do). In fact, the tandems with the > lowest > configured answer timers clear the call and propagate the clearing in > both > directions. The important point here is that this behaviour is a > codification of what is seen as good policy (i.e, don't waste resources, > etc.), not necessarily essential for call control. > > In this case, the problem arose because the caller (UAC) died > after sending > INVITE and UAS did not detect the client death. Can that not be handled > at > the trasport (tcp timers, heartbeats, etc.) and clear the call? > > In the case where the UAC is alive and keeps waiting for the > 200, either > UAS or the called (UAS/UAC) could clear the call as described above. > > I have seen answer timers cause problems in regular telephony > services, so > putting in mandatory timers (a-la ISDN or ISUP) would be a hindrance. > However, SP's need policies, preferably encoded in RFC's, that allow for > both call terminations on ring-no-answer and possibly extending the > timer > (e.g. via UPDATE). > > SIP does not have to codify an answer timer, although it may be > a good idea > to do provide some guidance. Also, the timer can be exchanged in SDP, > except it would need to be sent in TRYING or RINGING. In the absence of > a > timer, the matter of detecting a crashed device needs to addressed. > > --Vijay-- > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > > Of Rosen, > > Brian > > Sent: Friday, May 10, 2002 12:38 PM > > To: 'Prabhas Sinha'; Bert Culpepper; sip@ietf.org > > Subject: RE: [Sip] UPDATE and Expires > > > > > > Pick up your phone and dial a number without a message system. > > It will ring quite a while (not forever). Mine waits > > multiple minutes. > > The problem with making assumptions on how long to time out is > > that it's the user, not the UAC, that knows how long is long enough. > > What do you want to do, have him type in a timer length? > > Yes, you can use a timer on either end, but it needs to be on the > > order of minutes, not seconds, and it does not express the wishes > > of either the caller or the callee. It's the system designer (or > > administrator if it's programmable)'s idea of how long is enough. > > > > Note that in SIP, there are no messages passing while you are > > waiting. Of course, I want there to be a few (UPDATE with > > Expire), just so that the called party knows the calling party > > still thinks it ought to be ringing. Then the expiry can be > > on the order of seconds. > > > > Brian > > > > > -----Original Message----- > > > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > > > Sent: Friday, May 10, 2002 1:06 PM > > > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org > > > Subject: Re: [Sip] UPDATE and Expires > > > > > > > > > > I would think the caller will have an idea of how long > > > he/she wants to > > > wait > > > > for answer, and set the value of the Expires header > > > accordingly in the > > > > INVITE request. However, if the caller's UA doesn't > > > support this and it > > > > crashes, then I believe it's an implementation issue for > > > the UAS. Or when > > > > the callee answers the call, current defined protocol > > > behavior (no ACK > > > > received) will suffice here. > > > > > > > > Regards, > > > > Bert > > > > > > > > > > on the contrary, why dont dont we support it from the callee > > > end like PSTN ? > > > If the callee is not at his seat, then why to hold up the > > > resources until > > > caller's "Expire" header? > > > Think of the performance when there are millions of users > > > hitting this bend > > > and blocking the resources for more than actually needed. > > > If I know that I am not available then I can configure my UAC > > > somehow to > > > inform the caller on the very first ring that > > > I am not able to pick up the phone. I am just thinking it on > > > the lines of > > > PSTN operation -- its not the caller who decides how long the > > > call should be > > > presented > > > but its the callee's phone which handles it. If the current > > bis doesnt > > > support it then we might wanna bring in a minor extension to > > > handle this. > > > > > > Does it sound ok ? > > > > > > Prabhas > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 15:45:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08669 for ; Thu, 16 May 2002 15:45:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08782 for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:46:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07850; Thu, 16 May 2002 15:24:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07819 for ; Thu, 16 May 2002 15:24:41 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07452 for ; Thu, 16 May 2002 15:24:27 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJPcYH011747; Thu, 16 May 2002 15:25:38 -0400 (EDT) Message-ID: <3CE40757.27745562@dynamicsoft.com> Date: Thu, 16 May 2002 15:24:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3CD949D5.7080907@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. "Vijay K. Gurbani" wrote: > > Since most people were busy with the interim SIP WG meeting, I did not > hear from anyone on the list, I will send this out again... > > Some comments on -09bis on Timers C, B, and spiraling: > > 1) In SIP, proxies can fork either in serial or in parallel. Consider > serial forking for this discussion. Normally, in the presence of > multiple Contact headers to an address-of-record, a proxy will sort > the Contacts based on their q value and fork serially to each > Contact. If Contact 1 did not elicit a final response within a > certain time, Contact 2 will be tried, and so on. Problem is, > what exactly is the time for a proxy to give up on the current > Contact and try the next one? > > Reading -09bis, it appears that timer C can serve this function. Timer C is meant more for cleanup, not as a way to perform services. The timer value to use when moving amongst contacts depends heavily on the application. I suspect that normally there would be some logic guiding the sequential operation, rather than just based on the q values. As such, I think this is best left as implementation specific. > But the initial value of timer C is too high (3 minutes, and it is > a MUST to set it to at least 3 mins), so that will not work. > Another > possible candidate is the transaction timeout; if a proxy allows a > client transaction to continue (T1*64 seconds = 32 seconds) until it > times out, the time between trying the next Contact (32 seconds) is > too large for the caller to keep holding. So, this does not work > either. > > Should -09bis provide some guidance on timers to use in proxy cores > if serial forking is being used and > 1 Contact header is present, > or should this be left upto the implementer? Left to implementor. > > 2) Timer B controls transaction timeouts in INVITE client trans- > actions. The state diagram in Figure 5 is silent on what to > do if Timer B fires while control is in "Proceeding" state; i.e. > received a 180, but no final response. The correct behavior > should be to sent a CANCEL and enter "Terminated" state. No. Timer C used to be in here, specifying the amount of time the caller "lets the phone ring". However, this really only needs to be specified for proxies (which is whats in bis). For the UAC, how long to let the phone ring is entirely application specific. > > 3) Regarding finding the spiraled R-R on responses in order to > modify it (section 16.7, step 8), won't it be the case that > the first R-R in a response corresponds to the inner-most > spiral? Since the inner-most spiral will generate the first > response, can't we just get the first R-R header on a response > in order to modify it? Thats true for the first loop through, but not the second (or subsequent) loops through. Remember, record-routes are not popped as you traverse through it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 15:46:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08703 for ; Thu, 16 May 2002 15:46:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08812 for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:46:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07530; Thu, 16 May 2002 15:17:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07499 for ; Thu, 16 May 2002 15:17:51 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07142 for ; Thu, 16 May 2002 15:17:36 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJIfYH011714; Thu, 16 May 2002 15:18:41 -0400 (EDT) Message-ID: <3CE405B6.68310065@dynamicsoft.com> Date: Thu, 16 May 2002 15:17:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: aki.niemi@nokia.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Thursday, May 16, 2002 9:47 AM > > To: bcampbell@dynamicsoft.com; sip@ietf.org > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > > changes) > > > > > > {snip} > > > > > I wish I had a piece of text to suggest that would satisfy this, > > but I don't. I understand that there may be a non-bis09 > > compatible proxy out there despite the suggestions made about the > > congestion control in the MESSAGE draft. But still, fixing a > > maximum size of 1300 bytes for IM seems to me, if you don't mind > > my saying ;), a hack. Sort of like the one that limited SMSs to > > be only 160 characters long... > > I certainly don't mind you saying it :-). > > The problem is not just pre-bis proxies, btw. If I understand correctly, > even a bis proxy can choose to switch to UDP if it cannot reach the next > hop > via TCP. A general fix might lie there. Right. We did that to handle backwards compatibility with UAs that are pre-bis and don't support TCP. I must admit that I also dislike the artificial limit. But, I've been thinking about this more, and I think a different perspective on it helps. Generally, page mode allows arbitrarily large content to be sent. However, after a certain size is exceeded, the protocol moves to a model of indirect content instead of directly sending it. I would argue that the reason for this is not so much congestion control, but consent. If you are sending an IM to a user on a wireless phone, you really don't want to send them that 300meg movie unless they really want it. Content indirection allows the recipient the ability to decide whether they want the content now or later. This makes a lot of sense for content of varied types and of larger sized content. So, overall, an IM system that provides page mode can support messages of any size, it just requires content indirection to support the larger stuff. So, all of that means we need this little content indirection thing pretty badly, after all. My sense from the interim meeting was that the requirements work was actually in pretty good shape, and we were ready to get moving on the implementation, which is also pretty straightforward. It really belongs in sip not simple, though. I hope our ADs would be gracious about getting a work item into sip whose purpose is to greatly enhance the story on consent and congestion control.... ;) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 15:55:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09114 for ; Thu, 16 May 2002 15:55:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09004 for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:55:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08204; Thu, 16 May 2002 15:30:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08160 for ; Thu, 16 May 2002 15:30:23 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07813 for ; Thu, 16 May 2002 15:30:09 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJVGYH011751; Thu, 16 May 2002 15:31:17 -0400 (EDT) Message-ID: <3CE408AA.6E1417BF@dynamicsoft.com> Date: Thu, 16 May 2002 15:29:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Possible ABNF bug References: <3CE2B67C.11209B4@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > > Hi, > > Bis-09 says that the "@" character is not allowed in the SIP-URI (or > SIPS-URI) if the userinfo part of the URI is empty (eg "@sip.world.com" > is not allowed). > > However, the ABNF says: > > SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters [ > headers ] > > userinfo = [ user / telephone-subscriber [ ":" password ]] > > Now, the first line (defines SIP-URI) does indicate that userinfo, > together with @, is optional in the URI. > > The second line (defines userinfo), however, indicates that user, > telephone-subscriber and password ALSO are optional for userinfo, which > to my understanding means that an empty value IS a valid value for > userinfo. This is an error. > > I think the correct syntax should be: > > userinfo = ( user / telephone-subscriber [ ":" password ]) > > Also, does the syntax above password to be used together with user, or > only together with telephone-subscriber? IF so, then I guess the correct > syntax shall be: > > userinfo = ( user / telephone-subscriber) [ ":" password ] Correct. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 15:59:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09271 for ; Thu, 16 May 2002 15:59:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09097 for sip-archive@odin.ietf.org; Thu, 16 May 2002 16:00:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08624; Thu, 16 May 2002 15:37:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08594 for ; Thu, 16 May 2002 15:37:45 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08232 for ; Thu, 16 May 2002 15:37:30 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJceYH011760; Thu, 16 May 2002 15:38:40 -0400 (EDT) Message-ID: <3CE40A66.5CD536D8@dynamicsoft.com> Date: Thu, 16 May 2002 15:37:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org Subject: Re: [Sip] Message draft changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Actually, I pulled the number out of the bis-09, which says you SHOULD > use > congestion control if your content-size is >1300. Clearly, that number > appears to be chosen there for the reasons you mention. I agree with > your > statement, but I prefer to keep the number consistent between the > message > draft and the SIP spec. Actually, the spec uses 1300 only when the path MTU is not known: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU 3572 is unknown, the request MUST be sent using TCP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 16:39:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10249 for ; Thu, 16 May 2002 16:39:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11532 for sip-archive@odin.ietf.org; Thu, 16 May 2002 16:39:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09770; Thu, 16 May 2002 16:11:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09738 for ; Thu, 16 May 2002 16:11:43 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09483 for ; Thu, 16 May 2002 16:11:27 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4GKB3d04104; Thu, 16 May 2002 15:11:04 -0500 From: "Dean Willis" To: Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, Date: Thu, 16 May 2002 15:10:31 -0500 Message-ID: <007f01c1fd15$bc104d10$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revised: draft-willis-sip-svcrtdisco to -04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bernie and I have revised the Service Route Discovery draft. This was pretty much just a language cleanup with a few points clarified in REGISTER processing if there is a stored P-Service-Route. We also attempted to globally change the term "header" to "header field" to be consistent with the language in RFC 3261. The latest version is available at: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-04.htm l http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-04.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-04.xml And should be available soon on the IETF site. Please note that this draft is in "Expert Review", closing very soon . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 16:57:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10722 for ; Thu, 16 May 2002 16:57:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12002 for sip-archive@odin.ietf.org; Thu, 16 May 2002 16:57:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10165; Thu, 16 May 2002 16:21:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10133 for ; Thu, 16 May 2002 16:21:46 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09701 for ; Thu, 16 May 2002 16:21:31 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4GKL6d04229; Thu, 16 May 2002 15:21:07 -0500 From: "Dean Willis" To: Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, Date: Thu, 16 May 2002 15:20:35 -0500 Message-ID: <008b01c1fd17$23743ce0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008C_01C1FCED.3A9E34E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] Alert to Version Number Issue: I-D ACTION:draft-willis-sip-path-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_008C_01C1FCED.3A9E34E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Somehow I got out of synch with the Internet-Drafts list, and my path -07 got announced as -06 and my -06 didn't get announced at all. Oops. Way forward: I have reset the softarmor site to match IETF. The "unannounced" version -06 is in the morgue area as -06a. The version currently posted is officially version -06, and has been amended to match. A new version -07 containing final changes should be forthcoming, so the whole thing becomes only a matter of historical interest anyhow. -- Dean -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, May 15, 2002 6:12 AM To: IETF-Announce: Cc: sip@ietf.org Subject: I-D ACTION:draft-willis-sip-path-06.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, B. Hoeneisen Filename : draft-willis-sip-path-06.txt Pages : 17 Date : 14-May-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: 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 request travelling from the user's home network to the registered UA must traverse these proxies. The REGISTER method 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 field, 'Path' which provides such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.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-willis-sip-path-06.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-path-06.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. ------=_NextPart_000_008C_01C1FCED.3A9E34E0 Content-Type: Message/External-body; name="ATT00137.dat" Content-Disposition: attachment; filename="ATT00137.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020514141854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-path-06.txt ------=_NextPart_000_008C_01C1FCED.3A9E34E0 Content-Type: Message/External-body; name="draft-willis-sip-path-06.txt" Content-Disposition: attachment; filename="draft-willis-sip-path-06.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020514141854.I-D@ietf.org> ------=_NextPart_000_008C_01C1FCED.3A9E34E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 18:17:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12240 for ; Thu, 16 May 2002 18:17:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15499 for sip-archive@odin.ietf.org; Thu, 16 May 2002 18:17:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14477; Thu, 16 May 2002 17:46:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14446 for ; Thu, 16 May 2002 17:46:24 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11757 for ; Thu, 16 May 2002 17:46:08 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GLkGX29582; Thu, 16 May 2002 16:46:16 -0500 (CDT) From: "Ben Campbell" To: "Jonathan Rosenberg" Cc: , , Subject: RE: [Sip] Message draft changes Date: Thu, 16 May 2002 16:46:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CE40A66.5CD536D8@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, May 16, 2002 2:37 PM > To: Ben Campbell > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org > Subject: Re: [Sip] Message draft changes > > > > > Ben Campbell wrote: > > > > Actually, I pulled the number out of the bis-09, which says you SHOULD > > use > > congestion control if your content-size is >1300. Clearly, that number > > appears to be chosen there for the reasons you mention. I agree with > > your > > statement, but I prefer to keep the number consistent between the > > message > > draft and the SIP spec. > > > Actually, the spec uses 1300 only when the path MTU is not known: > > If a request is within 200 bytes of the path MTU, or if it is larger > than 1300 bytes and the path MTU 3572 > is unknown, the request MUST be sent using TCP. > > But, unless the UAC sending a MESSAGE request has only one hop, it is very unlikely that the UAC can know the MTU for each hop. I can add text handles the case for when you _do_ know the full path MTU--but I don't think that situation will occur very often in the pager model. Thanks! Ben. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 18:27:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12387 for ; Thu, 16 May 2002 18:27:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15731 for sip-archive@odin.ietf.org; Thu, 16 May 2002 18:27:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15157; Thu, 16 May 2002 18:01:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15126 for ; Thu, 16 May 2002 18:01:27 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12006 for ; Thu, 16 May 2002 18:01:11 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4GM0so00724; Thu, 16 May 2002 18:00:54 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA24270; Thu, 16 May 2002 17:00:53 -0500 (CDT) Message-ID: <3CE42BED.3070109@lucent.com> Date: Thu, 16 May 2002 17:00:13 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3CD949D5.7080907@lucent.com> <3CE40757.27745562@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan: vkg>2) Timer B controls transaction timeouts in INVITE client trans- vkg> actions. The state diagram in Figure 5 is silent on what to vkg> do if Timer B fires while control is in "Proceeding" state; i.e. vkg> received a 180, but no final response. The correct behavior vkg> should be to sent a CANCEL and enter "Terminated" state. jdr> No. Timer C used to be in here, specifying the amount of time the jdr> caller "lets the phone ring". However, this really only needs to be jdr> specified for proxies (which is whats in bis). For the UAC, how jdr> long to let the phone ring is entirely application specific. Hmmm, so what happens in the following case: UAC: INVITE sip:rep@aa.business Expires: 30 UAS: 182 Queued 5 minutes waiting time [after 1/2 minute] UAS: 182 Queued 4.5 minutes waiting time After 30 seconds, the UAC will tear the transaction down since it never got a final response; it got provisional responses which made proxies increase their Timer C so they were fine. But what about the UAC? Looking at Figure 5, it seems that UAC will also benefit from a dynamic transaction timeout window. Furthermore, why set Timer B in the "Calling" state? If UDP is being used, we will know on the second retx that a UAS does not exist (if the socket is bind()'ed to the UAS -- funny, this is missing from -09bis). If TCP (or TLS, or I believe even SCTP) is being used, the connection will fail right away. So, a transport error is bound to occur in the "Calling" state if a UAS does not exist. Is it possible to set timer B in the "Proceeding" state and initalize it to the value of the Expires header (if present, T1*64 if not) and then dynamically updated on provisionals, just like proxies? For that matter, consider the above call flow for a UAS. The spec now dictates (in Section 13.3.1) that if the INVITE contained an Expires header, then the UAS should generate a 487 after the time in Expires expires. So based on this interpretation, should the UAS at aa.business even accept the session since it knows that there is no way a final response will be generated in 30 seconds and there is no way it can get the UAC to extend the expiration time? vkg> Should -09bis provide some guidance on timers to use in proxy cores vkg> if serial forking is being used and > 1 Contact header is present, vkg> or should this be left upto the implementer? jdr> The timer value to use when moving amongst contacts depends heavily jdr> on the application. I suspect that normally there would be some jdr> logic guiding the sequential operation, rather than just based on jdr> the q values. As such, I think this is best left as implementation jdr> specific. I still believe that the spec will not go wrong if it provided some guidance. For instance, most people are tuned to picking up their phone before 4 rings since after that it kicks over to answering machines or voice mail servers. 4 rings is about 20 seconds. Maybe 20 seconds is a good default for a UAC branch to be tried in case serial forking. vkg>3) Regarding finding the spiraled R-R on responses in order to vkg> modify it (section 16.7, step 8), won't it be the case that vkg> the first R-R in a response corresponds to the inner-most vkg> spiral? Since the inner-most spiral will generate the first vkg> response, can't we just get the first R-R header on a response vkg> in order to modify it? jdr> Thats true for the first loop through, but not the second (or jdr> subsequent) loops through. Remember, record-routes are not popped jdr> as you traverse through it. Yes, of course; you are absolutely right. I conveniently forgot that part. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 18:57:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13245 for ; Thu, 16 May 2002 18:57:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17279 for sip-archive@odin.ietf.org; Thu, 16 May 2002 18:57:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16680; Thu, 16 May 2002 18:35:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16649 for ; Thu, 16 May 2002 18:35:47 -0400 (EDT) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12658 for ; Thu, 16 May 2002 18:35:31 -0400 (EDT) Message-ID: <20020516223546.72165.qmail@web11607.mail.yahoo.com> Received: from [207.46.137.8] by web11607.mail.yahoo.com via HTTP; Thu, 16 May 2002 15:35:46 PDT Date: Thu, 16 May 2002 15:35:46 -0700 (PDT) From: Sean Olson Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) To: Jonathan Rosenberg , Ben Campbell Cc: aki.niemi@nokia.com, sip@ietf.org In-Reply-To: <3CE405B6.68310065@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The consent piece is an interesting adjunct to the content indirection requirements. I already allude to the fact that you need to be able to negotiate support / demand for such a mechanism. Do we need to express explicit policy about when content indirection should be used? /sean --- Jonathan Rosenberg wrote: > > > Ben Campbell wrote: > > > > > -----Original Message----- > > > From: aki.niemi@nokia.com > [mailto:aki.niemi@nokia.com] > > > Sent: Thursday, May 16, 2002 9:47 AM > > > To: bcampbell@dynamicsoft.com; sip@ietf.org > > > Subject: RE: MESSAGE size limitations (Was: RE: > [Sip] Message draft > > > changes) > > > > > > > > > > {snip} > > > > > > > > I wish I had a piece of text to suggest that > would satisfy this, > > > but I don't. I understand that there may be a > non-bis09 > > > compatible proxy out there despite the > suggestions made about the > > > congestion control in the MESSAGE draft. But > still, fixing a > > > maximum size of 1300 bytes for IM seems to me, > if you don't mind > > > my saying ;), a hack. Sort of like the one that > limited SMSs to > > > be only 160 characters long... > > > > I certainly don't mind you saying it :-). > > > > The problem is not just pre-bis proxies, btw. If I > understand correctly, > > even a bis proxy can choose to switch to UDP if it > cannot reach the next > > hop > > via TCP. A general fix might lie there. > > Right. We did that to handle backwards compatibility > with UAs that are > pre-bis and don't support TCP. > > I must admit that I also dislike the artificial > limit. But, I've been > thinking about this more, and I think a different > perspective on it > helps. Generally, page mode allows arbitrarily large > content to be sent. > However, after a certain size is exceeded, the > protocol moves to a model > of indirect content instead of directly sending it. > I would argue that > the reason for this is not so much congestion > control, but consent. If > you are sending an IM to a user on a wireless phone, > you really don't > want to send them that 300meg movie unless they > really want it. Content > indirection allows the recipient the ability to > decide whether they want > the content now or later. This makes a lot of sense > for content of > varied types and of larger sized content. > > So, overall, an IM system that provides page mode > can support messages > of any size, it just requires content indirection to > support the larger > stuff. > > So, all of that means we need this little content > indirection thing > pretty badly, after all. My sense from the interim > meeting was that the > requirements work was actually in pretty good shape, > and we were ready > to get moving on the implementation, which is also > pretty > straightforward. It really belongs in sip not > simple, though. I hope our > ADs would be gracious about getting a work item into > sip whose purpose > is to greatly enhance the story on consent and > congestion control.... ;) > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle > Rock Avenue > Chief Scientist First Floor > dynamicsoft East > Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) > 952-5050 > http://www.jdrosen.net PH: (973) > 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 19:16:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13628 for ; Thu, 16 May 2002 19:16:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18208 for sip-archive@odin.ietf.org; Thu, 16 May 2002 19:16:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17255; Thu, 16 May 2002 18:56:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17208 for ; Thu, 16 May 2002 18:56:41 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13214 for ; Thu, 16 May 2002 18:56:25 -0400 (EDT) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4GMtad05293; Thu, 16 May 2002 17:55:36 -0500 Message-Id: <200205162255.g4GMtad05293@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Anders Kristensen Subject: Re: [Sip] Revision of draft-willis-sip-path to version -07 Date: Thu, 16 May 2002 17:55:35 -0500 X-Mailer: KMail [version 1.3.2] Cc: sip@ietf.org References: <01cb01c1fb77$429f2310$133fed0c@C1893415A> <3CE17F78.4050006@dynamicsoft.com> In-Reply-To: <3CE17F78.4050006@dynamicsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 14 May 2002 04:19 pm, Anders Kristensen wrote: > Hi Dean, > > You're still missing a couple: > > Line 190 (txt version): "reuqest" fixed > Line 253: "vfield" fixed > Other nits... > > Line 46: Does not compute: "The problem is that network topology may > be that..." restructured to: "The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request travelling fromt he user's home network to the registered UA must traverse these proxies." " > Line 139: is "service proxy" an established term? Why not just > "proxy". Switched to "home proxy" and added the definition: "a proxy serving as the terminal point for routing an address-of-record". > Line 141: is "transited" really a real word? yes. > > Line 147: "The proposed Path extension header field...". When > becoming RFC it's no longer a proposal. deleted. > Line 172: > > 2. The same set of intervening proxies MUST be visited by > requests between a home service proxy and the UA. That is, the proxy > route between the home service proxy and the UA is the exact reverse > of the proxy route between the UA and its registrar. > > As the draft points out later, this is not, strictly speaking, a > condition for applicability. One might end up with a subset of teh > path travelled by the REGISTER and also, a proxy might insert > addresses other than its own on the Path. rephrased as: "The same intermediate proxies or a set of proxies known to the intermediate proxies must be traversed, in reverse order, by requests sent through a home service proxy to the UA. In the simplest form, the route between the home service proxy and the UA is the exact inverse of the route between the UA and the route between the UA and the registrar" > Line 198: > > The primary difference between Path and Record-Route is that Path > applies to REGISTER and 200 OK responses to REGISTER. > Record-Route doesn't, and can't be defined in REGISTER for reasons of > backward compatibility. > > I'd say the more important difference is that Record-Route applies to > the dialog being set by the request it's used in whereas Path is used > to establish a route for subsequent requests. rephrased to: "The difference between Path and Record-Route is that Path applies toR EGISTER and 200 OK responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility. Furthermore, the vector established by Record-Route applies only to requests within the dialog that established that Record-Route, whereas the vector established by Path applies to future dialogs." -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 16 21:07:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16206 for ; Thu, 16 May 2002 21:07:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA24042 for sip-archive@odin.ietf.org; Thu, 16 May 2002 21:07:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22855; Thu, 16 May 2002 20:37:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22823 for ; Thu, 16 May 2002 20:37:24 -0400 (EDT) Received: from web12306.mail.yahoo.com (web12306.mail.yahoo.com [216.136.173.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15741 for ; Thu, 16 May 2002 20:37:09 -0400 (EDT) Message-ID: <20020517003722.69951.qmail@web12306.mail.yahoo.com> Received: from [64.121.72.77] by web12306.mail.yahoo.com via HTTP; Thu, 16 May 2002 17:37:22 PDT Date: Thu, 16 May 2002 17:37:22 -0700 (PDT) From: Natasha Varshney To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1723336866-1021595842=:68776" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --0-1723336866-1021595842=:68776 Content-Type: text/plain; charset=us-ascii Hi All, I am doing a research project on SIP security and privacy considerations.All I found was the working papers on the subject.Iam looking for some technical papers if available.If anyone can help... Thanks --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-1723336866-1021595842=:68776 Content-Type: text/html; charset=us-ascii

Hi All,

I am doing a research project on SIP security  and privacy considerations.All I  found was the working papers on the subject.Iam looking for some technical papers if available.If anyone can help...

Thanks


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-1723336866-1021595842=:68776-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 05:12:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06313 for ; Fri, 17 May 2002 05:12:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25336 for sip-archive@odin.ietf.org; Fri, 17 May 2002 05:12:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22768; Fri, 17 May 2002 04:31:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22710 for ; Fri, 17 May 2002 04:30:58 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05644 for ; Fri, 17 May 2002 04:30:43 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4H8Uos7014917; Fri, 17 May 2002 10:30:51 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4H8Uo9q020013; Fri, 17 May 2002 11:30:50 +0300 (EET DST) Message-ID: <3CE4BFBC.5C7FD554@lmf.ericsson.se> Date: Fri, 17 May 2002 11:30:52 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Possible ABNF bug References: <3CE2B67C.11209B4@lmf.ericsson.se> <3CE408AA.6E1417BF@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > > Bis-09 says that the "@" character is not allowed in the SIP-URI (or > > SIPS-URI) if the userinfo part of the URI is empty (eg "@sip.world.com" > > is not allowed). > > > > However, the ABNF says: > > > > SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters [ > > headers ] > > > > userinfo = [ user / telephone-subscriber [ ":" password ]] > > > > Now, the first line (defines SIP-URI) does indicate that userinfo, > > together with @, is optional in the URI. > > > > The second line (defines userinfo), however, indicates that user, > > telephone-subscriber and password ALSO are optional for userinfo, which > > to my understanding means that an empty value IS a valid value for > > userinfo. > > This is an error. > > > > > I think the correct syntax should be: > > > > userinfo = ( user / telephone-subscriber [ ":" password ]) > > > > Also, does the syntax above password to be used together with user, or > > only together with telephone-subscriber? IF so, then I guess the correct > > syntax shall be: > > > > userinfo = ( user / telephone-subscriber) [ ":" password ] > > Correct. Then, if we "continue" the syntax, it says: user = *( unreserved / escaped / user-unreserved ) So, even if userinfo must contain user (or telephone-subscriber) this still allows an empty value for user, which again allows an empty value for userinfo... So, I guess the correct syntax for user would be: user = 1*( unreserved / escaped / user-unreserved ) (If userinfo contains telephone-subscriber we don't have this problem, since telephone-subscriber always must contain some characters). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 06:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07646 for ; Fri, 17 May 2002 06:57:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29359 for sip-archive@odin.ietf.org; Fri, 17 May 2002 06:57:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27013; Fri, 17 May 2002 05:58:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26982 for ; Fri, 17 May 2002 05:58:49 -0400 (EDT) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06887 for ; Fri, 17 May 2002 05:58:34 -0400 (EDT) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Wed, 17 May 2000 12:08:53 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <39228BD5.13877.1515E3BE@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Subject: [Sip] via header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, I have a doubt regarding how the Via header is completed at the transport layer. Should the transport indicated in the sent-protocol parameter be modified, if the request was solicited to be sent on UDP, and the transport layer decided to send it on TCP? if not, what's the purpose of indicating UDP by the transaction layer? thanks Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 07:46:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09307 for ; Fri, 17 May 2002 07:46:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01665 for sip-archive@odin.ietf.org; Fri, 17 May 2002 07:47:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00536; Fri, 17 May 2002 07:26:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00504 for ; Fri, 17 May 2002 07:26:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08445; Fri, 17 May 2002 07:26:08 -0400 (EDT) Message-Id: <200205171126.HAA08445@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 17 May 2002 07:26:08 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : HTTP Digest Authentication Using AKA Author(s) : A. Niemi, J. Arkko, V. Torvinen Filename : draft-ietf-sip-digest-aka-02.txt Pages : 18 Date : 16-May-02 The Hypertext Transfer Protocol (HTTP) Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The Authentication and Key Agreement (AKA) mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. This memo specifies an AKA based one-time password generation mechanism for HTTP Digest access authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-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-ietf-sip-digest-aka-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-digest-aka-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-digest-aka-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-digest-aka-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145630.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 07:53:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09482 for ; Fri, 17 May 2002 07:53:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01746 for sip-archive@odin.ietf.org; Fri, 17 May 2002 07:53:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00574; Fri, 17 May 2002 07:26:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00540 for ; Fri, 17 May 2002 07:26:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08461; Fri, 17 May 2002 07:26:14 -0400 (EDT) Message-Id: <200205171126.HAA08461@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 17 May 2002 07:26:13 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 Session Inititation Protocol (SIP) Author(s) : B. Biggs, R. Dean, R. Mahy Filename : draft-ietf-sip-replaces-02.txt Pages : 17 Date : 16-May-02 This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Retrieve from Call Park'. Note that definition of these example features is non-normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-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-ietf-sip-replaces-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-replaces-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-replaces-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-replaces-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145640.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 11:52:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18274 for ; Fri, 17 May 2002 11:52:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14328 for sip-archive@odin.ietf.org; Fri, 17 May 2002 11:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13368; Fri, 17 May 2002 11:31:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13337 for ; Fri, 17 May 2002 11:31:52 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17620 for ; Fri, 17 May 2002 11:31:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFWVYH012633; Fri, 17 May 2002 11:32:32 -0400 (EDT) Message-ID: <3CE52234.E6B387CD@dynamicsoft.com> Date: Fri, 17 May 2002 11:31:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: Ben Campbell , aki.niemi@nokia.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: <20020516223546.72165.qmail@web11607.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: > > The consent piece is an interesting adjunct to the > content indirection requirements. I already allude > to the fact that you need to be able to negotiate > support / demand for such a mechanism. > > Do we need to express explicit policy about when > content indirection should be used? What I was saying is that the page mode spec DEFINES that policy explicitly - anything over 1300 bytes means indirection. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 12:03:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18988 for ; Fri, 17 May 2002 12:03:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16639 for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:03:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13648; Fri, 17 May 2002 11:38:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13549 for ; Fri, 17 May 2002 11:38:09 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17767 for ; Fri, 17 May 2002 11:37:53 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFd4YH012636; Fri, 17 May 2002 11:39:05 -0400 (EDT) Message-ID: <3CE523BE.B75B8BDC@dynamicsoft.com> Date: Fri, 17 May 2002 11:37:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3CE42BED.3070109@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > > Jonathan: > > vkg>2) Timer B controls transaction timeouts in INVITE client trans- > vkg> actions. The state diagram in Figure 5 is silent on what to > vkg> do if Timer B fires while control is in "Proceeding" state; i.e. > vkg> received a 180, but no final response. The correct behavior > vkg> should be to sent a CANCEL and enter "Terminated" state. > > jdr> No. Timer C used to be in here, specifying the amount of time the > jdr> caller "lets the phone ring". However, this really only needs to be > jdr> specified for proxies (which is whats in bis). For the UAC, how > jdr> long to let the phone ring is entirely application specific. > > Hmmm, so what happens in the following case: > > UAC: INVITE sip:rep@aa.business > Expires: 30 > > UAS: 182 Queued 5 minutes waiting time > [after 1/2 minute] > UAS: 182 Queued 4.5 minutes waiting time > > After 30 seconds, the UAC will tear the transaction down since it never > got a final response; it got provisional responses which made proxies > increase their Timer C so they were fine. But what about the UAC? It will probably cancel after 30 seconds. I think this is the right thing. A phone shouldn't be putting Expires in the INVITE unless it really means it. Ultimately, its a policy issue here. The UAC has expressed a policy, and the UAS has asked for more time. Who wins? I say, the UAC wins, since its the one that is making the call. The current mechanism reflects that, and you should insert Expires headers only if thats what you want. > Looking at Figure 5, it seems that UAC will also benefit from a > dynamic transaction timeout window. Furthermore, why set Timer B in > the "Calling" state? If UDP is being used, we will know on the second > retx that a UAS does not exist (if the socket is bind()'ed to the UAS -- > funny, this is missing from -09bis). If TCP (or TLS, or I believe even > SCTP) is being used, the connection will fail right away. So, a > transport error is bound to occur in the "Calling" state if a UAS does > not exist. Is it possible to set timer B in the "Proceeding" state and > initalize it to the value of the Expires header (if present, T1*64 if > not) and then dynamically updated on provisionals, just like proxies? I'm lost. Timer B handles time outs because of no response whatsoever. > > For that matter, consider the above call flow for a UAS. The spec now > dictates (in Section 13.3.1) that if the INVITE contained an Expires > header, then the UAS should generate a 487 after the time in Expires > expires. So based on this interpretation, should the UAS at aa.business > even accept the session since it knows that there is no way a final > response will be generated in 30 seconds and there is no way it can get > the UAC to extend the expiration time? It can do whatever it wants. I would be inclined to play a prompt that says "your call won't be answered within the expiration time you've specified. Please specify a longer time". Phones shouldn't be arbitrarily be putting Expires in the INVITEs like that. > > vkg> Should -09bis provide some guidance on timers to use in proxy cores > vkg> if serial forking is being used and > 1 Contact header is present, > vkg> or should this be left upto the implementer? > > jdr> The timer value to use when moving amongst contacts depends heavily > > jdr> on the application. I suspect that normally there would be some > jdr> logic guiding the sequential operation, rather than just based on > jdr> the q values. As such, I think this is best left as implementation > jdr> specific. > > I still believe that the spec will not go wrong if it provided some > guidance. For instance, most people are tuned to picking up their > phone before 4 rings since after that it kicks over to answering > machines or voice mail servers. 4 rings is about 20 seconds. Maybe > 20 seconds is a good default for a UAC branch to be tried in case > serial forking. It depends on the app; going to voicemail is one thing, doing a hunt across a group of customer service reps is another thing. Both are sequential fork, but both use different timers. I don't see the need to overspecify this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 12:04:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19051 for ; Fri, 17 May 2002 12:04:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16799 for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:05:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13872; Fri, 17 May 2002 11:41:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13841 for ; Fri, 17 May 2002 11:41:08 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17834 for ; Fri, 17 May 2002 11:40:51 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFg3YH012643; Fri, 17 May 2002 11:42:03 -0400 (EDT) Message-ID: <3CE5246E.74AA4210@dynamicsoft.com> Date: Fri, 17 May 2002 11:40:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org Subject: Re: [Sip] Message draft changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, May 16, 2002 2:37 PM > > To: Ben Campbell > > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org > > Subject: Re: [Sip] Message draft changes > > > > > > > > > > Ben Campbell wrote: > > > > > > Actually, I pulled the number out of the bis-09, which says you > SHOULD > > > use > > > congestion control if your content-size is >1300. Clearly, that > number > > > appears to be chosen there for the reasons you mention. I agree with > > > your > > > statement, but I prefer to keep the number consistent between the > > > message > > > draft and the SIP spec. > > > > > > Actually, the spec uses 1300 only when the path MTU is not known: > > > > If a request is within 200 bytes of the path MTU, or if it is larger > > than 1300 bytes and the path MTU 3572 > > is unknown, the request MUST be sent using TCP. > > > > > > But, unless the UAC sending a MESSAGE request has only one hop, it is > very > unlikely that the UAC can know the MTU for each hop. I can add text > handles > the case for when you _do_ know the full path MTU--but I don't think > that > situation will occur very often in the pager model. Careful here! Path and hop mean different things to folks at layer 3 and at the app layer. The Path MTU refers to the smallest MTU along each router hop from the IP source to the IP destination. For SIP, that is just a single "hop" from the UAC to a proxy, say. Each SIP "hop" (between UAC and proxy, or proxy to proxy) will have a different path MTU, and could conceivably make a different transport decision based on that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 12:10:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19243 for ; Fri, 17 May 2002 12:10:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16959 for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:10:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14062; Fri, 17 May 2002 11:43:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14030 for ; Fri, 17 May 2002 11:43:41 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17888 for ; Fri, 17 May 2002 11:43:25 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFidYH012826; Fri, 17 May 2002 11:44:40 -0400 (EDT) Message-ID: <3CE5250A.4FFF01B0@dynamicsoft.com> Date: Fri, 17 May 2002 11:43:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Possible ABNF bug References: <3CE4BFBC.5C7FD554@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > > Hi, > > > > Bis-09 says that the "@" character is not allowed in the SIP-URI (or > > > SIPS-URI) if the userinfo part of the URI is empty (eg > "@sip.world.com" > > > is not allowed). > > > > > > However, the ABNF says: > > > > > > SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters > [ > > > headers ] > > > > > > userinfo = [ user / telephone-subscriber [ ":" password ]] > > > > > > Now, the first line (defines SIP-URI) does indicate that userinfo, > > > together with @, is optional in the URI. > > > > > > The second line (defines userinfo), however, indicates that user, > > > telephone-subscriber and password ALSO are optional for userinfo, > which > > > to my understanding means that an empty value IS a valid value for > > > userinfo. > > > > This is an error. > > > > > > > > I think the correct syntax should be: > > > > > > userinfo = ( user / telephone-subscriber [ ":" password ]) > > > > > > Also, does the syntax above password to be used together with user, > or > > > only together with telephone-subscriber? IF so, then I guess the > correct > > > syntax shall be: > > > > > > userinfo = ( user / telephone-subscriber) [ ":" password ] > > > > Correct. > > Then, if we "continue" the syntax, it says: > > user = *( unreserved / escaped / user-unreserved ) > > So, even if userinfo must contain user (or telephone-subscriber) this > still > allows an empty value for user, which again allows an empty value for > userinfo... > > So, I guess the correct syntax for user would be: > > user = 1*( unreserved / escaped / user-unreserved ) > > (If userinfo contains telephone-subscriber we don't have this problem, > since > telephone-subscriber always must contain some characters). Right again. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 12:22:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19647 for ; Fri, 17 May 2002 12:22:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17426 for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14382; Fri, 17 May 2002 11:53:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14351 for ; Fri, 17 May 2002 11:53:03 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18304 for ; Fri, 17 May 2002 11:52:47 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4HFqOHs029079; Fri, 17 May 2002 08:52:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABR48415; Fri, 17 May 2002 08:49:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01773; Fri, 17 May 2002 08:52:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15589.10039.127865.917811@thomasm-u1.cisco.com> Date: Fri, 17 May 2002 08:52:23 -0700 (PDT) To: Jonathan Rosenberg Cc: Sean Olson , Ben Campbell , aki.niemi@nokia.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) In-Reply-To: <3CE52234.E6B387CD@dynamicsoft.com> References: <20020516223546.72165.qmail@web11607.mail.yahoo.com> <3CE52234.E6B387CD@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Sean Olson wrote: > > > > The consent piece is an interesting adjunct to the > > content indirection requirements. I already allude > > to the fact that you need to be able to negotiate > > support / demand for such a mechanism. > > > > Do we need to express explicit policy about when > > content indirection should be used? > > What I was saying is that the page mode spec DEFINES that policy > explicitly - anything over 1300 bytes means indirection. Jonathan, While I like the spirit of your proposal, I wonder if it's going to run into operational problems. Client's don't typically run web servers (especially on some well known OSen). Also: some cable MSO's filter port 80 to kill home web servers. That means that they'd have to find and upload that data to a willing web server. For long-lived data that's not unreasonable, but for short term/transient data that seems like a pretty big burden. When we discussed this ages ago it was in the context of inlining jpeg mug shots and the like. However if the context is IM, I'm not so sure again. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 12:24:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19670 for ; Fri, 17 May 2002 12:24:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17451 for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:24:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14527; Fri, 17 May 2002 11:55:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14498 for ; Fri, 17 May 2002 11:55:34 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18404 for ; Fri, 17 May 2002 11:55:13 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4HFt4X03762; Fri, 17 May 2002 10:55:05 -0500 (CDT) From: "Ben Campbell" To: "Jonathan Rosenberg" Cc: , , Subject: RE: [Sip] Message draft changes Date: Fri, 17 May 2002 10:54:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CE5246E.74AA4210@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, May 17, 2002 10:41 AM > To: Ben Campbell > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org > Subject: Re: [Sip] Message draft changes > > > > > Ben Campbell wrote: > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, May 16, 2002 2:37 PM > > > To: Ben Campbell > > > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org > > > Subject: Re: [Sip] Message draft changes > > > > > > > > > > > > > > > Ben Campbell wrote: > > > > > > > > Actually, I pulled the number out of the bis-09, which says you > > SHOULD > > > > use > > > > congestion control if your content-size is >1300. Clearly, that > > number > > > > appears to be chosen there for the reasons you mention. I agree with > > > > your > > > > statement, but I prefer to keep the number consistent between the > > > > message > > > > draft and the SIP spec. > > > > > > > > > Actually, the spec uses 1300 only when the path MTU is not known: > > > > > > If a request is within 200 bytes of the path MTU, or if it is larger > > > than 1300 bytes and the path MTU 3572 > > > is unknown, the request MUST be sent using TCP. > > > > > > > > > > But, unless the UAC sending a MESSAGE request has only one hop, it is > > very > > unlikely that the UAC can know the MTU for each hop. I can add text > > handles > > the case for when you _do_ know the full path MTU--but I don't think > > that > > situation will occur very often in the pager model. > > Careful here! Path and hop mean different things to folks at layer 3 and > at the app layer. The Path MTU refers to the smallest MTU along each > router hop from the IP source to the IP destination. For SIP, that is > just a single "hop" from the UAC to a proxy, say. Each SIP "hop" > (between UAC and proxy, or proxy to proxy) will have a different path > MTU, and could conceivably make a different transport decision based on > that. Ah, thanks for the terminology lession--I mean to say, that it is very unlikely that the MTU will know the smallest path MTU for every SIP device end-to-end. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 17 13:17:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21820 for ; Fri, 17 May 2002 13:17:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20213 for sip-archive@odin.ietf.org; Fri, 17 May 2002 13:18:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18620; Fri, 17 May 2002 12:47:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18589 for ; Fri, 17 May 2002 12:47:35 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20370 for ; Fri, 17 May 2002 12:47:19 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4HGlXr19335; Fri, 17 May 2002 12:47:34 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA02935; Fri, 17 May 2002 11:47:32 -0500 (CDT) Message-ID: <3CE53421.1050903@lucent.com> Date: Fri, 17 May 2002 11:47:29 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3CE42BED.3070109@lucent.com> <3CE523BE.B75B8BDC@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] >>Looking at Figure 5, it seems that UAC will also benefit from a >>dynamic transaction timeout window. Furthermore, why set Timer B in >>the "Calling" state? If UDP is being used, we will know on the second >>retx that a UAS does not exist (if the socket is bind()'ed to the UAS -- >>funny, this is missing from -09bis). If TCP (or TLS, or I believe even >>SCTP) is being used, the connection will fail right away. So, a >>transport error is bound to occur in the "Calling" state if a UAS does >>not exist. Is it possible to set timer B in the "Proceeding" state and >>initalize it to the value of the Expires header (if present, T1*64 if >>not) and then dynamically updated on provisionals, just like proxies? > > I'm lost. Timer B handles time outs because of no response whatsoever. OK; let me explain...in Figure 5, Calling state is exited when either of the following events occur: (1) Receipt of a 2xx (2) Receipt of a 1xx (3) Timer B fires (4) Transport error In case of UDP, a transport error will occur when the request is retx'd on a bound socket where a server is not listening. In case of TCP (TLS/TCP) and SCTP, a transport error will occur as soon as an attempt is made to establish a connection to an address where a server is not listening. Control thus always goes to Terminated state in case of a transport error (event (4)). Control also goes to Terminated state when a 2xx is received while in Calling state (event (1)). So that leaves events (2) and (3) for exiting Calling state. If we receive a 1xx (event (2)), we transit to Proceeding state as normal and *then* start Timer B. If we do not start Timer B in the Calling state, we are guaranteed to have exited Calling state either through events (4) (2) or (1). If we exit Calling state due to event (2), we can *then* start Timer B. This has the nice side-effect of maintaining a dynamic Timer B (mirroring Timer C for proxies). BTW, in -09bis I notice that binding UDP sockets to destination addresses (so that a ECONNREFUSED is generated on a retx) has been taken out. Was this intentional or a an error. What I describe above depends on a bound UDP socket. Also note that even if a UAC core does put an "Expires: 60" in a request, the client transaction will still time out in 32 s (T1*64) as per -09bis. Suggested change to the sentence on line 3274 (-09bis, PDF): "For any transport, the client transaction MUST start timer B with a value of the Expires header, if present, or 64*T1 if not." Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 15:30:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00323 for ; Fri, 17 May 2002 15:30:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27499 for sip-archive@odin.ietf.org; Fri, 17 May 2002 15:31:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25862; Fri, 17 May 2002 15:01:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25834 for ; Fri, 17 May 2002 15:01:26 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27825 for ; Fri, 17 May 2002 15:01:11 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4HJ0Ed11561; Fri, 17 May 2002 14:00:14 -0500 From: "Dean Willis" To: "'Michael Thomas'" , "'Jonathan Rosenberg'" Cc: "'Sean Olson'" , "'Ben Campbell'" , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Fri, 17 May 2002 13:59:40 -0500 Message-ID: <003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <15589.10039.127865.917811@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit One must ask -- at what point should one transition from IM to email? Mike rote: > Jonathan Rosenberg writes: > > > > > > Sean Olson wrote: > > > > > > The consent piece is an interesting adjunct to the > > > content indirection requirements. I already allude > > > to the fact that you need to be able to negotiate > > > support / demand for such a mechanism. > > > > > > Do we need to express explicit policy about when > > > content indirection should be used? > > > > What I was saying is that the page mode spec DEFINES that > policy > explicitly - anything over 1300 bytes means indirection. > > > Jonathan, > > While I like the spirit of your proposal, I wonder > if it's going to run into operational problems. > Client's don't typically run web servers . . . > short term/transient data that seems like a pretty > big burden. > > When we discussed this ages ago it was in the > context of inlining jpeg mug shots and the like. > However if the context is IM, I'm not so sure > again. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 15:42:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01265 for ; Fri, 17 May 2002 15:42:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28365 for sip-archive@odin.ietf.org; Fri, 17 May 2002 15:42:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26353; Fri, 17 May 2002 15:14:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26319 for ; Fri, 17 May 2002 15:14:55 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28544 for ; Fri, 17 May 2002 15:14:40 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4HJE9uF008741; Fri, 17 May 2002 12:14:09 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABR54045; Fri, 17 May 2002 12:11:14 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA01781; Fri, 17 May 2002 12:14:16 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15589.22152.263398.962375@thomasm-u1.cisco.com> Date: Fri, 17 May 2002 12:14:16 -0700 (PDT) To: "Dean Willis" Cc: "'Michael Thomas'" , "'Jonathan Rosenberg'" , "'Sean Olson'" , "'Ben Campbell'" , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) In-Reply-To: <003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2> References: <15589.10039.127865.917811@thomasm-u1.cisco.com> <003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > > One must ask -- at what point should one transition from IM to > email? Immediately? Mike, buddyless _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 16:23:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02804 for ; Fri, 17 May 2002 16:23:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29758 for sip-archive@odin.ietf.org; Fri, 17 May 2002 16:23:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28674; Fri, 17 May 2002 15:51:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28643 for ; Fri, 17 May 2002 15:51:52 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01686 for ; Fri, 17 May 2002 15:51:36 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA06492; Fri, 17 May 2002 15:51:36 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4HJpZ2i022695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 May 2002 15:51:35 -0400 (EDT) Message-ID: <3CE55F35.4020107@cs.columbia.edu> Date: Fri, 17 May 2002 15:51:17 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , "'Jonathan Rosenberg'" , "'Sean Olson'" , "'Ben Campbell'" , aki.niemi@nokia.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: <15589.10039.127865.917811@thomasm-u1.cisco.com> <003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2> <15589.22152.263398.962375@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Joking aside, this may not be such a bad idea: Send an IM with a message reference, with email sent simultaneously. Generally, mail delivery is measured in seconds (and for the long messages we're talking about here, any processing delays would tend to be overwhelmed by transport delays). Avoids all firewall, cable modem restriction and NAT issues and, to boot, leverages off the likelihood that SIP and SMTP address are the same. Plus, with IMAP, the client already gets to decide whether to download attachments or not. Michael Thomas wrote: > Dean Willis writes: > > > > One must ask -- at what point should one transition from IM to > > email? > > Immediately? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 17:32:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07107 for ; Fri, 17 May 2002 17:32:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04304 for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:32:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02528; Fri, 17 May 2002 17:02:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02497 for ; Fri, 17 May 2002 17:02:53 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04905 for ; Fri, 17 May 2002 17:02:37 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4HL2LI32393 for ; Fri, 17 May 2002 16:02:21 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 16:02:16 -0500 Message-ID: <70565611B164D511957A001083FCDD560187031C@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Fri, 17 May 2002 16:02:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Asserted-Identity: How to 'hint'? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In the course of the discussion between Mark Watson, Cullen Jennings and myself about the short-term identity work, we have returned a few times to the question of the infamous hint. This hint is, of course, a way that a user agent (one that is not a member of the Trust Domain in the short-term network asserted identity space) can provide a 'hint' to the intermediary that will generate an Asserted-Identity indicating which identity among several possibilities should be asserted. The need for this arises particularly from the 3G space, in which the authentication process takes place independently of SIP and does not carry this sort of personal identity information. It also assumes that the operators of the intermediary in question are aware of several legitimate identities which the user can elect to assert. It has been proposed on the mailing list and elsewhere that the Asserted-Identity header should be re-used by user agents outside the Trust Domain to provide such a hint. I see a number of reasons for and against using the Asserted-Identity for this purpose. For example, today, there is a requirement that asserted-identities which are transmitted from untrusted sources should not be used in any way - this would seem to weaken that requirement. There is also possibly some behavior that still needs to be specified (like how an intermediary would reject or otherwise handle a request with an inappropriate hint) that might be impactful to our choice. For the time being, however, I would like to suggest that providing the hint is outside the scope of the current deliverables (the asserted-identity requirements and mechanism drafts), which need to be complete, as we discussed in the interim meeting, by the end of this month. I believe that a separate draft should propose the use of Asserted-Identity or any other header for this hint (in whatever timeframe is appropriate for 3G's requirements), but that we should not speak to this matter in the current asserted-identity deliverables. There is, as I see it, no dependency on defining this hint before we dictate how intermediaries will assert identities. Any comments on this plan? Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 17:48:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07921 for ; Fri, 17 May 2002 17:48:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04578 for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:48:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03225; Fri, 17 May 2002 17:17:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03178 for ; Fri, 17 May 2002 17:17:26 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06047 for ; Fri, 17 May 2002 17:17:10 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4HLGnX26667; Fri, 17 May 2002 16:16:49 -0500 (CDT) From: "Ben Campbell" To: "Henning Schulzrinne" , "Michael Thomas" , "Dean Willis" , "'Jonathan Rosenberg'" , "'Sean Olson'" , Cc: Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Fri, 17 May 2002 16:16:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CE55F35.4020107@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK, to summarize where I think we are, I have seen 4 proposals for dealing with the message size controversy: 1) Just live with it. IM's are not designed to carry large content anyway. Large content should be sent using some other mechanism, like in-session messages, content indirection, or something completely different like email. (bottom line: limit stays, with perhaps a clarification of the how the limit relates to the lowest hop MTU.) 2) Fix the SIP "feature" that creates this problem in the first place, i.e. the fact that a proxy can fail over to UDP even when a congestion controlled transport is requested. Jonathan suggested dissallowing this proxy behavior for large content messages. I'm not sure how hard that charge would be to get into 3261. 3) Adding something like a proxy-require:contestion-safe tag, so that the UAC can insist on end-to-end congestion control. This of course means that large content MESSAGE requests could not pass _any_ existing proxies--but that is no more limiting than saying you can't have large content messages at all. It at least gives us a way to relax the limit if we someday do get proxies that support the tag. 4) Relax the limit back to a should, but take no further action. I do not think that would pass IESG muster at this point. Personally I lean towards option 1. Pager model IMs are really _not_ intended to be a file transfer mechanism. Even without a strict limit, I think that large content messages (where content is physically carried in the message) are a misuse of the mechanism. We should work to specify an indirect-content mechanism, a session based mechanism, or both. But those are out of scope for pager model messaging, and should not become a dependency for this draft. Option 4 is pretty much out of the question. 2 & 3 may be doable, but are significant enough that we might need to re-cycle the last call. This really seems to be a full circle discussion, back to IMPP requirements days. I think our best bet is to narrow the scope to something solveable--that is short text (or otherwise small content) instant messages, solve that, then work on more sophisticated mechanisms for large content. Thoughts? > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, May 17, 2002 2:51 PM > To: Michael Thomas > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell'; > aki.niemi@nokia.com; sip@ietf.org > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > > Joking aside, this may not be such a bad idea: Send an IM with a message > reference, with email sent simultaneously. Generally, mail delivery is > measured in seconds (and for the long messages we're talking about here, > any processing delays would tend to be overwhelmed by transport delays). > Avoids all firewall, cable modem restriction and NAT issues and, to > boot, leverages off the likelihood that SIP and SMTP address are the > same. Plus, with IMAP, the client already gets to decide whether to > download attachments or not. > > Michael Thomas wrote: > > Dean Willis writes: > > > > > > One must ask -- at what point should one transition from IM to > > > email? > > > > Immediately? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 17:50:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08101 for ; Fri, 17 May 2002 17:50:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04609 for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:50:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03724; Fri, 17 May 2002 17:29:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03694 for ; Fri, 17 May 2002 17:28:58 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06761 for ; Fri, 17 May 2002 17:28:42 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA14023; Fri, 17 May 2002 17:28:46 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4HLSi2i027240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 May 2002 17:28:45 -0400 (EDT) Message-ID: <3CE575FA.7070800@cs.columbia.edu> Date: Fri, 17 May 2002 17:28:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Michael Thomas , Dean Willis , "'Jonathan Rosenberg'" , "'Sean Olson'" , aki.niemi@nokia.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Plus, even if we do (1), this does not preclude (3) and maybe even (2) in the future, should there be a demonstrated need. Ben Campbell wrote: > OK, to summarize where I think we are, I have seen 4 proposals for dealing > with the message size controversy: > > 1) Just live with it. IM's are not designed to carry large content anyway. > Large content should be sent using some other mechanism, like in-session > messages, content indirection, or something completely different like email. > (bottom line: limit stays, with perhaps a clarification of the how the limit > relates to the lowest hop MTU.) > > 2) Fix the SIP "feature" that creates this problem in the first place, i.e. > the fact that a proxy can fail over to UDP even when a congestion controlled > transport is requested. Jonathan suggested dissallowing this proxy behavior > for large content messages. I'm not sure how hard that charge would be to > get into 3261. > > 3) Adding something like a proxy-require:contestion-safe tag, so that the > UAC can insist on end-to-end congestion control. This of course means that > large content MESSAGE requests could not pass _any_ existing proxies--but > that is no more limiting than saying you can't have large content messages > at all. It at least gives us a way to relax the limit if we someday do get > proxies that support the tag. > > 4) Relax the limit back to a should, but take no further action. I do not > think that would pass IESG muster at this point. > > Personally I lean towards option 1. Pager model IMs are really _not_ > intended to be a file transfer mechanism. Even without a strict limit, I > think that large content messages (where content is physically carried in > the message) are a misuse of the mechanism. We should work to specify an > indirect-content mechanism, a session based mechanism, or both. But those > are out of scope for pager model messaging, and should not become a > dependency for this draft. Option 4 is pretty much out of the question. 2 & > 3 may be doable, but are significant enough that we might need to re-cycle > the last call. > > This really seems to be a full circle discussion, back to IMPP requirements > days. I think our best bet is to narrow the scope to something > solveable--that is short text (or otherwise small content) instant messages, > solve that, then work on more sophisticated mechanisms for large content. > > Thoughts? > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Friday, May 17, 2002 2:51 PM >>To: Michael Thomas >>Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell'; >>aki.niemi@nokia.com; sip@ietf.org >>Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft >>changes) >> >> >>Joking aside, this may not be such a bad idea: Send an IM with a message >>reference, with email sent simultaneously. Generally, mail delivery is >>measured in seconds (and for the long messages we're talking about here, >>any processing delays would tend to be overwhelmed by transport delays). >>Avoids all firewall, cable modem restriction and NAT issues and, to >>boot, leverages off the likelihood that SIP and SMTP address are the >>same. Plus, with IMAP, the client already gets to decide whether to >>download attachments or not. >> >>Michael Thomas wrote: >> >>>Dean Willis writes: >>> > >>> > One must ask -- at what point should one transition from IM to >>> > email? >>> >>> Immediately? >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 17:53:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08249 for ; Fri, 17 May 2002 17:53:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04706 for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:53:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03187; Fri, 17 May 2002 17:17:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03110 for ; Fri, 17 May 2002 17:17:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06040; Fri, 17 May 2002 17:17:04 -0400 (EDT) Message-Id: <200205172117.RAA06040@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Fri, 17 May 2002 17:17:04 -0400 Subject: [Sip] Protocol Action: The Session Initiation Protocol UPDATE Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved the publication of the following two I-Ds as Proposed Standards: o The Session Initiation Protocol UPDATE Method o Integration of Resource Management and SIP These documents are the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary UPDATE is a new method for the Session Initiation protocol. It allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of the dialog. This means that it functions like a re-INVITE (sending a second INVITE methd), but it can be sent before the initial INVITE has completed, and therefore can serve purposes of early dialog negotiation. UPDATE needs source authentication and integrity protection, which are provided by mechanisms in RFC BBBB, the SIP protocol specification. Some architectures require that at session establishment time, once the callee has been alerted, the chances of a session establishment failure are minimum. One source of failure is the inability to reserve network resources for a session. In order to minimize "ghost rings", it is necessary to reserve network resources for the session before the callee is alerted. However, the reservation of network resources frequently requires learning the IP address, port, and session parameters from the callee. This information is obtained as a result of the initial offer/ answer Exchange carried in SIP. This exchange normally causes the "phone To ring", thus introducing a chicken-and-egg problem: resources cannot be reserved without performing an initial offer/answer exchange, and the initial offer/answer exchange can't be done without performing resource reservation. The solution is to introduce the concept of a precondition. A precondition is a set of constraints about the session which are introduced in the offer. The recipient of the offer generates an answer, but does not alert the user or otherwise proceed with session establishment. That only occurs when the preconditions are met. This can be known through a local event (such as a confirmation of a resource reservation), or through a new offer sent by the caller. Any specifics of resource reservation mechanisms or how a SIP endpoint might get local confirmation of the precondition being met are outside the scope of resource management integration specification. The preconditions are defined in the Session Description Protocol (SDP) parameters for the session, and the exchange in the SDP offer-answer, because they apply to specific media streams identified with the SDP body in SIP. Security needed for the preconditions exchanges includes source authentication and integrity protection, and these are provided by mechanisms in RFC BBBB. Working Group Summary The resource management integration spec was simplified considerably by the introduction of the UPDATE method. After that simplifying revision, both specs were strongly supported by the working group for advancement. Protocol Quality The specifications were reviewed for the IESG by Allison Mankin. John Loughney also did a careful review of the resource management integration spec. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 18:02:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08643 for ; Fri, 17 May 2002 18:02:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05344 for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:02:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04450; Fri, 17 May 2002 17:40:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04419 for ; Fri, 17 May 2002 17:40:05 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07423 for ; Fri, 17 May 2002 17:39:49 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g4HLe3B08914; Fri, 17 May 2002 17:40:03 -0400 (EDT) Reply-To: From: "Eric Burger" To: "Ben Campbell" Cc: Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Fri, 17 May 2002 17:41:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If we can wait, I would actually rather do #3. #2 is a non-starter; there are too many proxies that would blithely pass along the content. #4 is a non-starter; this is asking to break the Internet. We all know that people will use IM instead of e-mail to send that 4MB presentation and that 3GB movie. #1, which works, is a hack. It also will break some QoS schemes. E.g., SIP signaling gets higher priority than e-mail. #3 is, in a sense the correct answer (short of the truly correct answer on not sending content in a session initiation protocol, but that's another flame...). If the question of the proxy is, "can you safely transmit this?", then let us ask that question! To show the silliness of sending content in a session protocol, another solution that has not been mentioned yet would be to put congestion control into SIP #-))) [eyes shut closed!] -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Ben Campbell Sent: Friday, May 17, 2002 5:17 PM To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; aki.niemi@nokia.com Cc: sip@ietf.org Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) OK, to summarize where I think we are, I have seen 4 proposals for dealing with the message size controversy: 1) Just live with it. IM's are not designed to carry large content anyway. Large content should be sent using some other mechanism, like in-session messages, content indirection, or something completely different like email. (bottom line: limit stays, with perhaps a clarification of the how the limit relates to the lowest hop MTU.) 2) Fix the SIP "feature" that creates this problem in the first place, i.e. the fact that a proxy can fail over to UDP even when a congestion controlled transport is requested. Jonathan suggested dissallowing this proxy behavior for large content messages. I'm not sure how hard that charge would be to get into 3261. 3) Adding something like a proxy-require:contestion-safe tag, so that the UAC can insist on end-to-end congestion control. This of course means that large content MESSAGE requests could not pass _any_ existing proxies--but that is no more limiting than saying you can't have large content messages at all. It at least gives us a way to relax the limit if we someday do get proxies that support the tag. 4) Relax the limit back to a should, but take no further action. I do not think that would pass IESG muster at this point. Personally I lean towards option 1. Pager model IMs are really _not_ intended to be a file transfer mechanism. Even without a strict limit, I think that large content messages (where content is physically carried in the message) are a misuse of the mechanism. We should work to specify an indirect-content mechanism, a session based mechanism, or both. But those are out of scope for pager model messaging, and should not become a dependency for this draft. Option 4 is pretty much out of the question. 2 & 3 may be doable, but are significant enough that we might need to re-cycle the last call. This really seems to be a full circle discussion, back to IMPP requirements days. I think our best bet is to narrow the scope to something solveable--that is short text (or otherwise small content) instant messages, solve that, then work on more sophisticated mechanisms for large content. Thoughts? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 18:14:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09083 for ; Fri, 17 May 2002 18:14:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05646 for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:14:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04668; Fri, 17 May 2002 17:52:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04637 for ; Fri, 17 May 2002 17:52:39 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08196 for ; Fri, 17 May 2002 17:52:23 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4HLq7X29043; Fri, 17 May 2002 16:52:07 -0500 (CDT) From: "Ben Campbell" To: "Henning Schulzrinne" Cc: "Michael Thomas" , "Dean Willis" , "'Jonathan Rosenberg'" , "'Sean Olson'" , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Fri, 17 May 2002 16:51:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CE575FA.7070800@cs.columbia.edu> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Agreed, although the current wording might preclude that. Maybe it would be worth a slight mod that says if you _know_ all hops are congestion controlled, you can exceed the limit. Then a future solution for 2 and 3 would not be precluded. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, May 17, 2002 4:28 PM > To: Ben Campbell > Cc: Michael Thomas; Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; > aki.niemi@nokia.com; sip@ietf.org > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > > Plus, even if we do (1), this does not preclude (3) and maybe even (2) > in the future, should there be a demonstrated need. > > Ben Campbell wrote: > > OK, to summarize where I think we are, I have seen 4 proposals > for dealing > > with the message size controversy: > > > > 1) Just live with it. IM's are not designed to carry large > content anyway. > > Large content should be sent using some other mechanism, like in-session > > messages, content indirection, or something completely > different like email. > > (bottom line: limit stays, with perhaps a clarification of the > how the limit > > relates to the lowest hop MTU.) > > > > 2) Fix the SIP "feature" that creates this problem in the first > place, i.e. > > the fact that a proxy can fail over to UDP even when a > congestion controlled > > transport is requested. Jonathan suggested dissallowing this > proxy behavior > > for large content messages. I'm not sure how hard that charge > would be to > > get into 3261. > > > > 3) Adding something like a proxy-require:contestion-safe tag, > so that the > > UAC can insist on end-to-end congestion control. This of course > means that > > large content MESSAGE requests could not pass _any_ existing > proxies--but > > that is no more limiting than saying you can't have large > content messages > > at all. It at least gives us a way to relax the limit if we > someday do get > > proxies that support the tag. > > > > 4) Relax the limit back to a should, but take no further > action. I do not > > think that would pass IESG muster at this point. > > > > Personally I lean towards option 1. Pager model IMs are really _not_ > > intended to be a file transfer mechanism. Even without a strict limit, I > > think that large content messages (where content is physically > carried in > > the message) are a misuse of the mechanism. We should work to specify an > > indirect-content mechanism, a session based mechanism, or both. > But those > > are out of scope for pager model messaging, and should not become a > > dependency for this draft. Option 4 is pretty much out of the > question. 2 & > > 3 may be doable, but are significant enough that we might need > to re-cycle > > the last call. > > > > This really seems to be a full circle discussion, back to IMPP > requirements > > days. I think our best bet is to narrow the scope to something > > solveable--that is short text (or otherwise small content) > instant messages, > > solve that, then work on more sophisticated mechanisms for > large content. > > > > Thoughts? > > > > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Friday, May 17, 2002 2:51 PM > >>To: Michael Thomas > >>Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell'; > >>aki.niemi@nokia.com; sip@ietf.org > >>Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > >>changes) > >> > >> > >>Joking aside, this may not be such a bad idea: Send an IM with a message > >>reference, with email sent simultaneously. Generally, mail delivery is > >>measured in seconds (and for the long messages we're talking about here, > >>any processing delays would tend to be overwhelmed by transport delays). > >>Avoids all firewall, cable modem restriction and NAT issues and, to > >>boot, leverages off the likelihood that SIP and SMTP address are the > >>same. Plus, with IMAP, the client already gets to decide whether to > >>download attachments or not. > >> > >>Michael Thomas wrote: > >> > >>>Dean Willis writes: > >>> > > >>> > One must ask -- at what point should one transition from IM to > >>> > email? > >>> > >>> Immediately? > >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 18:25:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09507 for ; Fri, 17 May 2002 18:25:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05905 for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:25:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05397; Fri, 17 May 2002 18:04:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05370 for ; Fri, 17 May 2002 18:04:23 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08720 for ; Fri, 17 May 2002 18:04:04 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4HM3dc21042 for ; Fri, 17 May 2002 18:03:39 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 17:03:34 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870320@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Fri, 17 May 2002 17:03:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Asserted-Identity: A P- Header? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There has been some substantial discussion in this working group about the naming of the new header for the short-term network asserted identity work. Although it took us some time to arrive on an agreeable name, I'd like to suggest a slight modification to 'Asserted-Identity' - namely that it become a P- header. P- headers are defined in the 'sipchange' draft that discusses how extensions to SIP should be created. The P- is short for 'preliminary', 'private', or 'proprietary' - and in fact, I think the Asserted-Identity header for the short-term work is in fact compatible with all three of those adjectives. More substantially, there are also specific criteria for P- headers provided in the sipchange draft (in section 6.1) and I believe Asserted-Identity is a good match for nearly all of those criteria. sipchange says that P- headers may be appropriate when extensions "are private or proprietary in nature, because a characteristic motivating them is usage that is known not to fit the Internet architecture for SIP." As an extension, short-term asserted identity does not define new methods, responses codes, or option tags (criterion 2). The header is purely informational in nature (criterion 4). Asserted-Identity also bears a significant applicability statement (criterion 7). The current draft also meets the constraints identified by criteria 2 and 3. I'm sure we could get Expert Review as specified in criterion 1, and that the document could be passed as described by criterion 6. What do we gain by making Asserted-Identity a P- header? Really only political leeway; this doesn't entail any changes to how the header works. But the underlying Trust Domain model of the short-term identity work is not very compatible with the Internet model, and this may very well cause us some consternation moving forward this document (some discomfiture along these lines was previously expressed over sip-privacy-04). By making this header a P- header we can deflect this sort of criticism by identifying this as work that is known to be specific to private networks that do not adhere to the Internet model as such. sipchange introduced this concept specifically so that we could get this sort of header passed. If we aren't using the P- header for this, I'm not sure what we'd use it for. One thing that I know we lose by making Asserted-Identity a P- header is that the long-term identity story would no longer use the same header name as the short-term identity work. However, since the interface between long-term, certificate-based identity and short-term, trust-based identity will be defined as a gatewaying process, we really don't incur any cost from using different headers. Personally, I still feel there is something to be gained by using 'From' as the header in the long-term story (specifically, this jibes in certain ways with existing S/MIME behavior in rfc3261). So I suppose I don't find this loss to be troubling. Thoughts? Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 18:56:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11110 for ; Fri, 17 May 2002 18:56:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08766 for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:56:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07428; Fri, 17 May 2002 18:36:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07379 for ; Fri, 17 May 2002 18:36:17 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10172 for ; Fri, 17 May 2002 18:36:01 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4HMZfc21495; Fri, 17 May 2002 18:35:41 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 17:35:36 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870322@va02.va.neustar.com> From: "Peterson, Jon" To: "'Natasha Varshney'" , sip@ietf.org Subject: RE: [Sip] (no subject) Date: Fri, 17 May 2002 17:35:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDF3.266BBE00" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FDF3.266BBE00 Content-Type: text/plain; charset="iso-8859-1" Unfortunately, we only have 'working papers' at the moment, and these are as technical as papers on this subject are likely to get. Be sure to look at rfc2543bis-09, especially sections 22, 23 and 26 on security, since this material is more or less final now. There are a number of drafts examining the general privacy and identity concepts in SIP at the moment; it is a bit of a hot topic. However, the privacy story at least should be stable by the end of this month. Jon Peterson NeuStar, Inc. -----Original Message----- From: Natasha Varshney [mailto:natasha_varshney@yahoo.com] Sent: Thursday, May 16, 2002 5:37 PM To: sip@ietf.org Subject: [Sip] (no subject) Hi All, I am doing a research project on SIP security and privacy considerations.All I found was the working papers on the subject.Iam looking for some technical papers if available.If anyone can help... Thanks _____ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience ------_=_NextPart_001_01C1FDF3.266BBE00 Content-Type: text/html; charset="iso-8859-1"
Unfortunately, we only have 'working papers' at the moment, and these are as technical as papers on this subject are likely to get. Be sure to look at rfc2543bis-09, especially sections 22, 23 and 26 on security, since this material is more or less final now. There are a number of drafts examining the general privacy and identity concepts in SIP at the moment; it is a bit of a hot topic. However, the privacy story at least should be stable by the end of this month.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Natasha Varshney [mailto:natasha_varshney@yahoo.com]
Sent: Thursday, May 16, 2002 5:37 PM
To: sip@ietf.org
Subject: [Sip] (no subject)

Hi All,

I am doing a research project on SIP security  and privacy considerations.All I  found was the working papers on the subject.Iam looking for some technical papers if available.If anyone can help...

Thanks


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
------_=_NextPart_001_01C1FDF3.266BBE00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 18:57:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11171 for ; Fri, 17 May 2002 18:57:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08847 for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:57:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07770; Fri, 17 May 2002 18:39:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07736 for ; Fri, 17 May 2002 18:39:10 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10309 for ; Fri, 17 May 2002 18:38:53 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4HMc1c21520; Fri, 17 May 2002 18:38:02 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 17:37:56 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870323@va02.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" Cc: "'Robert Sparks'" , sip@ietf.org Subject: RE: [Sip] RE: Comment on sip-identity-00 Date: Fri, 17 May 2002 17:37:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Currently, my identity draft allows an authentication service to sign a header that represents a SIP[S] URI, some other headers that provide reference integrity, and optionally any other headers it would like. Thus if your network requires a Network Access Identity, as you suggest, that is distinct from the SIP[S] URI by which a user is identified, that Network Access Identity could be included in a separate header. So I'd like to think that the long-term identity story can accomodate your needs. I will be clarifying the document a bit in this regard as well. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Monday, May 13, 2002 9:35 PM > To: Peterson, Jon > Cc: 'Robert Sparks'; sip@ietf.org > Subject: [Sip] RE: Comment on sip-identity-00 > > > Peterson, Jon writes: > > > These are good points; throughout the identity draft, I > tried to use Digest > > only as an example, and indeed in plenty of authentication > systems the > > identifier of a user would not be suitable syntactically > or semantically for > > the username portion of a SIP URI. I do think it is not > unreasonable, > > however, in systems like Digest for a user to have an > expectation that the > > username they enter into an authentication dialog (for > example) will be the > > username that appears in their authenticated identity. > > i tried to make this same point. in our case the username used in > digest authentication is the general NAI (Network Access Identifier) of > the user and the sip network asserted identity i-d cannot that the > username used in the digest authentication (or any other authentication > scheme) has nothing to do with the sip uris the user may have. the i-d > should make this requirement explicitly clear and also clearly explain > that what is asserted is the sip uri the user wants to use for this > request. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 17 19:03:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11367 for ; Fri, 17 May 2002 19:03:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA09417 for sip-archive@odin.ietf.org; Fri, 17 May 2002 19:03:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08348; Fri, 17 May 2002 18:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08320 for ; Fri, 17 May 2002 18:44:59 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10566 for ; Fri, 17 May 2002 18:44:39 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g4HMikf32190; Fri, 17 May 2002 18:44:46 -0400 From: "Victor Paulsamy" To: Cc: Date: Fri, 17 May 2002 15:43:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Was the Translate heade used? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last but one reads, "... From this 200 OK, the STUN agent knows whether or not the Translate header was used or not." In the example shown, the STUN agent learnt the public IP by querying STUN sever and changed the outgoing REGISTER appropriately to reflect this. When this request reaches the proxy, it checks the sent-by value against the received address; they are same in this case (hence no received= param). Say, the proxy supports SIP extensions for NAT. The proxy then rewrites the Translate header with sent-by value (in this case) which is same as the original value it carried in it. When returned in the 200 OK response, the STUN agent sees that, the Translate header has the same value that it put in, yet, the proxy supports the extension for NAT. So, the Translate header will be different in the response only when the client does not rewrite the private IPs with public ones in the request. Will it not be wrong, per the quoted string, to think that the proxy didn't use the Translate header? Regards, --victor Victor Paulsamy E-mail: victor@zapex.com Senior Software Engineer Phone : 650.930.1339 (Direct) Zapex Technologies, Inc. Phone : 650.930.1300 (Main) Mountain View, CA 94043 Fax : 650.930.1399 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat May 18 01:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24924 for ; Sat, 18 May 2002 01:13:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29710 for sip-archive@odin.ietf.org; Sat, 18 May 2002 01:13:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20493; Sat, 18 May 2002 00:47:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20462 for ; Sat, 18 May 2002 00:47:27 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24029 for ; Sat, 18 May 2002 00:47:08 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 178w7m-0003GK-00; Sat, 18 May 2002 07:47:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15589.56538.116801.546774@harjus.eng.song.fi> Date: Sat, 18 May 2002 07:47:22 +0300 To: "Peterson, Jon" Cc: "'sip@ietf.org'" Subject: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <70565611B164D511957A001083FCDD560187031C@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD560187031C@va02.va.neustar.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > For the time being, however, I would like to suggest that providing the hint > is outside the scope of the current deliverables (the asserted-identity > requirements and mechanism drafts), which need to be complete, as we > discussed in the interim meeting, by the end of this month. I believe that a > separate draft should propose the use of Asserted-Identity or any other > header for this hint (in whatever timeframe is appropriate for 3G's > requirements), but that we should not speak to this matter in the current > asserted-identity deliverables. There is, as I see it, no dependency on > defining this hint before we dictate how intermediaries will assert > identities. > > Any comments on this plan? first, i don't like at all the idea that ietf sip working group discussions are dictated and constrained by 3gpp schedules. we must have time to really solve the problems and not just hide them under the carpet because of 3gpp. second, it is not possible to assert a sip identity of a user without the hint capability in case the user has more than one possible sip identity, because in that case the asserting entity would have no other choice than to reject the call. third, i don't see the hinting problem to be so complex that it would need to be hidden under the carper. in case the caller doesn't want to be anonymous, the sip uri in the from header can serve as the hint. this is also good because of backwards compatibility. in case the from header is "Anonymous", the hint needs to be provided by another header that looks like the from header. we could call it anything, for example, Really-From. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat May 18 01:18:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25082 for ; Sat, 18 May 2002 01:18:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29765 for sip-archive@odin.ietf.org; Sat, 18 May 2002 01:18:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21090; Sat, 18 May 2002 00:54:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21059 for ; Sat, 18 May 2002 00:54:22 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24252 for ; Sat, 18 May 2002 00:54:07 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 178wEW-0003GT-00; Sat, 18 May 2002 07:54:20 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15589.56956.537034.331285@harjus.eng.song.fi> Date: Sat, 18 May 2002 07:54:20 +0300 To: "Ben Campbell" Cc: "Henning Schulzrinne" , "Michael Thomas" , "Dean Willis" , "'Jonathan Rosenberg'" , "'Sean Olson'" , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) In-Reply-To: References: <3CE55F35.4020107@cs.columbia.edu> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell writes: > 2) Fix the SIP "feature" that creates this problem in the first place, i.e. > the fact that a proxy can fail over to UDP even when a congestion controlled > transport is requested. Jonathan suggested dissallowing this proxy behavior > for large content messages. I'm not sure how hard that charge would be to > get into 3261. i'm not quite sure what the above means, but i'm in favor of using hop-by-hop tcp for large messages. if the next sip hop doesn't speak tcp, then the message would simply be rejected until the proxy or the us of the next hop is upgraded. this is not different from other sip messages, such as invite, which too can easily be bigger than the mtu of a link. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 18 06:28:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07680 for ; Sat, 18 May 2002 06:28:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09355 for sip-archive@odin.ietf.org; Sat, 18 May 2002 06:29:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08904; Sat, 18 May 2002 06:04:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08857 for ; Sat, 18 May 2002 06:04:01 -0400 (EDT) Received: from webmail17.rediffmail.com (webmail17.rediffmail.com [203.199.83.27] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07211 for ; Sat, 18 May 2002 06:03:43 -0400 (EDT) Received: (qmail 13738 invoked by uid 510); 18 May 2002 10:03:20 -0000 Date: 18 May 2002 10:03:20 -0000 Message-ID: <20020518100320.13737.qmail@webmail17.rediffmail.com> Received: from unknown (203.197.251.7) by rediffmail.com via HTTP; 18 May 2002 10:03:20 -0000 MIME-Version: 1.0 From: "Ashhar Farhan" Reply-To: "Ashhar Farhan" To: "Henning Schulzrinne" Cc: "Michael Thomas" , "Dean Willis" , "'Jonathan Rosenberg'" , "'Sean Olson'" , aki.niemi@nokia.com, sip@ietf.org, "Ben Campbell" Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Content-type: text/plain; format=flowed Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On Sat, 18 May 2002 Henning Schulzrinne wrote : >Plus, even if we do (1), this does not preclude (3) and maybe >even (2) in the future, should there be a demonstrated need. > if you have been following the noises from GSM world, multimedia messaging is turing out to be a big opportunity (personally, i dont agree), but if you consider that MESSAGE may, at a future date, also contain very large content, then is it not possible that the actual content be a hyperlink in the MESSAGE body? there are some real problems with using MESSAGE for anything but short text messages: 1) it is the charter of SIP that it will use other standardised protocols where required rather than provide an alternative. If we already have ftp, http and a few more available, then why invent yet another one? 2)MESSAGE's main feature is that it is session less so it provides a rapid means of messagine without creating any session. this is not going to be of any particular advantage when u are going to transfer more than a few kilbytes in anycase. In such cases, you are better off with other protocols. using MESSAGE as a carrier of the URL. - farhan _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 18 11:14:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16913 for ; Sat, 18 May 2002 11:14:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17164 for sip-archive@odin.ietf.org; Sat, 18 May 2002 11:14:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16441; Sat, 18 May 2002 10:54:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16410 for ; Sat, 18 May 2002 10:54:14 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16227 for ; Sat, 18 May 2002 10:53:57 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4IErnX96892; Sat, 18 May 2002 09:53:50 -0500 (CDT) From: "Ben Campbell" To: "Ashhar Farhan" , "Henning Schulzrinne" Cc: "Michael Thomas" , "Dean Willis" , "'Jonathan Rosenberg'" , "'Sean Olson'" , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Sat, 18 May 2002 09:53:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020518100320.13737.qmail@webmail17.rediffmail.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Farhan, What you describe is exactly what we mean by content-indirection. The actual payload is merely a URL that refers to external content. This is a lot like the external body part feature already available in MIME. We have work in progress to refine that idea. >From the rest of your email, I assume you concur with my option 1? Thanks! Ben. > -----Original Message----- > From: Ashhar Farhan [mailto:afarhan@rediffmail.com] > Sent: Saturday, May 18, 2002 5:03 AM > To: Henning Schulzrinne > Cc: Michael Thomas; Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; > aki.niemi@nokia.com; sip@ietf.org; Ben Campbell > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > > > > On Sat, 18 May 2002 Henning Schulzrinne wrote : > >Plus, even if we do (1), this does not preclude (3) and maybe > >even (2) in the future, should there be a demonstrated need. > > > > if you have been following the noises from GSM world, multimedia > messaging is turing out to be a big opportunity (personally, i > dont agree), but if you consider that MESSAGE may, at a future > date, also contain very large content, then is it not possible > that the actual content be a hyperlink in the MESSAGE body? > > there are some real problems with using MESSAGE for anything but > short text messages: > > 1) it is the charter of SIP that it will use other standardised > protocols where required rather than provide an alternative. If we > already have ftp, http and a few more available, then why invent > yet another one? > > 2)MESSAGE's main feature is that it is session less so it provides > a rapid means of messagine without creating any session. this is > not going to be of any particular advantage when u are going to > transfer more than a few kilbytes in anycase. In such cases, you > are better off with other protocols. using MESSAGE as a carrier of > the URL. > > - farhan > > > _________________________________________________________ > Click below to visit monsterindia.com and review jobs in India or > Abroad > http://monsterindia.rediff.com/jobs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 18 16:27:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27595 for ; Sat, 18 May 2002 16:27:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26577 for sip-archive@odin.ietf.org; Sat, 18 May 2002 16:27:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26340; Sat, 18 May 2002 16:04:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26309 for ; Sat, 18 May 2002 16:04:52 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26874 for ; Sat, 18 May 2002 16:04:36 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4IK5nYH014022; Sat, 18 May 2002 16:05:50 -0400 (EDT) Message-ID: <3CE6B3C1.91A3507@dynamicsoft.com> Date: Sat, 18 May 2002 16:04:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Victor Paulsamy CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Was the Translate heade used? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Victor Paulsamy wrote: > > In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last > but > one reads, "... From this 200 OK, the STUN agent knows whether or not > the > Translate header was used or not." > > In the example shown, the STUN agent learnt the public IP by querying > STUN > sever and changed the outgoing REGISTER appropriately to reflect this. > When > this request reaches the proxy, it checks the sent-by value against the > received address; they are same in this case (hence no received= param). No, they wouldn't be the same. The registration is sent over TCP, and uses a different port than was used to communicate with the STUN server. > Say, the proxy supports SIP extensions for NAT. The proxy then rewrites > the > Translate header with sent-by value (in this case) which is same as the > original value it carried in it. When returned in the 200 OK response, > the > STUN agent sees that, the Translate header has the same value that it > put > in, yet, the proxy supports the extension for NAT. Since the source port is different than the Contact port, the contact would be rewritten and the client would know. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat May 18 18:14:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01362 for ; Sat, 18 May 2002 18:14:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00184 for sip-archive@odin.ietf.org; Sat, 18 May 2002 18:14:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29397; Sat, 18 May 2002 17:48:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29367 for ; Sat, 18 May 2002 17:48:38 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00507 for ; Sat, 18 May 2002 17:48:20 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22873 for ; Sat, 18 May 2002 17:46:52 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22866 for ; Sat, 18 May 2002 17:46:52 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Sat, 18 May 2002 15:49:19 -0600 Message-ID: Thread-Topic: [Sip] Asserted-Identity: How to 'hint'? Thread-Index: AcH+KKRiRi5T8OCmROW7fHV+QiTeogAh7gTg From: "Zmolek, Andrew (Andrew)" To: , "Peterson, Jon" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA29368 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Juha wrote: > first, i don't like at all the idea that ietf sip working group > discussions are dictated and constrained by 3gpp schedules. we must > have time to really solve the problems and not just hide them > under the carpet because of 3gpp. I agree with Juha's concern here, but at the same time I have to admit that past history in the IETF around this class of problems is not encouraging, so the plausible alternatives seem worse. Regardless of how bullish one might be over 3GPP itself, it has been an effective forcing function for work that would otherwise be bogged down for years in the politics of obstructionism that have taken over so many other well-intentioned working groups around us. Thanks to the seemingly tireless efforts of a few members of the SIP community, we have been able to make tremendous progress in the past year (by addressing concerns head-on--not avoiding and postponing them), and if Jon is ready to take this on I'm inclined to throw more support on the side of getting this done than worry unduly about producing something less than perfect. The IETF is already quite effective at drowning most of its young in an ocean of worry and concern--it would really be quite a feat indeed to produce a runt *and* somehow sneak it by those in the IETF pledged to fight evil in all its many forms. --Andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 11:51:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11763 for ; Sun, 19 May 2002 11:51:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14222 for sip-archive@odin.ietf.org; Sun, 19 May 2002 11:51:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13080; Sun, 19 May 2002 11:25:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13051 for ; Sun, 19 May 2002 11:25:52 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11013 for ; Sun, 19 May 2002 11:25:36 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4JFPLPI002159; Sun, 19 May 2002 08:25:21 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AAE25185 (AUTH rmahy); Sun, 19 May 2002 08:25:20 -0700 (PDT) Message-Id: <200205191525.AAE25185@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with HTTP/1.0; Sun, 19 May 2002 08:29:05 -0700 Date: Sun, 19 May 2002 08:29:05 -0700 From: Rohan Mahy Subject: Re: [Sip] Asserted-Identity: How to 'hint'? To: "Peterson, Jon" Cc: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The requirement for a hint is well understood, limited in scope, and well motivated in the draft. Nobody has identified any technical reason why the hint won't work. Your argument that allowing a hint weakens the strength of the language on ignoring Asserted-Identity from untrusted parties is purely philosophical in nature. I don't buy your argument. thanks, -rohan ---- Original message ---- >Date: Fri, 17 May 2002 16:02:11 -0500 >From: "Peterson, Jon" >Subject: [Sip] Asserted-Identity: How to 'hint'? >To: "'sip@ietf.org'" > > >In the course of the discussion between Mark Watson, Cullen Jennings and >myself about the short-term identity work, we have returned a few times to >the question of the infamous hint. This hint is, of course, a way that a >user agent (one that is not a member of the Trust Domain in the short-term >network asserted identity space) can provide a 'hint' to the intermediary >that will generate an Asserted-Identity indicating which identity among >several possibilities should be asserted. > >The need for this arises particularly from the 3G space, in which the >authentication process takes place independently of SIP and does not carry >this sort of personal identity information. It also assumes that the >operators of the intermediary in question are aware of several legitimate >identities which the user can elect to assert. > >It has been proposed on the mailing list and elsewhere that the >Asserted-Identity header should be re-used by user agents outside the Trust >Domain to provide such a hint. I see a number of reasons for and against >using the Asserted-Identity for this purpose. For example, today, there is a >requirement that asserted-identities which are transmitted from untrusted >sources should not be used in any way - this would seem to weaken that >requirement. There is also possibly some behavior that still needs to be >specified (like how an intermediary would reject or otherwise handle a >request with an inappropriate hint) that might be impactful to our choice. > >For the time being, however, I would like to suggest that providing the hint >is outside the scope of the current deliverables (the asserted-identity >requirements and mechanism drafts), which need to be complete, as we >discussed in the interim meeting, by the end of this month. I believe that a >separate draft should propose the use of Asserted-Identity or any other >header for this hint (in whatever timeframe is appropriate for 3G's >requirements), but that we should not speak to this matter in the current >asserted-identity deliverables. There is, as I see it, no dependency on >defining this hint before we dictate how intermediaries will assert >identities. > >Any comments on this plan? > >Jon Peterson >NeuStar, Inc. > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 11:53:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11818 for ; Sun, 19 May 2002 11:53:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14284 for sip-archive@odin.ietf.org; Sun, 19 May 2002 11:53:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12826; Sun, 19 May 2002 11:18:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12785 for ; Sun, 19 May 2002 11:18:06 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10736 for ; Sun, 19 May 2002 11:17:49 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4JFHVEU023929; Sun, 19 May 2002 08:17:31 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AAE25164 (AUTH rmahy); Sun, 19 May 2002 08:17:30 -0700 (PDT) Message-Id: <200205191517.AAE25164@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with HTTP/1.0; Sun, 19 May 2002 08:21:15 -0700 Date: Sun, 19 May 2002 08:21:15 -0700 From: Rohan Mahy Subject: Re: [Sip] Asserted-Identity: A P- Header? To: "Peterson, Jon" Cc: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I believe a P- header is consistent with the applicability scope built into the draft. I also feel that the cryptographic identity draft should use the Asserted-Identity header (without the P- ). thanks, -rohan ---- Original message ---- >Date: Fri, 17 May 2002 17:03:25 -0500 >From: "Peterson, Jon" >Subject: [Sip] Asserted-Identity: A P- Header? >To: "'sip@ietf.org'" > > >There has been some substantial discussion in this working group about the >naming of the new header for the short-term network asserted identity work. >Although it took us some time to arrive on an agreeable name, I'd like to >suggest a slight modification to 'Asserted-Identity' - namely that it become >a P- header. > >P- headers are defined in the 'sipchange' draft that discusses how >extensions to SIP should be created. The P- is short for 'preliminary', >'private', or 'proprietary' - and in fact, I think the Asserted-Identity >header for the short-term work is in fact compatible with all three of those >adjectives. More substantially, there are also specific criteria for P- >headers provided in the sipchange draft (in section 6.1) and I believe >Asserted-Identity is a good match for nearly all of those criteria. > >sipchange says that P- headers may be appropriate when extensions "are >private or proprietary in nature, because a characteristic motivating them >is usage that is known not to fit the Internet architecture for SIP." As an >extension, short-term asserted identity does not define new methods, >responses codes, or option tags (criterion 2). The header is purely >informational in nature (criterion 4). Asserted-Identity also bears a >significant applicability statement (criterion 7). The current draft also >meets the constraints identified by criteria 2 and 3. I'm sure we could get >Expert Review as specified in criterion 1, and that the document could be >passed as described by criterion 6. > >What do we gain by making Asserted-Identity a P- header? Really only >political leeway; this doesn't entail any changes to how the header works. >But the underlying Trust Domain model of the short-term identity work is not >very compatible with the Internet model, and this may very well cause us >some consternation moving forward this document (some discomfiture along >these lines was previously expressed over sip-privacy-04). By making this >header a P- header we can deflect this sort of criticism by identifying this >as work that is known to be specific to private networks that do not adhere >to the Internet model as such. sipchange introduced this concept >specifically so that we could get this sort of header passed. If we aren't >using the P- header for this, I'm not sure what we'd use it for. > >One thing that I know we lose by making Asserted-Identity a P- header is >that the long-term identity story would no longer use the same header name >as the short-term identity work. However, since the interface between >long-term, certificate-based identity and short-term, trust-based identity >will be defined as a gatewaying process, we really don't incur any cost from >using different headers. Personally, I still feel there is something to be >gained by using 'From' as the header in the long-term story (specifically, >this jibes in certain ways with existing S/MIME behavior in rfc3261). So I >suppose I don't find this loss to be troubling. > >Thoughts? > >Jon Peterson >NeuStar, Inc. > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 12:50:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13725 for ; Sun, 19 May 2002 12:50:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17496 for sip-archive@odin.ietf.org; Sun, 19 May 2002 12:51:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16434; Sun, 19 May 2002 12:27:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16392 for ; Sun, 19 May 2002 12:27:44 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13173 for ; Sun, 19 May 2002 12:27:27 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 179TX3-0003c0-00; Sun, 19 May 2002 19:27:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15591.53885.740566.581104@harjus.eng.song.fi> Date: Sun, 19 May 2002 19:27:41 +0300 To: Rohan Mahy Cc: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: A P- Header? In-Reply-To: <200205191517.AAE25164@imop.cisco.com> References: <200205191517.AAE25164@imop.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy writes: > I believe a P- header is consistent with the applicability > scope built into the draft. > > I also feel that the cryptographic identity draft should use > the Asserted-Identity header (without the P- ). i don't see the point of having two headers for the same purpose, one with P and one without just in order to meet some 3gpp deadline. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 13:40:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15192 for ; Sun, 19 May 2002 13:40:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20734 for sip-archive@odin.ietf.org; Sun, 19 May 2002 13:40:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19114; Sun, 19 May 2002 13:11:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19083 for ; Sun, 19 May 2002 13:11:44 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14349 for ; Sun, 19 May 2002 13:11:27 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4JHB1I15796; Sun, 19 May 2002 12:11:01 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sun, 19 May 2002 12:10:56 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870328@va02.va.neustar.com> From: "Peterson, Jon" To: "'Rohan Mahy'" Cc: sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Sun, 19 May 2002 12:10:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org My argument was not that the proposed hint won't work - just that it isn't necessary to solve the problem at hand. It might not be the case that the problems with the hint stop at the philosophical point you mention below. What I asked in my last mail was not whether or not we needed a hint, but rather whether or not we should table that question until we resolve the other questions at hand. I just don't want to spend the cycles arguing about the hint given our very aggressive timetable - frankly, I think that reaching consensus on this hint matter might push back our dates a bit. Let's investigate this hint stuff in June, but for now just figure out how a Trust Domain can manage an asserted identity in a message. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, May 19, 2002 8:29 AM > To: Peterson, Jon > Cc: sip@ietf.org > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > Hi, > > The requirement for a hint is well understood, limited in > scope, and well motivated in the draft. Nobody has identified > any technical reason why the hint won't work. Your argument > that allowing a hint weakens the strength of the language on > ignoring Asserted-Identity from untrusted parties is purely > philosophical in nature. I don't buy your argument. > > thanks, > -rohan > > > ---- Original message ---- > >Date: Fri, 17 May 2002 16:02:11 -0500 > >From: "Peterson, Jon" > >Subject: [Sip] Asserted-Identity: How to 'hint'? > >To: "'sip@ietf.org'" > > > > > >In the course of the discussion between Mark Watson, Cullen > Jennings and > >myself about the short-term identity work, we have returned a > few times to > >the question of the infamous hint. This hint is, of course, a > way that a > >user agent (one that is not a member of the Trust Domain in > the short-term > >network asserted identity space) can provide a 'hint' to the > intermediary > >that will generate an Asserted-Identity indicating which > identity among > >several possibilities should be asserted. > > > >The need for this arises particularly from the 3G space, in > which the > >authentication process takes place independently of SIP and > does not carry > >this sort of personal identity information. It also assumes > that the > >operators of the intermediary in question are aware of > several legitimate > >identities which the user can elect to assert. > > > >It has been proposed on the mailing list and elsewhere that the > >Asserted-Identity header should be re-used by user agents > outside the Trust > >Domain to provide such a hint. I see a number of reasons for > and against > >using the Asserted-Identity for this purpose. For example, > today, there is a > >requirement that asserted-identities which are transmitted > from untrusted > >sources should not be used in any way - this would seem to > weaken that > >requirement. There is also possibly some behavior that still > needs to be > >specified (like how an intermediary would reject or otherwise > handle a > >request with an inappropriate hint) that might be impactful > to our choice. > > > >For the time being, however, I would like to suggest that > providing the hint > >is outside the scope of the current deliverables (the > asserted-identity > >requirements and mechanism drafts), which need to be > complete, as we > >discussed in the interim meeting, by the end of this month. I > believe that a > >separate draft should propose the use of Asserted-Identity or > any other > >header for this hint (in whatever timeframe is appropriate > for 3G's > >requirements), but that we should not speak to this matter in > the current > >asserted-identity deliverables. There is, as I see it, no > dependency on > >defining this hint before we dictate how intermediaries will > assert > >identities. > > > >Any comments on this plan? > > > >Jon Peterson > >NeuStar, Inc. > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 14:27:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16825 for ; Sun, 19 May 2002 14:27:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23217 for sip-archive@odin.ietf.org; Sun, 19 May 2002 14:27:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21545; Sun, 19 May 2002 13:58:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21517 for ; Sun, 19 May 2002 13:58:51 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15816 for ; Sun, 19 May 2002 13:58:33 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 179UxF-0003dm-00; Sun, 19 May 2002 20:58:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15591.59353.341736.922912@harjus.eng.song.fi> Date: Sun, 19 May 2002 20:58:49 +0300 To: "Peterson, Jon" Cc: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <70565611B164D511957A001083FCDD5601870328@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD5601870328@va02.va.neustar.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > My argument was not that the proposed hint won't work - just that it isn't > necessary to solve the problem at hand. i don't know what problem you have in hand, but i definitely need the hint to solve the problem that i (and anyone who gateways sip calls to pstn) has in hand: i need a hint header, when i can't use the uri in the from header as the hint, i.e., when the from is anonymous. if the intention of the sip working group is only to solve 3gpp problems and ignore the generic problems, then we either need another working group or the 3gpp folks have to solve their problems somewhere else. the area directors might be able to give a hint what we should do. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 22:00:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04626 for ; Sun, 19 May 2002 22:00:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA19785 for sip-archive@odin.ietf.org; Sun, 19 May 2002 22:00:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17705; Sun, 19 May 2002 21:27:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17669 for ; Sun, 19 May 2002 21:27:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03210 for ; Sun, 19 May 2002 21:27:08 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4K1QtPI015904; Sun, 19 May 2002 18:26:55 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACY38567; Sun, 19 May 2002 18:27:06 -0700 (PDT) From: "Cullen Jennings" To: , "Peterson, Jon" Cc: "'Rohan Mahy'" , Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Sun, 19 May 2002 18:27:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15591.59353.341736.922912@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm not really sure what you see as the problem at hand - I'm just guessing, but ... If the Gateway was part of the Trust Domain, I think you can solve the problem you want without the hint. If the GW is not part of the Trust Domain then I don't see even how the hint will really help if all the elements act as required. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > jh@lohi.eng.song.fi > Sent: Sunday, May 19, 2002 10:59 AM > To: Peterson, Jon > Cc: 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > Peterson, Jon writes: > > > My argument was not that the proposed hint won't work - just > that it isn't > > necessary to solve the problem at hand. > > i don't know what problem you have in hand, but i definitely need the > hint to solve the problem that i (and anyone who gateways sip calls to > pstn) has in hand: i need a hint header, when i can't use the uri in the > from header as the hint, i.e., when the from is anonymous. > > if the intention of the sip working group is only to solve 3gpp problems > and ignore the generic problems, then we either need another working > group or the 3gpp folks have to solve their problems somewhere else. > the area directors might be able to give a hint what we should do. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 22:51:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07205 for ; Sun, 19 May 2002 22:51:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22079 for sip-archive@odin.ietf.org; Sun, 19 May 2002 22:51:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20695; Sun, 19 May 2002 22:27:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20666 for ; Sun, 19 May 2002 22:27:47 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05857 for ; Sun, 19 May 2002 22:27:28 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4K2RFHs010410; Sun, 19 May 2002 19:27:15 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AAE26828 (AUTH rmahy); Sun, 19 May 2002 19:27:14 -0700 (PDT) Message-Id: <200205200227.AAE26828@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with HTTP/1.0; Sun, 19 May 2002 19:31:04 -0700 Date: Sun, 19 May 2002 19:31:04 -0700 From: Rohan Mahy Subject: Re: [Sip] draft-mahy-sipping-join-and-fork-00 To: Victor Paulsamy Cc: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Party "A" might find the dialog information for a Join from an out of band mechanism like a web page, embedded in a Refer-To header in a REFER request, or from some appropriate event package. (there may be other reasonable ways to get this info as well). An appropriate event package will be resubmitted as a SIPPING WG item soon, but is available as an individual draft now as: draft-rosenberg-sip-call-package-01.txt discussion on the two event packages in this draft takes place on the SIPPING WG list: sipping@ietf.org hope this helps. thanks, -rohan ---- Original message ---- >Date: Tue, 14 May 2002 18:02:42 -0700 >From: "Victor Paulsamy" >Subject: [Sip] draft-mahy-sipping-join-and-fork-00 >To: >Cc: , "Victor Paulsamy" > >In e.g., 6.1 Join accepted for local mixing: B&C are in a session. A sends >in an INVITE to B requesting it to add to the existing session (using Join). >How did A learn about the on going session? > >Appreciate any response. > >Regards, > >--victor > >Victor Paulsamy E-mail: victor@zapex.com >Senior Software Engineer Phone : 650.930.1339 (Direct) >Zapex Technologies, Inc. Phone : 650.930.1300 (Main) >Mountain View, CA 94043 Fax : 650.930.1399 > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun May 19 23:07:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08239 for ; Sun, 19 May 2002 23:07:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA23338 for sip-archive@odin.ietf.org; Sun, 19 May 2002 23:07:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21826; Sun, 19 May 2002 22:44:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21790 for ; Sun, 19 May 2002 22:44:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06761 for ; Sun, 19 May 2002 22:43:40 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4K2hRPI003185; Sun, 19 May 2002 19:43:27 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACY38931; Sun, 19 May 2002 19:43:39 -0700 (PDT) From: "Cullen Jennings" To: , "Rohan Mahy" Cc: "Peterson, Jon" , Subject: RE: [Sip] Asserted-Identity: A P- Header? Date: Sun, 19 May 2002 19:44:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15591.53885.740566.581104@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't think the P-Header issue has much to do with 3GPP. The non cryptographic (AKA short term) Asserted-Identity work has a limited scope of applicability - It is not usable in the circumstances we might call the general internet. The way the requirements draft limits where it can be used, and the other agreements that it have to be in place for it to work, is what makes it seem like it lines up with the intent of a P-Header. The cryptographic solution (AKA long term) stuff does not have these limitations and thus would not require a P-Header. It's not clear to me yet, but having it this way might turn out to be very advantageous when building nodes that understand both the crypto and non crypto solutions and need to pass information from one type of domain to another. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > jh@lohi.eng.song.fi > Sent: Sunday, May 19, 2002 9:28 AM > To: Rohan Mahy > Cc: Peterson, Jon; sip@ietf.org > Subject: Re: [Sip] Asserted-Identity: A P- Header? > > > Rohan Mahy writes: > > > I believe a P- header is consistent with the applicability > > scope built into the draft. > > > > I also feel that the cryptographic identity draft should use > > the Asserted-Identity header (without the P- ). > > i don't see the point of having two headers for the same purpose, one > with P and one without just in order to meet some 3gpp deadline. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 00:42:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13255 for ; Mon, 20 May 2002 00:42:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA28359 for sip-archive@odin.ietf.org; Mon, 20 May 2002 00:42:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27139; Mon, 20 May 2002 00:19:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27104 for ; Mon, 20 May 2002 00:19:39 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11599 for ; Mon, 20 May 2002 00:19:21 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 179ee0-0003lq-00; Mon, 20 May 2002 07:19:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15592.31064.107813.518993@harjus.eng.song.fi> Date: Mon, 20 May 2002 07:19:36 +0300 To: "Cullen Jennings" Cc: "Peterson, Jon" , "'Rohan Mahy'" , Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: References: <15591.59353.341736.922912@harjus.eng.song.fi> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cullen Jennings writes: > I'm not really sure what you see as the problem at hand - I'm just guessing, > but ... If the Gateway was part of the Trust Domain, I think you can solve > the problem you want without the hint. no, i can't because the user almost always has multiple sip identities and thus, in the anonymous case, needs to hint the trust domain which identity he/she wants to use for the call. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 05:35:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02131 for ; Mon, 20 May 2002 05:35:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20402 for sip-archive@odin.ietf.org; Mon, 20 May 2002 05:35:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19376; Mon, 20 May 2002 05:13:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19347 for ; Mon, 20 May 2002 05:13:32 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01404 for ; Mon, 20 May 2002 05:13:13 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4K9Dmk18741 for ; Mon, 20 May 2002 12:13:48 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 12:13:24 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 12:13:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 20 May 2002 12:13:24 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED11@esebe013.NOE.Nokia.com> Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Thread-Index: AcH96D4X/9oors2jSqyKRzzY7RPyWgB8oXFg To: , , , , , Cc: X-OriginalArrivalTime: 20 May 2002 09:13:24.0823 (UTC) FILETIME=[986DA670:01C1FFDE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA19348 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, If #2 is in any way possible, let's pursue that. Reading the bis-09 again, I can't help but wonder if the RFC2543 option of still trying with UDP, if TCP has failed actually provides value for messages over the UDP maximum datagram size of 65,535 bytes. If there was a SHOULD in trying UDP when TCP fails, but a SHOULD NOT if size is over 65k, would the MESSAGE then be more well behaved? I.e., enough to be able to relax the size limit to a SHOULD strength in the message draft? Otherwise, I'm ready to live with #2, given that the text is changed to align with bis-09 (MESSAGE talks about payload size, whereas bis-09 talks about request size), and provide with a way to send larger messages if there is a transport with congestion control all the way to the destination. Cheers, Aki > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Saturday, May 18, 2002 12:17 AM > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo) > Cc: sip@ietf.org > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > > OK, to summarize where I think we are, I have seen 4 > proposals for dealing > with the message size controversy: > > 1) Just live with it. IM's are not designed to carry large > content anyway. > Large content should be sent using some other mechanism, like > in-session > messages, content indirection, or something completely > different like email. > (bottom line: limit stays, with perhaps a clarification of > the how the limit > relates to the lowest hop MTU.) > > 2) Fix the SIP "feature" that creates this problem in the > first place, i.e. > the fact that a proxy can fail over to UDP even when a > congestion controlled > transport is requested. Jonathan suggested dissallowing this > proxy behavior > for large content messages. I'm not sure how hard that charge > would be to > get into 3261. > > 3) Adding something like a proxy-require:contestion-safe tag, > so that the > UAC can insist on end-to-end congestion control. This of > course means that > large content MESSAGE requests could not pass _any_ existing > proxies--but > that is no more limiting than saying you can't have large > content messages > at all. It at least gives us a way to relax the limit if we > someday do get > proxies that support the tag. > > 4) Relax the limit back to a should, but take no further > action. I do not > think that would pass IESG muster at this point. > > Personally I lean towards option 1. Pager model IMs are really _not_ > intended to be a file transfer mechanism. Even without a > strict limit, I > think that large content messages (where content is > physically carried in > the message) are a misuse of the mechanism. We should work to > specify an > indirect-content mechanism, a session based mechanism, or > both. But those > are out of scope for pager model messaging, and should not become a > dependency for this draft. Option 4 is pretty much out of the > question. 2 & > 3 may be doable, but are significant enough that we might > need to re-cycle > the last call. > > This really seems to be a full circle discussion, back to > IMPP requirements > days. I think our best bet is to narrow the scope to something > solveable--that is short text (or otherwise small content) > instant messages, > solve that, then work on more sophisticated mechanisms for > large content. > > Thoughts? > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, May 17, 2002 2:51 PM > > To: Michael Thomas > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell'; > > aki.niemi@nokia.com; sip@ietf.org > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > > changes) > > > > > > Joking aside, this may not be such a bad idea: Send an IM > with a message > > reference, with email sent simultaneously. Generally, mail > delivery is > > measured in seconds (and for the long messages we're > talking about here, > > any processing delays would tend to be overwhelmed by > transport delays). > > Avoids all firewall, cable modem restriction and NAT issues and, to > > boot, leverages off the likelihood that SIP and SMTP address are the > > same. Plus, with IMAP, the client already gets to decide whether to > > download attachments or not. > > > > Michael Thomas wrote: > > > Dean Willis writes: > > > > > > > > One must ask -- at what point should one transition from IM to > > > > email? > > > > > > Immediately? > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 07:35:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07065 for ; Mon, 20 May 2002 07:35:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26860 for sip-archive@odin.ietf.org; Mon, 20 May 2002 07:36:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25037; Mon, 20 May 2002 07:09:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25007 for ; Mon, 20 May 2002 07:09:05 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05909 for ; Mon, 20 May 2002 07:08:48 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4KB8RZ24043; Mon, 20 May 2002 13:08:27 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4KB7d210408; Mon, 20 May 2002 12:07:40 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 12:08:37 +0100 Message-ID: From: "Mark Watson" To: "'Peterson, Jon'" , "'Rohan Mahy'" Cc: sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Mon, 20 May 2002 12:08:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FFEE.A9A13BE0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FFEE.A9A13BE0 Content-Type: text/plain; charset="iso-8859-1" The 'hint' was one of the three requirements that 3GPP communicated to us in April. It is a separate requirement from the Network Asserted Identity itself, and so is not addressed in the requirements draft, although I have been careful to point this out, and to point out that it is a requirement nontheless, on several occasions. I believe we need the 'hint' in the same timeframe as the rest of the short term work. Whether it is the same header/draft or a different header/draft is another question on which I will only say that we'd better make up our minds pretty quick. ...Mark > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 19 May 2002 18:11 > To: 'Rohan Mahy' > Cc: sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > My argument was not that the proposed hint won't work - just > that it isn't > necessary to solve the problem at hand. It might not be the > case that the > problems with the hint stop at the philosophical point you > mention below. > What I asked in my last mail was not whether or not we needed > a hint, but > rather whether or not we should table that question until we > resolve the > other questions at hand. I just don't want to spend the > cycles arguing about > the hint given our very aggressive timetable - frankly, I think that > reaching consensus on this hint matter might push back our > dates a bit. > Let's investigate this hint stuff in June, but for now just > figure out how a > Trust Domain can manage an asserted identity in a message. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Sunday, May 19, 2002 8:29 AM > > To: Peterson, Jon > > Cc: sip@ietf.org > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > Hi, > > > > The requirement for a hint is well understood, limited in > > scope, and well motivated in the draft. Nobody has identified > > any technical reason why the hint won't work. Your argument > > that allowing a hint weakens the strength of the language on > > ignoring Asserted-Identity from untrusted parties is purely > > philosophical in nature. I don't buy your argument. > > > > thanks, > > -rohan > > > > > > ---- Original message ---- > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > >From: "Peterson, Jon" > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > >To: "'sip@ietf.org'" > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > Jennings and > > >myself about the short-term identity work, we have returned a > > few times to > > >the question of the infamous hint. This hint is, of course, a > > way that a > > >user agent (one that is not a member of the Trust Domain in > > the short-term > > >network asserted identity space) can provide a 'hint' to the > > intermediary > > >that will generate an Asserted-Identity indicating which > > identity among > > >several possibilities should be asserted. > > > > > >The need for this arises particularly from the 3G space, in > > which the > > >authentication process takes place independently of SIP and > > does not carry > > >this sort of personal identity information. It also assumes > > that the > > >operators of the intermediary in question are aware of > > several legitimate > > >identities which the user can elect to assert. > > > > > >It has been proposed on the mailing list and elsewhere that the > > >Asserted-Identity header should be re-used by user agents > > outside the Trust > > >Domain to provide such a hint. I see a number of reasons for > > and against > > >using the Asserted-Identity for this purpose. For example, > > today, there is a > > >requirement that asserted-identities which are transmitted > > from untrusted > > >sources should not be used in any way - this would seem to > > weaken that > > >requirement. There is also possibly some behavior that still > > needs to be > > >specified (like how an intermediary would reject or otherwise > > handle a > > >request with an inappropriate hint) that might be impactful > > to our choice. > > > > > >For the time being, however, I would like to suggest that > > providing the hint > > >is outside the scope of the current deliverables (the > > asserted-identity > > >requirements and mechanism drafts), which need to be > > complete, as we > > >discussed in the interim meeting, by the end of this month. I > > believe that a > > >separate draft should propose the use of Asserted-Identity or > > any other > > >header for this hint (in whatever timeframe is appropriate > > for 3G's > > >requirements), but that we should not speak to this matter in > > the current > > >asserted-identity deliverables. There is, as I see it, no > > dependency on > > >defining this hint before we dictate how intermediaries will > > assert > > >identities. > > > > > >Any comments on this plan? > > > > > >Jon Peterson > > >NeuStar, Inc. > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1FFEE.A9A13BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Asserted-Identity: How to 'hint'?

The 'hint' was one of the three requirements that = 3GPP communicated to us in April.

It is a separate requirement from the Network = Asserted Identity itself, and so is not addressed in the requirements = draft, although I have been careful to point this out, and to point out = that it is a requirement nontheless, on several occasions.

I believe we need the 'hint' in the same timeframe as = the rest of the short term work.

Whether it is the same header/draft or a different = header/draft is another question on which I will only say that we'd = better make up our minds pretty quick.

...Mark


> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: 19 May 2002 18:11
> To: 'Rohan Mahy'
> Cc: sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to = 'hint'?
>
>
>
> My argument was not that the proposed hint = won't work - just
> that it isn't
> necessary to solve the problem at hand. It = might not be the
> case that the
> problems with the hint stop at the = philosophical point you
> mention below.
> What I asked in my last mail was not whether or = not we needed
> a hint, but
> rather whether or not we should table that = question until we
> resolve the
> other questions at hand. I just don't want to = spend the
> cycles arguing about
> the hint given our very aggressive timetable - = frankly, I think that
> reaching consensus on this hint matter might = push back our
> dates a bit.
> Let's investigate this hint stuff in June, but = for now just
> figure out how a
> Trust Domain can manage an asserted identity in = a message.
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: Sunday, May 19, 2002 8:29 AM
> > To: Peterson, Jon
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] Asserted-Identity: How = to 'hint'?
> >
> >
> > Hi,
> >
> > The requirement for a hint is well = understood, limited in
> > scope, and well motivated in the = draft.  Nobody has identified
> > any technical reason why the hint won't = work.   Your argument
> > that allowing a hint weakens the strength = of the language on
> > ignoring Asserted-Identity from untrusted = parties is purely
> > philosophical in nature.  I don't buy = your argument.
> >
> > thanks,
> > -rohan
> >
> >
> > ---- Original message ----
> > >Date: Fri, 17 May 2002 16:02:11 = -0500
> > >From: "Peterson, Jon" = <jon.peterson@neustar.biz> 
> > >Subject: [Sip] Asserted-Identity: How = to 'hint'? 
> > >To: "'sip@ietf.org'" = <sip@ietf.org>
> > >
> > >
> > >In the course of the discussion = between Mark Watson, Cullen
> > Jennings and
> > >myself about the short-term identity = work, we have returned a
> > few times to
> > >the question of the infamous hint. = This hint is, of course, a
> > way that a
> > >user agent (one that is not a member = of the Trust Domain in
> > the short-term
> > >network asserted identity space) can = provide a 'hint' to the
> > intermediary
> > >that will generate an = Asserted-Identity indicating which
> > identity among
> > >several possibilities should be = asserted.
> > >
> > >The need for this arises particularly = from the 3G space, in
> > which the
> > >authentication process takes place = independently of SIP and
> > does not carry
> > >this sort of personal identity = information. It also assumes
> > that the
> > >operators of the intermediary in = question are aware of
> > several legitimate
> > >identities which the user can elect to = assert.
> > >
> > >It has been proposed on the mailing = list and elsewhere that the
> > >Asserted-Identity header should be = re-used by user agents
> > outside the Trust
> > >Domain to provide such a hint. I see a = number of reasons for
> > and against
> > >using the Asserted-Identity for this = purpose. For example,
> > today, there is a
> > >requirement that asserted-identities = which are transmitted
> > from untrusted
> > >sources should not be used in any way = - this would seem to
> > weaken that
> > >requirement. There is also possibly = some behavior that still
> > needs to be
> > >specified (like how an intermediary = would reject or otherwise
> > handle a
> > >request with an inappropriate hint) = that might be impactful
> > to our choice.
> > >
> > >For the time being, however, I would = like to suggest that
> > providing the hint
> > >is outside the scope of the current = deliverables (the
> > asserted-identity
> > >requirements and mechanism drafts), = which need to be
> > complete, as we
> > >discussed in the interim meeting, by = the end of this month. I
> > believe that a
> > >separate draft should propose the use = of Asserted-Identity or
> > any other
> > >header for this hint (in whatever = timeframe is appropriate
> > for 3G's
> > >requirements), but that we should not = speak to this matter in
> > the current
> > >asserted-identity deliverables. There = is, as I see it, no
> > dependency on
> > >defining this hint before we dictate = how intermediaries will
> > assert
> > >identities.
> > >
> > >Any comments on this plan?
> > >
> > >Jon Peterson
> > >NeuStar, Inc.
> > >
> > = >_______________________________________________
> > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >This list is for NEW development of = the core SIP Protocol
> > >Use sip-implementors@cs.columbia.edu = for questions on current sip
> > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1FFEE.A9A13BE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 08:13:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09748 for ; Mon, 20 May 2002 08:13:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29645 for sip-archive@odin.ietf.org; Mon, 20 May 2002 08:14:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28017; Mon, 20 May 2002 07:55:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27986 for ; Mon, 20 May 2002 07:55:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08329; Mon, 20 May 2002 07:55:05 -0400 (EDT) Message-Id: <200205201155.HAA08329@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 20 May 2002 07:55:05 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Extension Header Field for Service Route Discovery in Private Networks Author(s) : D. Willis, B. Hoeneisen Filename : draft-willis-sip-scvrtdisco-04.txt Pages : 15 Date : 17-May-02 This document proposes a private SIP extension header used in conjunction with responses to REGISTER messages to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-04.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-willis-sip-scvrtdisco-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-scvrtdisco-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020517135143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-scvrtdisco-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-scvrtdisco-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517135143.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 09:44:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16447 for ; Mon, 20 May 2002 09:44:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05468 for sip-archive@odin.ietf.org; Mon, 20 May 2002 09:44:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03509; Mon, 20 May 2002 09:17:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03455 for ; Mon, 20 May 2002 09:17:29 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13834 for ; Mon, 20 May 2002 09:17:09 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4KDGVX54642; Mon, 20 May 2002 08:16:33 -0500 (CDT) From: "Ben Campbell" To: , , , , , Cc: Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Mon, 20 May 2002 08:16:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED11@esebe013.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Would you expect the MESSAGE draft to stall waiting for a 3261 fix? > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Monday, May 20, 2002 4:13 AM > To: bcampbell@dynamicsoft.com; hgs@cs.columbia.edu; mat@cisco.com; > dean.willis@softarmor.com; jdrosen@dynamicsoft.com; seancolson@yahoo.com > Cc: sip@ietf.org > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > > Hi, > > If #2 is in any way possible, let's pursue that. Reading the > bis-09 again, I can't help but wonder if the RFC2543 option of > still trying with UDP, if TCP has failed actually provides value > for messages over the UDP maximum datagram size of 65,535 bytes. > > If there was a SHOULD in trying UDP when TCP fails, but a SHOULD > NOT if size is over 65k, would the MESSAGE then be more well > behaved? I.e., enough to be able to relax the size limit to a > SHOULD strength in the message draft? > > Otherwise, I'm ready to live with #2, given that the text is > changed to align with bis-09 (MESSAGE talks about payload size, > whereas bis-09 talks about request size), and provide with a way > to send larger messages if there is a transport with congestion > control all the way to the destination. > > Cheers, > Aki > > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Saturday, May 18, 2002 12:17 AM > > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan > > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo) > > Cc: sip@ietf.org > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > > changes) > > > > > > OK, to summarize where I think we are, I have seen 4 > > proposals for dealing > > with the message size controversy: > > > > 1) Just live with it. IM's are not designed to carry large > > content anyway. > > Large content should be sent using some other mechanism, like > > in-session > > messages, content indirection, or something completely > > different like email. > > (bottom line: limit stays, with perhaps a clarification of > > the how the limit > > relates to the lowest hop MTU.) > > > > 2) Fix the SIP "feature" that creates this problem in the > > first place, i.e. > > the fact that a proxy can fail over to UDP even when a > > congestion controlled > > transport is requested. Jonathan suggested dissallowing this > > proxy behavior > > for large content messages. I'm not sure how hard that charge > > would be to > > get into 3261. > > > > 3) Adding something like a proxy-require:contestion-safe tag, > > so that the > > UAC can insist on end-to-end congestion control. This of > > course means that > > large content MESSAGE requests could not pass _any_ existing > > proxies--but > > that is no more limiting than saying you can't have large > > content messages > > at all. It at least gives us a way to relax the limit if we > > someday do get > > proxies that support the tag. > > > > 4) Relax the limit back to a should, but take no further > > action. I do not > > think that would pass IESG muster at this point. > > > > Personally I lean towards option 1. Pager model IMs are really _not_ > > intended to be a file transfer mechanism. Even without a > > strict limit, I > > think that large content messages (where content is > > physically carried in > > the message) are a misuse of the mechanism. We should work to > > specify an > > indirect-content mechanism, a session based mechanism, or > > both. But those > > are out of scope for pager model messaging, and should not become a > > dependency for this draft. Option 4 is pretty much out of the > > question. 2 & > > 3 may be doable, but are significant enough that we might > > need to re-cycle > > the last call. > > > > This really seems to be a full circle discussion, back to > > IMPP requirements > > days. I think our best bet is to narrow the scope to something > > solveable--that is short text (or otherwise small content) > > instant messages, > > solve that, then work on more sophisticated mechanisms for > > large content. > > > > Thoughts? > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Friday, May 17, 2002 2:51 PM > > > To: Michael Thomas > > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell'; > > > aki.niemi@nokia.com; sip@ietf.org > > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > > > changes) > > > > > > > > > Joking aside, this may not be such a bad idea: Send an IM > > with a message > > > reference, with email sent simultaneously. Generally, mail > > delivery is > > > measured in seconds (and for the long messages we're > > talking about here, > > > any processing delays would tend to be overwhelmed by > > transport delays). > > > Avoids all firewall, cable modem restriction and NAT issues and, to > > > boot, leverages off the likelihood that SIP and SMTP address are the > > > same. Plus, with IMAP, the client already gets to decide whether to > > > download attachments or not. > > > > > > Michael Thomas wrote: > > > > Dean Willis writes: > > > > > > > > > > One must ask -- at what point should one transition from IM to > > > > > email? > > > > > > > > Immediately? > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 10:13:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23281 for ; Mon, 20 May 2002 10:13:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07317 for sip-archive@odin.ietf.org; Mon, 20 May 2002 10:13:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06220; Mon, 20 May 2002 09:58:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06187 for ; Mon, 20 May 2002 09:58:42 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19260 for ; Mon, 20 May 2002 09:58:24 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AF30E2AA0154; Mon, 20 May 2002 09:50:40 -0400 Message-ID: <002d01c20005$77bff320$2300000a@acmepacket.com> From: "Bob Penfield" To: , , References: <3409234.1021473697235.JavaMail.root@127.0.0.1> Subject: Re: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt Date: Mon, 20 May 2002 09:51:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- >From: > >Bob, > >Many thanks for your comments. It is re-assuring to know that some IETF >experts have reviewed my draft. > >Please consider my comments below. I look forward to your further input, >if necessary. > >Regards, > >Duncan > >>2) Does this draft need an explicit Applicability Statement? >> >I think the draft could be applicable to various systems, >but obviously I am writing it primarily with a 3GPP >requirement in mind. Do you think I need to add an >explicit Applicability Statement? My IETF procedural >knowledge is (I'm afraid) limited. > Almost all of the other P-header proposals include one. I think due to the special circumstances required for this header, there needs to be one. I think it is just a matter of organizing all of the applicability information you already have into a formal Applicability Statement section. >>8) Section 7.2 is labeled "UAS behavior", but talks only about proxy >>behavior. I don't think there is any UAS behavior for this header. > >Does 'Proxy behaviour' cover the case of a B2BUA? > There is no mention of a B2BUA, and I don't see anything in this draft would turn a proxy into a B2BUA. In any event, you are talking about an intermediary (proxy, B2BUA, or whatever you call it) as opposed to an endpoint. It seems to me both 7.2 and 7.3 are talking about the same thing. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 10:43:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00727 for ; Mon, 20 May 2002 10:43:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08888 for sip-archive@odin.ietf.org; Mon, 20 May 2002 10:43:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07556; Mon, 20 May 2002 10:18:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07514 for ; Mon, 20 May 2002 10:18:29 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24711 for ; Mon, 20 May 2002 10:18:10 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4KEHIY11214 for ; Mon, 20 May 2002 17:17:18 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 17:18:26 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 17:18:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 20 May 2002 17:18:26 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED19@esebe013.NOE.Nokia.com> Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Thread-Index: AcIAAJVjwDo6S7OdTsaJp7pxQXr5jQAAeBmA To: , , , , , Cc: X-OriginalArrivalTime: 20 May 2002 14:18:26.0813 (UTC) FILETIME=[3543B2D0:01C20009] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07515 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Would you expect the MESSAGE draft to stall waiting for a 3261 fix? If you're talking about another draft-ietf-sip-rfc3261bis cycle, certainly not. But (a) since RFC 3261 hasn't actually been published yet, I imagine a "fix" could sneak in even in such a late stage. Of course not being that familiar with the IETF process this may be daydreaming, but I was under the impression that even though undesireable, changes may be considered even to documents that have been approved by the IESG. Another issue is, that (b) would a fix such as the one described by the post below actually properly fulfill the requirements for congestion control of MESSAGEs. If both (a) and (b) aren't going to be reality, I will shut my mouth for now, save my comments for whichever documents will update the protocol in the future, and be perfectly happy with #1, as long as the text is aligned with bis-09 on the relevant parts. Cheers, Aki > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Monday, May 20, 2002 4:13 AM > > To: bcampbell@dynamicsoft.com; hgs@cs.columbia.edu; mat@cisco.com; > > dean.willis@softarmor.com; jdrosen@dynamicsoft.com; > seancolson@yahoo.com > > Cc: sip@ietf.org > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > > changes) > > > > > > Hi, > > > > If #2 is in any way possible, let's pursue that. Reading the > > bis-09 again, I can't help but wonder if the RFC2543 option of > > still trying with UDP, if TCP has failed actually provides value > > for messages over the UDP maximum datagram size of 65,535 bytes. > > > > If there was a SHOULD in trying UDP when TCP fails, but a SHOULD > > NOT if size is over 65k, would the MESSAGE then be more well > > behaved? I.e., enough to be able to relax the size limit to a > > SHOULD strength in the message draft? > > > > Otherwise, I'm ready to live with #2, given that the text is > > changed to align with bis-09 (MESSAGE talks about payload size, > > whereas bis-09 talks about request size), and provide with a way > > to send larger messages if there is a transport with congestion > > control all the way to the destination. > > > > Cheers, > > Aki > > > > > > > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: Saturday, May 18, 2002 12:17 AM > > > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan > > > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo) > > > Cc: sip@ietf.org > > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] > Message draft > > > changes) > > > > > > > > > OK, to summarize where I think we are, I have seen 4 > > > proposals for dealing > > > with the message size controversy: > > > > > > 1) Just live with it. IM's are not designed to carry large > > > content anyway. > > > Large content should be sent using some other mechanism, like > > > in-session > > > messages, content indirection, or something completely > > > different like email. > > > (bottom line: limit stays, with perhaps a clarification of > > > the how the limit > > > relates to the lowest hop MTU.) > > > > > > 2) Fix the SIP "feature" that creates this problem in the > > > first place, i.e. > > > the fact that a proxy can fail over to UDP even when a > > > congestion controlled > > > transport is requested. Jonathan suggested dissallowing this > > > proxy behavior > > > for large content messages. I'm not sure how hard that charge > > > would be to > > > get into 3261. > > > > > > 3) Adding something like a proxy-require:contestion-safe tag, > > > so that the > > > UAC can insist on end-to-end congestion control. This of > > > course means that > > > large content MESSAGE requests could not pass _any_ existing > > > proxies--but > > > that is no more limiting than saying you can't have large > > > content messages > > > at all. It at least gives us a way to relax the limit if we > > > someday do get > > > proxies that support the tag. > > > > > > 4) Relax the limit back to a should, but take no further > > > action. I do not > > > think that would pass IESG muster at this point. > > > > > > Personally I lean towards option 1. Pager model IMs are > really _not_ > > > intended to be a file transfer mechanism. Even without a > > > strict limit, I > > > think that large content messages (where content is > > > physically carried in > > > the message) are a misuse of the mechanism. We should work to > > > specify an > > > indirect-content mechanism, a session based mechanism, or > > > both. But those > > > are out of scope for pager model messaging, and should > not become a > > > dependency for this draft. Option 4 is pretty much out of the > > > question. 2 & > > > 3 may be doable, but are significant enough that we might > > > need to re-cycle > > > the last call. > > > > > > This really seems to be a full circle discussion, back to > > > IMPP requirements > > > days. I think our best bet is to narrow the scope to something > > > solveable--that is short text (or otherwise small content) > > > instant messages, > > > solve that, then work on more sophisticated mechanisms for > > > large content. > > > > > > Thoughts? > > > > > > > -----Original Message----- > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > Sent: Friday, May 17, 2002 2:51 PM > > > > To: Michael Thomas > > > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; > 'Ben Campbell'; > > > > aki.niemi@nokia.com; sip@ietf.org > > > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] > Message draft > > > > changes) > > > > > > > > > > > > Joking aside, this may not be such a bad idea: Send an IM > > > with a message > > > > reference, with email sent simultaneously. Generally, mail > > > delivery is > > > > measured in seconds (and for the long messages we're > > > talking about here, > > > > any processing delays would tend to be overwhelmed by > > > transport delays). > > > > Avoids all firewall, cable modem restriction and NAT > issues and, to > > > > boot, leverages off the likelihood that SIP and SMTP > address are the > > > > same. Plus, with IMAP, the client already gets to > decide whether to > > > > download attachments or not. > > > > > > > > Michael Thomas wrote: > > > > > Dean Willis writes: > > > > > > > > > > > > One must ask -- at what point should one > transition from IM to > > > > > > email? > > > > > > > > > > Immediately? > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 11:37:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08160 for ; Mon, 20 May 2002 11:37:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14028 for sip-archive@odin.ietf.org; Mon, 20 May 2002 11:38:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11643; Mon, 20 May 2002 11:10:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11609 for ; Mon, 20 May 2002 11:10:47 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06308 for ; Mon, 20 May 2002 11:10:27 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4KFB5k15798 for ; Mon, 20 May 2002 18:11:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 May 2002 18:10:43 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 May 2002 18:10:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 20 May 2002 18:10:41 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE253@esebe013.NOE.Nokia.com> Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Thread-Index: AcH96D4X/9oors2jSqyKRzzY7RPyWgB8oXFgAA1gDRA= To: , , , , , , Cc: X-OriginalArrivalTime: 20 May 2002 15:10:43.0482 (UTC) FILETIME=[82DD67A0:01C20010] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA11610 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, > If #2 is in any way possible, let's pursue that. Reading the > bis-09 again, I can't help but wonder if the RFC2543 option > of still trying with UDP, if TCP has failed actually provides > value for messages over the UDP maximum datagram size of 65,535 bytes. > > If there was a SHOULD in trying UDP when TCP fails, but a > SHOULD NOT if size is over 65k, would the MESSAGE then be > more well behaved? I.e., enough to be able to relax the size > limit to a SHOULD strength in the message draft? > > Otherwise, I'm ready to live with #2, given that the text is ^^ Here, I meant to say of course that #1 is all right by me. Sorry for the mixup ;) > changed to align with bis-09 (MESSAGE talks about payload > size, whereas bis-09 talks about request size), and provide > with a way to send larger messages if there is a transport > with congestion control all the way to the destination. > > Cheers, > Aki > > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Saturday, May 18, 2002 12:17 AM > > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan > > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo) > > Cc: sip@ietf.org > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft > > changes) > > > > > > OK, to summarize where I think we are, I have seen 4 > > proposals for dealing > > with the message size controversy: > > > > 1) Just live with it. IM's are not designed to carry large > > content anyway. > > Large content should be sent using some other mechanism, like > > in-session > > messages, content indirection, or something completely > > different like email. > > (bottom line: limit stays, with perhaps a clarification of > > the how the limit > > relates to the lowest hop MTU.) > > > > 2) Fix the SIP "feature" that creates this problem in the > > first place, i.e. > > the fact that a proxy can fail over to UDP even when a > > congestion controlled > > transport is requested. Jonathan suggested dissallowing this > > proxy behavior > > for large content messages. I'm not sure how hard that charge > > would be to > > get into 3261. > > > > 3) Adding something like a proxy-require:contestion-safe tag, > > so that the > > UAC can insist on end-to-end congestion control. This of > > course means that > > large content MESSAGE requests could not pass _any_ existing > > proxies--but > > that is no more limiting than saying you can't have large > > content messages > > at all. It at least gives us a way to relax the limit if we > > someday do get > > proxies that support the tag. > > > > 4) Relax the limit back to a should, but take no further > > action. I do not > > think that would pass IESG muster at this point. > > > > Personally I lean towards option 1. Pager model IMs are really _not_ > > intended to be a file transfer mechanism. Even without a > > strict limit, I > > think that large content messages (where content is > > physically carried in > > the message) are a misuse of the mechanism. We should work to > > specify an > > indirect-content mechanism, a session based mechanism, or > > both. But those > > are out of scope for pager model messaging, and should not become a > > dependency for this draft. Option 4 is pretty much out of the > > question. 2 & > > 3 may be doable, but are significant enough that we might > > need to re-cycle > > the last call. > > > > This really seems to be a full circle discussion, back to > > IMPP requirements > > days. I think our best bet is to narrow the scope to something > > solveable--that is short text (or otherwise small content) > > instant messages, > > solve that, then work on more sophisticated mechanisms for > > large content. > > > > Thoughts? > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Friday, May 17, 2002 2:51 PM > > > To: Michael Thomas > > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben > Campbell'; > > > aki.niemi@nokia.com; sip@ietf.org > > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] > Message draft > > > changes) > > > > > > > > > Joking aside, this may not be such a bad idea: Send an IM > > with a message > > > reference, with email sent simultaneously. Generally, mail > > delivery is > > > measured in seconds (and for the long messages we're > > talking about here, > > > any processing delays would tend to be overwhelmed by > > transport delays). > > > Avoids all firewall, cable modem restriction and NAT > issues and, to > > > boot, leverages off the likelihood that SIP and SMTP > address are the > > > same. Plus, with IMAP, the client already gets to decide > whether to > > > download attachments or not. > > > > > > Michael Thomas wrote: > > > > Dean Willis writes: > > > > > > > > > > One must ask -- at what point should one transition > from IM to > > > > > email? > > > > > > > > Immediately? > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 11:48:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08871 for ; Mon, 20 May 2002 11:48:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14765 for sip-archive@odin.ietf.org; Mon, 20 May 2002 11:48:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13452; Mon, 20 May 2002 11:32:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13321 for ; Mon, 20 May 2002 11:32:19 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07703 for ; Mon, 20 May 2002 11:32:00 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4KFVUd06528; Mon, 20 May 2002 10:31:31 -0500 From: "Dean Willis" To: "'Rohan Mahy'" , "'Peterson, Jon'" , "'Peterson, Jon'" Cc: , Subject: RE: [Sip] Asserted-Identity: A P- Header? Date: Mon, 20 May 2002 10:31:27 -0500 Message-ID: <000001c20013$69491110$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <200205191517.AAE25164@imop.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Rohan Mahy > Sent: Sunday, May 19, 2002 10:21 AM > To: Peterson, Jon; Peterson, Jon > Cc: sip@ietf.org; sip@ietf.org > Subject: Re: [Sip] Asserted-Identity: A P- Header? > > > Hi, > > I believe a P- header is consistent with the applicability > scope built into the draft. > > I also feel that the cryptographic identity draft should use > the Asserted-Identity header (without the P- ). > I tend to disagree. It would appear that privacy requirements indicate that removal of the P-Hint header would be required by a proxy in the domain of trust before forwarding something out. This probably indicates a requirement for a Proxy-Require so that UA's "know" that this protection is provided by the proxy network. We can't do Proxy-Requires for a P-header as far as I know. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 13:21:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20598 for ; Mon, 20 May 2002 13:21:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22170 for sip-archive@odin.ietf.org; Mon, 20 May 2002 13:21:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20334; Mon, 20 May 2002 12:59:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20298 for ; Mon, 20 May 2002 12:59:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18283; Mon, 20 May 2002 12:59:31 -0400 (EDT) Message-Id: <200205201659.MAA18283@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 20 May 2002 12:59:30 -0400 Subject: [Sip] Last Call: The Refer Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o The Refer Method o The Session Inititation Protocol (SIP) o The Reason Header Field for the Session Initiation Protocol o Internet Media Types message/sipfrag o SIP Extension for Registering Non-Adjacent Contacts The IESG will also consider publication of Best Current Practices for Third Party Call Control in the Session Initiation Protocol as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 16:48:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09760 for ; Mon, 20 May 2002 16:48:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11177 for sip-archive@odin.ietf.org; Mon, 20 May 2002 16:48:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10264; Mon, 20 May 2002 16:35:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09267 for ; Mon, 20 May 2002 16:28:16 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08140; Mon, 20 May 2002 16:27:57 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4KKSFl19468; Mon, 20 May 2002 16:28:15 -0400 (EDT) Message-Id: <200205202028.g4KKSFl19468@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: iesg@ietf.org cc: sip@ietf.org In-reply-to: (Your message of "Mon, 20 May 2002 12:59:30 EDT.") <200205201659.MAA18283@ietf.org> Date: Mon, 20 May 2002 16:28:15 -0400 Subject: [Sip] Re: Last Call: The Refer Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > The IESG has received a request from the Session Initiation Protocol > Working Group to consider publication of the following Internet-Drafts > as Proposed Standards: > > o The Refer Method > > could you change the title to something like "The SIP Refer Method"? it's getting harder and harder to tell what an RFC is about from looking at the title. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 16:50:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09906 for ; Mon, 20 May 2002 16:50:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11328 for sip-archive@odin.ietf.org; Mon, 20 May 2002 16:50:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10542; Mon, 20 May 2002 16:38:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10502 for ; Mon, 20 May 2002 16:38:39 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08995 for ; Mon, 20 May 2002 16:38:20 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4KKbad08458; Mon, 20 May 2002 15:37:36 -0500 From: "Dean Willis" To: Cc: , , , Date: Mon, 20 May 2002 15:37:32 -0500 Message-ID: <005501c2003e$2b9f7cc0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to wrap up: http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-04.txt I think this version accomodates all changes requested to date. Anybody still have anything to add? Speak now . . . Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 17:16:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12044 for ; Mon, 20 May 2002 17:16:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14314 for sip-archive@odin.ietf.org; Mon, 20 May 2002 17:16:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11744; Mon, 20 May 2002 16:56:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11711 for ; Mon, 20 May 2002 16:56:50 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10381 for ; Mon, 20 May 2002 16:56:30 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g4KKukE10462; Mon, 20 May 2002 16:56:46 -0400 From: "Victor Paulsamy" To: "Jonathan Rosenberg" Cc: Date: Mon, 20 May 2002 13:55:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CE6B3C1.91A3507@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] RE: Was the Translate heade used? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Victor Paulsamy wrote: > > > > In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last > > but > > one reads, "... From this 200 OK, the STUN agent knows whether or not > > the > > Translate header was used or not." > > > > In the example shown, the STUN agent learnt the public IP by querying > > STUN > > sever and changed the outgoing REGISTER appropriately to reflect this. > > When > > this request reaches the proxy, it checks the sent-by value against the > > received address; they are same in this case (hence no received= param). > > No, they wouldn't be the same. The registration is sent over TCP, and > uses a different port than was used to communicate with the STUN server. > The example message corresponding to the text is: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5678 From: sip:user@provider.com To: sip:user@provider.com Call-ID: 88sdasdlasd0 Contact: sip:user@1.2.3.4:5678 Translate: sip:user@1.2.3.4:5678 CSeq: 88790 REGISTER Here, the request is indeed, sent using UDP. > > Say, the proxy supports SIP extensions for NAT. The proxy then rewrites > > the > > Translate header with sent-by value (in this case) which is same as the > > original value it carried in it. When returned in the 200 OK response, > > the > > STUN agent sees that, the Translate header has the same value that it > > put > > in, yet, the proxy supports the extension for NAT. > > Since the source port is different than the Contact port, the contact > would be rewritten and the client would know. > The source port (10) has been natted to 5678 (hence the port in Contact holds 5678). The original request sent by the client: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.1 From: sip:user@provider.com To: sip:user@provider.com Call-ID: 99asdasd98hnn Contact: sip:user@10.0.1.1:5060 CSeq: 88790 REGISTER The STUN agent finds out the address and port (as seen by the proxy) by querying the STUN server; rewrites the message to: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5678 From: sip:user@provider.com To: sip:user@provider.com Call-ID: 88sdasdlasd0 Contact: sip:user@1.2.3.4:5678 Translate: sip:user@1.2.3.4:5678 CSeq: 88790 REGISTER When sent out, the NAT rewrites the source address and port (to 1.2.3.4:5678), finally reached the proxy. At the proxy, it sees a Translate header hence, finds out a matching Contact header. The host value is replaced with the sent-by field from the Via (which in this case, is same as the value that's already present). The port number is replaced with the sent-by field (again, the same value that's carried in it). Though, the entire Contact header is rewritten, it results in the very same value it has already been carrying! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 17:22:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12560 for ; Mon, 20 May 2002 17:22:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14686 for sip-archive@odin.ietf.org; Mon, 20 May 2002 17:23:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13189; Mon, 20 May 2002 17:03:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13120 for ; Mon, 20 May 2002 17:03:00 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10951; Mon, 20 May 2002 17:02:40 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4KL2Pd08622; Mon, 20 May 2002 16:02:25 -0500 From: "Dean Willis" To: , Date: Mon, 20 May 2002 16:02:22 -0500 Message-ID: <007201c20041$a2e472b0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Final notes, slides, etc. from MaySIP/SIPPING interim meeting Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think I've posted all the notes and slides I received related to the interim meeting at: http://www.softarmor.com/sipwg/meets/interim-may-02/index.html Please let me know if we're still missing anything. Thanks, -- Your Humble Clerk-Typist Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 20 20:52:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25482 for ; Mon, 20 May 2002 20:52:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA00704 for sip-archive@odin.ietf.org; Mon, 20 May 2002 20:52:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28848; Mon, 20 May 2002 20:18:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28800 for ; Mon, 20 May 2002 20:18:15 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23868 for ; Mon, 20 May 2002 20:17:57 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4L0Hgd09820; Mon, 20 May 2002 19:17:42 -0500 From: "Dean Willis" To: Cc: "'Keith Moore'" Subject: RE: [Sip] Re: Last Call: The Refer Method to Proposed Standard Date: Mon, 20 May 2002 19:17:39 -0500 Message-ID: <009e01c2005c$eab532d0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <200205202028.g4KKSFl19468@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Keith asked: > could you change the title to something like > "The SIP Refer Method"? it's getting harder and harder to > tell what an RFC is about from looking at the title. This is a good suggestion. I've been trying to name things very explicitly, like: SIP Extension Header Field for Service Route Discovery in Private Networks And: SIP Extension for Registering Non-Adjacent Contacts which probably should have been: SIP Extension Header Field for Registering Non-Adjacent Contacts Perhaps we should put something on naming extension specs into the "Guidelines for Authors of SIP Extensions" document? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 03:37:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24799 for ; Tue, 21 May 2002 03:37:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28981 for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:37:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27809; Tue, 21 May 2002 03:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27785 for ; Tue, 21 May 2002 03:16:45 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23774 for ; Tue, 21 May 2002 03:16:28 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7HdYH017243; Tue, 21 May 2002 03:17:39 -0400 (EDT) Message-ID: <3CE9F436.A2ED116C@dynamicsoft.com> Date: Tue, 21 May 2002 03:16:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, "'Keith Moore'" Subject: Re: [Sip] Re: Last Call: The Refer Method to Proposed Standard References: <009e01c2005c$eab532d0$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'll add some words to the authors guidelines draft about this. Thanks, Jonathan R. Dean Willis wrote: > > Keith asked: > > could you change the title to something like > > "The SIP Refer Method"? it's getting harder and harder to > > tell what an RFC is about from looking at the title. > > This is a good suggestion. I've been trying to name things very > explicitly, like: > > SIP Extension Header Field for Service Route Discovery in Private > Networks > > And: > > SIP Extension for Registering Non-Adjacent Contacts > > which probably should have been: > > SIP Extension Header Field for Registering Non-Adjacent Contacts > > Perhaps we should put something on naming extension specs into the > "Guidelines for Authors of SIP Extensions" document? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 03:47:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25415 for ; Tue, 21 May 2002 03:47:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29531 for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:47:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28147; Tue, 21 May 2002 03:29:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28116 for ; Tue, 21 May 2002 03:29:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24398 for ; Tue, 21 May 2002 03:29:09 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7TrYH017259; Tue, 21 May 2002 03:29:53 -0400 (EDT) Message-ID: <3CE9F714.59EC6FEF@dynamicsoft.com> Date: Tue, 21 May 2002 03:28:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: bcampbell@dynamicsoft.com, hgs@cs.columbia.edu, mat@cisco.com, dean.willis@softarmor.com, seancolson@yahoo.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED11@esebe013.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > Hi, > > If #2 is in any way possible, let's pursue that. Reading the bis-09 > again, I can't help but wonder if the RFC2543 option of still trying > with UDP, if TCP has failed actually provides value for messages over > the UDP maximum datagram size of 65,535 bytes. Well, to be honest, there are other reasons why sending such large content (over 64k) in SIP directly is a bad idea in any case, TCP or no TCP. I can't tell you how many times I've flamed people for sending 10M email attachments to mailing lists; I always prefer a URL so that I can fetch it at my convenience. MMS in the GSM world works the same; everything is via indirection. My concern is actually with the arbitraryness of the 1300 number; I fear there will be cases when an indirection might even exceed this limit (in the case of S/MIME with a cert chain). Last thing we want to do is discourage S/MIME usage... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 03:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25483 for ; Tue, 21 May 2002 03:48:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29552 for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:48:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28741; Tue, 21 May 2002 03:33:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28710 for ; Tue, 21 May 2002 03:33:56 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24607 for ; Tue, 21 May 2002 03:33:38 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7YoYH017262; Tue, 21 May 2002 03:34:50 -0400 (EDT) Message-ID: <3CE9F83E.FA53CE9F@dynamicsoft.com> Date: Tue, 21 May 2002 03:33:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Sean Olson , Ben Campbell , aki.niemi@nokia.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: <15589.10039.127865.917811@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Jonathan Rosenberg writes: > > > > > > Sean Olson wrote: > > > > > > The consent piece is an interesting adjunct to the > > > content indirection requirements. I already allude > > > to the fact that you need to be able to negotiate > > > support / demand for such a mechanism. > > > > > > Do we need to express explicit policy about when > > > content indirection should be used? > > > > What I was saying is that the page mode spec DEFINES that policy > > explicitly - anything over 1300 bytes means indirection. > > Jonathan, > > While I like the spirit of your proposal, I wonder > if it's going to run into operational problems. > Client's don't typically run web servers > (especially on some well known OSen). Also: some > cable MSO's filter port 80 to kill home web > servers. That means that they'd have to find and > upload that data to a willing web server. For > long-lived data that's not unreasonable, but for > short term/transient data that seems like a pretty > big burden. Well, in the wireless world, there is an argument to be made that almost all large data won't be stored on the phone in any case, but rather available on a server. Clearly there are exceptions (those new phones with built in cameras, i.e., the Danger device), and clearly this isn't true for PCs on the wired Internet. However, if we had a procedure that allowed an automata on the phone to upload content to a server, specify a lifetime, and set permissions on who can fetch the content, I see no drawbacks to the approach of uploading it to such a server. These kinds of servers are already features of existing wired IM solutions, which use them mostly for file transfer right now. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 03:58:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26021 for ; Tue, 21 May 2002 03:58:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29860 for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:59:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28862; Tue, 21 May 2002 03:36:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28831 for ; Tue, 21 May 2002 03:36:10 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24707 for ; Tue, 21 May 2002 03:35:53 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7b6YH017265; Tue, 21 May 2002 03:37:07 -0400 (EDT) Message-ID: <3CE9F8C6.68147C6C@dynamicsoft.com> Date: Tue, 21 May 2002 03:35:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org Subject: Re: [Sip] Message draft changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > Careful here! Path and hop mean different things to folks at layer 3 > and > > at the app layer. The Path MTU refers to the smallest MTU along each > > router hop from the IP source to the IP destination. For SIP, that is > > just a single "hop" from the UAC to a proxy, say. Each SIP "hop" > > (between UAC and proxy, or proxy to proxy) will have a different path > > MTU, and could conceivably make a different transport decision based > on > > that. > > Ah, thanks for the terminology lession--I mean to say, that it is very > unlikely that the MTU will know the smallest path MTU for every SIP > device > end-to-end. Actually, I think you mean to say that it is very unlikely that the UA will know the path MTU for reaching every sip device. I agree, but its not the case that it needs to know. In most usages, the UA will talk to an outbound proxy, and it will know the path MTU to the outbound proxy. Its determination about whether to use UDP or TCP would then be based on this specific path MTU. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 04:31:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27759 for ; Tue, 21 May 2002 04:31:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02576 for sip-archive@odin.ietf.org; Tue, 21 May 2002 04:31:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01305; Tue, 21 May 2002 04:15:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01278 for ; Tue, 21 May 2002 04:15:46 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26999 for ; Tue, 21 May 2002 04:15:27 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4L8G5k03537 for ; Tue, 21 May 2002 11:16:05 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 May 2002 11:15:41 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 21 May 2002 11:15:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Tue, 21 May 2002 11:15:40 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED1F@esebe013.NOE.Nokia.com> Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Thread-Index: AcIAmSq6HfW4N/E9RYSf0tO7101DowABLWNw To: Cc: , , , , , X-OriginalArrivalTime: 21 May 2002 08:15:41.0089 (UTC) FILETIME=[B24B8910:01C2009F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA01279 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, > > If #2 is in any way possible, let's pursue that. Reading the bis-09 > > again, I can't help but wonder if the RFC2543 option of still trying > > with UDP, if TCP has failed actually provides value for > messages over > > the UDP maximum datagram size of 65,535 bytes. > > Well, to be honest, there are other reasons why sending such large > content (over 64k) in SIP directly is a bad idea in any case, > TCP or no > TCP. I can't tell you how many times I've flamed people for > sending 10M > email attachments to mailing lists; I always prefer a URL so > that I can > fetch it at my convenience. I totally agree. However, I know of email lists / systems, which have local policy governing the sizes of attachments. I feel such optionality is currently missing from the MESSAGE draft. For example, the default content-indirection policy seems to be that the sender always performs it. How about if this was part of the recipient's service offering? Sort of like a safeguard for UAs behind the low-capacity links. > MMS in the GSM world works the same; everything is via indirection. But only on the "last hop", i.e., the core MMS infra still has direct content all the way. I actually think this model should be available for the SIP MESSAGE indirection as well. > My concern is actually with the arbitraryness of the 1300 > number; I fear > there will be cases when an indirection might even exceed > this limit (in > the case of S/MIME with a cert chain). Last thing we want to do is > discourage S/MIME usage... Yes, and in fact concerning this, there is an inconsistency with the SIP spec, which talks about 1300 bytes for the *whole* request. If we abide by that limit, with those lengthy Subject fields etc., there is even less space for the indirection object in the payload. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 04:42:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28289 for ; Tue, 21 May 2002 04:42:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02851 for sip-archive@odin.ietf.org; Tue, 21 May 2002 04:42:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02092; Tue, 21 May 2002 04:28:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02061 for ; Tue, 21 May 2002 04:28:48 -0400 (EDT) Received: from webmail22.rediffmail.com (webmail22.rediffmail.com [203.199.83.32] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27608 for ; Tue, 21 May 2002 04:28:28 -0400 (EDT) Received: (qmail 393 invoked by uid 510); 21 May 2002 08:27:26 -0000 Date: 21 May 2002 08:27:26 -0000 Message-ID: <20020521082726.392.qmail@webmail22.rediffmail.com> Received: from unknown (203.197.251.7) by rediffmail.com via HTTP; 21 May 2002 08:27:26 -0000 MIME-Version: 1.0 From: "Ashhar Farhan" Reply-To: "Ashhar Farhan" To: "Jonathan Rosenberg" Cc: bcampbell@dynamicsoft.com, hgs@cs.columbia.edu, mat@cisco.com, dean.willis@softarmor.com, seancolson@yahoo.com, sip@ietf.org, aki.niemi@nokia.com Subject: Re: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Content-type: text/plain; format=flowed Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org if the messages are no longer just text, then there is a case for negotiating content-type. the UA may or may not be able to display html for instance and might want a short text description instead. in which case: (1) do we have to return 'Method Not supported' in the response? (2) do we also recommend an alternative? - farhan _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 06:30:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02823 for ; Tue, 21 May 2002 06:30:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08772 for sip-archive@odin.ietf.org; Tue, 21 May 2002 06:30:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07704; Tue, 21 May 2002 06:02:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07677 for ; Tue, 21 May 2002 06:02:11 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01711 for ; Tue, 21 May 2002 06:01:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4LA27s7008882; Tue, 21 May 2002 12:02:07 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4LA279q010580; Tue, 21 May 2002 13:02:07 +0300 (EET DST) Message-ID: <3CEA1B1E.E4E20C18@lmf.ericsson.se> Date: Tue, 21 May 2002 13:02:06 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip CC: Allison Mankin , "Jari Arkko (LMF)" , "Vesa Torvinen (LMF)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Reviewers for the sec-agree draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello folks, we need SIP people willing to have a look at the new version (01) of the sec-agree draft (released one week and a half ago). http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-sec-agree-01.txt As you proabbly know, the previous version (00) had some problems that were discovered during the iterim meeting in Vegas. The discovery of problems (such as a broken SIP syntax) at that point of time (after the WGLC had finished) indicates that nobody in the SIP WG bothered to read the document. I am not saying that this draft is so interesting that everyone will enjoy reading it, but we would need at least a couple of reviewers that are familiar with SIP and have the energy to review the document. We cannot let the SIP WG send documents to the IESG that have major flaws! Here you have a brief summary of the changes we introduced to the new version of the draft (01): The syntax has been fixed. Now it is allowed to have different security mechanisms listed (separated by commas or in different lines). The previous draft used commas to separate security mechanism tokens. That made the header field non-SIP compliant. The scope has been narrowed down. Before, the draft tried to solve every security negotiation problem that could be found in a SIP network. Now the draft only tries to resolve the security negotiation between a host and its next SIP hop (e.g., UA and the outbound proxy). The negotiation works as follows. The UA sends a SIP message (typically OPTIONS) to its outbound proxy listing its security capabilities (e.g., TLS and IPSec). The outbound proxy sends a response with its own capabilities (it is important that the list in the server is static). With this information, client and server initiate the security mechanims (e.g., initiate a TLS conection). When the client sends another SIP message to the outbound proxy, this time using the TLS connection, it includes a header field that contains the list obtained previously from the server. This way, the server can check whether a MitM changes the list in order to perform a bid-down attack. Of course, this security negotiation mechanism requires that all the security mechanisms advertised provide integrity protection, at least. Thank you, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 07:55:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05810 for ; Tue, 21 May 2002 07:55:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13250 for sip-archive@odin.ietf.org; Tue, 21 May 2002 07:56:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12046; Tue, 21 May 2002 07:31:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12017 for ; Tue, 21 May 2002 07:31:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05072; Tue, 21 May 2002 07:31:32 -0400 (EDT) Message-Id: <200205211131.HAA05072@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 May 2002 07:31:31 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : HTTP Digest Authentication Using AKA Author(s) : A. Niemi, J. Arkko, V. Torvinen Filename : draft-ietf-sip-digest-aka-03.txt Pages : 18 Date : 20-May-02 The Hypertext Transfer Protocol (HTTP) Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The Authentication and Key Agreement (AKA) mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. This memo specifies an AKA based one-time password generation mechanism for HTTP Digest access authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-03.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-ietf-sip-digest-aka-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-digest-aka-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-digest-aka-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-digest-aka-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143415.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 07:58:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05981 for ; Tue, 21 May 2002 07:58:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13299 for sip-archive@odin.ietf.org; Tue, 21 May 2002 07:58:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11861; Tue, 21 May 2002 07:31:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11819 for ; Tue, 21 May 2002 07:31:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04885; Tue, 21 May 2002 07:30:47 -0400 (EDT) Message-Id: <200205211130.HAA04885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 May 2002 07:30:47 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-associated-uri-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol extension for Associated Uniform Resource Identifiers Author(s) : M. Garcia Filename : draft-garcia-sip-associated-uri-01.txt Pages : 6 Date : 20-May-02 This memo describes a private extension to SIP [1] that allows a registrar to return a set of Associated URIs to a UAC. We define the P-Associated-URI header, used in the 200 OK response to a REGISTER request or 200-class response to a SUBSCRIBE. The P-Associated-URI header transports the set of Associated URIs to the SIP URI that has been registered or subscribed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-associated-uri-01.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-garcia-sip-associated-uri-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-associated-uri-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-associated-uri-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-associated-uri-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143242.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 07:58:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05997 for ; Tue, 21 May 2002 07:58:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13313 for sip-archive@odin.ietf.org; Tue, 21 May 2002 07:58:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11908; Tue, 21 May 2002 07:31:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11856 for ; Tue, 21 May 2002 07:31:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04901; Tue, 21 May 2002 07:30:52 -0400 (EDT) Message-Id: <200205211130.HAA04901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 May 2002 07:30:51 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-visited-network-id-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol extension for Visited Network Identifier Author(s) : M. Garcia Filename : draft-garcia-sip-visited-network-id-01.txt Pages : 7 Date : 20-May-02 This memo describes a private extension to SIP in the form of a P-Visited-Network-ID header. The contents of the header identify each of the visited networks the message traversed en-route to the home network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-visited-network-id-01.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-garcia-sip-visited-network-id-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-visited-network-id-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-visited-network-id-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-visited-network-id-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143252.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 08:00:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06115 for ; Tue, 21 May 2002 08:00:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13686 for sip-archive@odin.ietf.org; Tue, 21 May 2002 08:00:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11797; Tue, 21 May 2002 07:31:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11766 for ; Tue, 21 May 2002 07:31:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04864; Tue, 21 May 2002 07:30:42 -0400 (EDT) Message-Id: <200205211130.HAA04864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 May 2002 07:30:42 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-called-party-id-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol extension for Called Party Identity Author(s) : M. Garcia Filename : draft-garcia-sip-called-party-id-01.txt Pages : 8 Date : 20-May-02 This memo describes a private extension to SIP in the form of a P-Called-Party-ID header. A proxy inserts this header typically in an INVITE, en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which ID out of several IDs the invitation was sent to (for example, the user may be using simultaneously a personal and a business SIP URI to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the ID used to receive the invitation to the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-called-party-id-01.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-garcia-sip-called-party-id-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-called-party-id-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-called-party-id-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-called-party-id-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143232.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 08:39:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07544 for ; Tue, 21 May 2002 08:39:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15427 for sip-archive@odin.ietf.org; Tue, 21 May 2002 08:39:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14277; Tue, 21 May 2002 08:14:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14246 for ; Tue, 21 May 2002 08:14:21 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06514 for ; Tue, 21 May 2002 08:14:03 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA03670; Tue, 21 May 2002 08:14:18 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-39-64.mad.east.verizon.net [138.89.39.64]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LCEF2i005157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 May 2002 08:14:16 -0400 (EDT) Message-ID: <3CEA3A4D.8070904@cs.columbia.edu> Date: Tue, 21 May 2002 08:15:09 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org, "'Keith Moore'" Subject: Re: [Sip] Re: Last Call: The Refer Method to Proposed Standard References: <009e01c2005c$eab532d0$1d036e3f@TXDWILLIS2> <3CE9F436.A2ED116C@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We should probably be consistent. We're seeing a lot of drafts titled something like "Private Session Initiation Protocol feature to do foo", others "SIP extension to do bar". It would be nice to be able to easily grep the RFC list and come up with all SIP-related drafts. Jonathan Rosenberg wrote: > I'll add some words to the authors guidelines draft about this. > > Thanks, > Jonathan R. > > Dean Willis wrote: > >>Keith asked: >> >>>could you change the title to something like >>>"The SIP Refer Method"? it's getting harder and harder to >>>tell what an RFC is about from looking at the title. >> >>This is a good suggestion. I've been trying to name things very >>explicitly, like: >> >> SIP Extension Header Field for Service Route Discovery in Private >>Networks >> >>And: >> >> SIP Extension for Registering Non-Adjacent Contacts >> >>which probably should have been: >> >> SIP Extension Header Field for Registering Non-Adjacent Contacts >> >>Perhaps we should put something on naming extension specs into the >>"Guidelines for Authors of SIP Extensions" document? >> >>-- >>Dean >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 10:07:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11047 for ; Tue, 21 May 2002 10:07:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19884 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:07:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18513; Tue, 21 May 2002 09:40:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18484 for ; Tue, 21 May 2002 09:40:45 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10153 for ; Tue, 21 May 2002 09:40:26 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4LDYpX59091; Tue, 21 May 2002 08:34:51 -0500 (CDT) From: "Ben Campbell" To: "Jonathan Rosenberg" Cc: , , Subject: RE: [Sip] Message draft changes Date: Tue, 21 May 2002 08:34:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3CE9F8C6.68147C6C@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] [snip] > Actually, I think you mean to say that it is very unlikely that the UA > will know the path MTU for reaching every sip device. I agree, but its > not the case that it needs to know. In most usages, the UA will talk to > an outbound proxy, and it will know the path MTU to the outbound proxy. > Its determination about whether to use UDP or TCP would then be based on > this specific path MTU. > Yes, that is what I mean. Why does only the first hop matter for the UDP/TCP decision? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 10:27:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11813 for ; Tue, 21 May 2002 10:27:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20936 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:27:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19972; Tue, 21 May 2002 10:09:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19926 for ; Tue, 21 May 2002 10:09:21 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11127 for ; Tue, 21 May 2002 10:09:01 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4LE3RX61346; Tue, 21 May 2002 09:03:27 -0500 (CDT) From: "Ben Campbell" To: "Ashhar Farhan" , "Jonathan Rosenberg" Cc: , , , , , Subject: RE: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Tue, 21 May 2002 09:03:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <20020521082726.392.qmail@webmail22.rediffmail.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ashhar Farhan [mailto:afarhan@rediffmail.com] > Sent: Tuesday, May 21, 2002 3:27 AM > To: Jonathan Rosenberg > Cc: bcampbell@dynamicsoft.com; hgs@cs.columbia.edu; mat@cisco.com; > dean.willis@softarmor.com; seancolson@yahoo.com; sip@ietf.org; > aki.niemi@nokia.com > Subject: Re: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft > changes) > > > if the messages are no longer just text, then there is a case for > negotiating content-type. the UA may or may not be able to display > html for instance and might want a short text description instead. > in which case: > (1) do we have to return 'Method Not supported' in the response? > (2) do we also recommend an alternative? > - farhan SIP already has a mechanism for dealing with this situation. Do you think that MESSAGE requires more here? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 10:28:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11876 for ; Tue, 21 May 2002 10:28:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20993 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:28:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19502; Tue, 21 May 2002 10:01:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19467 for ; Tue, 21 May 2002 10:01:12 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10780 for ; Tue, 21 May 2002 10:00:53 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 May 2002 14:01:34 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Reviewers for the sec-agree draft Date: Tue, 21 May 2002 15:01:11 +0100 Message-ID: <45730E094814E44488F789C1CDED27AEC552F4@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Reviewers for the sec-agree draft Thread-Index: AcIAsRCSYZA7u0SdQbm/8OSUMLuMrQAHedKQ From: "James Undery" To: "Gonzalo Camarillo" , "sip" Cc: "Jari Arkko (LMF)" , "Vesa Torvinen (LMF)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19468 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I'll have to admit myself of being guilty of not reading drafts recently. But I'd note digest-integrity needs to be dropped as it protects the body of messages only. If it can't be dropped a lpidf like extension would be required (http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to place your headers in the body. James > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 21 May 2002 11:02 > To: sip > Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF) > Subject: [Sip] Reviewers for the sec-agree draft > > > Hello folks, > > we need SIP people willing to have a look at the new version > (01) of the > sec-agree draft (released one week and a half ago). > > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se > c-agree-01.txt > > As you proabbly know, the previous version (00) had some problems that > were discovered during the iterim meeting in Vegas. The discovery of > problems (such as a broken SIP syntax) at that point of time > (after the > WGLC had finished) indicates that nobody in the SIP WG > bothered to read > the document. > > I am not saying that this draft is so interesting that everyone will > enjoy reading it, but we would need at least a couple of > reviewers that > are familiar with SIP and have the energy to review the document. We > cannot let the SIP WG send documents to the IESG that have > major flaws! > > > Here you have a brief summary of the changes we introduced to the new > version of the draft (01): > > The syntax has been fixed. Now it is allowed to have > different security > mechanisms listed (separated by commas or in different lines). The > previous draft used commas to separate security mechanism tokens. That > made the header field non-SIP compliant. > > The scope has been narrowed down. Before, the draft tried to > solve every > security negotiation problem that could be found in a SIP network. Now > the draft only tries to resolve the security negotiation > between a host > and its next SIP hop (e.g., UA and the outbound proxy). > > > The negotiation works as follows. The UA sends a SIP message > (typically > OPTIONS) to its outbound proxy listing its security > capabilities (e.g., > TLS and IPSec). The outbound proxy sends a response with its own > capabilities (it is important that the list in the server is static). > With this information, client and server initiate the > security mechanims > (e.g., initiate a TLS conection). > > When the client sends another SIP message to the outbound proxy, this > time using the TLS connection, it includes a header field > that contains > the list obtained previously from the server. This way, the server can > check whether a MitM changes the list in order to perform a bid-down > attack. > > Of course, this security negotiation mechanism requires that all the > security mechanisms advertised provide integrity protection, at least. > > Thank you, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 10:44:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12584 for ; Tue, 21 May 2002 10:44:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22249 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:44:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20549; Tue, 21 May 2002 10:22:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20521 for ; Tue, 21 May 2002 10:22:03 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11543 for ; Tue, 21 May 2002 10:21:44 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LELWa16441; Tue, 21 May 2002 09:21:33 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 09:21:35 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A632A1@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'James Undery'" , "'Gonzalo Camarillo'" , "'sip'" Cc: "'Jari Arkko (LMF)'" , "'Vesa Torvinen (LMF)'" Subject: RE: [Sip] Reviewers for the sec-agree draft Date: Tue, 21 May 2002 09:21:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200D2.CAA6DAE0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C200D2.CAA6DAE0 Content-Type: text/plain; charset="iso-8859-1" James, The use of 'sipfrag' (draft-sparks-sip-mimetypes-03 or whatever is the latest version) is assumed. But, I agree that it should be explicitly stated for clarity. Sanjoy > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, May 21, 2002 9:01 AM > To: Gonzalo Camarillo; sip > Cc: Jari Arkko (LMF); Vesa Torvinen (LMF) > Subject: RE: [Sip] Reviewers for the sec-agree draft > > > Hi, > > I'll have to admit myself of being guilty of not reading drafts > recently. But I'd note digest-integrity needs to be dropped as it > protects the body of messages only. If it can't be dropped a > lpidf like > extension would be required > (http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to > place your headers in the body. > > James > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 21 May 2002 11:02 > > To: sip > > Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF) > > Subject: [Sip] Reviewers for the sec-agree draft > > > > > > Hello folks, > > > > we need SIP people willing to have a look at the new version > > (01) of the > > sec-agree draft (released one week and a half ago). > > > > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se > > c-agree-01.txt > > > > As you proabbly know, the previous version (00) had some > problems that > > were discovered during the iterim meeting in Vegas. The discovery of > > problems (such as a broken SIP syntax) at that point of time > > (after the > > WGLC had finished) indicates that nobody in the SIP WG > > bothered to read > > the document. > > > > I am not saying that this draft is so interesting that everyone will > > enjoy reading it, but we would need at least a couple of > > reviewers that > > are familiar with SIP and have the energy to review the document. We > > cannot let the SIP WG send documents to the IESG that have > > major flaws! > > > > > > Here you have a brief summary of the changes we introduced > to the new > > version of the draft (01): > > > > The syntax has been fixed. Now it is allowed to have > > different security > > mechanisms listed (separated by commas or in different lines). The > > previous draft used commas to separate security mechanism > tokens. That > > made the header field non-SIP compliant. > > > > The scope has been narrowed down. Before, the draft tried to > > solve every > > security negotiation problem that could be found in a SIP > network. Now > > the draft only tries to resolve the security negotiation > > between a host > > and its next SIP hop (e.g., UA and the outbound proxy). > > > > > > The negotiation works as follows. The UA sends a SIP message > > (typically > > OPTIONS) to its outbound proxy listing its security > > capabilities (e.g., > > TLS and IPSec). The outbound proxy sends a response with its own > > capabilities (it is important that the list in the server > is static). > > With this information, client and server initiate the > > security mechanims > > (e.g., initiate a TLS conection). > > > > When the client sends another SIP message to the outbound > proxy, this > > time using the TLS connection, it includes a header field > > that contains > > the list obtained previously from the server. This way, the > server can > > check whether a MitM changes the list in order to perform a bid-down > > attack. > > > > Of course, this security negotiation mechanism requires that all the > > security mechanisms advertised provide integrity > protection, at least. > > > > Thank you, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C200D2.CAA6DAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Reviewers for the sec-agree draft

James,

The use of 'sipfrag' (draft-sparks-sip-mimetypes-03 = or whatever is the latest version) is assumed. But, I agree that it = should be explicitly stated for clarity.

Sanjoy

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, May 21, 2002 9:01 AM
> To: Gonzalo Camarillo; sip
> Cc: Jari Arkko (LMF); Vesa Torvinen = (LMF)
> Subject: RE: [Sip] Reviewers for the sec-agree = draft
>
>
> Hi,
>
> I'll have to admit myself of being guilty of = not reading drafts
> recently. But I'd note digest-integrity needs = to be dropped as it
> protects the body of messages only. If it can't = be dropped a
> lpidf like
> extension would be required
> (http://www.jdrosen.net/papers/draft-rosenberg-impp-lpi= df-00.txt) to
> place your headers in the body.
>
> James
>
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > Sent: 21 May 2002 11:02
> > To: sip
> > Cc: Allison Mankin; Jari Arkko (LMF); Vesa = Torvinen (LMF)
> > Subject: [Sip] Reviewers for the sec-agree = draft
> >
> >
> > Hello folks,
> >
> > we need SIP people willing to have a look = at the new version
> > (01) of the
> > sec-agree draft (released one week and a = half ago).
> >
> > http://standards.ericsson.net/gonzalo/papers/draft-iet= f-sip-se
> > c-agree-01.txt
> >
> > As you proabbly know, the previous version = (00) had some
> problems that
> > were discovered during the iterim meeting = in Vegas. The discovery of
> > problems (such as a broken SIP syntax) at = that point of time
> > (after the
> > WGLC had finished) indicates that nobody = in the SIP WG
> > bothered to read
> > the document.
> >
> > I am not saying that this draft is so = interesting that everyone will
> > enjoy reading it, but we would need at = least a couple of
> > reviewers that
> > are familiar with SIP and have the energy = to review the document. We
> > cannot let the SIP WG send documents to = the IESG that have
> > major flaws!
> >
> >
> > Here you have a brief summary of the = changes we introduced
> to the new
> > version of the draft (01):
> >
> > The syntax has been fixed. Now it is = allowed to have
> > different security
> > mechanisms listed (separated by commas or = in different lines). The
> > previous draft used commas to separate = security mechanism
> tokens. That
> > made the header field non-SIP = compliant.
> >
> > The scope has been narrowed down. Before, = the draft tried to
> > solve every
> > security negotiation problem that could be = found in a SIP
> network. Now
> > the draft only tries to resolve the = security negotiation
> > between a host
> > and its next SIP hop (e.g., UA and the = outbound proxy).
> >
> >
> > The negotiation works as follows. The UA = sends a SIP message
> > (typically
> > OPTIONS) to its outbound proxy listing its = security
> > capabilities (e.g.,
> > TLS and IPSec). The outbound proxy sends a = response with its own
> > capabilities (it is important that the = list in the server
> is static).
> > With this information, client and server = initiate the
> > security mechanims
> > (e.g., initiate a TLS conection).
> >
> > When the client sends another SIP message = to the outbound
> proxy, this
> > time using the TLS connection, it includes = a header field
> > that contains
> > the list obtained previously from the = server. This way, the
> server can
> > check whether a MitM changes the list in = order to perform a bid-down
> > attack.
> >
> > Of course, this security negotiation = mechanism requires that all the
> > security mechanisms advertised provide = integrity
> protection, at least.
> >
> > Thank you,
> >
> > Gonzalo
> > --
> > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > = Finland           = ;        http://www.hut.fi/~gonzalo
> >
> > = _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the = core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for = questions on current sip
> > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C200D2.CAA6DAE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 10:49:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12852 for ; Tue, 21 May 2002 10:49:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22575 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:49:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20854; Tue, 21 May 2002 10:26:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20772 for ; Tue, 21 May 2002 10:26:09 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11752 for ; Tue, 21 May 2002 10:25:49 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4LEQ7s7004052 for ; Tue, 21 May 2002 16:26:07 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 21 16:26:01 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB43Z69>; Tue, 21 May 2002 16:26:01 +0200 Message-ID: <29F33B0CF787D51195FC0002A56B3DC10101B84F@efijont103> From: "Vesa Torvinen (LMF)" To: "'James Undery'" Cc: "Jari Arkko (LMF)" , "Gonzalo Camarillo Gonzalez (LMF)" , sip Subject: RE: [Sip] Reviewers for the sec-agree draft Date: Tue, 21 May 2002 16:25:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Text in section 3.5 is supposed to address this issue: "If digest-integrity is chosen, the 494 (Security Agreement Required) response will contain an HTTP authentication challenge. The client MUST use the qos parameter possibly together with some variant of MIME tunneling so that the Security-Verify header field in the request is integrity protected in the MIME body. Note that digest alone would not fulfill the minimum security requirements of this specification." We didn't want to specify how to use 'digest-integrity' exactly because this draft is related to negotiation - not individual mechanisms. Neither did we want to drop the mechanism from the list because someone can implement it using existing standards (e.g. MIME, B2BUA, etc). Vesa -----Original Message----- From: James Undery [mailto:jundery@ubiquity.net] Sent: 21. toukokuuta 2002 17:01 To: Gonzalo Camarillo; sip Cc: Jari Arkko (LMF); Vesa Torvinen (LMF) Subject: RE: [Sip] Reviewers for the sec-agree draft Hi, I'll have to admit myself of being guilty of not reading drafts recently. But I'd note digest-integrity needs to be dropped as it protects the body of messages only. If it can't be dropped a lpidf like extension would be required (http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to place your headers in the body. James > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 21 May 2002 11:02 > To: sip > Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF) > Subject: [Sip] Reviewers for the sec-agree draft > > > Hello folks, > > we need SIP people willing to have a look at the new version > (01) of the > sec-agree draft (released one week and a half ago). > > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se > c-agree-01.txt > > As you proabbly know, the previous version (00) had some problems that > were discovered during the iterim meeting in Vegas. The discovery of > problems (such as a broken SIP syntax) at that point of time > (after the > WGLC had finished) indicates that nobody in the SIP WG > bothered to read > the document. > > I am not saying that this draft is so interesting that everyone will > enjoy reading it, but we would need at least a couple of > reviewers that > are familiar with SIP and have the energy to review the document. We > cannot let the SIP WG send documents to the IESG that have > major flaws! > > > Here you have a brief summary of the changes we introduced to the new > version of the draft (01): > > The syntax has been fixed. Now it is allowed to have > different security > mechanisms listed (separated by commas or in different lines). The > previous draft used commas to separate security mechanism tokens. That > made the header field non-SIP compliant. > > The scope has been narrowed down. Before, the draft tried to > solve every > security negotiation problem that could be found in a SIP network. Now > the draft only tries to resolve the security negotiation > between a host > and its next SIP hop (e.g., UA and the outbound proxy). > > > The negotiation works as follows. The UA sends a SIP message > (typically > OPTIONS) to its outbound proxy listing its security > capabilities (e.g., > TLS and IPSec). The outbound proxy sends a response with its own > capabilities (it is important that the list in the server is static). > With this information, client and server initiate the > security mechanims > (e.g., initiate a TLS conection). > > When the client sends another SIP message to the outbound proxy, this > time using the TLS connection, it includes a header field > that contains > the list obtained previously from the server. This way, the server can > check whether a MitM changes the list in order to perform a bid-down > attack. > > Of course, this security negotiation mechanism requires that all the > security mechanisms advertised provide integrity protection, at least. > > Thank you, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 10:50:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12916 for ; Tue, 21 May 2002 10:50:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22667 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:50:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21871; Tue, 21 May 2002 10:38:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21843 for ; Tue, 21 May 2002 10:38:50 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12377 for ; Tue, 21 May 2002 10:38:31 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 May 2002 14:39:12 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Reviewers for the sec-agree draft Date: Tue, 21 May 2002 15:41:22 +0100 Message-ID: <45730E094814E44488F789C1CDED27AEC552F5@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Reviewers for the sec-agree draft Thread-Index: AcIA084N4VvsSfiFTL+cFr+3/OA/9wAAGoVQ From: "James Undery" To: "Vesa Torvinen (LMF)" Cc: "Jari Arkko (LMF)" , "Gonzalo Camarillo Gonzalez (LMF)" , "sip" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA21844 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Vesa Torvinen (LMF) [mailto:Vesa.Torvinen@lmf.ericsson.se] > Sent: 21 May 2002 15:26 > To: James Undery > Cc: Jari Arkko (LMF); Gonzalo Camarillo Gonzalez (LMF); sip > Subject: RE: [Sip] Reviewers for the sec-agree draft > > > Text in section 3.5 is supposed to address this issue: > > "If digest-integrity is chosen, the 494 (Security Agreement Required) > response will contain an HTTP authentication challenge. The client > MUST use the qos parameter possibly together with some variant of The word possibly above worries me, it'd also be nice to make the mechanism explicit e.g. 'sipfrags' as Sanjoy suggested. > MIME tunneling so that the Security-Verify header field in the > request is integrity protected in the MIME body. Note that digest > alone would not fulfill the minimum security requirements of this > specification." > > We didn't want to specify how to use 'digest-integrity' exactly > because this draft is related to negotiation - not individual > mechanisms. Neither did we want to drop the mechanism from the > list because someone can implement it using existing standards > (e.g. MIME, B2BUA, etc). I think a small amount of usage is required e.g. S/MIME protection MUST include any Security-* headers present. (This is mainly implicit at the moment.) James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 11:48:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15369 for ; Tue, 21 May 2002 11:48:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25441 for sip-archive@odin.ietf.org; Tue, 21 May 2002 11:48:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24165; Tue, 21 May 2002 11:19:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24086 for ; Tue, 21 May 2002 11:19:54 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14523; Tue, 21 May 2002 11:19:34 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LFJYa10120; Tue, 21 May 2002 10:19:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 10:19:37 -0500 Message-ID: From: "Sriram Parameswar" To: "'iesg@ietf.org'" , sip@ietf.org Subject: Re:[Sip] Last Call: The Refer Method to Proposed Standard Date: Tue, 21 May 2002 10:19:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200DA.E6433570" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C200DA.E6433570 Content-Type: text/plain; charset="iso-8859-1" Hi: A couple of comments on the Refer draft. 1. It would be good to add REFER to the table in Section 3 and put "m" for Mandatory against the Refer-To header. This would clarify what is in the text just below - also its in keeping with other draft published (example: events draft section 8.2). 2. I had sent a similar comment to the list on 4/26/2002. Section 4.2.2 and section 8.2 of the Events draft http://www.ietf.org/internet-drafts/draft-ietf-sip-events-05.txt (reproduced below for convenience) show that the Subscription State as a mandatory header in a NOTIFY method. It would be good to include these in the examples. I would also like to suggest a small discussion on the semantics of the Subscripton-State header, they will be useful especially in out-of-band REFER's to give the referor (originator of REFER) some idea when he could retry a REFER. For example the discussion could read: The NOTIFY to a REFER MUST contain a Subscription-State which indicates the status of the subscription. Typically for a successful REFER, the NOTIFY SHOULD contain a Subscription-State of "terminated". It may not contain a reason code for the termination, however if one exists it SHOULD be "timeout" (for success cases). For cases where the REFER failed or was rejected (especially out-of-band REFERs) the Subscription-State header with its"reason" and "retry-after" parameters provides important information as to when the REFER may be retried, see the events drafts [EVENTS] for the semantics of the reason codes and the "retry-after" parameters. Please note that the message/sipfrag body will contain the specific reason the REFER failed. Thanks, Sriram Parameswar ----------------------Section 4.2.2 Events draft------------------------------ NOTIFY requests MUST contain a "Subscription-State" header with a value of "active", "pending", or "terminated". ...If the value of the "Subscription-State" header is "terminated", the notifier SHOULD also include a "reason" parameter. The notifier MAY also include a "retry-after" parameter, where appropriate. ----------Section 8.2 Events draft Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT Subscription-State R - - - - - - - - m __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C200DA.E6433570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re:[Sip] Last Call: The Refer Method to Proposed = Standard

Hi:

A couple of comments on the Refer = draft.

1. It would be good to add REFER to = the table in Section 3 and put "m" for Mandatory against the = Refer-To header. This would clarify what is in the text just below - = also its in keeping with other draft published (example: events draft = section 8.2).

2. I had sent a similar comment to the = list on 4/26/2002. Section 4.2.2 and section 8.2 of the Events draft http://www.ietf.org/internet-drafts/draft-ietf-sip-eve= nts-05.txt (reproduced below for convenience) show that the = Subscription State as a mandatory header in a NOTIFY method. It would = be good to include these in the examples. I would also like to suggest = a small discussion on the semantics of the Subscripton-State header, = they will be useful especially in out-of-band REFER's to give the = referor (originator of REFER) some idea when he could retry a REFER. = For example the discussion could read:

         The NOTIFY to a REFER MUST contain a Subscription-State = which indicates the status of the subscription. Typically for a = successful REFER, the NOTIFY SHOULD contain a Subscription-State of = "terminated". It may not contain a reason code for the = termination, however if one exists it SHOULD be "timeout" = (for success cases). For cases where the REFER failed or was rejected = (especially out-of-band REFERs) the Subscription-State header with = its"reason" and "retry-after" parameters provides = important information as to when the REFER may be retried, see the = events drafts [EVENTS] for the semantics of the reason codes and the = "retry-after" parameters. Please note that the = message/sipfrag body will contain the specific reason the REFER = failed.

Thanks,

Sriram Parameswar

----------------------Section 4.2.2 = Events draft------------------------------
NOTIFY requests MUST contain a = "Subscription-State" header with a value of = "active", "pending", or "terminated". = ...If the value of the "Subscription-State" header is = "terminated", the notifier SHOULD also include a = "reason" parameter. The notifier MAY also include a = "retry-after" parameter, where appropriate.

----------Section 8.2 Events = draft
Header field    =         where proxy ACK BYE CAN INV = OPT REG PRA SUB NOT
Subscription-State =      = R            = ;         = -       = -        = -       = -        = -        -     = -        = -       m



__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: = 972-685-8540
Interactive Multimedia Server (IMS) = Fax: 972-684-3986
Nortel Networks, Richardson = USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C200DA.E6433570-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 12:26:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17441 for ; Tue, 21 May 2002 12:26:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29270 for sip-archive@odin.ietf.org; Tue, 21 May 2002 12:26:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28106; Tue, 21 May 2002 12:11:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28081 for ; Tue, 21 May 2002 12:11:47 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16307 for ; Tue, 21 May 2002 12:11:28 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.234]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4LGCbYH017642; Tue, 21 May 2002 12:12:37 -0400 (EDT) Message-ID: <3CEA7198.E7B0BE6B@dynamicsoft.com> Date: Tue, 21 May 2002 12:11:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org Subject: Re: [Sip] Message draft changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > [snip] > > > Actually, I think you mean to say that it is very unlikely that the UA > > will know the path MTU for reaching every sip device. I agree, but its > > not the case that it needs to know. In most usages, the UA will talk > to > > an outbound proxy, and it will know the path MTU to the outbound > proxy. > > Its determination about whether to use UDP or TCP would then be based > on > > this specific path MTU. > > > > Yes, that is what I mean. Why does only the first hop matter for the > UDP/TCP > decision? Because each hop (in the SIP sense) makes an independent decision about which transport to use, and that decision is a function of the size of the request and the path MTU to the next hop (in the sip sense). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 13:01:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19347 for ; Tue, 21 May 2002 13:01:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02196 for sip-archive@odin.ietf.org; Tue, 21 May 2002 13:01:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29063; Tue, 21 May 2002 12:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29032 for ; Tue, 21 May 2002 12:23:57 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17063 for ; Tue, 21 May 2002 12:23:37 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4LGNJPI008341; Tue, 21 May 2002 09:23:20 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS02255; Tue, 21 May 2002 09:20:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03438; Tue, 21 May 2002 09:23:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15594.29815.153064.848806@thomasm-u1.cisco.com> Date: Tue, 21 May 2002 09:23:19 -0700 (PDT) To: Jonathan Rosenberg Cc: Ben Campbell , hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org Subject: Re: [Sip] Message draft changes In-Reply-To: <3CEA7198.E7B0BE6B@dynamicsoft.com> References: <3CEA7198.E7B0BE6B@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > Because each hop (in the SIP sense) makes an independent decision about > which transport to use, and that decision is a function of the size of > the request and the path MTU to the next hop (in the sip sense). Well then, SIP imitates the net again. The net has path MTU discovery to get around this problem; why shouldn't SIP? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 14:49:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24236 for ; Tue, 21 May 2002 14:49:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA07921 for sip-archive@odin.ietf.org; Tue, 21 May 2002 14:49:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06638; Tue, 21 May 2002 14:26:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06599 for ; Tue, 21 May 2002 14:26:21 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23246 for ; Tue, 21 May 2002 14:26:02 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA20168; Tue, 21 May 2002 20:26:01 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA16484; Tue, 21 May 2002 20:24:07 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 11:21:21 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DB7@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'adam@dynamicsoft.com'" Cc: "'sip@ietf.org'" Subject: [SIP] NOTIFY request MUST contain an Expires header? Date: Tue, 21 May 2002 11:21:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, draft-ietf-sip-events states that 200-class responses to SUBSCRIBE requests MUST contain an "Expires" header, which defines the duration of the subscription. In the case of forking, the subscriber will receive only one 200-class response. If the subscriber allows multiple subscriptions and installs further subscriptions when receiving NOTIFY requests, the durations of these subscriptions will not be known to the subscriber as the 200-class responses for these subscriptions would have been dropped at the forking proxy. I think the Expires header should be made mandatory in NOTIFY. Please excuse me if this has been brought up before. Regards, _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 15:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26864 for ; Tue, 21 May 2002 15:54:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11041 for sip-archive@odin.ietf.org; Tue, 21 May 2002 15:55:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10160; Tue, 21 May 2002 15:34:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00073 for ; Mon, 20 May 2002 20:34:46 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24691 for ; Mon, 20 May 2002 20:34:27 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4L0Yh209090 for ; Mon, 20 May 2002 20:34:44 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 19:34:43 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C0296C9EF@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: Dean Willis , Cullen Jennings , "Henrikson, Eric H (Eric)" , sip@ietf.org Subject: RE: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-0 1.txt Date: Mon, 20 May 2002 19:34:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean, Thank you for sending back the responses on my behalf when I was away from my email. I will be updating the draft to give a better explation of the motivation. Eric -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, May 13, 2002 10:37 PM To: Cullen Jennings; Henrikson, Eric H (Eric); sip@ietf.org Subject: Re: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt The proxy doesn't correlate it. The billing system correlates, using the "original call ID" For example: Here's an example: You go through an S-CSCF, through an anonymizer AS and out to a partner company (but we still want you to be anonymized from them so they don't send you spam later) for gateway services. The partner company sends charging records back. We want to be able to correlate the charging records (keyed by OrigID) with the records written by the S-CSCF. Actually, I just realized that this anonymization trick would be useful for statistical "blind sampling" of the veracity of a partner's billing system. You heard it first here folks! DCS had a very similar header called the DCS billing ID or something like that. -- Dean ----- Original Message ----- From: "Cullen Jennings" To: "Henrikson, Eric H (Eric)" ; "Dean Willis" ; Sent: Monday, May 13, 2002 10:55 PM Subject: RE: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt > > I don't understand why the proxy, P1, that sent the call to the AS (a > B2BUA), would need to correlate the call that came back from the AS with the > original call that P1 sent to the AS. Are there any requirements of what we > are trying to solve here? > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Henrikson, Eric H (Eric) > > Sent: Tuesday, May 07, 2002 9:55 AM > > To: Dean Willis; sip@ietf.org > > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison > > Mankin'; Drage, Keith (Keith) > > Subject: [Sip] Expert Review: > > draft-henrikson-sip-original-dialog-id-01.txt > > > > > > Attached is revision 01 of the original-dialog-id draft. > > > > Please return comments by May 10, 2002. > > > > > > Thank you. > > Eric Henrikson > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, May 01, 2002 6:38 AM > > To: sip@ietf.org > > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison > > Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric) > > Subject: Expert Review: draft-henrikson-sip-original-dialog-id-00.txt > > > > > > > > The SIP working group has been asked to provide expert review of > > draft-henrikson-sip-original-dialog-id. This documents a P-header used > > in 3GPP to associate dialogs across a 3GPP application server acting as > > a back-to-back user agent. > > > > We'd like to complete expert review by May 10, 2002. > > > > Please copy your comments to the list and to Keith Drage and Eric > > Henrikson, who will coordinate responses and edit the draft > > apporpriately. > > > > Thanks, > > > > -- > > Dean Willis > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 16:00:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27116 for ; Tue, 21 May 2002 16:00:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11543 for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:00:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10868; Tue, 21 May 2002 15:48:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10839 for ; Tue, 21 May 2002 15:47:55 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26553 for ; Tue, 21 May 2002 15:47:36 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A445C1AA0154; Tue, 21 May 2002 15:47:17 -0400 Message-ID: <00f701c20100$1a2a4200$2300000a@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" , Cc: , , , References: <005501c2003e$2b9f7cc0$1d036e3f@TXDWILLIS2> Subject: Re: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt Date: Tue, 21 May 2002 15:45:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A couple minor nits: 1) The RFC 2119 reference paragraph should be a separate section as opposed to being part of the Abstract. 2) Section 2, 1st para, last sentence: s/to to/to/ cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Dean Willis" To: Cc: ; ; ; Sent: Monday, May 20, 2002 4:37 PM Subject: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt > > I'd like to wrap up: > > http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-04.txt > > > I think this version accomodates all changes requested to date. > > Anybody still have anything to add? Speak now . . . > > Thanks, > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 21 16:02:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27202 for ; Tue, 21 May 2002 16:02:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11683 for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:02:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10599; Tue, 21 May 2002 15:39:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10528 for ; Tue, 21 May 2002 15:39:16 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26241; Tue, 21 May 2002 15:38:57 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A25A445201F6; Tue, 21 May 2002 15:39:06 -0400 Message-ID: <00bf01c200fe$f65edb20$2300000a@acmepacket.com> From: "Bob Penfield" To: Cc: "Robert Sparks" , , "Rohan Mahy" References: <200205201659.MAA18283@ietf.org> Subject: Re: [Sip] Last Call: The Refer Method to Proposed Standard Date: Tue, 21 May 2002 15:37:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I found a few minor problems with a couple of these documents. I apologize for the lateness of these comments. draft-ietf-sip-refer-04.txt: 1) I agree that the title should be changed to "The SIP Refer Method". 2) Section 4 2a) It refers to tables 4 & 5 in the SIP spec (RFC 3261). It should be tables 2 and 3. 2b) 4th line: change "each mandatory" to "mandatory" (there used to be 2 headers, but now just one ) 2c) last sentence: change "enc and e-e columns" to "proxy column". (The enc & e-e columns in RFC 2543 were replaced by the proxy column in RFC 3261). 3) Section 10. 3rd paragraph says that method names are not registered with IANA, but according to section 27.4 of RFC 3261, they now are registered. This spec needs to register the REFER method. draft-ietf-sip-replaces-02.txt: 1) The examples on page 4 and page 10 include a Referred-By header. This header was removed from the REFER spec and therefore has not been defined. It should be removed from the examples. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "The IESG" To: Cc: Sent: Monday, May 20, 2002 12:59 PM Subject: [Sip] Last Call: The Refer Method to Proposed Standard > > The IESG has received a request from the Session Initiation Protocol > Working Group to consider publication of the following Internet-Drafts > as Proposed Standards: > > o The Refer Method > > o The Session Inititation Protocol (SIP) > > o The Reason Header Field for the Session Initiation Protocol > > o Internet Media Types message/sipfrag > > o SIP Extension for Registering Non-Adjacent Contacts > > > > The IESG will also consider publication of Best Current Practices for > Third Party Call Control in the Session Initiation Protocol > as a BCP. > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002. > > Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt > http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt > http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 21 16:45:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29483 for ; Tue, 21 May 2002 16:45:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13657 for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:45:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12636; Tue, 21 May 2002 16:29:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12604 for ; Tue, 21 May 2002 16:29:08 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28690 for ; Tue, 21 May 2002 16:28:48 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4LKRFd17099; Tue, 21 May 2002 15:27:15 -0500 From: "Dean Willis" To: , Cc: , , , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Tue, 21 May 2002 15:26:47 -0500 Message-ID: <00ac01c20105$d68d6490$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED1F@esebe013.NOE.Nokia.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Aki says: > I totally agree. However, I know of email lists / systems, > which have local policy governing the sizes of attachments. I > feel such optionality is currently missing from the MESSAGE > draft. For example, the default content-indirection policy > seems to be that the sender always performs it. How about if > this was part of the recipient's service offering? Sort of > like a safeguard for UAs behind the low-capacity links. It's called a B2BUA or "in network UA" -- it accepts the SIP message, stores the content, and sends a new message (containing a pointer) on towards the user. Like other B2BUA-ish things, this capability is implicit in the current specification. But yeah, it's a cool and useful service opportunity. I use something very similar to send snippets of large emails to my mobile devices. Then I can look at the snippets and guess if it's worth downloading full text at $10/MB . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 21 16:50:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29758 for ; Tue, 21 May 2002 16:50:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13754 for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:50:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12584; Tue, 21 May 2002 16:28:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12550 for ; Tue, 21 May 2002 16:28:14 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28626 for ; Tue, 21 May 2002 16:27:54 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4LKRDd17096; Tue, 21 May 2002 15:27:14 -0500 From: "Dean Willis" To: "'Ben Campbell'" , "'Jonathan Rosenberg'" Cc: , , Subject: RE: [Sip] Message draft changes Date: Tue, 21 May 2002 15:26:47 -0500 Message-ID: <00ab01c20105$d62ec9d0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Actually, I think you mean to say that it is very unlikely > that the UA > > will know the path MTU for reaching every sip device. I > agree, but its > > not the case that it needs to know. In most usages, the UA > will talk > > to an outbound proxy, and it will know the path MTU to the outbound > > proxy. Its determination about whether to use UDP or TCP > would then be > > based on this specific path MTU. > > > > Yes, that is what I mean. Why does only the first hop matter > for the UDP/TCP decision? Because the definition of "proxy" is to "delegate decision-making to another entity.". The crux of the argument is that once it has left the UA and gotten safely to the first-hop-proxy, what to do NEXT is now the proxy's problem. Maybe that next hop proxy implements flow control for UDP by tunnelling all UDP requests over SSH. Maybe it uses SCTP. But it's the only one who really KNOWS. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 21 17:00:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00302 for ; Tue, 21 May 2002 17:00:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15037 for sip-archive@odin.ietf.org; Tue, 21 May 2002 17:00:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13532; Tue, 21 May 2002 16:43:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13503 for ; Tue, 21 May 2002 16:43:07 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29384 for ; Tue, 21 May 2002 16:42:47 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4LKg3d17186; Tue, 21 May 2002 15:42:03 -0500 From: "Dean Willis" To: "'Bob Penfield'" , Cc: , , , Subject: RE: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt Date: Tue, 21 May 2002 15:41:38 -0500 Message-ID: <00ad01c20107$e83bd7b0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00f701c20100$1a2a4200$2300000a@acmepacket.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob noted: > A couple minor nits: > > 1) The RFC 2119 reference paragraph should be a separate > section as opposed to being part of the Abstract. I wondered about this too, but I copied the section wholsale from some moderately recently published RFC (which, I don't recall, just grabbed a number out of the RFC pool). However, further review shows that the majority of newest documents include such annotation in a separate section such as "Conventions used in this document" (RFC 3206) or "Terminology" (RFC 3207). > 2) Section 2, 1st para, last sentence: s/to to/to/ Oops oops. I will fix both in next, hopefully final rev. ANYBODY HAVE ANYTHING ELSE? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 21 17:12:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00808 for ; Tue, 21 May 2002 17:12:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15692 for sip-archive@odin.ietf.org; Tue, 21 May 2002 17:12:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13911; Tue, 21 May 2002 16:54:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13882 for ; Tue, 21 May 2002 16:54:25 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29900 for ; Tue, 21 May 2002 16:54:04 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4LKsFX92799; Tue, 21 May 2002 15:54:15 -0500 (CDT) From: "Ben Campbell" To: "Dean Willis" , "'Jonathan Rosenberg'" Cc: , , Subject: RE: [Sip] Message draft changes Date: Tue, 21 May 2002 15:54:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <00ab01c20105$d62ec9d0$1d036e3f@TXDWILLIS2> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, May 21, 2002 3:27 PM > To: 'Ben Campbell'; 'Jonathan Rosenberg' > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org > Subject: RE: [Sip] Message draft changes > > > > > Actually, I think you mean to say that it is very unlikely > > that the UA > > > will know the path MTU for reaching every sip device. I > > agree, but its > > > not the case that it needs to know. In most usages, the UA > > will talk > > > to an outbound proxy, and it will know the path MTU to the outbound > > > proxy. Its determination about whether to use UDP or TCP > > would then be > > > based on this specific path MTU. > > > > > > > Yes, that is what I mean. Why does only the first hop matter > > for the UDP/TCP decision? > > Because the definition of "proxy" is to "delegate decision-making to > another entity.". The crux of the argument is that once it has left the > UA and gotten safely to the first-hop-proxy, what to do NEXT is now the > proxy's problem. Maybe that next hop proxy implements flow control for > UDP by tunnelling all UDP requests over SSH. Maybe it uses SCTP. But > it's the only one who really KNOWS. > Right, of course--I was confusing myself with the stonger requirement for MESSAGE, where the fact that some downstream proxy could convert to UDP causes us to limit request size to 1300. The original question comes from feedback suggesting this size was unnecesarily arbitrary. It was also suggested that it should be relative to path MTU to the first hop. But I am not sure the first hop path MTU is relevant. The real goal is to keep the size below the path MTU of _all_ hops, _most_ of the time. The first hop mtu tells you nothing about the rest. I assume the 1300 default was chosen for SIP in general because of a belief that, if you have no knowledge of MTU size, that value is a reasonable SWAG. I don't see how we can do any better for MESSAGE. > -- > Dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 21 17:43:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02027 for ; Tue, 21 May 2002 17:43:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17039 for sip-archive@odin.ietf.org; Tue, 21 May 2002 17:44:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16117; Tue, 21 May 2002 17:29:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16088 for ; Tue, 21 May 2002 17:29:07 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01469 for ; Tue, 21 May 2002 17:28:47 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.234]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4LLU6YH018164; Tue, 21 May 2002 17:30:07 -0400 (EDT) Message-ID: <3CEABC01.6DC423D9@dynamicsoft.com> Date: Tue, 21 May 2002 17:28:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: "'adam@dynamicsoft.com'" , "'sip@ietf.org'" Subject: Re: [SIP] NOTIFY request MUST contain an Expires header? References: <5B4D0C5BA65ECA46969C1419122317E6E74DB7@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Hi, > > draft-ietf-sip-events states that 200-class responses to SUBSCRIBE > requests > MUST contain an "Expires" header, which defines the duration of the > subscription. In the case of forking, the subscriber will receive only > one > 200-class response. If the subscriber allows multiple subscriptions and > installs further subscriptions when receiving NOTIFY requests, the > durations > of these subscriptions will not be known to the subscriber as the > 200-class > responses for these subscriptions would have been dropped at the forking > proxy. I think the Expires header should be made mandatory in NOTIFY. There is an expires parameter in the Subscription-State header which conveys the expiration of the subscription. The decision was made not to use the Expires header for this purpose, since Expires refers to the message its carried in, and it is not the NOTIFY which is expiring, but the subscription. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 01:56:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19255 for ; Wed, 22 May 2002 01:56:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16451 for sip-archive@odin.ietf.org; Wed, 22 May 2002 01:56:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16092; Wed, 22 May 2002 01:39:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16033 for ; Wed, 22 May 2002 01:39:19 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18627 for ; Wed, 22 May 2002 01:39:00 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4M5ccuF020878; Tue, 21 May 2002 22:38:38 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACY93242; Tue, 21 May 2002 22:39:00 -0700 (PDT) From: "Cullen Jennings" To: , Date: Tue, 21 May 2002 22:39:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200205211130.HAA04901@ietf.org> Content-Transfer-Encoding: 7bit Subject: [Sip] draft-garcia-sip-visited-network-id-01.txt and history requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems to me that the mechanism that meets the requirements of the history requirements (draft-watson-sipping-req-history-01.txt) would also solve this problem. Do we want two things to do the same thing? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 01:56:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19276 for ; Wed, 22 May 2002 01:56:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16474 for sip-archive@odin.ietf.org; Wed, 22 May 2002 01:56:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16108; Wed, 22 May 2002 01:39:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16039 for ; Wed, 22 May 2002 01:39:20 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18632 for ; Wed, 22 May 2002 01:39:02 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4M5cnEU004775; Tue, 21 May 2002 22:38:49 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACY93243; Tue, 21 May 2002 22:39:00 -0700 (PDT) From: "Cullen Jennings" To: , Date: Tue, 21 May 2002 22:39:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-garcia-sip-called-party-id-01.txt and history requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems to me that the mechanism that meets the requirements of the history requirements (draft-watson-sipping-req-history-01.txt) would also solve this problem. Do we want two things to do the same thing? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 03:03:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14458 for ; Wed, 22 May 2002 03:03:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02727 for sip-archive@odin.ietf.org; Wed, 22 May 2002 03:03:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01591; Wed, 22 May 2002 02:46:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01560 for ; Wed, 22 May 2002 02:46:12 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13717 for ; Wed, 22 May 2002 02:45:37 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4M6iLY01596 for ; Wed, 22 May 2002 09:44:21 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 May 2002 09:45:07 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 09:45:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Wed, 22 May 2002 09:45:06 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED22@esebe013.NOE.Nokia.com> Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Thread-Index: AcIBBlJzEHPB5G1QREm9rgUjlcxrkQAVMReQ To: , Cc: , , , , X-OriginalArrivalTime: 22 May 2002 06:45:07.0511 (UTC) FILETIME=[360B1470:01C2015C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA01561 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Aki says: > > I totally agree. However, I know of email lists / systems, > > which have local policy governing the sizes of attachments. I > > feel such optionality is currently missing from the MESSAGE > > draft. For example, the default content-indirection policy > > seems to be that the sender always performs it. How about if > > this was part of the recipient's service offering? Sort of > > like a safeguard for UAs behind the low-capacity links. > > It's called a B2BUA or "in network UA" -- it accepts the SIP message, > stores the content, and sends a new message (containing a pointer) on > towards the user. Like other B2BUA-ish things, this capability is > implicit in the current specification. Yes, the capability is there, but since the sender itself is always responsible for enforcing the 1300 byte size limitation of the MESSAGE request, this effectively negates any need for such a UA in the network. I was saying that it would be nice if the actual enforcement of the size limit could be relaxed, so that it could also be up to such a store-and-forward UA in the network. However, having said that I can't think of a simple way to make this happen. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 04:15:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17036 for ; Wed, 22 May 2002 04:15:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06097 for sip-archive@odin.ietf.org; Wed, 22 May 2002 04:15:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03782; Wed, 22 May 2002 03:27:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03751 for ; Wed, 22 May 2002 03:27:28 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15381 for ; Wed, 22 May 2002 03:25:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4M7Qbk03280 for ; Wed, 22 May 2002 10:26:37 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 May 2002 10:26:05 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 10:26:03 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 10:26:02 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Message draft changes X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 22 May 2002 10:26:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791CC@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Message draft changes Thread-Index: AcIBCbFZb7Qia8YMSXuozHZh7c8NKQAV/JuA To: , , Cc: , X-OriginalArrivalTime: 22 May 2002 07:26:03.0000 (UTC) FILETIME=[EDA0F780:01C20161] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA03752 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, May 21, 2002 11:54 PM > To: Dean Willis; 'Jonathan Rosenberg' > Cc: Khartabil Hisham (NMP/Helsinki); Niemi Aki (NET/Espoo); > sip@ietf.org > Subject: RE: [Sip] Message draft changes > > > I assume the 1300 default was chosen for SIP in general > because of a belief > that, if you have no knowledge of MTU size, that value is a > reasonable SWAG. > I don't see how we can do any better for MESSAGE. There is no need to mention anything about that in the MESSAGE draft. A reference to RFC3261 is enough for this issue. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 22 04:53:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17824 for ; Wed, 22 May 2002 04:53:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07906 for sip-archive@odin.ietf.org; Wed, 22 May 2002 04:53:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05458; Wed, 22 May 2002 04:00:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05401 for ; Wed, 22 May 2002 04:00:25 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16542 for ; Wed, 22 May 2002 04:00:06 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4M80Os7000661; Wed, 22 May 2002 10:00:24 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4M80N9q016726; Wed, 22 May 2002 11:00:23 +0300 (EET DST) Message-ID: <3CEB5017.C835BE93@ericsson.com> Date: Wed, 22 May 2002 11:00:23 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-garcia-sip-called-party-id-01.txt and history requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Cullen: I am aware that this P- header may be part of the history. However, as you know, the history is still in requirements phase, whereas 3GPP Release 5 needs a solution by June timeframe. Miguel Cullen Jennings wrote: > > It seems to me that the mechanism that meets the requirements of the history > requirements (draft-watson-sipping-req-history-01.txt) would also solve this > problem. Do we want two things to do the same thing? > > Cullen -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 22 04:55:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17902 for ; Wed, 22 May 2002 04:55:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07961 for sip-archive@odin.ietf.org; Wed, 22 May 2002 04:55:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05500; Wed, 22 May 2002 04:00:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05446 for ; Wed, 22 May 2002 04:00:28 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16546 for ; Wed, 22 May 2002 04:00:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4M80Qs7000671; Wed, 22 May 2002 10:00:26 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4M80Q9q016731; Wed, 22 May 2002 11:00:26 +0300 (EET DST) Message-ID: <3CEB501A.9B6B6FED@ericsson.com> Date: Wed, 22 May 2002 11:00:26 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and history requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Cullen: I am aware that this P- header may be part of the history. However, as you know, the history is still in requirements phase, whereas 3GPP Release 5 needs a solution by June timeframe. Miguel Cullen Jennings wrote: > > It seems to me that the mechanism that meets the requirements of the history > requirements (draft-watson-sipping-req-history-01.txt) would also solve this > problem. Do we want two things to do the same thing? > > Cullen -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 22 05:16:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18287 for ; Wed, 22 May 2002 05:16:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09012 for sip-archive@odin.ietf.org; Wed, 22 May 2002 05:16:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06427; Wed, 22 May 2002 04:23:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06397 for ; Wed, 22 May 2002 04:23:54 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17326 for ; Wed, 22 May 2002 04:23:35 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA11240; Wed, 22 May 2002 10:23:51 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA16791; Wed, 22 May 2002 10:23:52 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 10:23:54 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DC8@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Jonathan Rosenberg'" Cc: "'adam@dynamicsoft.com'" , "'sip@ietf.org'" Subject: RE: [SIP] NOTIFY request MUST contain an Expires header? Date: Wed, 22 May 2002 10:23:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the answer. In that case, shouldn't the "expires" parameter in the Subscription-State header in NOTIFY carry the same MUST strength as for Expires header in 200 OK response to SUBSCRIBE, instead of just a SHOULD (second last paragraph of 4.2.2 of draft-sip-events)? Section 4.2.4 'Subscriber NOTIFY Behavior' also talks about the "expires" parameter with "If the Subscription-State header also contains an "expires" parameter...", but what if it does not ? Can a NOTIFY request which matches (according to 4.3.4) the SUBSCRIBE request create a subscription and a new dialog if its Subscription-State does not contain an "expires" parameter ? Regards, Ya-Ching Tan Jonathan Rosenberg wrote: | | There is an expires parameter in the Subscription-State header which | conveys the expiration of the subscription. The decision was made not to | use the Expires header for this purpose, since Expires refers to the | message its carried in, and it is not the NOTIFY which is | expiring, but the subscription. | _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 22 07:20:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22665 for ; Wed, 22 May 2002 07:20:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA14368 for sip-archive@odin.ietf.org; Wed, 22 May 2002 07:20:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12381; Wed, 22 May 2002 06:42:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12350 for ; Wed, 22 May 2002 06:42:40 -0400 (EDT) Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21198 for ; Wed, 22 May 2002 06:42:19 -0400 (EDT) From: frank.derks@philips.com Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl6.philips.com (Postfix) with ESMTP id 4B88FA0CA5 for ; Wed, 22 May 2002 12:42:38 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA13467 for ; Wed, 22 May 2002 12:42:38 +0200 (MET DST) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA17163 for ; Wed, 22 May 2002 12:42:37 +0200 (MET DST) To: sip@ietf.org Subject: Re: [Sip] Last Call: The Refer Method to Proposed Standard X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 22 May 2002 12:41:04 +0200 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 22/05/2002 12:43:37, Serialize complete at 22/05/2002 12:43:37 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003AD12CC1256BC1_=" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 003AD12CC1256BC1_= Content-Type: text/plain; charset="us-ascii" - Section 6.1, 2nd paragraph, contains a rather strange sentence "For example, if the URI is a SIP URI indicating an INVITE should be generated ..." I guess that it should be: "For example, if the URI is a SIP URI indicating an INVITE an INVITE should be generated ..." - The use of colons after header names is not always consistent. E.g. in 6.3.1's first bullet item "Call-ID". - Section 7.1, first paragraph, states: "The details of this flow indicate this ..." I guess it should state: "The details of this flow indicate that this ..." Furthermore, the example that follows is not in line with the text. The text states that there is no To: tag, but there is one in the example. - Section 8.1 talks about INVITE URIs. I am not sure whether this type of URI (although I think I understand what is meant) is defined anywhere. Regards, Frank ----- Original Message ----- From: "The IESG" To: Cc: Sent: Monday, May 20, 2002 12:59 PM Subject: [Sip] Last Call: The Refer Method to Proposed Standard > > The IESG has received a request from the Session Initiation Protocol > Working Group to consider publication of the following Internet-Drafts > as Proposed Standards: > > o The Refer Method > > o The Session Inititation Protocol (SIP) > > o The Reason Header Field for the Session Initiation Protocol > > o Internet Media Types message/sipfrag > > o SIP Extension for Registering Non-Adjacent Contacts > > > > The IESG will also consider publication of Best Current Practices for > Third Party Call Control in the Session Initiation Protocol > as a BCP. > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002. > > Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt > http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt > http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 003AD12CC1256BC1_= Content-Type: text/html; charset="us-ascii"
- Section 6.1, 2nd paragraph, contains a rather strange sentence

  "For example, if the URI is a SIP URI indicating an INVITE
   should be generated ..."

  I guess that it should be:

  "For example, if the URI is a SIP URI indicating an INVITE
   an INVITE should be generated ..."

- The use of colons after header names is not always consistent.
  E.g. in 6.3.1's first bullet item "Call-ID".

- Section 7.1, first paragraph, states:

  "The details of this flow indicate this ..."

  I guess it should state:

  "The details of this flow indicate that this ..."

  Furthermore, the example that follows is not in line with the
  text. The text states that there is no To: tag, but there is
  one in the example.

- Section 8.1 talks about INVITE URIs. I am not sure whether this
  type of URI (although I think I understand what is meant) is
  defined anywhere.

 
Regards,

Frank


----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
To: <IETF-Announce:>
Cc: <sip@ietf.org>
Sent: Monday, May 20, 2002 12:59 PM
Subject: [Sip] Last Call: The Refer Method to Proposed Standard


>
> The IESG has received a request from the Session Initiation Protocol
> Working Group to consider publication of the following Internet-Drafts
> as Proposed Standards:
>
>  o The Refer Method
> <draft-ietf-sip-refer-04.txt>
>  o The Session Inititation Protocol (SIP)
> <draft-ietf-sip-replaces-02.txt>
>  o The Reason Header Field for the Session Initiation Protocol
> <draft-ietf-sip-reason-01.txt>
>  o Internet Media Types message/sipfrag
> <draft-sparks-sip-mimetypes-03.txt>
>  o SIP Extension for Registering Non-Adjacent Contacts
> <draft-willis-sip-path-06.txt>
>
>
> The IESG will also consider publication of Best Current Practices for
> Third Party Call Control in the Session Initiation Protocol
> <draft-ietf-sipping-3pcc-00.txt> as a BCP.
>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002.
>
> Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt
> http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
> http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

--=_alternative 003AD12CC1256BC1_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 22 07:49:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24609 for ; Wed, 22 May 2002 07:49:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16221 for sip-archive@odin.ietf.org; Wed, 22 May 2002 07:50:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14450; Wed, 22 May 2002 07:21:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14427 for ; Wed, 22 May 2002 07:21:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22859; Wed, 22 May 2002 07:21:13 -0400 (EDT) Message-Id: <200205221121.HAA22859@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 May 2002 07:21:13 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-path-07.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP Extension for Registering Non-Adjacent Contacts Author(s) : D. Willis, B. Hoeneisen Filename : draft-willis-sip-path-07.txt Pages : 18 Date : 21-May-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: and is generally dynamic and associated with the IP address or hostname of the SIP UA. The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request travelling from the user's home network to the registered UA must traverse these proxies. The REGISTER method 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 field, 'Path' which provides such a mechanism A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-path-07.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-willis-sip-path-07.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-path-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020521141821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-path-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-path-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020521141821.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 10:10:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03414 for ; Wed, 22 May 2002 10:10:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27067 for sip-archive@odin.ietf.org; Wed, 22 May 2002 10:11:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23225; Wed, 22 May 2002 09:27:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23194 for ; Wed, 22 May 2002 09:27:47 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00942 for ; Wed, 22 May 2002 09:27:28 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g4MDQSX62294; Wed, 22 May 2002 08:26:28 -0500 (CDT) Message-ID: <3CEB9C74.9050509@dynamicsoft.com> Date: Wed, 22 May 2002 08:26:12 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: dean.willis@softarmor.com, jdrosen@dynamicsoft.com, hgs@cs.columbia.edu, mat@cisco.com, seancolson@yahoo.com, sip@ietf.org Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED22@esebe013.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: >>Aki says: [snip] >>It's called a B2BUA or "in network UA" -- it accepts the SIP message, >>stores the content, and sends a new message (containing a pointer) on >>towards the user. Like other B2BUA-ish things, this capability is >>implicit in the current specification. > > > Yes, the capability is there, but since the sender itself is always responsible for enforcing the 1300 byte size limitation of the MESSAGE request, this effectively negates any need for such a UA in the network. > > I was saying that it would be nice if the actual enforcement of the size limit could be relaxed, so that it could also be up to such a store-and-forward UA in the network. However, having said that I can't think of a simple way to make this happen. > You would still have the congestion control issue to the b2bua. We are adding new wording to say that if you know you are congestion-safe all the way, you can exceed the limit. If that device is under your control in such a way that you can ensure congestion-safe transports all the way to the b2bua, then you would be covered. Thanks! Ben. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 10:43:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05057 for ; Wed, 22 May 2002 10:43:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28947 for sip-archive@odin.ietf.org; Wed, 22 May 2002 10:43:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25555; Wed, 22 May 2002 09:59:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25524 for ; Wed, 22 May 2002 09:59:07 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02732 for ; Wed, 22 May 2002 09:58:47 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MDwTL17424; Wed, 22 May 2002 15:58:29 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MDvfU29306; Wed, 22 May 2002 14:57:41 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 14:58:49 +0100 Message-ID: From: "Mark Watson" To: "'Peterson, Jon'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Wed, 22 May 2002 14:58:41 +0100 Importance: high X-Priority: 1 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org All, Can we have a *decision* asap as to whether the 'hint' uses Asserted-Identity, or another header in another draft. I do not mind which. If the latter I will publish an I-D describing it as soon as we have a decision, assuming it is this week, since I'm away next week. If we do nothing, then I guess 3GPP will make up its own mind how to do this, without supervision or advice from IETF, which I think would be a bad thing. Regards...Mark -----Original Message----- From: Watson, Mark [MDN05:EP10:EXCH] Sent: 20 May 2002 12:08 To: 'Peterson, Jon'; 'Rohan Mahy' Cc: sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? The 'hint' was one of the three requirements that 3GPP communicated to us in April. It is a separate requirement from the Network Asserted Identity itself, and so is not addressed in the requirements draft, although I have been careful to point this out, and to point out that it is a requirement nontheless, on several occasions. I believe we need the 'hint' in the same timeframe as the rest of the short term work. Whether it is the same header/draft or a different header/draft is another question on which I will only say that we'd better make up our minds pretty quick. ...Mark > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 19 May 2002 18:11 > To: 'Rohan Mahy' > Cc: sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > My argument was not that the proposed hint won't work - just > that it isn't > necessary to solve the problem at hand. It might not be the > case that the > problems with the hint stop at the philosophical point you > mention below. > What I asked in my last mail was not whether or not we needed > a hint, but > rather whether or not we should table that question until we > resolve the > other questions at hand. I just don't want to spend the > cycles arguing about > the hint given our very aggressive timetable - frankly, I think that > reaching consensus on this hint matter might push back our > dates a bit. > Let's investigate this hint stuff in June, but for now just > figure out how a > Trust Domain can manage an asserted identity in a message. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Sunday, May 19, 2002 8:29 AM > > To: Peterson, Jon > > Cc: sip@ietf.org > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > Hi, > > > > The requirement for a hint is well understood, limited in > > scope, and well motivated in the draft. Nobody has identified > > any technical reason why the hint won't work. Your argument > > that allowing a hint weakens the strength of the language on > > ignoring Asserted-Identity from untrusted parties is purely > > philosophical in nature. I don't buy your argument. > > > > thanks, > > -rohan > > > > > > ---- Original message ---- > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > >From: "Peterson, Jon" > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > >To: "'sip@ietf.org'" > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > Jennings and > > >myself about the short-term identity work, we have returned a > > few times to > > >the question of the infamous hint. This hint is, of course, a > > way that a > > >user agent (one that is not a member of the Trust Domain in > > the short-term > > >network asserted identity space) can provide a 'hint' to the > > intermediary > > >that will generate an Asserted-Identity indicating which > > identity among > > >several possibilities should be asserted. > > > > > >The need for this arises particularly from the 3G space, in > > which the > > >authentication process takes place independently of SIP and > > does not carry > > >this sort of personal identity information. It also assumes > > that the > > >operators of the intermediary in question are aware of > > several legitimate > > >identities which the user can elect to assert. > > > > > >It has been proposed on the mailing list and elsewhere that the > > >Asserted-Identity header should be re-used by user agents > > outside the Trust > > >Domain to provide such a hint. I see a number of reasons for > > and against > > >using the Asserted-Identity for this purpose. For example, > > today, there is a > > >requirement that asserted-identities which are transmitted > > from untrusted > > >sources should not be used in any way - this would seem to > > weaken that > > >requirement. There is also possibly some behavior that still > > needs to be > > >specified (like how an intermediary would reject or otherwise > > handle a > > >request with an inappropriate hint) that might be impactful > > to our choice. > > > > > >For the time being, however, I would like to suggest that > > providing the hint > > >is outside the scope of the current deliverables (the > > asserted-identity > > >requirements and mechanism drafts), which need to be > > complete, as we > > >discussed in the interim meeting, by the end of this month. I > > believe that a > > >separate draft should propose the use of Asserted-Identity or > > any other > > >header for this hint (in whatever timeframe is appropriate > > for 3G's > > >requirements), but that we should not speak to this matter in > > the current > > >asserted-identity deliverables. There is, as I see it, no > > dependency on > > >defining this hint before we dictate how intermediaries will > > assert > > >identities. > > > > > >Any comments on this plan? > > > > > >Jon Peterson > > >NeuStar, Inc. > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 11:17:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08754 for ; Wed, 22 May 2002 11:17:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01331 for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:18:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29025; Wed, 22 May 2002 10:45:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28997 for ; Wed, 22 May 2002 10:45:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05202 for ; Wed, 22 May 2002 10:45:26 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4MEjFPI001625; Wed, 22 May 2002 07:45:15 -0700 (PDT) Received: from OranLT ([161.44.238.34]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACY99404; Wed, 22 May 2002 07:45:25 -0700 (PDT) From: "David R. Oran" To: "'Mark Watson'" , "'Peterson, Jon'" , "'Rohan Mahy'" , Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Wed, 22 May 2002 10:45:12 -0400 Organization: Cisco Systems Message-ID: <005b01c2019f$476c8f80$22ee2ca1@OranLT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I suggest we allow the hint to be placed in the asserted-identity rather than in another header. A boundary proxy has to deal with a UA putting in the header no matter what, if only to reject the request with an error. Once we have a full solution the issue of hints should go away as a side effect of having the "authorization server" functionality that Jon proposes. Better IMHO to have one obsolescent header to deal with rather than two, as well as avoiding the concomitant verbiage describing the combinatoric cases involving two headers. Dave. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Mark Watson > Sent: Wednesday, May 22, 2002 9:59 AM > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > Importance: High > > > All, > > Can we have a *decision* asap as to whether the 'hint' uses > Asserted-Identity, or another header in another draft. > > I do not mind which. If the latter I will publish an I-D > describing it as soon as we have a decision, assuming it is > this week, since I'm away next week. > > If we do nothing, then I guess 3GPP will make up its own mind > how to do this, without supervision or advice from IETF, > which I think would be a bad thing. > > Regards...Mark > > > -----Original Message----- > From: Watson, Mark [MDN05:EP10:EXCH] > Sent: 20 May 2002 12:08 > To: 'Peterson, Jon'; 'Rohan Mahy' > Cc: sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > The 'hint' was one of the three requirements that 3GPP > communicated to us in April. > It is a separate requirement from the Network Asserted > Identity itself, and so is not addressed in the requirements > draft, although I have been careful to point this out, and to > point out that it is a requirement nontheless, on several > occasions. I believe we need the 'hint' in the same timeframe > as the rest of the short term work. > Whether it is the same header/draft or a different > header/draft is another question on which I will only say > that we'd better make up our minds pretty quick. ...Mark > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: 19 May 2002 18:11 > > To: 'Rohan Mahy' > > Cc: sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > My argument was not that the proposed hint won't work - just > > that it isn't > > necessary to solve the problem at hand. It might not be the > > case that the > > problems with the hint stop at the philosophical point you > > mention below. > > What I asked in my last mail was not whether or not we needed > > a hint, but > > rather whether or not we should table that question until we > > resolve the > > other questions at hand. I just don't want to spend the > > cycles arguing about > > the hint given our very aggressive timetable - frankly, I > think that > > reaching consensus on this hint matter might push back our > > dates a bit. > > Let's investigate this hint stuff in June, but for now just > > figure out how a > > Trust Domain can manage an asserted identity in a message. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, May 19, 2002 8:29 AM > > > To: Peterson, Jon > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > Hi, > > > > > > The requirement for a hint is well understood, limited in > > > scope, and well motivated in the draft. Nobody has identified > > > any technical reason why the hint won't work. Your argument > > > that allowing a hint weakens the strength of the language on > > > ignoring Asserted-Identity from untrusted parties is purely > > > philosophical in nature. I don't buy your argument. > > > > > > thanks, > > > -rohan > > > > > > > > > ---- Original message ---- > > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > > >From: "Peterson, Jon" > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > > >To: "'sip@ietf.org'" > > > > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > > Jennings and > > > >myself about the short-term identity work, we have returned a > > > few times to > > > >the question of the infamous hint. This hint is, of course, a > > > way that a > > > >user agent (one that is not a member of the Trust Domain in > > > the short-term > > > >network asserted identity space) can provide a 'hint' to the > > > intermediary > > > >that will generate an Asserted-Identity indicating which > > > identity among > > > >several possibilities should be asserted. > > > > > > > >The need for this arises particularly from the 3G space, in > > > which the > > > >authentication process takes place independently of SIP and > > > does not carry > > > >this sort of personal identity information. It also assumes > > > that the > > > >operators of the intermediary in question are aware of > > > several legitimate > > > >identities which the user can elect to assert. > > > > > > > >It has been proposed on the mailing list and elsewhere that the > > > >Asserted-Identity header should be re-used by user agents > > > outside the Trust > > > >Domain to provide such a hint. I see a number of reasons for > > > and against > > > >using the Asserted-Identity for this purpose. For example, > > > today, there is a > > > >requirement that asserted-identities which are transmitted > > > from untrusted > > > >sources should not be used in any way - this would seem to > > > weaken that > > > >requirement. There is also possibly some behavior that still > > > needs to be > > > >specified (like how an intermediary would reject or otherwise > > > handle a > > > >request with an inappropriate hint) that might be impactful > > > to our choice. > > > > > > > >For the time being, however, I would like to suggest that > > > providing the hint > > > >is outside the scope of the current deliverables (the > > > asserted-identity > > > >requirements and mechanism drafts), which need to be > > > complete, as we > > > >discussed in the interim meeting, by the end of this month. I > > > believe that a > > > >separate draft should propose the use of Asserted-Identity or > > > any other > > > >header for this hint (in whatever timeframe is appropriate > > > for 3G's > > > >requirements), but that we should not speak to this matter in > > > the current > > > >asserted-identity deliverables. There is, as I see it, no > > > dependency on > > > >defining this hint before we dictate how intermediaries will > > > assert > > > >identities. > > > > > > > >Any comments on this plan? > > > > > > > >Jon Peterson > > > >NeuStar, Inc. > > > > > > > >_______________________________________________ > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >This list is for NEW development of the core SIP Protocol > > > >Use sip-implementors@cs.columbia.edu for questions on > current sip > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 11:22:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09490 for ; Wed, 22 May 2002 11:22:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01478 for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:22:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29429; Wed, 22 May 2002 10:52:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29325 for ; Wed, 22 May 2002 10:52:28 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05472 for ; Wed, 22 May 2002 10:52:07 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17AXTP-0004SV-00; Wed, 22 May 2002 17:52:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15595.45219.118919.381999@harjus.eng.song.fi> Date: Wed, 22 May 2002 17:52:19 +0300 To: "Mark Watson" Cc: "'Peterson, Jon'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > Can we have a *decision* asap as to whether the 'hint' uses > Asserted-Identity, or another header in another draft. i don't care what the "hint" header is called, as long as it is not "hint". the term "hint" is not good for this purpose, because it is not something the network can override. the network can only check it and then either accept it or reject the call. if Asserted-Identity is not ok for the majority, then my suggestion is "Really-From". it should be used only in case the from header is anonymous. otherwise the sip uri in the from header is used. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 11:27:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10577 for ; Wed, 22 May 2002 11:27:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02034 for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:28:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29468; Wed, 22 May 2002 10:52:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29328 for ; Wed, 22 May 2002 10:52:28 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05468 for ; Wed, 22 May 2002 10:51:56 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4MEmqKf021663; Wed, 22 May 2002 10:48:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 10:51:29 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36B4782@DYN-TX-EXCH-001.dynamicsoft.com> From: Andrew Allen To: "'David R. Oran'" , "'Mark Watson'" , "'Peterson, Jon'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Wed, 22 May 2002 10:51:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree with Dave. Lets put the hint in the asserted-identity. Lets not have two redundant headers that need to be transferred over the Radio interface unnecessarily. Andrew > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, May 22, 2002 9:45 AM > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > I suggest we allow the hint to be placed in the > asserted-identity rather > than in another header. A boundary proxy has to deal with a UA putting > in the header no matter what, if only to reject the request with an > error. > > Once we have a full solution the issue of hints should go > away as a side > effect of having the "authorization server" functionality that Jon > proposes. Better IMHO to have one obsolescent header to deal > with rather > than two, as well as avoiding the concomitant verbiage describing the > combinatoric cases involving two headers. > > Dave. > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Mark Watson > > Sent: Wednesday, May 22, 2002 9:59 AM > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > Importance: High > > > > > > All, > > > > Can we have a *decision* asap as to whether the 'hint' uses > > Asserted-Identity, or another header in another draft. > > > > I do not mind which. If the latter I will publish an I-D > > describing it as soon as we have a decision, assuming it is > > this week, since I'm away next week. > > > > If we do nothing, then I guess 3GPP will make up its own mind > > how to do this, without supervision or advice from IETF, > > which I think would be a bad thing. > > > > Regards...Mark > > > > > > -----Original Message----- > > From: Watson, Mark [MDN05:EP10:EXCH] > > Sent: 20 May 2002 12:08 > > To: 'Peterson, Jon'; 'Rohan Mahy' > > Cc: sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > The 'hint' was one of the three requirements that 3GPP > > communicated to us in April. > > It is a separate requirement from the Network Asserted > > Identity itself, and so is not addressed in the requirements > > draft, although I have been careful to point this out, and to > > point out that it is a requirement nontheless, on several > > occasions. I believe we need the 'hint' in the same timeframe > > as the rest of the short term work. > > Whether it is the same header/draft or a different > > header/draft is another question on which I will only say > > that we'd better make up our minds pretty quick. ...Mark > > > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: 19 May 2002 18:11 > > > To: 'Rohan Mahy' > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > My argument was not that the proposed hint won't work - just > > > that it isn't > > > necessary to solve the problem at hand. It might not be the > > > case that the > > > problems with the hint stop at the philosophical point you > > > mention below. > > > What I asked in my last mail was not whether or not we needed > > > a hint, but > > > rather whether or not we should table that question until we > > > resolve the > > > other questions at hand. I just don't want to spend the > > > cycles arguing about > > > the hint given our very aggressive timetable - frankly, I > > think that > > > reaching consensus on this hint matter might push back our > > > dates a bit. > > > Let's investigate this hint stuff in June, but for now just > > > figure out how a > > > Trust Domain can manage an asserted identity in a message. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > > Sent: Sunday, May 19, 2002 8:29 AM > > > > To: Peterson, Jon > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > Hi, > > > > > > > > The requirement for a hint is well understood, limited in > > > > scope, and well motivated in the draft. Nobody has identified > > > > any technical reason why the hint won't work. Your argument > > > > that allowing a hint weakens the strength of the language on > > > > ignoring Asserted-Identity from untrusted parties is purely > > > > philosophical in nature. I don't buy your argument. > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > > > ---- Original message ---- > > > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > > > >From: "Peterson, Jon" > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > > > >To: "'sip@ietf.org'" > > > > > > > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > > > Jennings and > > > > >myself about the short-term identity work, we have returned a > > > > few times to > > > > >the question of the infamous hint. This hint is, of course, a > > > > way that a > > > > >user agent (one that is not a member of the Trust Domain in > > > > the short-term > > > > >network asserted identity space) can provide a 'hint' to the > > > > intermediary > > > > >that will generate an Asserted-Identity indicating which > > > > identity among > > > > >several possibilities should be asserted. > > > > > > > > > >The need for this arises particularly from the 3G space, in > > > > which the > > > > >authentication process takes place independently of SIP and > > > > does not carry > > > > >this sort of personal identity information. It also assumes > > > > that the > > > > >operators of the intermediary in question are aware of > > > > several legitimate > > > > >identities which the user can elect to assert. > > > > > > > > > >It has been proposed on the mailing list and elsewhere that the > > > > >Asserted-Identity header should be re-used by user agents > > > > outside the Trust > > > > >Domain to provide such a hint. I see a number of reasons for > > > > and against > > > > >using the Asserted-Identity for this purpose. For example, > > > > today, there is a > > > > >requirement that asserted-identities which are transmitted > > > > from untrusted > > > > >sources should not be used in any way - this would seem to > > > > weaken that > > > > >requirement. There is also possibly some behavior that still > > > > needs to be > > > > >specified (like how an intermediary would reject or otherwise > > > > handle a > > > > >request with an inappropriate hint) that might be impactful > > > > to our choice. > > > > > > > > > >For the time being, however, I would like to suggest that > > > > providing the hint > > > > >is outside the scope of the current deliverables (the > > > > asserted-identity > > > > >requirements and mechanism drafts), which need to be > > > > complete, as we > > > > >discussed in the interim meeting, by the end of this month. I > > > > believe that a > > > > >separate draft should propose the use of Asserted-Identity or > > > > any other > > > > >header for this hint (in whatever timeframe is appropriate > > > > for 3G's > > > > >requirements), but that we should not speak to this matter in > > > > the current > > > > >asserted-identity deliverables. There is, as I see it, no > > > > dependency on > > > > >defining this hint before we dictate how intermediaries will > > > > assert > > > > >identities. > > > > > > > > > >Any comments on this plan? > > > > > > > > > >Jon Peterson > > > > >NeuStar, Inc. > > > > > > > > > >_______________________________________________ > > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >This list is for NEW development of the core SIP Protocol > > > > >Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 11:48:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13319 for ; Wed, 22 May 2002 11:48:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03645 for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:48:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01201; Wed, 22 May 2002 11:16:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01169 for ; Wed, 22 May 2002 11:16:38 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08474 for ; Wed, 22 May 2002 11:16:01 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MFFgB02254; Wed, 22 May 2002 17:15:42 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MFEtU29450; Wed, 22 May 2002 16:14:55 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 16:16:02 +0100 Message-ID: From: "Mark Watson" To: "'Miguel A. Garcia'" , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and hist ory requirements Date: Wed, 22 May 2002 16:15:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201A3.338ADED2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201A3.338ADED2 Content-Type: text/plain; charset="iso-8859-1" I don't think this header overlaps with Request History. This header contains information identifying the NETWORK that a call is FROM (or rather has passed through) whereas Request History records information about changes in the Request-URI which indicates the USER that a call is TO. I don't think the Request-URI would ever contain the identity of the vistited network, so this information would not be captured by Request History. Regards...Mark > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 22 May 2002 09:00 > To: Cullen Jennings > Cc: sip@ietf.org > Subject: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and > history requirements > > > Hi Cullen: > > I am aware that this P- header may be part of the history. > However, as you know, > the history is still in requirements phase, whereas 3GPP > Release 5 needs a > solution by June timeframe. > > Miguel > > Cullen Jennings wrote: > > > > It seems to me that the mechanism that meets the > requirements of the history > > requirements (draft-watson-sipping-req-history-01.txt) > would also solve this > > problem. Do we want two things to do the same thing? > > > > Cullen > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C201A3.338ADED2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and = history requirements

I don't think this header overlaps with Request = History.

This header contains information identifying the = NETWORK that a call is FROM (or rather has passed through) whereas = Request History records information about changes in the Request-URI = which indicates the USER that a call is TO.

I don't think the Request-URI would ever contain the = identity of the vistited network, so this information would not be = captured by Request History.

Regards...Mark

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eric= sson.com]
> Sent: 22 May 2002 09:00
> To: Cullen Jennings
> Cc: sip@ietf.org
> Subject: [Sip] Re: = draft-garcia-sip-visited-network-id-01.txt and
> history requirements
>
>
> Hi Cullen:
>
> I am aware that this P- header may be part of = the history.
> However, as you know,
> the history is still in requirements phase, = whereas 3GPP
> Release 5 needs a
> solution by June timeframe.
>
> Miguel
>
> Cullen Jennings wrote:
> >
> > It seems to me that the mechanism that = meets the
> requirements of the history
> > requirements = (draft-watson-sipping-req-history-01.txt)
> would also solve this
> > problem. Do we want two things to do the = same thing?
> >
> > Cullen
>
> --
> Miguel-Angel = Garcia           =           Oy LM Ericsson = AB
>          = ;            = ;            = ;       Jorvas, Finland
> mailto:Miguel.A.Garcia@eric= sson.com     Phone:  +358 9 299 = 3553
> mailto:Miguel.A.Garcia@piuha.n= et        Mobile: +358 40 = 5140002
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C201A3.338ADED2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 14:20:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23239 for ; Wed, 22 May 2002 14:20:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13237 for sip-archive@odin.ietf.org; Wed, 22 May 2002 14:20:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11256; Wed, 22 May 2002 13:48:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11193 for ; Wed, 22 May 2002 13:48:00 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21638 for ; Wed, 22 May 2002 13:47:38 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MHkWd24220; Wed, 22 May 2002 12:46:32 -0500 From: "Dean Willis" To: Cc: , , , Date: Wed, 22 May 2002 12:46:03 -0500 Message-ID: <004801c201b8$8b4f1060$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We started working group last call of the sip-dhcpv6 draft on May 2. There has been no negative veedback that I'm aware of, so let's call WGLC complete and request IETF Last Call. http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 14:24:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23493 for ; Wed, 22 May 2002 14:24:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13498 for sip-archive@odin.ietf.org; Wed, 22 May 2002 14:24:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11267; Wed, 22 May 2002 13:48:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11195 for ; Wed, 22 May 2002 13:48:00 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21639 for ; Wed, 22 May 2002 13:47:38 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MHkXd24223; Wed, 22 May 2002 12:46:33 -0500 From: "Dean Willis" To: , Cc: , , , , Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes) Date: Wed, 22 May 2002 12:46:03 -0500 Message-ID: <004901c201b8$8bdb98f0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED22@esebe013.NOE.Nokia.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Yes, the capability is there, but since the sender itself is > always responsible for enforcing the 1300 byte size > limitation of the MESSAGE request, this effectively negates > any need for such a UA in the network. > > I was saying that it would be nice if the actual enforcement > of the size limit could be relaxed, so that it could also be > up to such a store-and-forward UA in the network. However, > having said that I can't think of a simple way to make this happen. Ah. I think you're right. I'm not a fan of the 3261 wording on size being blaneltly applied to message -- I think it far more reasonable to make the forwarding deision on a per-sip-HOP basis, where the decision maker has a reasonable understanding of the dynamics of the next hop, and if we find a hop that has a smaller-than-message MTU and doesn't support congestion control we reject and say "send smaller" . . . There's much to be learned from Path-MTU discovery in TCP. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 15:26:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26796 for ; Wed, 22 May 2002 15:26:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17579 for sip-archive@odin.ietf.org; Wed, 22 May 2002 15:26:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16151; Wed, 22 May 2002 15:00:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15666 for ; Wed, 22 May 2002 14:54:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25136; Wed, 22 May 2002 14:54:11 -0400 (EDT) Message-Id: <200205221854.OAA25136@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 22 May 2002 14:54:11 -0400 Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider DHCPv6 Options for SIP Servers as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 15:53:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28102 for ; Wed, 22 May 2002 15:53:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19285 for sip-archive@odin.ietf.org; Wed, 22 May 2002 15:53:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18491; Wed, 22 May 2002 15:33:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17475 for ; Wed, 22 May 2002 15:21:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26566; Wed, 22 May 2002 15:20:57 -0400 (EDT) Message-Id: <200205221920.PAA26566@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 22 May 2002 15:20:57 -0400 Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider DHCPv6 Options for SIP Servers as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 17:16:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01525 for ; Wed, 22 May 2002 17:16:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24011 for sip-archive@odin.ietf.org; Wed, 22 May 2002 17:16:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21971; Wed, 22 May 2002 16:54:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21940 for ; Wed, 22 May 2002 16:54:31 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29928 for ; Wed, 22 May 2002 16:54:10 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MKrcd25497; Wed, 22 May 2002 15:53:38 -0500 From: "Dean Willis" To: Cc: , , , Date: Wed, 22 May 2002 15:53:08 -0500 Message-ID: <006401c201d2$adefa980$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There have been only "nit" comments on the last few revs of this draft, and I believe they're all accounted for. I think we can close the Expert Review of this individual informational draft. Shall we proceed? Allison, HOW shall we proceed? Remember, this is a "P-header" . . . Do we have internet-drafts process as a typical individual informational, or does this go through iesg-secretary? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 17:20:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02066 for ; Wed, 22 May 2002 17:20:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24173 for sip-archive@odin.ietf.org; Wed, 22 May 2002 17:20:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21773; Wed, 22 May 2002 16:49:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21742 for ; Wed, 22 May 2002 16:49:43 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29731; Wed, 22 May 2002 16:49:22 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MKnBd25467; Wed, 22 May 2002 15:49:11 -0500 From: "Dean Willis" To: Cc: Date: Wed, 22 May 2002 15:48:41 -0500 Message-ID: <006301c201d2$0edc8c50$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Revised: draft-willis-sip-svcrtdisco to -05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We have (I believe) incorporated all comments received during working group Expert Review into draft-willis-sip-svcrtdisco. The new version is posted at: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-05.htm l http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-05.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-05.xml -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 17:54:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03795 for ; Wed, 22 May 2002 17:54:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25947 for sip-archive@odin.ietf.org; Wed, 22 May 2002 17:54:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25275; Wed, 22 May 2002 17:34:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25243 for ; Wed, 22 May 2002 17:34:39 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02982 for ; Wed, 22 May 2002 17:34:18 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4MLahV23788; Wed, 22 May 2002 16:36:46 -0500 Subject: Re: [Sip] Last Call: The Refer Method to Proposed Standard From: Robert Sparks To: frank.derks@philips.com Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 22 May 2002 16:23:24 -0500 Message-Id: <1022102607.4632.26.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2002-05-22 at 05:41, frank.derks@philips.com wrote: > > - Section 6.1, 2nd paragraph, contains a rather strange sentence > > "For example, if the URI is a SIP URI indicating an INVITE > should be generated ..." > > I guess that it should be: > > "For example, if the URI is a SIP URI indicating an INVITE > an INVITE should be generated ..." No, try "For example, if the URI is a SIP URI that indicates an INVITE should be generated". See below > > - The use of colons after header names is not always consistent. > E.g. in 6.3.1's first bullet item "Call-ID". will fix > > - Section 7.1, first paragraph, states: > > "The details of this flow indicate this ..." > > I guess it should state: > > "The details of this flow indicate that this ..." correct. will add "that" > > Furthermore, the example that follows is not in line with the > text. The text states that there is no To: tag, but there is > one in the example. It states there is no To: tag in the REFER request (and there isn't). I think you are seeing the To: tags in the subsequent messages? > > - Section 8.1 talks about INVITE URIs. I am not sure whether this > type of URI (although I think I understand what is meant) is > defined anywhere. draft-rfc2543bis-09 captures this in its discussion of SIP URIs. An SIP INVITE URI is one which either has no ;method= URI parameter (defaulting to INVITE) or explicitly states ;method=INVITE. Alternatives might look like sip:rsparks@dynamicsoft.com;method=SUBSCRIBE > RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 22 19:40:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08168 for ; Wed, 22 May 2002 19:40:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00727 for sip-archive@odin.ietf.org; Wed, 22 May 2002 19:40:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27083; Wed, 22 May 2002 18:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27052 for ; Wed, 22 May 2002 18:21:55 -0400 (EDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05023 for ; Wed, 22 May 2002 18:21:33 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g4MMLpJ12643; Wed, 22 May 2002 18:21:51 -0400 Message-Id: <200205222221.g4MMLpJ12643@minotaur.nge.isi.edu> To: "Dean Willis" cc: sip@ietf.org, brian.rosen@marconi.com, rohan@cisco.com, jo@ipdialog.com, mankin@isi.edu Reply-To: mankin@isi.edu Subject: Re: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05? In-reply-to: Your message of Wed, 22 May 2002 15:53:08 -0500. <006401c201d2$adefa980$1d036e3f@TXDWILLIS2> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Wed, 22 May 2002 18:21:51 -0400 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean, HOW you should proceed with a P-Header Informational: My view is that you send mail to the transport ADs saying expert review concluded the i-d was publishable as an Info, and could TSV please get it on the IESG agenda. We can encode this in sipchange a little more specifically (now it says you write to IESG on this). Sometimes the draft will come to IESG and Expert Review from the RFC Editor, but in this case, we don't need it to come from RFC-Ed. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 23 00:41:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17801 for ; Thu, 23 May 2002 00:41:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA13628 for sip-archive@odin.ietf.org; Thu, 23 May 2002 00:41:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12606; Thu, 23 May 2002 00:16:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12577 for ; Thu, 23 May 2002 00:16:02 -0400 (EDT) Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17353 for ; Thu, 23 May 2002 00:15:40 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 23 May 2002 09:46:02 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B7EC56C@esuims01.esamsungumit.com> Thread-Topic: load generation by a UA. Thread-Index: AcICEIwRXZNKAWDGTyiW8UGoj/UtlA== From: "ShavinderPal Singh" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA12578 Subject: [Sip] load generation by a UA. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Is there a possibility by which I can use a SIP UA to generate a more than 50 calls simultaneously? ( Or some other way) I need it for testing purposes. All we need is some way to initiate 50 calls per second, just to flood a SIP proxy. If this is possible, I would also need some way that these 50 calls generated should be accepted at the other end by a "called party UA". so that the "called UA" send 2xx's and these 50 calls are established also. So, please suggest. If any body has done it, please tell me how can I achieve this? Thanks & Regards s Ph.: 091-124-6383474 (e 250) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 23 05:23:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01540 for ; Thu, 23 May 2002 05:23:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05201 for sip-archive@odin.ietf.org; Thu, 23 May 2002 05:24:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04159; Thu, 23 May 2002 05:03:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04113 for ; Thu, 23 May 2002 05:03:31 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01036 for ; Thu, 23 May 2002 05:03:12 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA11516; Thu, 23 May 2002 11:03:05 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA02205; Thu, 23 May 2002 11:03:18 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 11:03:15 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DD1@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Dean Willis'" , sip@ietf.org Cc: brian.rosen@marconi.com, rohan@cisco.com, jo@ipdialog.com, mankin@isi.edu Subject: RE: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-0 5? Date: Thu, 23 May 2002 11:03:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I hope this is not too late... Comments : - 6.1 "If the UA refreshes the registration, the stored value of the P-Service-Route is updated according to the P-Service-Route header field of the latest 200 OK response". What happens if the re-registration gets negative response, or if the registration state expires? Should the UA clear the stored service route or should it still keeps the one from the latest 200 OK response? - 6.3 3rd paragraph "A REGISTER operation performing a Fetching Bindings SHOULD return the same value of P-Service-Route as returned in the corresponding previous REGISTER response for the address-of-record in question". I thought the whole idea is to avoid storing lookup tables in the home network (point 3 of Section 2). I would assume that the registrar generates a service route for the registering UA (be it a real registration or just a fetch) dynamically, based on its knowledge about the topology of the home network at that moment. So it cannot guarantee that the P-Service-Route calculated now has the same value as the one returned in the previous REGISTER response. Nits: - 6.1 "The UA performs a register as usual . The register response..." => "The UA registers an address-of-record as usual. The REGISTER response..." - In the examples, 200 OK to REGISTER should have To tags according to RFC 3261. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 23 09:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09512 for ; Thu, 23 May 2002 09:32:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18413 for sip-archive@odin.ietf.org; Thu, 23 May 2002 09:32:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16768; Thu, 23 May 2002 09:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16737 for ; Thu, 23 May 2002 09:06:00 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08250 for ; Thu, 23 May 2002 09:05:31 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4ND7JT26370 for ; Thu, 23 May 2002 16:07:19 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 May 2002 16:05:44 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 23 May 2002 16:05:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 23 May 2002 16:05:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 23 May 2002 16:05:41 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791E3@esebe019.NOE.Nokia.com> Thread-Topic: Comments on Path-07 Thread-Index: AcICWorYCc6lCwQTT0yxT6D6RlRZYA== To: Cc: X-OriginalArrivalTime: 23 May 2002 13:05:42.0322 (UTC) FILETIME=[8B107920:01C2025A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA16738 Subject: [Sip] Comments on Path-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit In section 4.2, it is mentioned that if a Proxy requires that the registrar supports the path extension, it inserts a Require header, should the proxy remove the supported header in that case? it is kinda redundant. Section 4.4 assumes that the home proxy and registrar are always co-located. What about when they are not (not talking about 3GPP for now). So in your diagram, P3 is actually the home proxy for UA2. Should there be some text talking about how P3 should behave when it receives a request? It contact the registrar, gets the path headers converts them to route and finds itself in the top-most route-header. The same issue was brought up about record-route and route headers. A proxy should remove the first route header or (if its not smart enough to recognise its own route, should just send it to itself). Also in this section, it does not mention anything about the first route being a strict-route and that the R-URI needs to be re-written yet again. In section 5, (this is a little too picky) in your examples, the display names in the to-header and from-header have '@'. This is not allowed. You need to place quotes around them, or better still, change them to something meaningful. There are also few spelling mistakes and nits, do you want those? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 23 11:10:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13877 for ; Thu, 23 May 2002 11:10:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25677 for sip-archive@odin.ietf.org; Thu, 23 May 2002 11:10:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23114; Thu, 23 May 2002 10:46:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23083 for ; Thu, 23 May 2002 10:46:34 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12808 for ; Thu, 23 May 2002 10:46:14 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4NEk0d31431; Thu, 23 May 2002 09:46:00 -0500 Message-ID: <006a01c20268$95f71ed0$133fed0c@C1893415A> From: "Dean Willis" To: "Tan Ya-Ching ICM N PG U ID A 1" , Cc: , , , , "Bernhard Honeisen" References: <5B4D0C5BA65ECA46969C1419122317E6E74DD1@mchh161e> Subject: Re: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05? Date: Thu, 23 May 2002 09:46:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks, will incorporate. I believe the procedure we're going to use is that I'll send the revised draft to the transport ADs and ask them to get it onto the IESG agenda. This probably points to a slight need for clarification in the SIP Change Process draft. So, one more rev before IESG. I'll incorporate any reasonable feedback received by 1400 USCST today. -- Dean ----- Original Message ----- From: "Tan Ya-Ching ICM N PG U ID A 1" To: "'Dean Willis'" ; Cc: ; ; ; Sent: Thursday, May 23, 2002 4:03 AM Subject: RE: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05? > Hi, > > I hope this is not too late... > > Comments : > > - 6.1 "If the UA refreshes the registration, the stored value of the > P-Service-Route is updated according to the P-Service-Route header field of > the latest 200 OK response". What happens if the re-registration gets > negative response, or if the registration state expires? Should the UA clear > the stored service route or should it still keeps the one from the latest > 200 OK response? > > - 6.3 3rd paragraph "A REGISTER operation performing a Fetching Bindings > SHOULD return the same value of P-Service-Route as returned in the > corresponding previous REGISTER response for the address-of-record in > question". I thought the whole idea is to avoid storing lookup tables in the > home network (point 3 of Section 2). I would assume that the registrar > generates a service route for the registering UA (be it a real registration > or just a fetch) dynamically, based on its knowledge about the topology of > the home network at that moment. So it cannot guarantee that the > P-Service-Route calculated now has the same value as the one returned in the > previous REGISTER response. > > Nits: > > - 6.1 "The UA performs a register as usual . The register response..." => > "The UA registers an address-of-record as usual. The REGISTER response..." > > - In the examples, 200 OK to REGISTER should have To tags according to RFC > 3261. > > > Regards, > Ya-Ching > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 23 11:47:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15340 for ; Thu, 23 May 2002 11:47:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28696 for sip-archive@odin.ietf.org; Thu, 23 May 2002 11:47:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26550; Thu, 23 May 2002 11:21:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26521 for ; Thu, 23 May 2002 11:21:35 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14365 for ; Thu, 23 May 2002 11:21:13 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4NFKtd31742; Thu, 23 May 2002 10:20:55 -0500 Message-ID: <00e901c2026d$76c92620$133fed0c@C1893415A> From: "Dean Willis" To: , References: <2038BCC78B1AD641891A0D1AE133DBB77791E3@esebe019.NOE.Nokia.com> Date: Thu, 23 May 2002 10:21:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments on Path-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hisham wrote: > In section 4.2, it is mentioned that if a Proxy requires that the registrar supports the path extension, it inserts a Require header, should the proxy remove the supported header in that case? it is kinda redundant. No, because the registrar has to decide with to do if the extension is required by a proxy but not supported by the UA. The two obvious options are "reject" and "accept", although there might also be an "accept and notify somebody externally". This is addressed in 4.3, Procedures at the Registrar: "If a registrar receives a REGISTER request containing a Path header field and there is no indication of support for the extension in the UA (via A Supported header field), the registrar must rely on local policy in determining how to treat this request. The recommended policy is for the registrar to reject the request with a 420 "Bad Extension" response indicating the Path extension. This approach allows the UA to detect that an intermediate proxy has innapropriatelty added a Path header field. However, the Path mechanism should technically work in the absence of UA support (at some compromise to security), so some registrars may choose to support the extension in the absence of a Supported header field value in the request." > Section 4.4 assumes that the home proxy and registrar are always co-located. What about when they are not (not talking about 3GPP for now). > So in your diagram, P3 is actually the home proxy for UA2. Should there be some text talking about how P3 should behave when it receives a request? It contact the registrar, gets the path headers converts them to route and finds itself in the top-most route-header. > > The same issue was brought up about record-route and route headers. A proxy should remove the first route header or (if its not smart enough to recognise its own route, should just send it to itself). I could put in a clarification that, if not co-located with the registrar, the home proxy apply local topology knowledge to construct a return route from the stored Path vector. > > Also in this section, it does not mention anything about the first route being a strict-route and that the R-URI needs to be re-written yet again. Huh? > > In section 5, (this is a little too picky) in your examples, the display names in the to-header and from-header have '@'. This is not allowed. You need to place quotes around them, or better still, change them to something meaningful. I assume you mean section 4? Good catch. > There are also few spelling mistakes and nits, do you want those? Yes. That's why I asked for feedback and proofreading on the list. That's why we went through six versions during list discussion and working group last call. That's why we have a seperate IETF Last Call, which has now been going on for over a week. So please post any corrections you think are needed. Be explicit! The same applies to any document under working group review -- the authors will be appreciative, and our work will be of better quality, if all of you folks in the working group take the initiative to provide feedback. Of course, the authors are free to disagree with suggestions and discuss further. Thanks! -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 12:49:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17804 for ; Thu, 23 May 2002 12:49:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04356 for sip-archive@odin.ietf.org; Thu, 23 May 2002 12:50:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02296; Thu, 23 May 2002 12:19:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02265 for ; Thu, 23 May 2002 12:19:51 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16820 for ; Thu, 23 May 2002 12:19:26 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NGI5l17979; Thu, 23 May 2002 18:18:05 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NGHFW14021; Thu, 23 May 2002 17:17:15 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 17:18:28 +0100 Message-ID: From: "Mark Watson" To: "'Andrew Allen'" , "'David R. Oran'" , "'Peterson, Jon'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Thu, 23 May 2002 17:18:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20274.F267C406" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20274.F267C406 Content-Type: text/plain; charset="iso-8859-1" In the absence of further comment, can I make a *proposal* that we stick with Asserted-Identity for the hint and for the NAI itself, and that both are described in Cullen's draft ? Can we take this as AGREED if there are no comments by cob tomorrow ? (Guidance sought from chairs on this second question). Updated requirements draft to be submitted first thing tomorrow. Regards...Mark > -----Original Message----- > From: Andrew Allen [mailto:AAllen@dynamicsoft.com] > Sent: 22 May 2002 15:51 > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'; > 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > I agree with Dave. Lets put the hint in the > asserted-identity. Lets not have > two redundant headers that need to be transferred over the > Radio interface > unnecessarily. > > Andrew > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: Wednesday, May 22, 2002 9:45 AM > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > I suggest we allow the hint to be placed in the > > asserted-identity rather > > than in another header. A boundary proxy has to deal with a > UA putting > > in the header no matter what, if only to reject the request with an > > error. > > > > Once we have a full solution the issue of hints should go > > away as a side > > effect of having the "authorization server" functionality that Jon > > proposes. Better IMHO to have one obsolescent header to deal > > with rather > > than two, as well as avoiding the concomitant verbiage > describing the > > combinatoric cases involving two headers. > > > > Dave. > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > > Behalf Of Mark Watson > > > Sent: Wednesday, May 22, 2002 9:59 AM > > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > Importance: High > > > > > > > > > All, > > > > > > Can we have a *decision* asap as to whether the 'hint' uses > > > Asserted-Identity, or another header in another draft. > > > > > > I do not mind which. If the latter I will publish an I-D > > > describing it as soon as we have a decision, assuming it is > > > this week, since I'm away next week. > > > > > > If we do nothing, then I guess 3GPP will make up its own mind > > > how to do this, without supervision or advice from IETF, > > > which I think would be a bad thing. > > > > > > Regards...Mark > > > > > > > > > -----Original Message----- > > > From: Watson, Mark [MDN05:EP10:EXCH] > > > Sent: 20 May 2002 12:08 > > > To: 'Peterson, Jon'; 'Rohan Mahy' > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > The 'hint' was one of the three requirements that 3GPP > > > communicated to us in April. > > > It is a separate requirement from the Network Asserted > > > Identity itself, and so is not addressed in the requirements > > > draft, although I have been careful to point this out, and to > > > point out that it is a requirement nontheless, on several > > > occasions. I believe we need the 'hint' in the same timeframe > > > as the rest of the short term work. > > > Whether it is the same header/draft or a different > > > header/draft is another question on which I will only say > > > that we'd better make up our minds pretty quick. ...Mark > > > > > > > > > > -----Original Message----- > > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > > Sent: 19 May 2002 18:11 > > > > To: 'Rohan Mahy' > > > > Cc: sip@ietf.org > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > > > > > My argument was not that the proposed hint won't work - just > > > > that it isn't > > > > necessary to solve the problem at hand. It might not be the > > > > case that the > > > > problems with the hint stop at the philosophical point you > > > > mention below. > > > > What I asked in my last mail was not whether or not we needed > > > > a hint, but > > > > rather whether or not we should table that question until we > > > > resolve the > > > > other questions at hand. I just don't want to spend the > > > > cycles arguing about > > > > the hint given our very aggressive timetable - frankly, I > > > think that > > > > reaching consensus on this hint matter might push back our > > > > dates a bit. > > > > Let's investigate this hint stuff in June, but for now just > > > > figure out how a > > > > Trust Domain can manage an asserted identity in a message. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > > > Sent: Sunday, May 19, 2002 8:29 AM > > > > > To: Peterson, Jon > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > > > > Hi, > > > > > > > > > > The requirement for a hint is well understood, limited in > > > > > scope, and well motivated in the draft. Nobody has > identified > > > > > any technical reason why the hint won't work. Your argument > > > > > that allowing a hint weakens the strength of the language on > > > > > ignoring Asserted-Identity from untrusted parties is purely > > > > > philosophical in nature. I don't buy your argument. > > > > > > > > > > thanks, > > > > > -rohan > > > > > > > > > > > > > > > ---- Original message ---- > > > > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > > > > >From: "Peterson, Jon" > > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > > > > >To: "'sip@ietf.org'" > > > > > > > > > > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > > > > Jennings and > > > > > >myself about the short-term identity work, we have returned a > > > > > few times to > > > > > >the question of the infamous hint. This hint is, of course, a > > > > > way that a > > > > > >user agent (one that is not a member of the Trust Domain in > > > > > the short-term > > > > > >network asserted identity space) can provide a 'hint' to the > > > > > intermediary > > > > > >that will generate an Asserted-Identity indicating which > > > > > identity among > > > > > >several possibilities should be asserted. > > > > > > > > > > > >The need for this arises particularly from the 3G space, in > > > > > which the > > > > > >authentication process takes place independently of SIP and > > > > > does not carry > > > > > >this sort of personal identity information. It also assumes > > > > > that the > > > > > >operators of the intermediary in question are aware of > > > > > several legitimate > > > > > >identities which the user can elect to assert. > > > > > > > > > > > >It has been proposed on the mailing list and > elsewhere that the > > > > > >Asserted-Identity header should be re-used by user agents > > > > > outside the Trust > > > > > >Domain to provide such a hint. I see a number of reasons for > > > > > and against > > > > > >using the Asserted-Identity for this purpose. For example, > > > > > today, there is a > > > > > >requirement that asserted-identities which are transmitted > > > > > from untrusted > > > > > >sources should not be used in any way - this would seem to > > > > > weaken that > > > > > >requirement. There is also possibly some behavior that still > > > > > needs to be > > > > > >specified (like how an intermediary would reject or otherwise > > > > > handle a > > > > > >request with an inappropriate hint) that might be impactful > > > > > to our choice. > > > > > > > > > > > >For the time being, however, I would like to suggest that > > > > > providing the hint > > > > > >is outside the scope of the current deliverables (the > > > > > asserted-identity > > > > > >requirements and mechanism drafts), which need to be > > > > > complete, as we > > > > > >discussed in the interim meeting, by the end of this month. I > > > > > believe that a > > > > > >separate draft should propose the use of Asserted-Identity or > > > > > any other > > > > > >header for this hint (in whatever timeframe is appropriate > > > > > for 3G's > > > > > >requirements), but that we should not speak to this matter in > > > > > the current > > > > > >asserted-identity deliverables. There is, as I see it, no > > > > > dependency on > > > > > >defining this hint before we dictate how intermediaries will > > > > > assert > > > > > >identities. > > > > > > > > > > > >Any comments on this plan? > > > > > > > > > > > >Jon Peterson > > > > > >NeuStar, Inc. > > > > > > > > > > > >_______________________________________________ > > > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > >This list is for NEW development of the core SIP Protocol > > > > > >Use sip-implementors@cs.columbia.edu for questions on > > > current sip > > > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > ------_=_NextPart_001_01C20274.F267C406 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Asserted-Identity: How to 'hint'?

In the absence of further comment, can I make a = *proposal* that we stick with Asserted-Identity for the hint and for = the NAI itself, and that both are described in Cullen's draft = ?

Can we take this as AGREED if there are no comments = by cob tomorrow ? (Guidance sought from chairs on this second = question).

Updated requirements draft to be submitted first = thing tomorrow.

Regards...Mark

> -----Original Message-----
> From: Andrew Allen [mailto:AAllen@dynamicsoft.com= ]
> Sent: 22 May 2002 15:51
> To: 'David R. Oran'; Watson, Mark = [MDN05:EP10:EXCH]; 'Peterson, Jon';
> 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to = 'hint'?
>
>
>
> I agree with Dave. Lets put the hint in the =
> asserted-identity. Lets not have
> two redundant headers that need to be = transferred over the
> Radio interface
> unnecessarily.
>
> Andrew
>
> > -----Original Message-----
> > From: David R. Oran [mailto:oran@cisco.com]
> > Sent: Wednesday, May 22, 2002 9:45 = AM
> > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan = Mahy'; sip@ietf.org
> > Subject: RE: [Sip] Asserted-Identity: How = to 'hint'?
> >
> >
> > I suggest we allow the hint to be placed = in the
> > asserted-identity rather
> > than in another header. A boundary proxy = has to deal with a
> UA putting
> > in the header no matter what, if only to = reject the request with an
> > error.
> >
> > Once we have a full solution the issue of = hints should go
> > away as a side
> > effect of having the "authorization = server" functionality that Jon
> > proposes. Better IMHO to have one = obsolescent header to deal
> > with rather
> > than two, as well as avoiding the = concomitant verbiage
> describing the
> > combinatoric cases involving two = headers.
> >
> > Dave.
> >
> > > -----Original Message-----
> > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On =
> > > Behalf Of Mark Watson
> > > Sent: Wednesday, May 22, 2002 9:59 = AM
> > > To: 'Peterson, Jon'; 'Rohan Mahy'; = sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: = How to 'hint'?
> > > Importance: High
> > >
> > >
> > > All,
> > >
> > > Can we have a *decision* asap as to = whether the 'hint' uses
> > > Asserted-Identity, or another header = in another draft.
> > >
> > > I do not mind which. If the latter I = will publish an I-D
> > > describing it as soon as we have a = decision, assuming it is
> > > this week, since I'm away next = week.
> > >
> > > If we do nothing, then I guess 3GPP = will make up its own mind
> > > how to do this, without supervision = or advice from IETF,
> > > which I think would  be a bad = thing.
> > >
> > > Regards...Mark
> > >
> > >
> > > -----Original Message-----
> > > From: Watson, Mark [MDN05:EP10:EXCH] =
> > > Sent: 20 May 2002 12:08
> > > To: 'Peterson, Jon'; 'Rohan = Mahy'
> > > Cc: sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: = How to 'hint'?
> > >
> > >
> > > The 'hint' was one of the three = requirements that 3GPP
> > > communicated to us in April.
> > > It is a separate requirement from the = Network Asserted
> > > Identity itself, and so is not = addressed in the requirements
> > > draft, although I have been careful = to point this out, and to
> > > point out that it is a requirement = nontheless, on several
> > > occasions. I believe we need the = 'hint' in the same timeframe
> > > as the rest of the short term work. =
> > > Whether it is the same header/draft = or a different
> > > header/draft is another question on = which I will only say
> > > that we'd better make up our minds = pretty quick. ...Mark
> > >
> > >
> > > > -----Original = Message-----
> > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> > > > Sent: 19 May 2002 18:11
> > > > To: 'Rohan Mahy'
> > > > Cc: sip@ietf.org
> > > > Subject: RE: [Sip] = Asserted-Identity: How to 'hint'?
> > > >
> > > >
> > > >
> > > > My argument was not that the = proposed hint won't work - just
> > > > that it isn't
> > > > necessary to solve the problem = at hand. It might not be the
> > > > case that the
> > > > problems with the hint stop at = the philosophical point you
> > > > mention below.
> > > > What I asked in my last mail was = not whether or not we needed
> > > > a hint, but
> > > > rather whether or not we should = table that question until we
> > > > resolve the
> > > > other questions at hand. I just = don't want to spend the
> > > > cycles arguing about
> > > > the hint given our very = aggressive timetable - frankly, I
> > > think that
> > > > reaching consensus on this hint = matter might push back our
> > > > dates a bit.
> > > > Let's investigate this hint = stuff in June, but for now just
> > > > figure out how a
> > > > Trust Domain can manage an = asserted identity in a message.
> > > >
> > > > Jon Peterson
> > > > NeuStar, Inc.
> > > >
> > > > > -----Original = Message-----
> > > > > From: Rohan Mahy [mailto:rohan@cisco.com]
> > > > > Sent: Sunday, May 19, 2002 = 8:29 AM
> > > > > To: Peterson, Jon
> > > > > Cc: sip@ietf.org
> > > > > Subject: Re: [Sip] = Asserted-Identity: How to 'hint'?
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > The requirement for a hint = is well understood, limited in
> > > > > scope, and well motivated = in the draft.  Nobody has
> identified
> > > > > any technical reason why = the hint won't work.   Your argument
> > > > > that allowing a hint = weakens the strength of the language on
> > > > > ignoring Asserted-Identity = from untrusted parties is purely
> > > > > philosophical in = nature.  I don't buy your argument.
> > > > >
> > > > > thanks,
> > > > > -rohan
> > > > >
> > > > >
> > > > > ---- Original message = ----
> > > > > >Date: Fri, 17 May 2002 = 16:02:11 -0500
> > > > > >From: "Peterson, = Jon" <jon.peterson@neustar.biz> 
> > > > > >Subject: [Sip] = Asserted-Identity: How to 'hint'? 
> > > > > >To: = "'sip@ietf.org'" <sip@ietf.org>
> > > > > >
> > > > > >
> > > > > >In the course of the = discussion between Mark Watson, Cullen
> > > > > Jennings and
> > > > > >myself about the = short-term identity work, we have returned a
> > > > > few times to
> > > > > >the question of the = infamous hint. This hint is, of course, a
> > > > > way that a
> > > > > >user agent (one that is = not a member of the Trust Domain in
> > > > > the short-term
> > > > > >network asserted = identity space) can provide a 'hint' to the
> > > > > intermediary
> > > > > >that will generate an = Asserted-Identity indicating which
> > > > > identity among
> > > > > >several possibilities = should be asserted.
> > > > > >
> > > > > >The need for this = arises particularly from the 3G space, in
> > > > > which the
> > > > > >authentication process = takes place independently of SIP and
> > > > > does not carry
> > > > > >this sort of personal = identity information. It also assumes
> > > > > that the
> > > > > >operators of the = intermediary in question are aware of
> > > > > several legitimate
> > > > > >identities which the = user can elect to assert.
> > > > > >
> > > > > >It has been proposed on = the mailing list and
> elsewhere that the
> > > > > >Asserted-Identity = header should be re-used by user agents
> > > > > outside the Trust
> > > > > >Domain to provide such = a hint. I see a number of reasons for
> > > > > and against
> > > > > >using the = Asserted-Identity for this purpose. For example,
> > > > > today, there is a
> > > > > >requirement that = asserted-identities which are transmitted
> > > > > from untrusted
> > > > > >sources should not be = used in any way - this would seem to
> > > > > weaken that
> > > > > >requirement. There is = also possibly some behavior that still
> > > > > needs to be
> > > > > >specified (like how an = intermediary would reject or otherwise
> > > > > handle a
> > > > > >request with an = inappropriate hint) that might be impactful
> > > > > to our choice.
> > > > > >
> > > > > >For the time being, = however, I would like to suggest that
> > > > > providing the hint
> > > > > >is outside the scope of = the current deliverables (the
> > > > > asserted-identity
> > > > > >requirements and = mechanism drafts), which need to be
> > > > > complete, as we
> > > > > >discussed in the = interim meeting, by the end of this month. I
> > > > > believe that a
> > > > > >separate draft should = propose the use of Asserted-Identity or
> > > > > any other
> > > > > >header for this hint = (in whatever timeframe is appropriate
> > > > > for 3G's
> > > > > >requirements), but that = we should not speak to this matter in
> > > > > the current
> > > > > >asserted-identity = deliverables. There is, as I see it, no
> > > > > dependency on
> > > > > >defining this hint = before we dictate how intermediaries will
> > > > > assert
> > > > > >identities.
> > > > > >
> > > > > >Any comments on this = plan?
> > > > > >
> > > > > >Jon Peterson
> > > > > >NeuStar, Inc.
> > > > > >
> > > > > = >_______________________________________________
> > > > > >Sip mailing list  = https://www1.ietf.org/mailman/listinfo/sip =
> > > > > >This list is for NEW = development of the core SIP Protocol
> > > > > >Use = sip-implementors@cs.columbia.edu for questions on
> > > current sip
> > > > > >Use sipping@ietf.org = 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 = sip-implementors@cs.columbia.edu for questions on
> current sip
> > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu = for questions on current sip
> > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for = questions on current sip
> > Use sipping@ietf.org for new developments = on the application of sip
> >
>

------_=_NextPart_001_01C20274.F267C406-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 14:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21614 for ; Thu, 23 May 2002 14:19:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09902 for sip-archive@odin.ietf.org; Thu, 23 May 2002 14:19:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08248; Thu, 23 May 2002 13:52:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08174 for ; Thu, 23 May 2002 13:52:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20284; Thu, 23 May 2002 13:52:09 -0400 (EDT) Message-Id: <200205231752.NAA20284@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Thu, 23 May 2002 13:52:09 -0400 Subject: [Sip] Document Action: HTTP Digest Authentication Using AKA to Informational Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved the Internet-Draft 'HTTP Digest Authentication Using AKA' as an Informational RFC. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 15:41:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24073 for ; Thu, 23 May 2002 15:41:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14073 for sip-archive@odin.ietf.org; Thu, 23 May 2002 15:41:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12550; Thu, 23 May 2002 15:13:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12519 for ; Thu, 23 May 2002 15:13:32 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23538 for ; Thu, 23 May 2002 15:13:11 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NJCZd00734; Thu, 23 May 2002 14:12:35 -0500 From: "Dean Willis" To: "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Peterson, Jon'" , "'Rohan Mahy'" , Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Thu, 23 May 2002 14:12:04 -0500 Message-ID: <006e01c2028d$b9e4a950$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark asked: ------- In the absence of further comment, can I make a *proposal* that we stick with Asserted-Identity for the hint and for the NAI itself, and that both are described in Cullen's draft ? Can we take this as AGREED if there are no comments by cob tomorrow ? (Guidance sought from chairs on this second question). Updated requirements draft to be submitted first thing tomorrow. -------- I support your proposal and AGREE with the closing plan. In other words, an asserted-identity with nothing to back up the assertion is just a statement of preference . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 17:47:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28599 for ; Thu, 23 May 2002 17:47:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21228 for sip-archive@odin.ietf.org; Thu, 23 May 2002 17:47:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20034; Thu, 23 May 2002 17:21:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20003 for ; Thu, 23 May 2002 17:21:16 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27781 for ; Thu, 23 May 2002 17:20:55 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NLJnd01468; Thu, 23 May 2002 16:19:50 -0500 From: "Dean Willis" To: "'Tan Ya-Ching ICM N PG U ID A 1'" , Cc: , , , Subject: RE: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05? Date: Thu, 23 May 2002 16:19:17 -0500 Message-ID: <007b01c2029f$80aa3850$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E6E74DD1@mchh161e> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ya-Ching wrote: > - 6.1 "If the UA refreshes the registration, the stored value > of the P-Service-Route is updated according to the > P-Service-Route header field of the latest 200 OK response". > What happens if the re-registration gets negative response, > or if the registration state expires? Should the UA clear the > stored service route or should it still keeps the one from > the latest 200 OK response? I suspect that the UA clears the stored route in a negative response case. It's kind of an open question what to do in the event of an expiration. We can add some text to this point. > > - 6.3 3rd paragraph "A REGISTER operation performing a > Fetching Bindings SHOULD return the same value of > P-Service-Route as returned in the corresponding previous > REGISTER response for the address-of-record in question". I > thought the whole idea is to avoid storing lookup tables in > the home network (point 3 of Section 2). I would assume that > the registrar generates a service route for the registering > UA (be it a real registration or just a fetch) dynamically, > based on its knowledge about the topology of the home network > at that moment. So it cannot guarantee that the > P-Service-Route calculated now has the same value as the one > returned in the previous REGISTER response. That's a really good point. A lot depends on the manner in which the P-Service-Route is constructed. It may in some cases be constructed from Path data. So I'd say that the registrar returns the "current" service route, whatever that is. I will so annotate. > > Nits: > > - 6.1 "The UA performs a register as usual . The register > response..." => "The UA registers an address-of-record as > usual. The REGISTER response..." Yep. > - In the examples, 200 OK to REGISTER should have To tags > according to RFC 3261. Yep. Of course, 3261 is inconsistent in its use of To tags. I think the whole tagging/branchid thing was a bad class of ideas, but I promised not to suggest we deprecate forking any more. . . Thanks for the feedback. It looks like one more rev . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 18:34:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29603 for ; Thu, 23 May 2002 18:34:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23708 for sip-archive@odin.ietf.org; Thu, 23 May 2002 18:34:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22559; Thu, 23 May 2002 18:11:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22527 for ; Thu, 23 May 2002 18:11:12 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29103 for ; Thu, 23 May 2002 18:10:51 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NMAq812703 for ; Thu, 23 May 2002 17:10:52 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 15:10:30 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D202AF8B64@zsc3c030.us.nortel.com> From: "Mo Zonoun" To: "'sip@ietf.org'" Date: Thu, 23 May 2002 15:11:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C202A6.B9B610FE" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C202A6.B9B610FE Content-Type: text/plain Unsubscribe qpMQ mzonoun@nortelnetworks.com ------_=_NextPart_001_01C202A6.B9B610FE Content-Type: text/html

Unsubscribe  qpMQ mzonoun@nortelnetworks.com

------_=_NextPart_001_01C202A6.B9B610FE-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 19:49:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00836 for ; Thu, 23 May 2002 19:49:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26269 for sip-archive@odin.ietf.org; Thu, 23 May 2002 19:49:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25338; Thu, 23 May 2002 19:26:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25299 for ; Thu, 23 May 2002 19:26:24 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00331 for ; Thu, 23 May 2002 19:26:02 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NNPXd02231; Thu, 23 May 2002 18:25:33 -0500 From: "Dean Willis" To: Cc: , , , "Miguel Garcia" Date: Thu, 23 May 2002 18:25:01 -0500 Message-ID: <008a01c202b1$10a12b60$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Poll: expert review of draft-garcia-sip-visited-network-id Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit As you may recall, we're providing expert review of draft-garcia-sip-visited-network-id. What's the feeling here? I THINK we have a general consensus that this work does not conflict with anything. Do we have a consensus that this is draft is "good enough" to work as an informational P-header? Or do we reject it, or require further consideration? Inquiring minds want to know . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 23 19:51:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00893 for ; Thu, 23 May 2002 19:51:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26317 for sip-archive@odin.ietf.org; Thu, 23 May 2002 19:52:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25363; Thu, 23 May 2002 19:26:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25307 for ; Thu, 23 May 2002 19:26:25 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00336 for ; Thu, 23 May 2002 19:26:04 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NNPYd02234; Thu, 23 May 2002 18:25:34 -0500 From: "Dean Willis" To: Cc: , , , "Miguel Garcia" Date: Thu, 23 May 2002 18:25:01 -0500 Message-ID: <008b01c202b1$10dfbb00$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Poll -- expert review of draft-garcia-sip-called-party-id Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit So team, what's the conclusion, if any, on draft-garcia-sip-called-party-id? Do we have a consensus for, consensus against, or require further consideration? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 03:08:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19065 for ; Fri, 24 May 2002 03:08:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22826 for sip-archive@odin.ietf.org; Fri, 24 May 2002 03:08:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21856; Fri, 24 May 2002 02:50:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21826 for ; Fri, 24 May 2002 02:50:29 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18858 for ; Fri, 24 May 2002 02:50:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4O6opk15212 for ; Fri, 24 May 2002 09:50:51 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 May 2002 09:50:28 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 May 2002 09:50:28 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 May 2002 09:50:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 24 May 2002 09:50:27 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791E6@esebe019.NOE.Nokia.com> Thread-Topic: Comments on Path-07 Thread-Index: AcICbXGCpwSgLe+tSTqEUKFN7HOCYAAflTkg To: , X-OriginalArrivalTime: 24 May 2002 06:50:28.0237 (UTC) FILETIME=[4A097BD0:01C202EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA21827 Subject: [Sip] RE: Comments on Path-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, May 23, 2002 6:21 PM > To: Khartabil Hisham (NMP/Helsinki); sip@ietf.org > Subject: Re: Comments on Path-07 > > > Hisham wrote: > > Also in this section, it does not mention anything about the first > route being a strict-route and that the R-URI needs to be > re-written yet > again. > > Huh? > Ok, I missed paragraph in section 4.3 "Note that the inserted Path header field values conform to the syntax of a Route element as defined in [1]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [1]" Perhaps Section 4.2 is more appropriate for this (or in both sections). > > There are also few spelling mistakes and nits, do you want those? > > Yes. That's why I asked for feedback and proofreading on the list. > That's why we went through six versions during list discussion and > working group last call. That's why we have a seperate IETF Last Call, > which has now been going on for over a week. > > So please post any corrections you think are needed. Be explicit! The > same applies to any document under working group review -- the authors > will be appreciative, and our work will be of better quality, > if all of > you folks in the working group take the initiative to provide > feedback. > Of course, the authors are free to disagree with suggestions > and discuss > further. Ok then. Here are a few: - Section 1 first sentence "p roxies" should be "proxies" - Section 1 second paragraph "Likewise, all requests between REGISTRAR and UAa must also traverse P1, P2, and P3 before reaching UA." should be "Likewise, all requests between REGISTRAR and UA1 ^ must also traverse P1, P2, and P3 before reaching UA1." ^ - Section 1 last paragraph, second last line "to to" - Section 3 just above table 3 "Support for the Path header field may be indicated by a UA by including the option-tag "path" in a Supported header field." Should that be a "MAY"? - Section 4.4 last paragraph last line "poilicy" should be "policy" That's all. Regards, Hisham > > Thanks! > > -- > Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 03:24:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19240 for ; Fri, 24 May 2002 03:24:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23134 for sip-archive@odin.ietf.org; Fri, 24 May 2002 03:24:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22932; Fri, 24 May 2002 03:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22896 for ; Fri, 24 May 2002 03:13:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19137 for ; Fri, 24 May 2002 03:12:43 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4O7CMuF024375; Fri, 24 May 2002 00:12:22 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACZ51096; Fri, 24 May 2002 00:12:44 -0700 (PDT) From: "Cullen Jennings" To: "Miguel Garcia" , Date: Fri, 24 May 2002 00:13:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <008b01c202b1$10dfbb00$1d036e3f@TXDWILLIS2> Content-Transfer-Encoding: 7bit Subject: [Sip] draft-garcia-sip-called-party-id and history Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I see this draft as dealing with the issue of a proxy retargeting sip:user1-business@example.com to sip:user1@192.0.2.4 As a proposed change, how would you feel about changing the syntax from P-Called-Party-ID to something like P-History: sip:user1-business@example.com or P-History: sip:user1-business@example.com;reason=SIP;cause=302;text="registrar retargeted" I understand that 3G wishes to resolve this by June, however, I think that if we wanted to, we could do a P-History just as fast as a P-Called-Party-ID. The existence of a non compatible Called-Party will complicate getting History done. If the consensus is not to ever do History, people should express on the sipping list that the requirements are bogus. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 04:46:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20474 for ; Fri, 24 May 2002 04:46:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26942 for sip-archive@odin.ietf.org; Fri, 24 May 2002 04:46:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25848; Fri, 24 May 2002 04:23:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25820 for ; Fri, 24 May 2002 04:23:11 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20100 for ; Fri, 24 May 2002 04:22:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4O8NAmG018028; Fri, 24 May 2002 10:23:10 +0200 (MEST) Received: from ericsson.com (ppp10.lmf.ericsson.se [131.160.102.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4O8N89q011409; Fri, 24 May 2002 11:23:08 +0300 (EET DST) Message-ID: <3CEDF86D.E97B2C7D@ericsson.com> Date: Fri, 24 May 2002 11:23:09 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-garcia-sip-called-party-id and history Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cullen: We are moving into dangerous grounds, because you want to solve the history issue. The aim of this header is much more narrower in scope. We don't want to solve the history problem. We just want to send an indication to the UAS with one out of many identities that the INVITE was sent. You claim that a non compatible Called-Party will complicate getting history done, and I disagree with this point. In the first proposal you make, the P-History would look like: P-History: sip:user1-business@example.com which is exactly the same as: P-Called-Party-ID: sip:user1-business@example.com with the exception that the P-Called-Party-ID contains the semantics of the header, why P-History is broader and we need to include something else to give a hint to the UAS. I suspect that is the reason why you have your second proposal, which is: P-History: sip:user1-business@example.com;reason=SIP;cause=302;text="registrar retargeted" And this is the problem to me. We would need to define the reason, cause, text, etc, for all the situations where a proxy retargets a URI. Isn't this the whole History header that still is requirements phase? I don't see any incompatibility problem if we have a P-Called-Party-ID with a clear and simple semantics, at the same time that we work towards a broad History, that has to include the requirements of a P-Called-Party-ID, and will eventually take over the P-Called-Party-ID. /Miguel > Cullen Jennings wrote: > > I see this draft as dealing with the issue of a proxy retargeting > sip:user1-business@example.com to sip:user1@192.0.2.4 > > As a proposed change, how would you feel about changing the syntax from > P-Called-Party-ID to something like > > P-History: sip:user1-business@example.com > or > P-History: > sip:user1-business@example.com;reason=SIP;cause=302;text="registrar > retargeted" > > I understand that 3G wishes to resolve this by June, however, I think that > if we wanted to, we could do a P-History just as fast as a > P-Called-Party-ID. The existence of a non compatible Called-Party will > complicate getting History done. If the consensus is not to ever do History, > people should express on the sipping list that the requirements are bogus. > > Cullen -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 07:20:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23257 for ; Fri, 24 May 2002 07:20:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03278 for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:20:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01998; Fri, 24 May 2002 06:49:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01969 for ; Fri, 24 May 2002 06:49:38 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22672 for ; Fri, 24 May 2002 06:49:17 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4OAnaH25885 for ; Fri, 24 May 2002 06:49:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 11:49:35 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0051B49D2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Mark Watson , "'Peterson, Jon'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Fri, 24 May 2002 11:49:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org With a 3GPP hat on, just to confirm that the "hint" is as much part of the 3GPP requirements as is the Asserted-Identity, and both are absolutely essential to the release we are trying to freeze now. Moreover, things are now running pretty close to the wire in terms of getting this in. Can we have a decision on this as soon as possible, and then get the revised drafts out for discussion on the SIP list, so we can get a clear idea of what the SIP working group view is. I do not think we really mind what the decision is; is there an IETF equivalent of tossing a coin? Within 3GPP we have got about as far as we get on this issue without going away and making it up for ourselves. And before anybody says yet again that this is a 3GPP only solution, I would point out that at both the SIP/SIPPING ad-hoc and in Las Vegas and on this list, the wireline operator's have been shouting for it just as much. Keith > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: 22 May 2002 14:59 > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > Importance: High > > > All, > > Can we have a *decision* asap as to whether the 'hint' uses > Asserted-Identity, or another header in another draft. > > I do not mind which. If the latter I will publish an I-D > describing it as > soon as we have a decision, assuming it is this week, since > I'm away next > week. > > If we do nothing, then I guess 3GPP will make up its own mind > how to do > this, without supervision or advice from IETF, which I think > would be a bad > thing. > > Regards...Mark > > > -----Original Message----- > From: Watson, Mark [MDN05:EP10:EXCH] > Sent: 20 May 2002 12:08 > To: 'Peterson, Jon'; 'Rohan Mahy' > Cc: sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > The 'hint' was one of the three requirements that 3GPP > communicated to us in > April. > It is a separate requirement from the Network Asserted > Identity itself, and > so is not addressed in the requirements draft, although I > have been careful > to point this out, and to point out that it is a requirement > nontheless, on > several occasions. > I believe we need the 'hint' in the same timeframe as the > rest of the short > term work. > Whether it is the same header/draft or a different > header/draft is another > question on which I will only say that we'd better make up > our minds pretty > quick. > ...Mark > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: 19 May 2002 18:11 > > To: 'Rohan Mahy' > > Cc: sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > My argument was not that the proposed hint won't work - just > > that it isn't > > necessary to solve the problem at hand. It might not be the > > case that the > > problems with the hint stop at the philosophical point you > > mention below. > > What I asked in my last mail was not whether or not we needed > > a hint, but > > rather whether or not we should table that question until we > > resolve the > > other questions at hand. I just don't want to spend the > > cycles arguing about > > the hint given our very aggressive timetable - frankly, I > think that > > reaching consensus on this hint matter might push back our > > dates a bit. > > Let's investigate this hint stuff in June, but for now just > > figure out how a > > Trust Domain can manage an asserted identity in a message. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, May 19, 2002 8:29 AM > > > To: Peterson, Jon > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > Hi, > > > > > > The requirement for a hint is well understood, limited in > > > scope, and well motivated in the draft. Nobody has identified > > > any technical reason why the hint won't work. Your argument > > > that allowing a hint weakens the strength of the language on > > > ignoring Asserted-Identity from untrusted parties is purely > > > philosophical in nature. I don't buy your argument. > > > > > > thanks, > > > -rohan > > > > > > > > > ---- Original message ---- > > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > > >From: "Peterson, Jon" > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > > >To: "'sip@ietf.org'" > > > > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > > Jennings and > > > >myself about the short-term identity work, we have returned a > > > few times to > > > >the question of the infamous hint. This hint is, of course, a > > > way that a > > > >user agent (one that is not a member of the Trust Domain in > > > the short-term > > > >network asserted identity space) can provide a 'hint' to the > > > intermediary > > > >that will generate an Asserted-Identity indicating which > > > identity among > > > >several possibilities should be asserted. > > > > > > > >The need for this arises particularly from the 3G space, in > > > which the > > > >authentication process takes place independently of SIP and > > > does not carry > > > >this sort of personal identity information. It also assumes > > > that the > > > >operators of the intermediary in question are aware of > > > several legitimate > > > >identities which the user can elect to assert. > > > > > > > >It has been proposed on the mailing list and elsewhere that the > > > >Asserted-Identity header should be re-used by user agents > > > outside the Trust > > > >Domain to provide such a hint. I see a number of reasons for > > > and against > > > >using the Asserted-Identity for this purpose. For example, > > > today, there is a > > > >requirement that asserted-identities which are transmitted > > > from untrusted > > > >sources should not be used in any way - this would seem to > > > weaken that > > > >requirement. There is also possibly some behavior that still > > > needs to be > > > >specified (like how an intermediary would reject or otherwise > > > handle a > > > >request with an inappropriate hint) that might be impactful > > > to our choice. > > > > > > > >For the time being, however, I would like to suggest that > > > providing the hint > > > >is outside the scope of the current deliverables (the > > > asserted-identity > > > >requirements and mechanism drafts), which need to be > > > complete, as we > > > >discussed in the interim meeting, by the end of this month. I > > > believe that a > > > >separate draft should propose the use of Asserted-Identity or > > > any other > > > >header for this hint (in whatever timeframe is appropriate > > > for 3G's > > > >requirements), but that we should not speak to this matter in > > > the current > > > >asserted-identity deliverables. There is, as I see it, no > > > dependency on > > > >defining this hint before we dictate how intermediaries will > > > assert > > > >identities. > > > > > > > >Any comments on this plan? > > > > > > > >Jon Peterson > > > >NeuStar, Inc. > > > > > > > >_______________________________________________ > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >This list is for NEW development of the core SIP Protocol > > > >Use sip-implementors@cs.columbia.edu for questions on > current sip > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 07:41:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24017 for ; Fri, 24 May 2002 07:41:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04632 for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:41:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03488; Fri, 24 May 2002 07:22:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03401 for ; Fri, 24 May 2002 07:22:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23484; Fri, 24 May 2002 07:21:57 -0400 (EDT) Message-Id: <200205241121.HAA23484@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 May 2002 07:21:57 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 Referred-By Mechanism Author(s) : R. Sparks Filename : draft-ietf-sip-referredby-00.txt Pages : 23 Date : 23-May-02 The SIP REFER method [2] provides a mechanism where one party (the referror) provides a second party (the referree) with an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referror to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referror and the URI to which the referror referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-00.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-ietf-sip-referredby-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-referredby-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020523132730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-referredby-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-referredby-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 07:41:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24040 for ; Fri, 24 May 2002 07:41:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04654 for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:41:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03460; Fri, 24 May 2002 07:22:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03348 for ; Fri, 24 May 2002 07:22:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23467; Fri, 24 May 2002 07:21:52 -0400 (EDT) Message-Id: <200205241121.HAA23467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 May 2002 07:21:52 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-call-auth-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP Extensions for Media Authorization Author(s) : W. Marshall, F. Andreasen, D. Evans Filename : draft-ietf-sip-call-auth-06.txt Pages : 16 Date : 23-May-02 This document describes the need for QoS and media authorization and defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-06.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-ietf-sip-call-auth-06.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-call-auth-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020523132720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-auth-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-auth-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132720.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 07:42:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24084 for ; Fri, 24 May 2002 07:42:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04695 for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:42:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04285; Fri, 24 May 2002 07:32:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03541 for ; Fri, 24 May 2002 07:24:22 -0400 (EDT) Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23542 for ; Fri, 24 May 2002 07:24:01 -0400 (EDT) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 24 May 2002 11:17:28 UT Received: from wellx.com (SIP [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id JR6DTHPD; Fri, 24 May 2002 13:18:18 +0200 Message-ID: <3CEE254A.FAB45662@wellx.com> Date: Fri, 24 May 2002 13:34:34 +0200 From: Aymeric MOIZARD Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 CC: sip@ietf.org References: <475FF955A05DD411980D00508B6D5FB0051B49D2@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Matching request for server transaction Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Reading the 17.23 section about the rules used to match a request, I found a possible issue. The spec says: [we must check the via branch, via sent-by parameter] "and in the case of a CANCEL request, the method of the request that created the transaction was also CANCEL. In the case where a pending CANCEL is going on and we are receiving an retransmission of INVITE. The INVITE will contains the same via branch and sent-by and is not a CANCEL, so it will match the CANCEL transaction according the rules defined. (the test expect us to test the method only for CANCEL request!) I am true if I say that the cseq method must always be compared and not only for CSeq? Aymeric _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 07:42:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24104 for ; Fri, 24 May 2002 07:42:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04709 for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:42:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03336; Fri, 24 May 2002 07:21:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03305 for ; Fri, 24 May 2002 07:21:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23370; Fri, 24 May 2002 07:21:22 -0400 (EDT) Message-Id: <200205241121.HAA23370@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 May 2002 07:21:22 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Extension Header Field for Service Route Discovery in Private Networks Author(s) : D. Willis, B. Hoeneisen Filename : draft-willis-sip-scvrtdisco-05.txt Pages : 15 Date : 23-May-02 This document proposes a private SIP extension header used in conjunction with responses to REGISTER messages to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-05.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-willis-sip-scvrtdisco-05.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-scvrtdisco-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020523132623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-scvrtdisco-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-scvrtdisco-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132623.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 08:22:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25278 for ; Fri, 24 May 2002 08:22:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06409 for sip-archive@odin.ietf.org; Fri, 24 May 2002 08:22:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05957; Fri, 24 May 2002 08:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05908 for ; Fri, 24 May 2002 08:03:34 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24627 for ; Fri, 24 May 2002 08:03:13 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4OC2RI13787; Fri, 24 May 2002 07:02:27 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 07:02:22 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> From: "Peterson, Jon" To: "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Fri, 24 May 2002 07:02:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2031A.DBB8F580" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2031A.DBB8F580 Content-Type: text/plain; charset="iso-8859-1" Since I've never been one to fly in the face of public opinion (cough), I'll agree (at least in this case) that we should go with majority rule and use the Asserted-Identity header for the 'hint'. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, May 23, 2002 9:18 AM To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In the absence of further comment, can I make a *proposal* that we stick with Asserted-Identity for the hint and for the NAI itself, and that both are described in Cullen's draft ? Can we take this as AGREED if there are no comments by cob tomorrow ? (Guidance sought from chairs on this second question). Updated requirements draft to be submitted first thing tomorrow. Regards...Mark > -----Original Message----- > From: Andrew Allen [ mailto:AAllen@dynamicsoft.com ] > Sent: 22 May 2002 15:51 > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'; > 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > I agree with Dave. Lets put the hint in the > asserted-identity. Lets not have > two redundant headers that need to be transferred over the > Radio interface > unnecessarily. > > Andrew > > > -----Original Message----- > > From: David R. Oran [ mailto:oran@cisco.com ] > > Sent: Wednesday, May 22, 2002 9:45 AM > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > I suggest we allow the hint to be placed in the > > asserted-identity rather > > than in another header. A boundary proxy has to deal with a > UA putting > > in the header no matter what, if only to reject the request with an > > error. > > > > Once we have a full solution the issue of hints should go > > away as a side > > effect of having the "authorization server" functionality that Jon > > proposes. Better IMHO to have one obsolescent header to deal > > with rather > > than two, as well as avoiding the concomitant verbiage > describing the > > combinatoric cases involving two headers. > > > > Dave. > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org ] On > > > Behalf Of Mark Watson > > > Sent: Wednesday, May 22, 2002 9:59 AM > > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > Importance: High > > > > > > > > > All, > > > > > > Can we have a *decision* asap as to whether the 'hint' uses > > > Asserted-Identity, or another header in another draft. > > > > > > I do not mind which. If the latter I will publish an I-D > > > describing it as soon as we have a decision, assuming it is > > > this week, since I'm away next week. > > > > > > If we do nothing, then I guess 3GPP will make up its own mind > > > how to do this, without supervision or advice from IETF, > > > which I think would be a bad thing. > > > > > > Regards...Mark > > > > > > > > > -----Original Message----- > > > From: Watson, Mark [MDN05:EP10:EXCH] > > > Sent: 20 May 2002 12:08 > > > To: 'Peterson, Jon'; 'Rohan Mahy' > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > The 'hint' was one of the three requirements that 3GPP > > > communicated to us in April. > > > It is a separate requirement from the Network Asserted > > > Identity itself, and so is not addressed in the requirements > > > draft, although I have been careful to point this out, and to > > > point out that it is a requirement nontheless, on several > > > occasions. I believe we need the 'hint' in the same timeframe > > > as the rest of the short term work. > > > Whether it is the same header/draft or a different > > > header/draft is another question on which I will only say > > > that we'd better make up our minds pretty quick. ...Mark > > > > > > > > > > -----Original Message----- > > > > From: Peterson, Jon [ mailto:jon.peterson@neustar.biz ] > > > > Sent: 19 May 2002 18:11 > > > > To: 'Rohan Mahy' > > > > Cc: sip@ietf.org > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > > > > > My argument was not that the proposed hint won't work - just > > > > that it isn't > > > > necessary to solve the problem at hand. It might not be the > > > > case that the > > > > problems with the hint stop at the philosophical point you > > > > mention below. > > > > What I asked in my last mail was not whether or not we needed > > > > a hint, but > > > > rather whether or not we should table that question until we > > > > resolve the > > > > other questions at hand. I just don't want to spend the > > > > cycles arguing about > > > > the hint given our very aggressive timetable - frankly, I > > > think that > > > > reaching consensus on this hint matter might push back our > > > > dates a bit. > > > > Let's investigate this hint stuff in June, but for now just > > > > figure out how a > > > > Trust Domain can manage an asserted identity in a message. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Rohan Mahy [ mailto:rohan@cisco.com ] > > > > > Sent: Sunday, May 19, 2002 8:29 AM > > > > > To: Peterson, Jon > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > > > > Hi, > > > > > > > > > > The requirement for a hint is well understood, limited in > > > > > scope, and well motivated in the draft. Nobody has > identified > > > > > any technical reason why the hint won't work. Your argument > > > > > that allowing a hint weakens the strength of the language on > > > > > ignoring Asserted-Identity from untrusted parties is purely > > > > > philosophical in nature. I don't buy your argument. > > > > > > > > > > thanks, > > > > > -rohan > > > > > > > > > > > > > > > ---- Original message ---- > > > > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > > > > >From: "Peterson, Jon" > > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > > > > >To: "'sip@ietf.org'" > > > > > > > > > > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > > > > Jennings and > > > > > >myself about the short-term identity work, we have returned a > > > > > few times to > > > > > >the question of the infamous hint. This hint is, of course, a > > > > > way that a > > > > > >user agent (one that is not a member of the Trust Domain in > > > > > the short-term > > > > > >network asserted identity space) can provide a 'hint' to the > > > > > intermediary > > > > > >that will generate an Asserted-Identity indicating which > > > > > identity among > > > > > >several possibilities should be asserted. > > > > > > > > > > > >The need for this arises particularly from the 3G space, in > > > > > which the > > > > > >authentication process takes place independently of SIP and > > > > > does not carry > > > > > >this sort of personal identity information. It also assumes > > > > > that the > > > > > >operators of the intermediary in question are aware of > > > > > several legitimate > > > > > >identities which the user can elect to assert. > > > > > > > > > > > >It has been proposed on the mailing list and > elsewhere that the > > > > > >Asserted-Identity header should be re-used by user agents > > > > > outside the Trust > > > > > >Domain to provide such a hint. I see a number of reasons for > > > > > and against > > > > > >using the Asserted-Identity for this purpose. For example, > > > > > today, there is a > > > > > >requirement that asserted-identities which are transmitted > > > > > from untrusted > > > > > >sources should not be used in any way - this would seem to > > > > > weaken that > > > > > >requirement. There is also possibly some behavior that still > > > > > needs to be > > > > > >specified (like how an intermediary would reject or otherwise > > > > > handle a > > > > > >request with an inappropriate hint) that might be impactful > > > > > to our choice. > > > > > > > > > > > >For the time being, however, I would like to suggest that > > > > > providing the hint > > > > > >is outside the scope of the current deliverables (the > > > > > asserted-identity > > > > > >requirements and mechanism drafts), which need to be > > > > > complete, as we > > > > > >discussed in the interim meeting, by the end of this month. I > > > > > believe that a > > > > > >separate draft should propose the use of Asserted-Identity or > > > > > any other > > > > > >header for this hint (in whatever timeframe is appropriate > > > > > for 3G's > > > > > >requirements), but that we should not speak to this matter in > > > > > the current > > > > > >asserted-identity deliverables. There is, as I see it, no > > > > > dependency on > > > > > >defining this hint before we dictate how intermediaries will > > > > > assert > > > > > >identities. > > > > > > > > > > > >Any comments on this plan? > > > > > > > > > > > >Jon Peterson > > > > > >NeuStar, Inc. > > > > > > > > > > > >_______________________________________________ > > > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > >This list is for NEW development of the core SIP Protocol > > > > > >Use sip-implementors@cs.columbia.edu for questions on > > > current sip > > > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > ------_=_NextPart_001_01C2031A.DBB8F580 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Asserted-Identity: How to 'hint'?
Since I've never been one to fly in the face of public opinion (cough), I'll agree (at least in this case) that we should go with majority rule and use the Asserted-Identity header for the 'hint'.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Thursday, May 23, 2002 9:18 AM
To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?

In the absence of further comment, can I make a *proposal* that we stick with Asserted-Identity for the hint and for the NAI itself, and that both are described in Cullen's draft ?

Can we take this as AGREED if there are no comments by cob tomorrow ? (Guidance sought from chairs on this second question).

Updated requirements draft to be submitted first thing tomorrow.

Regards...Mark

> -----Original Message-----
> From: Andrew Allen [mailto:AAllen@dynamicsoft.com]
> Sent: 22 May 2002 15:51
> To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon';
> 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
>
>
>
> I agree with Dave. Lets put the hint in the
> asserted-identity. Lets not have
> two redundant headers that need to be transferred over the
> Radio interface
> unnecessarily.
>
> Andrew
>
> > -----Original Message-----
> > From: David R. Oran [mailto:oran@cisco.com]
> > Sent: Wednesday, May 22, 2002 9:45 AM
> > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >
> >
> > I suggest we allow the hint to be placed in the
> > asserted-identity rather
> > than in another header. A boundary proxy has to deal with a
> UA putting
> > in the header no matter what, if only to reject the request with an
> > error.
> >
> > Once we have a full solution the issue of hints should go
> > away as a side
> > effect of having the "authorization server" functionality that Jon
> > proposes. Better IMHO to have one obsolescent header to deal
> > with rather
> > than two, as well as avoiding the concomitant verbiage
> describing the
> > combinatoric cases involving two headers.
> >
> > Dave.
> >
> > > -----Original Message-----
> > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On
> > > Behalf Of Mark Watson
> > > Sent: Wednesday, May 22, 2002 9:59 AM
> > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > Importance: High
> > >
> > >
> > > All,
> > >
> > > Can we have a *decision* asap as to whether the 'hint' uses
> > > Asserted-Identity, or another header in another draft.
> > >
> > > I do not mind which. If the latter I will publish an I-D
> > > describing it as soon as we have a decision, assuming it is
> > > this week, since I'm away next week.
> > >
> > > If we do nothing, then I guess 3GPP will make up its own mind
> > > how to do this, without supervision or advice from IETF,
> > > which I think would  be a bad thing.
> > >
> > > Regards...Mark
> > >
> > >
> > > -----Original Message-----
> > > From: Watson, Mark [MDN05:EP10:EXCH]
> > > Sent: 20 May 2002 12:08
> > > To: 'Peterson, Jon'; 'Rohan Mahy'
> > > Cc: sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > >
> > >
> > > The 'hint' was one of the three requirements that 3GPP
> > > communicated to us in April.
> > > It is a separate requirement from the Network Asserted
> > > Identity itself, and so is not addressed in the requirements
> > > draft, although I have been careful to point this out, and to
> > > point out that it is a requirement nontheless, on several
> > > occasions. I believe we need the 'hint' in the same timeframe
> > > as the rest of the short term work.
> > > Whether it is the same header/draft or a different
> > > header/draft is another question on which I will only say
> > > that we'd better make up our minds pretty quick. ...Mark
> > >
> > >
> > > > -----Original Message-----
> > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > > > Sent: 19 May 2002 18:11
> > > > To: 'Rohan Mahy'
> > > > Cc: sip@ietf.org
> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > >
> > > >
> > > >
> > > > My argument was not that the proposed hint won't work - just
> > > > that it isn't
> > > > necessary to solve the problem at hand. It might not be the
> > > > case that the
> > > > problems with the hint stop at the philosophical point you
> > > > mention below.
> > > > What I asked in my last mail was not whether or not we needed
> > > > a hint, but
> > > > rather whether or not we should table that question until we
> > > > resolve the
> > > > other questions at hand. I just don't want to spend the
> > > > cycles arguing about
> > > > the hint given our very aggressive timetable - frankly, I
> > > think that
> > > > reaching consensus on this hint matter might push back our
> > > > dates a bit.
> > > > Let's investigate this hint stuff in June, but for now just
> > > > figure out how a
> > > > Trust Domain can manage an asserted identity in a message.
> > > >
> > > > Jon Peterson
> > > > NeuStar, Inc.
> > > >
> > > > > -----Original Message-----
> > > > > From: Rohan Mahy [mailto:rohan@cisco.com]
> > > > > Sent: Sunday, May 19, 2002 8:29 AM
> > > > > To: Peterson, Jon
> > > > > Cc: sip@ietf.org
> > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > The requirement for a hint is well understood, limited in
> > > > > scope, and well motivated in the draft.  Nobody has
> identified
> > > > > any technical reason why the hint won't work.   Your argument
> > > > > that allowing a hint weakens the strength of the language on
> > > > > ignoring Asserted-Identity from untrusted parties is purely
> > > > > philosophical in nature.  I don't buy your argument.
> > > > >
> > > > > thanks,
> > > > > -rohan
> > > > >
> > > > >
> > > > > ---- Original message ----
> > > > > >Date: Fri, 17 May 2002 16:02:11 -0500
> > > > > >From: "Peterson, Jon" <jon.peterson@neustar.biz> 
> > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? 
> > > > > >To: "'sip@ietf.org'" <sip@ietf.org>
> > > > > >
> > > > > >
> > > > > >In the course of the discussion between Mark Watson, Cullen
> > > > > Jennings and
> > > > > >myself about the short-term identity work, we have returned a
> > > > > few times to
> > > > > >the question of the infamous hint. This hint is, of course, a
> > > > > way that a
> > > > > >user agent (one that is not a member of the Trust Domain in
> > > > > the short-term
> > > > > >network asserted identity space) can provide a 'hint' to the
> > > > > intermediary
> > > > > >that will generate an Asserted-Identity indicating which
> > > > > identity among
> > > > > >several possibilities should be asserted.
> > > > > >
> > > > > >The need for this arises particularly from the 3G space, in
> > > > > which the
> > > > > >authentication process takes place independently of SIP and
> > > > > does not carry
> > > > > >this sort of personal identity information. It also assumes
> > > > > that the
> > > > > >operators of the intermediary in question are aware of
> > > > > several legitimate
> > > > > >identities which the user can elect to assert.
> > > > > >
> > > > > >It has been proposed on the mailing list and
> elsewhere that the
> > > > > >Asserted-Identity header should be re-used by user agents
> > > > > outside the Trust
> > > > > >Domain to provide such a hint. I see a number of reasons for
> > > > > and against
> > > > > >using the Asserted-Identity for this purpose. For example,
> > > > > today, there is a
> > > > > >requirement that asserted-identities which are transmitted
> > > > > from untrusted
> > > > > >sources should not be used in any way - this would seem to
> > > > > weaken that
> > > > > >requirement. There is also possibly some behavior that still
> > > > > needs to be
> > > > > >specified (like how an intermediary would reject or otherwise
> > > > > handle a
> > > > > >request with an inappropriate hint) that might be impactful
> > > > > to our choice.
> > > > > >
> > > > > >For the time being, however, I would like to suggest that
> > > > > providing the hint
> > > > > >is outside the scope of the current deliverables (the
> > > > > asserted-identity
> > > > > >requirements and mechanism drafts), which need to be
> > > > > complete, as we
> > > > > >discussed in the interim meeting, by the end of this month. I
> > > > > believe that a
> > > > > >separate draft should propose the use of Asserted-Identity or
> > > > > any other
> > > > > >header for this hint (in whatever timeframe is appropriate
> > > > > for 3G's
> > > > > >requirements), but that we should not speak to this matter in
> > > > > the current
> > > > > >asserted-identity deliverables. There is, as I see it, no
> > > > > dependency on
> > > > > >defining this hint before we dictate how intermediaries will
> > > > > assert
> > > > > >identities.
> > > > > >
> > > > > >Any comments on this plan?
> > > > > >
> > > > > >Jon Peterson
> > > > > >NeuStar, Inc.
> > > > > >
> > > > > >_______________________________________________
> > > > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > >This list is for NEW development of the core SIP Protocol
> > > > > >Use sip-implementors@cs.columbia.edu for questions on
> > > current sip
> > > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on
> current sip
> > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>

------_=_NextPart_001_01C2031A.DBB8F580-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 10:21:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29812 for ; Fri, 24 May 2002 10:21:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12962 for sip-archive@odin.ietf.org; Fri, 24 May 2002 10:22:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12476; Fri, 24 May 2002 10:09:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12431 for ; Fri, 24 May 2002 10:09:37 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29451 for ; Fri, 24 May 2002 10:09:14 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA02528; Fri, 24 May 2002 16:09:20 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA19941; Fri, 24 May 2002 16:09:33 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 16:09:39 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DD9@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel A. Garcia'" Cc: sip@ietf.org Subject: [Sip] Comments on draft-garcia-sip-called-party-id-01 Date: Fri, 24 May 2002 16:09:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, - Reading the draft for the first time, I must say that I was confused by the 4th paragraph of the Section 2 which starts with "Another possible solution to the problem is...". Up to this point the draft talks about the problem, with no solution mentioned yet. With the "Another possible solution", I thought I had a corrupted version of the draft with some paragraphs missing. - The next paragraph which starts with "The solution described above...", the sentence "that some URIs may be automatically registered when the UA registers some of its URIs" confused me further. - Is the term "terminating ID" (of the current INVITE) defined somewhere ? I think you mean "the destination (request-URI) of the request before it was replaced by the contact address". - In the example, the sentence above the mesage F2 starts with "A user also...", do you actually mean "The user also..." ? - The last paragraph of Section 2 : "... the proxy that is serving the user..." should be made clearer, perhaps with "the proxy that is responsible for the home domain (as defined in RFC 3261) of the user" ? Also, please add a "header" after the P-Called-Party-ID in the same sentence. - Section 3 "1. The UA registers to his proxy with one or more SIP URIs". Does it have to be SIP URIs or can it be "SIP or SIPS URIs" ? I assume you mean here that the UA registers one or more address-of-record. "2. The proxy receives an INVITE destined to a user's ID" means : "2. An INVITE arrives at a proxy which is responsible for the domain of the Request-URI". Come to think of it, these applicability statements apply to all SIP requests in general. It is normal for a UA to register to his proxy with at least one address- of-record, and some proxy always receives an INVITE destined to a user' ID. I do not see how these statements meet the requirement of [3], which states : "An applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet." - Section 4 2nd paragraph o This paragraph seems to imply that any SIP proxy can insert the P-Call-Party-ID header field. o The term "standalone method" is not defined in SIP RFC. o INVITE is a method that initiates a dialog so it cannot be "INVITE or method that intiates a dialog". - Section 5 The sentence "The allowable usage of headers..." is repeated. The 3rd paragraph should be completely deleted. - Section 6.2 First paragraph o The term "standalone method" is not defined in SIP RFC. o INVITE is a method that initiates a dialog so it cannot be "INVITE or method that intiates a dialog". o "...contents Request-URI" => "...contents of the Request-URI..." Second paragraph o "...the proxy who..." => "...the proxy which..." - Ya-Ching Tan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 14:48:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10224 for ; Fri, 24 May 2002 14:48:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13547 for sip-archive@odin.ietf.org; Fri, 24 May 2002 14:48:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11103; Fri, 24 May 2002 14:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10876 for ; Fri, 24 May 2002 14:29:08 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03467 for ; Fri, 24 May 2002 11:55:24 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA07613; Fri, 24 May 2002 17:55:30 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA09366; Fri, 24 May 2002 17:55:43 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 17:55:49 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDA@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel A. Garcia'" Cc: sip@ietf.org Subject: RE: [Sip] Comments on draft-garcia-sip-visited-network-id-01 Date: Fri, 24 May 2002 17:55:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, - General The term 'standalone request' or 'standalone transaction request' is used throughout the document. Please define what it means. - 3rd paragraph of Section 1 "... it seems sensitive..." should be "... it seems sensible..." - Section 2, point 3 "There is not requirement that..." should be "There is no requirement that ...", and at the end of the sentence, "in this memo" should be "in this document". - Section 4 Please delete the 1st sentence "The P-Visited-Network-ID is an extension of a SIP header", or replace it with "This specification defines a new header field. - 1st paragraph on page 4 "..., a SIP node may insert a new P-Visited-Network-ID header, if there was already one present with different contents" is misleading. I think you meant : "..., a proxy MAY insert a new P-Visited-Network-ID header if the request does not contain any P-Visited-Network-ID header with the same network identifier as its own network identifier". Delete the "a vairous" in "...a various different administrative domains" - The addition to Table 2 in Section 4 A "r" should be added to the "ad" under proxy. Proxies must be able to read this header. - Section 5.1 "The UA SHOULD NOT insert" should be "MUST NOT insert". I think the result can be disastrous if a UA inserts one. - Section 5.2 Replace "the contents of a provisioned string" with just "a text string" and delete the "at the user's home domain" at the end. Otherwise it reads like "identifies ...the proxy is operating at the user's home network", where it is not. - 10.2 draft-sipping-garcia-3gpp-req-03 should be draft-garcia-sipping-3gpp-req-03 instead. This same error is also in the called party id draft. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 14:55:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10473 for ; Fri, 24 May 2002 14:55:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13905 for sip-archive@odin.ietf.org; Fri, 24 May 2002 14:55:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12942; Fri, 24 May 2002 14:45:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12752 for ; Fri, 24 May 2002 14:45:16 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05580 for ; Fri, 24 May 2002 13:00:42 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA28796; Fri, 24 May 2002 19:00:59 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA22591; Fri, 24 May 2002 19:01:01 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 19:01:06 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDB@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel.A.Garcia@ericsson.com'" Cc: "'sip@ietf.org'" Subject: [Sip] Comments on draft-garcia-sip-visited-network-id-01 Date: Fri, 24 May 2002 19:00:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, - General The term 'standalone request' or 'standalone transaction request' is used throughout the document. Please define what it means. - 3rd paragraph of Section 1 "... it seems sensitive..." should be "... it seems sensible..." - Section 2, point 3 "There is not requirement that..." should be "There is no requirement that ...", and at the end of the sentence, "in this memo" should be "in this document". - Section 4 Please delete the 1st sentence "The P-Visited-Network-ID is an extension of a SIP header", or replace it with "This specification defines a new header field. - 1st paragraph on page 4 "..., a SIP node may insert a new P-Visited-Network-ID header, if there was already one present with different contents" is misleading. I think you meant : "..., a proxy MAY insert a new P-Visited-Network-ID header if the request does not contain any P-Visited-Network-ID header with the same network identifier as its own network identifier". Delete the "a vairous" in "...a various different administrative domains" - The addition to Table 2 in Section 4 A "r" should be added to the "ad" under proxy. Proxies must be able to read this header. - Section 5.1 "The UA SHOULD NOT insert" should be "MUST NOT insert". I think the result can be disastrous if a UA inserts one. - Section 5.2 Replace "the contents of a provisioned string" with just "a text string" and delete the "at the user's home domain" at the end. Otherwise it reads like "identifies ...the proxy is operating at the user's home network", where it is not. - 10.2 draft-sipping-garcia-3gpp-req-03 should be draft-garcia-sipping-3gpp-req-03 instead. This same error is also in the called party id draft. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 15:46:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12108 for ; Fri, 24 May 2002 15:46:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17060 for sip-archive@odin.ietf.org; Fri, 24 May 2002 15:46:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15577; Fri, 24 May 2002 15:29:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15509 for ; Fri, 24 May 2002 15:28:55 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11412 for ; Fri, 24 May 2002 15:28:32 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4OJS6d08646; Fri, 24 May 2002 14:28:06 -0500 From: "Dean Willis" To: Cc: , , , Date: Fri, 24 May 2002 14:27:32 -0500 Message-ID: <00b201c20359$0d927570$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Poll: Expert Review of draft-henrikson-sip-orig-dialog-id Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yet another P-Header review. Please say anything you have to say about draft-henrikson-sip-orig-dialog-id so we can decide whether to accept it, reject it, or require further work. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 15:49:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12211 for ; Fri, 24 May 2002 15:49:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17210 for sip-archive@odin.ietf.org; Fri, 24 May 2002 15:49:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15553; Fri, 24 May 2002 15:28:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15502 for ; Fri, 24 May 2002 15:28:54 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11411 for ; Fri, 24 May 2002 15:28:32 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4OJS6d08651; Fri, 24 May 2002 14:28:06 -0500 From: "Dean Willis" To: Cc: , , , Date: Fri, 24 May 2002 14:27:32 -0500 Message-ID: <00b301c20359$0e1bf0c0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Poll: expert review of draft-henrikson-sip-charging-information Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You may recall that we're doing an Expert Review of draft-henrikson-sip-charging-information. If you have a strong opinion for, against, or supporting a need for further work, or any further suggestions for enhancement, please post them now. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 15:54:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12408 for ; Fri, 24 May 2002 15:54:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17395 for sip-archive@odin.ietf.org; Fri, 24 May 2002 15:54:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15626; Fri, 24 May 2002 15:29:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15566 for ; Fri, 24 May 2002 15:29:00 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11417 for ; Fri, 24 May 2002 15:28:37 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4OJS7d08654; Fri, 24 May 2002 14:28:07 -0500 From: "Dean Willis" To: Cc: , , , "Miguel Garcia" Date: Fri, 24 May 2002 14:27:32 -0500 Message-ID: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to request feedback on the expert review of draft-garcia-sip-associated URI: Option: Yeah Nay Or Needs More Work And of course, details on what and why . . . Anybody out there have a Strong Opinion One Way or Another? Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 17:57:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16613 for ; Fri, 24 May 2002 17:57:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24243 for sip-archive@odin.ietf.org; Fri, 24 May 2002 17:57:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23834; Fri, 24 May 2002 17:44:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23780 for ; Fri, 24 May 2002 17:43:59 -0400 (EDT) Received: from omta03.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16139 for ; Fri, 24 May 2002 17:43:38 -0400 (EDT) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta03.mta.everyone.net (Postfix) with ESMTP id 34A2A4A2A2 for ; Fri, 24 May 2002 14:43:57 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 0842736F9; Fri, 24 May 2002 14:43:57 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Fri, 24 May 2002 14:43:56 -0700 (PDT) From: Kosta Koeman To: sip@ietf.org Reply-To: kkoeman@techemail.com X-Originating-Ip: [131.107.3.79] Message-Id: <20020524214357.0842736F9@sitemail.everyone.net> Content-Transfer-Encoding: 7bit Subject: [Sip] bug in grammar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Subtle bug in grammer. Page 167 definition of rfc1123-date reads as wkday "," date1 SP time SP "GMT" should read wkday "," SP date1 SP time SP "GMT" Kosta _____________________________________________________________ Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 24 23:56:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29815 for ; Fri, 24 May 2002 23:56:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA06692 for sip-archive@odin.ietf.org; Fri, 24 May 2002 23:56:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05363; Fri, 24 May 2002 23:20:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05332 for ; Fri, 24 May 2002 23:20:00 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28154 for ; Fri, 24 May 2002 23:19:39 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4P3L1YH023448; Fri, 24 May 2002 23:21:02 -0400 (EDT) Message-ID: <3CEF02BE.6580CB9D@dynamicsoft.com> Date: Fri, 24 May 2002 23:19:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kkoeman@techemail.com CC: sip@ietf.org Subject: Re: [Sip] bug in grammar References: <20020524214357.0842736F9@sitemail.everyone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes, we are aware of that one. Thanks! -Jonathan R. Kosta Koeman wrote: > > Subtle bug in grammer. Page 167 definition of rfc1123-date reads as > > wkday "," date1 SP time SP "GMT" > > should read > > wkday "," SP date1 SP time SP "GMT" > > Kosta > > _____________________________________________________________ > Are you a Techie? Get Your Free Tech Email Address Now! Visit > http://www.TechEmail.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with > email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat May 25 02:32:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14548 for ; Sat, 25 May 2002 02:32:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA22466 for sip-archive@odin.ietf.org; Sat, 25 May 2002 02:32:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20174; Sat, 25 May 2002 02:03:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20145 for ; Sat, 25 May 2002 02:03:53 -0400 (EDT) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09119 for ; Sat, 25 May 2002 02:03:30 -0400 (EDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g4P63LE21733 for ; Sat, 25 May 2002 06:03:21 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002052423113005394 for ; Fri, 24 May 2002 23:11:30 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 23:03:21 -0700 Message-ID: From: "Krishnaswamy, Pavitra" To: "'sip@ietf.org'" Date: Fri, 24 May 2002 23:03:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Multicast Registrations Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a question about multicast registrations. What is the exact purpose of a multicast registration? Is it only meant for discovery of Registrars when a UA doesn't have this information or does it have any other meaning/use? In a UA implementation, does the multicast registration have to be refreshed periodically? If yes, won't it cause traffic issues on the network (more so if the expires header for the registration request is small). Would really appreciate any input on this issue. Thanks in advance, pavitra Pavitra Krishnaswamy Trillium, An Intel Company 12100 Wilshire Blvd. Los Angeles, CA 90025 http://www.trillium.com pavitra@trillium.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat May 25 09:32:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21265 for ; Sat, 25 May 2002 09:32:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09303 for sip-archive@odin.ietf.org; Sat, 25 May 2002 09:32:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08424; Sat, 25 May 2002 09:13:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08393 for ; Sat, 25 May 2002 09:13:30 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21147 for ; Sat, 25 May 2002 09:13:08 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4PDDRmG009208; Sat, 25 May 2002 15:13:27 +0200 (MEST) Received: from ericsson.com (ppp28.lmf.ericsson.se [131.160.102.28]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4PDDO4J002731; Sat, 25 May 2002 16:13:25 +0300 (EET DST) Message-ID: <3CEF8DF9.F2B33CA3@ericsson.com> Date: Sat, 25 May 2002 16:13:29 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: sip@ietf.org Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01 References: <5B4D0C5BA65ECA46969C1419122317E6E74DD9@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Ya-Ching: Thanks a lot for your comments. See my answers inline. /Miguel Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Hi, > > - Reading the draft for the first time, I must say that I was confused by > the 4th > paragraph of the Section 2 which starts with "Another possible solution to > the > problem is...". Up to this point the draft talks about the problem, with > no > solution mentioned yet. With the "Another possible solution", I thought I > had > a corrupted version of the draft with some paragraphs missing. > Section 2 starts with a description of the problem in the first paragraph. Paragraphs 2 and 3 in this section describe a possible solution that does not work. Paragraphs 4 and 5 describe another possible solution that does not work as well. That is why the 4th paragraph begins with "Another possible solution ...". > - The next paragraph which starts with "The solution described above...", > the > sentence "that some URIs may be automatically registered when the UA > registers some of its URIs" confused me further. > Maybe the following text is clearer: "some URIs may be automatically registered when the UA registers a particular URI". > - Is the term "terminating ID" (of the current INVITE) defined somewhere ? I > think > you mean "the destination (request-URI) of the request before it was > replaced > by the contact address". Yes, you are right. I think if I replace "terminating ID" by "intended destination URI" the sentence is clearer. It will read: "... so that the UAC is not aware of the intended destination URI in the current INVITE." > > - In the example, the sentence above the mesage F2 starts with > "A user also...", do you actually mean "The user also..." ? > Certainly is "The user also ..." > - The last paragraph of Section 2 : > "... the proxy that is serving the user..." should be made clearer, > perhaps with > "the proxy that is responsible for the home domain (as defined in RFC > 3261) of > the user" ? Also, please add a "header" after the P-Called-Party-ID in the > same > sentence. ok. Done!!! > > - Section 3 > "1. The UA registers to his proxy with one or more SIP URIs". Does it have > to be > SIP URIs or can it be "SIP or SIPS URIs" ? I assume you mean here that > the > UA registers one or more address-of-record. The important thing here is that the UAC registers at least one SIP or SIPS URI to his proxy. It is not relevant whether there are one or more address-of- record registered. What I want to say is that the user may register more than one SIP or SIPS URI. > "2. The proxy receives an INVITE destined to a user's ID" means : > "2. An INVITE arrives at a proxy which is responsible for the domain of > the > Request-URI". better... However we are missing the connection between the proxy and the registrar. Perhaps the sentence should read "an INVITE destined for the user arrives at a proxy in the domain where the user is registered. The proxy contacts the registrar to find the location of the user." > > Come to think of it, these applicability statements apply to all SIP > requests in > general. It is normal for a UA to register to his proxy with at least one > address- > of-record, and some proxy always receives an INVITE destined to a user' > ID. Not necessarily. Registration is an optional procedure in SIP, although quite common. Without registration this P- header has no sense at all. > I do not see how these statements meet the requirement of [3], which > states : > > "An applicability statement in the Informational RFC MUST > clearly document the useful scope of the proposal, and explain > its limitations and why it is not suitable for the general use > of SIP in the Internet." My effort was to scope as much as possible this header. It is suitable for the general use of SIP in the Internet, so I have nothing else to say. > > - Section 4 2nd paragraph > o This paragraph seems to imply that any SIP proxy can insert the > P-Call-Party-ID header field. fixed. > o The term "standalone method" is not defined in SIP RFC. I meant requests that do not create a dialog, such a MESSAGE. But I need to differentiate from requests that are sent within a dialog (e.g. INFO). I'll fix it somehow, but I think that the term standalone, although not define in RFC 3261, is understandable by the reader familiar with SIP. > o INVITE is a method that initiates a dialog so it cannot be "INVITE or > method that intiates a dialog". fixed > > - Section 5 > The sentence "The allowable usage of headers..." is repeated. The 3rd > paragraph should be completely deleted. > Ooops, I forgot to delete this paragraph when I replaced it by the next paragra. Thanks a lot. Fixed > - Section 6.2 > First paragraph > o The term "standalone method" is not defined in SIP RFC. > o INVITE is a method that initiates a dialog so it cannot be "INVITE or > method that intiates a dialog". > o "...contents Request-URI" => "...contents of the Request-URI..." > > Second paragraph > o "...the proxy who..." => "...the proxy which..." > All fixed. You will see the changes in the next version. > - Ya-Ching Tan > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat May 25 09:42:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21607 for ; Sat, 25 May 2002 09:42:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09535 for sip-archive@odin.ietf.org; Sat, 25 May 2002 09:42:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08463; Sat, 25 May 2002 09:14:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08432 for ; Sat, 25 May 2002 09:14:06 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21151 for ; Sat, 25 May 2002 09:13:44 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4PDE56n025796; Sat, 25 May 2002 15:14:05 +0200 (MEST) Received: from ericsson.com (ppp28.lmf.ericsson.se [131.160.102.28]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4PDE24J002740; Sat, 25 May 2002 16:14:03 +0300 (EET DST) Message-ID: <3CEF8E1F.41467F09@ericsson.com> Date: Sat, 25 May 2002 16:14:07 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: sip@ietf.org Subject: Re: [Sip] Comments on draft-garcia-sip-visited-network-id-01 References: <5B4D0C5BA65ECA46969C1419122317E6E74DDA@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Ya-Ching: Thanks a lot for your comments. See my answers inline. /Miguel Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Hi, > > - General > The term 'standalone request' or 'standalone transaction > request' is used throughout the document. Please define > what it means. Yes, I will apply a similar treatment as for the P-Called-Party-ID > > - 3rd paragraph of Section 1 > "... it seems sensitive..." should be "... it seems sensible..." > done > - Section 2, point 3 "There is not requirement that..." should > be "There is no requirement that ...", and at the end of the > sentence, "in this memo" should be "in this document". I have no problems with the change, but many RFCs refer to "this document" as "this memo". > > - Section 4 > Please delete the 1st sentence "The P-Visited-Network-ID > is an extension of a SIP header", or replace it with "This > specification defines a new header field. > Replaced > - 1st paragraph on page 4 > "..., a SIP node may insert a new P-Visited-Network-ID header, > if there was already one present with different contents" is > misleading. I think you meant : > "..., a proxy MAY insert a new P-Visited-Network-ID header > if the request does not contain any P-Visited-Network-ID header > with the same network identifier as its own network identifier". > > Delete the "a vairous" in "...a various different administrative > domains" > fine > - The addition to Table 2 in Section 4 > A "r" should be added to the "ad" under proxy. Proxies must > be able to read this header. > Ummm... not sure. If a proxy decides to encrypt this header, so that only the registrar or proxy at home is able to read it, it will not make any negative effect to other proxies in the path. The only negative effect is that these proxies in the middle will not be able to read the contents, so they will not know if the same visited network ID was already present or not. But it does not introduce any problem. > - Section 5.1 > "The UA SHOULD NOT insert" should be "MUST NOT insert". > I think the result can be disastrous if a UA inserts one. > Yes, I agree with you, it should be a MUST NOT. > - Section 5.2 > Replace "the contents of a provisioned string" with just "a text > string" and delete the "at the user's home domain" at the end. > Otherwise it reads like "identifies ...the proxy is operating > at the user's home network", where it is not. > What I wanted to express, is a scenario where a proxy in a visited network is using different strings to identify his own network at different home networks. So, for example, proxy P1 receives a request addressed to network N1; P1 inserts VNID1. The same proxy P1 receives a request addressed to network N2; it may decide to insert VNID2. This VNID is known between both networks, so from the point of view of the protocol I don't see why we should limit it here. > - 10.2 > draft-sipping-garcia-3gpp-req-03 should be > draft-garcia-sipping-3gpp-req-03 instead. This same error > is also in the called party id draft. Ooops... Fixed. > > Regards, > Ya-Ching -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 27 04:39:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14207 for ; Mon, 27 May 2002 04:39:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27929 for sip-archive@odin.ietf.org; Mon, 27 May 2002 04:40:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26679; Mon, 27 May 2002 04:13:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26647 for ; Mon, 27 May 2002 04:13:07 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13849 for ; Mon, 27 May 2002 04:12:44 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA00013; Mon, 27 May 2002 10:12:51 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA23818; Mon, 27 May 2002 10:13:05 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 10:13:12 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel A. Garcia'" Cc: sip@ietf.org Subject: RE: [Sip] Comments on draft-garcia-sip-called-party-id-01 Date: Mon, 27 May 2002 10:12:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Miguel, | | Maybe the following text is clearer: | "some URIs may be automatically registered when the UA registers a | particular URI". | A REGISTER is used to create a binding between an address-of-record AOR (or public address) and a contact address. One may use a new registration to bind more contact addresses to an AOR. It is also possible or have more than one AOR bound to the same contact address (more than one user can be registered on a single device). So it is not clear to me in your sentence above what URIs you are talking about - public addresses or contact addresses ? | | | | The important thing here is that the UAC registers at least | one SIP or SIPS | URI to his proxy. It is not relevant whether there are one or | more address-of- | record registered. What I want to say is that the user may | register more | than one SIP or SIPS URI. | Same comment as above. You cannot just say that a user register more than one SIP or SIPS URI. I think the point of the whole draft is that a user can have more than one address-of-record (public address) - sip:user1-business@example.com and sip:user1-private@example.com. These address-of-record's are bound to the same device. When he gets a call, the Request-URI is always replaced by his contact/device address and so he cannot tell which address-of-record the caller has used to call him. | > I do not see how these statements meet the requirement of | [3], which | > states : | > | > "An applicability statement in the Informational RFC MUST | > clearly document the useful scope of the proposal, and explain | > its limitations and why it is not suitable for the general use | > of SIP in the Internet." | | | My effort was to scope as much as possible this header. It is suitable | for the general use of SIP in the Internet, so I have nothing else to | say. | If it is suitable for the general use, why a P-header ? | > o The term "standalone method" is not defined in SIP RFC. | | | I'll fix it somehow, but I think that the term standalone, | although not define in RFC 3261, is understandable by the | reader familiar with SIP. | RFC 3261 even defines terms such as "Message", "Parallel Search". One simply can't start using a new term like "standalone request" or "standalone transaction request" and assume that it is 'understandable by the reader familiar with SIP'. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 27 04:58:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14659 for ; Mon, 27 May 2002 04:58:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29885 for sip-archive@odin.ietf.org; Mon, 27 May 2002 04:59:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28127; Mon, 27 May 2002 04:42:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28096 for ; Mon, 27 May 2002 04:42:51 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14244 for ; Mon, 27 May 2002 04:42:28 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA03049; Mon, 27 May 2002 10:42:36 +0200 (MET DST) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA04861; Mon, 27 May 2002 10:42:50 +0200 (MET DST) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 10:42:57 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDD@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel A. Garcia'" Cc: sip@ietf.org Subject: RE: [Sip] Comments on draft-garcia-sip-visited-network-id-01 Date: Mon, 27 May 2002 10:42:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Miguel, | > - The addition to Table 2 in Section 4 | > A "r" should be added to the "ad" under proxy. Proxies must | > be able to read this header. | > | | Ummm... not sure. If a proxy decides to encrypt this | header, so that only the registrar or proxy at home is able to | read it, it will not make any negative effect to other proxies | in the path. The only negative effect is that these proxies in | the middle will not be able to read the contents, so they will | not know if the same visited network ID was already present or | not. But it does not introduce any problem. | If P-Visited-Network_ID header cannot be read by proxy, I fail to see the point of this header. If the draft states that "... a SIP node (I think you mean proxy here) may insert a new P-Visited-Network-ID header, if there was already one present with different contents...", then you have to state what happens if the content is encrypted and the proxy cannot see the contents. You can't just say 'But it does not introduce any problem'. | | | What I wanted to express, is a scenario where a proxy in a visited | network is using different strings to identify his own network | at different home networks. So, for example, proxy P1 receives | a request addressed to network N1; P1 inserts VNID1. The same proxy | P1 receives a request addressed to network N2; it may decide to | insert VNID2. This VNID is known between both networks, so from | the point of view of the protocol I don't see why we should limit | it here. | OK. Now I get it. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 27 05:41:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15393 for ; Mon, 27 May 2002 05:41:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03615 for sip-archive@odin.ietf.org; Mon, 27 May 2002 05:42:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02383; Mon, 27 May 2002 05:28:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02353 for ; Mon, 27 May 2002 05:28:12 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15221 for ; Mon, 27 May 2002 05:27:48 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4R9S16n014981; Mon, 27 May 2002 11:28:03 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4R9S0gu024318; Mon, 27 May 2002 12:28:00 +0300 (EET DST) Message-ID: <3CF1FC20.3CFDAEE6@ericsson.com> Date: Mon, 27 May 2002 12:28:00 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: sip@ietf.org Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01 References: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Ya-Ching: Comments below Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Hi Miguel, > > | > | Maybe the following text is clearer: > | "some URIs may be automatically registered when the UA registers a > | particular URI". > | > > A REGISTER is used to create a binding between an address-of-record AOR (or > public address) and a contact address. One may use a new registration to > bind more contact addresses to an AOR. It is also possible or have more than > one AOR bound to the same contact address (more than one user can be > registered on a single device). So it is not clear to me in your sentence > above what URIs you are talking about - public addresses or contact > addresses ? Reading again the text, I agree with you, it is not clear at all. The case I refer is when an application server registers other address-of-record URIs pointing to the same contact address. I will clarify the terminology in the draft. > | > | > | > | The important thing here is that the UAC registers at least > | one SIP or SIPS > | URI to his proxy. It is not relevant whether there are one or > | more address-of- > | record registered. What I want to say is that the user may > | register more > | than one SIP or SIPS URI. > | > > Same comment as above. You cannot just say that a user register more than > one SIP or SIPS URI. I think the point of the whole draft is that a user can > have more than one address-of-record (public address) - > sip:user1-business@example.com and sip:user1-private@example.com. These > address-of-record's are bound to the same device. When he gets a call, the > Request-URI is always replaced by his contact/device address and so he > cannot tell which address-of-record the caller has used to call him. yes, I agree with you > > | > I do not see how these statements meet the requirement of > | [3], which > | > states : > | > > | > "An applicability statement in the Informational RFC MUST > | > clearly document the useful scope of the proposal, and explain > | > its limitations and why it is not suitable for the general use > | > of SIP in the Internet." > | > | > | My effort was to scope as much as possible this header. It is suitable > | for the general use of SIP in the Internet, so I have nothing else to > | say. > | > > If it is suitable for the general use, why a P-header ? Because so far nobody else has the requirement as we expressed. That's why we are going for a P- header. But the extension itself is not restricted to 3GPP. It is generally applicable to the Internet. > > | > o The term "standalone method" is not defined in SIP RFC. > | > | > | I'll fix it somehow, but I think that the term standalone, > | although not define in RFC 3261, is understandable by the > | reader familiar with SIP. > | > > RFC 3261 even defines terms such as "Message", "Parallel Search". One simply > can't start using a new term like "standalone request" or "standalone > transaction request" and assume that it is 'understandable by the reader > familiar with SIP'. > Yes, I understand your comment. I will do my best to make it clear what it means in the next version. Thanks for your comments. /miguel > Regards, > Ya-Ching > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 27 19:31:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26064 for ; Mon, 27 May 2002 19:31:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13255 for sip-archive@odin.ietf.org; Mon, 27 May 2002 19:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12468; Mon, 27 May 2002 19:14:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12437 for ; Mon, 27 May 2002 19:14:51 -0400 (EDT) Received: from dsl-64-192-31-101.telocity.com (dsl-64-192-31-101.telocity.com [64.192.31.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25970 for ; Mon, 27 May 2002 19:14:27 -0400 (EDT) Received: from keyser1.dsl-64-192-31-101.telocity.com ([192.168.0.1]) by dsl-64-192-31-101.telocity.com (JAMES SMTP Server 2.0a2) with SMTP ID 4 for ; Mon, 27 May 2002 19:14:10 -0400 Received: from jeff (unverified [192.168.0.18]) by KEYSER1.dsl-64-192-31-101.telocity.com (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 27 May 2002 19:13:35 -0400 From: "Jeff Keyser" To: "SIP Mailing List \(E-mail\)" Date: Mon, 27 May 2002 19:13:33 -0400 Message-ID: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I apologize if this is not the correct place for this comment. If this is not, please let me know where I should direct this. I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client, and the INVITE transactions of section 17 don't make sense to me as written. For both client and server INVITE transactions in the "Proceeding" state (and "Calling" state for client transactions), if a new response status code is 300-699, the transaction changes to the "Completed" state; and, if a new response status code is 2xx, the transaction changes to the "Terminated" state. The state diagrams show this same logic. I assume that this is supposed to be the other way around, since the "Completed" state is used the handle the ACK request of a connected call. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon May 27 21:20:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27026 for ; Mon, 27 May 2002 21:20:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA18099 for sip-archive@odin.ietf.org; Mon, 27 May 2002 21:20:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17172; Mon, 27 May 2002 21:01:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17146 for ; Mon, 27 May 2002 21:01:09 -0400 (EDT) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26781 for ; Mon, 27 May 2002 21:00:47 -0400 (EDT) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4S11Al03631; Mon, 27 May 2002 21:01:10 -0400 (EDT) Message-ID: <389c01c205e3$273eb010$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: "Jeff Keyser" , "SIP Mailing List \(E-mail\)" References: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com> Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 Date: Mon, 27 May 2002 21:01:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for bringing this up Jeff. I too had asked this question some time back to Vijay Gurbani. Even I am waiting to get some clarifications on it if I didnt understand the model. Prabhas ----- Original Message ----- From: "Jeff Keyser" To: "SIP Mailing List (E-mail)" Sent: Monday, May 27, 2002 7:13 PM Subject: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 > I apologize if this is not the correct place for this comment. If this is > not, please let me know where I should direct this. > > I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client, and > the INVITE transactions of section 17 don't make sense to me as written. > For both client and server INVITE transactions in the "Proceeding" state > (and "Calling" state for client transactions), if a new response status code > is 300-699, the transaction changes to the "Completed" state; and, if a new > response status code is 2xx, the transaction changes to the "Terminated" > state. The state diagrams show this same logic. > > I assume that this is supposed to be the other way around, since the > "Completed" state is used the handle the ACK request of a connected call. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 02:00:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01515 for ; Tue, 28 May 2002 02:00:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA11840 for sip-archive@odin.ietf.org; Tue, 28 May 2002 02:00:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10159; Tue, 28 May 2002 01:38:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10122 for ; Tue, 28 May 2002 01:38:26 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00371 for ; Tue, 28 May 2002 01:38:00 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4S5bsHs024939; Mon, 27 May 2002 22:37:54 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACZ93037; Mon, 27 May 2002 22:38:04 -0700 (PDT) From: "Cullen Jennings" To: Date: Mon, 27 May 2002 22:38:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-asserted-identity-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jon, Mark, and I have put together a new version of the asserted identity draft - until it arrives in the archives, you can find it at: http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-00.html http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-00.txt Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 02:03:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04999 for ; Tue, 28 May 2002 02:03:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12130 for sip-archive@odin.ietf.org; Tue, 28 May 2002 02:03:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10441; Tue, 28 May 2002 01:44:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10410 for ; Tue, 28 May 2002 01:44:47 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00518 for ; Tue, 28 May 2002 01:44:22 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4S5joYH024687; Tue, 28 May 2002 01:45:51 -0400 (EDT) Message-ID: <3CF3192F.CCB8076F@dynamicsoft.com> Date: Tue, 28 May 2002 01:44:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Keyser CC: "SIP Mailing List (E-mail)" Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 References: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Jeff Keyser wrote: > > I apologize if this is not the correct place for this comment. If this > is > not, please let me know where I should direct this. > > I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client, > and > the INVITE transactions of section 17 don't make sense to me as written. > For both client and server INVITE transactions in the "Proceeding" state > (and "Calling" state for client transactions), if a new response status > code > is 300-699, the transaction changes to the "Completed" state; and, if a > new > response status code is 2xx, the transaction changes to the "Terminated" > state. The state diagrams show this same logic. > > I assume that this is supposed to be the other way around, since the > "Completed" state is used the handle the ACK request of a connected > call. No, it is correct as written. The reason is that this state machine represents the *transaction* state. The transaction state machine is responsible for request/response correlation, retransmissions, and so on. It is NOT responsible for the management of the call state. When a 2xx is received, the transaction is complete. There is an ACK, but this ACK constitutes a separate transaction. Correlation of the ACK with the 2xx is done by the UAS at a higher layer, not by the transaction machines. In contrast, for non-2xx final responses, the ACK is part of the same transaction, and so the state machine must stick around to handle that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 02:40:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09613 for ; Tue, 28 May 2002 02:40:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14275 for sip-archive@odin.ietf.org; Tue, 28 May 2002 02:40:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12657; Tue, 28 May 2002 02:15:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12627 for ; Tue, 28 May 2002 02:15:13 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09399 for ; Tue, 28 May 2002 02:14:50 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4S6GIYH024701 for ; Tue, 28 May 2002 02:16:18 -0400 (EDT) Message-ID: <3CF32051.287C0D20@dynamicsoft.com> Date: Tue, 28 May 2002 02:14:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] new I-D for registration event package Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've just submitted draft-rosenberg-sip-reg-event to the archives. Until it appears you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sip-reg-event-00.txt This draft is an attempt to generalize the registration event package defined in: http://www.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-01.txt I believe there are a lot of valuable applications for a registration event package, and therefore, having a generalized version seems like a good thing. There is nothing radically different between the two drafts. The main difference is that mine defines a specific state machine for registration events, and defines an XML document format to specifically convey information about changes to that machine. It doesn't reuse the presence document format, as the beckmann draft does. My draft does appear to meet the 3gpp requirements. The key decision point for the group is whether to move forward with draft-rosenberg-sip-reg-event (as a sipwg draft) or draft-beckmann-sip-reg-event. Unfortunately, the timeline doesn't change in either case, since something is needed for 3gpp in quite short order. In some private email conversations, Mark and Georg indicated support for going with a generalized version, but I will let them speak for themselves. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 03:28:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10088 for ; Tue, 28 May 2002 03:28:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16949 for sip-archive@odin.ietf.org; Tue, 28 May 2002 03:28:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16037; Tue, 28 May 2002 03:06:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15998 for ; Tue, 28 May 2002 03:06:50 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09912 for ; Tue, 28 May 2002 03:06:26 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4S77eYH024722; Tue, 28 May 2002 03:07:41 -0400 (EDT) Message-ID: <3CF32C5C.EBB59A71@dynamicsoft.com> Date: Tue, 28 May 2002 03:06:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, Miguel Garcia Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > I'd like to request feedback on the expert review of > draft-garcia-sip-associated URI: > > Option: > > Yeah > Nay > Or Needs More Work > I think the draft is generally OK, but needs a bit more work. My main area of concern is the applicability statement. It really just repeats the semantics of the header. Really, the scope of applicability is more something like this: "This specification is applicable in SIP networks where the SIP provider is attempting to restrict the set of identities that a user can claim (in headers like the From field) in requests that it generates. It furthermore assumes that the provider knows the entire set of identities that a user can legitimately claim, and that the user is willing to restrict its claimed identities to that set. In normal SIP usage, the >From field is explicitly an end-user specified field. Effectively, this specification attempts to make it an end-user-specified and provider approved field. This specification also assumes a closed network model. The restriction of the From field (and other fields) to be among the list of approved values is enforced by a proxy in the domain of the caller. The specification provides no way to indicate or verify to downstream proxies or to the UAS that these fields have been limited in scope. As a result, this specification will only be useful in closed networks where elements know through configuration or administration that the fields have been restricted." I also think the security considerations section deserves some more attention. For one thing, I think that the information in this header is very sensitive. It exposes many additional identities for a user, which they might not otherwise want to divulge to everyone. For example, if the URI I register is sip:jdr@example.com, and everyone also has a valid URI which is their full name - sip:jonathan.rosenberg@example.com - eavesdropping the registrations will allow someone to learn my name. The draft alludes to this problem in the second paragraph, but it needs to strengthen the discussion and give specific examples like the one above. On an unrelated note, I must admit being baffled about why this is useful in a subscribe response. It seems like the associated URI are closely related to registrations, not subscriptions. Some minor points: 1. the syntax does not permit an empty value for the P-Associated-URI. What happens if there are no associated URI? If you simply omit the header altogetrher, how does the UA distinguish the case where the registrar doesn't support the extension, as opposed to the registrar has no associated URIs? 2. Is there an implicit assumption that the registrar will register the associated URI? I believe this is true in the 3gpp case. A UA probably needs to know whether they have been registered or not. I would not want to put a URI into a Reply-To header unless I knew it was a valid URI for receiving incoming calls.... 3. you write: > The registrar inserts the P-Associated-URI header into the 200 OK > response to a REGISTER request. The header is populated with a list of > URIs that are associated to the registered URI. probably "address-of-record" is better than "registered URI" in the above. 4. you write: > populate the From header value, or any other SIP header value that > provides information of the identity of the calling party, in a > subsequent dialog. s/subsequent dialog/subsequent request 5. you should probably have an explicit definition of associated URI. 6. you write: > 5.3 Procedures at the proxy > > This memo does not define any procedures at the proxy. > Well, presumably some proxy will enforce the list of associated-URI, and reject requests that have a value in the From field not amongst the allowed set? Is there a new response code for that? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 03:45:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10277 for ; Tue, 28 May 2002 03:45:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18394 for sip-archive@odin.ietf.org; Tue, 28 May 2002 03:45:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16665; Tue, 28 May 2002 03:22:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16634 for ; Tue, 28 May 2002 03:22:40 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10053 for ; Tue, 28 May 2002 03:22:16 -0400 (EDT) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 17CbJQ-0006SW-00; Tue, 28 May 2002 10:22:32 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15603.12344.116679.526241@lohi.eng.song.fi> Date: Tue, 28 May 2002 10:22:32 +0300 To: "Cullen Jennings" Cc: Subject: [Sip] draft-ietf-sip-asserted-identity-00 In-Reply-To: References: X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit once again: the term "hint" is not a good one. if user adds the a-i, then the network MUST respect it or reject the request. the network MUST not override the a-i and pick one of the identities on its own. for example, the user may have misspelled the its uri in the a-i. also, the text should say that in case from is anonymous the user MUST insert the a-i header if it has multiple identities, because otherwise the network cannot know which identity the user wants to use. finally, for backwards compatibility, if from is not anonymous and the user has multiple identities, then from uri can serve as the purpose of a-i. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 04:19:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10653 for ; Tue, 28 May 2002 04:19:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20622 for sip-archive@odin.ietf.org; Tue, 28 May 2002 04:19:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18721; Tue, 28 May 2002 03:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18683 for ; Tue, 28 May 2002 03:48:12 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10369 for ; Tue, 28 May 2002 03:47:47 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4S7lec30863 for ; Tue, 28 May 2002 03:47:41 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 02:47:35 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870367@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Tue, 28 May 2002 02:47:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-ietf-sip-privacy-general-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The following is a revision of my draft about privacy in SIP. Comments welcome, as always. http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.txt Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 06:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12048 for ; Tue, 28 May 2002 06:42:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29572 for sip-archive@odin.ietf.org; Tue, 28 May 2002 06:43:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27997; Tue, 28 May 2002 06:19:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27968 for ; Tue, 28 May 2002 06:19:55 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11790 for ; Tue, 28 May 2002 06:19:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SAJqmG013243 for ; Tue, 28 May 2002 12:19:52 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4SAJqgu011142 for ; Tue, 28 May 2002 13:19:52 +0300 (EET DST) Message-ID: <3CF359C6.126B596F@lmf.ericsson.se> Date: Tue, 28 May 2002 13:19:50 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] New version of the compression draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I have just submitted a new version of the SIP compression draft: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sip-compression-01.txt I have included an example and fixed a couple of things based on the feedback I have received so far. Regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 06:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12069 for ; Tue, 28 May 2002 06:43:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29587 for sip-archive@odin.ietf.org; Tue, 28 May 2002 06:43:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27864; Tue, 28 May 2002 06:18:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27833 for ; Tue, 28 May 2002 06:18:36 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11780 for ; Tue, 28 May 2002 06:18:10 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SAIK6n024727; Tue, 28 May 2002 12:18:20 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4SAIJgu011121; Tue, 28 May 2002 13:18:19 +0300 (EET DST) Message-ID: <3CF3596B.13D72E7@ericsson.com> Date: Tue, 28 May 2002 13:18:19 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2> <3CF32C5C.EBB59A71@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan: Thanks for your comments. See my answers inline. Jonathan Rosenberg wrote: > > Dean Willis wrote: > > > > I'd like to request feedback on the expert review of > > draft-garcia-sip-associated URI: > > > > Option: > > > > Yeah > > Nay > > Or Needs More Work > > > > I think the draft is generally OK, but needs a bit more work. My main > area of concern is the applicability statement. It really just repeats > the semantics of the header. Really, the scope of applicability is more > something like this: > > "This specification is applicable in SIP networks where the SIP provider > is attempting to restrict the set of identities that a user can claim > (in headers like the From field) in requests that it generates. It > furthermore assumes that the provider knows the entire set of identities > that a user can legitimately claim, and that the user is willing to > restrict its claimed identities to that set. In normal SIP usage, the > From field is explicitly an end-user specified field. Effectively, this > specification attempts to make it an end-user-specified and provider > approved field. > > This specification also assumes a closed network model. The restriction > of the From field (and other fields) to be among the list of approved > values is enforced by a proxy in the domain of the caller. The > specification provides no way to indicate or verify to downstream > proxies or to the UAS that these fields have been limited in scope. As a > result, this specification will only be useful in closed networks where > elements know through configuration or administration that the fields > have been restricted." So far so good. > I also think the security considerations section deserves some more > attention. For one thing, I think that the information in this header is > very sensitive. It exposes many additional identities for a user, which > they might not otherwise want to divulge to everyone. For example, if > the URI I register is sip:jdr@example.com, and everyone also has a valid > URI which is their full name - sip:jonathan.rosenberg@example.com - > eavesdropping the registrations will allow someone to learn my name. The > draft alludes to this problem in the second paragraph, but it needs to > strengthen the discussion and give specific examples like the one above. I will add this discussion to the security considerations. > On an unrelated note, I must admit being baffled about why this is > useful in a subscribe response. It seems like the associated URI are > closely related to registrations, not subscriptions. And in fact, the only usage in 3GPP is in registrations. But I got some comments that this may be useful in subscriptions as well. If nobody shouts, I will remove the usage of the header in subscriptions and restrict the scope to REGISTER only. > > Some minor points: > > 1. the syntax does not permit an empty value for the P-Associated-URI. > What happens if there are no associated URI? If you simply omit the > header altogetrher, how does the UA distinguish the case where the > registrar doesn't support the extension, as opposed to the registrar has > no associated URIs? Do we need to make a distinction between both cases? Either case, the user knows that no other identities are associated by the registrar, and therefore, explicit actions (e.g., REGISTER) has to be taken by the UAC. I am open to include an empty header, if it is needed. But I thought the consequences at the UAC are the same. > 2. Is there an implicit assumption that the registrar will register the > associated URI? I believe this is true in the 3gpp case. A UA probably > needs to know whether they have been registered or not. I would not want > to put a URI into a Reply-To header unless I knew it was a valid URI for > receiving incoming calls.... No, this is not the case. The "reg" event will provide such information. But the semantics of this header is just to provide a set of IDs that the user has associated to the address-of-record. They may or may not be registered, the user will know this information by other means (subscription to the registration event package). The user knows that he can initiate registration of any of the returned IDs, or it can populate the From with any of those IDs as well. That's it. We can clarify this if it is not clear enough. > 3. you write: > > > The registrar inserts the P-Associated-URI header into the 200 OK > > response to a REGISTER request. The header is populated with a list of > > URIs that are associated to the registered URI. > > probably "address-of-record" is better than "registered URI" in the > above. Sure. > > 4. you write: > > > populate the From header value, or any other SIP header value that > > provides information of the identity of the calling party, in a > > subsequent dialog. > > s/subsequent dialog/subsequent request > Done. > 5. you should probably have an explicit definition of associated URI. yeap. I'll add that. > 6. you write: > > > 5.3 Procedures at the proxy > > > > This memo does not define any procedures at the proxy. > > > > Well, presumably some proxy will enforce the list of associated-URI, and > reject requests that have a value in the From field not amongst the > allowed set? Is there a new response code for that? Yes, the proxy will send a 403 Forbidden. However, I don't think this is part of the scope of this I-D. I understand that the title "Procedures at the proxy" are procedures related to the extension (the header in this case). The idea in this I-D is to convey to the UA the list of URIs that he can use in subsequent requests, not how to police them. Therefore, there are not procedures at the proxy related to the P-Associated-URI header. Thanks a lot for your comments, Miguel > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 06:48:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12167 for ; Tue, 28 May 2002 06:48:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29951 for sip-archive@odin.ietf.org; Tue, 28 May 2002 06:49:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27795; Tue, 28 May 2002 06:17:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27772 for ; Tue, 28 May 2002 06:17:40 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11777 for ; Tue, 28 May 2002 06:17:14 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SAHYmG012448; Tue, 28 May 2002 12:17:35 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4SAHYgu011097; Tue, 28 May 2002 13:17:34 +0300 (EET DST) Message-ID: <3CF3593D.E6C2FE86@lmf.ericsson.se> Date: Tue, 28 May 2002 13:17:33 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip CC: Jonathan Rosemberg , Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] New version of the SIP over SCTP draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I have just submitted a new version of the SIP over SCTP draft. http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sctp-01.txt I have not changed anything. I have only updated the references (now they are divided into normative and informative ones). I am re-submitting this draft because its LC is scheduled for July, and version 00 expires in May 2002 (i.e., right now). Regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 09:59:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19068 for ; Tue, 28 May 2002 09:59:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15033 for sip-archive@odin.ietf.org; Tue, 28 May 2002 10:00:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12967; Tue, 28 May 2002 09:32:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12935 for ; Tue, 28 May 2002 09:32:17 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18007 for ; Tue, 28 May 2002 09:31:51 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4SDVaIZ010230; Tue, 28 May 2002 06:31:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABT02923; Tue, 28 May 2002 06:28:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA06007; Tue, 28 May 2002 06:31:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15603.34487.286237.10847@thomasm-u1.cisco.com> Date: Tue, 28 May 2002 06:31:35 -0700 (PDT) To: Jonathan Rosenberg Cc: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, Miguel Garcia Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri In-Reply-To: <3CF32C5C.EBB59A71@dynamicsoft.com> References: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2> <3CF32C5C.EBB59A71@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit So, I have a really dumb question. Why don't you limit the number of assertable identities by cryptographic means? That is, if I can't prove that I own an identity binding, it gets dumped on the floor? Mike Jonathan Rosenberg writes: > Dean Willis wrote: > > > > I'd like to request feedback on the expert review of > > draft-garcia-sip-associated URI: > > > > Option: > > > > Yeah > > Nay > > Or Needs More Work > > > > I think the draft is generally OK, but needs a bit more work. My main > area of concern is the applicability statement. It really just repeats > the semantics of the header. Really, the scope of applicability is more > something like this: > > "This specification is applicable in SIP networks where the SIP provider > is attempting to restrict the set of identities that a user can claim > (in headers like the From field) in requests that it generates. It > furthermore assumes that the provider knows the entire set of identities > that a user can legitimately claim, and that the user is willing to > restrict its claimed identities to that set. In normal SIP usage, the > >From field is explicitly an end-user specified field. Effectively, this > specification attempts to make it an end-user-specified and provider > approved field. > > This specification also assumes a closed network model. The restriction > of the From field (and other fields) to be among the list of approved > values is enforced by a proxy in the domain of the caller. The > specification provides no way to indicate or verify to downstream > proxies or to the UAS that these fields have been limited in scope. As a > result, this specification will only be useful in closed networks where > elements know through configuration or administration that the fields > have been restricted." > > > I also think the security considerations section deserves some more > attention. For one thing, I think that the information in this header is > very sensitive. It exposes many additional identities for a user, which > they might not otherwise want to divulge to everyone. For example, if > the URI I register is sip:jdr@example.com, and everyone also has a valid > URI which is their full name - sip:jonathan.rosenberg@example.com - > eavesdropping the registrations will allow someone to learn my name. The > draft alludes to this problem in the second paragraph, but it needs to > strengthen the discussion and give specific examples like the one above. > > On an unrelated note, I must admit being baffled about why this is > useful in a subscribe response. It seems like the associated URI are > closely related to registrations, not subscriptions. > > > > > > Some minor points: > > 1. the syntax does not permit an empty value for the P-Associated-URI. > What happens if there are no associated URI? If you simply omit the > header altogetrher, how does the UA distinguish the case where the > registrar doesn't support the extension, as opposed to the registrar has > no associated URIs? > > 2. Is there an implicit assumption that the registrar will register the > associated URI? I believe this is true in the 3gpp case. A UA probably > needs to know whether they have been registered or not. I would not want > to put a URI into a Reply-To header unless I knew it was a valid URI for > receiving incoming calls.... > > 3. you write: > > > The registrar inserts the P-Associated-URI header into the 200 OK > > response to a REGISTER request. The header is populated with a list of > > URIs that are associated to the registered URI. > > probably "address-of-record" is better than "registered URI" in the > above. > > 4. you write: > > > populate the From header value, or any other SIP header value that > > provides information of the identity of the calling party, in a > > subsequent dialog. > > s/subsequent dialog/subsequent request > > 5. you should probably have an explicit definition of associated URI. > > 6. you write: > > > 5.3 Procedures at the proxy > > > > This memo does not define any procedures at the proxy. > > > > Well, presumably some proxy will enforce the list of associated-URI, and > reject requests that have a value in the From field not amongst the > allowed set? Is there a new response code for that? > > > Thanks, > Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 10:14:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19648 for ; Tue, 28 May 2002 10:14:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16639 for sip-archive@odin.ietf.org; Tue, 28 May 2002 10:15:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14203; Tue, 28 May 2002 09:46:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14174 for ; Tue, 28 May 2002 09:46:45 -0400 (EDT) Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18573 for ; Tue, 28 May 2002 09:46:20 -0400 (EDT) Received: from deewana (pool-138-88-38-201.res.east.verizon.net [138.88.38.201]) by repulse.cnchost.com id JAA28996; Tue, 28 May 2002 09:46:40 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <001b01c2064f$f2df78f0$0100000a@nextone.com> From: "Medhavi Bhatia" To: Date: Tue, 28 May 2002 09:59:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] media source port in SDP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I remember there was a discussion some while back about specifying the source port for the media in the SDP. Is that standardized yet ? I am still seeing some vendors using the RFC 2327 format, and assuming that the source port for media will be the same as the receive port specified in the SDP. Is that correct or standardized somewhere ? Medhavi. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 10:38:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20428 for ; Tue, 28 May 2002 10:38:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18657 for sip-archive@odin.ietf.org; Tue, 28 May 2002 10:39:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16346; Tue, 28 May 2002 10:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16313 for ; Tue, 28 May 2002 10:09:52 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19403 for ; Tue, 28 May 2002 10:09:26 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4SE9Id13012; Tue, 28 May 2002 10:09:18 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA25971; Tue, 28 May 2002 09:09:17 -0500 (CDT) Message-ID: <3CF38F73.7010107@lucent.com> Date: Tue, 28 May 2002 09:08:51 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prabhas Sinha CC: Jeff Keyser , "SIP Mailing List (E-mail)" Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 References: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com> <389c01c205e3$273eb010$743c0198@ecew2k.ncsu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Prabhas Sinha wrote: > Thanks for bringing this up Jeff. I too had asked this question some time > back to Vijay Gurbani. > Even I am waiting to get some clarifications on it if I didnt understand > the model. The protocol state machine for the INVITE transaction is accurate as it stands (a fair amount of derivative work has been done based on it, so it's soundness is not an issue). To understand why the state machine is as shown, you need to recognize that the ACK to a 200 OK (INVITE) consists of a separate transaction entirely. It may be routed separatley from the INVITE that triggered it. ACKs for non-2xx responses to INVITE are considered part of the same transaction, and in fact, are propogated on a hop-by-hop basis. Hence, when the client state machine gets a 200 OK to an INVITE, it enters the Terminated state (since the ACK will be a new transaction). When the client state machine gets a non-2xx, it will generate the ACK and then enter the Terminated state. Hope that helps. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 11:52:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22714 for ; Tue, 28 May 2002 11:52:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23330 for sip-archive@odin.ietf.org; Tue, 28 May 2002 11:52:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21169; Tue, 28 May 2002 11:19:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21144 for ; Tue, 28 May 2002 11:19:32 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21654 for ; Tue, 28 May 2002 11:19:06 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA28627; Tue, 28 May 2002 17:19:14 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06275; Tue, 28 May 2002 17:19:28 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 17:19:30 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DE6@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'bcampbell@dynamicsoft.com'" Cc: sip@ietf.org Subject: [SIP] Provisional response for MESSAGE Date: Tue, 28 May 2002 17:19:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, The last paragraph of draft-ietf-sip-message-04 section 9 states that : "It has been suggested that provisional responses should not be used for pager-model MESSAGE requests. However, this is not possible, as many proxy servers will not be aware of the MESSAGE method, and will treat MESSAGE requests using the standard non-invite transaction. Additionally, prohibiting provisional responses may in some cases increase the number of retries, and actually make congestion problems worse. Therefore MESSAGE requests SHOULD receive the same provisional response treatment as any other non-INVITE method, as described in the SIP specification." But RFC 3261 (8.2.6.1 for UAS, 16.2 for stateful proxy, 16.11 stateless proxy) states that provisional response SHOULD NOT be issued for a non-INVITE request. So this is effectively 'prohibiting provisional responses' and 'may in some cases increase the number of retries'. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 12:16:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23621 for ; Tue, 28 May 2002 12:16:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26141 for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:16:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23309; Tue, 28 May 2002 11:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23232 for ; Tue, 28 May 2002 11:51:45 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22673; Tue, 28 May 2002 11:51:20 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 08:51:10 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 08:51:10 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 08:51:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 May 2002 08:51:10 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 28 May 2002 08:51:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 08:51:09 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIByNPUE2XbCWMZTheCqot6fIRBLgElfF6g From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 28 May 2002 15:51:09.0875 (UTC) FILETIME=[7C699830:01C2065F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23235 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I have a major issue with this spec, namely that the security problems are not addressed. The security section correctly lists one of the main security threats, the spoofing of a DHCP server: The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC 3263 [3] apply. If an adversary manages to modify the response from a DHCP server or insert its own response, a SIP user agent could be led to contact a rogue SIP server, possibly one that then intercepts call requests or denies service. A modified DHCP answer could also omit host names that translated to TLS-based SIP servers, thus facilitating intercept. This is a very real attack, especially in the deployment phase of IPv6, when there may not even be an actual DHCPv6 server on the local network. Think for example of an 802.11 hotpoint, in which any enterprising attacker could publish his very own DHCPv6 server. Yet, the security work seems to stop here. There is no attempt at mitigating the attack. IMHO, we should not publish a spec that open the door for a grave attack and offers no mitigation. -- Christian Huitema > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, May 22, 2002 12:21 PM > Cc: sip@ietf.org > Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed > Standard > > > The IESG has received a request from the Session Initiation Protocol > Working Group to consider DHCPv6 Options for SIP Servers > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 12:48:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24405 for ; Tue, 28 May 2002 12:48:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28371 for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:48:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26614; Tue, 28 May 2002 12:22:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26537 for ; Tue, 28 May 2002 12:22:47 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23827; Tue, 28 May 2002 12:22:21 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA06444; Tue, 28 May 2002 12:22:40 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SGMd2i012740 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 May 2002 12:22:39 -0400 (EDT) Message-ID: <3CF3AEB2.5020702@cs.columbia.edu> Date: Tue, 28 May 2002 12:22:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: iesg@ietf.org, sip@ietf.org Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian, thanks for your comment. I'm slightly confused, however, why this particular problem is any different for SIP servers than for any other, non-SIP server identified by a DHCPv6 server. Also, Section 21 of http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-25.txt addresses this particular issue. Could you clarify your comments in these two aspects? Henning Christian Huitema wrote: > I have a major issue with this spec, namely that the security problems > are not addressed. The security section correctly lists one of the main > security threats, the spoofing of a DHCP server: > > The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC > 3263 [3] apply. If an adversary manages to modify the response from a > DHCP server or insert its own response, a SIP user agent could be led > to contact a rogue SIP server, possibly one that then intercepts call > requests or denies service. A modified DHCP answer could also omit > host names that translated to TLS-based SIP servers, thus > facilitating intercept. > > This is a very real attack, especially in the deployment phase of IPv6, > when there may not even be an actual DHCPv6 server on the local network. > Think for example of an 802.11 hotpoint, in which any enterprising > attacker could publish his very own DHCPv6 server. Yet, the security > work seems to stop here. There is no attempt at mitigating the attack. > IMHO, we should not publish a spec that open the door for a grave attack > and offers no mitigation. > > -- Christian Huitema > > >>-----Original Message----- >>From: The IESG [mailto:iesg-secretary@ietf.org] >>Sent: Wednesday, May 22, 2002 12:21 PM >>Cc: sip@ietf.org >>Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed >>Standard >> >> >>The IESG has received a request from the Session Initiation Protocol >>Working Group to consider DHCPv6 Options for SIP Servers >> as a Proposed Standard. >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002. >> >>Files can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt >> >> >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 12:50:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24535 for ; Tue, 28 May 2002 12:50:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28525 for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:50:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26734; Tue, 28 May 2002 12:24:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26700 for ; Tue, 28 May 2002 12:24:06 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23890 for ; Tue, 28 May 2002 12:23:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SGOxYH025062; Tue, 28 May 2002 12:24:59 -0400 (EDT) Message-ID: <3CF3AEF9.EF57314C@dynamicsoft.com> Date: Tue, 28 May 2002 12:23:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, Miguel Garcia Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <15603.34487.286237.10847@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > So, I have a really dumb question. Why don't you > limit the number of assertable identities by > cryptographic means? That is, if I can't prove > that I own an identity binding, it gets dumped > on the floor? Sure; I think the issue (Miguel can correct me if I'm wrong), is that the UA needs to be configured with the set of identities it can claim in the first place. The same credentials would allow the user to assert any one of those, but the phone needs to know which it should present to the user to use. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 12:51:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24573 for ; Tue, 28 May 2002 12:51:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28647 for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:51:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27474; Tue, 28 May 2002 12:31:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27450 for ; Tue, 28 May 2002 12:31:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24093 for ; Tue, 28 May 2002 12:31:01 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SGWJYH025117; Tue, 28 May 2002 12:32:19 -0400 (EDT) Message-ID: <3CF3B0B1.F176F2F4@dynamicsoft.com> Date: Tue, 28 May 2002 12:30:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <3CF3596B.13D72E7@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Miguel A. Garcia" wrote: > > > On an unrelated note, I must admit being baffled about why this is > > useful in a subscribe response. It seems like the associated URI are > > closely related to registrations, not subscriptions. > > And in fact, the only usage in 3GPP is in registrations. But I got > some comments that this may be useful in subscriptions as well. If > nobody > shouts, I will remove the usage of the header in subscriptions and > restrict > the scope to REGISTER only. Yes, please. I think we should strive to limit scope for P-headers, not the other way around. This is especially true when the motivating need is not even clear. > > 1. the syntax does not permit an empty value for the P-Associated-URI. > > What happens if there are no associated URI? If you simply omit the > > header altogetrher, how does the UA distinguish the case where the > > registrar doesn't support the extension, as opposed to the registrar > has > > no associated URIs? > > Do we need to make a distinction between both cases? Either case, the > user knows that no other identities are associated by the registrar, > and therefore, explicit actions (e.g., REGISTER) has to be taken by > the UAC. I thought you indicated below that this extension did not imply the registration of the associated identities... That aside, it does make a difference. The UA needs to know whether it can put any identity it likes in the From field (since the network is not trying to impose restrictions on the set), or whether it can't put any identity except the one it registered (since the network is imposing restrictions, and there is just one valid identity). > > 2. Is there an implicit assumption that the registrar will register > the > > associated URI? I believe this is true in the 3gpp case. A UA probably > > needs to know whether they have been registered or not. I would not > want > > to put a URI into a Reply-To header unless I knew it was a valid URI > for > > receiving incoming calls.... > > No, this is not the case. The "reg" event will provide such information. > But the semantics of this header is just to provide a set of IDs that > the > user has associated to the address-of-record. They may or may not be > registered, > the user will know this information by other means (subscription to the > registration event package). The user knows that he can initiate > registration > of any of the returned IDs, or it can populate the From with any of > those > IDs as well. That's it. Presumably the UA will need to make sure that they are registered; you should probably note in the draft that there is no assumption that the associated URI are registered, and that if the UA wants that, it should check and perform the registrations if needed. > > > 5.3 Procedures at the proxy > > > > > > This memo does not define any procedures at the proxy. > > > > > > > Well, presumably some proxy will enforce the list of associated-URI, > and > > reject requests that have a value in the From field not amongst the > > allowed set? Is there a new response code for that? > > Yes, the proxy will send a 403 Forbidden. However, I don't think this is > > part of the scope of this I-D. I understand that the title "Procedures > at > the proxy" are procedures related to the extension (the header in this > case). > The idea in this I-D is to convey to the UA the list of URIs that he can > use > in subsequent requests, not how to police them. Therefore, there are not > procedures at the proxy related to the P-Associated-URI header. Well, its all intertwined. The associated-URI list is the only way a UA has to retry if it should get this error, since it conveys the allowed URI in the first place. Actually, 403 is really NOT the right response. If it gets this, how does the UA recover? It needs to know that the problem was a disallowed From value, and it needs to know which ones are OK. I would argue that the way to deal with this is a new response code that would contain in it the Associated-URI header indicating which ones are allowed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 13:04:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25022 for ; Tue, 28 May 2002 13:04:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29716 for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28056; Tue, 28 May 2002 12:44:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28030 for ; Tue, 28 May 2002 12:44:34 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24283 for ; Tue, 28 May 2002 12:44:09 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SGj2YH025130; Tue, 28 May 2002 12:45:02 -0400 (EDT) Message-ID: <3CF3B3AC.48C27A59@dynamicsoft.com> Date: Tue, 28 May 2002 12:43:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, hgs@cs.columbia.edu Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6 References: <004801c201b8$8b4f1060$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit One comment. One of the things we need to be striving for is to move everything consistently towards the usage of loose routing for sending requests through intermediate hops. This has countless benefits, primarily derived from the ability to associate parameters and other information with the loose route URI. A local outbound proxy is most definitely a hop that can be specified with a loose route. So, while bis does allow a UAC to simply send requests to a configured IP/FQDN rather than use loose routing, it recommends loose routing. So, my question is this: why don't we specify that the DHCP option provides you a URI that is used as a loose route, and not a domain name/IP address? Wouldn't that handle v6,v4 domain names and everything else? Also, I suspect that in many cases, local outbound proxies will be doing compression. How does the client know whether it can send compressed sip messages to its proxy? Well, we have a URI parameter for this purpose: http://search.ietf.org/internet-drafts/draft-camarillo-sip-sigcomp-00.txt Thus, if the client learns about the local outbound proxy through a URI, it will be able to learn whether it supports compression. If only the address/domain name are provided, separate means are needed to learn about support for compression. Thanks, Jonathan R. Dean Willis wrote: > > We started working group last call of the sip-dhcpv6 draft on May 2. > There has been no negative veedback that I'm aware of, so let's call > WGLC complete and request IETF Last Call. > > http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 13:15:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25435 for ; Tue, 28 May 2002 13:15:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00487 for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:15:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28613; Tue, 28 May 2002 12:50:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28540 for ; Tue, 28 May 2002 12:50:43 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24539; Tue, 28 May 2002 12:50:17 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 09:50:11 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 09:50:11 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 09:50:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 May 2002 09:50:10 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 28 May 2002 09:50:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 09:50:09 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIGY+cZgCz9UYC8TO+NqTOeZsi1HwAAayzA From: "Christian Huitema" To: "Henning Schulzrinne" Cc: , X-OriginalArrivalTime: 28 May 2002 16:50:10.0190 (UTC) FILETIME=[BA9ACAE0:01C20667] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA28542 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit There are multiple issues with your reference to the DHCPv6 draft. First, let me observe that the DHCPv6 draft proposes two security solutions, the use of "delayed authentication", which relies on a pre-shared key, and the use of IPSEC, for which key negotiation and key validation is not specified. At a minimum, the SIP option draft should explain how these mechanisms can be used to mitigate the SIP-specific security risks. We should also explain in which contexts these security mechanisms can be used. For example, the DHCPv6 draft states that: The "delayed authentication" protocol does not attempt to address situations where a client may roam from one administrative domain to another, i.e. interdomain roaming. This protocol is focused on solving the intradomain problem where the out-of-band exchange of a shared key is feasible. Shall we conclude that the SIP option should not be used in roaming scenarios? If that is the case, then we have a serious application domain restriction, which should be very clearly stated in the SIP option draft. If you actually want to address a roaming scenario, then you have to describe how you are going to use IPSEC between the server and the client, and how you are going to validate the IPSEC keys. The DHCPv6 document itself is still a draft. Since you need a normative reference, the publication of the SIP option has to be gated by the publication of DHCPv6 itself. Finally, there are security issues with the very concept of an outgoing proxy, which is essentially a "man-in-the-middle" by design. I would expect SIP agents to perform some level of validation before they decide to use the outgoing proxy proposed by the local network. In most roaming scenarios, the SIP agent will probably elect to simply maintain a secure connection with its "home server", and ignore the local proxy -- just like most mail agent simply get their mail using an IMAP or POP3 connection to their mail server, instead of forwarding the mail to a local server. -- Christian Huitema > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, May 28, 2002 9:22 AM > To: Christian Huitema > Cc: iesg@ietf.org; sip@ietf.org > Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed > Standard > > Christian, > > thanks for your comment. I'm slightly confused, however, why this > particular problem is any different for SIP servers than for any other, > non-SIP server identified by a DHCPv6 server. Also, Section 21 of > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-25.txt > addresses this particular issue. Could you clarify your comments in > these two aspects? > > Henning > > Christian Huitema wrote: > > I have a major issue with this spec, namely that the security problems > > are not addressed. The security section correctly lists one of the main > > security threats, the spoofing of a DHCP server: > > > > The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC > > 3263 [3] apply. If an adversary manages to modify the response from a > > DHCP server or insert its own response, a SIP user agent could be led > > to contact a rogue SIP server, possibly one that then intercepts call > > requests or denies service. A modified DHCP answer could also omit > > host names that translated to TLS-based SIP servers, thus > > facilitating intercept. > > > > This is a very real attack, especially in the deployment phase of IPv6, > > when there may not even be an actual DHCPv6 server on the local network. > > Think for example of an 802.11 hotpoint, in which any enterprising > > attacker could publish his very own DHCPv6 server. Yet, the security > > work seems to stop here. There is no attempt at mitigating the attack. > > IMHO, we should not publish a spec that open the door for a grave attack > > and offers no mitigation. > > > > -- Christian Huitema > > > > > >>-----Original Message----- > >>From: The IESG [mailto:iesg-secretary@ietf.org] > >>Sent: Wednesday, May 22, 2002 12:21 PM > >>Cc: sip@ietf.org > >>Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed > >>Standard > >> > >> > >>The IESG has received a request from the Session Initiation Protocol > >>Working Group to consider DHCPv6 Options for SIP Servers > >> as a Proposed Standard. > >> > >>The IESG plans to make a decision in the next few weeks, and solicits > >>final comments on this action. Please send any comments to the > >>iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002. > >> > >>Files can be obtained via > >>http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 13:38:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26167 for ; Tue, 28 May 2002 13:38:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02161 for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:39:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00438; Tue, 28 May 2002 13:13:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00413 for ; Tue, 28 May 2002 13:13:04 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25341 for ; Tue, 28 May 2002 13:12:38 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA10649; Tue, 28 May 2002 13:12:41 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SHCe2i015117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 May 2002 13:12:40 -0400 (EDT) Message-ID: <3CF3BA6A.7090700@cs.columbia.edu> Date: Tue, 28 May 2002 13:12:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6 References: <004801c201b8$8b4f1060$1d036e3f@TXDWILLIS2> <3CF3B3AC.48C27A59@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree that this would be useful, albeit a bit unusual compared to other DHCP options. There are a few issues that would need to be resolved: - Would this apply to v6 only? I don't know that the state of the v4 draft is in the IESG pipeline and what other "customers" there are. This would be the first DHCP option containing a URI, so this may cause some broader issues. - It would be possible to add this mode as a third mechanism on top of the existing two (either as the byte identifier in v4 or as top-level items in v6) in both v4 and v6. That would seem to be the least likely to cause hick-ups. - As the only mode, URIs would not be amenable to DNS host name compression, so this is not quite equivalent. I suspect that that is a minor issue. Jonathan Rosenberg wrote: > One comment. > > One of the things we need to be striving for is to move everything > consistently towards the usage of loose routing for sending requests > through intermediate hops. This has countless benefits, primarily > derived from the ability to associate parameters and other information > with the loose route URI. A local outbound proxy is most definitely a > hop that can be specified with a loose route. So, while bis does allow a > UAC to simply send requests to a configured IP/FQDN rather than use > loose routing, it recommends loose routing. > > So, my question is this: why don't we specify that the DHCP option > provides you a URI that is used as a loose route, and not a domain > name/IP address? Wouldn't that handle v6,v4 domain names and everything > else? > > Also, I suspect that in many cases, local outbound proxies will be doing > compression. How does the client know whether it can send compressed sip > messages to its proxy? Well, we have a URI parameter for this purpose: > > http://search.ietf.org/internet-drafts/draft-camarillo-sip-sigcomp-00.txt > > Thus, if the client learns about the local outbound proxy through a URI, > it will be able to learn whether it supports compression. If only the > address/domain name are provided, separate means are needed to learn > about support for compression. > > Thanks, > Jonathan R. > > Dean Willis wrote: > >>We started working group last call of the sip-dhcpv6 draft on May 2. >>There has been no negative veedback that I'm aware of, so let's call >>WGLC complete and request IETF Last Call. >> >>http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt >> >>-- >>Dean >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 13:55:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26590 for ; Tue, 28 May 2002 13:55:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03271 for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:56:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01779; Tue, 28 May 2002 13:31:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01709 for ; Tue, 28 May 2002 13:31:44 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26014; Tue, 28 May 2002 13:31:18 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA12336; Tue, 28 May 2002 13:31:41 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SHVe2i015906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 May 2002 13:31:40 -0400 (EDT) Message-ID: <3CF3BEDE.4060703@cs.columbia.edu> Date: Tue, 28 May 2002 13:31:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: iesg@ietf.org, sip@ietf.org Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The "delayed authentication" protocol does not attempt to address > situations where a client may roam from one administrative domain > to another, i.e. interdomain roaming. This protocol is focused on > solving the intradomain problem where the out-of-band exchange of a > shared key is feasible. > > Shall we conclude that the SIP option should not be used in roaming > scenarios? If that is the case, then we have a serious application > domain restriction, which should be very clearly stated in the SIP > option draft. If you actually want to address a roaming scenario, then > you have to describe how you are going to use IPSEC between the server > and the client, and how you are going to validate the IPSEC keys. It would be helpful to have the 3G folks chime in here. Realistically, we aren't going to be developing new IPsec key distribution protocols for this application, but 3G may already have to deliver a shared secret in a remote (away from home) environment. As a side note, I find this restriction a rather serious one beyond SIP: After all, DHCP is most useful when I'm away from my home network. In my home network, I can easily configure things statically. > > The DHCPv6 document itself is still a draft. Since you need a normative > reference, the publication of the SIP option has to be gated by the > publication of DHCPv6 itself. That is clearly the case. I'm sure the IESG will ensure that :-) > > Finally, there are security issues with the very concept of an outgoing > proxy, which is essentially a "man-in-the-middle" by design. I would > expect SIP agents to perform some level of validation before they decide > to use the outgoing proxy proposed by the local network. In most roaming > scenarios, the SIP agent will probably elect to simply maintain a secure > connection with its "home server", and ignore the local proxy -- just > like most mail agent simply get their mail using an IMAP or POP3 > connection to their mail server, instead of forwarding the mail to a > local server. There are lots of proxies that the caller has no control over (among others, any proxies in the callee's domain), so this is hardly new. They may not have a choice if the local outbound proxy controls the firewall. Thus, having a secure connection to a home proxy might get the SIP packets through, but will make for a rather silent phone conversation. > > -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 14:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27207 for ; Tue, 28 May 2002 14:20:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04770 for sip-archive@odin.ietf.org; Tue, 28 May 2002 14:20:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04069; Tue, 28 May 2002 14:02:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04043 for ; Tue, 28 May 2002 14:02:19 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26711 for ; Tue, 28 May 2002 14:01:53 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A62893200306; Tue, 28 May 2002 14:02:16 -0400 Message-ID: <002001c20671$db2b14e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Miguel A. Garcia" , "Tan Ya-Ching ICM N PG U ID A 1" Cc: References: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e> <3CF1FC20.3CFDAEE6@ericsson.com> Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01 Date: Tue, 28 May 2002 14:02:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A couple follow-ups and one new comment below ----- Original Message ----- From: "Miguel A. Garcia" > Tan Ya-Ching ICM N PG U ID A 1 wrote: > > > > | > I do not see how these statements meet the requirement of > > | [3], which > > | > states : > > | > > > | > "An applicability statement in the Informational RFC MUST > > | > clearly document the useful scope of the proposal, and explain > > | > its limitations and why it is not suitable for the general use > > | > of SIP in the Internet." > > | > > | > > | My effort was to scope as much as possible this header. It is suitable > > | for the general use of SIP in the Internet, so I have nothing else to > > | say. > > | > > > > If it is suitable for the general use, why a P-header ? > > > Because so far nobody else has the requirement as we expressed. > That's why we are going for a P- header. But the extension itself > is not restricted to 3GPP. It is generally applicable to the Internet. > Does the fact that one would want to use P-Called-Party-ID when they cannot (or will not) rely on the To field, need be included in the applicability statement? > > > | > o The term "standalone method" is not defined in SIP RFC. > > | > > | > > | I'll fix it somehow, but I think that the term standalone, > > | although not define in RFC 3261, is understandable by the > > | reader familiar with SIP. > > | > > > > RFC 3261 even defines terms such as "Message", "Parallel Search". One simply > > can't start using a new term like "standalone request" or "standalone > > transaction request" and assume that it is 'understandable by the reader > > familiar with SIP'. > > > > Yes, I understand your comment. I will do my best to make it > clear what it means in the next version. > I think what you are trying to say is that the P-Called-Party-ID can be inserted in any request that initiates a dialog, or any request that is completely outside of a dialog. These should be the only requests that would have been issued with an AOR type Request-URI that a proxy would replace. All other requests (those within an existing dialog) would have a Request-URI equal to a URI that the UA learned from a Contact header in the request/response that created the dialog. Is this correct? New issue: In the header field table in Section 5, shouldn't the header be optional for a SUBSCRIBE and not allowed for a NOTIFY? SUBSCRIBE initiates a dialog, and NOTIFY should use the value from the Contact of the SUBSCRIBE for the R-URI (thus R-URI would not be changed by a proxy). cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 14:50:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27835 for ; Tue, 28 May 2002 14:50:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06661 for sip-archive@odin.ietf.org; Tue, 28 May 2002 14:51:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05810; Tue, 28 May 2002 14:32:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05739 for ; Tue, 28 May 2002 14:32:03 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27485 for ; Tue, 28 May 2002 14:31:39 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SIUkd11494; Tue, 28 May 2002 13:30:46 -0500 From: "Dean Willis" To: "'Juha Heinanen'" , "'Cullen Jennings'" Cc: Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 Date: Tue, 28 May 2002 13:30:06 -0500 Message-ID: <00ac01c20675$b0e01150$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <15603.12344.116679.526241@lohi.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha wrote: > once again: > > the term "hint" is not a good one. if user adds the a-i, > then the network MUST respect it or reject the request. the > network MUST not override the a-i and pick one of the > identities on its own. for example, the user may have > misspelled the its uri in the a-i. > > also, the text should say that in case from is anonymous the > user MUST insert the a-i header if it has multiple > identities, because otherwise the network cannot know which > identity the user wants to use. > > finally, for backwards compatibility, if from is not > anonymous and the user has multiple identities, then from uri > can serve as the purpose of a-i. Oh my! I think Juha is absolutely correct, in the nost common case. Of course, there may be other cases. Commonly, the UA asserts an identity. If it has credentials to do so (say, a cert issued by a trusted CA) it MAY use those credentials to provide support for its assertion. An intermediate service node (authentication or identification server) MAY also support the assertion by applying its own credentials. In the common case, the identification server would be expected to support the assertion made by the UA if the UA made any assertion of identity. If the UA doesn't assert identity with a-i, then one might consider the "from" field as a lower-strength assertion of identity, and the identification server could cryptographically support that identity. One could also establish the identity to be asserted based on the identity used in authentication (with digest, for example) or as a matter of policy (the user didn't say, so they get their "default" identity asserted). Of course, there may be special agreements between the user and the identification server which fall outside this common usage. Consider, for example, the "anonymization server". Such a server might strip away all other user identity information, substituting a "stage name" (say, "sip:userx@anonymizer.com"), which would then be cryptographically supported by the server. Such a construction would not be depdendent on any kind of "hinting" mechanism. It would have the advantage of traceability and nonrepudiability back to the anonymizer service, which could then (if needed) provide reachability back to the actual user. This application, while not the general case, does represent a mode in which the requirements put forth by Juha in the above text do not actually apply. So I think it important to differentiate the common usage from the possible usage. This suggests softening some of the MUSTs suggested by Juha into SHOULDs, accompanied by appropriate discussion of the possible use cases. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:28:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28417 for ; Tue, 28 May 2002 15:28:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09240 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:29:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07955; Tue, 28 May 2002 15:09:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07921 for ; Tue, 28 May 2002 15:09:01 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28174 for ; Tue, 28 May 2002 15:08:36 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SJ8THs018750 for ; Tue, 28 May 2002 12:08:29 -0700 (PDT) Received: from cisco.com (rtp-vpn2-439.cisco.com [10.82.241.183]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03218 for ; Tue, 28 May 2002 12:08:21 -0700 (PDT) Message-ID: <3CF3D5A4.18AA6208@cisco.com> Date: Tue, 28 May 2002 15:08:20 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "'sip@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Updated call-auth draft with one change Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Greetings As a result of IESG review, we have updated the call-auth draft which you can now get from http://search.ietf.org/internet-drafts/draft-ietf-sip-call-auth-06.txt While incorporating the IESG comments, we discovered, that with the grammar change from the -04 to -05, it no longer made sense to include the Length field from the RFC 2750 Policy Element. Consequently, the document now says, that the Length field is excluded. I thought you might like to know that. Regards Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:41:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28886 for ; Tue, 28 May 2002 15:41:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10676 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:41:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09014; Tue, 28 May 2002 15:25:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08944 for ; Tue, 28 May 2002 15:25:12 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28341 for ; Tue, 28 May 2002 15:24:47 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNud11774; Tue, 28 May 2002 14:23:56 -0500 From: "Dean Willis" To: "'Miguel A. Garcia'" , "'Jonathan Rosenberg'" Cc: , , , Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Date: Tue, 28 May 2002 14:23:13 -0500 Message-ID: <00b001c2067d$1e30aba0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CF3596B.13D72E7@ericsson.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Miguel said: > Jonathan said: > > Well, presumably some proxy will enforce the list of > associated-URI, > > and reject requests that have a value in the From field not amongst > > the allowed set? Is there a new response code for that? > > Yes, the proxy will send a 403 Forbidden. However, I don't > think this is > part of the scope of this I-D. I understand that the title > "Procedures at the proxy" are procedures related to the > extension (the header in this case). The idea in this I-D is > to convey to the UA the list of URIs that he can use > in subsequent requests, not how to police them. Therefore, > there are not procedures at the proxy related to the > P-Associated-URI header. Actually, this policy enforcement is being made by the 3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like-a- proxy called the P-CSCF. Documenting the behavior of this rather specalized node is probably far outside the scope of an IETF effort. Proxies, in general, are not expected to restrict the range of identity expression allowed to a user based on some sort of P-header. In fact, one might argue that proxies in general are PROHIBITED from doing this sort of thing . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:42:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28938 for ; Tue, 28 May 2002 15:42:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10761 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:43:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09134; Tue, 28 May 2002 15:27:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09095 for ; Tue, 28 May 2002 15:27:22 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28362 for ; Tue, 28 May 2002 15:26:58 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJRmYH025293; Tue, 28 May 2002 15:27:48 -0400 (EDT) Message-ID: <3CF3D9D4.BFE306AC@dynamicsoft.com> Date: Tue, 28 May 2002 15:26:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6 References: <3CF3BA6A.7090700@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I agree that this would be useful, albeit a bit unusual compared to > other DHCP options. There are a few issues that would need to be > resolved: > > - Would this apply to v6 only? I don't know that the state of the v4 > draft is in the IESG pipeline and what other "customers" there are. This > > would be the first DHCP option containing a URI, so this may cause some > broader issues. Understood. Its definitely not v6 specific. Maybe we need to define it separately because its too late or controversial. My main point is that technically, I think it is far superior to using IP addresses or domain names. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:43:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28955 for ; Tue, 28 May 2002 15:43:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10776 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:43:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08743; Tue, 28 May 2002 15:24:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08666 for ; Tue, 28 May 2002 15:24:28 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28308; Tue, 28 May 2002 15:24:04 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNtd11771; Tue, 28 May 2002 14:23:56 -0500 From: "Dean Willis" To: "'Christian Huitema'" , Cc: Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 14:23:13 -0500 Message-ID: <00af01c2067d$1da42310$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian wrote: > I have a major issue with this spec, namely that the security > problems are not addressed. The security section correctly > lists one of the main security threats, the spoofing of a DHCP server: Yes, this is a real issue. But isn't this sort of a general DHCP problem rather than one specific to the usage of SIP? Do we need to bascially stop using DHCP while working on it, and if so is this (SIP working group) the right forum to try and tackle that? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:44:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29001 for ; Tue, 28 May 2002 15:44:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10823 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:44:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08976; Tue, 28 May 2002 15:25:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08910 for ; Tue, 28 May 2002 15:25:08 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28339 for ; Tue, 28 May 2002 15:24:43 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNvd11777; Tue, 28 May 2002 14:23:57 -0500 From: "Dean Willis" To: "'Jonathan Rosenberg'" , "'Michael Thomas'" Cc: , , , , "'Miguel Garcia'" Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Date: Tue, 28 May 2002 14:23:13 -0500 Message-ID: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CF3AEF9.EF57314C@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Michael Thomas wrote: > > > > So, I have a really dumb question. Why don't you > > limit the number of assertable identities by > > cryptographic means? That is, if I can't prove > > that I own an identity binding, it gets dumped > > on the floor? > > Sure; I think the issue (Miguel can correct me if I'm wrong), > is that the UA needs to be configured with the set of > identities it can claim in the first place. The same > credentials would allow the user to assert any one of those, > but the phone needs to know which it should present to the > user to use. It goes a little further than this. We're also informing the UA of a number of extisting "aliases". The UA can expect to see calls "To:" any of these aliases, and needs to delivery them appropriately to the user as direct calls rather than as calls targeted originally to some other user that have just been forwarded here. This might interact with distinctive-ringing features, for example. So there is applicability in both "UA-originated" and UA-terminated" scenarios, and there is no requirement that the client be able to cryptographically assert the identity associated with an inbound alias. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:44:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29022 for ; Tue, 28 May 2002 15:44:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10852 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:44:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08942; Tue, 28 May 2002 15:25:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08896 for ; Tue, 28 May 2002 15:25:05 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28337 for ; Tue, 28 May 2002 15:24:40 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNsd11763; Tue, 28 May 2002 14:23:54 -0500 From: "Dean Willis" To: "'Gonzalo Camarillo'" , "'sip'" Cc: "'Jonathan Rosemberg'" , "'Henning Schulzrinne'" Subject: RE: [Sip] New version of the SIP over SCTP draft Date: Tue, 28 May 2002 14:23:13 -0500 Message-ID: <00ad01c2067d$1ccb2830$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CF3593D.E6C2FE86@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Warning! There appears to be a revision numbering issue. I have a file by the same name on the supplemental site which appears to have been published last November. http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-sctp-01.txt Which replaced http://www.softarmor.com/sipwg/drafts/morgue/draft-ietf-sip-sctp-00.txt published last August. Perhaps the latest rev should be -02? -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Tuesday, May 28, 2002 5:18 AM > To: sip > Cc: Jonathan Rosemberg; Henning Schulzrinne > Subject: [Sip] New version of the SIP over SCTP draft > > > Hello, > > I have just submitted a new version of the SIP over SCTP draft. > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sctp-01.txt I have not changed anything. I have only updated the references (now they are divided into normative and informative ones). I am re-submitting this draft because its LC is scheduled for July, and version 00 expires in May 2002 (i.e., right now). Regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:45:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29042 for ; Tue, 28 May 2002 15:45:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10871 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:45:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08894; Tue, 28 May 2002 15:25:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08815 for ; Tue, 28 May 2002 15:24:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28328; Tue, 28 May 2002 15:24:34 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNtd11766; Tue, 28 May 2002 14:23:55 -0500 From: "Dean Willis" To: "'Henning Schulzrinne'" , "'Christian Huitema'" Cc: , Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 14:23:13 -0500 Message-ID: <00ae01c2067d$1d5abe00$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CF3BEDE.4060703@cs.columbia.edu> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Shall we conclude that the SIP option should not be used in roaming > > scenarios? If that is the case, then we have a serious application > > domain restriction, which should be very clearly stated in the SIP > > option draft. If you actually want to address a roaming > scenario, then > > you have to describe how you are going to use IPSEC between > the server > > and the client, and how you are going to validate the IPSEC keys. > > It would be helpful to have the 3G folks chime in here. > Realistically, > we aren't going to be developing new IPsec key distribution protocols > for this application, but 3G may already have to deliver a > shared secret > in a remote (away from home) environment. In the 3GPP scenario, there is a security negotiation process used after the default proxy is selected. This, within reasonable usage of the term "assures", assures that the selected default proxy is within the trust domain of the subscriber's home network. Very roughly speaking, a piece of the AKA key is transferred along a transititive IPSEC chain to the visited proxy, and the UA will not achieve successful communication with the visited proxy unless it has that key. This would seem to prevent proxy spoofing, within the limits imposed by the transitive-trust model of 3GPP. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:47:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29116 for ; Tue, 28 May 2002 15:47:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11114 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:48:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10057; Tue, 28 May 2002 15:32:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10025 for ; Tue, 28 May 2002 15:32:07 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28567 for ; Tue, 28 May 2002 15:31:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJX2YH025297; Tue, 28 May 2002 15:33:02 -0400 (EDT) Message-ID: <3CF3DB0E.215085E3@dynamicsoft.com> Date: Tue, 28 May 2002 15:31:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Miguel A. Garcia'" , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <00b001c2067d$1e30aba0$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Miguel said: > > Jonathan said: > > > Well, presumably some proxy will enforce the list of > > associated-URI, > > > and reject requests that have a value in the From field not amongst > > > the allowed set? Is there a new response code for that? > > > > Yes, the proxy will send a 403 Forbidden. However, I don't > > think this is > > part of the scope of this I-D. I understand that the title > > "Procedures at the proxy" are procedures related to the > > extension (the header in this case). The idea in this I-D is > > to convey to the UA the list of URIs that he can use > > in subsequent requests, not how to police them. Therefore, > > there are not procedures at the proxy related to the > > P-Associated-URI header. > > Actually, this policy enforcement is being made by the > 3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like-a- > proxy called the P-CSCF. Documenting the behavior of this rather > specalized node is probably far outside the scope of an IETF effort. > Proxies, in general, are not expected to restrict the range of identity > expression allowed to a user based on some sort of P-header. In fact, > one might argue that proxies in general are PROHIBITED from doing this > sort of thing . . . Well, that enforcement IS being done, and I thought was core to the entire concept here. Indeed, this is the essence of what I suggested for the new applicability statement. My point is, if you are doing such restrictions, you need to have a response code appropriate for this error case. I will also note that of all things proxies are doing these days, rejecting a call because the From is not authorized is the least evil. Indeed, one might argue that this is equivalent to sip level ingress address filtering (RFC 2827), and is possibly a very good thing to do. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 15:51:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29207 for ; Tue, 28 May 2002 15:51:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11422 for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:52:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10167; Tue, 28 May 2002 15:32:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10131 for ; Tue, 28 May 2002 15:32:39 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28598 for ; Tue, 28 May 2002 15:32:14 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJXZYH025300; Tue, 28 May 2002 15:33:35 -0400 (EDT) Message-ID: <3CF3DB2F.E9D91D75@dynamicsoft.com> Date: Tue, 28 May 2002 15:31:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Michael Thomas'" , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, "'Miguel Garcia'" Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > Michael Thomas wrote: > > > > > > So, I have a really dumb question. Why don't you > > > limit the number of assertable identities by > > > cryptographic means? That is, if I can't prove > > > that I own an identity binding, it gets dumped > > > on the floor? > > > > Sure; I think the issue (Miguel can correct me if I'm wrong), > > is that the UA needs to be configured with the set of > > identities it can claim in the first place. The same > > credentials would allow the user to assert any one of those, > > but the phone needs to know which it should present to the > > user to use. > > It goes a little further than this. We're also informing the UA of a > number of extisting "aliases". The UA can expect to see calls "To:" any > of these aliases, and needs to delivery them appropriately to the user > as direct calls rather than as calls targeted originally to some other > user that have just been forwarded here. This might interact with > distinctive-ringing features, for example. This isn't documented in the draft either, and needs to be. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 16:06:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29517 for ; Tue, 28 May 2002 16:06:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12676 for sip-archive@odin.ietf.org; Tue, 28 May 2002 16:07:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10720; Tue, 28 May 2002 15:42:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10693 for ; Tue, 28 May 2002 15:42:21 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28913 for ; Tue, 28 May 2002 15:41:57 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJhLYH025321; Tue, 28 May 2002 15:43:23 -0400 (EDT) Message-ID: <3CF3DD7A.F6FFD98D@dynamicsoft.com> Date: Tue, 28 May 2002 15:41:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: "'adam@dynamicsoft.com'" , "'sip@ietf.org'" Subject: Re: [SIP] NOTIFY request MUST contain an Expires header? References: <5B4D0C5BA65ECA46969C1419122317E6E74DC8@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Thanks for the answer. > > In that case, shouldn't the "expires" parameter in the > Subscription-State > header in NOTIFY carry the same MUST strength as for Expires header in > 200 > OK response to SUBSCRIBE, instead of just a SHOULD (second last > paragraph of > 4.2.2 of draft-sip-events)? Section 4.2.4 'Subscriber NOTIFY Behavior' > also > talks about the "expires" parameter with "If the Subscription-State > header > also contains an "expires" parameter...", but what if it does not ? Can > a > NOTIFY request which matches (according to 4.3.4) the SUBSCRIBE request > create a subscription and a new dialog if its Subscription-State does > not > contain an "expires" parameter ? Yes, this is a good point. I believe this is probably an error in sip-events, and that the expires parameter needs to be present with MUST strength. Adam? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 16:17:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29724 for ; Tue, 28 May 2002 16:17:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13028 for sip-archive@odin.ietf.org; Tue, 28 May 2002 16:17:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11555; Tue, 28 May 2002 15:55:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11523 for ; Tue, 28 May 2002 15:55:34 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29247 for ; Tue, 28 May 2002 15:55:10 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA29165; Tue, 28 May 2002 15:55:08 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SJt72i022456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 May 2002 15:55:08 -0400 (EDT) Message-ID: <3CF3E07E.3090403@cs.columbia.edu> Date: Tue, 28 May 2002 15:54:38 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6 References: <3CF3BA6A.7090700@cs.columbia.edu> <3CF3D9D4.BFE306AC@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm happy to add this as another option, but I'm more than a bit afraid of further delaying progress on something which already has seen more than its share of delays. If we get stuck in general debates as to whether DHCP should be allowed at all, we'll get another decade or so, so there'll be plenty of time :-) Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > >>I agree that this would be useful, albeit a bit unusual compared to >>other DHCP options. There are a few issues that would need to be >>resolved: >> >>- Would this apply to v6 only? I don't know that the state of the v4 >>draft is in the IESG pipeline and what other "customers" there are. This >> >>would be the first DHCP option containing a URI, so this may cause some >>broader issues. > > > Understood. Its definitely not v6 specific. Maybe we need to define it > separately because its too late or controversial. My main point is that > technically, I think it is far superior to using IP addresses or domain > names. > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue May 28 17:08:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01171 for ; Tue, 28 May 2002 17:08:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17454 for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:08:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15179; Tue, 28 May 2002 16:41:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15102 for ; Tue, 28 May 2002 16:41:52 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00588; Tue, 28 May 2002 16:41:26 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 13:41:19 -0700 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 13:41:19 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 13:41:18 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 13:41:18 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 28 May 2002 13:41:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 13:41:18 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIGfTd3vsQjOe91RASdqO6Xm4cI4QACjkEQ From: "Christian Huitema" To: "Dean Willis" , Cc: X-OriginalArrivalTime: 28 May 2002 20:41:17.0765 (UTC) FILETIME=[0452CF50:01C20688] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA15113 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Christian wrote: > > I have a major issue with this spec, namely that the security > > problems are not addressed. The security section correctly > > lists one of the main security threats, the spoofing of a DHCP server: > > Yes, this is a real issue. > > But isn't this sort of a general DHCP problem rather than one specific > to the usage of SIP? > > Do we need to bascially stop using DHCP while working on it, and if so > is this (SIP working group) the right forum to try and tackle that? Well, there is a middle ground, which is to only use DHCP when the risk/benefit ratio is right. My contention is that, in the case of SIP, the risk/benefit ratio is weighted a lot towards risk, and that in general there are other solutions. For example, we know that the UA must have some explicit configuration -- reference URL, security credentials, etc. In these cases, using DHCP for SIP is not needed. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 17:34:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01756 for ; Tue, 28 May 2002 17:34:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19336 for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:34:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17842; Tue, 28 May 2002 17:18:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17768 for ; Tue, 28 May 2002 17:18:18 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01384; Tue, 28 May 2002 17:17:52 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA15553; Tue, 28 May 2002 17:18:15 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SLIE2i026056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 May 2002 17:18:14 -0400 (EDT) Message-ID: <3CF3F3F8.6050502@cs.columbia.edu> Date: Tue, 28 May 2002 17:17:44 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Dean Willis , iesg@ietf.org, sip@ietf.org Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > have some explicit configuration -- reference URL, security credentials, > etc. In these cases, using DHCP for SIP is not needed. I don't think that is true. In a visited network, the outbound proxy may be needed to communicate, as I mentioned in my previous email. Plus, I don't see that the SIP case is so special. If I spoof a DHCP server (absent of a shared secret), I can hand out bogus IP addresses that conveniently end up sending all packets to the default router for that address (another compromised server). Why bother with just received S/MIME encrypted SIP requests if I can get the whole hog? I don't know which of the DHCP IPv4 options will find its way into v6, but the POP server option, the NNTP server option and NIS+ options seem to be at least as juicy a target. I'm all for a stronger applicability statement, but this would seem to apply to DHCPv6 in general. Basically, it would have to say "DHCPv6 is not currently suited for roaming users that don't have a pre-established secret with the visited domain". Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 17:39:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01888 for ; Tue, 28 May 2002 17:39:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19639 for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:39:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17682; Tue, 28 May 2002 17:16:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17650 for ; Tue, 28 May 2002 17:16:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01339 for ; Tue, 28 May 2002 17:16:03 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SLFlHs010648; Tue, 28 May 2002 14:15:47 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AAE98372 (AUTH rmahy); Tue, 28 May 2002 14:15:46 -0700 (PDT) Message-Id: <200205282115.AAE98372@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with HTTP/1.0; Tue, 28 May 2002 14:21:06 -0700 Date: Tue, 28 May 2002 14:21:06 -0700 From: Rohan Mahy Subject: Re: [Sip] new I-D for registration event package To: Jonathan Rosenberg Cc: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, As a point of process, if this work is adopted as a WG effort, it probably belongs in SIPPING or in SIMPLE. thanks, -rohan ---- Original message ---- >Date: Tue, 28 May 2002 02:14:41 -0400 >From: Jonathan Rosenberg >Subject: [Sip] new I-D for registration event package >To: sip@ietf.org > >Folks, > >I've just submitted draft-rosenberg-sip-reg-event to the archives. Until >it appears you can pick up a copy at: > >http://www.jdrosen.net/papers/draft-rosenberg-sip-reg-event-00.txt > >This draft is an attempt to generalize the registration event package >defined in: > >http://www.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-01.txt > >I believe there are a lot of valuable applications for a registration >event package, and therefore, having a generalized version seems like a >good thing. There is nothing radically different between the two drafts. >The main difference is that mine defines a specific state machine for >registration events, and defines an XML document format to specifically >convey information about changes to that machine. It doesn't reuse the >presence document format, as the beckmann draft does. My draft does >appear to meet the 3gpp requirements. > >The key decision point for the group is whether to move forward with >draft-rosenberg-sip-reg-event (as a sipwg draft) or >draft-beckmann-sip-reg-event. Unfortunately, the timeline doesn't change >in either case, since something is needed for 3gpp in quite short order. >In some private email conversations, Mark and Georg indicated support >for going with a generalized version, but I will let them speak for >themselves. > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 17:50:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02187 for ; Tue, 28 May 2002 17:50:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20725 for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:51:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19010; Tue, 28 May 2002 17:31:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18935 for ; Tue, 28 May 2002 17:31:23 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01675; Tue, 28 May 2002 17:30:56 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 14:30:41 -0700 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 14:30:41 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 14:30:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 14:30:41 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 28 May 2002 14:30:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 14:30:40 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIGjS+2GDNY1FuZQKi3FxZUgcKaogAAP++g From: "Christian Huitema" To: "Henning Schulzrinne" Cc: "Dean Willis" , , X-OriginalArrivalTime: 28 May 2002 21:30:40.0007 (UTC) FILETIME=[E9F51170:01C2068E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA18938 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > I don't know which of the DHCP IPv4 options will find its way into v6, > but the POP server option, the NNTP server option and NIS+ options seem > to be at least as juicy a target. It is unclear whether we need DHCPv6 at all. We definitely don't need it for address allocation, or to find the local gateway, but a "DHCP INFORM" procedure may be a useful way to convey some network parameters, such as the address of the local DNS server. OTOH, I don't believe that existing mail clients use DHCP to find out the address of their mail server; just because a DHCP option is defined does not means that it gets used... > I'm all for a stronger applicability statement, but this would seem to > apply to DHCPv6 in general. Basically, it would have to say "DHCPv6 is > not currently suited for roaming users that don't have a pre-established > secret with the visited domain". Yes, that would certainly be a reasonable first step. But I still believe that we have to give up the whole idea of discovering SIP proxies on the fly. To me, this looks like a ludicrous attempt to recreate the phone architecture on top of IP. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 17:50:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02204 for ; Tue, 28 May 2002 17:50:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20739 for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:51:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19279; Tue, 28 May 2002 17:34:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19173 for ; Tue, 28 May 2002 17:34:10 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01749 for ; Tue, 28 May 2002 17:33:44 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLWl412739; Tue, 28 May 2002 16:32:47 -0500 From: "Dean Willis" To: "'sip'" Cc: , , , "Jon Peterson \(jon.peterson@NeuStar.com\)" Date: Tue, 28 May 2002 16:32:06 -0500 Message-ID: <00d901c2068f$1e0b4420$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for draft-ietf-sip-privacy-general Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We need to do a quick review of the general privacy draft developed out of our discussion in Las Vegas. Please send any issues to the list and the editor IMMEDIATELY. The draft is available from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00. html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00. txt And soon to be available from internet-drafts if not already . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 17:53:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02285 for ; Tue, 28 May 2002 17:53:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21073 for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19163; Tue, 28 May 2002 17:34:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19126 for ; Tue, 28 May 2002 17:34:06 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01747 for ; Tue, 28 May 2002 17:33:40 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLWl412740; Tue, 28 May 2002 16:32:47 -0500 From: "Dean Willis" To: "'sip'" Cc: , , , "'Cullen Jennings'" Date: Tue, 28 May 2002 16:32:06 -0500 Message-ID: <00da01c2068f$1e0e5160$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We need to do a quick working group last call on the "Asserted Identity" draft. Please submit comments to the list and draft editor IMMEDIATELY. Draft available from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0 0.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0 0.txt And soon to be in the internet-drafts archive. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:07:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02560 for ; Tue, 28 May 2002 18:07:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22657 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20294; Tue, 28 May 2002 17:47:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20260 for ; Tue, 28 May 2002 17:47:28 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02082 for ; Tue, 28 May 2002 17:47:01 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLk7412846; Tue, 28 May 2002 16:46:07 -0500 From: "Dean Willis" To: "'Jonathan Rosenberg'" Cc: "'Miguel A. Garcia'" , , , , Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Date: Tue, 28 May 2002 16:45:24 -0500 Message-ID: <00dd01c20690$fac7a380$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CF3DB0E.215085E3@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Actually, this policy enforcement is being made by the > > > 3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like- > > a- > > proxy called the P-CSCF. Documenting the behavior of this rather > > specalized node is probably far outside the scope of an IETF effort. > > Proxies, in general, are not expected to restrict the range > of identity > > expression allowed to a user based on some sort of > P-header. In fact, > > one might argue that proxies in general are PROHIBITED from > doing this > > sort of thing . . . > > Well, that enforcement IS being done, and I thought was core > to the entire concept here. Indeed, this is the essence of > what I suggested for the new applicability statement. My > point is, if you are doing such restrictions, you need to > have a response code appropriate for this error case. > > I will also note that of all things proxies are doing these > days, rejecting a call because the From is not authorized is > the least evil. Indeed, one might argue that this is > equivalent to sip level ingress address filtering (RFC 2827), > and is possibly a very good thing to do. I'm not saying that proxies can't do ingress filtering, just that standardizing this behavior based on a P-header seems a bit iffy from a "SIP Change Process" perspective. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:09:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02619 for ; Tue, 28 May 2002 18:09:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22875 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:09:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20543; Tue, 28 May 2002 17:49:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20467 for ; Tue, 28 May 2002 17:49:30 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02136; Tue, 28 May 2002 17:49:03 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 14:48:56 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 14:48:56 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 14:48:56 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 14:48:55 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 28 May 2002 14:48:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 14:48:55 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIGkScDYvSrcbgxQMWy40LRJj85owAAB7Hw From: "Christian Huitema" To: "Dean Willis" , "Henning Schulzrinne" Cc: , X-OriginalArrivalTime: 28 May 2002 21:48:55.0533 (UTC) FILETIME=[76F111D0:01C20691] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA20470 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > If you have a better approach for discovering the SIP proxy controlling > the firewall that you didn't know that you were behind (and I'd argue > that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot said, > "all ears" . . . Could it be that this "sip proxy controlling the firewall" is part of the problem rather than part of the solution? It is certainly not part of the IP architecture... -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:20:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02915 for ; Tue, 28 May 2002 18:20:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23586 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:20:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22240; Tue, 28 May 2002 18:02:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22209 for ; Tue, 28 May 2002 18:02:54 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02480 for ; Tue, 28 May 2002 18:02:28 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SM0SYH025772; Tue, 28 May 2002 18:00:29 -0400 (EDT) Message-ID: <3CF3FD9D.1D5C6489@dynamicsoft.com> Date: Tue, 28 May 2002 17:58:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Dean Willis , Henning Schulzrinne , sip@ietf.org Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > If you have a better approach for discovering the SIP proxy > controlling > > the firewall that you didn't know that you were behind (and I'd argue > > that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot > said, > > "all ears" . . . > > Could it be that this "sip proxy controlling the firewall" is part of > the problem rather than part of the solution? It is certainly not part > of the IP architecture... In theory, I agree with you Christian, in that the whole notion of a visited proxy is silly; after all, when I'm in a hotel, I still connect to the same mail server back in my "home", and not a local hotel mail server which I discovered through DHCP. However, for communications services, local outbound proxies native to a visited domain do and will exist for many reasons (for example, local dialing plans, 911, local services, etc.), only one of which is firewall traversal. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:21:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02953 for ; Tue, 28 May 2002 18:21:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23665 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:21:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22090; Tue, 28 May 2002 18:01:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22055 for ; Tue, 28 May 2002 18:01:32 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02468 for ; Tue, 28 May 2002 18:01:06 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SM1nYH025781; Tue, 28 May 2002 18:01:49 -0400 (EDT) Message-ID: <3CF3FDEE.FEB7A29C@dynamicsoft.com> Date: Tue, 28 May 2002 18:00:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6 References: <3CF3E07E.3090403@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am fine to pursue this separately, and let the existing work continue. -Jonathan R. Henning Schulzrinne wrote: > > I'm happy to add this as another option, but I'm more than a bit afraid > of further delaying progress on something which already has seen more > than its share of delays. If we get stuck in general debates as to > whether DHCP should be allowed at all, we'll get another decade or so, > so there'll be plenty of time :-) > > Jonathan Rosenberg wrote: > > > > Henning Schulzrinne wrote: > > > >>I agree that this would be useful, albeit a bit unusual compared to > >>other DHCP options. There are a few issues that would need to be > >>resolved: > >> > >>- Would this apply to v6 only? I don't know that the state of the v4 > >>draft is in the IESG pipeline and what other "customers" there are. > This > >> > >>would be the first DHCP option containing a URI, so this may cause > some > >>broader issues. > > > > > > Understood. Its definitely not v6 specific. Maybe we need to define it > > separately because its too late or controversial. My main point is > that > > technically, I think it is far superior to using IP addresses or > domain > > names. > > > > -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:27:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03064 for ; Tue, 28 May 2002 18:27:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23957 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:28:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22417; Tue, 28 May 2002 18:04:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22345 for ; Tue, 28 May 2002 18:04:38 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02490; Tue, 28 May 2002 18:04:12 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4SM3XIZ006540; Tue, 28 May 2002 15:03:33 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABT15067; Tue, 28 May 2002 15:00:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA06061; Tue, 28 May 2002 15:03:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15603.65204.125284.667726@thomasm-u1.cisco.com> Date: Tue, 28 May 2002 15:03:32 -0700 (PDT) To: "Christian Huitema" Cc: "Dean Willis" , "Henning Schulzrinne" , , Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema writes: > > If you have a better approach for discovering the SIP proxy > controlling > > the firewall that you didn't know that you were behind (and I'd argue > > that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot > said, > > "all ears" . . . > > Could it be that this "sip proxy controlling the firewall" is part of > the problem rather than part of the solution? It is certainly not part > of the IP architecture... Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:35:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03223 for ; Tue, 28 May 2002 18:35:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24634 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:35:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23330; Tue, 28 May 2002 18:15:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23299 for ; Tue, 28 May 2002 18:15:21 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02749 for ; Tue, 28 May 2002 18:14:55 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 15:14:48 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 15:14:48 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 15:14:47 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 15:14:47 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 28 May 2002 15:14:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 15:14:45 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIGkvTnn9uu/+9PTqWseqwkJO/JAAAAIcqg From: "Christian Huitema" To: "Jonathan Rosenberg" Cc: "Dean Willis" , "Henning Schulzrinne" , X-OriginalArrivalTime: 28 May 2002 22:14:47.0429 (UTC) FILETIME=[13F19B50:01C20695] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA23300 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > In theory, I agree with you Christian, in that the whole notion of a > visited proxy is silly; after all, when I'm in a hotel, I still connect > to the same mail server back in my "home", and not a local hotel mail > server which I discovered through DHCP. > > However, for communications services, local outbound proxies native to a > visited domain do and will exist for many reasons (for example, local > dialing plans, 911, local services, etc.), only one of which is firewall > traversal. I don't think that the "firewall traversal" requirement actually applies to hotel connections. The hotel connection supposedly gives you a high speed Internet access, and they often charge you good money for the service. The hotel has no good reason to check whether you use TCP or UDP, or for that matter IPSEC -- and since we are speaking of a DHCPv6 option, we have to assume that we are using IPv6, and that there is no NAT to go through. In these conditions, the only real reason for the local proxy is a desire to control some specific applications -- very possibly, make you pay phone calls by the minute. As you say, this is silly, and I don't see why we should tweak our standards encourage such silliness. Now, if what you want is to discover the local 911 service, you probably don't want to use an insecure channel. Which would prevent using DHCPv6, since it is not secure in a roaming scenario... -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 18:57:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02558 for ; Tue, 28 May 2002 18:07:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22661 for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20246; Tue, 28 May 2002 17:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20164 for ; Tue, 28 May 2002 17:47:13 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02073; Tue, 28 May 2002 17:46:45 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLk5412840; Tue, 28 May 2002 16:46:05 -0500 From: "Dean Willis" To: "'Christian Huitema'" , "'Henning Schulzrinne'" Cc: , Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 16:45:24 -0500 Message-ID: <00db01c20690$f99c1bd0$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Yes, that would certainly be a reasonable first step. But I > still believe that we have to give up the whole idea of > discovering SIP proxies on the fly. To me, this looks like a > ludicrous attempt to recreate the phone architecture on top of IP. I suppose we could use multicast or v6-anycast with a standardized service address, but that would seem to have the same security issues as DHCP. . . If you have a better approach for discovering the SIP proxy controlling the firewall that you didn't know that you were behind (and I'd argue that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot said, "all ears" . . . In the meantime, I have to manually reconfigure MS-Messenger every time I go from my house to my office or back. It gets tedious. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 19:03:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03728 for ; Tue, 28 May 2002 19:03:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25919 for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:03:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24825; Tue, 28 May 2002 18:40:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24792 for ; Tue, 28 May 2002 18:40:05 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03323 for ; Tue, 28 May 2002 18:39:39 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SMdOHs003900; Tue, 28 May 2002 15:39:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABT16067; Tue, 28 May 2002 15:36:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA06068; Tue, 28 May 2002 15:39:22 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15604.1818.608100.513991@thomasm-u1.cisco.com> Date: Tue, 28 May 2002 15:39:22 -0700 (PDT) To: "Dean Willis" Cc: "'Jonathan Rosenberg'" , "'Michael Thomas'" , , , , , "'Miguel Garcia'" Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri In-Reply-To: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2> References: <3CF3AEF9.EF57314C@dynamicsoft.com> <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > > Michael Thomas wrote: > > > > > > So, I have a really dumb question. Why don't you > > > limit the number of assertable identities by > > > cryptographic means? That is, if I can't prove > > > that I own an identity binding, it gets dumped > > > on the floor? > > > > Sure; I think the issue (Miguel can correct me if I'm wrong), > > is that the UA needs to be configured with the set of > > identities it can claim in the first place. The same > > credentials would allow the user to assert any one of those, > > but the phone needs to know which it should present to the > > user to use. > > It goes a little further than this. We're also informing the UA of a > number of extisting "aliases". The UA can expect to see calls "To:" any > of these aliases, and needs to delivery them appropriately to the user > as direct calls rather than as calls targeted originally to some other > user that have just been forwarded here. This might interact with > distinctive-ringing features, for example. > > So there is applicability in both "UA-originated" and UA-terminated" > scenarios, and there is no requirement that the client be able to > cryptographically assert the identity associated with an inbound alias. Ok, I guess my next dumb question is whether we really want to go down the slippery slope of turning SIP into a provisioning protocol. As in, why stop here and what delimits this case with, oh say, sending down which distinctive ringing tone to associate with which identity? In your example, the UA wouldn't have any clue how to do what you said unless it had that binding... Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 19:32:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04079 for ; Tue, 28 May 2002 19:32:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27590 for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:33:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26502; Tue, 28 May 2002 19:12:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26413 for ; Tue, 28 May 2002 19:12:33 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03854; Tue, 28 May 2002 19:11:53 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SNBG413414; Tue, 28 May 2002 18:11:16 -0500 From: "Dean Willis" To: "'Christian Huitema'" , "'Henning Schulzrinne'" Cc: , Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 18:10:34 -0500 Message-ID: <011301c2069c$df838b00$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Could it be that this "sip proxy controlling the firewall" is > part of the problem rather than part of the solution? It is > certainly not part of the IP architecture... > > -- Christian Huitema Yes, I'm sure that dealing with reality is out-of-scope for our architecture. That's why we've been so successful at curtailing the spread of NAT and firewall boxes and assuring interoperability when they do spontaneously appear. Your argument, while principaled, is consistent with the declaration that since cars are approximately two horses wide (see "The Standard that Wouldn't Die") we should be able to feed them grain, steer them with reins and control their velocity with a buggy whip. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 19:34:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04096 for ; Tue, 28 May 2002 19:34:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27676 for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:34:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26380; Tue, 28 May 2002 19:12:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26343 for ; Tue, 28 May 2002 19:12:24 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03857 for ; Tue, 28 May 2002 19:11:59 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SNBF413411; Tue, 28 May 2002 18:11:15 -0500 From: "Dean Willis" To: "'Christian Huitema'" , "'Jonathan Rosenberg'" Cc: "'Henning Schulzrinne'" , Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 18:10:34 -0500 Message-ID: <011201c2069c$df496830$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian said: > I don't think that the "firewall traversal" requirement > actually applies to hotel connections. The hotel connection > supposedly gives you a high speed Internet access, and they > often charge you good money for the service. The hotel has no > good reason to check whether you use TCP or UDP, or for that > matter IPSEC -- and since we are speaking of a DHCPv6 option, > we have to assume that we are using IPv6, and that there is > no NAT to go through. In these conditions, the only real > reason for the local proxy is a desire to control some > specific applications -- very possibly, make you pay phone > calls by the minute. As you say, this is silly, and I don't > see why we should tweak our standards encourage such silliness. Where are you finding hotels with broadband that don't require use of their NAT box and HTTP proxy? I've never seen a hotel with a truly open internet connection. - Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 19:36:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04130 for ; Tue, 28 May 2002 19:36:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27723 for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:36:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26405; Tue, 28 May 2002 19:12:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26341 for ; Tue, 28 May 2002 19:12:23 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03856 for ; Tue, 28 May 2002 19:11:58 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SNBF413408; Tue, 28 May 2002 18:11:15 -0500 From: "Dean Willis" To: "'Michael Thomas'" Cc: "'Jonathan Rosenberg'" , , , , , "'Miguel Garcia'" Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Date: Tue, 28 May 2002 18:10:34 -0500 Message-ID: <011101c2069c$df0ab180$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <15604.1818.608100.513991@thomasm-u1.cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit MAT asked: > Ok, I guess my next dumb question is whether we > really want to go down the slippery slope of > turning SIP into a provisioning protocol. As in, > why stop here and what delimits this case with, oh > say, sending down which distinctive ringing tone > to associate with which identity? In your example, > the UA wouldn't have any clue how to do what you > said unless it had that binding... That, my friend, is why it's a P-header and not a standard extension. The assosiated-URI's-associated-ringing-tone-selector idea is pretty clever. Why don't you write up a P-header draft and submit it? Odds are it makes it into Release-6 :-) (I smile, but do not jest). -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 20:21:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04826 for ; Tue, 28 May 2002 20:21:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29804 for sip-archive@odin.ietf.org; Tue, 28 May 2002 20:22:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28574; Tue, 28 May 2002 19:53:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28000 for ; Tue, 28 May 2002 19:42:42 -0400 (EDT) Received: from dsl-64-192-31-101.telocity.com (dsl-64-192-31-101.telocity.com [64.192.31.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04273 for ; Tue, 28 May 2002 19:42:17 -0400 (EDT) Received: from keyser1.dsl-64-192-31-101.telocity.com ([192.168.0.1]) by dsl-64-192-31-101.telocity.com (JAMES SMTP Server 2.0a2) with SMTP ID 102 for ; Tue, 28 May 2002 19:42:06 -0400 Received: from jeff (unverified [192.168.0.18]) by KEYSER1.dsl-64-192-31-101.telocity.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 28 May 2002 19:41:30 -0400 From: "Jeff Keyser" To: "'Jonathan Rosenberg'" Cc: "'SIP Mailing List \(E-mail\)'" Subject: RE: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 Date: Tue, 28 May 2002 19:41:28 -0400 Message-ID: <000001c206a1$30ca97c0$1200a8c0@dsl6419231101.telocity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CF3192F.CCB8076F@dynamicsoft.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the clarification. Perhaps this reasoning should be explicitly stated in the document, since I apparently wasn't the only person who was confused by this. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, May 28, 2002 1:44 AM > To: Jeff Keyser > Cc: SIP Mailing List (E-mail) > Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09 > > > inline. > > Jeff Keyser wrote: > > > > I apologize if this is not the correct place for this > comment. If this > > is > > not, please let me know where I should direct this. > > > > I am working with draft-ietf-sip-rfc2543bis-09 to write a > SIP client, > > and > > the INVITE transactions of section 17 don't make sense to > me as written. > > For both client and server INVITE transactions in the > "Proceeding" state > > (and "Calling" state for client transactions), if a new > response status > > code > > is 300-699, the transaction changes to the "Completed" > state; and, if a > > new > > response status code is 2xx, the transaction changes to the > "Terminated" > > state. The state diagrams show this same logic. > > > > I assume that this is supposed to be the other way around, since the > > "Completed" state is used the handle the ACK request of a connected > > call. > > No, it is correct as written. > > The reason is that this state machine represents the *transaction* > state. The transaction state machine is responsible for > request/response > correlation, retransmissions, and so on. It is NOT responsible for the > management of the call state. When a 2xx is received, the > transaction is > complete. There is an ACK, but this ACK constitutes a separate > transaction. Correlation of the ACK with the 2xx is done by > the UAS at a > higher layer, not by the transaction machines. In contrast, > for non-2xx > final responses, the ACK is part of the same transaction, and so the > state machine must stick around to handle that. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 22:50:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07737 for ; Tue, 28 May 2002 22:50:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08878 for sip-archive@odin.ietf.org; Tue, 28 May 2002 22:50:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04943; Tue, 28 May 2002 21:57:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04886 for ; Tue, 28 May 2002 21:57:51 -0400 (EDT) Received: from sict.ac.cn ([210.72.128.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06601 for ; Tue, 28 May 2002 21:57:26 -0400 (EDT) Received: from guy ([210.72.128.47]) by sict.ac.cn (Merak 4.10.020) with SMTP id 5105A6C8 for ; Wed, 29 May 2002 09:56:16 +0800 MIME-Version: 1.0 Message-Id: <3CF436D8.00000A.00748@guy> Date: Wed, 29 May 2002 10:03:04 +0800 Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_4DOUH890000000000000" X-Mailer: IncrediMail 2001 (1750690) From: "Guy" X-FID: BA285063-5BCE-11D4-AF8D-0050DAC67E11 X-FVER: 2.0 X-FIT: Letter X-FCOL: Elegant Paper X-FCAT: Stationery X-FDIS: Rice Fields X-Extensions: SU1CTDEsNDEsgUmBSTAkkcGNgZmVTY0wNCxNhYUoiU0kOMEoTYGBjYEoJDSZnSyFhUksSU1CTDIsMCwsSU1CTDMsMCws X-BG: X-BGT: repeat X-BGC: #dce0e3 X-BGPX: 0px X-BGPY: 0px X-ASN: ANIM3D00-NONE-0000-0000-000000000000 X-ASNF: 0 X-ASH: ANIM3D00-NONE-0000-0000-000000000000 X-ASHF: 1 X-AN: 6486DDE0-3EFD-11D4-BA3D-0050DAC68030 X-ANF: 0 X-AP: 6486DDE0-3EFD-11D4-BA3D-0050DAC68030 X-APF: 1 X-AD: C3C52140-4147-11D4-BA3D-0050DAC68030 X-ADF: 0 X-AUTO: X-ASN,X-ASH,X-AN,X-AP,X-AD X-CNT: ; X-Priority: 3 To: Subject: [Sip] About BYE and CANCEL Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------Boundary-00=_4DOUH890000000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_4DOUCJD0000000000000" --------------Boundary-00=_4DOUCJD0000000000000 Content-Type: Text/Plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I want to know the scenario when the UA should send BYE or CANCEL.=0D =46rom RFC2543,CANCEL is only used to terminate the pending request.=0D My question is : whether BYE request also can terminate the pending reque= st or not?=0D Best regards!!=0D =0D =0D Guy=0D Email: ligang@sict.ac.cn --------------Boundary-00=_4DOUCJD0000000000000 Content-Type: Text/HTML; charset="gb2312" Content-Transfer-Encoding: quoted-printable =0D =0A
I want to know the scenario when the UA should send BYE or=20 CANCEL.
From RFC2543,CANCEL is only used to terminate the pending=20 request.
My question is : whether BYE request also can terminate t= he=20 pending request or not?
Best regards!!
 
 
Guy
Email:  ligang@sict.ac.cn
 
____________________________________________________
  IncrediMai= l -=20 Email has finally evolved - Click=20 Here --------------Boundary-00=_4DOUCJD0000000000000-- --------------Boundary-00=_4DOUH890000000000000 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <9C396D79-4828-4D43-B88D-024A313BF700> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --------------Boundary-00=_4DOUH890000000000000 Content-Type: Image/jpeg Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAHbAAAC1gAABZX/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAGUAcwMBIgACEQEDEQH/ xACAAAEBAQEAAAAAAAAAAAAAAAAAAQIGAQEBAAAAAAAAAAAAAAAAAAAAARABAAICAwEAAgMAAAAA AAAAAQARIQIxQRIiQDIQMFARAAICAgIBBAIDAQEAAAAAAAERACExQVFhcYGRobECEsHhMtHxEgEA AAAAAAAAAAAAAAAAAABQ/9oADAMBAAIRAxEAAADtRZYE1ASghQFgUZoCkKSwLmhcllAEqkSkqFAl hUomoAS3IoJqFlDNpFEAQFE1AIVYAWIVKAJRNZpYCwVmmshKACA0CBAUCBYGwf/aAAgBAgABBQD8 B/yP/9oACAEDAAEFAPz6/or8H//aAAgBAQABBQC2+ZeHjbD+saX6hwXeDW1Rg4xLLTa+m7ZiIEsI 1MTiHP1dYpvFADiFM1/X6nq9byuwdPPz5oFofWlEMQ9ULKrWq2ppG9Y2J6INQma9lVTRdlUKgHzX XSEECw1SYu5WsGoJPkisZYpx31GvXZQ/JM3VwShzVTsp1EZbBI8LcaUSih86+s2Zl4Wp6+lAZnVs Dkjdku5m+lJTdXDG2SHM9M2wKX1YxsaZTTwmoVrYnqsMrM652yjs01K0mtbGAz6Y5dpfqNz06qpq 5QNjiIjiZtbhtceNuf0jyeqGgu6rXMvI4omPWbPMYzEfMI+axHnFvOP4/9oACAECAgY/AGP/2gAI AQMCBj8AY//aAAgBAQEGPwB72Yucb1BfIhFEaeZ+xRXFQELN+HEUQdjU0Xn4g9gRCQcpw1yajGYs P/kFvUzvjUBWrIMFHI2OJQNEAjiEEFdTmfG/MTHq5RFOnpTV3kzCBx7x4YOD1AV5uYJvnqMA0hep jfwpYCwC4Bx3q55zeZRBCw9TkoIuHw78RdczSNH2mgqcLpRC+RASAkA3B13mcYd5mR84c/yOx4lW tRAZ6mGDhiP9WgXVyhWA+xDgMOWGMsTg/wBTz8SjjXrP8hHIlX1MZ6mDzgc/cIV/iyN1GBR0MQMK jnEzvvMz8mUkErKlfqU63iV+IKNH7mNZBLFQEpEDeDOV32IVn8WR4caoywqI2p695mbZzNUQIcKf k0bo+0NpCqn7CiQiNGXkdQen1DpjGeZ7WNw3pK+I93maCPc16+Zkf6XxMCsFwAkaiIB57vc/IAhZ /HqZBBbB0ZokAEOGxsYqBgPp8agQBu4VSMJdqx6SwDsGBrTmAR93uZGX6KePowEADAIjoX8gw459 CICaW/MLGvodQfkDW71zBxRHtB3j3jC4PMIYoAgKNfPMCQNN7jCzvlzXPopzhQvNZY3CRya9ZrEF fRE0iCB5mscZuVYfKmAi94uE3Q8qfytQ7xD0svmFcmaxNPI8iMjh3pmF2HbzqeUi+YkiD/MrOl5L mbwPuWVfmXpv3hDH8qAjPpiZHXkRnSd6ZhB53mejzKV6US0K9TCCLyCeIhtETX5MsHBGJkD/ANiF kMCE2qGoCdZ8Q8AMGpYFqEhdhRIYH3CF3d1M/Mexma+4CwdQ2Ddcx0exAlmj04QUQd8QWLB/iB5G xmEg5TENVZqPYzFV8eHAy9T/AEc8a4n3Ov6g/VwvE6lpQ4VNysXzhS8esOO8w/rlF/rypjV3B5H1 Knr8T//Z --------------Boundary-00=_4DOUH890000000000000-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 23:05:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08089 for ; Tue, 28 May 2002 23:05:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA10257 for sip-archive@odin.ietf.org; Tue, 28 May 2002 23:05:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06539; Tue, 28 May 2002 22:20:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06511 for ; Tue, 28 May 2002 22:20:31 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06874 for ; Tue, 28 May 2002 22:20:07 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4T2JpIZ011645 for ; Tue, 28 May 2002 19:19:51 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAF01003; Tue, 28 May 2002 19:19:50 -0700 (PDT) Date: Tue, 28 May 2002 19:16:11 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] P- headers vs. requirements in sip change process Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, >From tsvarea-sipchange the requirements for P- headers are: 1. Expert Review 2. No option tags, response codes, or methods 3. No overlap with planned/chartered extensions 4. Purely informational in nature 5. Does not undermine security 6. Clearly documented in RFC 7. Appropriate applicability statement I've taken a stab at documenting compliance with these requirements. I've also included an evaluation of call-auth as a comparison. Please note that in future proposed P- headers should go through SIPPING. draft-ietf-sip-call-auth 1. Expert Review Via the SIP working group as WG document 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions No overlap 4. Purely informational in nature OK 5. Does not undermine security Minor caveats, well documented 6. Clearly documented in RFC OK 7. Appropriate applicability statement Yes, very narrow in scope draft-ietf-sip-asserted-identity 1. Expert Review Via WG as WG document 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions Some overlap with future crytographic identity work, scope of overlap intentionally narrow 4. Purely informational in nature OK 5. Does not undermine security Minor caveats, usage well documented 6. Clearly documented in RFC OK 7. Appropriate applicability statement Yes, very narrow scope draft-garcia-sip-visited-network-id 1. Expert Review some review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions No overlap 4. Purely informational in nature OK 5. Does not undermine security Negligible impact, well documented 6. Clearly documented in RFC OK 7. Appropriate applicability statement Needs to provide more general usage guidance draft-garcia-sip-called-party-id 1. Expert Review some review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions some overlap with request-history work, very narrow in scope 4. Purely informational in nature OK 5. Does not undermine security Some privacy concerns 6. Clearly documented in RFC OK 7. Appropriate applicability statement Needs to provide more general usage guidance, Should mention the partial overlap with request history draft-garcia-sip-associated-uri 1. Expert Review some review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions No overlap 4. Purely informational in nature OK 5. Does not undermine security Some privacy concerns, can be addressed with standard mechanisms 6. Clearly documented in RFC OK 7. Appropriate applicability statement Needs to provide more general usage guidance draft-henrikson-sip-charging-information 1. Expert Review some review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions No overlap 4. Purely informational in nature OK 5. Does not undermine security ? 6. Clearly documented in RFC OK 7. Appropriate applicability statement Some good general guidance given, need to explain when NOT to use draft-henrikson-sip-orig-dialog-id 1. Expert Review some review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions significant overlap with SIP state, and cookies (chartered work) 4. Purely informational in nature Unclear. Appears to change algorithm used for SIP routing 5. Does not undermine security Unclear 6. Clearly documented in RFC Not yet 7. Appropriate applicability statement Needs to provide more general usage guidance draft-mills-sip-access-network-info 1. Expert Review some review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions No overlap 4. Purely informational in nature OK 5. Does not undermine security Some privacy concerns; generally well addressed in security section 6. Clearly documented in RFC OK 7. Appropriate applicability statement No applicability statement present draft-willis-sip-svcrtdisco 1. Expert Review good level of review from SIP WG 2. No option tags, response codes, or methods OK 3. No overlap with planned/chartered extensions No overlap 4. Purely informational in nature OK 5. Does not undermine security minor caveats addressed in security considerations 6. Clearly documented in RFC Yes 7. Appropriate applicability statement Some general guidance given, need to explain when NOT to use In addition there is an informational event package proposed... draft-beckmann-sip-reg-event 1. Expert Review some review in SIP, really needs review in SIMPLE 2. No template-packages OK 3. No overlap with planned/chartered extensions This appears to be a generically useful event package which should be addressed as a charter item in SIPPING Jonathan Rosenberg proposed such a document 4. Does not contradict normative behavior OK 5. Does not undermine security Mechanism introduces no new security concerns 6. Clearly documented in RFC Needs more detail - underspecified 7. Appropriate applicability statement No applicability statement present Probably not needed if this becomes a general purpose mechanism _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 23:14:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08186 for ; Tue, 28 May 2002 23:14:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA10645 for sip-archive@odin.ietf.org; Tue, 28 May 2002 23:15:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07975; Tue, 28 May 2002 22:34:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07905 for ; Tue, 28 May 2002 22:34:14 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07363; Tue, 28 May 2002 22:33:48 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 19:33:41 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 19:33:40 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 May 2002 19:33:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 May 2002 19:33:40 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 28 May 2002 19:33:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Date: Tue, 28 May 2002 19:33:40 -0700 Message-ID: Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard thread-index: AcIGnQfWL8cYWdzsTB+aVSsgguNWFwAGpZsQ From: "Christian Huitema" To: "Dean Willis" , "Henning Schulzrinne" Cc: , X-OriginalArrivalTime: 29 May 2002 02:33:40.0581 (UTC) FILETIME=[3E6C8150:01C206B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA07908 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > Could it be that this "sip proxy controlling the firewall" is > > part of the problem rather than part of the solution? It is > > certainly not part of the IP architecture... > > Yes, I'm sure that dealing with reality is out-of-scope for our > architecture. That's why we've been so successful at curtailing the > spread of NAT and firewall boxes and assuring interoperability when they > do spontaneously appear. OK, so here is a reality check: the specific proposal is for a DHCPv6 option -- that is, DHCP for IPv6. Either IPv6 is actually deployed, in which case we don't need the NAT, or IPv6 is not deployed, in which case we don't need the option. As for firewall traversal, I have a very hard time believing that an enterprise firewall that you randomly discovered through DHCP will let you send UDP packet through -- that will require at a minimum some solid exchange of credentials. > Your argument, while principaled, is consistent with the declaration > that since cars are approximately two horses wide (see "The Standard > that Wouldn't Die") we should be able to feed them grain, steer them > with reins and control their velocity with a buggy whip. Uh, is this useful? -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue May 28 23:37:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08780 for ; Tue, 28 May 2002 23:37:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA11845 for sip-archive@odin.ietf.org; Tue, 28 May 2002 23:38:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09314; Tue, 28 May 2002 22:59:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09283 for ; Tue, 28 May 2002 22:59:52 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07919 for ; Tue, 28 May 2002 22:59:27 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4T2xKHs003807 for ; Tue, 28 May 2002 19:59:20 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAF01278; Tue, 28 May 2002 19:59:19 -0700 (PDT) Date: Tue, 28 May 2002 19:55:40 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Generic Registration Package Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I posted a question asking if we want to adopt a generic event package for the status of registrations on the SIPPING list. Without requirements, that is where all new work should go. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 29 02:15:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20151 for ; Wed, 29 May 2002 02:15:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA02426 for sip-archive@odin.ietf.org; Wed, 29 May 2002 02:16:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26578; Wed, 29 May 2002 01:58:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26547 for ; Wed, 29 May 2002 01:57:57 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10852 for ; Wed, 29 May 2002 01:57:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4T5vgmG022263; Wed, 29 May 2002 07:57:42 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4T5vfgu007757; Wed, 29 May 2002 08:57:41 +0300 (EET DST) Message-ID: <3CF46DD5.66298EA1@lmf.ericsson.se> Date: Wed, 29 May 2002 08:57:41 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'sip'" , "'Jonathan Rosemberg'" , "'Henning Schulzrinne'" Subject: Re: [Sip] New version of the SIP over SCTP draft References: <00ad01c2067d$1ccb2830$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Dean, Yes, I already warned the editor about this. The new version should be 02. In fact, the only thing I forgot was to change the name of the file, since the draft itself says 02 above the title. Thanks, Gonzalo Dean Willis wrote: > > Warning! There appears to be a revision numbering issue. > > I have a file by the same name on the supplemental site which appears to > have been published last November. > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-sctp-01.txt > > Which replaced > > http://www.softarmor.com/sipwg/drafts/morgue/draft-ietf-sip-sctp-00.txt > published last August. > > Perhaps the latest rev should be -02? > > -- > Dean > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Gonzalo Camarillo > > Sent: Tuesday, May 28, 2002 5:18 AM > > To: sip > > Cc: Jonathan Rosemberg; Henning Schulzrinne > > Subject: [Sip] New version of the SIP over SCTP draft > > > > > > Hello, > > > > I have just submitted a new version of the SIP over SCTP draft. > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sctp-01.txt > > I have not changed anything. I have only updated the references (now > they are divided into normative and informative ones). > > I am re-submitting this draft because its LC is scheduled for July, and > version 00 expires in May 2002 (i.e., right now). > > Regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:08:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10282 for ; Wed, 29 May 2002 07:08:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01221 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:08:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00189; Wed, 29 May 2002 06:46:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00155 for ; Wed, 29 May 2002 06:46:00 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10075 for ; Wed, 29 May 2002 06:45:35 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4TAiec25873; Wed, 29 May 2002 06:44:41 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 05:44:35 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870375@va02.va.neustar.com> From: "Peterson, Jon" To: "'Juha Heinanen'" , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 Date: Wed, 29 May 2002 05:44:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I don't think anything that is expressed in this draft is incompatible with what you're attempting to accomplish with the normative statements below - except in so far as you levy restrictions that are not meaningful for all networks. "Hint", for whatever reason, is the term that has stuck throughout this discussion. There are meaningful cases in which a network would elect to use some identity other than that hinted by the user, so I don't feel this term is entirely inappropriate. There is a concept, though one that is not discussed extensively in the draft, that a user authenticates themselves in some fashion to the network. The Spec(T) example in the draft suggests SIP Digest authentication, if I recall. The P-Asserted-Identity could be populated based on an identity expressed in that authentication process, rather than a From header, in the absence of a hint (although admittedly in some networks the authentication will not supply a usable identity as such). This applies equally to cases in which the user has supplied an anonymous From header. This would seem to provide a credible alternative to the MUST that you suggest below, one that I see no reason to rule out. The short-term identity work puts the network, not the user, firmly in the driver's seat. There are other forms of identity (like the contents of the >From header field) that are more directly under the user's control. You are welcome to apply whatever policies you like for proxy servers in your own network, including the ones you enumerate below. I don't think this requires any support in the protocol, though. We mention, but do not mandate, that a proxy server can reject requests that have an inappropriate hint. I'm not sure I see any value in strengthening this. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Tuesday, May 28, 2002 12:23 AM > To: Cullen Jennings > Cc: sip@ietf.org > Subject: [Sip] draft-ietf-sip-asserted-identity-00 > > > once again: > > the term "hint" is not a good one. if user adds the a-i, then the > network MUST respect it or reject the request. the network MUST not > override the a-i and pick one of the identities on its own. for > example, the user may have misspelled the its uri in the a-i. > > also, the text should say that in case from is anonymous the user MUST > insert the a-i header if it has multiple identities, because otherwise > the network cannot know which identity the user wants to use. > > finally, for backwards compatibility, if from is not anonymous and the > user has multiple identities, then from uri can serve as the > purpose of > a-i. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:47:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11708 for ; Wed, 29 May 2002 07:47:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03800 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:47:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02949; Wed, 29 May 2002 07:34:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02916 for ; Wed, 29 May 2002 07:34:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11209; Wed, 29 May 2002 07:33:38 -0400 (EDT) Message-Id: <200205291133.HAA11209@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:33:37 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SCTP as a Transport for SIP Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo Filename : draft-ietf-sip-sctp-02.txt Pages : 11 Date : 28-May-02 This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-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-ietf-sip-sctp-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sctp-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sctp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sctp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130906.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:47:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11730 for ; Wed, 29 May 2002 07:47:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03851 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:48:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02677; Wed, 29 May 2002 07:33:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02647 for ; Wed, 29 May 2002 07:32:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10977; Wed, 29 May 2002 07:32:31 -0400 (EDT) Message-Id: <200205291132.HAA10977@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:32:30 -0400 Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Access Network Info header Author(s) : D. Mills Filename : draft-mills-sip-access-network-info-02.txt Pages : 8 Date : 28-May-02 This mechanism is useful in SIP networks that provide layer 2/layer 3 connectivity through different access technologies. SIP User Agents This document defines the private SIP extension header P-Access- Network-Info. may use this header to relay information about the access technology to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-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-mills-sip-access-network-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mills-sip-access-network-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mills-sip-access-network-info-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-mills-sip-access-network-info-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130701.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:50:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11938 for ; Wed, 29 May 2002 07:50:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03964 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:51:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03109; Wed, 29 May 2002 07:34:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02993 for ; Wed, 29 May 2002 07:34:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11246; Wed, 29 May 2002 07:33:49 -0400 (EDT) Message-Id: <200205291133.HAA11246@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:33:49 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-privacy-general-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : A Privacy Mechanism for the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-ietf-sip-privacy-general-00.txt Pages : 28 Date : 28-May-02 This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new 'privacy service' logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-general-00.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-ietf-sip-privacy-general-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-privacy-general-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528133320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-privacy-general-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-privacy-general-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528133320.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:53:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12079 for ; Wed, 29 May 2002 07:53:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04088 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:53:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02494; Wed, 29 May 2002 07:31:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02462 for ; Wed, 29 May 2002 07:31:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10731; Wed, 29 May 2002 07:31:10 -0400 (EDT) Message-Id: <200205291131.HAA10731@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:31:09 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-reg-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Session Initiation Protocol (SIP) Event Package for Registrations Author(s) : J. Rosenberg Filename : draft-rosenberg-sip-reg-00.txt Pages : 24 Date : 28-May-02 This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. These registrations therefore represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-reg-00.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-rosenberg-sip-reg-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-reg-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130450.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:53:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12093 for ; Wed, 29 May 2002 07:53:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04102 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02989; Wed, 29 May 2002 07:34:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02951 for ; Wed, 29 May 2002 07:34:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11227; Wed, 29 May 2002 07:33:43 -0400 (EDT) Message-Id: <200205291133.HAA11227@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:33:42 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-asserted-identity-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks Author(s) : C. Jennings, J. Peterson, M. Watson Filename : draft-ietf-sip-asserted-identity-00.txt Pages : 17 Date : 28-May-02 This document describes private extensions to SIP that enable a network of trusted SIP servers to assert the identity of end users or end systems, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for inter-domain use, or use in the Internet at large. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-00.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-ietf-sip-asserted-identity-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-asserted-identity-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528133256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-asserted-identity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-asserted-identity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528133256.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 07:55:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12187 for ; Wed, 29 May 2002 07:55:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04310 for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:56:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02546; Wed, 29 May 2002 07:31:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02516 for ; Wed, 29 May 2002 07:31:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10776; Wed, 29 May 2002 07:31:22 -0400 (EDT) Message-Id: <200205291131.HAA10776@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:31:21 -0400 Subject: [Sip] I-D ACTION:draft-camarillo-sip-compression-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Compressing the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-camarillo-sip-compression-01.txt Pages : 11 Date : 28-May-02 This document describes a mechanism to signal that compression is desired for one or more SIP messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-compression-01.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-camarillo-sip-compression-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-sip-compression-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-compression-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-compression-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130511.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 08:22:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13420 for ; Wed, 29 May 2002 08:22:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06505 for sip-archive@odin.ietf.org; Wed, 29 May 2002 08:22:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04522; Wed, 29 May 2002 07:57:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00209 for ; Wed, 29 May 2002 06:47:25 -0400 (EDT) Received: from hotmail.com (f314.law10.hotmail.com [64.4.14.189]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10078 for ; Wed, 29 May 2002 06:47:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 May 2002 03:46:54 -0700 Received: from 192.35.17.22 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 29 May 2002 10:46:54 GMT X-Originating-IP: [192.35.17.22] From: "Salva Rey" To: sip@ietf.org Date: Wed, 29 May 2002 10:46:54 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 May 2002 10:46:54.0336 (UTC) FILETIME=[25AD2800:01C206FE] Subject: [Sip] transaction layer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sorry, I posted a very similar question before, the change and addition are in between quote marks. if sending a response on a server transaction a transport error occurs, should the "transaction layer" try on all the destinations resolved by draft-ietf-sip-srv-06.txt (used as reference [4] in draft rfc-2534bis-09), before informing the transaction user of the error, "and transitioning to the terminated state"? thanks a lot, Salva Rey _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 08:27:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13541 for ; Wed, 29 May 2002 08:27:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07081 for sip-archive@odin.ietf.org; Wed, 29 May 2002 08:27:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04492; Wed, 29 May 2002 07:57:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00007 for ; Wed, 29 May 2002 06:41:34 -0400 (EDT) Received: from hotmail.com (f198.law10.hotmail.com [64.4.15.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10006 for ; Wed, 29 May 2002 06:41:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 May 2002 03:41:03 -0700 Received: from 192.35.17.22 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 29 May 2002 10:41:03 GMT X-Originating-IP: [192.35.17.22] From: "Salva Rey" To: sip@ietf.org Date: Wed, 29 May 2002 10:41:03 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 May 2002 10:41:03.0892 (UTC) FILETIME=[54CBA540:01C206FD] Subject: [Sip] Transport layer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, if sending a response on a server transaction a transport error occurs, should the transport layer try on all the destinations resolved by draft-ietf-sip-srv-06.txt (used as reference [4] in draft rfc-2534bis-09), before informing the transaction user of the error? thanks a lot, Salva Rey _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 09:08:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15248 for ; Wed, 29 May 2002 09:08:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11894 for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:08:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09825; Wed, 29 May 2002 08:49:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09713 for ; Wed, 29 May 2002 08:49:20 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14362 for ; Wed, 29 May 2002 08:48:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmemG021093; Wed, 29 May 2002 14:48:40 +0200 (MEST) Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmcIJ006794; Wed, 29 May 2002 15:48:38 +0300 (EET DST) Message-ID: <3CF4CD58.6A0BE283@ericsson.com> Date: Wed, 29 May 2002 15:45:12 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Bob Penfield CC: Tan Ya-Ching ICM N PG U ID A 1 , sip@ietf.org Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01 References: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e> <3CF1FC20.3CFDAEE6@ericsson.com> <002001c20671$db2b14e0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob: Thanks for your comments. Answers inline. /Miguel Bob Penfield wrote: > > A couple follow-ups and one new comment below > [snip] > > Does the fact that one would want to use P-Called-Party-ID when they cannot > (or will not) rely on the To field, need be included in the applicability > statement? IMHO any decent implementation should not rely on the To header for any other thing that maintaining the dialogs (and for that you need only the tag). This should be evident for the SIP ilustrated reader. Therefore, I don't think it is necessary to add anything else in the applicability statement. > > > > > > | > o The term "standalone method" is not defined in SIP RFC. > > > | > > > | > > > | I'll fix it somehow, but I think that the term standalone, > > > | although not define in RFC 3261, is understandable by the > > > | reader familiar with SIP. > > > | > > > > > > RFC 3261 even defines terms such as "Message", "Parallel Search". One > simply > > > can't start using a new term like "standalone request" or "standalone > > > transaction request" and assume that it is 'understandable by the reader > > > familiar with SIP'. > > > > > > > Yes, I understand your comment. I will do my best to make it > > clear what it means in the next version. > > > > I think what you are trying to say is that the P-Called-Party-ID can be > inserted in any request that initiates a dialog, or any request that is > completely outside of a dialog. These should be the only requests that would > have been issued with an AOR type Request-URI that a proxy would replace. > All other requests (those within an existing dialog) would have a > Request-URI equal to a URI that the UA learned from a Contact header in the > request/response that created the dialog. Is this correct? Precisely. > New issue: > > In the header field table in Section 5, shouldn't the header be optional for > a SUBSCRIBE and not allowed for a NOTIFY? SUBSCRIBE initiates a dialog, and > NOTIFY should use the value from the Contact of the SUBSCRIBE for the R-URI > (thus R-URI would not be changed by a proxy). Definitely. Thanks for catching the bug. > > cheers, > (-:bob -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 09:08:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15265 for ; Wed, 29 May 2002 09:08:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11909 for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:08:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09836; Wed, 29 May 2002 08:49:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09719 for ; Wed, 29 May 2002 08:49:21 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14365 for ; Wed, 29 May 2002 08:48:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmW6n023273; Wed, 29 May 2002 14:48:32 +0200 (MEST) Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmTIJ006770; Wed, 29 May 2002 15:48:29 +0300 (EET DST) Message-ID: <3CF4CA18.C875EE15@ericsson.com> Date: Wed, 29 May 2002 15:31:20 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <3CF3596B.13D72E7@ericsson.com> <3CF3B0B1.F176F2F4@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > "Miguel A. Garcia" wrote: > > > > > > On an unrelated note, I must admit being baffled about why this is > > > useful in a subscribe response. It seems like the associated URI are > > > closely related to registrations, not subscriptions. > > > > And in fact, the only usage in 3GPP is in registrations. But I got > > some comments that this may be useful in subscriptions as well. If > > nobody > > shouts, I will remove the usage of the header in subscriptions and > > restrict > > the scope to REGISTER only. > > Yes, please. I think we should strive to limit scope for P-headers, not > the other way around. This is especially true when the motivating need > is not even clear. Miguel-> Fine. I fixed that. > > > 1. the syntax does not permit an empty value for the P-Associated-URI. > > > What happens if there are no associated URI? If you simply omit the > > > header altogetrher, how does the UA distinguish the case where the > > > registrar doesn't support the extension, as opposed to the registrar > > has > > > no associated URIs? > > > > Do we need to make a distinction between both cases? Either case, the > > user knows that no other identities are associated by the registrar, > > and therefore, explicit actions (e.g., REGISTER) has to be taken by > > the UAC. > > I thought you indicated below that this extension did not imply the > registration of the associated identities... > > That aside, it does make a difference. The UA needs to know whether it > can put any identity it likes in the From field (since the network is > not trying to impose restrictions on the set), or whether it can't put > any identity except the one it registered (since the network is imposing > restrictions, and there is just one valid identity). Miguel-> Fine. I added some text explaining this situation. > > > 2. Is there an implicit assumption that the registrar will register > > the > > > associated URI? I believe this is true in the 3gpp case. A UA probably > > > needs to know whether they have been registered or not. I would not > > want > > > to put a URI into a Reply-To header unless I knew it was a valid URI > > for > > > receiving incoming calls.... > > > > No, this is not the case. The "reg" event will provide such information. > > But the semantics of this header is just to provide a set of IDs that > > the > > user has associated to the address-of-record. They may or may not be > > registered, > > the user will know this information by other means (subscription to the > > registration event package). The user knows that he can initiate > > registration > > of any of the returned IDs, or it can populate the From with any of > > those > > IDs as well. That's it. > > Presumably the UA will need to make sure that they are registered; you > should probably note in the draft that there is no assumption that the > associated URI are registered, and that if the UA wants that, it should > check and perform the registrations if needed. Miguel-> Done. I some text referencing the registration event package, as the mechanism to guess whether the associated URIs are registered or not. > > > > 5.3 Procedures at the proxy > > > > > > > > This memo does not define any procedures at the proxy. > > > > > > > > > > Well, presumably some proxy will enforce the list of associated-URI, > > and > > > reject requests that have a value in the From field not amongst the > > > allowed set? Is there a new response code for that? > > > > Yes, the proxy will send a 403 Forbidden. However, I don't think this is > > > > part of the scope of this I-D. I understand that the title "Procedures > > at > > the proxy" are procedures related to the extension (the header in this > > case). > > The idea in this I-D is to convey to the UA the list of URIs that he can > > use > > in subsequent requests, not how to police them. Therefore, there are not > > procedures at the proxy related to the P-Associated-URI header. > > Well, its all intertwined. The associated-URI list is the only way a UA > has to retry if it should get this error, since it conveys the allowed > URI in the first place. Actually, 403 is really NOT the right response. > If it gets this, how does the UA recover? It needs to know that the > problem was a disallowed From value, and it needs to know which ones are > OK. I would argue that the way to deal with this is a new response code > that would contain in it the Associated-URI header indicating which ones > are allowed. There are two issues to solve here, namely: 1) Does the UAC need to know there was something wrong with one of the headers? I would say, yes. And I agree that the proxy should return the list of allowed IDs in the form of a P-Associated-URI. 2) Is 403 the best response code? I don't see why 403 is not a right response code *if we add the P-Associated-URI* to the response in the 403. Once must notice also that P- headers can't add a new response code. So my proposal: the policy enforcement proxy returns a 403 response in case the URI in the From header or any other SIP header value that provides information of the identity of the calling party is not populated with any of the allowable URIs. The proxy adds a P-Associated-URI header with the complete list of allowable URIs to the user. Is this correct? /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 09:08:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15280 for ; Wed, 29 May 2002 09:08:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11923 for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:08:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09810; Wed, 29 May 2002 08:49:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09706 for ; Wed, 29 May 2002 08:49:20 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14364 for ; Wed, 29 May 2002 08:48:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmNmG020941; Wed, 29 May 2002 14:48:23 +0200 (MEST) Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmJIJ006757; Wed, 29 May 2002 15:48:20 +0300 (EET DST) Message-ID: <3CF4B20D.5180A4F7@ericsson.com> Date: Wed, 29 May 2002 13:48:45 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Michael Thomas , Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <15603.34487.286237.10847@thomasm-u1.cisco.com> <3CF3AEF9.EF57314C@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Michael Thomas wrote: > > > > So, I have a really dumb question. Why don't you > > limit the number of assertable identities by > > cryptographic means? That is, if I can't prove > > that I own an identity binding, it gets dumped > > on the floor? > > Sure; I think the issue (Miguel can correct me if I'm wrong), is that > the UA needs to be configured with the set of identities it can claim in > the first place. The same credentials would allow the user to assert any > one of those, but the phone needs to know which it should present to the > user to use. Jonathan, I must correct you. This is the story in 3GPP: there may be cases where the user has one identity configured in a special SIM card called the IMS SIM (ISIM). The network may have allocated other identities to the user, and those IDs arepreconfigured in the network, but not in the terminal nor in the ISIM. The user will register with the ID configured in the ISIM and will get back the others allocated to him. There are other cases where the user may not even have an ISIM. It has only a UMTS SIM, USIM (let's say, the old card). In this case, there is nothing related to SIP configured in his SIM card, becuase that card was developped before SIP was introduced in 3GPP. The terminal will derive certain SIP identites from the USIM, it will register to his home network, and get back "the real" SIP identities. Summarizing, there are cases where the user does not even know who he is. So no, we can't take the assumption that the UA is aware of all the identities allocated to him. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 09:14:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15600 for ; Wed, 29 May 2002 09:14:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12476 for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:14:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09788; Wed, 29 May 2002 08:49:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09712 for ; Wed, 29 May 2002 08:49:20 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14363 for ; Wed, 29 May 2002 08:48:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmbmG021052; Wed, 29 May 2002 14:48:37 +0200 (MEST) Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmXIJ006778; Wed, 29 May 2002 15:48:34 +0300 (EET DST) Message-ID: <3CF4CBEB.42321922@ericsson.com> Date: Wed, 29 May 2002 15:39:07 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Dean Willis CC: "'Jonathan Rosenberg'" , "'Michael Thomas'" , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > Michael Thomas wrote: > > > > > > So, I have a really dumb question. Why don't you > > > limit the number of assertable identities by > > > cryptographic means? That is, if I can't prove > > > that I own an identity binding, it gets dumped > > > on the floor? > > > > Sure; I think the issue (Miguel can correct me if I'm wrong), > > is that the UA needs to be configured with the set of > > identities it can claim in the first place. The same > > credentials would allow the user to assert any one of those, > > but the phone needs to know which it should present to the > > user to use. > > It goes a little further than this. We're also informing the UA of a > number of extisting "aliases". The UA can expect to see calls "To:" any > of these aliases, and needs to delivery them appropriately to the user > as direct calls rather than as calls targeted originally to some other > user that have just been forwarded here. This might interact with > distinctive-ringing features, for example. I don't know where did you get this information, but as far as I know, what you are saying is not within the scope of the draft. You are assuming an implicit 3rd party registration of all the associated URIs. And I have just added some text to the draft to clarify that this is not the case. The associated URIs, in the general case, are not implicitly registered. The UAC should use other mechanism, such as a subscription to its own registration event to guess it. In 3GPP some of the associated-URIs are implicitly registered by the registrar, but that is not even the general case for the P-Associated-URI. /Miguel > So there is applicability in both "UA-originated" and UA-terminated" > scenarios, and there is no requirement that the client be able to > cryptographically assert the identity associated with an inbound alias. > > -- > Dean -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 09:31:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16387 for ; Wed, 29 May 2002 09:31:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13580 for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:32:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12325; Wed, 29 May 2002 09:13:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12282 for ; Wed, 29 May 2002 09:13:18 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15543 for ; Wed, 29 May 2002 09:12:56 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 29 May 2002 08:11:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <7E06D3212981524CA10D2A114937C41484AE25@NREXCH.netrake.net> Thread-Topic: Comment on draft-willis-sip-scvrtdisco-05 Thread-Index: AcIHElNxu/xsR5PmSB+Vh+XdzsVwrQ== From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA12283 Subject: [Sip] Comment on draft-willis-sip-scvrtdisco-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit In section 5 "Syntax", why is the form for P-Service-Route: P-Service-Route = "P-Service-Route" HCOLON 1#( p-sr-value) instead of what is the defacto common form: P-Service-Route = "P-Service-Route" HCOLON p-sr-value *( COMMA p-sr-value ) Additionally, if the first form is used, what is the delimiter between p-sr-value fields? Can I assume it's WSP? - rob -- Rob Phillips, Sr. Software Engineer Netrake Corporation mailto: rob@netrake.com 3000 Technology Drive voice: (214) 291-1096 Suite 100 fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 10:44:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19700 for ; Wed, 29 May 2002 10:44:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18721 for sip-archive@odin.ietf.org; Wed, 29 May 2002 10:44:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16743; Wed, 29 May 2002 10:16:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16712 for ; Wed, 29 May 2002 10:16:04 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18687 for ; Wed, 29 May 2002 10:15:40 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 29 May 2002 09:15:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <7E06D3212981524CA10D2A114937C41484AE26@NREXCH.netrake.net> Thread-Topic: Comment on draft-mills-sip-access-network-info-02 Thread-Index: AcIHG0fWrz9jnUVYR5SgnEfrng1KRg== From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA16713 Subject: [Sip] Comment on draft-mills-sip-access-network-info-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit In section 7 "The P-Access-Network-Info header", the rules for 3gpp-cgi , and 3gpp-utran-cell-id need to have their rule names changed. RFC2234 section 2.1 specifies that rule names must start with an alpha character only, not an alphanum. Might I suggest access-3gpp-cgi, and access-3gpp-utran-cell-id - rob -- Rob Phillips, Sr. Software Engineer Netrake Corporation mailto: rob@netrake.com 3000 Technology Drive voice: (214) 291-1096 Suite 100 fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 14:10:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27364 for ; Wed, 29 May 2002 14:10:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05126 for sip-archive@odin.ietf.org; Wed, 29 May 2002 14:11:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02547; Wed, 29 May 2002 13:45:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02513 for ; Wed, 29 May 2002 13:45:16 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26504 for ; Wed, 29 May 2002 13:44:50 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4THi6420090; Wed, 29 May 2002 12:44:07 -0500 From: "Dean Willis" To: "'Miguel A. Garcia'" , "'Jonathan Rosenberg'" Cc: , , , Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Date: Wed, 29 May 2002 12:43:23 -0500 Message-ID: <004b01c20738$5517a090$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3CF4CA18.C875EE15@ericsson.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > > > 2. Is there an implicit assumption that the registrar will > > > > register > > > the > > > > associated URI? I believe this is true in the 3gpp case. A UA > > > > probably needs to know whether they have been > registered or not. I > > > > would not > > > want > > > > to put a URI into a Reply-To header unless I knew it > was a valid > > > > URI > > > for > > > > receiving incoming calls.... > > > > > > No, this is not the case. The "reg" event will provide such > > > information. But the semantics of this header is just to > provide a > > > set of IDs that the user has associated to the address-of-record. > > > They may or may not be registered, > > > the user will know this information by other means > (subscription to the > > > registration event package). The user knows that he can initiate > > > registration > > > of any of the returned IDs, or it can populate the From > with any of > > > those > > > IDs as well. That's it. > > > > Presumably the UA will need to make sure that they are > registered; you > > should probably note in the draft that there is no > assumption that the > > associated URI are registered, and that if the UA wants that, it > > should check and perform the registrations if needed. > > Miguel-> Done. I some text referencing the registration event package, > as the mechanism to guess whether the associated URIs are > registered or not. I think there's some confusion about what "registered" means for an associated URI. URIs often work without anyone having sent a REGISTER message associating a contact with them. For example, in my office, 9724735455@dynamicsoft.com is configured in my home server to forward to dwillis@dynamcisoft.com. So, 9724735455@dynamicsoft.com is an "associated URI" that might be included in the P-Associated-URI response when dwillis@dynamicsoft.com registers. The question of "does inclusion in a P-Associated-URI header mean that the registrar registered that URI" is orthogonal to this draft and completely out of scope. There may or may not be one or more regisistations for each associated URI -- it just doesn't matter as far as this draft is concerned. I think from some of the comments that people are reading the draft BACKWARDS. This is not a mechanism by which a UA requests registratio of additional URIs. This is a technique by which a registrar informs a UA of aliases known to the registrar which will be forwarded to the UA. > > > > > > 5.3 Procedures at the proxy > > > > > > > > > > This memo does not define any procedures at the proxy. > > > > > > > > > > > > > Well, presumably some proxy will enforce the list of > > > > associated-URI, > > > and > > > > reject requests that have a value in the From field not amongst > > > > the allowed set? Is there a new response code for that? > > > > > > Yes, the proxy will send a 403 Forbidden. However, I don't think > > > this is > > > > > > part of the scope of this I-D. I understand that the title > > > "Procedures at the proxy" are procedures related to the extension > > > (the header in this case). > > > The idea in this I-D is to convey to the UA the list of > URIs that he can > > > use > > > in subsequent requests, not how to police them. > Therefore, there are not > > > procedures at the proxy related to the P-Associated-URI header. > > > > Well, its all intertwined. The associated-URI list is the > only way a > > UA has to retry if it should get this error, since it conveys the > > allowed URI in the first place. Actually, 403 is really NOT > the right > > response. If it gets this, how does the UA recover? It > needs to know > > that the problem was a disallowed From value, and it needs to know > > which ones are OK. I would argue that the way to deal with > this is a > > new response code that would contain in it the > Associated-URI header > > indicating which ones are allowed. Actually, we're doing identity filtering, not From filtering. The UA would presumbaly use a P-Asserted-Identity header to assert one of the associated URIs on a new request. We need to evaluate the following proposal in that context. > There are two issues to solve here, namely: > 1) Does the UAC need to know there was something wrong with one of the > headers? I would say, yes. And I agree that the proxy should return > the list of allowed IDs in the form of a P-Associated-URI. > 2) Is 403 the best response code? I don't see why 403 is not a right > response code *if we add the P-Associated-URI* to the response in > the 403. Once must notice also that P- headers can't add a new > response code. > > So my proposal: the policy enforcement proxy returns a 403 > response in case the URI in the From header or any other SIP > header value that > provides information of the identity of the calling party is not > populated with any of the allowable URIs. The proxy adds a > P-Associated-URI header with the complete list of allowable > URIs to the user. Is this correct? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 15:37:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00570 for ; Wed, 29 May 2002 15:37:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12413 for sip-archive@odin.ietf.org; Wed, 29 May 2002 15:37:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10470; Wed, 29 May 2002 15:05:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10439 for ; Wed, 29 May 2002 15:05:50 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29260 for ; Wed, 29 May 2002 15:05:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4TJ2aLe015226 for ; Wed, 29 May 2002 15:02:36 -0400 (EDT) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LJW81ZN8; Wed, 29 May 2002 15:05:17 -0400 Message-ID: <3CF5266D.5030802@dynamicsoft.com> Date: Wed, 29 May 2002 15:05:17 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] draft-mills-sip-access-network-info-02.txt grammer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Nit: the grammar seems to allow only one access-info parameter per P-Access-Network-Info header. Is that intentional? Anders _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 15:58:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01324 for ; Wed, 29 May 2002 15:58:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13527 for sip-archive@odin.ietf.org; Wed, 29 May 2002 15:58:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11604; Wed, 29 May 2002 15:29:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11554 for ; Wed, 29 May 2002 15:29:34 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00168 for ; Wed, 29 May 2002 15:29:10 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.13]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TJUQYH026664; Wed, 29 May 2002 15:30:26 -0400 (EDT) Message-ID: <3CF52BF1.31047ADC@dynamicsoft.com> Date: Wed, 29 May 2002 15:28:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'sip'" , rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, "Jon Peterson (jon.peterson@NeuStar.com)" Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general References: <00d901c2068f$1e0b4420$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Comments: > Withholding the identity of a user will, among other > things, render the other parties in the dialog unable to send new SIP > requests to the user outside of the context of the current dialog. Thats not necessarily true; I can remain anonymous and even get a call back later on (for example, Reply-To: sip:user8222739@anonymous.net) - the key is that my identity is never revealed. > A display-name is a quoted string containing > a name for the identified user (for example, "Alice"). As a nit, display-names need not be quoted strings. > The privacy problem is further complicated by proxy servers (also > referred to in this document as "intermediaries" or "the network") > that add headers of their own, such as the Record-Route and Via > headers. Its probably also worth referncing the identity work as another source of identity information that can be inserted by proxies. > The scope of these privacy requirements is solely the SIP protocol as > it is described in [1]. The mechanisms at the disposal of user > agents and proxy servers are restricted to those described in the SIP > specification. Also, the privacy properties of the headers listed in > the core SIP specification alone, as opposed to headers defined by > any existing or planned extension, are considered here. I don't quite understand this paragraph. If a future extension defines a header that reveals identity information, shouldn't this draft cover requests for privacy of that information? > The > author maintains that these problems are sufficiently well addressed > in the baseline SIP specification and related documents, and that no > new mechanisms are required. Minor nit - but as a working group draft, its not appropriate to make statements about the opinions of the author, as the document represents group consensus. Its sufficient to just strike "The author maintains that". > When a user voluntarily asserts an identity in a request, they are > claiming that they can receive requests sent to that identity in that > domain. Thats a narrow definition of identity, particularly since the draft discusses ip address privacy, which wouldn't qualify as an identity by the above definition. Neither would a contact URI. meta-comment: as the draft is a bit verbose, it might be helpful to have in the introduction a paragraph or two which overviews the structure of the document and discusses how the sections relate. > The following SIP headers, when generated by a user agent, can > directly or indirectly reveal identity information about the > originator of a message: From, Contact, Reply-To, Via, Call-Info, > User-Agent, Organization, Subject, Call-ID, In-Reply-To The sentence ends mid-stream. Also, you have forgotten two very, very important ones - Authorization and Proxy-Authorization. In general, I think the draft needs discussion of these headers specifically. The user should only include such headers if it is willing to provide identity information for the realm provided in the challenge. Furthermore, the user may need to verify that the proxy is indeed part of the realm that they claim to be from before the user provides identity information to it. Right now, we have no real way to do that unless the proxy is the first hop proxy, in which case TLS can be used to ascertain the identity of the proxy that is providing the challenge before providing credentials. All of this needs to be discussed. The issue is similar to that of routing requests to privacy services. Also, you left off the Server header and the Warning header, both of which can potentially (although unlikely) reveal identity information in a response. > destination of the message, users MAY also place legitimate values > for these headers in encapsulated 'message/sip' S/MIME bodies as > described in the SIP specification. A reference to the specific section number would be useful here. > Privacy-hdr = "Privacy" HCOLON priv-value *(COMMA priv-value) > priv-value = "header" | "session" | "user" | "none" | "critical" | token I would strongly advise that you also allow for semi-colon separated parameters for the purposes of future extensibility. Also, you need to use slashes "/" to separate or-values, not vertical bars "|". > header: The user requests that a privacy service obscure those > headers cannot be completely expunged of identifying information > without the assistance of intermediaries (such as Via and > Contact). s/cannot/that cannot > Note that requesting session privacy when end-to-end session > encryption is not possible raises serious security concerns (see > Section 6.2). Indeed. This is why I wrote http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt which allows both to the extent that is possible. > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Privacy amrd o o o o o - I think privacy is still useful in a register message. It would be helpful when I want to register through my provider using an anonymizer service, which possibly obfuscates the Contact header. Interestingly, the privacy service couldn't obfuscate the From or To field, since these are needed by the registrar. Perhaps that is why Privacy is not allowed here? It makes me wonder if there is a need to specify privacy on a slighlty more granular level, allowing the user to request obfuscation of groups of headers (To/From in one group, Contact/Via/RR in another). Also, you need to explicitly specify the set of valid combinations of the various privacy values; its not entirely clear from the text. > critical: The user asserts that the privacy services requested for > this message are critical, and that therefore, if these privacy > services cannot be provided by the network, this request should be > rejected. Criticality cannot be managed appropriately for > responses. OK, I hate to dredge up old issues, and perhaps this was hashed out in the many privacy threads I didn't get to, but, it seems like the value of critical is going to neccessitate a Proxy-Require header. The draft makes no mention of the use of proxy-require or the protocol implications if the extension is not supported by proxies. The proxy-require can be removed once the services have been performed, which is a good thing. > It is RECOMMENDED that service providers couple the privacy service > function with a local outbound proxy. Users can thereby send their > messages that request privacy through their usual outbound route. > Users should not assume, however, that the administrative domain that > is the destination of the request would be willing and able to > perform the privacy service function on their behalf. How does the user know whether privacy services are supported? Do they need to try it with Proxy-Require to see if the request fails? I also toyed with the idea of defining a URI parameter that indicated that the URI represents a resource that can provide privacy functions, similar to the way we have a URI parameter for indicating that a resource can provide compression. However, I don't think this is a good idea, but wanted to mention it for completeness. > What a responding user agent can do, however, is ensure that the path > by which requests reach them traverses their privacy service. In > some architectures, the privacy service function will be fulfilled by > the same server to which requests for the local administrative domain > are sent, and hence it will automatically be in the path of incoming > requests. However, if this is not the case, the user will have to > ensure that requests are directed through a third-party privacy > service. The simplest way to accomplish this is to procure a > 'private' URI from the third-party service and to distribute this as > an address-of-record. The user would then register their normal > address-of-record as a contact address with the third-party service. Based on this, the third party privacy service would see the request before their actual provider. I can imagine there are also cases where the opposite makes more sense - the user registers their anonymous AOR as a contact address with their actual provider. TO me, this makes more sense. You want the privacy function closest to the user; in the case of responses, that means that you want it to be the first element that gets the response, which would motivate registering the anonymous AOR as a contact with the actual provider. Another means for providing anonymity of responses is to use a CPL script to forward a request to the anonymization service. I think its worth mentioning this as well. This also raises the question of whether a privacy service is a "hop" described by a URI in a route header, or is an identity, which would appear in the request URI and be translated. Clearly, the assumption above is the latter. Thats going to be true for some privacy services, but for things like session privacy, I would argue that these are hops, and they are ideally reached with URIs in route headers, not the request-URI. > The techniques described in this section do not extend to the > creation of falsified but plausible URIs and display-names that do > not identify the originator but may fool the remote party into > believing that the originator is not anonymous. Awkward - reword. > If these headers require anonymization, the > user MUST request that service from an intermediary, namely a privacy > service. > MUST seems overly strong in this case.... > For headers indicating how further requests in the current dialog > should be routed (such as the Contact header) I think its useful to provide the full set, namely, Contact, Via, and SDP addresses and hostnames. I don't understand why section 5 is a separate section. Since its about construct anonymous messages, it seems like it is naturally a subsection of 4.1. This relates to my meta-comment about the verbosity of the draft; it reads a bit too much like a dialog, and not quite enough like a protocol specification. Section 5 is really describing normative behavior for user agents, and belongs in the section which describes that. > This document defines a new SIP logical role called a "privacy > service". The privacy service role is instantiated by a network > intermediary, frequently by entities that can act as SIP proxy > servers. The function of a privacy service is to supply privacy > functions for SIP messages that cannot be provided by user agents > themselves. I think its worth noting that privacy services are described by URIs (see above comments on whether they are hop URIs or destination URIs) > However, if the Privacy header value of > 'none' is specified in a message, privacy services MUST NOT perform > any privacy function. I have a feeling that the MUST NOT strength is going to be a problem for these folks that claim they have a regulatory requirement to provide privacy even when the user doesn't want it (or at least, I recall that this was the claim). > Privacy services MUST implement the 'none' and 'critical' privacy > levels, and MAY implement any of other privacy levels described in > Section 4.2 as well as any extensions that are not detailed in this > document. 'critical' is not really a level, so much as a qualifier on all of the other levels. > When a privacy service performs one of the functions corresponding to > a privacy level listed in the Privacy header, it SHOULD remove the > corresponding priv-value from the Privacy header - otherwise, any > other privacy service involved with routing this message might > unnecessarily apply the same function, which in many cases would be > undesirable. When the last priv-value (not counting 'critical') has > been removed from the Privacy header, the entire Privacy header MUST > be removed from a message. I am concerned about the complete removal of the privacy header. THe problem is that downstream elements may insert additional identification information into the request. I would propose that a new value for the header be defined, say "no-add", which tells elements that they don't need to modify any headers, but that they should not add any further identification information to a request. If the header value was present in a request, and is then performed by a proxy, the proxy changes that value to no-add. > Firstly, a request for header privacy entails that the server SHOULD > NOT add any of the following headers to the message: Call-Info, > Server, and Organization. All of these provide optional information > that could reveal facts about the user that has request anonymity. > I would make the statement more general, namely, it SHOULD NOT add any headers which could reveal any identity information. For example, Call-Info, Server and Organization. > Privacy services operating on requests SHOULD remove all Via headers > that have been added to the request prior to its arrival at the > privacy service (a practice commonly referred to as "Via hiding") No, its not "via hiding", which has a specific definition from rfc2543. This is different; I would call it "via stripping". > Note > that the topmost such Via header in a request contains an IP address > or hostname that designates the originating client, and subsequent > Via headers may indicate hosts in the same administrative domain as > the client. This is backwards. Its the bottom-most Via header value. Note also that you should use the formal terminology - there is only one Via header, but it has multiple values. > When a privacy service alters the Contact header of a > request, it MUST insert a Record-Route header pointing to itself so > that it can restore the appropriate contact address as necessary. Thats not true. The Contact header will presumably route to itself, so that an additional record-route is not necessary. > In a manner similar to Via hiding, a privacy service SHOULD also hide > any Record-Route headers that have been added to a request before it > reaches the privacy service. Such Record-Route headers might also > divulge information about the administrative domain of the client. > Once Record-Route headers have been hidden, however, the privacy > service MUST add appropriate Route headers to future requests as > needed. Given how easy it is to get this wrong, I would avise putting a bit more text in there about properly constructing the route and record-routes. > that are so removed, which requires the privacy service to keep a > pretty significant amount of state on a per-session basis. Its per-dialog. Its worth noting that forking could create multiple dialogs, each of which would then need to be managed. > Note that the privacy service MUST remove any non-essential > informational headers that have been added by the client, including > the Subject, Call-Info, Organization, User-Agent, Reply-To and In- > Reply-To. You use the term client here, which would imply that this is only for requests. Since the spec is generally request/response agnostic, you need to use the term "user agent". I suspect there are other instances of things like this too; I personally read most of the draft with requests in mind. Its worth doing a pass on the document with responses in mind to make sure its correct. > Therefore, any time that a privacy service needs to modify any > dialog-matching headers for privacy reasons, it SHOULD act as a > transparent back-to-back user agent This was discussed on the list; the term transparent B2BUA is not defined in bis or in this document. You need to be more exact in your definitions. > Note that authentication mechanisms, including the Digest > authentication method described in the SIP specification, are outside > the scope of the privacy considerations in this document. Revealing > identity through authentication is highly selective, and may not > result in the compromise of any private information. Obviously, > users that do not wish to reveal their identity to servers that issue > authentication challenges MAY elect not to respond to such > challenges. Ah, here is some text on Proxy-Auth and Auth. I disagree that these are outside the scope of the spec, and I think they deserve discussion along the lines I have outlined above. > IANA Considerations > > This document defines a new SIP header called "Privacy" that allows a > user agent to request a certain degree of privacy for a message. > This header is defined in Section 4.2. I am a big fan of very explicit IANA considerations sections. I would recommend you format this section as an outline, like this: Header Name to be Registered: Privacy RFC of Specification: RFC XXXX [Note to RFC Editor: please replace XXXX with the RFC number of this specification] Compact Form: none defined By the way, do we want to define a compact form? > The current values of the "Privacy" header are restricted to > 'header', 'session', 'user', 'none' and 'critical'. However, further > values for the "Privacy" header can be defined in RFCs approved by > the SIP working group. IANA registration for these "Privacy" header > field values is required. If you are setting up an IANA registry for these values, you are going to need more detail than this. See the sip-events spec for a good example of how to define an IANA registry. THanks, Jonathan R. Dean Willis wrote: > > We need to do a quick review of the general privacy draft developed out > of our discussion in Las Vegas. > > Please send any issues to the list and the editor IMMEDIATELY. > > The draft is available from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00. > html > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00. > txt > And soon to be available from internet-drafts if not already . . . > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 16:21:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01923 for ; Wed, 29 May 2002 16:21:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14869 for sip-archive@odin.ietf.org; Wed, 29 May 2002 16:21:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13038; Wed, 29 May 2002 15:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13007 for ; Wed, 29 May 2002 15:49:13 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01040 for ; Wed, 29 May 2002 15:48:47 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.13]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TJjqYH026677; Wed, 29 May 2002 15:45:52 -0400 (EDT) Message-ID: <3CF52F8F.687A0636@dynamicsoft.com> Date: Wed, 29 May 2002 15:44:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Miguel A. Garcia'" , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri References: <004b01c20738$5517a090$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > > Presumably the UA will need to make sure that they are > > registered; you > > > should probably note in the draft that there is no > > assumption that the > > > associated URI are registered, and that if the UA wants that, it > > > should check and perform the registrations if needed. > > > > Miguel-> Done. I some text referencing the registration event package, > > as the mechanism to guess whether the associated URIs are > > registered or not. Miguel - there is no need to use the registration event package for this. You can simply send a REGISTER request with the associated URI in the To field, and the registrar will return any registerd contacts. > > I think there's some confusion about what "registered" means for an > associated URI. URIs often work without anyone having sent a REGISTER > message associating a contact with them. For example, in my office, > 9724735455@dynamicsoft.com is configured in my home server to forward to > dwillis@dynamcisoft.com. So, 9724735455@dynamicsoft.com is an > "associated URI" that might be included in the P-Associated-URI response > when dwillis@dynamicsoft.com registers. > > The question of "does inclusion in a P-Associated-URI header mean that > the registrar registered that URI" is orthogonal to this draft and > completely out of scope. There may or may not be one or more > regisistations for each associated URI -- it just doesn't matter as far > as this draft is concerned. > > I think from some of the comments that people are reading the draft > BACKWARDS. This is not a mechanism by which a UA requests registratio > of additional URIs. This is a technique by which a registrar informs a > UA of aliases known to the registrar which will be forwarded to the UA. Whether the forwarding is created as a result of a binding to another URI, or through an implicit registration (whcih is really the same thing anyway), I thought Miguel was saying that there was no assumption about this URI being usable to receive requests. > > > > procedures at the proxy related to the P-Associated-URI header. > > > > > > Well, its all intertwined. The associated-URI list is the > > only way a > > > UA has to retry if it should get this error, since it conveys the > > > allowed URI in the first place. Actually, 403 is really NOT > > the right > > > response. If it gets this, how does the UA recover? It > > needs to know > > > that the problem was a disallowed From value, and it needs to know > > > which ones are OK. I would argue that the way to deal with > > this is a > > > new response code that would contain in it the > > Associated-URI header > > > indicating which ones are allowed. > > Actually, we're doing identity filtering, not From filtering. The UA > would presumbaly use a P-Asserted-Identity header to assert one of the > associated URIs on a new request. > > We need to evaluate the following proposal in that context. I don't see how that changes anything. Anyway, I am not going to push it in the interests of limitng the scope of p-headers. If everyone says that the ability to reject isn't needed, its not needed, and so be it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 16:33:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02377 for ; Wed, 29 May 2002 16:33:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16013 for sip-archive@odin.ietf.org; Wed, 29 May 2002 16:34:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14198; Wed, 29 May 2002 16:04:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14170 for ; Wed, 29 May 2002 16:04:26 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01484 for ; Wed, 29 May 2002 16:03:58 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.13]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TK58YH026738; Wed, 29 May 2002 16:05:08 -0400 (EDT) Message-ID: <3CF53413.20FF612B@dynamicsoft.com> Date: Wed, 29 May 2002 16:03:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, ehenrikson@lucent.com Subject: Re: [Sip] Poll: expert review of draft-henrikson-sip-charging-information References: <00b301c20359$0e1bf0c0$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit First off, I have to apologize for the lateness of these comments. Given the scope of my comments, I should have raised them earlier. I have some serious concerns about this draft. Most notably, I disagree entirely with the assessment that the problem isn't entirely solved by loose routing. When the S-CSCF sends a request to an application server, it ought to be inserting two loose routes - one that points to the AS, and another that points back to itself, containing whatever context is needed for the S-CSCF to do what it needs to do from that point forward. The draft makes the following statement: > One may consider using the Route header as a mechanism to get the > request sent back to the S-CSCF. However, Route headers don't > automatically transit an AS acting as a B2BUA. This could be > overcome by using loose-routing and application logic in the B2BUA. > But that is not the full problem to be solved. A strong correlation > of dialogs is also needed for accounting purposes to treat the > sequence of dialogs as a concatenated single dialog. A common > identification tag needs to be carried in each related dialog so > that the charging functions can associate all the dialogs. A smart B2BUA will not discard loose routes, particularly not one thats used in 3gpp for this reason exactly. Thus, the principal motivation given, being able to corelate incoming INVITEs from outgoing ones in a spiral - is not correct. We explicitly designed the loose routing stuff to enable exactly this kind of function (remember the Bjorkner service route draft?). The other argument that is given here - correlation of dialogs for accounting purposes - makes no sense to me. The route header provides the ability for the S-CSCF to completely correlate the incoming INVITE to the one it sent out. It therefore has all the information it needs to account for the calls and to know which applications are invoked. The last thing I want to do is specify two ways of doing the same thing. Given that this kind of correlation is square in the sights of loose routing, I am concerned about the overlap. -Jonathan R. Dean Willis wrote: > > You may recall that we're doing an Expert Review of > draft-henrikson-sip-charging-information. > > If you have a strong opinion for, against, or supporting a need for > further work, or any further suggestions for enhancement, please post > them now. > > -- > Dean Willis > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 17:06:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03372 for ; Wed, 29 May 2002 17:06:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18628 for sip-archive@odin.ietf.org; Wed, 29 May 2002 17:06:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16428; Wed, 29 May 2002 16:44:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16385 for ; Wed, 29 May 2002 16:44:02 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02604 for ; Wed, 29 May 2002 16:43:35 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4TKgl421240; Wed, 29 May 2002 15:42:48 -0500 From: "Dean Willis" To: "'Miguel A. Garcia'" Cc: "'Jonathan Rosenberg'" , "'Michael Thomas'" , , , , Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri Date: Wed, 29 May 2002 15:42:03 -0500 Message-ID: <000001c20751$4b4bcf00$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3CF4CBEB.42321922@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Wednesday, May 29, 2002 7:39 AM > To: Dean Willis > Cc: 'Jonathan Rosenberg'; 'Michael Thomas'; sip@ietf.org; > rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com > Subject: Re: [Sip] Poll: expert review of > draft-garcia-sip-associated-uri > > > Dean Willis wrote: > > > > > Michael Thomas wrote: > > > > > > > > So, I have a really dumb question. Why don't you > > > > limit the number of assertable identities by > cryptographic means? > > > > That is, if I can't prove that I own an identity > binding, it gets > > > > dumped on the floor? > > > > > > Sure; I think the issue (Miguel can correct me if I'm wrong), is > > > that the UA needs to be configured with the set of > identities it can > > > claim in the first place. The same credentials would > allow the user > > > to assert any one of those, but the phone needs to know which it > > > should present to the user to use. > > > > It goes a little further than this. We're also informing > the UA of a > > number of extisting "aliases". The UA can expect to see calls "To:" > > any of these aliases, and needs to delivery them > appropriately to the > > user as direct calls rather than as calls targeted > originally to some > > other user that have just been forwarded here. This might interact > > with distinctive-ringing features, for example. > > I don't know where did you get this information, but as far > as I know, what you are saying is not within the scope of the > draft. You are > assuming an implicit 3rd party registration of all the > associated URIs. And I have just added some text to the draft > to clarify that this is > not the case. The associated URIs, in the general case, are > not implicitly registered. The UAC should use other > mechanism, such as a subscription to its own registration > event to guess it. No. I'm assuming that any issue of registering an associated URI is completely outside of the scope of this draft. The fact that an associated URI is returned by a registrar has NO INDICATION WHATSOEVER on the registration state of an associated URI. All that is being claimed is that the given URI is associated with the tAOR of the registration request. The UA might assert an associated URI in making a new request. The associate URI might be used to make a new request to the UA. Both of these uses are outside the scope of this draft. Incidentally, I don't believe that subscribing to the registration state of a specific AOR will return anything about the registration state of other AORs that have the first AOR as a Contact or have the same Contact as that first AOR. Instead, I think you actually need to subscribe to the registration state of the AOR in question. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 17:27:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03952 for ; Wed, 29 May 2002 17:27:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19506 for sip-archive@odin.ietf.org; Wed, 29 May 2002 17:27:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18549; Wed, 29 May 2002 17:04:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18523 for ; Wed, 29 May 2002 17:04:45 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03290 for ; Wed, 29 May 2002 17:04:20 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.13]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TL5oYH026802 for ; Wed, 29 May 2002 17:05:50 -0400 (EDT) Message-ID: <3CF5424D.949B5346@dynamicsoft.com> Date: Wed, 29 May 2002 17:04:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org References: <200205291132.HAA10977@ietf.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Comments on this draft: The title needs to have the acronym SIP expanded. The abstract reads oddly; it seems like a sentence has been misplaced: > 1. Abstract > This mechanism is useful in SIP networks that provide layer 2/layer > 3 connectivity through different access technologies. SIP User > Agents > This document defines the private SIP extension header P-Access- > Network-Info. may use this header to relay information about the > access technology to serving proxies in their home network. I think "SIP User Agents" needs to be moved before "may use this header" The applicability statement is not quite right. It needs to capture the specific assumptions and scenarios which limit the scope of this draft. I would propose something like the following: "This draft is appropriate in environments where SIP services are dependent on a SIP elements knowing details about the IP and lower layer technologies used by a UA to connect to the SIP network. Specifically, the extension requires that the UA know the access technology it is using, and that a proxy desires such information to provide services. Generally, SIP is built on the "Everything over IP and IP over Everything" principle, where the access technology is not relevant for the operation of SIP. Since SIP systems generally should not care or even know about the access technology, this draft is not for general SIP usage. The information revealed in the P-Access-Network-Info header is potentially very sensitive. Proper protection of this information depends on the existence of specific business and security relationships amongst the proxies that will see messages containing this header. It also depends on explicit knowledge of the UA on the existence of those relationships. Thefefore, this mechanism is only appropriate in environments where the appropriate relationships are in place, and the UA has explicit knowledge that they exist." > Other examples include a laptop connected to a > wireless LAN at an airport, or a laptop connected to a local ISP > from a hotel room. I have to agree with Bob's assessment that the appropriate business relationships will not be in place between the proxy at the airport and the proxy in my home network. Therefore, this example is really not appropriate. > For instance, > the type of access being used may influence home network decisions > on what level of security to apply to sessions. I don't see what the access network has to do with session level security (or what proxies have to do with session level security). > It may be desired that the home network have the knowledge of some > information relating to the network that provided access to the > service. This sentence is awkward, I suggest rewording to "The home network may desire knowledge about the access network." The introduction and overview aren't really different. I would suggest moving the overview into the introduction, and have a separate "Overview of Operations" section which overviews the basic operation of the extension. That section is fairly short, since the extension is simple. Something like: --- Overview of Operation This section provides an overview of the operation of this extension, and is not normative in nature. When a user agent generates a SIP request which it knows is going to be securely sent to its home network, it inserts a P-Access-Network-Info header into the request. This header contains information on the access network that the UA is using to get IP connectivity. The header is ignored by intermediate proxies between the UA and the home proxy. The home proxy can inspect the header and make use of the information contained there to provide services. Before proxying the request onwards, the home proxy strips the header from the request. --- > The P-Access-Network-Info header MAY be inserted by a UA. Proxies, > MUST NOT add to or modify the contents of the P-Access-Network-Info. This text appears in the section that describes teh syntax and values of the P-header. Generally (as we learned with bis), its better to place normative behavior in one place. Therefore, I suggest you move any normative behavior like this into section 8. Section 7 should remain nothing more than a description of the syntax of the header and the meaning of the various parameters. > The proxy in the home network may act upon any information in the P- > Access-Network-Info header if it is present, to provide a different > service depending on the network through which the UA is accessing > the server. For example, for cellular radio access networks the home > network may use the cell ID to provide basic localised services. > > A proxy in the home network MUST delete the header before forwarding > the message outside of its own administrative network domain or > outside a trusted administrative network domain. this text belongs in 8.2. > Some systems may require that the P-Access-Network-Info header is > only sent by the UAC when a secure connection to the proxy in the > home network is present. For example, in 3GPP systems, the UAC MUST > NOT send this header in the initial unauthenticated REGISTER > request. this text belongs in 8.1. > A UAC supporting this extension may be capable of accessing the > services provided by its home network via one or more access > technologies. This sentence sort of states the obvious. Obviously the UAC is capable of accessing the SIP network through some access technology. > Such a UAC must know the values to use for each type > of supported access technology. The means of this determination are > outside the scope of this document. this belongs in section 8.1. > The home network must know the possible values that a particular UA > may use to populate the access-type and access-info fields. > > In other words, a home network with business agreements allowing > users to access via a particular technology must be able to parse > the P-Access-Network-Info header containing an access-type for that > technology in order to use this information. > > For example, the access-type could read "IEEE-802.11b". If a home > network knows it has a business agreement with a W-LAN access > network, it must be ready to understand the value "IEEE-802.11b". > Similarly, a UAC supporting this extension that can access via W-LAN > must be able to insert the relevant value. This text confuses me, since it tries to belabor an obvious point - that the proxy must know how to parse these values. Maybe I am missing something. Perhaps this is related to the fact that no definition is provided for 3gpp-cgi and 3gpp-utran-cell-id? I don't see why you can't just provide a definition for those and then delete the statements above. > A UAC that supports this extension and is willing to disclose the > related parameters MAY insert the P-Access-Network-Info header in > any SIP message request. You probably need to provide some guidance on when it ought to be doing that. I have a suspicion that you do have specific requirements (like, every request in order to keep cell-id up to date). > This document does not define either the nature of the information > or the messages where the P-Access-Network-Info needs to be > inserted. This is confusing; it does define the nature of the information. What am I missing? > A proxy, typically located in the home network, and therefore > trusted, MUST delete the header when the SIP signaling is forwarded > to a SIP server located in a non-trusted administrative network > domain. The access network information is used by a home network and > is of no interest to the destination > network. What about a trusted administrative network domain? I think that the home proxy MUST strip this in all cases. > This extension assumes that the access network is trusted by the UA > (because the UAÆs home network has a trust relationship with the > access network), as described in section 7. The trust relationship is not between the access network and the home network. The assumption is that there is a trust relationship between the UA and the proxy it sends the request to, and then between all proxies between the outbound proxy and the home proxy. > The home network uses the information contained in this header to > provide additional services and This sentence ends mid-stream. > UAs are expected to provide correct information. However, there are > no security problems resulting from a UAC inserting incorrect > information. Well, I doubt that is true in the case of cell-id. Providing false location information can be used for all sorts of bad things. Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The SIP Access Network Info header > Author(s) : D. Mills > Filename : draft-mills-sip-access-network-info-02.txt > Pages : 8 > Date : 28-May-02 > > This mechanism is useful in SIP networks that provide layer 2/layer > 3 connectivity through different access technologies. SIP User > Agents > This document defines the private SIP extension header P-Access- > Network-Info. may use this header to relay information about the > access technology to serving proxies in their home network. The > serving proxy may then use this information to optimize services for > the UA. For example, a 3GPP terminal uses this header to pass > information about the access network such as radio access technology > and cell ID to its home service. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-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-mills-sip-access-network-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: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-mills-sip-access-network-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. > > ------------------------------------------------------------------------ > > Subject: > Date: Wed, 29 May 2002 10:32:52 -0400 > > ------------------------------------------------------------------------ > > ATT38948.txtName: ATT38948.txt > Type: Plain Text (text/plain) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed May 29 18:32:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05792 for ; Wed, 29 May 2002 18:32:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23487 for sip-archive@odin.ietf.org; Wed, 29 May 2002 18:32:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22030; Wed, 29 May 2002 18:11:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22003 for ; Wed, 29 May 2002 18:11:05 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05374 for ; Wed, 29 May 2002 18:10:42 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g4TMAsX82466; Wed, 29 May 2002 17:10:54 -0500 (CDT) Message-ID: <3CF551D1.6080100@dynamicsoft.com> Date: Wed, 29 May 2002 17:10:25 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" , sip Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Some comments. My mail reader didn't want to cooperate on quotes--the text between "" is from the draft. Most of these are really nits "Note that there is a fine line between identity fraud and humor in some cases. Many email clients by default render to the user only the display-name of the sender of a message. It is easy to populate the display-name in a way that many would consider abusive; it is best not to select any display-name that may suggest an attempt to impersonate someone else." This section sounds like something that belongs in a bcp, not in a draft that I assume is intended to become a normative RFC. "From the former [sip:jon.peterson@neustar.biz], the full name and employer of the party in question can easily be gleaned. From the latter, you learn nothing other than that the party desires anonymity. In some cases, sufficient anonymity can be achieved by selecting an oblique URI. Today, the SIP specification recommends a URI with "anonymous" in the user portion of the From header." Hmm, I fear someone might read this and believe too much, that is, that they could really know the identity of the sender from a URL in a From header. For example, _I_ could use that URL. If you glean something from it, you would glean wrong. (Perhaps s/glean/guess would be sufficient here.) "For these reasons, the hostname value 'anonymous.invalid' SHOULD be used for anonymous URIs. The full recommended form of the From header for anonymity is (note that this From header, like all others, MUST contain a valid and unique 'tag=' parameter): " Does this require reserving anonymous.invalid to never resolve to something real? How would you enforce that? (Maybe a new TLD for "invalid" :-) ) "If the 'critical' privacy level is present in the Privacy header of a request, then if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header then it MUST either fail the request, or it MUST forward the request to another privacy service which can fulfill these functions (note that before forwarding the request, the privacy service SHOULD complete a subset of the functions if it can). " This one scares me a little. It implies that, even if I have gone to a great deal of trouble to directly talk to a privacy service (perhaps over TLS) and specify "critical", it can still forward the request without having performed privacy services. Doesn't this brings up the whole transitity of trust and trust boundery issue that we keep getting bogged down on? "Firstly, a request for header privacy entails that the server SHOULD NOT add any of the following headers to the message: Call-Info, Server, and Organization. All of these provide optional information that could reveal facts about the user that has request anonymity. " I would be happier if the situations that would allow the server to insert one of those headers were enumerated. More of a "MUST NOT unless" form. I tend to think it should be "MUST NOT unless it is impossible to fulfill the SIP request without doing so." "Privacy services would be wise to authenticate users before providing a privacy function. To downstream entities, the privacy service will be the only responsible party to whom anonymous messages can be traced, and in abuse cases the privacy service could be held accountable for the actions of parties that it shelters. " I'm not sure I agree with this. In some cases, _not_ authenticating might be the only defence against sopoena(sp?). This paragraph falls into the area of legal advice that should be given by lawers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 29 21:14:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09747 for ; Wed, 29 May 2002 21:14:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03771 for sip-archive@odin.ietf.org; Wed, 29 May 2002 21:15:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01227; Wed, 29 May 2002 20:55:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01161 for ; Wed, 29 May 2002 20:54:56 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09158; Wed, 29 May 2002 20:54:30 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4U0sQ423048; Wed, 29 May 2002 19:54:26 -0500 From: "Dean Willis" To: , , Date: Wed, 29 May 2002 19:53:40 -0500 Message-ID: <002201c20774$70d3ba80$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Draft-willis-sip-path revised to -08 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bernie and I just released what we hope is the REALLY final version of the Path draft. This includes all feedback (mostly nits) so far from IETF Last Call. For example, I spelled out "Session Initiation Protocol" in the title. Material available from: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-08.html http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-08.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-08.xml And will be available from internet-drafts shortly, I expect. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed May 29 21:18:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09808 for ; Wed, 29 May 2002 21:18:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04025 for sip-archive@odin.ietf.org; Wed, 29 May 2002 21:19:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01219; Wed, 29 May 2002 20:55:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01156 for ; Wed, 29 May 2002 20:54:56 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09157; Wed, 29 May 2002 20:54:30 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4U0sQ423049; Wed, 29 May 2002 19:54:26 -0500 From: "Dean Willis" To: , Date: Wed, 29 May 2002 19:53:40 -0500 Message-ID: <002101c20774$70d0ad40$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-willis-sip-scvrtdisco revised to -06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bernie and I just released what we hope is the final version of the Service Route Discovery draft. This version fixes some syntax errors in the examples. I also cleaned up the grammar slightly. New stuff at: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.htm l http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.xml -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 30 00:53:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13984 for ; Thu, 30 May 2002 00:53:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15532 for sip-archive@odin.ietf.org; Thu, 30 May 2002 00:54:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14089; Thu, 30 May 2002 00:28:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14062 for ; Thu, 30 May 2002 00:28:04 -0400 (EDT) Received: from rautu.eng.song.fi (mail@p8-vanraj-ra12.teliafi.net [195.10.137.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13398 for ; Thu, 30 May 2002 00:27:34 -0400 (EDT) Received: from jh by rautu.eng.song.fi with local (Exim 3.12 #1 (Debian)) id 17DBGe-00007i-00; Thu, 30 May 2002 00:46:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15605.19484.700710.415050@rautu.eng.song.fi> Date: Thu, 30 May 2002 00:46:04 +0300 To: "Peterson, Jon" Cc: Cullen Jennings , sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 In-Reply-To: <70565611B164D511957A001083FCDD5601870375@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD5601870375@va02.va.neustar.com> X-Mailer: VM 7.00 under Emacs 21.1.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > "Hint", for whatever reason, is the term that has stuck throughout this > discussion. There are meaningful cases in which a network would elect to use > some identity other than that hinted by the user, so I don't feel this term > is entirely inappropriate. looks like my values differ from yours. i as a service provider have to respects the user's wish. if there is many, i simply can't pick an identity for a user on my own. also, if the users wish conflicts with his subscription, i must clear the call. > There is a concept, though one that is not discussed extensively in the > draft, that a user authenticates themselves in some fashion to the network. > The Spec(T) example in the draft suggests SIP Digest authentication, if I > recall. The P-Asserted-Identity could be populated based on an identity > expressed in that authentication process, rather than a From header, in the > absence of a hint (although admittedly in some networks the authentication > will not supply a usable identity as such). This applies equally to cases in > which the user has supplied an anonymous From header. This would seem to > provide a credible alternative to the MUST that you suggest below, one that > I see no reason to rule out. that doesn't work if the user has multiple sip identities. > The short-term identity work puts the network, not the user, firmly in the > driver's seat. sounds a very bellhead approach to me. if the user claims to be someone that conflicts with the idea of the network regarding who the user should be, then the network should not make things up, but deny the request. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 07:51:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00015 for ; Thu, 30 May 2002 07:51:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18695 for sip-archive@odin.ietf.org; Thu, 30 May 2002 07:52:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17189; Thu, 30 May 2002 07:27:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17089 for ; Thu, 30 May 2002 07:27:41 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29274; Thu, 30 May 2002 07:27:14 -0400 (EDT) Message-Id: <200205301127.HAA29274@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 30 May 2002 07:27:13 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-called-party-id-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol extension for Called Party Identity Author(s) : M. Garcia Filename : draft-garcia-sip-called-party-id-02.txt Pages : 8 Date : 29-May-02 This memo describes a private extension to SIP in the form of a P-Called-Party-ID header. A proxy inserts this header typically in an INVITE, en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which ID out of several IDs the invitation was sent to (for example, the user may be using simultaneously a personal and a business SIP URI to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the ID used to receive the invitation to the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-called-party-id-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-garcia-sip-called-party-id-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-called-party-id-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020529140408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-called-party-id-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-called-party-id-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020529140408.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 07:52:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00062 for ; Thu, 30 May 2002 07:52:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18775 for sip-archive@odin.ietf.org; Thu, 30 May 2002 07:53:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17241; Thu, 30 May 2002 07:27:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17205 for ; Thu, 30 May 2002 07:27:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29292; Thu, 30 May 2002 07:27:20 -0400 (EDT) Message-Id: <200205301127.HAA29292@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 30 May 2002 07:27:20 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-visited-network-id-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol extension for Visited Network Identifier Author(s) : M. Garcia Filename : draft-garcia-sip-visited-network-id-02.txt Pages : 7 Date : 29-May-02 This memo describes a private extension to SIP in the form of a P-Visited-Network-ID header. The contents of the header identify each of the visited networks the message traversed en-route to the home network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-visited-network-id-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-garcia-sip-visited-network-id-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-visited-network-id-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020529140417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-visited-network-id-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-visited-network-id-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020529140417.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 08:45:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01832 for ; Thu, 30 May 2002 08:45:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23919 for sip-archive@odin.ietf.org; Thu, 30 May 2002 08:46:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21991; Thu, 30 May 2002 08:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21963 for ; Thu, 30 May 2002 08:27:24 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01264 for ; Thu, 30 May 2002 08:26:56 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GWX00101BWCEU@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 May 2002 13:26:36 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GWX00NLCBWC2I@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 May 2002 13:26:36 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 13:26:51 +0100 Content-return: allowed Date: Thu, 30 May 2002 13:26:25 +0100 From: "Elwell, John" Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general To: "'sip'" Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BC@Beex50.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT "When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the corresponding priv-value from the Privacy header - otherwise, any other privacy service involved with routing this message might unnecessarily apply the same function, which in many cases would be undesirable." This seems to be in contradiction with draft-ietf-sip-asserted-identity, which show "Privacy: id" being maintained with the forwarded INVITE. "When the last priv-value (not counting 'critical') has been removed from the Privacy header, the entire Privacy header MUST be removed from a message." Is this wise in the case of "None"? -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: 28 May 2002 22:32 > To: 'sip' > Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; Jon > Peterson (jon.peterson@NeuStar.com) > Subject: [Sip] WGLC for draft-ietf-sip-privacy-general > > > > We need to do a quick review of the general privacy draft > developed out > of our discussion in Las Vegas. > > Please send any issues to the list and the editor IMMEDIATELY. > > The draft is available from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g > eneral-00. > html > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g eneral-00. txt And soon to be available from internet-drafts if not already . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 08:57:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02237 for ; Thu, 30 May 2002 08:57:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24717 for sip-archive@odin.ietf.org; Thu, 30 May 2002 08:57:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22674; Thu, 30 May 2002 08:32:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22647 for ; Thu, 30 May 2002 08:32:10 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01424 for ; Thu, 30 May 2002 08:31:43 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GWX00101C4BN5@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 May 2002 13:31:23 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GWX00NPXC4B2I@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 May 2002 13:31:23 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 13:31:38 +0100 Content-return: allowed Date: Thu, 30 May 2002 13:31:13 +0100 From: "Elwell, John" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity To: "'sip'" Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BD@Beex50.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Section 5, 3rd paragraph: "The proxy MAY add a P-Asserted-Identity header field with either a single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a P-Asserted-Identity header field with a single tel URL." This seems to imply that a proxy can add a header even if there is already a header of the type concerned. Presumably this should not be allowed. -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28 May 2002 22:32 > To: 'sip' > Cc: brian.rosen@marconi.com; rohan@cisco.com; jo@ipdialog.com; 'Cullen > Jennings' > Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > We need to do a quick working group last call on the > "Asserted Identity" > draft. > > Please submit comments to the list and draft editor IMMEDIATELY. > > Draft available from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted- identity-0 0.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0 0.txt And soon to be in the internet-drafts archive. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 09:39:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04253 for ; Thu, 30 May 2002 09:39:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29259 for sip-archive@odin.ietf.org; Thu, 30 May 2002 09:40:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26975; Thu, 30 May 2002 09:16:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28560 for ; Wed, 29 May 2002 20:21:57 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08369 for ; Wed, 29 May 2002 20:21:32 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4U0LQS28586 for ; Wed, 29 May 2002 20:21:27 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 19:21:26 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02B3F23E@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: Jonathan Rosenberg , Dean Willis Cc: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, ehenrikson@lucent.com, "Drage, Keith (Keith)" Subject: RE: [Sip] Poll: expert review of draft-henrikson-sip-charging-in formation Date: Wed, 29 May 2002 19:21:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, Thank you for the comments. I am open to any alternative that solves the problem of correlating the dialogs at the S-CSCF. Please confirm that I am understanding your proposal correctly. The problem we are trying to solve only pertains to the case of a B2BUA type of application server for 3GPP. If an INVITE is sent from a S-CSCF to a B2BUA, which then sends a new INVITE back to the S-CSCF, I don't see how using just the Route information can be used to correlate the new INVITE with the old INVITE. Each INVITE may have different To tag, From tag and Call-ID. The (plain) Route header in the new INVITE may be common with dozens of other INVITEs that have followed this same path. I find the following definition for Route: Route = "Route" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param ) rr-param = generic-param Are you suggesting that there is some parameter placed in the 2nd Route header element inserted by the S-CSCF that it uses for the correlation? If so, then is it ok to use a 3GPP specific parameter defined within 3GPP specifications (rr-param)? If that is what is meant, then I can see where the S-CSCF could define a unique value to send with the 2nd Route header, e.g. ";correlate=2349873453", and we could require that 3GPP compliant B2BUA Application Servers return 2nd Route header as the topmost Route header to the S-CSCF . Eric Henrikson p.s. I presume you are referring to the P-Original-Dialog-ID draft and not the charging information draft. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, May 29, 2002 1:04 PM To: Dean Willis Cc: sip@ietf.org; rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; ehenrikson@lucent.com Subject: Re: [Sip] Poll: expert review of draft-henrikson-sip-charging-information First off, I have to apologize for the lateness of these comments. Given the scope of my comments, I should have raised them earlier. I have some serious concerns about this draft. Most notably, I disagree entirely with the assessment that the problem isn't entirely solved by loose routing. When the S-CSCF sends a request to an application server, it ought to be inserting two loose routes - one that points to the AS, and another that points back to itself, containing whatever context is needed for the S-CSCF to do what it needs to do from that point forward. The draft makes the following statement: > One may consider using the Route header as a mechanism to get the > request sent back to the S-CSCF. However, Route headers don't > automatically transit an AS acting as a B2BUA. This could be > overcome by using loose-routing and application logic in the B2BUA. > But that is not the full problem to be solved. A strong correlation > of dialogs is also needed for accounting purposes to treat the > sequence of dialogs as a concatenated single dialog. A common > identification tag needs to be carried in each related dialog so > that the charging functions can associate all the dialogs. A smart B2BUA will not discard loose routes, particularly not one thats used in 3gpp for this reason exactly. Thus, the principal motivation given, being able to corelate incoming INVITEs from outgoing ones in a spiral - is not correct. We explicitly designed the loose routing stuff to enable exactly this kind of function (remember the Bjorkner service route draft?). The other argument that is given here - correlation of dialogs for accounting purposes - makes no sense to me. The route header provides the ability for the S-CSCF to completely correlate the incoming INVITE to the one it sent out. It therefore has all the information it needs to account for the calls and to know which applications are invoked. The last thing I want to do is specify two ways of doing the same thing. Given that this kind of correlation is square in the sights of loose routing, I am concerned about the overlap. -Jonathan R. Dean Willis wrote: > > You may recall that we're doing an Expert Review of > draft-henrikson-sip-charging-information. > > If you have a strong opinion for, against, or supporting a need for > further work, or any further suggestions for enhancement, please post > them now. > > -- > Dean Willis > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 10:26:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06763 for ; Thu, 30 May 2002 10:26:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03744 for sip-archive@odin.ietf.org; Thu, 30 May 2002 10:27:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00527; Thu, 30 May 2002 09:52:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00477 for ; Thu, 30 May 2002 09:52:44 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05003 for ; Thu, 30 May 2002 09:52:19 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA19187; Thu, 30 May 2002 14:51:55 +0100 (BST) Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Thu, 30 May 2002 14:51:47 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 30 May 2002 14:51:46 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 14:51:45 +0100 Message-Id: To: akristensen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] draft-mills-sip-access-network-info-02.txt grammer Date: Thu, 30 May 2002 14:51:40 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Anders, Yes, that was the intention. I believe there is sufficient room for future expansion (should we need it) with the 'extension-access-info' field. Duncan -----Original Message----- From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] Sent: 29 May 2002 20:05 To: SIP Subject: [Sip] draft-mills-sip-access-network-info-02.txt grammer Nit: the grammar seems to allow only one access-info parameter per P-Access-Network-Info header. Is that intentional? Anders _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 10:30:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06894 for ; Thu, 30 May 2002 10:30:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04095 for sip-archive@odin.ietf.org; Thu, 30 May 2002 10:30:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00934; Thu, 30 May 2002 09:57:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00902 for ; Thu, 30 May 2002 09:57:33 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05232 for ; Thu, 30 May 2002 09:57:09 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4UDunuF010039; Thu, 30 May 2002 06:56:49 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADA52282; Thu, 30 May 2002 06:57:11 -0700 (PDT) From: "Cullen Jennings" To: "Juha Heinanen" , "Peterson, Jon" Cc: "Cullen Jennings" , Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 Date: Thu, 30 May 2002 07:02:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <15605.19484.700710.415050@rautu.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Would you feel better about this hint stuff if we put in that Spec(T) must specify how the situation is handled when a node receiving a hint which is not going to be honored. So Spec(T) would need to say that if you got a hint and you were actually going to use a different AI in the trust domain, then you must do one of a) just do it and not tell the user b) return an error to the user c) unspecified. I see difficulties in really deploying and this - at the UAC, it might be hard to know AI the trust domain will use for UA - presumably I would need to get it exactly right on the UA - if it is using both a sip and tel url do I have to include both of them? I feel there is a header where the UA gets to assert who it wants to be known as - it's the From header. There is another header where the network gets to assert information about who it thinks the user is - this is the Asserted-Identity header. There is a header where the user gets to control the scope of how widely this network information is distributed - that is the Privacy header. Cullen -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Juha Heinanen Sent: Wednesday, May 29, 2002 2:46 PM To: Peterson, Jon Cc: Cullen Jennings; sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 Peterson, Jon writes: > "Hint", for whatever reason, is the term that has stuck throughout this > discussion. There are meaningful cases in which a network would elect to use > some identity other than that hinted by the user, so I don't feel this term > is entirely inappropriate. looks like my values differ from yours. i as a service provider have to respects the user's wish. if there is many, i simply can't pick an identity for a user on my own. also, if the users wish conflicts with his subscription, i must clear the call. > There is a concept, though one that is not discussed extensively in the > draft, that a user authenticates themselves in some fashion to the network. > The Spec(T) example in the draft suggests SIP Digest authentication, if I > recall. The P-Asserted-Identity could be populated based on an identity > expressed in that authentication process, rather than a From header, in the > absence of a hint (although admittedly in some networks the authentication > will not supply a usable identity as such). This applies equally to cases in > which the user has supplied an anonymous From header. This would seem to > provide a credible alternative to the MUST that you suggest below, one that > I see no reason to rule out. that doesn't work if the user has multiple sip identities. > The short-term identity work puts the network, not the user, firmly in the > driver's seat. sounds a very bellhead approach to me. if the user claims to be someone that conflicts with the idea of the network regarding who the user should be, then the network should not make things up, but deny the request. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 12:41:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12460 for ; Thu, 30 May 2002 12:41:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19143 for sip-archive@odin.ietf.org; Thu, 30 May 2002 12:42:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17300; Thu, 30 May 2002 12:19:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17272 for ; Thu, 30 May 2002 12:19:55 -0400 (EDT) Received: from rautu.eng.song.fi (mail@dial-01-14.community.co.uk [195.72.167.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11510 for ; Thu, 30 May 2002 12:19:27 -0400 (EDT) Received: from jh by rautu.eng.song.fi with local (Exim 3.12 #1 (Debian)) id 17DB5L-00007Q-00; Thu, 30 May 2002 00:34:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15605.18783.943848.879871@rautu.eng.song.fi> Date: Thu, 30 May 2002 00:34:23 +0300 To: Rohan Mahy Cc: sip@ietf.org Subject: [Sip] P- headers vs. requirements in sip change process In-Reply-To: References: X-Mailer: VM 7.00 under Emacs 21.1.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy writes: > 3. No overlap with planned/chartered extensions > 4. Purely informational in nature with regards to nai, i don't think the above two apply, since there is clearly a generic need to augment sip with a nai style header when the user has included anonymous from uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 13:05:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13251 for ; Thu, 30 May 2002 13:05:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20741 for sip-archive@odin.ietf.org; Thu, 30 May 2002 13:05:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18987; Thu, 30 May 2002 12:39:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18957 for ; Thu, 30 May 2002 12:39:56 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12388 for ; Thu, 30 May 2002 12:39:30 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4UGdPHs015971; Thu, 30 May 2002 09:39:25 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADA55849; Thu, 30 May 2002 09:39:35 -0700 (PDT) From: "Cullen Jennings" To: "Elwell, John" , Cc: "Fluffy" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity Date: Thu, 30 May 2002 09:44:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BD@Beex50.siemenscomms.co.uk> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes, it should not be allowed. There can be at most one AI with a sip or sips header and at most one AI with a tel. I agree the language is loose. Any suggestion on what I should change this paragraph too? What about: "The proxy MAY add a P-Asserted-Identity header field with either a single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a P-Asserted-Identity header field with a single tel URL. There can not be more that one of each of these so if there are existing P-Asserted-Identity headers, they must be replaced." I don't really like this either but it was the best I could do in 30 seconds - suggestions? Thanks, Cullen -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Elwell, John Sent: Thursday, May 30, 2002 5:31 AM To: 'sip' Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity Section 5, 3rd paragraph: "The proxy MAY add a P-Asserted-Identity header field with either a single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a P-Asserted-Identity header field with a single tel URL." This seems to imply that a proxy can add a header even if there is already a header of the type concerned. Presumably this should not be allowed. -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28 May 2002 22:32 > To: 'sip' > Cc: brian.rosen@marconi.com; rohan@cisco.com; jo@ipdialog.com; 'Cullen > Jennings' > Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > We need to do a quick working group last call on the > "Asserted Identity" > draft. > > Please submit comments to the list and draft editor IMMEDIATELY. > > Draft available from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted- identity-0 0.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0 0.txt And soon to be in the internet-drafts archive. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 14:11:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15958 for ; Thu, 30 May 2002 14:11:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25821 for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:12:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23545; Thu, 30 May 2002 13:38:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23514 for ; Thu, 30 May 2002 13:38:35 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14593 for ; Thu, 30 May 2002 13:38:08 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4UHbvI01297; Thu, 30 May 2002 12:37:57 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 12:37:52 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870381@va02.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general Date: Thu, 30 May 2002 12:37:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for these extensive notes - the draft definitely needed a solid reading. Most of these edits I'll accept as you've suggested; a few notes below on interesting or controversial issues. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, May 29, 2002 12:29 PM > To: Dean Willis > Cc: 'sip'; rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; > Jon Peterson (jon.peterson@NeuStar.com) > Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general > > > Comments: > > > Withholding the identity of a user will, among other > > things, render the other parties in the dialog unable to send new SIP > > requests to the user outside of the context of the current dialog. > > Thats not necessarily true; I can remain anonymous and even get a call > back later on (for example, Reply-To: sip:user8222739@anonymous.net) - > the key is that my identity is never revealed. > I think anonymous callback is distinct from privacy as it is defined here. Apparently, sip:userXYZ@anonymous.net is an address at which you can reached - even though it is a relatively opaque piece of data, I would still consider it in this definition a form of identity, one best suited to something like anonymous callback. The term 'personal information' is sometimes used in this draft to refer to something other than 'identity' - the identity sip:userXYZ@anonymous.net reveals no personal information. Perhaps this is a distinction that could be drawn out a bit more. [snip] > > > The scope of these privacy requirements is solely the SIP protocol as > > it is described in [1]. The mechanisms at the disposal of user > > agents and proxy servers are restricted to those described in the SIP > > specification. Also, the privacy properties of the headers listed in > > the core SIP specification alone, as opposed to headers defined by > > any existing or planned extension, are considered here. > > I don't quite understand this paragraph. If a future extension defines a > header that reveals identity information, shouldn't this draft cover > requests for privacy of that information? > I'll rephrase that a bit. My point was just that I don't happen to reference and detail any existing SIP extensions in this draft. Obviously the draft has its own extensibility mechanism to accomodate future extensions, and even some recommendations for authors of extensions to SIP. [snip] > > > The following SIP headers, when generated by a user agent, can > > directly or indirectly reveal identity information about the > > originator of a message: From, Contact, Reply-To, Via, Call-Info, > > User-Agent, Organization, Subject, Call-ID, In-Reply-To > [snip] > Also, you have forgotten two very, very important ones - Authorization > and Proxy-Authorization. In general, I think the draft needs discussion > of these headers specifically. The user should only include such headers > if it is willing to provide identity information for the realm provided > in the challenge. Furthermore, the user may need to verify that the > proxy is indeed part of the realm that they claim to be from before the > user provides identity information to it. Right now, we have no real way > to do that unless the proxy is the first hop proxy, in which case TLS > can be used to ascertain the identity of the proxy that is providing the > challenge before providing credentials. All of this needs to be > discussed. The issue is similar to that of routing requests to privacy > services. > Some effort has been made in the recent privacy/identity work to split privacy and identity concepts into separate drafts. The practices you describe for providing identity information to a server that issues challenges, I think, belong in the identity drafts, not here (there is some text exactly to this effect in the second section of my longterm identity draft, actually). For the most part, we've also tried to put concerns related to authentication into the identity drafts, both of which normatively depend on the privacy draft. I really don't want to duplicate language and so forth, so I hope that the language in the Sec Cons of the privacy draft is really all we need here. There are, after all, other forms of authentication than SIP Digest, which have parallel concerns, and I don't think we should open that can of worms in the privacy draft. > > > Header field where proxy ACK BYE CAN INV OPT REG > > ___________________________________________________________ > > Privacy amrd o o o o o - > > I think privacy is still useful in a register message. It would be > helpful when I want to register through my provider using an anonymizer > service, which possibly obfuscates the Contact header. Interestingly, > the privacy service couldn't obfuscate the From or To field, since these > are needed by the registrar. Perhaps that is why Privacy is not allowed > here? It makes me wonder if there is a need to specify privacy on a > slighlty more granular level, allowing the user to request obfuscation > of groups of headers (To/From in one group, Contact/Via/RR in > another). > Yes, the To/From implication combined with obscuring of the Contact(s) is one reason why Privacy isn't allowed here. Note that the levels of granularity you suggest are already in the draft, I think, since the procedures for 'header' level privacy (6.1) entail the obfuscation of Contact/Via/RR, whereas only 'user' level privacy conceals the To/From. So actually, I think it would be possible to only obscure contacts. I guess this extension just isn't designed to keep identity information private from registrars - the utility of that remains obscure to me after some reflection on the matter. This is partly a question of when the privacy service should be closer to the user (presumably one hop away) than a registrar, when it should be farther away, and when the privacy service and registrar should be colocated. Registering an anonymous Contact could be meaningful when your privacy service is closer to you than your register. If the two are conflated, or the registrar is closer than your privacy service, there probably wouldn't be any need to register an anonymous Contact. Although the draft mandates no architecture, I think it leans towards this second scenario for providing privacy when you are the called party. Given all that, though, I agree that this restriction can be removed - there's no reason to forbid registering a Contact through a privacy service that will provide privacy for these Contact addresses (granted that what appears in the Contact after it passes through a privacy service is an 'anonymous callback' sort of contact address, rather than an unroutable URI that expresses anonymity). > > critical: The user asserts that the privacy services requested for > > this message are critical, and that therefore, if these privacy > > services cannot be provided by the network, this request should be > > rejected. Criticality cannot be managed appropriately for > > responses. > > OK, I hate to dredge up old issues, and perhaps this was hashed out in > the many privacy threads I didn't get to, but, it seems like the value > of critical is going to neccessitate a Proxy-Require header. The draft > makes no mention of the use of proxy-require or the protocol > implications if the extension is not supported by proxies. The > proxy-require can be removed once the services have been performed, > which is a good thing. > Proxy-Require would also make it difficult to have a privacy service reside more than one hop away from a client. But agreed that criticality is severely hampered without something along these lines. This had been discussed briefly (off the list, I think), but I don't think the discussion ever arrived at any conclusion. Throughout the draft the assumption is made that the user is aware of a distinct privacy service in the network, with which they have some sort of relationship, through which calls will be routed. Arguably, without that relationship a privacy service is of no value (that is, not just any privacy service will do - it must be one that is specifically known to the user for reasons of accountability). In that sense, the draft makes the (possibly dangerous) assumption that no in-band feature negotiation is necessary - the user knows out-of-band that that the server in question supports privacy. Would be a pity if they were wrong. As we've discussed before, this taps somewhat into the whole service discovery/composition problem, one that we know isn't going to be resolved in the scope of this draft, anyway. > > It is RECOMMENDED that service providers couple the privacy service > > function with a local outbound proxy. Users can thereby send their > > messages that request privacy through their usual outbound route. > > Users should not assume, however, that the administrative domain that > > is the destination of the request would be willing and able to > > perform the privacy service function on their behalf. > > How does the user know whether privacy services are supported? Do they > need to try it with Proxy-Require to see if the request fails? > The text above is meant to suggest that users should know out-of-band that their local administrative domain supports a privacy service function. [snip] > > > What a responding user agent can do, however, is ensure that the path > > by which requests reach them traverses their privacy service. In > > some architectures, the privacy service function will be fulfilled by > > the same server to which requests for the local administrative domain > > are sent, and hence it will automatically be in the path of incoming > > requests. However, if this is not the case, the user will have to > > ensure that requests are directed through a third-party privacy > > service. The simplest way to accomplish this is to procure a > > 'private' URI from the third-party service and to distribute this as > > an address-of-record. The user would then register their normal > > address-of-record as a contact address with the third-party service. > > Based on this, the third party privacy service would see the request > before their actual provider. I can imagine there are also cases where > the opposite makes more sense - the user registers their anonymous AOR > as a contact address with their actual provider. TO me, this makes more > sense. You want the privacy function closest to the user; in the case of > responses, that means that you want it to be the first element that gets > the response, which would motivate registering the anonymous AOR as a > contact with the actual provider. I think both approaches probably have their place. The approach I detail above is more of a sort of anonymous callback' service; a user could distribute a 'private' URI in the From field of requests they send. In this case the privacy service effectively becomes the registrar of the user. > > This also raises the question of whether a privacy service is a "hop" > described by a URI in a route header, or is an identity, which would > appear in the request URI and be translated. Clearly, the assumption > above is the latter. Thats going to be true for some privacy services, > but for things like session privacy, I would argue that these are hops, > and they are ideally reached with URIs in route headers, not the > request-URI. > I think you are exposing that latent distinction in the draft between an 'anonymous callback' identity and a privacy service that acts on normal identityies - that there are actually a couple of ways that a request could potentially reach a privacy service. Pre-loaded routes are the most common way, but anonymous callback identities are another way to reach a privacy service. Again, agreed that this distinction should be formalized a bit. > I don't understand why section 5 is a separate section. Since its about > construct anonymous messages, it seems like it is naturally a subsection > of 4.1. This relates to my meta-comment about the verbosity of the > draft; it reads a bit too much like a dialog, and not quite enough like > a protocol specification. Section 5 is really describing normative > behavior for user agents, and belongs in the section which describes > that. > I suppose I felt that URI creation actually wasn't the exclusive responsibility of user agents - privacy services also have some responsibility for creating anonymous URIs. I really don't feel that strongly about how the sections are arrayed. Specmanship is a much more difficult art than protocol design. I think there needs to be a prosody RFC, a Strunk & White of the IETF, so slow learners like myself can get up to speed a little quicker. > > This document defines a new SIP logical role called a "privacy > > service". The privacy service role is instantiated by a network > > intermediary, frequently by entities that can act as SIP proxy > > servers. The function of a privacy service is to supply privacy > > functions for SIP messages that cannot be provided by user agents > > themselves. > > I think its worth noting that privacy services are described by URIs > (see above comments on whether they are hop URIs or destination URIs) > > > However, if the Privacy header value of > > 'none' is specified in a message, privacy services MUST NOT perform > > any privacy function. > > I have a feeling that the MUST NOT strength is going to be a problem for > these folks that claim they have a regulatory requirement to provide > privacy even when the user doesn't want it (or at least, I recall that > this was the claim). > I hope the existing wording will be sufficient - my conversations with some of the parties raising these regulatory concerns have suggested that networks are required to implement the user's preferences (that tends to be the motivating government requirement). The trick is, there needs to be a way for those preferences to be specified implicitly and administratively, not just explicitly and in-band. We do provide a way to do that in the draft. > > When a privacy service performs one of the functions corresponding to > > a privacy level listed in the Privacy header, it SHOULD remove the > > corresponding priv-value from the Privacy header - otherwise, any > > other privacy service involved with routing this message might > > unnecessarily apply the same function, which in many cases would be > > undesirable. When the last priv-value (not counting 'critical') has > > been removed from the Privacy header, the entire Privacy header MUST > > be removed from a message. > > I am concerned about the complete removal of the privacy header. THe > problem is that downstream elements may insert additional identification > information into the request. I would propose that a new value for the > header be defined, say "no-add", which tells elements that they don't > need to modify any headers, but that they should not add any further > identification information to a request. If the header value was present > in a request, and is then performed by a proxy, the proxy changes that > value to no-add. > Agreed that parties downstream might add further information to the request - but these entities might not even support the Privacy extension at all. I'm not sure what we can really do to guard against this contingency. Maybe this doesn't really come through in the text today (something I should fix), but I've been envisioning that users should try not to route the request through intermediaries that are likely to add personal information subsequent to the privacy service (by choosing appropriate preloaded Route header orders, perhaps). This argues a bit on the 'closeness' issue for keeping your privacy service far away from you. > > When a privacy service alters the Contact header of a > > request, it MUST insert a Record-Route header pointing to itself so > > that it can restore the appropriate contact address as necessary. > > Thats not true. The Contact header will presumably route to itself, so > that an additional record-route is not necessary. > That would work too, and is probably more efficient - I was envisioning that the privacy service would add a Contact header with an anonymous URI (i.e. one using the 'anonymous.invalid' hostname), and that therefore Record-Routing was necessary to get the request back to the privacy service. Of course if the Contact indicates the privacy service, that is sufficient. I note that this makes the anonymous Contact registration story make a bit more sense. > > In a manner similar to Via hiding, a privacy service SHOULD also hide > > any Record-Route headers that have been added to a request before it > > reaches the privacy service. Such Record-Route headers might also > > divulge information about the administrative domain of the client. > > Once Record-Route headers have been hidden, however, the privacy > > service MUST add appropriate Route headers to future requests as > > needed. > > Given how easy it is to get this wrong, I would avise putting a bit more > text in there about properly constructing the route and record-routes. > Agreed, it's potentially pretty complicated. My text above does ring a bit of "magic happens". > > > Therefore, any time that a privacy service needs to modify any > > dialog-matching headers for privacy reasons, it SHOULD act as a > > transparent back-to-back user agent > > This was discussed on the list; the term transparent B2BUA is not > defined in bis or in this document. You need to be more exact in your > definitions. I'd hate to be defining that common term in this document... but, agreed, this section should be more explicit about the exact behavior required. > > IANA Considerations > > [snip] > By the way, do we want to define a compact form? Um... I don't know, really. Any other opinions about that? > > THanks, > Jonathan R. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 14:18:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16181 for ; Thu, 30 May 2002 14:18:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25988 for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:17:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24191; Thu, 30 May 2002 13:51:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24159 for ; Thu, 30 May 2002 13:51:05 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15147 for ; Thu, 30 May 2002 13:50:39 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4UHoSc27425; Thu, 30 May 2002 13:50:28 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 12:50:23 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870382@va02.va.neustar.com> From: "Peterson, Jon" To: "'Ben Campbell'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general Date: Thu, 30 May 2002 12:50:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the comments, Ben. We need 'em. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, May 29, 2002 3:10 PM > To: Peterson, Jon; sip > Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general > > > Some comments. My mail reader didn't want to cooperate on quotes--the > text between "" is from the draft. > > Most of these are really nits > > > "Note that there is a fine line between identity fraud and humor in some > cases. Many email clients by default render to the user only the > display-name of the sender of a message. It is easy to populate the > display-name in a way that many would consider abusive; it is best not > to select any display-name that may suggest an attempt to impersonate > someone else." > > This section sounds like something that belongs in a bcp, not in a draft > that I assume is intended to become a normative RFC. How about we move it to the Sec Cons - as far as I can make it, the Sec Cons is a ghetto for well-meaning non-normative statements along these lines. > > "From the former [sip:jon.peterson@neustar.biz], the full name and > employer of the party in question can easily be gleaned. From the > latter, you learn nothing other than that the party desires anonymity. > In some cases, sufficient anonymity can be achieved by selecting an > oblique URI. Today, the SIP specification recommends a URI with > "anonymous" in the user portion of the From header." > > Hmm, I fear someone might read this and believe too much, that is, that > they could really know the identity of the sender from a URL in a From > header. For example, _I_ could use that URL. If you glean something from > it, you would glean wrong. (Perhaps s/glean/guess would be > sufficient here.) I can s/glean/guess. > > "For these reasons, the hostname value 'anonymous.invalid' SHOULD be > used for anonymous URIs. The full recommended form of the From header > for anonymity is (note that this From header, like all others, MUST > contain a valid and unique 'tag=' parameter): " > > Does this require reserving anonymous.invalid to never resolve to > something real? How would you enforce that? (Maybe a new TLD for > "invalid" :-) ) Fortunately, RFC2606 beat us to it. Perhaps I should list this as a reference. > > "If the 'critical' privacy level is present in the Privacy header of a > request, then if the privacy service is incapable of performing all of > the levels of privacy specified in the Privacy header then it MUST > either fail the request, or it MUST forward the request to another > privacy service which can fulfill these functions (note that before > forwarding the request, the privacy service SHOULD complete a subset of > the functions if it can). " > > This one scares me a little. It implies that, even if I have gone to a > great deal of trouble to directly talk to a privacy service (perhaps > over TLS) and specify "critical", it can still forward the request > without having performed privacy services. Doesn't this brings up the > whole transitity of trust and trust boundery issue that we keep getting > bogged down on? I can see why this language would make you a little nervous. I think there are perhaps a couple of good reasons to allow communities of privacy services that can forward requests among one another (wiser authors in the future might design onion routing schemes for SIP requests, or something). Agreed there are some transitivity issues here - it is absolutely critical that the user is related to the service that performs the privacy function. Then again, if their privacy server has already performed some privacy functions before forwarding the request (say, 'header' privacy), then a second privacy service that performs additional functions ('session', say) might not be in a position to even identity the originating user. There are cases where this is useful, I think. I'm sensitive to your concerns, and I think they merit some language, but I'm not sure what to add. > > "Firstly, a request for header privacy entails that the server SHOULD > NOT add any of the following headers to the message: Call-Info, Server, > and Organization. All of these provide optional information that could > reveal facts about the user that has request anonymity. " > > I would be happier if the situations that would allow the server to > insert one of those headers were enumerated. More of a "MUST NOT unless" > form. I tend to think it should be "MUST NOT unless it is impossible to > fulfill the SIP request without doing so." > Are there any conditions in which the fulfillment of a request is predicated on the population of any of those three headers? Maybe this is also related to criticality - if a server must populate those headers, but cannot because of a critical privacy condition, then it should most likely fail the request. > "Privacy services would be wise to authenticate users before providing a > privacy function. To downstream entities, the privacy service will be > the only responsible party to whom anonymous messages can be traced, and > in abuse cases the privacy service could be held accountable for the > actions of parties that it shelters. " > > I'm not sure I agree with this. In some cases, _not_ authenticating > might be the only defence against sopoena(sp?). This paragraph falls > into the area of legal advice that should be given by lawers. > Well, it's true that we shouldn't be trying to dispense legal advice as such, but I feel the basic principle that is outlined here is worth mentioning if we can eliminate any implication of professional counsel. I'll see if I can't manage that. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 14:18:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16182 for ; Thu, 30 May 2002 14:18:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26002 for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24288; Thu, 30 May 2002 13:52:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24253 for ; Thu, 30 May 2002 13:52:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15233; Thu, 30 May 2002 13:52:26 -0400 (EDT) Message-Id: <200205301752.NAA15233@ietf.org> From: The IESG To: IETF-Announce: ; cc: sip@ietf.org, sipping@ietf.org Reply-to: iesg@ietf.org Date: Thu, 30 May 2002 13:52:26 -0400 Subject: [Sip] Last Call: A Privacy Mechanism for the Session Initiation Protocol (SIP) to Proposed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group to consider A Privacy Mechanism for the Session Initiation Protocol (SIP) for publication as a Proposed Standard The IESG will also consider publication of the following Internet-Drafts for publication as Informational RFCs: o Extensions to the Session Initiation Protocol (SIP) for Asserted Identity o Short term requirements for Network Asserted Identity The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 13, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-general-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-nai-reqs-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 14:48:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17169 for ; Thu, 30 May 2002 14:48:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27727 for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:48:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26243; Thu, 30 May 2002 14:24:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26211 for ; Thu, 30 May 2002 14:24:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16347; Thu, 30 May 2002 14:23:54 -0400 (EDT) Message-Id: <200205301823.OAA16347@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Thu, 30 May 2002 14:23:54 -0400 Subject: [Sip] Document Action: SIP Extensions for Media Authorization to Informational Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved SIP Extensions for Media Authorization for publication as an Informational RFC, but request that the title be changed to Private SIP Extensions for Media Authorization This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 17:20:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20215 for ; Thu, 30 May 2002 17:20:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05926 for sip-archive@odin.ietf.org; Thu, 30 May 2002 17:21:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03755; Thu, 30 May 2002 16:44:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03718 for ; Thu, 30 May 2002 16:44:17 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19626 for ; Thu, 30 May 2002 16:43:51 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4UKhjI10436; Thu, 30 May 2002 15:43:45 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 15:43:40 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870387@va02.va.neustar.com> From: "Peterson, Jon" To: "'Elwell, John'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general Date: Thu, 30 May 2002 15:43:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On the first issue, yes, the examples in sip-asserted-identity go against this SHOULD in sip-privacy-general, with some good reasons. Perhaps those reasons could stand to be motivated a bit in the identity draft - but I don't think this is the wrong behavior, anyway. On the second issue, the draft says if 'none' is present the privacy service MUST NOT perform any privacy function. The draft also says (section 4.2): "An intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already specified." So I think it should be clear that Privacy headers containing 'none' will not be removed. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk] > Sent: Thursday, May 30, 2002 5:26 AM > To: 'sip' > Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general > > > "When a privacy service performs one of the functions corresponding to > a privacy level listed in the Privacy header, it SHOULD remove the > corresponding priv-value from the Privacy header - otherwise, any > other privacy service involved with routing this message might > unnecessarily apply the same function, which in many cases would be > undesirable." > > This seems to be in contradiction with > draft-ietf-sip-asserted-identity, > which show "Privacy: id" being maintained with the forwarded INVITE. > > "When the last priv-value (not counting 'critical') has > been removed from the Privacy header, the entire Privacy header MUST > be removed from a message." > > Is this wise in the case of "None"? > > -------------------------------------------------------------- > John Elwell (john.elwell@siemens.com) > Siemens Communications Limited, > Technology Drive, Beeston, > Nottingham NG9 1LA, UK > Tel: +44 115 943 4989 Fax: +44 115 943 4969 > -------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > > Sent: 28 May 2002 22:32 > > To: 'sip' > > Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; Jon > > Peterson (jon.peterson@NeuStar.com) > > Subject: [Sip] WGLC for draft-ietf-sip-privacy-general > > > > > > > > We need to do a quick review of the general privacy draft > > developed out > > of our discussion in Las Vegas. > > > > Please send any issues to the list and the editor IMMEDIATELY. > > > > The draft is available from: > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g > > eneral-00. > > html > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g > eneral-00. > txt > And soon to be available from internet-drafts if not already . . . > > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu May 30 17:22:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20245 for ; Thu, 30 May 2002 17:22:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06011 for sip-archive@odin.ietf.org; Thu, 30 May 2002 17:23:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04282; Thu, 30 May 2002 16:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04257 for ; Thu, 30 May 2002 16:59:54 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19878 for ; Thu, 30 May 2002 16:59:28 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4UKwW430043; Thu, 30 May 2002 15:58:32 -0500 From: "Dean Willis" To: "'Elwell, John'" , "'sip'" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity Date: Thu, 30 May 2002 15:57:43 -0500 Message-ID: <00d401c2081c$a4d08270$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BD@Beex50.siemenscomms.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit John Elwell pondered: > Section 5, 3rd paragraph: > "The proxy MAY add a P-Asserted-Identity header field with either a > single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a > P-Asserted-Identity header field with a single tel URL." > > This seems to imply that a proxy can add a header even if > there is already a header of the type concerned. Presumably > this should not be allowed. Why? There might be some issue with multiple tel URLs and gateway interworking, but asserting multiple identities seems like a very reasonable thing from a SIP perspective. If you're a PGP user, you may well have multiple identities associated with one PGO key. There are practical reasons for doing this, and it doesn't seem to cause any problems. Different proxies or authentication servers might "know you" by different identities and be able to assert those identities on your behalf. It might also be reasonable to have multiple assertions for the same identity, like multiple signers in PGP. Signed, dwillis@dynamicsoft.com dean.willis@softarmor.com dwillis@greycouncil.com edean_willis@yahoo.com Ad nasueatum . . . _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 30 18:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21342 for ; Thu, 30 May 2002 18:38:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09717 for sip-archive@odin.ietf.org; Thu, 30 May 2002 18:38:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08490; Thu, 30 May 2002 18:14:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08459 for ; Thu, 30 May 2002 18:14:56 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21017 for ; Thu, 30 May 2002 18:14:30 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4UMEIc01090; Thu, 30 May 2002 18:14:18 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 17:14:12 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870389@va02.va.neustar.com> From: "Peterson, Jon" To: "'Dean Willis'" , "'Elwell, John'" , "'sip'" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity Date: Thu, 30 May 2002 17:14:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree that asserting multiple identities is interesting. In the course of the short-term work, we made a simple scope decision that multiple identities (aside from one SIP[S] URI and one tel URL) is a long-term problem. Obviously, it is pretty easy with the long-term approach to sign multiple identity values in a single body, provide multiple bodies, and so on. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, May 30, 2002 1:58 PM > To: 'Elwell, John'; 'sip' > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > John Elwell pondered: > > Section 5, 3rd paragraph: > > "The proxy MAY add a P-Asserted-Identity header field > with either a > > single SIP URI or a single SIPS URI. Likewise, the > proxy MAY add a > > P-Asserted-Identity header field with a single tel URL." > > > > This seems to imply that a proxy can add a header even if > > there is already a header of the type concerned. Presumably > > this should not be allowed. > > Why? > > There might be some issue with multiple tel URLs and gateway > interworking, but asserting multiple identities seems like a very > reasonable thing from a SIP perspective. > > If you're a PGP user, you may well have multiple identities associated > with one PGO key. There are practical reasons for doing this, and it > doesn't seem to cause any problems. > > Different proxies or authentication servers might "know you" by > different identities and be able to assert those identities on your > behalf. It might also be reasonable to have multiple > assertions for the > same identity, like multiple signers in PGP. > > Signed, > > dwillis@dynamicsoft.com > dean.willis@softarmor.com > dwillis@greycouncil.com > edean_willis@yahoo.com > > Ad nasueatum . . . > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 30 18:45:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21441 for ; Thu, 30 May 2002 18:45:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09965 for sip-archive@odin.ietf.org; Thu, 30 May 2002 18:46:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08429; Thu, 30 May 2002 18:14:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08396 for ; Thu, 30 May 2002 18:14:14 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21012 for ; Thu, 30 May 2002 18:13:49 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4UMCuI15986; Thu, 30 May 2002 17:12:56 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 17:12:51 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870388@va02.va.neustar.com> From: "Peterson, Jon" To: "'Juha Heinanen'" , Rohan Mahy Cc: sip@ietf.org Subject: RE: [Sip] P- headers vs. requirements in sip change process Date: Thu, 30 May 2002 17:12:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org While the purpose of the short-term asserted identity work overlaps with the purpose of the long-term asserted identity work (both provide a means for network intermediaries to ascertain and share identity information), I think their delineation is fairly clear. The short-term work is inextricably tied to the Trust Domain model and all that implies. Moreover, we are working on defining (in a separate document) a means of gatewaying between networks using the short-term approach and the Internet at large (i.e. the long-term approach) which will throw the distinction into even starker relief. The purpose of this restriction in sipchange is, I think, to prevent P- headers from becoming defacto standards that later chartered work cannot replace. I would have to contend that the domain of applicability of the short-term work is so limited that this risk is manageable. I think the content of the NAI header is 'informational' - it is displayed to the destination (or not, when privacy is required) as the identity of the originator of the session. A header that is not 'informational' in this sense would be, for example, the Via header, which is used directly in routing message responses, and changes the behavior of nodes that handle it. At least that's how I read the corresponding passage in sipchange; this is a "header which merely provides additional information pertinent to a request or a response". Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Wednesday, May 29, 2002 2:34 PM > To: Rohan Mahy > Cc: sip@ietf.org > Subject: [Sip] P- headers vs. requirements in sip change process > > > Rohan Mahy writes: > > > 3. No overlap with planned/chartered extensions > > 4. Purely informational in nature > > with regards to nai, i don't think the above two apply, since there is > clearly a generic need to augment sip with a nai style header when the > user has included anonymous from uri. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 30 18:45:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21460 for ; Thu, 30 May 2002 18:45:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09979 for sip-archive@odin.ietf.org; Thu, 30 May 2002 18:46:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08647; Thu, 30 May 2002 18:18:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08616 for ; Thu, 30 May 2002 18:17:59 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21079 for ; Thu, 30 May 2002 18:17:34 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g4UMHcX88976; Thu, 30 May 2002 17:17:38 -0500 (CDT) Message-ID: <3CF6A500.8080901@dynamicsoft.com> Date: Thu, 30 May 2002 17:17:36 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" , Cullen Jennings , Mark Watson CC: sip X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on draft-ietf-sip-asserted-identity-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Some comments/questions: > If a UA is part of the Trust Domain from which it received a message > containing a P-Asserted-Identity header field, then it can use the > value freely but it MUST ensure that it does not forward the > information to any element that is not part of the Trust Domain. > Does this in any way depend on a request for privacy? Or do we place a stronger burden on a UAS than on a proxy for non-sharing of asserted identity? (OK, just one question) Thanks! Ben. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 30 22:30:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24550 for ; Thu, 30 May 2002 22:30:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA19512 for sip-archive@odin.ietf.org; Thu, 30 May 2002 22:31:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17618; Thu, 30 May 2002 21:58:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17591 for ; Thu, 30 May 2002 21:58:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24137 for ; Thu, 30 May 2002 21:58:05 -0400 (EDT) Received: from [10.1.30.23] (rtp-vpn1-659.cisco.com [10.82.226.147]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4V1vlPI011486; Thu, 30 May 2002 18:57:48 -0700 (PDT) Date: Thu, 30 May 2002 21:57:35 -0400 From: "David R. Oran" To: Dean Willis , "'Christian Huitema'" , "'Jonathan Rosenberg'" cc: "'Henning Schulzrinne'" , sip@ietf.org Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard Message-ID: <1082776.1022795855@[10.1.30.23]> In-Reply-To: <011201c2069c$df496830$1d036e3f@TXDWILLIS2> References: <011201c2069c$df496830$1d036e3f@TXDWILLIS2> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit --On Tuesday, May 28, 2002 6:10 PM -0500 Dean Willis wrote: > > Christian said: >> I don't think that the "firewall traversal" requirement >> actually applies to hotel connections. The hotel connection >> supposedly gives you a high speed Internet access, and they >> often charge you good money for the service. The hotel has no >> good reason to check whether you use TCP or UDP, or for that >> matter IPSEC -- and since we are speaking of a DHCPv6 option, >> we have to assume that we are using IPv6, and that there is >> no NAT to go through. In these conditions, the only real >> reason for the local proxy is a desire to control some >> specific applications -- very possibly, make you pay phone >> calls by the minute. As you say, this is silly, and I don't >> see why we should tweak our standards encourage such silliness. > > > Where are you finding hotels with broadband that don't require use of > their NAT box and HTTP proxy? I've never seen a hotel with a truly open > internet connection. > Uh, right here. I'm using one to send this message. For $9.95 a day you get a NAT'ed address and their HTP proxy. For $14.95 you get a public address and open access. What's your point? > - > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ----------------------------------------------------------- David R. Oran Phone/Fax: +1 978 264 2048 Cisco Systems VoIP: +1 408 571 4576 7 Ladyslipper Lane Email: oran@cisco.com Acton, MA 01720 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu May 30 23:15:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25363 for ; Thu, 30 May 2002 23:15:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA21487 for sip-archive@odin.ietf.org; Thu, 30 May 2002 23:16:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20142; Thu, 30 May 2002 22:45:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20115 for ; Thu, 30 May 2002 22:45:43 -0400 (EDT) Received: from mail.datang.com (38613.ddn.xaonline.com [61.185.215.108] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25107 for ; Thu, 30 May 2002 22:45:17 -0400 (EDT) Received: from zhonghua (38625.ddn.xaonline.com [61.185.215.120] (may be forged)) by mail.datang.com (8.11.0/8.11.0) with SMTP id g4V2rJj29057 for ; Fri, 31 May 2002 10:53:19 +0800 From: "zhong hua" To: Date: Fri, 31 May 2002 10:45:06 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA20116 Subject: [Sip] anycast Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit what is anycast type of service. Thanks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 02:24:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07093 for ; Fri, 31 May 2002 02:24:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06578 for sip-archive@odin.ietf.org; Fri, 31 May 2002 02:24:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05100; Fri, 31 May 2002 01:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05069 for ; Fri, 31 May 2002 01:44:06 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28078 for ; Fri, 31 May 2002 01:43:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4V5i3mG004402 for ; Fri, 31 May 2002 07:44:03 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4V5i3a9005688 for ; Fri, 31 May 2002 08:44:03 +0300 (EET DST) Message-ID: <3CF70DA3.74A87943@ericsson.com> Date: Fri, 31 May 2002 08:44:03 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] draft-garcia-sip-associated-uri-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I submitted version -02 of the P-Associated-URI header. I have incorporated all the comments in the discussion. Note that is out of the scope of this draft to describe a proxy who is policing From headers and alike. I believe the draft will be announced soon. In the meantime, you can fetch it from: http://standards.ericsson.net/sip/drafts/draft-garcia-sip-associated-uri-02.txt Other 2 P- headers draft revisions that were already announced are: http://standards.ericsson.net/sip/drafts/draft-garcia-sip-visited-network-id-02.txt http://standards.ericsson.net/sip/drafts/draft-garcia-sip-called-party-id-02.txt These two include mainly clarifications and comments I got in the mailing list. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 02:53:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07532 for ; Fri, 31 May 2002 02:53:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08274 for sip-archive@odin.ietf.org; Fri, 31 May 2002 02:54:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07760; Fri, 31 May 2002 02:37:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07728 for ; Fri, 31 May 2002 02:37:27 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07289 for ; Fri, 31 May 2002 02:37:01 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17Dg2P-0007Kk-00; Fri, 31 May 2002 09:37:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.6693.482999.227938@harjus.eng.song.fi> Date: Fri, 31 May 2002 09:37:25 +0300 To: "Peterson, Jon" Cc: Rohan Mahy , sip@ietf.org Subject: RE: [Sip] P- headers vs. requirements in sip change process In-Reply-To: <70565611B164D511957A001083FCDD5601870388@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD5601870388@va02.va.neustar.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > I think the content of the NAI header is 'informational' - it is displayed > to the destination (or not, when privacy is required) as the identity of the > originator of the session. A header that is not 'informational' in this > sense would be, for example, the Via header, which is used directly in > routing message responses, and changes the behavior of nodes that handle it. > At least that's how I read the corresponding passage in sipchange; this is a > "header which merely provides additional information pertinent to a request > or a response". when a request with nai header hits a sip/pstn gateway, for example, its contents may very well effect how the message is handled or routed by the gateway. also, nai is and in fact MUST be used also within a single trust domain if the user has specified anonymous from header and the request goes to a sip/pstn gw.. so the nai header is not just some "nice to know" thing, but an integral part of the sip specification. finally we may even need a new error code to signal to the user that inserts a nai header the case where the user inserted nai identity doesn't match with the network. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 03:12:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07820 for ; Fri, 31 May 2002 03:12:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09550 for sip-archive@odin.ietf.org; Fri, 31 May 2002 03:13:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08363; Fri, 31 May 2002 02:55:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08332 for ; Fri, 31 May 2002 02:55:30 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07570 for ; Fri, 31 May 2002 02:55:04 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17DgJt-0007LR-00; Fri, 31 May 2002 09:55:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.7777.699826.20294@harjus.eng.song.fi> Date: Fri, 31 May 2002 09:55:29 +0300 To: "Cullen Jennings" Cc: "Peterson, Jon" , Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 In-Reply-To: References: <15605.19484.700710.415050@rautu.eng.song.fi> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cullen Jennings writes: > I feel there is a header where the UA gets to assert who it wants to be > known as - it's the From header. yes, but if the user uses anonymous from header, the it MUST use nai header for that purpose. i don't know about Tspec(T). nao should be part of basic sip and it doesn't sound like a good idea to start to parameterize the basic semantics of the protocol. so my suggestion is that if the user inserted nai doesn't match with networks opinion, the network MUST reject the request with an error code. the user then will know to change the contents of the nai header, which is a very reasonable thing to do. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 03:53:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08434 for ; Fri, 31 May 2002 03:53:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11485 for sip-archive@odin.ietf.org; Fri, 31 May 2002 03:53:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09962; Fri, 31 May 2002 03:28:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09933 for ; Fri, 31 May 2002 03:28:32 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07982 for ; Fri, 31 May 2002 03:28:06 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GWY00G01SQ7PR@siemenscomms.co.uk> for sip@ietf.org; Fri, 31 May 2002 08:27:43 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GWY00FFBSQ7L5@siemenscomms.co.uk>; Fri, 31 May 2002 08:27:43 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 08:27:58 +0100 Content-return: allowed Date: Fri, 31 May 2002 08:27:31 +0100 From: "Elwell, John" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity To: "'Cullen Jennings'" Cc: sip@ietf.org Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C2@Beex50.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Cullen, What about: "The proxy MAY add a P-Asserted-Identity header field with either a single SIP URI or a single SIPS URI, provided there is not already a SIP URI or SIPS URI present. Likewise, the proxy MAY add a P-Asserted-Identity header field with a single tel URL, provided there is not already a tel URL present." John -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 30 May 2002 17:45 > To: Elwell, John; sip@ietf.org > Cc: Fluffy > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > Yes, it should not be allowed. There can be at most one AI > with a sip or > sips header and at most one AI with a tel. I agree the > language is loose. > Any suggestion on what I should change this paragraph too? > > What about: > > "The proxy MAY add a P-Asserted-Identity header field with either a > single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a > P-Asserted-Identity header field with a single tel URL. > There can not be > more that one of each of these so if there are existing > P-Asserted-Identity > headers, they must be replaced." > > I don't really like this either but it was the best I could do in 30 > seconds - suggestions? > > Thanks, Cullen > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Elwell, > John > Sent: Thursday, May 30, 2002 5:31 AM > To: 'sip' > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > Section 5, 3rd paragraph: > "The proxy MAY add a P-Asserted-Identity header field with either a > single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a > P-Asserted-Identity header field with a single tel URL." > > This seems to imply that a proxy can add a header even if > there is already a > header of the type concerned. Presumably this should not be allowed. > > -------------------------------------------------------------- > John Elwell (john.elwell@siemens.com) > Siemens Communications Limited, > Technology Drive, Beeston, > Nottingham NG9 1LA, UK > Tel: +44 115 943 4989 Fax: +44 115 943 4969 > -------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 28 May 2002 22:32 > > To: 'sip' > > Cc: brian.rosen@marconi.com; rohan@cisco.com; > jo@ipdialog.com; 'Cullen > > Jennings' > > Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > > > > > We need to do a quick working group last call on the > > "Asserted Identity" > > draft. > > > > Please submit comments to the list and draft editor IMMEDIATELY. > > > > Draft available from: > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted- > identity-0 > 0.html > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted- identity-0 0.txt And soon to be in the internet-drafts archive. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 04:03:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08609 for ; Fri, 31 May 2002 04:03:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12592 for sip-archive@odin.ietf.org; Fri, 31 May 2002 04:04:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10907; Fri, 31 May 2002 03:42:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10878 for ; Fri, 31 May 2002 03:42:29 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08175 for ; Fri, 31 May 2002 03:42:02 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GWY00H01TDI40@siemenscomms.co.uk> for sip@ietf.org; Fri, 31 May 2002 08:41:43 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GWY00FNTTD9GH@siemenscomms.co.uk>; Fri, 31 May 2002 08:41:33 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 08:41:48 +0100 Content-return: allowed Date: Fri, 31 May 2002 08:41:21 +0100 From: "Elwell, John" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity To: "'Dean Willis'" Cc: "'sip@ietf.org'" Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C3@Beex50.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Dean, My motivation for saying it should not be allowed was that it seemed to be implied elsewhere in the document - I wanted clarification. However, multiple identities of the same type might give a problem for gateways, as you pointed out. I guess a gateway would just have to pick one, e.g., the first. Regards, John -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 30 May 2002 21:58 > To: 'Elwell, John'; 'sip' > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > John Elwell pondered: > > Section 5, 3rd paragraph: > > "The proxy MAY add a P-Asserted-Identity header field > with either a > > single SIP URI or a single SIPS URI. Likewise, the > proxy MAY add a > > P-Asserted-Identity header field with a single tel URL." > > > > This seems to imply that a proxy can add a header even if > > there is already a header of the type concerned. Presumably > > this should not be allowed. > > Why? > > There might be some issue with multiple tel URLs and gateway > interworking, but asserting multiple identities seems like a very > reasonable thing from a SIP perspective. > > If you're a PGP user, you may well have multiple identities associated > with one PGO key. There are practical reasons for doing this, and it > doesn't seem to cause any problems. > > Different proxies or authentication servers might "know you" by > different identities and be able to assert those identities on your > behalf. It might also be reasonable to have multiple > assertions for the > same identity, like multiple signers in PGP. > > Signed, > > dwillis@dynamicsoft.com > dean.willis@softarmor.com > dwillis@greycouncil.com > edean_willis@yahoo.com > > Ad nasueatum . . . > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 04:21:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08919 for ; Fri, 31 May 2002 04:21:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13651 for sip-archive@odin.ietf.org; Fri, 31 May 2002 04:21:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11905; Fri, 31 May 2002 03:58:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11874 for ; Fri, 31 May 2002 03:58:39 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08498 for ; Fri, 31 May 2002 03:58:11 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17DhIz-0007MY-00; Fri, 31 May 2002 10:58:37 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.11565.220136.731385@harjus.eng.song.fi> Date: Fri, 31 May 2002 10:58:37 +0300 To: "Elwell, John" Cc: "'Cullen Jennings'" , sip@ietf.org Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity In-Reply-To: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C2@Beex50.siemenscomms.co.uk> References: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C2@Beex50.siemenscomms.co.uk> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Elwell, John writes: > "The proxy MAY add a P-Asserted-Identity header field with either a single > SIP URI or a single SIPS URI, provided there is not already a SIP URI or > SIPS URI present. Likewise, the proxy MAY add a P-Asserted-Identity header > field with a single tel URL, provided there is not already a tel URL > present." what about modifying an existing nai header? is that is not allowed then the above text is fine with me, since it also forces the proxy to reject the request if the user has inserted the nai and the network doesn't like its contents. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 04:31:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09030 for ; Fri, 31 May 2002 04:31:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14647 for sip-archive@odin.ietf.org; Fri, 31 May 2002 04:32:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13355; Fri, 31 May 2002 04:15:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13260 for ; Fri, 31 May 2002 04:15:46 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08860 for ; Fri, 31 May 2002 04:15:18 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GWY00H01UWZZC@siemenscomms.co.uk> for sip@ietf.org; Fri, 31 May 2002 09:14:59 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GWY00HAYUWYL2@siemenscomms.co.uk>; Fri, 31 May 2002 09:14:59 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 09:15:14 +0100 Content-return: allowed Date: Fri, 31 May 2002 09:14:46 +0100 From: "Elwell, John" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity To: "'jh@lohi.eng.song.fi'" , "'Cullen Jennings'" Cc: sip@ietf.org Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C6@Beex50.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT I had assumed that any header that was to be removed would already have been removed at this point. However, looking at the rest of the text again, this is not clear. So how about: "The proxy MAY add a P-Asserted-Identity header field with either a single SIP URI or a single SIPS URI, provided there is not already a SIP URI or SIPS URI present or replacing a SIP URI or SIPS URI from an untrusted source. Likewise, the proxy MAY add a P-Asserted-Identity header field with a single tel URL, provided there is not already a tel URL present or replacing a tel URL from an untrusted source." John -------------------------------------------------------------- John Elwell (john.elwell@siemens.com) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 31 May 2002 08:59 > To: Elwell, John > Cc: 'Cullen Jennings'; sip@ietf.org > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > Elwell, John writes: > > > "The proxy MAY add a P-Asserted-Identity header field with > either a single > > SIP URI or a single SIPS URI, provided there is not > already a SIP URI or > > SIPS URI present. Likewise, the proxy MAY add a > P-Asserted-Identity header > > field with a single tel URL, provided there is not already > a tel URL > > present." > > what about modifying an existing nai header? is that is not > allowed then > the above text is fine with me, since it also forces the > proxy to reject > the request if the user has inserted the nai and the network doesn't > like its contents. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 06:32:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10615 for ; Fri, 31 May 2002 06:32:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21497 for sip-archive@odin.ietf.org; Fri, 31 May 2002 06:32:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20091; Fri, 31 May 2002 06:08:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20060 for ; Fri, 31 May 2002 06:08:17 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10241 for ; Fri, 31 May 2002 06:07:51 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4VA8F721835 for ; Fri, 31 May 2002 06:08:15 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:08:14 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0051B5113@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Juha Heinanen , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00 Date: Fri, 31 May 2002 11:08:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The term "hint" was an attempt to get away from the impression that the user asserted the identity and the network "screened" it to use the much abused ISDN term. My view is that the content of the asserted-identity is entirely a policy matter of the trusted network. How the trusted network therefore takes the "hint" is entirely up to the policy of the network. It must not be assumed by any reader that the function is just screening, i.e. pass on the value or replace it by a new value. For example, if the user provides a tel-url, and the trusted network knows of the relationship between that tel-url and a one of a number of sip-urls that it can assert, then it would be perfectly appropriate to assert the sip-url if that is what the network policy requires. I have no problem including a network policy statement within the spec(t) as regards how the hint is handled, as to provide adequate hints the UA needs to have some knowledge of this, but I will object if anybody attempts to describe it as a "screening" function. Keith > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: 28 May 2002 08:23 > To: Cullen Jennings > Cc: sip@ietf.org > Subject: [Sip] draft-ietf-sip-asserted-identity-00 > > > once again: > > the term "hint" is not a good one. if user adds the a-i, then the > network MUST respect it or reject the request. the network MUST not > override the a-i and pick one of the identities on its own. for > example, the user may have misspelled the its uri in the a-i. > > also, the text should say that in case from is anonymous the user MUST > insert the a-i header if it has multiple identities, because otherwise > the network cannot know which identity the user wants to use. > > finally, for backwards compatibility, if from is not anonymous and the > user has multiple identities, then from uri can serve as the > purpose of > a-i. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 07:40:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12106 for ; Fri, 31 May 2002 07:40:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25603 for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:41:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23850; Fri, 31 May 2002 07:21:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23819 for ; Fri, 31 May 2002 07:21:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11454; Fri, 31 May 2002 07:21:05 -0400 (EDT) Message-Id: <200205311121.HAA11454@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 31 May 2002 07:21:05 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Security Mechanism Agreement for SIP Sessions Author(s) : J. Arkko et al. Filename : draft-ietf-sip-sec-agree-02.txt Pages : 16 Date : 30-May-02 SIP has a number of security mechanisms. Some of them have been built in to the SIP protocol, such as HTTP authentication or secure attachments. These mechanisms have even alternative algorithms and parameters. SIP does not currently provide any mechanism for selecting which security mechanisms to use between two entities. In particular, even if some mechanisms such as OPTIONS were used to make this selection, the selection would be vulnerable against the Bidding-Down attack. This document defines three header fields for negotiating the security mechanisms within SIP between a SIP entity and its next SIP hop. A SIP entity applying this mechanism must always require some minimum security (i.e. integrity protection) from all communicating parties in order to secure the negotiation, but the negotiation can agree on which specific minimum security is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-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-ietf-sip-sec-agree-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sec-agree-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020530103526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-agree-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-agree-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103526.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 07:40:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12104 for ; Fri, 31 May 2002 07:40:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25604 for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:41:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23900; Fri, 31 May 2002 07:21:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23863 for ; Fri, 31 May 2002 07:21:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11472; Fri, 31 May 2002 07:21:10 -0400 (EDT) Message-Id: <200205311121.HAA11472@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 31 May 2002 07:21:10 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-path-08.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Session Initiation Protocol Extension for Registering Non-Adjacent Contacts Author(s) : D. Willis, B. Hoeneisen Filename : draft-willis-sip-path-08.txt Pages : 18 Date : 30-May-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: and is generally dynamic and associated with the IP address or hostname of the SIP UA. The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request travelling from the user's home network to the registered UA must traverse these proxies. The REGISTER method 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 field, 'Path' which provides such a mechanism A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-path-08.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-willis-sip-path-08.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-path-08.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020530103536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-path-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-path-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103536.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 07:41:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12142 for ; Fri, 31 May 2002 07:41:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25626 for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:41:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23694; Fri, 31 May 2002 07:21:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23664 for ; Fri, 31 May 2002 07:21:09 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11380; Fri, 31 May 2002 07:20:41 -0400 (EDT) Message-Id: <200205311120.HAA11380@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 31 May 2002 07:20:40 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-associated-uri-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol extension for Associated Uniform Resource Identifiers Author(s) : M. Garcia Filename : draft-garcia-sip-associated-uri-02.txt Pages : 7 Date : 30-May-02 This memo describes a private extension to SIP [1] that allows a registrar to return a set of associated URIs to a registered address- of-record. We define the P-Associated-URI header field, used in the 200 OK response to a REGISTER request. The P-Associated-URI header field transports the set of Associated URIs to the registered address- of-record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-associated-uri-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-garcia-sip-associated-uri-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-associated-uri-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020530103442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-associated-uri-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-associated-uri-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 07:46:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12265 for ; Fri, 31 May 2002 07:46:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25766 for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:46:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23737; Fri, 31 May 2002 07:21:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23703 for ; Fri, 31 May 2002 07:21:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11398; Fri, 31 May 2002 07:20:45 -0400 (EDT) Message-Id: <200205311120.HAA11398@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 31 May 2002 07:20:44 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol Extension Header Field for Service Route Discovery in Private Networks Author(s) : D. Willis, B. Hoeneisen Filename : draft-willis-sip-scvrtdisco-06.txt Pages : 16 Date : 30-May-02 This document proposes a private SIP extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-06.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-willis-sip-scvrtdisco-06.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-scvrtdisco-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020530103453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-scvrtdisco-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-scvrtdisco-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103453.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 09:39:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16169 for ; Fri, 31 May 2002 09:39:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04224 for sip-archive@odin.ietf.org; Fri, 31 May 2002 09:39:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29489; Fri, 31 May 2002 08:47:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07430 for ; Thu, 30 May 2002 17:55:58 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20720 for ; Thu, 30 May 2002 17:55:33 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4ULtR217150 for ; Thu, 30 May 2002 17:55:27 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 16:55:26 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02BD4FFB@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: Dean Willis , sip@ietf.org Cc: rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Date: Thu, 30 May 2002 16:55:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: Poll: expert review of draft-henrikson-sip-charging-informati on Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org All, Revision 3 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today. Revision 3 contains the following changes: - additions to Applicability Statement for when the new charging headers don't apply - clarifications to the Security Considerations - fixing the examples to show IP addresses for the charging function addresses - additional sections for acknowledgements and the full copyright statement The new revision should appear on the IETF web site soon. Please let me know if you have further comments or would like a copy of rev 3 prior to its appearence on the web site. Thank you. Eric Henrikson -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, May 24, 2002 12:28 PM To: sip@ietf.org Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; ehenrikson@lucent.com Subject: Poll: expert review of draft-henrikson-sip-charging-information You may recall that we're doing an Expert Review of draft-henrikson-sip-charging-information. If you have a strong opinion for, against, or supporting a need for further work, or any further suggestions for enhancement, please post them now. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 11:42:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19895 for ; Fri, 31 May 2002 11:42:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14594 for sip-archive@odin.ietf.org; Fri, 31 May 2002 11:42:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10724; Fri, 31 May 2002 10:58:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10693 for ; Fri, 31 May 2002 10:58:49 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18671 for ; Fri, 31 May 2002 10:58:23 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AFA85C2F0128; Fri, 31 May 2002 10:58:48 -0400 Message-ID: <00c001c208b2$e620b7e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , References: <200205291132.HAA10977@ietf.org> <3CF5424D.949B5346@dynamicsoft.com> Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.txt Date: Fri, 31 May 2002 10:53:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Rosenberg" > > The title needs to have the acronym SIP expanded. I know this is a really minor point, but why does SIP need to be expanded in the title? Most other I-Ds and RFCs (besides the base spec of course) use the acronym of the protocol in their title. The problem we've had in the past is that the title did not even include the acronym. Why not require the expansion in the abstract? cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 11:42:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19911 for ; Fri, 31 May 2002 11:42:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14611 for sip-archive@odin.ietf.org; Fri, 31 May 2002 11:42:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12018; Fri, 31 May 2002 11:09:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11992 for ; Fri, 31 May 2002 11:09:24 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18948 for ; Fri, 31 May 2002 11:08:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4VEFE901222 for ; Fri, 31 May 2002 17:15:14 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 31 May 2002 17:16:27 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 17:16:27 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 17:16:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 31 May 2002 17:16:26 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779217@esebe019.NOE.Nokia.com> Thread-Topic: comments on refer-04 Thread-Index: AcIIrcAhRc+Jb4ufR9mNrQJrotmnaw== To: X-OriginalArrivalTime: 31 May 2002 14:16:27.0203 (UTC) FILETIME=[C083E930:01C208AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA11993 Subject: [Sip] comments on refer-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Section 3. "Refer-To is a request-header as defined by [1]. It may only appear in a REFER request" Should that be a "MAY" or should it actually say "It only appears in a REFER request"? Section 6.4 "Registrars and Redirect Servers SHOULD return a 603 to a REFER request, unless they are also playing some other SIP role." I would think sending a 501 is more appropriate. This follows the default behaviour of UASs responding to unknown methods. 603 requires the registrar/redirect server to recognise the REFER. How about "Registrars and Redirect servers do not require modifications to support the Refer method. A 501 response is returned by default if the UAS is RFC3216 compliant. If they are modified to support REFER, Registrars and Redirect Servers SHOULD return a 603 to a REFER request , unless they are also playing some other SIP role." Section 7. All Examples don't show the cookie in the branch-id of Via-header. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri May 31 12:39:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21864 for ; Fri, 31 May 2002 12:39:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20328 for sip-archive@odin.ietf.org; Fri, 31 May 2002 12:39:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15132; Fri, 31 May 2002 11:50:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15101 for ; Fri, 31 May 2002 11:50:07 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20125 for ; Fri, 31 May 2002 11:49:41 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4VFrhV28374; Fri, 31 May 2002 10:53:44 -0500 Subject: Re: [Sip] comments on refer-04 From: Robert Sparks To: hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7779217@esebe019.NOE.Nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7779217@esebe019.NOE.Nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 10:45:34 -0500 Message-Id: <1022859935.1373.44.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the comments! On Fri, 2002-05-31 at 09:16, hisham.khartabil@nokia.com wrote: > Section 3. > "Refer-To is a request-header as defined by [1]. It may only appear > in a REFER request" > > Should that be a "MAY" or should it actually say "It only appears in a REFER request"? the second > > Section 6.4 > "Registrars and Redirect Servers SHOULD return a 603 to a REFER > request, unless they are also playing some other SIP role." > > I would think sending a 501 is more appropriate. This follows the default behaviour of UASs responding to unknown methods. 603 requires the registrar/redirect server to recognise the REFER. > > How about "Registrars and Redirect servers do not require modifications to support the Refer method. A 501 response is returned by default if the UAS is RFC3216 compliant. If they are modified to support REFER, Registrars and Redirect Servers SHOULD return a 603 to a REFER request , unless they are also playing some other SIP role." I'll add a sentence capturing the 501 default behavior. This 603 requirement, however, is old text and I don't think folks have looked at it recently. I propose that it is wrong. A redirect server is method agnostic and should treat REFER the way it treats any other request (redirecting it if policy allows it). A registrar that knows what REFER is needs to reject the request but 603 is not the right code (603 implies that the REFER will fail _everywhere_). I believe 405 is the right code for this case. I will make these changes unless I hear objections. > > Section 7. > All Examples don't show the cookie in the branch-id of Via-header. Will fix > > Regards, > Hisham > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03636 for ; Fri, 31 May 2002 16:17:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02112 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:18:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00835; Fri, 31 May 2002 15:59:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00806 for ; Fri, 31 May 2002 15:59:56 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02833 for ; Fri, 31 May 2002 15:59:27 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A638ABBE012A; Fri, 31 May 2002 15:59:52 -0400 Message-ID: <017c01c208dc$d0065b20$2300000a@acmepacket.com> From: "Bob Penfield" To: "Peterson, Jon" , "'Jonathan Rosenberg'" Cc: References: <70565611B164D511957A001083FCDD5601870381@va02.va.neustar.com> Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general Date: Fri, 31 May 2002 15:53:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit see comments below ----- Original Message ----- From: "Peterson, Jon" > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] [snip] > > > > > Header field where proxy ACK BYE CAN INV OPT REG > > > ___________________________________________________________ > > > Privacy amrd o o o o o - > > > > I think privacy is still useful in a register message. It would be > > helpful when I want to register through my provider using an anonymizer > > service, which possibly obfuscates the Contact header. Interestingly, > > the privacy service couldn't obfuscate the From or To field, since these > > are needed by the registrar. Perhaps that is why Privacy is not allowed > > here? It makes me wonder if there is a need to specify privacy on a > > slighlty more granular level, allowing the user to request obfuscation > > of groups of headers (To/From in one group, Contact/Via/RR in > > another). > > > > Yes, the To/From implication combined with obscuring of the Contact(s) is > one reason why Privacy isn't allowed here. Note that the levels of > granularity you suggest are already in the draft, I think, since the > procedures for 'header' level privacy (6.1) entail the obfuscation of > Contact/Via/RR, whereas only 'user' level privacy conceals the To/From. So > actually, I think it would be possible to only obscure contacts. As you say, there is only an implication of which headers the 'user' or 'header' levels apply to. Do we need an explicit list in the draft? > > I guess this extension just isn't designed to keep identity information > private from registrars - the utility of that remains obscure to me after > some reflection on the matter. This is partly a question of when the privacy > service should be closer to the user (presumably one hop away) than a > registrar, when it should be farther away, and when the privacy service and > registrar should be colocated. Registering an anonymous Contact could be > meaningful when your privacy service is closer to you than your register. If > the two are conflated, or the registrar is closer than your privacy service, > there probably wouldn't be any need to register an anonymous Contact. > Although the draft mandates no architecture, I think it leans towards this > second scenario for providing privacy when you are the called party. > > Given all that, though, I agree that this restriction can be removed - > there's no reason to forbid registering a Contact through a privacy service > that will provide privacy for these Contact addresses (granted that what > appears in the Contact after it passes through a privacy service is an > 'anonymous callback' sort of contact address, rather than an unroutable URI > that expresses anonymity). Although I agree that privacy is useful for REGISTER, it then becomes critical that the REGISTER message be secured between the UA and the registrar since it contains the mapping between the AOR and anonymous-callback-URI. > > > critical: The user asserts that the privacy services requested for > > > this message are critical, and that therefore, if these privacy > > > services cannot be provided by the network, this request should be > > > rejected. Criticality cannot be managed appropriately for > > > responses. > > > > OK, I hate to dredge up old issues, and perhaps this was hashed out in > > the many privacy threads I didn't get to, but, it seems like the value > > of critical is going to neccessitate a Proxy-Require header. The draft > > makes no mention of the use of proxy-require or the protocol > > implications if the extension is not supported by proxies. The > > proxy-require can be removed once the services have been performed, > > which is a good thing. > > > > Proxy-Require would also make it difficult to have a privacy service reside > more than one hop away from a client. But agreed that criticality is > severely hampered without something along these lines. This had been > discussed briefly (off the list, I think), but I don't think the discussion > ever arrived at any conclusion. > > Throughout the draft the assumption is made that the user is aware of a > distinct privacy service in the network, with which they have some sort of > relationship, through which calls will be routed. Arguably, without that > relationship a privacy service is of no value (that is, not just any privacy > service will do - it must be one that is specifically known to the user for > reasons of accountability). In that sense, the draft makes the (possibly > dangerous) assumption that no in-band feature negotiation is necessary - the > user knows out-of-band that that the server in question supports privacy. > Would be a pity if they were wrong. > > As we've discussed before, this taps somewhat into the whole service > discovery/composition problem, one that we know isn't going to be resolved > in the scope of this draft, anyway. > > > > It is RECOMMENDED that service providers couple the privacy service > > > function with a local outbound proxy. Users can thereby send their > > > messages that request privacy through their usual outbound route. > > > Users should not assume, however, that the administrative domain that > > > is the destination of the request would be willing and able to > > > perform the privacy service function on their behalf. > > > > How does the user know whether privacy services are supported? Do they > > need to try it with Proxy-Require to see if the request fails? > > > > The text above is meant to suggest that users should know out-of-band that > their local administrative domain supports a privacy service function. I too am quite concerned about this. It seems adaquate to say the UA "just knows" when we're talking about a P-Header with limited applicability, but not necessarily for a general purpose protocol mechanism. However, this mechanism would use a Require header, not a Proxy-Require. There are very few headers mentioned in this draft that RFC 3261 allows a proxy to modify or delete. I assert that performing any user, header or session privacy functions in an intermediary turns the privacy service into a B2BUA. If the UA is aware that is sending to a privacy service then it can certainly be aware that it is sending to a B2BUA and include the tag in its Require header. [snip] > > > > When a privacy service alters the Contact header of a > > > request, it MUST insert a Record-Route header pointing to itself so > > > that it can restore the appropriate contact address as necessary. > > > > Thats not true. The Contact header will presumably route to itself, so > > that an additional record-route is not necessary. > > > > That would work too, and is probably more efficient - I was envisioning > that the privacy service would add a Contact header with an anonymous URI > (i.e. one using the 'anonymous.invalid' hostname), and that therefore > Record-Routing was necessary to get the request back to the privacy service. > Of course if the Contact indicates the privacy service, that is sufficient. > I note that this makes the anonymous Contact registration story make a bit > more sense. I agree that just the Contact is more efficient, but will that be the only method allowed? And one more thing, in section 6 it says "Privacy services MUST implement the 'none' and 'critical' privacy levels". I just thought it was weird that a privacy service that had the minimum required implementation would not actually perform any privacy function. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:32:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03970 for ; Fri, 31 May 2002 16:32:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03387 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:32:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01689; Fri, 31 May 2002 16:09:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01660 for ; Fri, 31 May 2002 16:09:33 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03477 for ; Fri, 31 May 2002 16:09:04 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKAbYH028738; Fri, 31 May 2002 16:10:37 -0400 (EDT) Message-ID: <3CF7D859.367EB56@dynamicsoft.com> Date: Fri, 31 May 2002 16:08:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'sip@ietf.org'" Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general References: <70565611B164D511957A001083FCDD5601870381@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > > Thats not necessarily true; I can remain anonymous and even get a call > > back later on (for example, Reply-To: sip:user8222739@anonymous.net) - > > the key is that my identity is never revealed. > > > > I think anonymous callback is distinct from privacy as it is defined > here. > Apparently, sip:userXYZ@anonymous.net is an address at which you can > reached > - even though it is a relatively opaque piece of data, I would still > consider it in this definition a form of identity, one best suited to > something like anonymous callback. The term 'personal information' is > sometimes used in this draft to refer to something other than 'identity' > - > the identity sip:userXYZ@anonymous.net reveals no personal information. > Perhaps this is a distinction that could be drawn out a bit more. I'm confused as to whether you are agreeing or disagreeing with me.... > > > The scope of these privacy requirements is solely the SIP protocol > as > > > it is described in [1]. The mechanisms at the disposal of user > > > agents and proxy servers are restricted to those described in the > SIP > > > specification. Also, the privacy properties of the headers > listed in > > > the core SIP specification alone, as opposed to headers defined > by > > > any existing or planned extension, are considered here. > > > > I don't quite understand this paragraph. If a future extension defines > a > > header that reveals identity information, shouldn't this draft cover > > requests for privacy of that information? > > > > I'll rephrase that a bit. My point was just that I don't happen to > reference > and detail any existing SIP extensions in this draft. Obviously the > draft > has its own extensibility mechanism to accomodate future extensions, and > even some recommendations for authors of extensions to SIP. Right - but what I mean is, if a future extension to SIP defines some new form of identity, this specification would apply to help ensure privacy of that information, no? > > Also, you have forgotten two very, very important ones - Authorization > > and Proxy-Authorization. In general, I think the draft needs > discussion > > of these headers specifically. The user should only include such > headers > > if it is willing to provide identity information for the realm > provided > > in the challenge. Furthermore, the user may need to verify that the > > proxy is indeed part of the realm that they claim to be from before > the > > user provides identity information to it. Right now, we have no real > way > > to do that unless the proxy is the first hop proxy, in which case TLS > > can be used to ascertain the identity of the proxy that is providing > the > > challenge before providing credentials. All of this needs to be > > discussed. The issue is similar to that of routing requests to privacy > > services. > > > > Some effort has been made in the recent privacy/identity work to split > privacy and identity concepts into separate drafts. The practices you > describe for providing identity information to a server that issues > challenges, I think, belong in the identity drafts, not here (there is > some > text exactly to this effect in the second section of my longterm > identity > draft, actually). For the most part, we've also tried to put concerns > related to authentication into the identity drafts, both of which > normatively depend on the privacy draft. I really don't want to > duplicate > language and so forth, so I hope that the language in the Sec Cons of > the > privacy draft is really all we need here. There are privacy concerns with digest which are important to mention. Specifically, a UA that wants to know who I am might issue a 401, and fake the realm for my domain. I provide my identity in an Authorization header, and this information is then provided to the UAS. The problem is that the existing digest mechanism has a flaw regarding privacy, in that there is no assurance that the entity requesting credentials for the realm properly represents the realm, unless you are connected to them through TLS. Thus, I think it is important to mention this problem here. > > There are, after all, other forms of authentication than SIP Digest, > which > have parallel concerns, and I don't think we should open that can of > worms > in the privacy draft. The problem above is specific to digest. It doesn't exist for other forms of authentication (for example, entering a pin into an IVR system), since there I can verify the identity of the system because I dialed the number to access it, and *presumably* pstn routing will ensure that the call reaches the proper system. > > I think privacy is still useful in a register message. It would be > > helpful when I want to register through my provider using an > anonymizer > > service, which possibly obfuscates the Contact header. Interestingly, > > the privacy service couldn't obfuscate the From or To field, since > these > > are needed by the registrar. Perhaps that is why Privacy is not > allowed > > here? It makes me wonder if there is a need to specify privacy on a > > slighlty more granular level, allowing the user to request obfuscation > > of groups of headers (To/From in one group, Contact/Via/RR in > > another). > > > > Yes, the To/From implication combined with obscuring of the Contact(s) > is > one reason why Privacy isn't allowed here. Note that the levels of > granularity you suggest are already in the draft, I think, since the > procedures for 'header' level privacy (6.1) entail the obfuscation of > Contact/Via/RR, whereas only 'user' level privacy conceals the To/From. > So > actually, I think it would be possible to only obscure contacts. OK, I missed that. > > I guess this extension just isn't designed to keep identity information > private from registrars - the utility of that remains obscure to me > after > some reflection on the matter. This is partly a question of when the > privacy > service should be closer to the user (presumably one hop away) than a > registrar, when it should be farther away, and when the privacy service > and > registrar should be colocated. Registering an anonymous Contact could be > meaningful when your privacy service is closer to you than your > register. If > the two are conflated, or the registrar is closer than your privacy > service, > there probably wouldn't be any need to register an anonymous Contact. > Although the draft mandates no architecture, I think it leans towards > this > second scenario for providing privacy when you are the called party. > > Given all that, though, I agree that this restriction can be removed - > there's no reason to forbid registering a Contact through a privacy > service > that will provide privacy for these Contact addresses (granted that what > appears in the Contact after it passes through a privacy service is an > 'anonymous callback' sort of contact address, rather than an unroutable > URI > that expresses anonymity). True; this differing requirement may be sufficient to say that REGISTER security really is something different, and would necessitate a separate tag for it. So, I'm changing my mind here. > > > > critical: The user asserts that the privacy services requested for > > > this message are critical, and that therefore, if these > privacy > > > services cannot be provided by the network, this request > should be > > > rejected. Criticality cannot be managed appropriately for > > > responses. > > > > OK, I hate to dredge up old issues, and perhaps this was hashed out in > > the many privacy threads I didn't get to, but, it seems like the value > > of critical is going to neccessitate a Proxy-Require header. The draft > > makes no mention of the use of proxy-require or the protocol > > implications if the extension is not supported by proxies. The > > proxy-require can be removed once the services have been performed, > > which is a good thing. > > > > Proxy-Require would also make it difficult to have a privacy service > reside > more than one hop away from a client. I thought you had argued that it more or less HAS to be one hop away in order to properly authenticate it.... > But agreed that criticality is > severely hampered without something along these lines. This had been > discussed briefly (off the list, I think), but I don't think the > discussion > ever arrived at any conclusion. > > Throughout the draft the assumption is made that the user is aware of a > distinct privacy service in the network, with which they have some sort > of > relationship, through which calls will be routed. Arguably, without that > relationship a privacy service is of no value (that is, not just any > privacy > service will do - it must be one that is specifically known to the user > for > reasons of accountability). In that sense, the draft makes the (possibly > dangerous) assumption that no in-band feature negotiation is necessary - > the > user knows out-of-band that that the server in question supports > privacy. > Would be a pity if they were wrong. Big pity. > > As we've discussed before, this taps somewhat into the whole service > discovery/composition problem, one that we know isn't going to be > resolved > in the scope of this draft, anyway. I don't think we need to boil the ocean here. If the common case is the one where the privacy service is one hop away, and the user wants assurance that its really running there, Proxy-Require provides an easy way to determine that with no loss of functionality (it should strip the proxy-require). There are clear problems if its multiple hops away, and so perhaps its not used in that case, or perhaps it is, but at least its defined and available in order to get a high degree of assurance. > > Based on this, the third party privacy service would see the request > > before their actual provider. I can imagine there are also cases where > > the opposite makes more sense - the user registers their anonymous AOR > > as a contact address with their actual provider. TO me, this makes > more > > sense. You want the privacy function closest to the user; in the case > of > > responses, that means that you want it to be the first element that > gets > > the response, which would motivate registering the anonymous AOR as a > > contact with the actual provider. > > I think both approaches probably have their place. The approach I detail > above is more of a sort of anonymous callback' service; a user could > distribute a 'private' URI in the From field of requests they send. In > this > case the privacy service effectively becomes the registrar of the user. OK, so can the other case get documented here as well? > > I don't understand why section 5 is a separate section. Since its > about > > construct anonymous messages, it seems like it is naturally a > subsection > > of 4.1. This relates to my meta-comment about the verbosity of the > > draft; it reads a bit too much like a dialog, and not quite enough > like > > a protocol specification. Section 5 is really describing normative > > behavior for user agents, and belongs in the section which describes > > that. > > > > I suppose I felt that URI creation actually wasn't the exclusive > responsibility of user agents - privacy services also have some > responsibility for creating anonymous URIs. I really don't feel that > strongly about how the sections are arrayed. We ran into this issue a few times with bis, and decided to place the text within the context that first needed it, and then back-reference it from the other place. > > > When a privacy service performs one of the functions corresponding > to > > > a privacy level listed in the Privacy header, it SHOULD remove > the > > > corresponding priv-value from the Privacy header - otherwise, any > > > other privacy service involved with routing this message might > > > unnecessarily apply the same function, which in many cases would > be > > > undesirable. When the last priv-value (not counting 'critical') > has > > > been removed from the Privacy header, the entire Privacy header > MUST > > > be removed from a message. > > > > I am concerned about the complete removal of the privacy header. THe > > problem is that downstream elements may insert additional > identification > > information into the request. I would propose that a new value for the > > header be defined, say "no-add", which tells elements that they don't > > need to modify any headers, but that they should not add any further > > identification information to a request. If the header value was > present > > in a request, and is then performed by a proxy, the proxy changes that > > value to no-add. > > > > Agreed that parties downstream might add further information to the > request > - but these entities might not even support the Privacy extension at > all. Yup. Bad. > I'm not sure what we can really do to guard against this contingency. Well, if you had the proxy-require tag, you could have a privacy tag which instructed the last service to not strip proxy-require. This provides insanely high degrees of certainty, at a cost of interop. If the proxy-require is stripped, having the privacy tag still there at least helps in those proxies which DO understand this extension, so its still better than nothing. If, as we hope, this draft gets widely implemented, and every proxy supports it, you would hamper the ability to offer privacy functions to future extensions that might have proxies inserting information. As such, I feel quite strongly that some kind of privacy tag needs to get propagated all the way. > Maybe > this doesn't really come through in the text today (something I should > fix), > but I've been envisioning that users should try not to route the request > through intermediaries that are likely to add personal information > subsequent to the privacy service (by choosing appropriate preloaded > Route > header orders, perhaps). This argues a bit on the 'closeness' issue for > keeping your privacy service far away from you. Well, I don't know in general how the user would know ahead of times what route headers to use in order to avoid additional intermediaries... > > > > > Therefore, any time that a privacy service needs to modify any > > > dialog-matching headers for privacy reasons, it SHOULD act as a > > > transparent back-to-back user agent > > > > This was discussed on the list; the term transparent B2BUA is not > > defined in bis or in this document. You need to be more exact in your > > definitions. > > I'd hate to be defining that common term in this document... but, > agreed, > this section should be more explicit about the exact behavior required. > > > > IANA Considerations > > > > [snip] > > By the way, do we want to define a compact form? > > Um... I don't know, really. Any other opinions about that? I always have mixed feelings on compact form; arguably sigcomp makes it moot, but since we are approaching the mtu in many inter-proxy messages... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:32:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03969 for ; Fri, 31 May 2002 16:32:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03378 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:32:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01625; Fri, 31 May 2002 16:08:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01594 for ; Fri, 31 May 2002 16:08:50 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03467 for ; Fri, 31 May 2002 16:08:22 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 692A46A906; Fri, 31 May 2002 23:08:48 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 801936A905 for ; Fri, 31 May 2002 23:08:46 +0300 (EEST) Message-ID: <3CF7D893.9010702@piuha.net> Date: Fri, 31 May 2002 23:09:55 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: sip References: <933FADF5E673D411B8A30002A5608A0E03A63273@zrc2c012.us.nortel.com> <3CE0B7C0.C4A1F003@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=7.0 tests=TO_LOCALPART_EQ_REAL version=2.20 Content-Transfer-Encoding: 7bit Subject: [Sip] RTP, SIP, UDP, and IPv6 NUD Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm working on an informational document (draft-ietf-ipv6-cellular-host-02.txt) that discusses some issues related to IPv6 implementation on mobile terminals. IPv6 has a function for Neighbour Unreachability Detection (NUD, RFC 2461). The purpose of this function is to ensure that the nearest neighbour, typically the router, is up and running. This check is normally done at the IP layer, by sending a Neighbour Solicitation message and getting back a Neighbour Advertisement message. However, these messages are sometimes unnecessary if some upper layer already knows that we have connectivity. RFC 2461 specifies that the reception of a TCP acknowledgement for something that we have sent recently shows that we have connectivity to the peer, and consequently, to the router. Note that it isn't enough to see that we are *receiving* packets, we need to know if the packets we *sent* are getting through. Note also that any upper-layer advise to IPv6 is purely a local optimization and optional. Unfortunately, the TCP ACK scheme doesn't work with UDP, and this might lead to sending some unnecessary NS/NA messages when SIP and RTP traffic is running over UDP. As bandwidth usage on cellular environments is pretty critical, we'd like to do something about it. I've been asked to describe whether some typical cellular host applications can provide such feedback. And here's why I come to you, given that SIP and RTP-based IP traffic is a one of the major applications. My first question is if RTCP can provide the information. Does this work. (Yeah, I know its the wrong group but I'm subscribed here and I'm sure you know the answer.) When UDP is used for transporting RTP, the RTCP protocol feedback should be used as a basis for the reachability confirmation. If an RTCP packet is received with a reception report block indicating some packets have gone through, then packets are reaching the peer. If they have reached the peer, they have also reached the neighbour. The second question is if SIP can provide the information. Does this work: When UDP is used for transporting SIP, responses to SIP requests should be used as the confirmation that packets sent to the peer are reaching it. When the host is acting as the server side SIP node, such confirmation is generally not available. However, a host may interprete the receipt of a SIP ACK request as confirmation that the previously sent response to a SIP INVITE request has reached the peer. Thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:37:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04127 for ; Fri, 31 May 2002 16:37:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03717 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:38:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01938; Fri, 31 May 2002 16:14:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01907 for ; Fri, 31 May 2002 16:14:25 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03569 for ; Fri, 31 May 2002 16:13:56 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKFTYH028742; Fri, 31 May 2002 16:15:29 -0400 (EDT) Message-ID: <3CF7D980.6D30361D@dynamicsoft.com> Date: Fri, 31 May 2002 16:13:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Ben Campbell'" , "'sip@ietf.org'" Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general References: <70565611B164D511957A001083FCDD5601870382@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > > Does this require reserving anonymous.invalid to never resolve to > > something real? How would you enforce that? (Maybe a new TLD for > > "invalid" :-) ) > > Fortunately, RFC2606 beat us to it. Perhaps I should list this as a > reference. Yes. In fact, its normative in order to ensure exactly the property ben was worried about. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:43:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04207 for ; Fri, 31 May 2002 16:43:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03865 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:44:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02101; Fri, 31 May 2002 16:17:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02070 for ; Fri, 31 May 2002 16:17:50 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03631 for ; Fri, 31 May 2002 16:17:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKIsYH028745; Fri, 31 May 2002 16:18:54 -0400 (EDT) Message-ID: <3CF7DA4D.925D2F55@dynamicsoft.com> Date: Fri, 31 May 2002 16:17:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general References: <017c01c208dc$d0065b20$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > > > How does the user know whether privacy services are supported? Do > they > > > need to try it with Proxy-Require to see if the request fails? > > > > > > > The text above is meant to suggest that users should know out-of-band > that > > their local administrative domain supports a privacy service function. > > I too am quite concerned about this. It seems adaquate to say the UA > "just > knows" when we're talking about a P-Header with limited applicability, > but > not necessarily for a general purpose protocol mechanism. Right. > > However, this mechanism would use a Require header, not a Proxy-Require. > There are very few headers mentioned in this draft that RFC 3261 allows > a > proxy to modify or delete. I assert that performing any user, header or > session privacy functions in an intermediary turns the privacy service > into > a B2BUA. If the UA is aware that is sending to a privacy service then it > can > certainly be aware that it is sending to a B2BUA and include the tag in > its > Require header. Hmm. The problem is that you want get the desired effect if there are no privacy services on the path, and you thought there were. Inserting a Require: privacy in teh request would get the request all the way to the UAS, who then knows your identity, in addition to knowing that you wanted to be anonymous. Seems like the worst of all cases. So, while in theory, you might be right, practically speaking this has to be proxy-require to work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:49:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04296 for ; Fri, 31 May 2002 16:49:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04117 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:50:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02858; Fri, 31 May 2002 16:30:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02814 for ; Fri, 31 May 2002 16:30:15 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03863 for ; Fri, 31 May 2002 16:29:47 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKVFYH028761; Fri, 31 May 2002 16:31:15 -0400 (EDT) Message-ID: <3CF7DD32.43D6BE52@dynamicsoft.com> Date: Fri, 31 May 2002 16:29:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Elwell, John" CC: "'jh@lohi.eng.song.fi'" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity References: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C6@Beex50.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Elwell, John" wrote: > > I had assumed that any header that was to be removed would already have > been > removed at this point. However, looking at the rest of the text again, > this > is not clear. So how about: > > "The proxy MAY add a P-Asserted-Identity header field with either a > single > SIP URI or a single SIPS URI, provided there is not already a SIP URI or > SIPS URI present or replacing a SIP URI or SIPS URI from an untrusted > source. Likewise, the proxy MAY add a P-Asserted-Identity header field > with > a single tel URL, provided there is not already a tel URL present or > replacing a tel URL from an untrusted source." THis is still awkward. Might I suggest: If there is no P-Asserted-Identity header field present, a proxy MAY add one containing at most one SIP or SIP URIs, and at most one tel URL. If there is a P-Asserted-Identity header present, and it contains a SIP or SIP URI from an untrusted source, the proxy MAY replace that SIP or SIPS URI with a single SIP or SIP URI. If there is a P-Asserted-Identity header present, and it contains a tel URL from an untrusted source, the proxy MAY replace that tel URL with a single tel URL. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 16:50:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04339 for ; Fri, 31 May 2002 16:50:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04180 for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:51:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02180; Fri, 31 May 2002 16:19:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02151 for ; Fri, 31 May 2002 16:19:27 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03662 for ; Fri, 31 May 2002 16:18:59 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKKSYH028748; Fri, 31 May 2002 16:20:28 -0400 (EDT) Message-ID: <3CF7DAAB.F5DED92A@dynamicsoft.com> Date: Fri, 31 May 2002 16:18:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Elwell, John'" , "'sip@ietf.org'" Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general References: <70565611B164D511957A001083FCDD5601870387@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > On the first issue, yes, the examples in sip-asserted-identity go > against > this SHOULD in sip-privacy-general, with some good reasons. Perhaps > those > reasons could stand to be motivated a bit in the identity draft - but I > don't think this is the wrong behavior, anyway. > > On the second issue, the draft says if 'none' is present the privacy > service > MUST NOT perform any privacy function. The draft also says (section > 4.2): > "An intermediary MUST NOT modify the Privacy header in any way if the > 'none' > priv-value is already specified." So I think it should be clear that > Privacy > headers containing 'none' will not be removed. I think you should explicitly note this exception. In my experience, the more explicit you are in specs, the better. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 17:35:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05357 for ; Fri, 31 May 2002 17:35:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07519 for sip-archive@odin.ietf.org; Fri, 31 May 2002 17:35:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05497; Fri, 31 May 2002 17:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05437 for ; Fri, 31 May 2002 17:00:54 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04521 for ; Fri, 31 May 2002 17:00:24 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VL1oYH028796; Fri, 31 May 2002 17:01:51 -0400 (EDT) Message-ID: <3CF7E45C.E2C66BC4@dynamicsoft.com> Date: Fri, 31 May 2002 17:00:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Bob Penfield'" , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general References: <005c01c208e5$56c18010$1d036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > Hmm. The problem is that you want get the desired effect if > > there are no privacy services on the path, and you thought > > there were. Inserting a > > Require: privacy in teh request would get the request all the > > way to the UAS, who then knows your identity, in addition to > > knowing that you wanted to be anonymous. Seems like the worst > > of all cases. So, while in theory, you might be right, > > practically speaking this has to be proxy-require to work. > > And you have to KNOW you have a proxy in between, otherwise the remote > UA gets the Proxy-Require header AND your AI. Good point. > > Query -- is the presence of the Proxy-require header in a message > delivered to the remote UA in and of itself a privacy issue? They KNOW > you've requested privacy . . . The from field already says its anonymous (in all likelihood). So, I don't see a problem. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 17:40:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05406 for ; Fri, 31 May 2002 17:40:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07693 for sip-archive@odin.ietf.org; Fri, 31 May 2002 17:41:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04421; Fri, 31 May 2002 16:55:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04387 for ; Fri, 31 May 2002 16:55:56 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04458 for ; Fri, 31 May 2002 16:55:31 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4VKtC405361; Fri, 31 May 2002 15:55:12 -0500 From: "Dean Willis" To: "'Jonathan Rosenberg'" , "'Bob Penfield'" Cc: "'Peterson, Jon'" , Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general Date: Fri, 31 May 2002 15:54:21 -0500 Message-ID: <005c01c208e5$56c18010$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3CF7DA4D.925D2F55@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Hmm. The problem is that you want get the desired effect if > there are no privacy services on the path, and you thought > there were. Inserting a > Require: privacy in teh request would get the request all the > way to the UAS, who then knows your identity, in addition to > knowing that you wanted to be anonymous. Seems like the worst > of all cases. So, while in theory, you might be right, > practically speaking this has to be proxy-require to work. And you have to KNOW you have a proxy in between, otherwise the remote UA gets the Proxy-Require header AND your AI. Query -- is the presence of the Proxy-require header in a message delivered to the remote UA in and of itself a privacy issue? They KNOW you've requested privacy . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri May 31 18:02:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05694 for ; Fri, 31 May 2002 18:02:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08764 for sip-archive@odin.ietf.org; Fri, 31 May 2002 18:02:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07636; Fri, 31 May 2002 17:39:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07613 for ; Fri, 31 May 2002 17:39:23 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05394 for ; Fri, 31 May 2002 17:38:53 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VLeIYH028825; Fri, 31 May 2002 17:40:18 -0400 (EDT) Message-ID: <3CF7ED61.AE86452E@dynamicsoft.com> Date: Fri, 31 May 2002 17:38:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I hate to throw a wrench in here, but since we do have an oppty for another rev of the doc during ietf LC, I would like to voice an opinion. I don't believe that the hint should use the same header. My reasoning is simple. A header has a particular meaning. That meaning should be invariant to where that header appears, request or response, or any other conditions. We have been burned HARD by this one with the Contact header, which really has two different meanings depending on context. It was only much later on we realized that we needed both in the same request, but of course, its too late... P-Asserted-Identity should mean "this is the identity asserted by the trust domain for the originator of this message". Period. That is not at all the same thing as "this is the identity the end user would like you to use, assuming its one of the allowed identities for this user". In fact, there are vastly different trust implications for the two semantics. I can see right now a case where some misconfigured proxy forgets to strip the "hint" and all of a sudden it becomes a fraudulent call, since the hint was the identity of a different user. It wouldn't shock me either if one day down the road we find we do need both of these things in the same request. I don't care what you call it. But, its not P-Asserted-Identity. -Jonathan R. "Peterson, Jon" wrote: > > Since I've never been one to fly in the face of public opinion (cough), > I'll agree (at least in this case) that we should go with majority rule > and use the Asserted-Identity header for the 'hint'. > > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: Thursday, May 23, 2002 9:18 AM > To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy'; > sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > In the absence of further comment, can I make a *proposal* that we stick > with Asserted-Identity for the hint and for the NAI itself, and that > both are described in Cullen's draft ? > > Can we take this as AGREED if there are no comments by cob tomorrow ? > (Guidance sought from chairs on this second question). > > Updated requirements draft to be submitted first thing tomorrow. > > Regards...Mark > > > -----Original Message----- > > From: Andrew Allen [ mailto:AAllen@dynamicsoft.com > ] > > Sent: 22 May 2002 15:51 > > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'; > > 'Rohan Mahy'; sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > I agree with Dave. Lets put the hint in the > > asserted-identity. Lets not have > > two redundant headers that need to be transferred over the > > Radio interface > > unnecessarily. > > > > Andrew > > > > > -----Original Message----- > > > From: David R. Oran [ mailto:oran@cisco.com > ] > > > Sent: Wednesday, May 22, 2002 9:45 AM > > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > I suggest we allow the hint to be placed in the > > > asserted-identity rather > > > than in another header. A boundary proxy has to deal with a > > UA putting > > > in the header no matter what, if only to reject the request with an > > > error. > > > > > > Once we have a full solution the issue of hints should go > > > away as a side > > > effect of having the "authorization server" functionality that Jon > > > proposes. Better IMHO to have one obsolescent header to deal > > > with rather > > > than two, as well as avoiding the concomitant verbiage > > describing the > > > combinatoric cases involving two headers. > > > > > > Dave. > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org > ] On > > > > Behalf Of Mark Watson > > > > Sent: Wednesday, May 22, 2002 9:59 AM > > > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > Importance: High > > > > > > > > > > > > All, > > > > > > > > Can we have a *decision* asap as to whether the 'hint' uses > > > > Asserted-Identity, or another header in another draft. > > > > > > > > I do not mind which. If the latter I will publish an I-D > > > > describing it as soon as we have a decision, assuming it is > > > > this week, since I'm away next week. > > > > > > > > If we do nothing, then I guess 3GPP will make up its own mind > > > > how to do this, without supervision or advice from IETF, > > > > which I think would be a bad thing. > > > > > > > > Regards...Mark > > > > > > > > > > > > -----Original Message----- > > > > From: Watson, Mark [MDN05:EP10:EXCH] > > > > Sent: 20 May 2002 12:08 > > > > To: 'Peterson, Jon'; 'Rohan Mahy' > > > > Cc: sip@ietf.org > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > The 'hint' was one of the three requirements that 3GPP > > > > communicated to us in April. > > > > It is a separate requirement from the Network Asserted > > > > Identity itself, and so is not addressed in the requirements > > > > draft, although I have been careful to point this out, and to > > > > point out that it is a requirement nontheless, on several > > > > occasions. I believe we need the 'hint' in the same timeframe > > > > as the rest of the short term work. > > > > Whether it is the same header/draft or a different > > > > header/draft is another question on which I will only say > > > > that we'd better make up our minds pretty quick. ...Mark > > > > > > > > > > > > > -----Original Message----- > > > > > From: Peterson, Jon [ mailto:jon.peterson@neustar.biz > ] > > > > > Sent: 19 May 2002 18:11 > > > > > To: 'Rohan Mahy' > > > > > Cc: sip@ietf.org > > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > > > > > > > > > My argument was not that the proposed hint won't work - just > > > > > that it isn't > > > > > necessary to solve the problem at hand. It might not be the > > > > > case that the > > > > > problems with the hint stop at the philosophical point you > > > > > mention below. > > > > > What I asked in my last mail was not whether or not we needed > > > > > a hint, but > > > > > rather whether or not we should table that question until we > > > > > resolve the > > > > > other questions at hand. I just don't want to spend the > > > > > cycles arguing about > > > > > the hint given our very aggressive timetable - frankly, I > > > > think that > > > > > reaching consensus on this hint matter might push back our > > > > > dates a bit. > > > > > Let's investigate this hint stuff in June, but for now just > > > > > figure out how a > > > > > Trust Domain can manage an asserted identity in a message. > > > > > > > > > > Jon Peterson > > > > > NeuStar, Inc. > > > > > > > > > > > -----Original Message----- > > > > > > From: Rohan Mahy [ mailto:rohan@cisco.com > ] > > > > > > Sent: Sunday, May 19, 2002 8:29 AM > > > > > > To: Peterson, Jon > > > > > > Cc: sip@ietf.org > > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > The requirement for a hint is well understood, limited in > > > > > > scope, and well motivated in the draft. Nobody has > > identified > > > > > > any technical reason why the hint won't work. Your argument > > > > > > that allowing a hint weakens the strength of the language on > > > > > > ignoring Asserted-Identity from untrusted parties is purely > > > > > > philosophical in nature. I don't buy your argument. > > > > > > > > > > > > thanks, > > > > > > -rohan > > > > > > > > > > > > > > > > > > ---- Original message ---- > > > > > > >Date: Fri, 17 May 2002 16:02:11 -0500 > > > > > > >From: "Peterson, Jon" > > > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'? > > > > > > >To: "'sip@ietf.org'" > > > > > > > > > > > > > > > > > > > > >In the course of the discussion between Mark Watson, Cullen > > > > > > Jennings and > > > > > > >myself about the short-term identity work, we have returned a > > > > > > > few times to > > > > > > >the question of the infamous hint. This hint is, of course, a > > > > > > > way that a > > > > > > >user agent (one that is not a member of the Trust Domain in > > > > > > the short-term > > > > > > >network asserted identity space) can provide a 'hint' to the > > > > > > intermediary > > > > > > >that will generate an Asserted-Identity indicating which > > > > > > identity among > > > > > > >several possibilities should be asserted. > > > > > > > > > > > > > >The need for this arises particularly from the 3G space, in > > > > > > which the > > > > > > >authentication process takes place independently of SIP and > > > > > > does not carry > > > > > > >this sort of personal identity information. It also assumes > > > > > > that the > > > > > > >operators of the intermediary in question are aware of > > > > > > several legitimate > > > > > > >identities which the user can elect to assert. > > > > > > > > > > > > > >It has been proposed on the mailing list and > > elsewhere that the > > > > > > >Asserted-Identity header should be re-used by user agents > > > > > > outside the Trust > > > > > > >Domain to provide such a hint. I see a number of reasons for > > > > > > and against > > > > > > >using the Asserted-Identity for this purpose. For example, > > > > > > today, there is a > > > > > > >requirement that asserted-identities which are transmitted > > > > > > from untrusted > > > > > > >sources should not be used in any way - this would seem to > > > > > > weaken that > > > > > > >requirement. There is also possibly some behavior that still > > > > > > needs to be > > > > > > >specified (like how an intermediary would reject or otherwise > > > > > > > handle a > > > > > > >request with an inappropriate hint) that might be impactful > > > > > > to our choice. > > > > > > > > > > > > > >For the time being, however, I would like to suggest that > > > > > > providing the hint > > > > > > >is outside the scope of the current deliverables (the > > > > > > asserted-identity > > > > > > >requirements and mechanism drafts), which need to be > > > > > > complete, as we > > > > > > >discussed in the interim meeting, by the end of this month. I > > > > > > > believe that a > > > > > > >separate draft should propose the use of Asserted-Identity or > > > > > > > any other > > > > > > >header for this hint (in whatever timeframe is appropriate > > > > > > for 3G's > > > > > > >requirements), but that we should not speak to this matter in > > > > > > > the current > > > > > > >asserted-identity deliverables. There is, as I see it, no > > > > > > dependency on > > > > > > >defining this hint before we dictate how intermediaries will > > > > > > assert > > > > > > >identities. > > > > > > > > > > > > > >Any comments on this plan? > > > > > > > > > > > > > >Jon Peterson > > > > > > >NeuStar, Inc. > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > > >This list is for NEW development of the core SIP Protocol > > > > > > >Use sip-implementors@cs.columbia.edu for questions on > > > > current sip > > > > > > >Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip