From root@core3.amsl.com Wed Sep 2 03:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7AA113A69E9; Wed, 2 Sep 2009 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090902101501.7AA113A69E9@core3.amsl.com> Date: Wed, 2 Sep 2009 03:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-presence-scaling-requirements-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:15:01 -0000 --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 Core Working Group of the IETF. Title : Scaling Requirements for Presence in SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-sipcore-presence-scaling-requirements-02.txt Pages : 9 Date : 2009-09-02 The document lists requirements for optimizations of SIP/SIMPLE. These optimizations should reduce the load on the network and the presence servers due to inter-domain presence subscriptions. The need for the requirements is based on a separate document that provides scaling analysis for inter-domain presence over SIP/SIMPLE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-presence-scaling-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-02030404.I-D@ietf.org> --NextPart-- From adam@nostrum.com Wed Sep 2 12:09:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D59828C0CE for ; Wed, 2 Sep 2009 12:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPdJDnfF0DSu for ; Wed, 2 Sep 2009 12:09:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5939C3A6971 for ; Wed, 2 Sep 2009 12:09:22 -0700 (PDT) Received: from [172.16.3.81] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n82J9Zms001469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2009 14:09:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A9EC2EF.40508@nostrum.com> Date: Wed, 02 Sep 2009 14:09:35 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------030705080007030705040505" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] [Fwd: Nomcom 2009-10: Reminder Call for Nominations, Local Office hours, Nominee Questionnaires available] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:09:24 -0000 This is a multi-part message in MIME format. --------------030705080007030705040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] Sipcorers: The nomcom process is a very important part of maintaining quality leadership within the IETF. Please take a moment to read the attached email and take action as you feel appropriate. Thanks. /a -------- Original Message -------- Subject: Nomcom 2009-10: Reminder Call for Nominations, Local Office hours, Nominee Questionnaires available Date: Mon, 31 Aug 2009 15:23:03 -0700 (PDT) From: Mary Barnes To: IETF Announcement list CC: ietf@ietf.org Hi all, This email covers 3 topics: 1) Reminder: Call for Nominations 2) New: Local Office Hours 3) New: Questionnaires available for nominees Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =============================================================================== 1) Call for Nominations ------------------------ The nomination period ends in less than 3 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours ----------------------- In order to facilitate additional feedback, the Nomcom is planning to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders before the deadline. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------030705080007030705040505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

Sipcorers:

The nomcom process is a very important part of maintaining quality leadership within the IETF. Please take a moment to read the attached email and take action as you feel appropriate. Thanks.

/a

-------- Original Message --------
Subject: Nomcom 2009-10: Reminder Call for Nominations, Local Office hours, Nominee Questionnaires available
Date: Mon, 31 Aug 2009 15:23:03 -0700 (PDT)
From: Mary Barnes <mary.barnes@nortel.com>
To: IETF Announcement list <ietf-announce@ietf.org>
CC: ietf@ietf.org 


Hi all,

This email covers 3 topics:
1) Reminder: Call for Nominations
2) New: Local Office Hours
3) New: Questionnaires available for nominees 

Best Regards, 
Mary Barnes
nomcom-chair@ietf.org
mary.h.barnes@gmail.com
mary.barnes@nortel.com


===============================================================================
1) Call for Nominations
------------------------
The nomination period ends in less than 3 weeks on Sept. 18th, 2009. We
appreciate the folks that have taken the time to make nominations thus
far. But, we do need more nominations. Please use the online tool to
nominate - it's easy and secure:
https://wiki.tools.ietf.org/group/nomcom/09/nominate

Details on the open positions, as well as other details and options for
making nominations are available on the Nomcom homepage:
https://wiki.tools.ietf.org/group/nomcom/09/

Please consider that the sooner you make the nominations, the more time
your nominee(s) will have to complete the necessary questionnaire (item 3
below).  As well, please consider nominating more than one person for a
particular position. You will have the opportunity to provide additional
feedback later and it's important to consider that not all nominees will
be able to accept the nomination. 


2) Local office hours
-----------------------

In order to facilitate additional feedback, the Nomcom is planning to
make themselves available for office areas at various geographic locations
for 3 weeks in September, starting on the 8th. 

Below please find the list of locations where Nomcom members will be
available for these f2f meetings . Unless dates are identified below, the
Nomcom member is generally available for part of the day during the weeks
of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than
English in which the Nomcom member is fluent are identfied.  

Please contact a Nomcom member in a specific geographic location to
arrange a convenient meeting time and place. Most Nomcom members are
flexible as to meeting locations - i.e., we can travel to your office,
meet at our offices or somewhere in between.  

As a reminder folks can always contact any Nomcom member to provide
feedback at anytime - i.e., you don't need to participate in these f2f
sessions to provide feedback. 


Belgium: 
     Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept
21-25) (Languages: French) 

Boston, Mass, USA:  
     Stephen Kent - kent@bbn.com  (Sept 16-18) 

Boulder, CO, USA: 
     Wassim Haddad - wmhaddad@gmail.com (Sept 14-18)

Dallas/Ft. Worth, TX, USA:  
     Mary Barnes  - mary.h.barnes@gmail.com 
     Lucy Yong - lucyyong@huawei.com  (Languages: Chinese) 

Helsinki, Finland: 
      Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish)
 

Ithaca, NY, USA: 
      Scott Brim - scott.brim@gmail.com

Montevideo, Uruguay: 
      Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages:
Spanish, Portuguese) 

Montreal, Quebec, Canada 
     Wassim Haddad - wmhaddad@gmail.com (Sept 8-11)
     -- Can also be available in Ottawa if folks are interested 

Paris, France: 
      Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be
(Sept 15-18)  (Languages: French)

San Diego, CA, USA: 
      Randall Gellens - rg+ietf@qualcomm.com   
      Dave Crocker - dcrocker@bbiw.net  (Sept 16-18)

Silicon Valley/SF Bay,  CA, USA: 
      Dave Crocker - dcrocker@bbiw.net  (Sept 8-11, Sept 14-15, Sept
21-25)   
      Dorothy Gellert - Dorothy.gellert@gmail.com

3) Questionnaires available for nominees: 

For folks that have been notified that they have been nominated for any
of the positions, the questionnaires are now available on the Nomcom09
tools website:
https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire
https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire
https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire

If you have any questions, please let me know. I will be contacting
everyone individually, as well as sending reminders before the deadline. 


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--------------030705080007030705040505-- From oej@edvina.net Thu Sep 3 08:02:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5763A6D48 for ; Thu, 3 Sep 2009 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2HpR-ArdQ6P for ; Thu, 3 Sep 2009 08:02:02 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 179B43A6D5E for ; Thu, 3 Sep 2009 08:01:59 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id EC4AA28433; Thu, 3 Sep 2009 16:44:36 +0200 (CEST) Message-Id: From: "Olle E. Johansson" To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Sep 2009 17:00:07 +0200 References: <8376427F-05D6-483B-A5B2-EE20751A8B03@edvina.net> X-Mailer: Apple Mail (2.936) Subject: [sipcore] Fwd: draft-ietf-sipcore-sec-flows-00 :: Feedback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:02:03 -0000 I haven't gotten any feedback on my feedback, but that may be the way =20= it should be. I'm just curious on who's taking care of the progress of =20= this document. Regards, /O Vidarebefordrat brev: > Fr=E5n: "Olle E. Johansson" > Datum: on 5 aug 2009 13.39.28 GMT+02:00 > Till: SIPCORE > =C4mne: [sipcore] draft-ietf-sipcore-sec-flows-00 :: Feedback > > I vaguely remember that Adam mentioned this draft at the IETF75 =20 > meeting... ;-) > > Here's a few comments from someone who hasn't followed previous =20 > discussion on it: > > A bit more of education needed > ------------------------------------------ > I think that since the area of security in SIP is covered in =20 > multiple documents that are hard to navigate through, this document =20= > needs to act a bit more as a hitchhiker's guide for both developers =20= > and implementors - administrators of servers. Currently it requires =20= > a great deal of TLS/PKI knowledge to be useful, something I humbly =20 > suggest we should try to work around, to lower the bar. We actually =20= > want people to implement this, and to do it correctly. > > The document starts quickly and the reader is lost in section 4.1 =20 > where we throw a text encoding of a CA certificate in his face. The =20= > really important information is hidden in section 7 and 8 after page =20= > up and down with various encoding schemes that for most people will =20= > look and feel like a strange Swedish dialect from Kn=E4ckebr=F6dshult...= =20 > Can we restructure and move these sections up front? > > Relationship between server host name, served domain and SRV/NAPTR =20 > records needs to be explained > = --------------------------------------------------------------------------= -------------------------------------------------------------------- > Even though this is propably explained in five other documents, I =20 > think we could clarify this a bit. > > - how does one host serve multiple domains? Is this reflected at all =20= > in the server certificate? > - If SRV for example.com points to stockholm.example.com - which CN =20= > and which subjAltName should be used? > > The example used for domain "example.com" with hostname =20 > "example.com" is avoiding this... > > Explain the certificate request (CSR) > ------------------------------------------------- > In the real world, not in developer labs, the procedure for creating =20= > the key pair and generating a CSR on the host and the actual routine =20= > that signs and produces a certificate are two different procedures. =20= > This is not covered at all in this draft. In order to get the =20 > necessary Subject Alternative Names in the cert, and the EKU =20 > information, the CSR needs to reflect that. If you parse the scripts =20= > and the OpenSSL config file in the back, you can find out how this =20 > fits together. I think it would help all of us to actually have some =20= > examples of the parsed CSR as well to clearly explain the procedure. > > > Small changes > -------------------- > > Page 4, section 1: > > ..."this document provides a common certificate that can be"... I =20 > would change that to > ..."this document provides a common certificate and private key that =20= > can be"... > > Page 5, section 4.1 > > "Note that the basic constraints allow it to be used as a CA" > -> "Note that the X.509v3 Basic Constraints in the certificate =20 > allows it to be used as a CA, certificate authority." > > > I would insert a sentence at the end: > > "This certificate is used to verify client and host certificates, =20 > it's not used directly in the TLS call flow." > > Page 10, Section 4.3 - User certs > > "This is necessary for interoperating with CPIM gateway" > Now, english is not my native language, but I want a small "a" =20 > before "CPIM" ;-) > > I would change the first sentence to: > > "The user certificate, used in many apps, for fluffy@example.com is =20= > shown below" > > This would explain why we have other apps and data in there and also =20= > point out that one user cert can be used for many different apps. > > Also, the last sentence: > > "Note that the X509v3 Extended Key Usage attribute refers to the SIP =20= > OID introduced in [12] - 1.3.6.1.5.5.7.3.20 > > Page 28, section 7 > > The last paragraph seems to be about S/MIME but it doesn't say so. I =20= > think that could be clarified. > > Page 33 > > "These could be in two PEM files or one .p12 file." > > Many servers actually has both PEM sections - the private key and =20 > the cert - in one combined file. Yes, it's confusing, but it's done. > > ------- > Well, that was the result of reading and drinking a Nice Cup of Tea =20= > (TM) :-) > > /Olle > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From richard@shockey.us Fri Sep 4 13:05:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D262A3A6A72 for ; Fri, 4 Sep 2009 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DujgvJxmdXDl for ; Fri, 4 Sep 2009 13:05:40 -0700 (PDT) Received: from outbound-mail-102.bluehost.com (outbound-mail-102.bluehost.com [69.89.22.12]) by core3.amsl.com (Postfix) with SMTP id 620D23A67ED for ; Fri, 4 Sep 2009 13:05:40 -0700 (PDT) Received: (qmail 3865 invoked by uid 0); 4 Sep 2009 20:06:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 4 Sep 2009 20:06:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=bijHYAljBqXUuyUwSgYAM1gJTyQXamE9F8ElivtDrFHen3PjRJviIb7I2w+lpiAlm6Ay9aWBTASXCQ7MlzD6v+15R6RcG4jwgQ5GKe2Uxnew9EhQseDArYUF6N3isSoI; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mjf2n-0001FJ-Bp; Fri, 04 Sep 2009 14:06:01 -0600 From: "Richard Shockey" To: , Date: Fri, 4 Sep 2009 16:05:53 -0400 Message-ID: <01a201ca2d9b$1c05bf80$54113e80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcotmxrGGabvJ0eaS8WejQ+OiCHZZQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [sipcore] Results of a SIPforum effort to understand problems with Fax and SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 20:05:41 -0000 The SIPforum has recently issued a report on ongoing issues with SIP and Fax that may be of interest to the larger SIP community. Work on understanding the problems with FAX and SIP are continuing and members of the IETF SIP community are invited to participate in future discussions. SIPforum FoIP Task Group Charter The proposed charter of the SIP Forum FoIP task group is to investigate ongoing issues with the deployment of fax services, specifically ITU T.38, in SIP networks. SIP networks cannot adequately replace analog PSTN in enterprises unless essential services such as FAX are accommodated. The use of ITU T.37 email based store and forward has not been successful due to the specific legal status fax enjoys in law and that fax communications has 3rd party confirmation of transmission and/or delivery in carrier billing records (non repudiation). Classic FAX (T.30) over G.711 has not proved to be reliable and SIP communications , in the future, may use other codecs that have been proven to break T.30 such as G.729 and other high compression codecs like SPEEDEX etc. The SIP Forum FoIP task group is chartered to accomplish the following tasks: 1. Fully document what the current issues are surrounding ITU T.38 in SIP networks. a. What interoperability testing procedures currently exist. b. What are the common factors in T.38 failure such as page length or lack of ECM support in carrier gateways and ATA's. c. Network packet loss considerations. 2. Determine what solutions are currently available to address the problem. 3. Determine if the problem can be solved within the scope of existing IETF SIP and ITU T.38 Recommendations. 4. If the problems can be solved using existing standards by tightening requirements, document the procedures vendors and carriers need to implement in an appropriate SIP Forum Technical Recommendation. 5. If, in the judgment of the SIP Forum FoIP WG, existing IETF and or ITU standards need to be modified, develop a strongly worded recommendation to the appropriate Standards Development Organization (SDO) on what the SIP Forum FoIP WG has discovered and recommend appropriate action by the SDO to remedy the issue. Information about the FoIP Task Group http://www.sipforum.org/content/view/310/252/ The Fax Problem Statement Report. http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,30 3/Itemid,75/ Richard Shockey Member Board of Directors SIPforum Co-Chair SIPforum Technical Task Groups PSTN Mobile: +1 703.593.2683 skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 From brian@estacado.net Tue Sep 8 12:04:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6413A67AC for ; Tue, 8 Sep 2009 12:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSrWYNeUV7T1 for ; Tue, 8 Sep 2009 12:04:16 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 800B13A6831 for ; Tue, 8 Sep 2009 12:04:12 -0700 (PDT) Received: from dn3-229.estacado.net (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n88J4alR040593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 14:04:36 -0500 (CDT) (envelope-from brian@estacado.net) Message-Id: From: Brian Hibbard To: "Olle E. Johansson" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 14:04:31 -0500 References: <8376427F-05D6-483B-A5B2-EE20751A8B03@edvina.net> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] Fwd: draft-ietf-sipcore-sec-flows-00 :: Feedback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:04:17 -0000 Hello Olle, Thank you very much for your feedback. Unfortunately, there is no =20 prize for being the first and only reviewer so far. I apologize for =20 taking so long to respond. For the time being, I am the custodian of =20= the draft. Please see my comments below. -Brian On Sep 3, 2009, at 10:00 AM, Olle E. Johansson wrote: > I haven't gotten any feedback on my feedback, but that may be the =20 > way it should be. I'm just curious on who's taking care of the =20 > progress of this document. > > Regards, > /O > > Vidarebefordrat brev: > >> Fr=E5n: "Olle E. Johansson" >> Datum: on 5 aug 2009 13.39.28 GMT+02:00 >> Till: SIPCORE >> =C4mne: [sipcore] draft-ietf-sipcore-sec-flows-00 :: Feedback >> >> I vaguely remember that Adam mentioned this draft at the IETF75 =20 >> meeting... ;-) >> >> Here's a few comments from someone who hasn't followed previous =20 >> discussion on it: >> >> A bit more of education needed >> ------------------------------------------ >> I think that since the area of security in SIP is covered in =20 >> multiple documents that are hard to navigate through, this document =20= >> needs to act a bit more as a hitchhiker's guide for both developers =20= >> and implementors - administrators of servers. Currently it requires =20= >> a great deal of TLS/PKI knowledge to be useful, something I humbly =20= >> suggest we should try to work around, to lower the bar. We actually =20= >> want people to implement this, and to do it correctly. >> >> The document starts quickly and the reader is lost in section 4.1 =20 >> where we throw a text encoding of a CA certificate in his face. The =20= >> really important information is hidden in section 7 and 8 after =20 >> page up and down with various encoding schemes that for most people =20= >> will look and feel like a strange Swedish dialect from =20 >> Kn=E4ckebr=F6dshult... Can we restructure and move these sections up =20= >> front? >> >> Relationship between server host name, served domain and SRV/NAPTR =20= >> records needs to be explained >> = --------------------------------------------------------------------------= -------------------------------------------------------------------- >> Even though this is propably explained in five other documents, I =20 >> think we could clarify this a bit. >> >> - how does one host serve multiple domains? Is this reflected at =20 >> all in the server certificate? >> - If SRV for example.com points to stockholm.example.com - which CN =20= >> and which subjAltName should be used? >> >> The example used for domain "example.com" with hostname =20 >> "example.com" is avoiding this... >> >> Explain the certificate request (CSR) >> ------------------------------------------------- >> In the real world, not in developer labs, the procedure for =20 >> creating the key pair and generating a CSR on the host and the =20 >> actual routine that signs and produces a certificate are two =20 >> different procedures. This is not covered at all in this draft. In =20= >> order to get the necessary Subject Alternative Names in the cert, =20 >> and the EKU information, the CSR needs to reflect that. If you =20 >> parse the scripts and the OpenSSL config file in the back, you can =20= >> find out how this fits together. I think it would help all of us to =20= >> actually have some examples of the parsed CSR as well to clearly =20 >> explain the procedure. These are good ideas, but my understanding is that this draft is not =20 intended to be tutorial in nature. It is intended only to provide =20 concrete reference examples. A new tutorial document would probably =20 be helpful and well received by the community, but the SIP Sec Flows =20= draft does not purport to be that document. Is this OK with you? >> >> >> Small changes >> -------------------- >> >> Page 4, section 1: >> >> ..."this document provides a common certificate that can be"... I =20 >> would change that to >> ..."this document provides a common certificate and private key =20 >> that can be"... >> >> Page 5, section 4.1 >> >> "Note that the basic constraints allow it to be used as a CA" >> -> "Note that the X.509v3 Basic Constraints in the certificate =20 >> allows it to be used as a CA, certificate authority." >> >> >> I would insert a sentence at the end: >> >> "This certificate is used to verify client and host certificates, =20 >> it's not used directly in the TLS call flow." >> >> Page 10, Section 4.3 - User certs >> >> "This is necessary for interoperating with CPIM gateway" >> Now, english is not my native language, but I want a small "a" =20 >> before "CPIM" ;-) >> >> I would change the first sentence to: >> >> "The user certificate, used in many apps, for fluffy@example.com is =20= >> shown below" >> >> This would explain why we have other apps and data in there and =20 >> also point out that one user cert can be used for many different =20 >> apps. >> >> Also, the last sentence: >> >> "Note that the X509v3 Extended Key Usage attribute refers to the =20 >> SIP OID introduced in [12] - 1.3.6.1.5.5.7.3.20 >> >> Page 28, section 7 >> >> The last paragraph seems to be about S/MIME but it doesn't say so. =20= >> I think that could be clarified. >> >> Page 33 >> >> "These could be in two PEM files or one .p12 file." >> >> Many servers actually has both PEM sections - the private key and =20 >> the cert - in one combined file. Yes, it's confusing, but it's done. These all sound good. I will go make these changes. >> >> ------- >> Well, that was the result of reading and drinking a Nice Cup of Tea =20= >> (TM) :-) >> >> /Olle >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Sep 8 13:06:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8098428C2E7 for ; Tue, 8 Sep 2009 13:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dr9EmSJRwDH for ; Tue, 8 Sep 2009 13:06:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AFD8B28C1AB for ; Tue, 8 Sep 2009 13:06:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-c4-4aa6b96a4a53 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F6.CB.06532.B69B6AA4; Tue, 8 Sep 2009 22:07:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 22:07:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA30BF.F05BAB5E" Date: Tue, 8 Sep 2009 22:07:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3265bis: 200, 202 and filters Thread-Index: Acowv/CUQL83E9/bTdu6uBjjgk/2Dg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 08 Sep 2009 20:07:06.0545 (UTC) FILETIME=[F0827A10:01CA30BF] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] 3265bis: 200, 202 and filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:06:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA30BF.F05BAB5E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When reading section 3.3.4 of RFC 4660 it seems that, when the filter mechanism is used, 200 and 202 responses have different meaning to the subscriber: 200 means that the filter was accepted, while 202 means that the filter has yet not been accepted. (The RFC does not explicitly say how the client will find out in case of forking (the client never gets the 200/202), but I assume it will figure it out based on whether the NOTIFY contains state information or not?) In any case, in 3265bis, would we need to say that subscription extensions CAN define usages of both 200 and 202, event if the default would be to always use 202? Are there any other extensions with similar issues?=20 Regards, Christer ------_=_NextPart_001_01CA30BF.F05BAB5E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3265bis: 200, 202 and filters

Hi,

When reading section 3.3.4 of RFC 4660 = it seems that, when the filter mechanism is used, 200 and 202 responses = have different meaning to the subscriber: 200 means that the filter was = accepted, while 202 means that the filter has yet not been = accepted.

(The RFC does not explicitly say how = the client will find out in case of forking (the client never gets the = 200/202), but I assume it will figure it out based on whether the NOTIFY = contains state information or not?)

In any case, in 3265bis, would we need = to say that subscription extensions CAN define usages of both 200 and = 202, event if the default would be to always use 202?

Are there any other extensions with = similar issues?

Regards,

Christer

------_=_NextPart_001_01CA30BF.F05BAB5E-- From adam@nostrum.com Tue Sep 8 13:30:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DBA28C333 for ; Tue, 8 Sep 2009 13:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiBLmWlz08P7 for ; Tue, 8 Sep 2009 13:30:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A9BC928C325 for ; Tue, 8 Sep 2009 13:30:10 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n88KUc70024296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Sep 2009 15:30:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AA6BEEE.3040006@nostrum.com> Date: Tue, 08 Sep 2009 15:30:38 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020204010006060005050605" Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Subject: Re: [sipcore] 3265bis: 200, 202 and filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:30:12 -0000 This is a multi-part message in MIME format. --------------020204010006060005050605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/8/09 15:07, Sep 8, Christer Holmberg wrote: > > When reading section 3.3.4 of RFC 4660 it seems that, when the filter > mechanism is used, 200 and 202 responses have different meaning to the > subscriber: 200 means that the filter was accepted, while 202 means > that the filter has yet not been accepted. > The behavior of 202 in 4660 is consistent with that of 202 in 3265. And, because it suffers the forking problem, it's equally useless. I don't think discouraging the sending of 202 in 3265bis will impact 4660 implementations negatively. /a --------------020204010006060005050605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/8/09 15:07, Sep 8, Christer Holmberg wrote:
3265bis: 200, 202 and filters

When reading section 3.3.4 of RFC 4660 it seems that, when the filter mechanism is used, 200 and 202 responses have different meaning to the subscriber: 200 means that the filter was accepted, while 202 means that the filter has yet not been accepted.


The behavior of 202 in 4660 is consistent with that of 202 in 3265. And, because it suffers the forking problem, it's equally useless. I don't think discouraging the sending of 202 in 3265bis will impact 4660 implementations negatively.

/a
--------------020204010006060005050605-- From adam@nostrum.com Tue Sep 8 15:45:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925923A6A11 for ; Tue, 8 Sep 2009 15:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krtyI6sefeSa for ; Tue, 8 Sep 2009 15:45:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id ABED43A689E for ; Tue, 8 Sep 2009 15:45:45 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n88Mk0r8034304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 17:46:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AA6DEA7.7090403@nostrum.com> Date: Tue, 08 Sep 2009 17:45:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: sipcore@ietf.org References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: Jonathan Lennox , Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 22:45:48 -0000 Just a quick reminder that we discussed this vigorously in Stockholm without reaching any conclusion. To help spur things along, here's a summary of the arguments made during that discussion: http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue%201:%20AOR%20tag Please resume discussion on the list, and see if we can reach any sort of rough agreement. /a From dean.willis@softarmor.com Tue Sep 8 16:26:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081743A6A05 for ; Tue, 8 Sep 2009 16:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg2hBsmRQn1o for ; Tue, 8 Sep 2009 16:26:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 253883A6A87 for ; Tue, 8 Sep 2009 16:26:48 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n88NRHBb030526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 8 Sep 2009 18:27:18 -0500 Message-Id: From: Dean Willis To: SIPCORE In-Reply-To: <4AA6DEA7.7090403@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 18:27:11 -0500 References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> X-Mailer: Apple Mail (2.936) Subject: [sipcore] [DW] What is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 23:26:49 -0000 On Sep 8, 2009, at 5:45 PM, Adam Roach wrote: > Just a quick reminder that we discussed this vigorously in Stockholm > without reaching any conclusion. To help spur things along, here's a > summary of the arguments made during that discussion: > > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue > %201:%20AOR%20tag > > Please resume discussion on the list, and see if we can reach any > sort of rough agreement. AORs might be used as targets for initial requests that are rerouted or retargeted by contact routing or tabular translation. AORs might be the identity bindings attached to GRUUs (see sections 1, 3, and 5 of draft-ietf-sip-gruu-15). AORs might or might not be human-readable and likley to appear on business cards. None of these definitions effectively differentiates AORs from other URIs. I propose instead that an AOR is a SIP URI for which it is reasonable to expect that an authentication service would issue an identity certification, should an authentication service be in operation for the domain in question. This might include RFC 4474 authentication, DIGEST authentication at a registrar, proxy, or gateway, P-Asserted- Identity as in RFC 3325 and IMS, or any similar certification of identity arranged through an enrollment process. One might argue that in a simplistic non-authenticating proxy- registrar that the registration action (which associates a Contact with the To: URI of the request) forms the minimal identity certification needed for this definition. Correspondingly, a systems configuration with similar effect that statically configures a rerouting or retargeting destination relative to an input URI forms a comparable minimal identity certification. Further, acceptance of an AOR as a terminal value at a SIP UA selected through conventional routing (as in RFC 3263) resolution mechanisms would constitute a minimal identity certification. Another wording would make an AOR the input member of any (input, output) tuple wherein a SIP transformation operation transforms (either reroutes or retargets) the input URI such that the output URI is selected, OR where an authentication operation is performed on the input member (and especially where the two operations are combined).. The output URI may also be an AOR, but only if it participates as an input member into a transformation or authentication operation. We might do well to speak of the "strength" of an AOR as a product of the strength of the identity certification. For example, an an AOR for which RFC 4474 identity certification is available would be "stronger" than one resolved strictly through RFC 3263 resolution. This doesn't affect the definition of an AOR, but might affect how one would react to that AOR within an authorization system. -- Dean From pkyzivat@cisco.com Tue Sep 8 21:12:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F47F3A6862 for ; Tue, 8 Sep 2009 21:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1jv3o5rUAax for ; Tue, 8 Sep 2009 21:12:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 305FA3A67A1 for ; Tue, 8 Sep 2009 21:12:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALPHpkpAZnme/2dsb2JhbADFJohDAZArBYIugWo X-IronPort-AV: E=Sophos;i="4.44,356,1249257600"; d="scan'208";a="57267859" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Sep 2009 04:12:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n894CcVx005343; Wed, 9 Sep 2009 00:12:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n894CcQ4015088; Wed, 9 Sep 2009 04:12:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 00:12:38 -0400 Received: from [10.86.252.180] ([10.86.252.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 00:12:37 -0400 Message-ID: <4AA72B32.9070000@cisco.com> Date: Wed, 09 Sep 2009 00:12:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2009 04:12:37.0503 (UTC) FILETIME=[C3E9E8F0:01CA3103] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3554; t=1252469558; x=1253333558; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20[DW]=20What=20is=20an=20AoR ? |Sender:=20 |To:=20Dean=20Willis=20; bh=5Vw+nAoa4J4yHx+gx597VDALmp1l4bdQgAfAR4V4NnY=; b=GeqyzmwpTE7PBq1f5zyqO5X4xRmUdXdpf9DtAOzlTJiSPhJL81Aw6iau20 NpJuJQTd/6kWkWjT1LgAR2JWDVqtDVwnD+KJOzM8Ni4RbJzjchcHz5fenWVl z71mZgFs7R; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] [DW] What is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 04:12:08 -0000 Its really interesting that this term, which has been ubiquitous in the sip world for so long should turn out to be so hard to define thoroughly. :-( I kind of like Dean's idea of tying this to authentication, though as he is exploring below, the precise definition of what constitutes *sufficient* authentication to warrant use of the term AOR remains a bit elusive. Thanks, Paul Dean Willis wrote: > > On Sep 8, 2009, at 5:45 PM, Adam Roach wrote: > >> Just a quick reminder that we discussed this vigorously in Stockholm >> without reaching any conclusion. To help spur things along, here's a >> summary of the arguments made during that discussion: >> >> http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue%201:%20AOR%20tag >> >> >> Please resume discussion on the list, and see if we can reach any sort >> of rough agreement. > > > > > AORs might be used as targets for initial requests that are rerouted or > retargeted by contact routing or tabular translation. AORs might be the > identity bindings attached to GRUUs (see sections 1, 3, and 5 of > draft-ietf-sip-gruu-15). AORs might or might not be human-readable and > likley to appear on business cards. None of these definitions > effectively differentiates AORs from other URIs. > > I propose instead that an AOR is a SIP URI for which it is reasonable to > expect that an authentication service would issue an identity > certification, should an authentication service be in operation for the > domain in question. This might include RFC 4474 authentication, DIGEST > authentication at a registrar, proxy, or gateway, P-Asserted-Identity as > in RFC 3325 and IMS, or any similar certification of identity arranged > through an enrollment process. > > One might argue that in a simplistic non-authenticating proxy-registrar > that the registration action (which associates a Contact with the To: > URI of the request) forms the minimal identity certification needed for > this definition. Correspondingly, a systems configuration with similar > effect that statically configures a rerouting or retargeting destination > relative to an input URI forms a comparable minimal identity > certification. Further, acceptance of an AOR as a terminal value at a > SIP UA selected through conventional routing (as in RFC 3263) resolution > mechanisms would constitute a minimal identity certification. > > Another wording would make an AOR the input member of any (input, > output) tuple wherein a SIP transformation operation transforms (either > reroutes or retargets) the input URI such that the output URI is > selected, OR where an authentication operation is performed on the input > member (and especially where the two operations are combined).. The > output URI may also be an AOR, but only if it participates as an input > member into a transformation or authentication operation. > > > We might do well to speak of the "strength" of an AOR as a product of > the strength of the identity certification. For example, an an AOR for > which RFC 4474 identity certification is available would be "stronger" > than one resolved strictly through RFC 3263 resolution. This doesn't > affect the definition of an AOR, but might affect how one would react to > that AOR within an authorization system. > > -- > Dean_______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Sep 8 22:27:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB943A6906 for ; Tue, 8 Sep 2009 22:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpwmBmEePRZo for ; Tue, 8 Sep 2009 22:27:55 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 28EB73A681B for ; Tue, 8 Sep 2009 22:27:54 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-cd-4aa73cf94c5d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 62.28.18827.9FC37AA4; Wed, 9 Sep 2009 07:28:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 07:28:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 07:26:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 3265bis: 200, 202 and filters Thread-Index: Acoww0AwoFu8k67vSOubobtOSqKuggAStysn References: <4AA6BEEE.3040006@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , X-OriginalArrivalTime: 09 Sep 2009 05:28:20.0453 (UTC) FILETIME=[57B91150:01CA310E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] 3265bis: 200, 202 and filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:27:56 -0000 Hi, =20 >>When reading section 3.3.4 of RFC 4660 it seems that, when the filter = mechanism is used, 200 and 202 >>responses have different meaning to the = subscriber: 200 means that the filter was accepted, while 202 means = >>that the filter has yet not been accepted. > >The behavior of 202 in 4660 is consistent with that of 202 in 3265. = And, because it suffers the forking >problem, it's equally useless. I = don't think discouraging the sending of 202 in 3265bis will impact 4660 = >implementations negatively. =20 The draft talks about removing the 202 response. =20 Regards, =20 Christer =20 From adam@nostrum.com Wed Sep 9 08:16:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C35428C0E1 for ; Wed, 9 Sep 2009 08:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1FMGnaDYJ-a for ; Wed, 9 Sep 2009 08:16:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 720B73A6870 for ; Wed, 9 Sep 2009 08:16:34 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n89FH3VO024292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2009 10:17:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AA7C6EF.80901@nostrum.com> Date: Wed, 09 Sep 2009 10:17:03 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AA6BEEE.3040006@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: 200, 202 and filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:16:35 -0000 Christer Holmberg wrote: > Hi, > > >>> When reading section 3.3.4 of RFC 4660 it seems that, when the filter mechanism is used, 200 and 202 >>responses have different meaning to the subscriber: 200 means that the filter was accepted, while 202 means >>that the filter has yet not been accepted. >>> >> The behavior of 202 in 4660 is consistent with that of 202 in 3265. And, because it suffers the forking >problem, it's equally useless. I don't think discouraging the sending of 202 in 3265bis will impact 4660 >implementations negatively. >> > > The draft talks about removing the 202 response. > The discussion in Sweden basically resolved to adding text that basically says "don't send it, and don't expect it, but don't choke on it either." I don't see how 4660 impacts the decision either way. /a From AUDET@nortel.com Wed Sep 9 16:41:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CDE3A69DC for ; Wed, 9 Sep 2009 16:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Isu-7HlFH7cj for ; Wed, 9 Sep 2009 16:41:36 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 35A193A683F for ; Wed, 9 Sep 2009 16:41:35 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n89NfJ307114; Wed, 9 Sep 2009 23:41:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 18:41:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> In-Reply-To: <4AA6DEA7.7090403@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: Acow1jAu4HqpWUyiTXS8G+ZNcL1MMgAyy3rQ References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> From: "Francois Audet" To: "Adam Roach" , Cc: Jonathan Lennox , Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 23:41:40 -0000 I guess the summary is that we are kind of stalled on some of the = issues, in particular the aor tag issue. It seems that a significant fraction of = people do not believe that an AOR is deterministic construct that is worthy of being tagged as such. In my background (which is an Enterprise software/telephony background), "users" have accounts. An AOR is the series of addresses corresponding to these accounts, along with any aliases (such as phone=20 numbers expressed in SIP/TEL format). To me, AORs are not this fluffy concept that others on the list have made it up to be.=20 But in any case, I don't think we'll be able to reach a concensus on it. I believe that we need to step back and find a different way to skin = this cat. Going back to the requirements of WHAT we are really trying to solve at = the UAS: 1) Tagging the last address (including parameters) that was used in a Request-URI before being replaced by the Contact. i.e., the target-uri problem 1a) It has been argued that sometimes with the target-uri problem you may actually be looking for the first address (and parameters) as opposed to the last one. 2) Tagging addresses that represents a DIFFERENT user/resource, as a result of re-targeting. i.e., the re-targeting problem (voicemail, IVR, etc.) We could potentially solve those two by having tags for "mapped" and "contacts", and use a pointer to the index of what it is mapped from (I guess we could do=20 forward pointing instead of backward pointing, but then forking would be more cumbersome). Having the tag pointing to the index would remove ambiguity if entries are removed by a proxy, etc.=20 So, if I take a specific example of a call to bob being redirected to carol, the HI would look like=20 this: History-Info: ;index=3D1; History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D2;mp=3D1 History-Info: ;index=3D2.1;rc=3D2 For problem 1 (target-uri), the UAS would look at the last rc tag which = is it's registered contact, and see what it points to (i.e., index 2). = Index 2 is therefore the last target-uri. For problem 2 (redirection), the UAS looks for the last mp tag (it = points to index 1). Index 1 (bob) is therefore the "redirecting" number. Alternatively, the = UAS may look for the FIRST retargeting (many voicemail work with the first one). Anyways, this is just brainstorming (and it notably doesn't solve - I = think - the=20 Freephone/1-800 number problem).=20 Ideas? > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Tuesday, September 08, 2009 15:46 > To: sipcore@ietf.org > Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith=20 > Drage; Jon Peterson; Elwell, John; Robert Sparks; Jonathan=20 > Lennox; Dean Willis > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > Just a quick reminder that we discussed this vigorously in=20 > Stockholm without reaching any conclusion. To help spur=20 > things along, here's a summary of the arguments made during=20 > that discussion: >=20 > =20 > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > 201:%20AOR%20tag >=20 > Please resume discussion on the list, and see if we can reach=20 > any sort of rough agreement. >=20 > /a >=20 From shida@ntt-at.com Wed Sep 9 21:23:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85AAA3A6895 for ; Wed, 9 Sep 2009 21:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOItU0CHuGqq for ; Wed, 9 Sep 2009 21:23:49 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.1.3]) by core3.amsl.com (Postfix) with SMTP id 0EB3B3A67F3 for ; Wed, 9 Sep 2009 21:23:45 -0700 (PDT) Received: (qmail 28759 invoked from network); 10 Sep 2009 04:30:56 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway05.websitewelcome.com with SMTP; 10 Sep 2009 04:30:56 -0000 Received: from flh1aeb007.tky.mesh.ad.jp ([60.237.171.7]:59031 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1MlbCd-0007ye-6h; Wed, 09 Sep 2009 23:24:11 -0500 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Shida Schubert In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> Date: Thu, 10 Sep 2009 13:24:09 +0900 Content-Transfer-Encoding: 7bit Message-Id: <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> To: Francois Audet X-Mailer: Apple Mail (2.1075.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 04:23:50 -0000 I think the following could work for Freephone(toll-free), AFAIK all is needed for freephone was the mp tag and some guidance on where to look for a toll-free. I believe that solving the problem of toll-free is really determining the current target of the request, which I believe is what mp is trying to address. Generally if the incoming request is delivered via toll-free, then an entry before the last mp(mapped-to) is likely to be a toll-free number (mapped-from). Although, without globally deterministic way to mark the toll-free, it's hard for it to work across countries as different countries have different toll-free prefixes. (Here in Japan, it's 0120-xxx and not 1-800). We could though, possibly define a service URN or some tags for typical services that are out there and tag HI-entry representing such service with service URN that we define. History-Info: < sip:DirectoryAssistance @example.com>;index=1;service=urn:service:directory-assistance History-Info: ;index=1.1;mp=1 History-Info: ;index=1.1.1;rc=1 History-Info: ;index=1.1.2;rc=2 Regards Shida On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > I guess the summary is that we are kind of stalled on some of the > issues, in > particular the aor tag issue. It seems that a significant fraction > of people > do not believe that an AOR is deterministic construct that is worthy > of > being tagged as such. > > In my background (which is an Enterprise software/telephony > background), > "users" have accounts. An AOR is the series of addresses > corresponding to these accounts, along with any aliases (such as phone > numbers expressed in SIP/TEL format). To me, AORs are not this fluffy > concept that others on the list have made it up to be. > > But in any case, I don't think we'll be able to reach a concensus on > it. > > I believe that we need to step back and find a different way to skin > this cat. > > Going back to the requirements of WHAT we are really trying to solve > at the > UAS: > > 1) Tagging the last address (including parameters) that was used in > a Request-URI before being replaced by the Contact. > i.e., the target-uri problem > 1a) It has been argued that sometimes with the target-uri problem > you may actually be looking for the first address (and > parameters) > as opposed to the last one. > > 2) Tagging addresses that represents a DIFFERENT user/resource, as a > result of re-targeting. > i.e., the re-targeting problem (voicemail, IVR, etc.) > > We could potentially solve those two by having tags for > "mapped" and "contacts", and use a pointer to the index > of what it is mapped from (I guess we could do > forward pointing instead of backward pointing, but then > forking would be more cumbersome). > > Having the tag pointing to the index would remove ambiguity > if entries are removed by a proxy, etc. > > So, if I take a specific example of a call to bob > being redirected to carol, the HI would look like > this: > > History-Info: ;index=1; > History-Info: ;\ > index=1.1;rc=1 > History-Info: ;index=2;mp=1 > History-Info: ;index=2.1;rc=2 > > For problem 1 (target-uri), the UAS would look at the last rc tag > which is > it's registered contact, and see what it points to (i.e., index 2). > Index 2 is therefore > the last target-uri. > > For problem 2 (redirection), the UAS looks for the last mp tag (it > points to index 1). > Index 1 (bob) is therefore the "redirecting" number. Alternatively, > the UAS may look for > the FIRST retargeting (many voicemail work with the first one). > > Anyways, this is just brainstorming (and it notably doesn't solve - > I think - the > Freephone/1-800 number problem). > > Ideas? > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, September 08, 2009 15:46 >> To: sipcore@ietf.org >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith >> Drage; Jon Peterson; Elwell, John; Robert Sparks; Jonathan >> Lennox; Dean Willis >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> Just a quick reminder that we discussed this vigorously in >> Stockholm without reaching any conclusion. To help spur >> things along, here's a summary of the arguments made during >> that discussion: >> >> >> http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% >> 201:%20AOR%20tag >> >> Please resume discussion on the list, and see if we can reach >> any sort of rough agreement. >> >> /a >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Sep 9 22:02:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FD93A6892 for ; Wed, 9 Sep 2009 22:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFKRHVuEfOBx for ; Wed, 9 Sep 2009 22:02:08 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2D7843A6862 for ; Wed, 9 Sep 2009 22:02:07 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-83-4aa8887005cc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 2C.3B.18827.07888AA4; Thu, 10 Sep 2009 07:02:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 07:02:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Sep 2009 07:02:09 +0200 Message-ID: In-Reply-To: <4AA7C6EF.80901@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 3265bis: 200, 202 and filters Thread-Index: AcoxYJuPbdeJ/oDQSiOZPJecsnu4xwAcm1fQ References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 10 Sep 2009 05:02:10.0969 (UTC) FILETIME=[DAA69090:01CA31D3] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: 200, 202 and filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 05:02:09 -0000 Hi,=20 >>>>When reading section 3.3.4 of RFC 4660 it seems that,=20 >>>>when the filter mechanism is used, 200 and 202 >>responses=20 >>>>have different meaning to the subscriber: 200 means that the=20 >>>>filter was accepted, while 202 means >>that the filter has=20 >>>>yet not been accepted. >>>> =20 >>>>The behavior of 202 in 4660 is consistent with that of 202=20 >>>>in 3265. And, because it suffers the forking >problem, it's=20 >>>>equally useless. I don't think discouraging the sending of=20 >>>>202 in 3265bis will impact 4660 >implementations negatively. >>> =20 >> =20 >>The draft talks about removing the 202 response. >> =20 >>=20 >The discussion in Sweden basically resolved to adding text=20 >that basically says "don't send it, and don't expect it, but=20 >don't choke on it either." >=20 >I don't see how 4660 impacts the decision either way. It is probably just a wording issue. I simply ask that we choose a wording so that nobody later can claim that 4660, since it does send 202, goes against 3265bis. It is similar to INFO, where we have wording saying that just because we now require info events legacy usage of INFO is still "valid". Regards, Christer From AUDET@nortel.com Thu Sep 10 10:06:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94283A6A1D for ; Thu, 10 Sep 2009 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ4We8FGB0NM for ; Thu, 10 Sep 2009 10:06:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E15E83A689A for ; Thu, 10 Sep 2009 10:06:26 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8AH6Jx24463; Thu, 10 Sep 2009 17:06:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Sep 2009 12:06:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> In-Reply-To: <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoxzpJ3WJP2FLpZQzKpW4UdSLDk8QAaloZg References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> From: "Francois Audet" To: "Shida Schubert" Cc: Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 17:06:28 -0000 Ok, thanks. Let's wait for more input on this before we go for another rev of the draft.=20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: Wednesday, September 09, 2009 21:24 > To: Audet, Francois (SC100:3055) > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; Hadriel=20 > Kaplan; Dean Willis; Elwell, John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 > I think the following could work for Freephone(toll-free),=20 > AFAIK all is needed for freephone was the mp tag and some=20 > guidance on where to look for a toll-free. >=20 > I believe that solving the problem of toll-free is really=20 > determining the current target of the request, which I=20 > believe is what mp is trying to address. Generally if the=20 > incoming request is delivered via toll-free, then an entry=20 > before the last mp(mapped-to) is likely to be a toll-free=20 > number (mapped-from). >=20 > Although, without globally deterministic way to mark the=20 > toll-free, it's hard for it to work across countries as=20 > different countries have different toll-free prefixes. > (Here in Japan, it's 0120-xxx and not 1-800). >=20 > We could though, possibly define a service URN or some tags=20 > for typical services that are out there and tag HI-entry=20 > representing such service with service URN that we define. >=20 > History-Info: =20 > < > sip:DirectoryAssistance > @example.com>;index=3D1;service=3Durn:service:directory-assistance > History-Info: = ;index=3D1.1;mp=3D1 > History-Info: ;index=3D1.1.1;rc=3D1 > History-Info: ;index=3D1.1.2;rc=3D2 >=20 > Regards > Shida >=20 > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: >=20 > > I guess the summary is that we are kind of stalled on some of the=20 > > issues, in particular the aor tag issue. It seems that a=20 > significant=20 > > fraction of people do not believe that an AOR is deterministic=20 > > construct that is worthy of being tagged as such. > > > > In my background (which is an Enterprise software/telephony=20 > > background), "users" have accounts. An AOR is the series of=20 > addresses=20 > > corresponding to these accounts, along with any aliases=20 > (such as phone=20 > > numbers expressed in SIP/TEL format). To me, AORs are not=20 > this fluffy=20 > > concept that others on the list have made it up to be. > > > > But in any case, I don't think we'll be able to reach a=20 > concensus on=20 > > it. > > > > I believe that we need to step back and find a different=20 > way to skin=20 > > this cat. > > > > Going back to the requirements of WHAT we are really trying=20 > to solve=20 > > at the > > UAS: > > > > 1) Tagging the last address (including parameters) that was used in > > a Request-URI before being replaced by the Contact. > > i.e., the target-uri problem > > 1a) It has been argued that sometimes with the=20 > target-uri problem > > you may actually be looking for the first address (and > > parameters) > > as opposed to the last one. > > > > 2) Tagging addresses that represents a DIFFERENT user/resource, as a > > result of re-targeting. > > i.e., the re-targeting problem (voicemail, IVR, etc.) > > > > We could potentially solve those two by having tags for=20 > "mapped" and=20 > > "contacts", and use a pointer to the index of what it is=20 > mapped from=20 > > (I guess we could do forward pointing instead of backward pointing,=20 > > but then forking would be more cumbersome). > > > > Having the tag pointing to the index would remove ambiguity=20 > if entries=20 > > are removed by a proxy, etc. > > > > So, if I take a specific example of a call to bob being=20 > redirected to=20 > > carol, the HI would look like > > this: > > > > History-Info: ;index=3D1; > > History-Info: ;\ > > index=3D1.1;rc=3D1 > > History-Info: ;index=3D2;mp=3D1 > > History-Info: ;index=3D2.1;rc=3D2 > > > > For problem 1 (target-uri), the UAS would look at the last rc tag=20 > > which is it's registered contact, and see what it points to (i.e.,=20 > > index 2). > > Index 2 is therefore > > the last target-uri. > > > > For problem 2 (redirection), the UAS looks for the last mp tag (it=20 > > points to index 1). > > Index 1 (bob) is therefore the "redirecting" number. Alternatively,=20 > > the UAS may look for the FIRST retargeting (many voicemail=20 > work with=20 > > the first one). > > > > Anyways, this is just brainstorming (and it notably doesn't=20 > solve - I=20 > > think - the Freephone/1-800 number problem). > > > > Ideas? > > > > > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> Sent: Tuesday, September 08, 2009 15:46 > >> To: sipcore@ietf.org > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith Drage; Jon=20 > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; Dean Willis > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > >> Just a quick reminder that we discussed this vigorously in=20 > Stockholm=20 > >> without reaching any conclusion. To help spur things=20 > along, here's a=20 > >> summary of the arguments made during that discussion: > >> > >> > >> http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > >> 201:%20AOR%20tag > >> > >> Please resume discussion on the list, and see if we can reach any=20 > >> sort of rough agreement. > >> > >> /a > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 From AUDET@nortel.com Thu Sep 10 11:49:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6CA3A6998 for ; Thu, 10 Sep 2009 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0ckuD5MqufZ for ; Thu, 10 Sep 2009 11:49:38 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3B8D63A6886 for ; Thu, 10 Sep 2009 11:49:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8AIo7x15115; Thu, 10 Sep 2009 18:50:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Sep 2009 13:50:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FE282CE@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] [DW] What is an AoR? Thread-Index: Acow2/BJzGUEjMz/QTKw9y8AM8IwbQBar8lQ References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com><4AA6DEA7.7090403@nostrum.com> From: "Francois Audet" To: "Dean Willis" , "SIPCORE" Subject: Re: [sipcore] [DW] What is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 18:49:39 -0000 Your second definition is similar to the one that is actually used in RFC 3261/section 6: Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.=20 Which is what I've been arguing for a while now. It says the following things: - Tel URIs are not AORs - Only the target domain can know for sure if it's an AOR (which is why I said earlier that something is an AOR when the target domain says = it's an AOR). - Typically, the location service is populated through registration. - AOR are the "public" address of the user (i.e., the reachable = address). Now, the problem with this definition is that taken at face value,=20 lots of things could be considered AORs. Perhaps too much to consider an AOR tag to be useful. I believe this is what many were saying in = Stockholm. Therefore my other email on trying a different angle to solve the = target-uri and redirection-number problems for History-Info. > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Tuesday, September 08, 2009 16:27 > To: SIPCORE > Subject: [sipcore] [DW] What is an AoR? >=20 >=20 > On Sep 8, 2009, at 5:45 PM, Adam Roach wrote: >=20 > > Just a quick reminder that we discussed this vigorously in=20 > Stockholm=20 > > without reaching any conclusion. To help spur things along,=20 > here's a=20 > > summary of the arguments made during that discussion: > > > > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue > > %201:%20AOR%20tag > > > > Please resume discussion on the list, and see if we can=20 > reach any sort=20 > > of rough agreement. >=20 >=20 >=20 >=20 > AORs might be used as targets for initial requests that are rerouted =20 > or retargeted by contact routing or tabular translation. AORs=20 > might be =20 > the identity bindings attached to GRUUs (see sections 1, 3,=20 > and 5 of =20 > draft-ietf-sip-gruu-15). AORs might or might not be=20 > human-readable and =20 > likley to appear on business cards. None of these definitions =20 > effectively differentiates AORs from other URIs. >=20 > I propose instead that an AOR is a SIP URI for which it is=20 > reasonable =20 > to expect that an authentication service would issue an identity =20 > certification, should an authentication service be in operation for =20 > the domain in question. This might include RFC 4474 authentication, =20 > DIGEST authentication at a registrar, proxy, or gateway, P-Asserted-=20 > Identity as in RFC 3325 and IMS, or any similar certification of =20 > identity arranged through an enrollment process. >=20 > One might argue that in a simplistic non-authenticating proxy-=20 > registrar that the registration action (which associates a Contact =20 > with the To: URI of the request) forms the minimal identity =20 > certification needed for this definition. Correspondingly, a systems =20 > configuration with similar effect that statically configures a =20 > rerouting or retargeting destination relative to an input URI=20 > forms a =20 > comparable minimal identity certification. Further, acceptance of an =20 > AOR as a terminal value at a SIP UA selected through conventional =20 > routing (as in RFC 3263) resolution mechanisms would constitute a =20 > minimal identity certification. >=20 > Another wording would make an AOR the input member of any (input, =20 > output) tuple wherein a SIP transformation operation transforms =20 > (either reroutes or retargets) the input URI such that the=20 > output URI =20 > is selected, OR where an authentication operation is=20 > performed on the =20 > input member (and especially where the two operations are=20 > combined).. =20 > The output URI may also be an AOR, but only if it participates as an =20 > input member into a transformation or authentication operation. >=20 >=20 > We might do well to speak of the "strength" of an AOR as a=20 > product of =20 > the strength of the identity certification. For example, an=20 > an AOR for =20 > which RFC 4474 identity certification is available would be=20 > "stronger" =20 > than one resolved strictly through RFC 3263 resolution. This doesn't =20 > affect the definition of an AOR, but might affect how one=20 > would react =20 > to that AOR within an authorization system. >=20 > -- > Dean=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Fri Sep 11 03:29:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351523A6891 for ; Fri, 11 Sep 2009 03:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c6OGamec6Jx for ; Fri, 11 Sep 2009 03:29:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C7FC43A698F for ; Fri, 11 Sep 2009 03:29:39 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-f1-4aaa26b7be8b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 43.38.06532.7B62AAA4; Fri, 11 Sep 2009 12:30:15 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 12:30:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Sep 2009 12:30:13 +0200 Message-ID: In-Reply-To: <4AA7C6EF.80901@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3265bis: Filters and first notify Thread-Index: AcoxYJuPbdeJ/oDQSiOZPJecsnu4xwBaLJjQ References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 11 Sep 2009 10:30:14.0653 (UTC) FILETIME=[D97422D0:01CA32CA] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:29:41 -0000 =20 Hi, Section 4.2.1.2 in 3265bis says: "Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber." Now, RFC 4660 allows the subscriber to, using the filter element, indicate when notifications are to be sent.=20 I ASSUME that, whatever filter one specifies, that MUST NOT affect the fact that the notifier must send a NOTIFY request immediately after accepting a subscription. I don't find any text about that in RFC 4660. When forking occurs this issue exists already in 3265. Regards, Christer From christer.holmberg@ericsson.com Fri Sep 11 03:33:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5342E28C134 for ; Fri, 11 Sep 2009 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgZpIl0FrWxI for ; Fri, 11 Sep 2009 03:33:17 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 37F1628C12A for ; Fri, 11 Sep 2009 03:33:16 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-9c-4aaa2790a892 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id B2.F6.18827.0972AAA4; Fri, 11 Sep 2009 12:33:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 12:33:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Sep 2009 12:33:52 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 3265bis: Filters and first notify Thread-Index: AcoxYJuPbdeJ/oDQSiOZPJecsnu4xwBaLJjQAAB5QHA= References: <4AA6BEEE.3040006@nostrum.com><4AA7C6EF.80901@nostrum.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 11 Sep 2009 10:33:52.0522 (UTC) FILETIME=[5B504EA0:01CA32CB] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:33:18 -0000 Actually, subclause 3.3.4 of 4660 says that a 200-class response will always trigger a NOTIFY, and that the filter acceptance may come later, so I assume there is no issue. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 11. syyskuuta 2009 13:30 > To: sipcore@ietf.org > Subject: [sipcore] 3265bis: Filters and first notify >=20 >=20 > =20 > Hi, >=20 > Section 4.2.1.2 in 3265bis says: >=20 > "Upon successfully accepting or refreshing a subscription,=20 > notifiers MUST send a NOTIFY message immediately to=20 > communicate the current resource state to the subscriber." >=20 > Now, RFC 4660 allows the subscriber to, using the filter=20 > element, indicate when notifications are to be sent.=20 >=20 > I ASSUME that, whatever filter one specifies, that MUST NOT=20 > affect the fact that the notifier must send a NOTIFY request=20 > immediately after accepting a subscription. I don't find any=20 > text about that in RFC 4660. >=20 > When forking occurs this issue exists already in 3265. >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Fri Sep 11 07:59:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5055C3A68B4 for ; Fri, 11 Sep 2009 07:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIOu7ldgV9rJ for ; Fri, 11 Sep 2009 07:59:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6291B3A680E for ; Fri, 11 Sep 2009 07:59:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFcCqkqrR7PE/2dsb2JhbADFC4hIAZAFBYQY X-IronPort-AV: E=Sophos;i="4.44,370,1249257600"; d="scan'208";a="386832351" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2009 15:00:08 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8BF07Lb003075; Fri, 11 Sep 2009 08:00:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8BF01i4004189; Fri, 11 Sep 2009 15:00:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 11:00:06 -0400 Received: from [10.86.252.180] ([10.86.252.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 11:00:06 -0400 Message-ID: <4AAA65F1.9020403@cisco.com> Date: Fri, 11 Sep 2009 11:00:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Sep 2009 15:00:06.0113 (UTC) FILETIME=[8C50DD10:01CA32F0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1149; t=1252681208; x=1253545208; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=203265bis=3A=20Filters=20and= 20first=20notify |Sender:=20; bh=pwJeYLFb7EdsSMhJACTC8Jnn+i0zKcP6/pkAVoiMEtQ=; b=eCg/dxI5YE+ZkFh8v0L9qYtxJwgaws8qUvh6WVMxwZdhDRtmKxvS+7g9UY ysYUqspsHhLM4PVm76uv3KnJFKDrHsFJQhE4VFRQpHlRpnPi7vDyilYAo2i5 evdnPZ5vtc; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 14:59:31 -0000 ISTM that the initial NOTIFY following a SUBSCRIBE, or especially a reSUBSCRIBE, is often a significant concern in the design of features. I think it would be advantageous if it was possible to design a filter that could intentionally suppress that first notify. Thanks, Paul Christer Holmberg wrote: > > Hi, > > Section 4.2.1.2 in 3265bis says: > > "Upon successfully accepting or refreshing a subscription, notifiers > MUST send a NOTIFY message immediately to communicate the current > resource state to the subscriber." > > Now, RFC 4660 allows the subscriber to, using the filter > element, indicate when notifications are to be sent. > > I ASSUME that, whatever filter one specifies, that MUST NOT affect the > fact that the notifier must send a NOTIFY request immediately after > accepting a subscription. I don't find any text about that in RFC 4660. > > When forking occurs this issue exists already in 3265. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From theo@crazygreek.co.uk Fri Sep 11 20:31:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2FD3A67FC for ; Fri, 11 Sep 2009 20:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV2wlD++q67Y for ; Fri, 11 Sep 2009 20:31:26 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with SMTP id 295AD3A67EB for ; Fri, 11 Sep 2009 20:31:26 -0700 (PDT) Received: from source ([209.85.218.225]) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSqsWNPqHjCFVvct0QxShqLBWZWzCc5yv@postini.com; Fri, 11 Sep 2009 20:32:05 PDT Received: by bwz25 with SMTP id 25so1183176bwz.32 for ; Fri, 11 Sep 2009 20:32:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.73.20 with SMTP id o20mr1572371faj.71.1252726324087; Fri, 11 Sep 2009 20:32:04 -0700 (PDT) In-Reply-To: <20090912031502.290BB3A6998@core3.amsl.com> References: <20090912031502.290BB3A6998@core3.amsl.com> From: Theo Zourzouvillys Date: Fri, 11 Sep 2009 20:31:44 -0700 Message-ID: <167dfb9b0909112031k3523ac3dg44677f6cbcdfad69@mail.gmail.com> To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] Fwd: I-D Action:draft-sparks-sipcore-invfix-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:31:27 -0000 evening, all y'alls. I've updated the draft to ensure backward compatibility with RFC 2543 UACs. Previously, any implementation implementing invfix would barf when handling a reINVITE from an RFC 2543 client, as both an ACK and INVITE would match the same transaction, and thus most likely be dropped. it wouldn't affect an initial INVITE from an RFC 2453 cleint, as the To tag is different between the INVITE and ACK to a 2xx. I'd appreciate any feedback on it. ~ Theo ---------- Forwarded message ---------- From: Date: Fri, Sep 11, 2009 at 8:15 PM Subject: I-D Action:draft-sparks-sipcore-invfix-01.txt To: i-d-announce@ietf.org This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. =A0Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. =A0The correction involves modifying the INVITE transaction state machines. =A0The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. From root@core3.amsl.com Sat Sep 12 00:45:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A23963A6784; Sat, 12 Sep 2009 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090912074501.A23963A6784@core3.amsl.com> Date: Sat, 12 Sep 2009 00:45:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-invfix-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 07:45:01 -0000 --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 Core Working Group of the IETF. Title : Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests Author(s) : R. Sparks, T. Zourzouvillys Filename : draft-ietf-sipcore-invfix-00.txt Pages : 20 Date : 2009-09-12 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-invfix-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-invfix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-12004050.I-D@ietf.org> --NextPart-- From adam@nostrum.com Sun Sep 13 11:57:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA573A6868 for ; Sun, 13 Sep 2009 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZksuMgJHceTQ for ; Sun, 13 Sep 2009 11:57:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9F0353A67EB for ; Sun, 13 Sep 2009 11:57:55 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8DIwPf7050005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Sep 2009 13:58:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AAD40D1.5000009@nostrum.com> Date: Sun, 13 Sep 2009 13:58:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Paul Kyzivat References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> <4AAA65F1.9020403@cisco.com> In-Reply-To: <4AAA65F1.9020403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 18:57:56 -0000 On 9/11/09 10:00, Sep 11, Paul Kyzivat wrote: > ISTM that the initial NOTIFY following a SUBSCRIBE, or especially a > reSUBSCRIBE, is often a significant concern in the design of features. > I think it would be advantageous if it was possible to design a filter > that could intentionally suppress that first notify. Subnot-etags provides that functionality -- at least, for resubscribes. You can't suppress the initial NOTIFY in a subscription due to the potential for forking. /a From christer.holmberg@ericsson.com Sun Sep 13 13:02:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C48F3A657C for ; Sun, 13 Sep 2009 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X35PLS1YFBhh for ; Sun, 13 Sep 2009 13:02:21 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 883F03A692A for ; Sun, 13 Sep 2009 13:02:21 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-b2-4aad4ff65a4f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 02.5F.18827.6FF4DAA4; Sun, 13 Sep 2009 22:03:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Sep 2009 22:03:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Sep 2009 21:59:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 3265bis: Filters and first notify Thread-Index: Aco0pDK0Waz/018oRfibMMJ8phxqSQACIPTJ References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> <4AAA65F1.9020403@cisco.com> <4AAD40D1.5000009@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Paul Kyzivat" X-OriginalArrivalTime: 13 Sep 2009 20:03:01.0964 (UTC) FILETIME=[32CB20C0:01CA34AD] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 20:02:23 -0000 Hi, >>ISTM that the initial NOTIFY following a SUBSCRIBE, or especially a >>reSUBSCRIBE, is often a significant concern in the design of features. >>I think it would be advantageous if it was possible to design a filter >>that could intentionally suppress that first notify. > >Subnot-etags provides that functionality -- at least, for resubscribes. >You can't suppress the initial NOTIFY in a subscription due to the >potential for forking. So, just to clarify: Since you can suppress the initial NOTIFY (at least for resubscribes) = that means that the SUB 200 OK will terminate the re-transmission of the = SUB request - normal SIP transaction handling, that is. So, also for initial subscriptions, I assume the 200 OK will also = terminate the re-transmission of the SUB requests - even if the = associated DIALOG will not be established until the initial INVITE = arrives. Correct? Regards, Christer =20 From pkyzivat@cisco.com Sun Sep 13 13:03:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EDB3A692A for ; Sun, 13 Sep 2009 13:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFHR+2EhpcGH for ; Sun, 13 Sep 2009 13:03:33 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 563E23A6853 for ; Sun, 13 Sep 2009 13:03:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKDsrEpAZnmf/2dsb2JhbADCGIhMAY4GBYQY X-IronPort-AV: E=Sophos;i="4.44,379,1249257600"; d="scan'208";a="57919239" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2009 20:04:15 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8DK4F2S020261; Sun, 13 Sep 2009 16:04:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8DK4Fmn011704; Sun, 13 Sep 2009 20:04:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Sep 2009 16:04:15 -0400 Received: from [10.86.251.59] ([10.86.251.59]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Sep 2009 16:04:14 -0400 Message-ID: <4AAD503A.10204@cisco.com> Date: Sun, 13 Sep 2009 16:04:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> <4AAA65F1.9020403@cisco.com> <4AAD40D1.5000009@nostrum.com> In-Reply-To: <4AAD40D1.5000009@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2009 20:04:14.0773 (UTC) FILETIME=[5E30E650:01CA34AD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1183; t=1252872255; x=1253736255; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=203265bis=3A=20Filters=20and= 20first=20notify |Sender:=20 |To:=20Adam=20Roach=20; bh=aDzEY10J3VzGe+Np7GV2kY3Y6nCEMd+hD79RNGna77k=; b=ohxvlt/HmfG6ZvZJV9irs+IISzmhI1F+l7j1EXdAOS1EPGxasGqT0Ispk/ IVdowJDGuNDxbp22b3vb7YQxL8hXDePQJgPR4+8GisSO/iI1wT1sWI+GBmk9 8k0VoaY6PU; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 20:03:34 -0000 Adam Roach wrote: > On 9/11/09 10:00, Sep 11, Paul Kyzivat wrote: >> ISTM that the initial NOTIFY following a SUBSCRIBE, or especially a >> reSUBSCRIBE, is often a significant concern in the design of features. >> I think it would be advantageous if it was possible to design a filter >> that could intentionally suppress that first notify. > > Subnot-etags provides that functionality -- at least, for resubscribes. That covers a lot of cases, but maybe not all. For instance, suppose you want to change the scope of a filter, so it filters out more information than it did before. In many cases the information that would be returned in the initial notify after that change will just be the new subset of what was previously received, and you wouldn't want to receive that. But I *think* the etag will be different for that, won't it? So you will have no way to suppress that notify. That seemed to be the kind of thing that might happen with the geolocation filtering that was discussed some time ago. > You can't suppress the initial NOTIFY in a subscription due to the > potential for forking. I understand that. Thanks, Paul From christer.holmberg@ericsson.com Sun Sep 13 13:37:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4014D3A68BB for ; Sun, 13 Sep 2009 13:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2HtlemR2yTO for ; Sun, 13 Sep 2009 13:37:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 01CA33A690D for ; Sun, 13 Sep 2009 13:37:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2cae000005a8f-7c-4aad58276b27 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 98.40.23183.7285DAA4; Sun, 13 Sep 2009 22:37:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Sep 2009 22:37:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Sep 2009 22:37:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 3265bis: Filters and first notify Thread-Index: Aco0rWBelq0sCHo1TJyZ68ZAyKTRJAAA+uhm References: <4AA6BEEE.3040006@nostrum.com> <4AA7C6EF.80901@nostrum.com> <4AAA65F1.9020403@cisco.com> <4AAD40D1.5000009@nostrum.com> <4AAD503A.10204@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 13 Sep 2009 20:37:34.0527 (UTC) FILETIME=[062324F0:01CA34B2] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] 3265bis: Filters and first notify X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 20:37:19 -0000 Hi Paul, =20 For filters, remember that the first NOTIFY (the first NOT sent after = each SUB/re-SUB has been received, that is) does not necessarily contain = the information based on the filters. So, even if you would supress that = first NOTIFY, I believe you may still receive the "subset" information = in a later NOTIFY. =20 Regards, =20 Christer ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Sun 13/09/2009 22:04 To: Adam Roach Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] 3265bis: Filters and first notify Adam Roach wrote: > On 9/11/09 10:00, Sep 11, Paul Kyzivat wrote: >> ISTM that the initial NOTIFY following a SUBSCRIBE, or especially a >> reSUBSCRIBE, is often a significant concern in the design of = features. >> I think it would be advantageous if it was possible to design a = filter >> that could intentionally suppress that first notify. > > Subnot-etags provides that functionality -- at least, for = resubscribes. That covers a lot of cases, but maybe not all. For instance, suppose you want to change the scope of a filter, so it filters out more information than it did before. In many cases the information that would be returned in the initial notify after that change will just be the new subset of what was previously received, and you wouldn't want to receive that. But I *think* the etag will be different for that, won't it? So you will have no way to suppress that notify. That seemed to be the kind of thing that might happen with the geolocation filtering that was discussed some time ago. > You can't suppress the initial NOTIFY in a subscription due to the > potential for forking. I understand that. Thanks, Paul From oej@edvina.net Mon Sep 14 10:11:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6043A6A61 for ; Mon, 14 Sep 2009 10:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAFbwHWQOJIf for ; Mon, 14 Sep 2009 10:11:50 -0700 (PDT) Received: from aero.webway.se (aero.webway.se [212.3.14.206]) by core3.amsl.com (Postfix) with ESMTP id 2112A3A6842 for ; Mon, 14 Sep 2009 10:11:49 -0700 (PDT) Received: from localhost (aero.webway.se [212.3.14.206]) by aero.webway.se (Postfix) with ESMTP id 833E9112B1E; Mon, 14 Sep 2009 17:12:23 +0000 (GMT) Received: from aero.webway.se ([212.3.14.206]) by localhost (aero.webway.se [212.3.14.206]) (amavisd-new, port 10024) with ESMTP id 59870-02; Mon, 14 Sep 2009 17:12:21 +0000 (GMT) Received: from [IPv6:::1] (ns.webway.se [87.96.134.125]) by aero.webway.se (Postfix) with ESMTP id C8981112A7A; Mon, 14 Sep 2009 17:12:20 +0000 (GMT) From: "Olle E. Johansson" To: Brian Hibbard In-Reply-To: References: <8376427F-05D6-483B-A5B2-EE20751A8B03@edvina.net> Message-Id: <4B39193F-F94C-4CE0-9DCD-1B550BE37460@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Sep 2009 19:12:24 +0200 X-Mailer: Apple Mail (2.936) X-Virus-Scanned: amavisd-new at webway.se Cc: SIPCORE Subject: Re: [sipcore] Fwd: draft-ietf-sipcore-sec-flows-00 :: Feedback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 17:11:51 -0000 8 sep 2009 kl. 21.04 skrev Brian Hibbard: > Hello Olle, > > Thank you very much for your feedback. Unfortunately, there is no =20 > prize for being the first and only reviewer so far. I apologize for =20= > taking so long to respond. For the time being, I am the custodian =20 > of the draft. You're welcome. --see below /Olle > > Please see my comments below. > > > -Brian > > On Sep 3, 2009, at 10:00 AM, Olle E. Johansson wrote: > >> I haven't gotten any feedback on my feedback, but that may be the =20 >> way it should be. I'm just curious on who's taking care of the =20 >> progress of this document. >> >> Regards, >> /O >> >> Vidarebefordrat brev: >> >>> Fr=E5n: "Olle E. Johansson" >>> Datum: on 5 aug 2009 13.39.28 GMT+02:00 >>> Till: SIPCORE >>> =C4mne: [sipcore] draft-ietf-sipcore-sec-flows-00 :: Feedback >>> >>> I vaguely remember that Adam mentioned this draft at the IETF75 =20 >>> meeting... ;-) >>> >>> Here's a few comments from someone who hasn't followed previous =20 >>> discussion on it: >>> >>> A bit more of education needed >>> ------------------------------------------ >>> I think that since the area of security in SIP is covered in =20 >>> multiple documents that are hard to navigate through, this =20 >>> document needs to act a bit more as a hitchhiker's guide for both =20= >>> developers and implementors - administrators of servers. Currently =20= >>> it requires a great deal of TLS/PKI knowledge to be useful, =20 >>> something I humbly suggest we should try to work around, to lower =20= >>> the bar. We actually want people to implement this, and to do it =20 >>> correctly. >>> >>> The document starts quickly and the reader is lost in section 4.1 =20= >>> where we throw a text encoding of a CA certificate in his face. =20 >>> The really important information is hidden in section 7 and 8 =20 >>> after page up and down with various encoding schemes that for most =20= >>> people will look and feel like a strange Swedish dialect from =20 >>> Kn=E4ckebr=F6dshult... Can we restructure and move these sections up = =20 >>> front? >>> >>> Relationship between server host name, served domain and SRV/NAPTR =20= >>> records needs to be explained >>> = --------------------------------------------------------------------------= -------------------------------------------------------------------- >>> Even though this is propably explained in five other documents, I =20= >>> think we could clarify this a bit. >>> >>> - how does one host serve multiple domains? Is this reflected at =20 >>> all in the server certificate? >>> - If SRV for example.com points to stockholm.example.com - which =20 >>> CN and which subjAltName should be used? >>> >>> The example used for domain "example.com" with hostname =20 >>> "example.com" is avoiding this... >>> >>> Explain the certificate request (CSR) >>> ------------------------------------------------- >>> In the real world, not in developer labs, the procedure for =20 >>> creating the key pair and generating a CSR on the host and the =20 >>> actual routine that signs and produces a certificate are two =20 >>> different procedures. This is not covered at all in this draft. In =20= >>> order to get the necessary Subject Alternative Names in the cert, =20= >>> and the EKU information, the CSR needs to reflect that. If you =20 >>> parse the scripts and the OpenSSL config file in the back, you can =20= >>> find out how this fits together. I think it would help all of us =20 >>> to actually have some examples of the parsed CSR as well to =20 >>> clearly explain the procedure. > > These are good ideas, but my understanding is that this draft is not =20= > intended to be tutorial in nature. It is intended only to provide =20 > concrete reference examples. A new tutorial document would probably =20= > be helpful and well received by the community, but the SIP Sec =20 > Flows draft does not purport to be that document. Is this OK with =20 > you? Let's agree on having examples of parsed CSR requests then :-) > > >>> >>> >>> Small changes >>> -------------------- >>> >>> Page 4, section 1: >>> >>> ..."this document provides a common certificate that can be"... I =20= >>> would change that to >>> ..."this document provides a common certificate and private key =20 >>> that can be"... >>> >>> Page 5, section 4.1 >>> >>> "Note that the basic constraints allow it to be used as a CA" >>> -> "Note that the X.509v3 Basic Constraints in the certificate =20 >>> allows it to be used as a CA, certificate authority." >>> >>> >>> I would insert a sentence at the end: >>> >>> "This certificate is used to verify client and host certificates, =20= >>> it's not used directly in the TLS call flow." >>> >>> Page 10, Section 4.3 - User certs >>> >>> "This is necessary for interoperating with CPIM gateway" >>> Now, english is not my native language, but I want a small "a" =20 >>> before "CPIM" ;-) >>> >>> I would change the first sentence to: >>> >>> "The user certificate, used in many apps, for fluffy@example.com =20 >>> is shown below" >>> >>> This would explain why we have other apps and data in there and =20 >>> also point out that one user cert can be used for many different =20 >>> apps. >>> >>> Also, the last sentence: >>> >>> "Note that the X509v3 Extended Key Usage attribute refers to the =20 >>> SIP OID introduced in [12] - 1.3.6.1.5.5.7.3.20 >>> >>> Page 28, section 7 >>> >>> The last paragraph seems to be about S/MIME but it doesn't say so. =20= >>> I think that could be clarified. >>> >>> Page 33 >>> >>> "These could be in two PEM files or one .p12 file." >>> >>> Many servers actually has both PEM sections - the private key and =20= >>> the cert - in one combined file. Yes, it's confusing, but it's done. > > These all sound good. I will go make these changes. Ok, Thanks. /O= From tianlinyi@huawei.com Wed Sep 16 19:25:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12F93A6B0B for ; Wed, 16 Sep 2009 19:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIGv-jjSLzlB for ; Wed, 16 Sep 2009 19:25:16 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9F9D428C16C for ; Wed, 16 Sep 2009 19:24:07 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ30099VG1BN8@szxga02-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 10:24:47 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ3004KTG1BQX@szxga02-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 10:24:47 +0800 (CST) Received: from [192.168.100.225] ([211.147.16.239]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ30043WG15HX@szxml02-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 10:24:47 +0800 (CST) Date: Thu, 17 Sep 2009 10:24:40 +0800 From: Linyi Tian To: sipcore@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lTZUOXMdZVWwYbhVlmib0A)" Thread-topic: Questions to info events draft Thread-index: Aco3PgJTjuPn2jz85E21fGyCTakYgw== User-Agent: Microsoft-Entourage/12.20.0.090605 X-Mailman-Approved-At: Wed, 16 Sep 2009 19:27:14 -0700 Subject: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 02:25:16 -0000 > 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. --Boundary_(ID_lTZUOXMdZVWwYbhVlmib0A) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, All In section 7.8 it talks about the rate of info requests. It is not clear to me where to specify the rate. 1. The first paragraph says that a Info package MUST define a requirement for the maximum rate. Does it mean the rate will be specified in the IANA registration? Or does it mean the INFO body(MIME) should include a parameter for the rate? 2. The second paragraph says that a package MUST define a throttle mechanism. Does it means the INFO body (MIME) needs to specify the mechanism? 7.8. Rate of INFO Requests Each Info Package MUST define a requirement of MUST strength which defines an absolute maximum on the rate at which an Info Package of a given type can generate INFO messages by a UA in a session. If possible, a package MUST define a throttle mechanism that allows UAs to further limit the rate of INFO messages. Cheers, Linyi --Boundary_(ID_lTZUOXMdZVWwYbhVlmib0A) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Questions to info events draft Hi, All

In section 7.8 it talks about the rate of info requests. It is not clear to me where to specify the rate.
1. The first paragraph says that a Info package MUST define a requirement for the maximum rate. Does it mean the rate will be specified in the IANA registration? Or does it mean the INFO body(MIME) should include a parameter for the rate?
2. The second paragraph says that a package MUST define a throttle mechanism. Does it means the INFO body (MIME) needs to specify the mechanism?

7.8.  Rate of INFO Requests

   Each Info Package MUST define a requirement of MUST strength which
   defines an absolute maximum on the rate at which an Info Package of a
   given type can generate INFO messages by a UA in a session.

   If possible, a package MUST define a throttle mechanism that allows
   UAs to further limit the rate of INFO messages.

Cheers,
Linyi --Boundary_(ID_lTZUOXMdZVWwYbhVlmib0A)-- From sanjsinh@cisco.com Wed Sep 16 21:47:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28BF3A63EC for ; Wed, 16 Sep 2009 21:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnjrRuXv334K for ; Wed, 16 Sep 2009 21:47:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B00FE3A6838 for ; Wed, 16 Sep 2009 21:47:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8EAOdbsUpAZnmf/2dsb2JhbACCKBYYwzeITAGQNwWEGA X-IronPort-AV: E=Sophos;i="4.44,401,1249257600"; d="scan'208,217";a="58524187" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Sep 2009 04:47:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8H4lrr9028976; Thu, 17 Sep 2009 00:47:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8H4lrMP019213; Thu, 17 Sep 2009 04:47:53 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 00:47:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA3751.E7846783" Date: Thu, 17 Sep 2009 00:47:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions to info events draft Thread-Index: Aco3PgJTjuPn2jz85E21fGyCTakYgwAE57Lg References: From: "Sanjay Sinha (sanjsinh)" To: "Linyi Tian" , X-OriginalArrivalTime: 17 Sep 2009 04:47:52.0975 (UTC) FILETIME=[042351F0:01CA3752] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4617; t=1253162873; x=1254026873; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20Questions=20to=20info=20eve nts=20draft |Sender:=20 |To:=20=22Linyi=20Tian=22=20,=20; bh=zUEQwYntw4/U6rokl8+Yu5D9vSDatRuOCpj9xFqvagg=; b=Eh3mmWzVpAEufGHq9L+bTpGxfuVaICDsciKEATna7sIcR+Q27YjpAOzJD9 KogNAV7vy5IJZN09Na51W6A2qQRvCNLMp0ibmp37Yqc5pz+dpkmhc8JQHIEV GuQ89Hqx3a; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 04:47:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3751.E7846783 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think each INFO event package will specify the rate of requests, whether there should be one INFO for each state change associated with that event or if that information can be buffered and sent one shot. =20 Sanjay ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi Tian Sent: Thursday, September 17, 2009 7:55 AM To: sipcore@ietf.org Subject: [sipcore] Questions to info events draft =09 =09 Hi, All =09 In section 7.8 it talks about the rate of info requests. It is not clear to me where to specify the rate. 1. The first paragraph says that a Info package MUST define a requirement for the maximum rate. Does it mean the rate will be specified in the IANA registration? Or does it mean the INFO body(MIME) should include a parameter for the rate? 2. The second paragraph says that a package MUST define a throttle mechanism. Does it means the INFO body (MIME) needs to specify the mechanism? =09 7.8. Rate of INFO Requests =09 Each Info Package MUST define a requirement of MUST strength which defines an absolute maximum on the rate at which an Info Package of a given type can generate INFO messages by a UA in a session. =09 If possible, a package MUST define a throttle mechanism that allows UAs to further limit the rate of INFO messages. =09 Cheers, Linyi=20 ------_=_NextPart_001_01CA3751.E7846783 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions to info events draft
I think each INFO event package will specify = the rate of=20 requests, whether there should be one INFO for each state change = associated with=20 that event or if that information can be buffered and sent one=20 shot.
 
Sanjay

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi=20 Tian
Sent: Thursday, September 17, 2009 7:55 = AM
To:=20 sipcore@ietf.org
Subject: [sipcore] Questions to info events = draft

Hi, All

In section 7.8 it talks about = the rate=20 of info requests. It is not clear to me where to specify the = rate.
1. The=20 first paragraph says that a Info package MUST define a requirement for = the=20 maximum rate. Does it mean the rate will be specified in the IANA=20 registration? Or does it mean the INFO body(MIME) should include a = parameter=20 for the rate?
2. The second paragraph says that a package MUST = define a=20 throttle mechanism. Does it means the INFO body (MIME) needs to = specify the=20 mechanism?

7.8.  Rate of INFO = Requests

   Each Info Package = MUST define=20 a requirement of MUST strength which
   defines an = absolute=20 maximum on the rate at which an Info Package of = a
   given=20 type can generate INFO messages by a UA in a=20 session.

   If possible, a package MUST define a = throttle mechanism that allows
   UAs to further = limit the=20 rate of INFO messages.

Cheers,
Linyi=20 ------_=_NextPart_001_01CA3751.E7846783-- From tianlinyi@huawei.com Wed Sep 16 22:14:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7E73A6814 for ; Wed, 16 Sep 2009 22:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmr0nFmK5q42 for ; Wed, 16 Sep 2009 22:13:58 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5C21A28C0F8 for ; Wed, 16 Sep 2009 22:13:58 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300JPSNWE6S@szxga04-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 13:14:39 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300BV5NWEFX@szxga04-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 13:14:38 +0800 (CST) Received: from [192.168.100.225] ([211.147.16.239]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ300IOJNWB0Z@szxml01-in.huawei.com>; Thu, 17 Sep 2009 13:14:38 +0800 (CST) Date: Thu, 17 Sep 2009 13:14:34 +0800 From: Linyi Tian In-reply-to: To: "Sanjay Sinha (sanjsinh)" , sipcore@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Xvyt8bNaKD3kS4VruKE3Sg)" Thread-topic: [sipcore] Questions to info events draft Thread-index: Aco3PgJTjuPn2jz85E21fGyCTakYgwAE57LgAAEHVL4= User-Agent: Microsoft-Entourage/12.20.0.090605 Subject: Re: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 05:14:03 -0000 > 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. --Boundary_(ID_Xvyt8bNaKD3kS4VruKE3Sg) Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7BIT Hi, Sanjay Thank you for your feedback. Does It mean that In the MIME body there should be one or more elements Indicates the rate? From the draft Itself It Is not clear to me how this will be done. Should we clarify this In the section 7.8? Cheers, Linyi On 09-9-17 $B2<8a(B12:47, "Sanjay Sinha (sanjsinh)" wrote: > I think each INFO event package will specify the rate of requests, whether > there should be one INFO for each state change associated with that event or > if that information can be buffered and sent one shot. > > Sanjay > >> >> >> >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Linyi Tian >> Sent: Thursday, September 17, 2009 7:55 AM >> To: sipcore@ietf.org >> Subject: [sipcore] Questions to info events draft >> >> >> Hi, All >> >> In section 7.8 it talks about the rate of info requests. It is not clear to >> me where to specify the rate. >> 1. The first paragraph says that a Info package MUST define a requirement >> for the maximum rate. Does it mean the rate will be specified in the IANA >> registration? Or does it mean the INFO body(MIME) should include a parameter >> for the rate? >> 2. The second paragraph says that a package MUST define a throttle >> mechanism. Does it means the INFO body (MIME) needs to specify the >> mechanism? >> >> 7.8. Rate of INFO Requests >> >> Each Info Package MUST define a requirement of MUST strength which >> defines an absolute maximum on the rate at which an Info Package of a >> given type can generate INFO messages by a UA in a session. >> >> If possible, a package MUST define a throttle mechanism that allows >> UAs to further limit the rate of INFO messages. >> >> Cheers, >> Linyi > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Boundary_(ID_Xvyt8bNaKD3kS4VruKE3Sg) Content-type: text/html; charset=ISO-2022-JP Content-transfer-encoding: 7BIT Re: [sipcore] Questions to info events draft Hi, Sanjay

Thank you for your feedback.

Does It mean that In the MIME body there should be one or more elements Indicates the rate? From the draft Itself It Is not clear to me how this will be done. Should we clarify this In the section 7.8?

Cheers,
Linyi


On 09-9-17 $B2<8a(B12:47, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com> wrote:

I think each INFO event package will specify the rate of requests, whether there should be one INFO for each state change associated with that event or if that information can be buffered and sent one shot.
Sanjay


 
From: sipcore-bounces@ietf.org  [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi  Tian
Sent: Thursday, September 17, 2009 7:55 AM
To:  sipcore@ietf.org
Subject: [sipcore] Questions to info events  draft

 
Hi, All

In section 7.8 it talks about the rate  of info requests. It is not clear to me where to specify the rate.
1. The  first paragraph says that a Info package MUST define a requirement for the  maximum rate. Does it mean the rate will be specified in the IANA  registration? Or does it mean the INFO body(MIME) should include a parameter  for the rate?
2. The second paragraph says that a package MUST define a  throttle mechanism. Does it means the INFO body (MIME) needs to specify the  mechanism?

7.8.  Rate of INFO Requests

   Each Info Package MUST define  a requirement of MUST strength which
   defines an absolute  maximum on the rate at which an Info Package of a
   given  type can generate INFO messages by a UA in a  session.

   If possible, a package MUST define a  throttle mechanism that allows
   UAs to further limit the  rate of INFO messages.

Cheers,
Linyi

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--Boundary_(ID_Xvyt8bNaKD3kS4VruKE3Sg)-- From dean.willis@softarmor.com Wed Sep 16 23:09:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819553A687C for ; Wed, 16 Sep 2009 23:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0BkLcvVSYF6 for ; Wed, 16 Sep 2009 23:09:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8607B3A6B4A for ; Wed, 16 Sep 2009 23:09:39 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8H69jSn005558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Sep 2009 01:09:47 -0500 Message-Id: <6A7DC460-7B5C-4574-9F8B-2A3F1028E37E@softarmor.com> From: Dean Willis To: Linyi Tian In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 01:09:40 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "Sanjay Sinha \(sanjsinh\)" , sipcore@ietf.org Subject: Re: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 06:09:40 -0000 On Sep 17, 2009, at 12:14 AM, Linyi Tian wrote: > Hi, Sanjay > > Thank you for your feedback. > > Does It mean that In the MIME body there should be one or more > elements Indicates the rate? From the draft Itself It Is not clear > to me how this will be done. Should we clarify this In the section > 7.8? I believe it means that the specification document (generally an RFC) that defines the INFO package describes the rate and limiter mechanism used with that INFO package. This rate is not encoded into the MIME; rather it is a characteristic of the INFO packagetype. -- Dean From christer.holmberg@ericsson.com Wed Sep 16 23:15:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF1C3A67F0 for ; Wed, 16 Sep 2009 23:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.479 X-Spam-Level: X-Spam-Status: No, score=-5.479 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP5jUP2krmuc for ; Wed, 16 Sep 2009 23:15:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 829DF3A6B3B for ; Wed, 16 Sep 2009 23:15:07 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-74-4ab1d41c4b33 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 72.7A.06532.C14D1BA4; Thu, 17 Sep 2009 08:15:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:15:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA375E.4F7F3EE6" Date: Thu, 17 Sep 2009 08:15:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions to info events draft Thread-Index: Aco3PgJTjuPn2jz85E21fGyCTakYgwAE57LgAAEHVL4AAh2ckA== References: From: "Christer Holmberg" To: "Linyi Tian" , "Sanjay Sinha (sanjsinh)" , X-OriginalArrivalTime: 17 Sep 2009 06:15:54.0357 (UTC) FILETIME=[50164250:01CA375E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 06:15:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA375E.4F7F3EE6 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, A new version of the draft is on its way, which will address the WGLC comments we've received. I BELIEVE we had a similar comment earlier, so we are looking into it. Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi Tian Sent: 17. syyskuuta 2009 8:15 To: Sanjay Sinha (sanjsinh); sipcore@ietf.org Subject: Re: [sipcore] Questions to info events draft Hi, Sanjay Thank you for your feedback. Does It mean that In the MIME body there should be one or more elements Indicates the rate? From the draft Itself It Is not clear to me how this will be done. Should we clarify this In the section 7.8? Cheers, Linyi On 09-9-17 $B2<8a(J12:47, "Sanjay Sinha (sanjsinh)" wrote: I think each INFO event package will specify the rate of requests, whether there should be one INFO for each state change associated with that event or if that information can be buffered and sent one shot. Sanjay ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi Tian Sent: Thursday, September 17, 2009 7:55 AM To: sipcore@ietf.org Subject: [sipcore] Questions to info events draft Hi, All In section 7.8 it talks about the rate of info requests. It is not clear to me where to specify the rate. 1. The first paragraph says that a Info package MUST define a requirement for the maximum rate. Does it mean the rate will be specified in the IANA registration? Or does it mean the INFO body(MIME) should include a parameter for the rate? 2. The second paragraph says that a package MUST define a throttle mechanism. Does it means the INFO body (MIME) needs to specify the mechanism? 7.8. Rate of INFO Requests Each Info Package MUST define a requirement of MUST strength which defines an absolute maximum on the rate at which an Info Package of a given type can generate INFO messages by a UA in a session. If possible, a package MUST define a throttle mechanism that allows UAs to further limit the rate of INFO messages. Cheers, Linyi ________________________________ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ------_=_NextPart_001_01CA375E.4F7F3EE6 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Re: [sipcore] Questions to info events draft
Hi,
 
A new version of the draft is on its way, which will address the WGLC comments we've received. I BELIEVE we had a similar comment earlier, so we are looking into it.
 
Regards,
 
Christer

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi Tian
Sent: 17. syyskuuta 2009 8:15
To: Sanjay Sinha (sanjsinh); sipcore@ietf.org
Subject: Re: [sipcore] Questions to info events draft

Hi, Sanjay

Thank you for your feedback.

Does It mean that In the MIME body there should be one or more elements Indicates the rate? From the draft Itself It Is not clear to me how this will be done. Should we clarify this In the section 7.8?

Cheers,
Linyi


On 09-9-17 $B2<8a(B12:47, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com> wrote:
I think each INFO event package will specify the rate of requests, whether there should be one INFO for each state change associated with that event or if that information can be buffered and sent one shot.

Sanjay

 
From: sipcore-bounces@ietf.org  [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi  Tian
Sent: Thursday, September 17, 2009 7:55 AM
To:  sipcore@ietf.org
Subject: [sipcore] Questions to info events  draft

 
Hi, All

In section 7.8 it talks about the rate  of info requests. It is not clear to me where to specify the rate.
1. The  first paragraph says that a Info package MUST define a requirement for the  maximum rate. Does it mean the rate will be specified in the IANA  registration? Or does it mean the INFO body(MIME) should include a parameter  for the rate?
2. The second paragraph says that a package MUST define a  throttle mechanism. Does it means the INFO body (MIME) needs to specify the  mechanism?

7.8.  Rate of INFO Requests

   Each Info Package MUST define  a requirement of MUST strength which
   defines an absolute  maximum on the rate at which an Info Package of a
   given  type can generate INFO messages by a UA in a  session.

   If possible, a package MUST define a  throttle mechanism that allows
   UAs to further limit the  rate of INFO messages.

Cheers,
Linyi

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
------_=_NextPart_001_01CA375E.4F7F3EE6-- From tianlinyi@huawei.com Wed Sep 16 23:23:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6A83A6951 for ; Wed, 16 Sep 2009 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq24a7HsG6VS for ; Wed, 16 Sep 2009 23:23:58 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5F1583A67A6 for ; Wed, 16 Sep 2009 23:23:58 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300BT8R5BPF@szxga03-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 14:24:47 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300N3NR5B1S@szxga03-in.huawei.com> for sipcore@ietf.org; Thu, 17 Sep 2009 14:24:47 +0800 (CST) Received: from [192.168.100.225] ([211.147.16.239]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ3005IFR57RH@szxml02-in.huawei.com>; Thu, 17 Sep 2009 14:24:47 +0800 (CST) Date: Thu, 17 Sep 2009 14:24:42 +0800 From: Linyi Tian In-reply-to: <6A7DC460-7B5C-4574-9F8B-2A3F1028E37E@softarmor.com> To: Dean Willis Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7BIT Thread-topic: [sipcore] Questions to info events draft Thread-index: Aco3X4qWHF/WxwXdHUK7fv7md5Vl4g== User-Agent: Microsoft-Entourage/12.20.0.090605 Cc: "Sanjay Sinha \(sanjsinh\)" , sipcore@ietf.org Subject: Re: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 06:23:59 -0000 Hi, Dean and Christer Thanks a lot! This clarifies my doubt. One more question, if we want to support suspend/resume capability for Info event that would mean: 1. Send Update with "Recv-Info=nil" and empty body. -- suspend 2. Send Update with "Recv-Info=type" and empty body. -- resume Is this understanding correct? Cheers, Linyi On 09-9-17 $B2<8a(B2:09, "Dean Willis" wrote: > > On Sep 17, 2009, at 12:14 AM, Linyi Tian wrote: > >> Hi, Sanjay >> >> Thank you for your feedback. >> >> Does It mean that In the MIME body there should be one or more >> elements Indicates the rate? From the draft Itself It Is not clear >> to me how this will be done. Should we clarify this In the section >> 7.8? > > > I believe it means that the specification document (generally an RFC) > that defines the INFO package describes the rate and limiter mechanism > used with that INFO package. This rate is not encoded into the MIME; > rather it is a characteristic of the INFO packagetype. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Thu Sep 17 03:48:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E048528C1E8 for ; Thu, 17 Sep 2009 03:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.36 X-Spam-Level: X-Spam-Status: No, score=-5.36 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGAZ-VgY-Jmf for ; Thu, 17 Sep 2009 03:48:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 794BC28C1E9 for ; Thu, 17 Sep 2009 03:48:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7b75ae000003337-6e-4ab213fb5d2f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 3E.07.13111.BF312BA4; Thu, 17 Sep 2009 12:48:27 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 12:47:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 12:47:28 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E643624DC; Thu, 17 Sep 2009 13:47:28 +0300 (EEST) Message-ID: <4AB213C0.6030903@ericsson.com> Date: Thu, 17 Sep 2009 13:47:28 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4A3227D2.4020808@ericsson.com> <4A40853F.8010102@ericsson.com> <4A6D995D.7040609@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2009 10:47:29.0035 (UTC) FILETIME=[4078CDB0:01CA3784] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 10:48:19 -0000 Folks, I did not see any follow-ups on the email below. It is important that we all are on the same page regarding the scope of this work. So, please, comment. Thanks, Gonzalo SIPCORE co-chair DRAGE, Keith (Keith) wrote: > So I would like to see agreement that: > > 1) rfc3625bis implementations are expected to be both forward and backward compatible with RFC 3265 implementations except where changes have been explicitly agreed to solve interoperability problems (i.e. of the order of RFC 3265 was so unclear in what should happen that any judgement of compatibility issues is impossible). This may be obvious to some people, but this is the first bis document we have done for SIP (apart from RFC 3261) and we should definitely state this is the policy. > > 2) Adam tells me that he thinks the list of addressed issues in the Appendixes to this document (which I believe come from various issue trackers like SIPIT) is pretty much complete. I would therefore suggest to take this as the stated scope of the work, unless the WG now identifies other issues. This is both the current Appendix B and Appendix C. > > Note that the scope of the work could always be extended by consensus call later, but we do need to avoid open ended work items where we keep adding new tasks as the work progresses. > > > I would like to understand some of the clause numbering changes in the document, because some of the changes that have occurred are less than helpful in identifying real differences between the two documents. Maybe Adam can talk me through this during IETF. > > Finally there is one requirement in RFC 5367 that updates RFC 3265. What are we going to do with that requirement. > > regards > > Keith > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Monday, July 27, 2009 1:11 PM >> To: SIPCORE >> Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion >> >> Folks, >> >> the WG item version of this draft has just been submitted. I >> would like to see discussions about the scope of this effort, >> per my previous email below. >> >> http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-00.txt >> >> Thanks, >> >> Gonzalo >> SIPCORE co-chair >> >> Gonzalo Camarillo wrote: >>> Hi, >>> >>> based on all the responses received, there is agreement that the WG >>> should work on revising RFC 3265 and that this draft is a good >>> starting point for that. Therefore, I will ask our ADs to add a >>> milestone to revise RFC 3265 and the author of the draft to >> submit it >>> as a SIPCORE WG item. >>> >>> Keith brought up two good questions about the scope of this effort >>> that we need to resolve (while he agrees on a limited-scope update >>> that would preserve backwards compatibility, he would object to a >>> wider scope). The first discussions on this topic need to deal with >>> those questions in order to reach an agreement on the >> actual scope of this effort. >>> Thanks, >>> >>> Gonzalo >>> SIPCORE cochair >>> >>> >>> Gonzalo Camarillo wrote: >>>> Folks, >>>> >>>> since the publication of RFC 3265, we have gotten significant >>>> experience deploying SIP-based notification systems. It has been >>>> proposed to revise RFC 3265 based on that experience. We have two >>>> questions for the WG: >>>> >>>> 1) should we add a milestone to our charter to revise RFC 3265? >>>> >>>> 2) if we add such a milestone, should we take the >> following draft as >>>> the initial WG item for the milestone? >>>> >>>> http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> SIPCORE co-chair >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From eburger@standardstrack.com Thu Sep 17 03:50:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4BE3A67AF for ; Thu, 17 Sep 2009 03:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbNRcW6+3o+S for ; Thu, 17 Sep 2009 03:50:39 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 48F4F3A690D for ; Thu, 17 Sep 2009 03:50:39 -0700 (PDT) Received: from ip68-100-198-133.dc.dc.cox.net ([68.100.198.133] helo=[192.168.2.3]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MoEaF-0007qp-V5; Thu, 17 Sep 2009 03:51:28 -0700 Message-Id: From: Eric Burger To: Linyi Tian In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 06:51:24 -0400 References: X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] Questions to info events draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 10:50:40 -0000 That would work in all cases. However, remember there can be glare, and an INFO might be in flight from the far end. On Sep 17, 2009, at 2:24 AM, Linyi Tian wrote: > Hi, Dean and Christer > > Thanks a lot! This clarifies my doubt. > > One more question, if we want to support suspend/resume capability > for Info > event that would mean: > 1. Send Update with "Recv-Info=nil" and empty body. -- suspend > 2. Send Update with "Recv-Info=type" and empty body. -- resume > > Is this understanding correct? > > Cheers, > Linyi > > > On 09-9-17 $B2<8a(B2:09, "Dean Willis" > wrote: > >> >> On Sep 17, 2009, at 12:14 AM, Linyi Tian wrote: >> >>> Hi, Sanjay >>> >>> Thank you for your feedback. >>> >>> Does It mean that In the MIME body there should be one or more >>> elements Indicates the rate? From the draft Itself It Is not clear >>> to me how this will be done. Should we clarify this In the section >>> 7.8? >> >> >> I believe it means that the specification document (generally an RFC) >> that defines the INFO package describes the rate and limiter >> mechanism >> used with that INFO package. This rate is not encoded into the MIME; >> rather it is a characteristic of the INFO packagetype. >> >> -- >> Dean >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Thu Sep 17 04:01:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3BA3A6936 for ; Thu, 17 Sep 2009 04:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zSD0bGD5MAJ for ; Thu, 17 Sep 2009 04:01:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5EF2C28C16A for ; Thu, 17 Sep 2009 04:01:01 -0700 (PDT) X-AuditID: c1b4fb3e-b7b75ae000003337-9c-4ab2171f407e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DD.78.13111.F1712BA4; Thu, 17 Sep 2009 13:01:51 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 13:01:14 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 13:01:14 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B991224DC; Thu, 17 Sep 2009 14:01:14 +0300 (EEST) Message-ID: <4AB216FA.8060105@ericsson.com> Date: Thu, 17 Sep 2009 14:01:14 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Sparks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2009 11:01:14.0717 (UTC) FILETIME=[2C9DE0D0:01CA3786] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 11:01:05 -0000 Hi Robert, > I found having this WGLC right before and over IETF hindered my ability > for a thorough review from scratch style review. > I suspect others are in the same boat. we issued the WGLC before the IETF in order to take advance of the extra cycles people put in on IETF stuff right before the face-to-face meetings. You seem to think it was a bad idea. Do you have any recommendation on how to time WGLCs so that they are more effective? Thanks, Gonzalo From hannes.tschofenig@nsn.com Thu Sep 17 04:04:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00F93A6AA1 for ; Thu, 17 Sep 2009 04:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHFoilgQvOfG for ; Thu, 17 Sep 2009 04:04:49 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D3CE928C203 for ; Thu, 17 Sep 2009 04:04:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n8HB5X73032345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2009 13:05:34 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n8HB5XmI006820; Thu, 17 Sep 2009 13:05:33 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 13:05:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2009 14:08:25 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501B2DE95@FIESEXC015.nsn-intra.net> In-Reply-To: <4AB216FA.8060105@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) Thread-Index: Aco3hkjXYcfbNTj6QQ68UpBufO8RXgAAJQ/g References: <4AB216FA.8060105@ericsson.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Gonzalo Camarillo" , "Robert Sparks" X-OriginalArrivalTime: 17 Sep 2009 11:05:33.0855 (UTC) FILETIME=[C71332F0:01CA3786] Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 11:04:50 -0000 I also noticed this problem in other working groups. It is particularly bad to have the WGLC during the draft submission period.=20 >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Gonzalo Camarillo >Sent: 17 September, 2009 14:01 >To: Robert Sparks >Cc: sipcore@ietf.org; draft-ietf-sipcore-info-events@tools.ietf.org >Subject: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) > >Hi Robert, > >> I found having this WGLC right before and over IETF hindered my=20 >> ability for a thorough review from scratch style review. >> I suspect others are in the same boat. > >we issued the WGLC before the IETF in order to take advance of=20 >the extra cycles people put in on IETF stuff right before the=20 >face-to-face meetings. You seem to think it was a bad idea. Do=20 >you have any recommendation on how to time WGLCs so that they=20 >are more effective? > >Thanks, > >Gonzalo > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Thu Sep 17 04:07:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAE728C200 for ; Thu, 17 Sep 2009 04:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.493 X-Spam-Level: X-Spam-Status: No, score=-5.493 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ12Uu2Eed2D for ; Thu, 17 Sep 2009 04:07:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B66403A6967 for ; Thu, 17 Sep 2009 04:07:03 -0700 (PDT) X-AuditID: c1b4fb3e-b7b75ae000003337-b4-4ab21889bc4b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 09.49.13111.98812BA4; Thu, 17 Sep 2009 13:07:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 13:07:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2009 13:07:48 +0200 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501B2DE95@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) Thread-Index: Aco3hkjXYcfbNTj6QQ68UpBufO8RXgAAJQ/gAAADncA= References: <4AB216FA.8060105@ericsson.com> <3D3C75174CB95F42AD6BCC56E5555B4501B2DE95@FIESEXC015.nsn-intra.net> From: "Christer Holmberg" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Gonzalo Camarillo" , "Robert Sparks" X-OriginalArrivalTime: 17 Sep 2009 11:07:49.0581 (UTC) FILETIME=[17F957D0:01CA3787] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 11:07:05 -0000 Hi, There is going to be a new version of the document with a number of editorial changes, based on comments received, so I would suggest that those people who haven't looked at the draft yet wait for that. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Tschofenig,=20 > Hannes (NSN - FI/Espoo) > Sent: 17. syyskuuta 2009 14:08 > To: Gonzalo Camarillo; Robert Sparks > Cc: sipcore@ietf.org; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events=20 > WGLC comments) >=20 > I also noticed this problem in other working groups. It is=20 > particularly bad to have the WGLC during the draft submission period.=20 >=20 > >-----Original Message----- > >From: sipcore-bounces@ietf.org > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Gonzalo Camarillo > >Sent: 17 September, 2009 14:01 > >To: Robert Sparks > >Cc: sipcore@ietf.org; draft-ietf-sipcore-info-events@tools.ietf.org > >Subject: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC=20 > comments) > > > >Hi Robert, > > > >> I found having this WGLC right before and over IETF hindered my=20 > >> ability for a thorough review from scratch style review. > >> I suspect others are in the same boat. > > > >we issued the WGLC before the IETF in order to take advance of the=20 > >extra cycles people put in on IETF stuff right before the=20 > face-to-face=20 > >meetings. You seem to think it was a bad idea. Do you have any=20 > >recommendation on how to time WGLCs so that they are more effective? > > > >Thanks, > > > >Gonzalo > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ben@nostrum.com Thu Sep 17 14:17:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C60A3A69E3 for ; Thu, 17 Sep 2009 14:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5GgXpTReMc7 for ; Thu, 17 Sep 2009 14:17:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 86AD43A6821 for ; Thu, 17 Sep 2009 14:17:22 -0700 (PDT) Received: from dn3-213.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8HLHsVZ089232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2009 16:17:54 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2009 16:17:53 -0500 Message-Id: <2EAB1CF8-5FFB-4142-9950-5BBCA7AED5FE@nostrum.com> To: Brian Hibbard Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , ono.kumiko@lab.ntt.co.jp, Robert Sparks Subject: [sipcore] Review of draft-ietf-sipcore-sec-flows-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:17:24 -0000 Hi, Someone pretending to be me agreed to review draft-ietf-sipcore-sec-=20 flows-00 at the SIPCORE meeting in Stockholm. Since the chairs aren't =20= buying my claims of identity theft, here's a review. I've broken it =20 into substantive and editorial sections. I did _not_ attempt mechanical verification of the data and scripts in =20= the draft--this is a human brain only review. ------------------------------------------------- *** Substantive Comments: -- Status: Is this really intended as standards track, rather than informational =20= or possibly BCP? Is there anything normative in this doc? -- Section 3, last paragraph: "This document does not show the =20 messages needed to check Certificate Revocation Lists (see [3]) as =20 that is not part of the SIP call flow" You explicitly list test cases for cert revocation--so I think it =20 would be fair to show them, or at least mention them in the flows. I =20 could argue that the TLS handshake is not part of the SIP flow either. =20= I suspect that one reason not to show them is that their may not be a =20= clear answer as to how to check CRLs--but if that is the case we =20 should shine a light on it. -- Section 4.1: Is "0" a reasonable serial number? The validity has a Not After date of 2013. Does that mean the RFC =20 expires then :-) More importantly, do the certs for testing in the =20 appendix share these dates? If so, I suggest they be set to further in =20= the future. -- Section 4.2: The cert examples don't include chains longer than 2. I don't know if =20= it's really necessary to include examples for non-root issuer certs, =20 but it might be worth throwing in a paragraph that they can exist and =20= how they differ from root or end-entity certs. -- Section 5.2: General I'd like to see a little more about how this MESSAGE request is =20 associated with the TLS session from the handshake example. I think it =20= might actually be useful to show the RFC3263 stuff somewhere, either =20 as an explicit part of the call flow or as a few sentences of =20 explanatory text. A few sentences about how the UA decides whether to =20= create a new TLS session or use an existing one might be helpful. -- Section 5.2, MESSAGE request: Contact: RFC3428 forbids Contact header fields in MESSAGE requests or =20= 2XX responses to MESSAGE. This brings up the question as to whether =20 MESSAGE is a good example, as you may wish to illustrate SIPS rules =20 concerning Contact. (This reoccurs in all MESSAGE and 200 OK examples) CSeq: I suggest a more "random looking" initial CSeq value. -- Same section, 200 OK Contact: There's that Contact again. Also, if you _were_ going to =20 illustrate Contact, I think a SIPS URL rather than "transport=3DTLS" =20 would be appropriate, since the original r-URI was SIPS. -- Section 6.1, first text paragraph at top of page 16: "Also note =20 that the sender=92s certificate is not attached as it is optional in = [8]." It would be instructive to have an example with the certificate =20 included. -- Section 7, title "Observed Interoperability Issues" Who observed them? Is this experience from SIPits, etc? I think it =20 would strengthen the idea that these are real-world, observed-in-the-=20 wild issues to give sources. -- Paragraph 2: "Some SIP clients..." Do mean client class devices, or user agents in general? Does this =20 exclude proxies? (same question throughout section.) -- Paragraph 5: "Implementations should send.... but must be prepared =20= to receive..." Is that intended as a normative statement? -- Last paragraph: I think there's some implicit stuff here that should be explicit. Do =20 you mean to recommend never attaching certs? It's probably worth =20 mentioning the message size limit issue. What do you mean by "it =20 cannot be relied upon"--that you can't rely on the peer sending it, or =20= it is unreliable when the peer does send it? -- Section 8, first bullet entry: "the peer's URI" What URI? An AoR for the user? =46rom or To values? Contacts? Request-=20= URIs? For request URIs, do we need to discuss the effects of retargeting? Do =20= we need to consider some of the current History-Info discussions? -- 2nd bullet: What if all you've got is an IP address? Do we disallow IPAddress =20 entries in SubjectAltName? -- 1st sub-bullet: "(Wildcard matching is not allowed against these dNSName entries)" Is there something that can be referenced here? In particular, RFC2818 =20= explicitly allows wildcards in dNSName entries. It is not obvious to =20 me whether the proscription against wildcards in RFC4474 should apply =20= to general use of TLS, or just to identity. -- section 8, list of tests: What about cases where the basic constraints or allowed uses are not =20 appropriate? Is it worth putting in cases around self-signed certs? =20 (i.e. self-signed cert, explicitly trusted, not trusted, etc.) How =20 about cases where one or more certs in the chain to the root were not =20= provided and not available through other means? -- 13.2 (Informative References) The criteria in this draft for normative vs informative references are =20= not clear to me, particularly in the cases of 17 and 18. OTOH, are =20 any of the references really normative for this draft? Appendix A: Do you expect these scripts to work with all future versions of =20 OpenSSL :-) If not, it may be worth mentioning the latest version =20 that this has been tested with. -- 3rd paragraph from end: "IE, Outlook, and Netscape..." Please give full names and version numbers tested. Also, did you =20 really mean Netscape instead of Firefox? *** Editorial Comments: -- Title: The title is really a bit misleading, as it sounds like an exhaustive =20= set of security flows, when it's really pretty narrow. Something more =20= along the line of "...using SIP with TLS and S/MIME". rather than =20 "...using SIP security mechanisms." might be in order. -- Section 2: I didn't find any 2119 normative language in the draft. If there's no =20= intent to have normative language, please remove section 2 and the =20 2119 reference. -- Section 3: It's odd to see Security Considerations so early. I think rfc2223 =20 requires it to be "near the end". -- Section 5.1, first paragraph: (Personal pet peeve) Please avoid the form "defined in [6]" for =20 references. That may save the author some effort, but creates more =20 effort for the reader to have to flip all over the place. The best approach is "defined in [6]", =20 although I've learned to put up with "defined in [mnemonic =20 reference]". I prefer the former, as the sentence should makes sense =20= with the reference stripped completely. But at least the latter lets =20 the reader know what is being referenced without having to flip to the =20= end of the doc every time. -- Section 5.1, SSLDump output: A bit of explanation of the format whould be helpful. For example, a =20 bit about the C>S vs S>C fields would help. Or maybe a reference to =20 the SSLDump documentation. -- Section 6.1, 1st paragraph: "Example Signed Message." Sentence fragment. -- Section 6.1, first paragraph after example MESSAGE request: The paragraph is ambiguous about which "header", "boundary", and =20 "Content" type you refer to, since all of those occur multiple times =20 in the entire message. I think you are referring to the text/plain =20 sub-part in all cases, but it could be more clear. -- Section 6.1, top of page 16: Here you re-state the contents of the text/plain sub-part I mentioned =20= in the previous comment. But it's not clear from the formatting or =20 text that this is the case--it looks like random orphaned lines. This =20= is aggravated by the poor luck of a page break right before it. I =20 suggest adding some text to the previous example to the effect of "... =20= in the body part shown below:" It would also help to indent or =20 otherwise set off the body part text from the text around it. -- Section 6.1, first non-example paragraph at the top of page 16: =20 "ASN.1 parse of binary Blob 1." Sentence Fragment. -- Section 6.1, top of page 18: "The above dump of Blob 1 has SHA-1 =20 parameters set to NULL. Below are the same contents signed with the =20 same key, but omitting the NULL according to [10]. This is the =20 preferred encoding." I would consider putting the preferred encoding first. (Do you even =20 need an example of the non-preferred encoding?--why not just show the =20= preferred on and mention the non-preferred in text, or in the interop =20= issues section?) -- 6.2, first paragraph: 'Example encrypted text/plain message that =20 says "hello":' Sentence fragment. -- 6.2, "ASN.1 parse of binary Blob 2." Sentence fragment. -- Section 7, Paragraph 4: (starting with "When used with SIP,..." Is this an interop issue? You don't mention whether this is something =20= that devices get wrong. As it stands, it is probably more suited for =20 the SecCons section. 2nd to last paragraph: Another candidate for SecCons. -- Section 8, first paragraph: Calling the section the "beginning of a list" implies you aren't =20 through with it. Perhaps you mean "non-exhaustive", or "an example =20 list" or something else? -- 2nd paragraph: I take this to mean some of this is truly folklore, and some come from =20= bona-fide normative language somewhere. Can you distinguish between =20 the two? The true folklore parts may point to future normative work we =20= need to do. For [16], can you reference the section number? Also, you mention [16] and [17] as normative works, but they are =20 informative references. I don't know if that's a problem, just sayin'... -- section 8, 2nd bullet item: s/"as fed into 3263..."/"from the initial DNS query in the server =20 location process. [RFC3263]" -- Section 12: I suspect this section should be removed from the RFC, as hopefully =20 the issue will be resolved. And since an RFC is written in stone, I'm =20= not sure the maintainability of the examples will matter anymore. -- Appendix A, general: It would be handy to have a table(s) showing file names and contents, =20= rather than having to pick through paragraph streams to find them. -- Appendix A, 3rd paragraph, last sentence: "...filed..." should "filed" be "file"? From ben@nostrum.com Thu Sep 17 14:22:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D473A69FD for ; Thu, 17 Sep 2009 14:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRpmNBOvEgfQ for ; Thu, 17 Sep 2009 14:22:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 17FA63A68EA for ; Thu, 17 Sep 2009 14:22:29 -0700 (PDT) Received: from dn3-213.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8HLN1XU089642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2009 16:23:01 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Ben Campbell In-Reply-To: <2EAB1CF8-5FFB-4142-9950-5BBCA7AED5FE@nostrum.com> Date: Thu, 17 Sep 2009 16:23:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EAB1CF8-5FFB-4142-9950-5BBCA7AED5FE@nostrum.com> To: Brian Hibbard X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , ono.kumiko@lab.ntt.co.jp, Robert Sparks Subject: Re: [sipcore] Review of draft-ietf-sipcore-sec-flows-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:22:32 -0000 I also note that the author's email address ono.kumiko@lab.ntt.co.jp =20 bounced. Is there a newer email address for Kumiko? On Sep 17, 2009, at 4:17 PM, Ben Campbell wrote: > Hi, > > Someone pretending to be me agreed to review draft-ietf-sipcore-sec-=20= > flows-00 at the SIPCORE meeting in Stockholm. Since the chairs =20 > aren't buying my claims of identity theft, here's a review. I've =20 > broken it into substantive and editorial sections. > > I did _not_ attempt mechanical verification of the data and scripts =20= > in the draft--this is a human brain only review. > > > ------------------------------------------------- > > *** Substantive Comments: > > -- Status: > Is this really intended as standards track, rather than =20 > informational or possibly BCP? Is there anything normative in this =20 > doc? > > -- Section 3, last paragraph: "This document does not show the =20 > messages needed to check Certificate Revocation Lists (see [3]) as =20 > that is not part of the SIP call flow" > > You explicitly list test cases for cert revocation--so I think it =20 > would be fair to show them, or at least mention them in the flows. I =20= > could argue that the TLS handshake is not part of the SIP flow =20 > either. I suspect that one reason not to show them is that their may =20= > not be a clear answer as to how to check CRLs--but if that is the =20 > case we should shine a light on it. > > -- Section 4.1: > > Is "0" a reasonable serial number? > > The validity has a Not After date of 2013. Does that mean the RFC =20 > expires then :-) More importantly, do the certs for testing in the =20 > appendix share these dates? If so, I suggest they be set to further =20= > in the future. > > -- Section 4.2: > > The cert examples don't include chains longer than 2. I don't know =20 > if it's really necessary to include examples for non-root issuer =20 > certs, but it might be worth throwing in a paragraph that they can =20 > exist and how they differ from root or end-entity certs. > > -- Section 5.2: General > > I'd like to see a little more about how this MESSAGE request is =20 > associated with the TLS session from the handshake example. I think =20= > it might actually be useful to show the RFC3263 stuff somewhere, =20 > either as an explicit part of the call flow or as a few sentences of =20= > explanatory text. A few sentences about how the UA decides whether =20 > to create a new TLS session or use an existing one might be helpful. > > -- Section 5.2, MESSAGE request: > > Contact: RFC3428 forbids Contact header fields in MESSAGE requests =20 > or 2XX responses to MESSAGE. This brings up the question as to =20 > whether MESSAGE is a good example, as you may wish to illustrate =20 > SIPS rules concerning Contact. (This reoccurs in all MESSAGE and 200 =20= > OK examples) > > CSeq: I suggest a more "random looking" initial CSeq value. > > -- Same section, 200 OK > > Contact: There's that Contact again. Also, if you _were_ going to =20 > illustrate Contact, I think a SIPS URL rather than "transport=3DTLS" =20= > would be appropriate, since the original r-URI was SIPS. > > -- Section 6.1, first text paragraph at top of page 16: "Also note =20 > that the sender=92s certificate is not attached as it is optional in =20= > [8]." > > It would be instructive to have an example with the certificate =20 > included. > > > -- Section 7, title "Observed Interoperability Issues" > > Who observed them? Is this experience from SIPits, etc? I think it =20 > would strengthen the idea that these are real-world, observed-in-the-=20= > wild issues to give sources. > > -- Paragraph 2: "Some SIP clients..." > > Do mean client class devices, or user agents in general? Does this =20 > exclude proxies? (same question throughout section.) > > -- Paragraph 5: "Implementations should send.... but must be =20 > prepared to receive..." > > Is that intended as a normative statement? > > -- Last paragraph: > > I think there's some implicit stuff here that should be explicit. Do =20= > you mean to recommend never attaching certs? It's probably worth =20 > mentioning the message size limit issue. What do you mean by "it =20 > cannot be relied upon"--that you can't rely on the peer sending it, =20= > or it is unreliable when the peer does send it? > > -- Section 8, first bullet entry: "the peer's URI" > > What URI? An AoR for the user? =46rom or To values? Contacts? Request-=20= > URIs? > > For request URIs, do we need to discuss the effects of retargeting? =20= > Do we need to consider some of the current History-Info discussions? > > -- 2nd bullet: > > What if all you've got is an IP address? Do we disallow IPAddress =20 > entries in SubjectAltName? > > -- 1st sub-bullet: "(Wildcard > matching is not allowed against these dNSName entries)" > > Is there something that can be referenced here? In particular, =20 > RFC2818 explicitly allows wildcards in dNSName entries. It is not =20 > obvious to me whether the proscription against wildcards in RFC4474 =20= > should apply to general use of TLS, or just to identity. > > -- section 8, list of tests: > > What about cases where the basic constraints or allowed uses are not =20= > appropriate? Is it worth putting in cases around self-signed certs? =20= > (i.e. self-signed cert, explicitly trusted, not trusted, etc.) How =20 > about cases where one or more certs in the chain to the root were =20 > not provided and not available through other means? > > -- 13.2 (Informative References) > > The criteria in this draft for normative vs informative references =20 > are not clear to me, particularly in the cases of 17 and 18. OTOH, =20= > are any of the references really normative for this draft? > > Appendix A: > > Do you expect these scripts to work with all future versions of =20 > OpenSSL :-) If not, it may be worth mentioning the latest version =20 > that this has been tested with. > > -- 3rd paragraph from end: "IE, Outlook, and Netscape..." > > Please give full names and version numbers tested. Also, did you =20 > really mean Netscape instead of Firefox? > > > > *** Editorial Comments: > > -- Title: > > The title is really a bit misleading, as it sounds like an =20 > exhaustive set of security flows, when it's really pretty narrow. =20 > Something more along the line of "...using SIP with TLS and S/MIME". =20= > rather than "...using SIP security mechanisms." might be in order. > > -- Section 2: > I didn't find any 2119 normative language in the draft. If there's =20 > no intent to have normative language, please remove section 2 and =20 > the 2119 reference. > > -- Section 3: > It's odd to see Security Considerations so early. I think rfc2223 =20 > requires it to be "near the end". > > -- Section 5.1, first paragraph: > > (Personal pet peeve) Please avoid the form "defined in [6]" for =20 > references. That may save the author some effort, but creates more =20 > effort for the reader to have to flip all over the place. > > The best approach is "defined in [6]", =20 > although I've learned to put up with "defined in [mnemonic =20 > reference]". I prefer the former, as the sentence should makes =20 > sense with the reference stripped completely. But at least the =20 > latter lets the reader know what is being referenced without having =20= > to flip to the end of the doc every time. > > -- Section 5.1, SSLDump output: > > A bit of explanation of the format whould be helpful. For example, a =20= > bit about the C>S vs S>C fields would help. Or maybe a reference to =20= > the SSLDump documentation. > > > -- Section 6.1, 1st paragraph: "Example Signed Message." > > Sentence fragment. > > -- Section 6.1, first paragraph after example MESSAGE request: > > The paragraph is ambiguous about which "header", "boundary", and =20 > "Content" type you refer to, since all of those occur multiple times =20= > in the entire message. I think you are referring to the text/plain =20= > sub-part in all cases, but it could be more clear. > > -- Section 6.1, top of page 16: > > Here you re-state the contents of the text/plain sub-part I =20 > mentioned in the previous comment. But it's not clear from the =20 > formatting or text that this is the case--it looks like random =20 > orphaned lines. This is aggravated by the poor luck of a page break =20= > right before it. I suggest adding some text to the previous example =20= > to the effect of "... in the body part shown below:" It would also =20 > help to indent or otherwise set off the body part text from the text =20= > around it. > > -- Section 6.1, first non-example paragraph at the top of page 16: =20 > "ASN.1 parse of binary Blob 1." > > Sentence Fragment. > > -- Section 6.1, top of page 18: "The above dump of Blob 1 has SHA-1 =20= > parameters set to NULL. Below are the same contents signed with the =20= > same key, but omitting the NULL according to [10]. This is the =20 > preferred encoding." > > I would consider putting the preferred encoding first. (Do you even =20= > need an example of the non-preferred encoding?--why not just show =20 > the preferred on and mention the non-preferred in text, or in the =20 > interop issues section?) > > -- 6.2, first paragraph: 'Example encrypted text/plain message that =20= > says "hello":' > > Sentence fragment. > > -- 6.2, "ASN.1 parse of binary Blob 2." > > Sentence fragment. > > -- Section 7, Paragraph 4: (starting with "When used with SIP,..." > > Is this an interop issue? You don't mention whether this is =20 > something that devices get wrong. As it stands, it is probably more =20= > suited for the SecCons section. > > 2nd to last paragraph: > > Another candidate for SecCons. > > -- Section 8, first paragraph: > > Calling the section the "beginning of a list" implies you aren't =20 > through with it. Perhaps you mean "non-exhaustive", or "an example =20 > list" or something else? > > -- 2nd paragraph: > > I take this to mean some of this is truly folklore, and some come =20 > from bona-fide normative language somewhere. Can you distinguish =20 > between the two? The true folklore parts may point to future =20 > normative work we need to do. > > For [16], can you reference the section number? > > Also, you mention [16] and [17] as normative works, but they are =20 > informative references. I don't know if that's a problem, just =20 > sayin'... > > -- section 8, 2nd bullet item: > > s/"as fed into 3263..."/"from the initial DNS query in the server =20 > location process. [RFC3263]" > > -- Section 12: > > I suspect this section should be removed from the RFC, as hopefully =20= > the issue will be resolved. And since an RFC is written in stone, =20 > I'm not sure the maintainability of the examples will matter anymore. > > -- Appendix A, general: > > It would be handy to have a table(s) showing file names and =20 > contents, rather than having to pick through paragraph streams to =20 > find them. > > -- Appendix A, 3rd paragraph, last sentence: "...filed..." > > should "filed" be "file"? > > > > > > > From kumiko@cs.columbia.edu Thu Sep 17 15:07:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4BE3A6A26 for ; Thu, 17 Sep 2009 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeiD7ZP9kxqw for ; Thu, 17 Sep 2009 15:07:44 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id BE9223A6A60 for ; Thu, 17 Sep 2009 15:07:44 -0700 (PDT) Received: from dhcp46.cs.columbia.edu (dhcp46.cs.columbia.edu [128.59.19.246]) (user=ko2155 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n8HM7wNu005702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Sep 2009 18:07:59 -0400 (EDT) Message-Id: <670DE410-5CB7-4D1C-AEF1-B1CE595AEF6E@cs.columbia.edu> From: Kumiko Ono To: Ben Campbell In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 18:07:58 -0400 References: <2EAB1CF8-5FFB-4142-9950-5BBCA7AED5FE@nostrum.com> X-Mailer: Apple Mail (2.936) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: SIPCORE , ono.kumiko@lab.ntt.co.jp, Robert Sparks , Brian Hibbard Subject: Re: [sipcore] Review of draft-ietf-sipcore-sec-flows-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 22:07:46 -0000 My current address is kumiko@cs.columbia.edu and I belong to Columbia =20= Univ. Please update the email and my affiliation. Thanks, Kumiko On Sep 17, 2009, at 5:23 PM, Ben Campbell wrote: > I also note that the author's email address ono.kumiko@lab.ntt.co.jp =20= > bounced. Is there a newer email address for Kumiko? > > On Sep 17, 2009, at 4:17 PM, Ben Campbell wrote: > >> Hi, >> >> Someone pretending to be me agreed to review draft-ietf-sipcore-sec-=20= >> flows-00 at the SIPCORE meeting in Stockholm. Since the chairs =20 >> aren't buying my claims of identity theft, here's a review. I've =20 >> broken it into substantive and editorial sections. >> >> I did _not_ attempt mechanical verification of the data and scripts =20= >> in the draft--this is a human brain only review. >> >> >> ------------------------------------------------- >> >> *** Substantive Comments: >> >> -- Status: >> Is this really intended as standards track, rather than =20 >> informational or possibly BCP? Is there anything normative in this =20= >> doc? >> >> -- Section 3, last paragraph: "This document does not show the =20 >> messages needed to check Certificate Revocation Lists (see [3]) as =20= >> that is not part of the SIP call flow" >> >> You explicitly list test cases for cert revocation--so I think it =20 >> would be fair to show them, or at least mention them in the flows. =20= >> I could argue that the TLS handshake is not part of the SIP flow =20 >> either. I suspect that one reason not to show them is that their =20 >> may not be a clear answer as to how to check CRLs--but if that is =20 >> the case we should shine a light on it. >> >> -- Section 4.1: >> >> Is "0" a reasonable serial number? >> >> The validity has a Not After date of 2013. Does that mean the RFC =20 >> expires then :-) More importantly, do the certs for testing in the =20= >> appendix share these dates? If so, I suggest they be set to further =20= >> in the future. >> >> -- Section 4.2: >> >> The cert examples don't include chains longer than 2. I don't know =20= >> if it's really necessary to include examples for non-root issuer =20 >> certs, but it might be worth throwing in a paragraph that they can =20= >> exist and how they differ from root or end-entity certs. >> >> -- Section 5.2: General >> >> I'd like to see a little more about how this MESSAGE request is =20 >> associated with the TLS session from the handshake example. I think =20= >> it might actually be useful to show the RFC3263 stuff somewhere, =20 >> either as an explicit part of the call flow or as a few sentences =20 >> of explanatory text. A few sentences about how the UA decides =20 >> whether to create a new TLS session or use an existing one might be =20= >> helpful. >> >> -- Section 5.2, MESSAGE request: >> >> Contact: RFC3428 forbids Contact header fields in MESSAGE requests =20= >> or 2XX responses to MESSAGE. This brings up the question as to =20 >> whether MESSAGE is a good example, as you may wish to illustrate =20 >> SIPS rules concerning Contact. (This reoccurs in all MESSAGE and =20 >> 200 OK examples) >> >> CSeq: I suggest a more "random looking" initial CSeq value. >> >> -- Same section, 200 OK >> >> Contact: There's that Contact again. Also, if you _were_ going to =20 >> illustrate Contact, I think a SIPS URL rather than "transport=3DTLS" =20= >> would be appropriate, since the original r-URI was SIPS. >> >> -- Section 6.1, first text paragraph at top of page 16: "Also note =20= >> that the sender=92s certificate is not attached as it is optional in =20= >> [8]." >> >> It would be instructive to have an example with the certificate =20 >> included. >> >> >> -- Section 7, title "Observed Interoperability Issues" >> >> Who observed them? Is this experience from SIPits, etc? I think it =20= >> would strengthen the idea that these are real-world, observed-in-=20 >> the-wild issues to give sources. >> >> -- Paragraph 2: "Some SIP clients..." >> >> Do mean client class devices, or user agents in general? Does this =20= >> exclude proxies? (same question throughout section.) >> >> -- Paragraph 5: "Implementations should send.... but must be =20 >> prepared to receive..." >> >> Is that intended as a normative statement? >> >> -- Last paragraph: >> >> I think there's some implicit stuff here that should be explicit. =20 >> Do you mean to recommend never attaching certs? It's probably worth =20= >> mentioning the message size limit issue. What do you mean by "it =20 >> cannot be relied upon"--that you can't rely on the peer sending it, =20= >> or it is unreliable when the peer does send it? >> >> -- Section 8, first bullet entry: "the peer's URI" >> >> What URI? An AoR for the user? =46rom or To values? Contacts? = Request-=20 >> URIs? >> >> For request URIs, do we need to discuss the effects of retargeting? =20= >> Do we need to consider some of the current History-Info discussions? >> >> -- 2nd bullet: >> >> What if all you've got is an IP address? Do we disallow IPAddress =20 >> entries in SubjectAltName? >> >> -- 1st sub-bullet: "(Wildcard >> matching is not allowed against these dNSName entries)" >> >> Is there something that can be referenced here? In particular, =20 >> RFC2818 explicitly allows wildcards in dNSName entries. It is not =20 >> obvious to me whether the proscription against wildcards in RFC4474 =20= >> should apply to general use of TLS, or just to identity. >> >> -- section 8, list of tests: >> >> What about cases where the basic constraints or allowed uses are =20 >> not appropriate? Is it worth putting in cases around self-signed =20 >> certs? (i.e. self-signed cert, explicitly trusted, not trusted, =20 >> etc.) How about cases where one or more certs in the chain to the =20 >> root were not provided and not available through other means? >> >> -- 13.2 (Informative References) >> >> The criteria in this draft for normative vs informative references =20= >> are not clear to me, particularly in the cases of 17 and 18. OTOH, =20= >> are any of the references really normative for this draft? >> >> Appendix A: >> >> Do you expect these scripts to work with all future versions of =20 >> OpenSSL :-) If not, it may be worth mentioning the latest version =20= >> that this has been tested with. >> >> -- 3rd paragraph from end: "IE, Outlook, and Netscape..." >> >> Please give full names and version numbers tested. Also, did you =20 >> really mean Netscape instead of Firefox? >> >> >> >> *** Editorial Comments: >> >> -- Title: >> >> The title is really a bit misleading, as it sounds like an =20 >> exhaustive set of security flows, when it's really pretty narrow. =20 >> Something more along the line of "...using SIP with TLS and S/=20 >> MIME". rather than "...using SIP security mechanisms." might be in =20= >> order. >> >> -- Section 2: >> I didn't find any 2119 normative language in the draft. If there's =20= >> no intent to have normative language, please remove section 2 and =20 >> the 2119 reference. >> >> -- Section 3: >> It's odd to see Security Considerations so early. I think rfc2223 =20 >> requires it to be "near the end". >> >> -- Section 5.1, first paragraph: >> >> (Personal pet peeve) Please avoid the form "defined in [6]" for =20 >> references. That may save the author some effort, but creates more =20= >> effort for the reader to have to flip all over the place. >> >> The best approach is "defined in [6]", =20 >> although I've learned to put up with "defined in [mnemonic =20 >> reference]". I prefer the former, as the sentence should makes =20 >> sense with the reference stripped completely. But at least the =20 >> latter lets the reader know what is being referenced without having =20= >> to flip to the end of the doc every time. >> >> -- Section 5.1, SSLDump output: >> >> A bit of explanation of the format whould be helpful. For example, =20= >> a bit about the C>S vs S>C fields would help. Or maybe a reference =20= >> to the SSLDump documentation. >> >> >> -- Section 6.1, 1st paragraph: "Example Signed Message." >> >> Sentence fragment. >> >> -- Section 6.1, first paragraph after example MESSAGE request: >> >> The paragraph is ambiguous about which "header", "boundary", and =20 >> "Content" type you refer to, since all of those occur multiple =20 >> times in the entire message. I think you are referring to the text/=20= >> plain sub-part in all cases, but it could be more clear. >> >> -- Section 6.1, top of page 16: >> >> Here you re-state the contents of the text/plain sub-part I =20 >> mentioned in the previous comment. But it's not clear from the =20 >> formatting or text that this is the case--it looks like random =20 >> orphaned lines. This is aggravated by the poor luck of a page break =20= >> right before it. I suggest adding some text to the previous example =20= >> to the effect of "... in the body part shown below:" It would also =20= >> help to indent or otherwise set off the body part text from the =20 >> text around it. >> >> -- Section 6.1, first non-example paragraph at the top of page 16: =20= >> "ASN.1 parse of binary Blob 1." >> >> Sentence Fragment. >> >> -- Section 6.1, top of page 18: "The above dump of Blob 1 has SHA-1 =20= >> parameters set to NULL. Below are the same contents signed with the =20= >> same key, but omitting the NULL according to [10]. This is the =20 >> preferred encoding." >> >> I would consider putting the preferred encoding first. (Do you even =20= >> need an example of the non-preferred encoding?--why not just show =20 >> the preferred on and mention the non-preferred in text, or in the =20 >> interop issues section?) >> >> -- 6.2, first paragraph: 'Example encrypted text/plain message that =20= >> says "hello":' >> >> Sentence fragment. >> >> -- 6.2, "ASN.1 parse of binary Blob 2." >> >> Sentence fragment. >> >> -- Section 7, Paragraph 4: (starting with "When used with SIP,..." >> >> Is this an interop issue? You don't mention whether this is =20 >> something that devices get wrong. As it stands, it is probably more =20= >> suited for the SecCons section. >> >> 2nd to last paragraph: >> >> Another candidate for SecCons. >> >> -- Section 8, first paragraph: >> >> Calling the section the "beginning of a list" implies you aren't =20 >> through with it. Perhaps you mean "non-exhaustive", or "an example =20= >> list" or something else? >> >> -- 2nd paragraph: >> >> I take this to mean some of this is truly folklore, and some come =20 >> from bona-fide normative language somewhere. Can you distinguish =20 >> between the two? The true folklore parts may point to future =20 >> normative work we need to do. >> >> For [16], can you reference the section number? >> >> Also, you mention [16] and [17] as normative works, but they are =20 >> informative references. I don't know if that's a problem, just =20 >> sayin'... >> >> -- section 8, 2nd bullet item: >> >> s/"as fed into 3263..."/"from the initial DNS query in the server =20 >> location process. [RFC3263]" >> >> -- Section 12: >> >> I suspect this section should be removed from the RFC, as hopefully =20= >> the issue will be resolved. And since an RFC is written in stone, =20 >> I'm not sure the maintainability of the examples will matter anymore. >> >> -- Appendix A, general: >> >> It would be handy to have a table(s) showing file names and =20 >> contents, rather than having to pick through paragraph streams to =20 >> find them. >> >> -- Appendix A, 3rd paragraph, last sentence: "...filed..." >> >> should "filed" be "file"? >> >> >> >> >> >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Mon Sep 21 06:36:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5D53A6922 for ; Mon, 21 Sep 2009 06:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faUER2P3MFer for ; Mon, 21 Sep 2009 06:36:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DB95E3A67E7 for ; Mon, 21 Sep 2009 06:36:37 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8LDbX4b097381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 08:37:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AB7819D.8020407@nostrum.com> Date: Mon, 21 Sep 2009 08:37:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4A3227D2.4020808@ericsson.com> <4A40853F.8010102@ericsson.com> <4A6D995D.7040609@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 13:36:39 -0000 [as an individual] On 7/27/09 09:09, Jul 27, DRAGE, Keith (Keith) wrote: > 1) rfc3625bis implementations are expected to be both forward and backward compatible with RFC 3265 implementations except where changes have been explicitly agreed to solve interoperability problems (i.e. of the order of RFC 3265 was so unclear in what should happen that any judgement of compatibility issues is impossible). This may be obvious to some people, but this is the first bis document we have done for SIP (apart from RFC 3261) and we should definitely state this is the policy. > I agree with this principle. You will see this, for example, reflected in section 4.5.2 of the current draft. > 2) Adam tells me that he thinks the list of addressed issues in the Appendixes to this document (which I believe come from various issue trackers like SIPIT) is pretty much complete. I would therefore suggest to take this as the stated scope of the work, unless the WG now identifies other issues. This is both the current Appendix B and Appendix C. > I agree with this scope. > I would like to understand some of the clause numbering changes in the document, because some of the changes that have occurred are less than helpful in identifying real differences between the two documents. Maybe Adam can talk me through this during IETF. > 3265 was broken up along protocol lines ("Here's how you do SUBSCRIBE. Now, here's how you do NOTIFY"). Based on implementor feedback, I've rearranged the bis along implementation lines ("Here's what a subscriber does. Here's what a notifier does"). This saves implementors the work of digging through normative behavior for things they're not interested in. > Finally there is one requirement in RFC 5367 that updates RFC 3265. What are we going to do with that requirement. > I presume you mean inclusion of Call-Info in NOTIFY? We should probably put that in 3265bis. /a From rjsparks@nostrum.com Mon Sep 21 07:13:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38853A67C0 for ; Mon, 21 Sep 2009 07:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71PNEXLx2tDA for ; Mon, 21 Sep 2009 07:13:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 956F628C119 for ; Mon, 21 Sep 2009 07:13:04 -0700 (PDT) Received: from [192.168.2.2] (pool-173-71-53-15.dllstx.fios.verizon.net [173.71.53.15]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8LEE1Nv000191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Sep 2009 09:14:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Gonzalo Camarillo In-Reply-To: <4AB216FA.8060105@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 09:14:00 -0500 References: <4AB216FA.8060105@ericsson.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.53.15 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:13:05 -0000 Inline. On Sep 17, 2009, at 6:01 AM, Gonzalo Camarillo wrote: > Hi Robert, > >> I found having this WGLC right before and over IETF hindered my >> ability for a thorough review from scratch style review. >> I suspect others are in the same boat. > > we issued the WGLC before the IETF in order to take advance of the > extra cycles people put in on IETF stuff right before the face-to- > face meetings. > You seem to think it was a bad idea. To be perfectly clear - I understand what you were trying to do and I was providing you feedback that it didn't work (at least for me). How many reviews did you get as a result of that LC? > Do you have any recommendation on how to time WGLCs so that they are > more effective? I don't think there's a generic answer to that question. It's going to depend on the document and the set of people who really should be reviewing it. While timing is a good knob to pay attention to, I don't think we're going to find one setting we can leave it in. The bigger question this is a part of is making WGLCs more effective whenever they are issued. For this particular document, I suspect we're down to asking people to commit to reviews. > > Thanks, > > Gonzalo > From dean.willis@softarmor.com Mon Sep 21 20:18:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF13A3A698E for ; Mon, 21 Sep 2009 20:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UX2jqzZljU4 for ; Mon, 21 Sep 2009 20:18:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2C7E93A68F9 for ; Mon, 21 Sep 2009 20:18:56 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8M3JrAS030056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Sep 2009 22:19:55 -0500 Message-Id: From: Dean Willis To: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 22:19:48 -0500 References: <4AB216FA.8060105@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 03:18:57 -0000 On Sep 21, 2009, at 9:14 AM, Robert Sparks wrote: > Inline. > > On Sep 17, 2009, at 6:01 AM, Gonzalo Camarillo wrote: > >> Hi Robert, >> >>> I found having this WGLC right before and over IETF hindered my >>> ability for a thorough review from scratch style review. >>> I suspect others are in the same boat. >> >> we issued the WGLC before the IETF in order to take advance of the >> extra cycles people put in on IETF stuff right before the face-to- >> face meetings. >> You seem to think it was a bad idea. > > To be perfectly clear - I understand what you were trying to do and > I was providing you feedback that it didn't work (at least for me). > How many reviews did you get as a result of that LC? In all honesty, we almost never get any real reviews for a WGLC unless the chairs go out and task somebody to do such a review. But sometimes, we get consensus. Which is more valuable? -- Dean From tianlinyi@huawei.com Mon Sep 21 20:53:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFFC3A68A5 for ; Mon, 21 Sep 2009 20:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRuWgTQI9Tf4 for ; Mon, 21 Sep 2009 20:53:00 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7F6403A67F3 for ; Mon, 21 Sep 2009 20:53:00 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQC00960TI0IF@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 11:54:01 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQC00K4XTI038@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 11:54:00 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQC00EBLTI0F8@szxml06-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 11:54:00 +0800 (CST) Date: Tue, 22 Sep 2009 11:54:00 +0800 From: Linyi TIAN To: sipcore@ietf.org Message-id: <014801ca3b38$51ab7940$f5026bc0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3TgfDK6wK2ohoRqY2gcigQ)" Content-language: zh-cn Thread-index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5g== Subject: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 03:53:03 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_3TgfDK6wK2ohoRqY2gcigQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, All I have a general question about the guidance when to use SIP INFO and SIP INFO-Package. If a MIME can clearly states its application usage, do we still need to use SIP INFO-Package? Is there any guidance on this? Compared between the old SIP INFO and new SIP INFO (without info event framework), is "Info-Package" header the only difference? Cheers, Linyi --Boundary_(ID_3TgfDK6wK2ohoRqY2gcigQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, All

 

I have a general question about = the guidance when to use SIP INFO and SIP = INFO-Package.

 

If a MIME can clearly states its application usage, do we still need to use SIP INFO-Package? Is there = any guidance on this?

 

Compared between the old SIP = INFO and new SIP INFO (without info event framework), is “Info-Package” = header the only difference?

 

Cheers,

Linyi

--Boundary_(ID_3TgfDK6wK2ohoRqY2gcigQ)-- From christer.holmberg@ericsson.com Mon Sep 21 22:06:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA263A6831 for ; Mon, 21 Sep 2009 22:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVTtXzlIrMFp for ; Mon, 21 Sep 2009 22:06:42 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9DBC83A68A5 for ; Mon, 21 Sep 2009 22:06:42 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-62-4ab85ba0d483 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 43.2E.22406.0AB58BA4; Tue, 22 Sep 2009 07:07:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 07:06:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 07:06:30 +0200 Message-ID: In-Reply-To: <014801ca3b38$51ab7940$f5026bc0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gACfSvw References: <014801ca3b38$51ab7940$f5026bc0$@com> From: "Christer Holmberg" To: "Linyi TIAN" , X-OriginalArrivalTime: 22 Sep 2009 05:06:30.0192 (UTC) FILETIME=[721DDB00:01CA3B42] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 05:06:43 -0000 Hi, The guidance is: If you are coming up with a new usage of INFO, use Info-Package - no matter if you could claim that the Content-Type etc tells it all. Hopefully the next version of the draft will be more clear on this. Regards, Christer=20 From christer.holmberg@ericsson.com Mon Sep 21 22:08:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D10C3A67D2 for ; Mon, 21 Sep 2009 22:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsmNlGUuvQvo for ; Mon, 21 Sep 2009 22:08:23 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8FD943A6783 for ; Mon, 21 Sep 2009 22:08:22 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-29-4ab85c0494d8 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 6A.4E.22406.40C58BA4; Tue, 22 Sep 2009 07:09:24 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 07:08:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 07:08:39 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) Thread-Index: Aco7M5RKA/Y/vwUdS+SVweo1i5WXoAADukgg References: <4AB216FA.8060105@ericsson.com> From: "Christer Holmberg" To: "Dean Willis" , "Robert Sparks" X-OriginalArrivalTime: 22 Sep 2009 05:08:40.0320 (UTC) FILETIME=[BFADD000:01CA3B42] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 05:08:24 -0000 Hi, Regarding info-events, at least Robert provided very good comments on the previous version on the draft. Other people provided very good comments on the version before that, eventhough we weren't yet in WGLC at that point (AFAIK). Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 22. syyskuuta 2009 6:20 > To: Robert Sparks > Cc: sipcore@ietf.org; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] Timing of WGLCs WAS (Re: info-events=20 > WGLC comments) >=20 >=20 > On Sep 21, 2009, at 9:14 AM, Robert Sparks wrote: >=20 > > Inline. > > > > On Sep 17, 2009, at 6:01 AM, Gonzalo Camarillo wrote: > > > >> Hi Robert, > >> > >>> I found having this WGLC right before and over IETF hindered my=20 > >>> ability for a thorough review from scratch style review. > >>> I suspect others are in the same boat. > >> > >> we issued the WGLC before the IETF in order to take advance of the=20 > >> extra cycles people put in on IETF stuff right before the face-to-=20 > >> face meetings. > >> You seem to think it was a bad idea. > > > > To be perfectly clear - I understand what you were trying=20 > to do and I=20 > > was providing you feedback that it didn't work (at least for me). > > How many reviews did you get as a result of that LC? >=20 > In all honesty, we almost never get any real reviews for a=20 > WGLC unless the chairs go out and task somebody to do such a=20 > review. But sometimes, we get consensus. Which is more valuable? >=20 > -- > Dean >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From sanjsinh@cisco.com Mon Sep 21 22:19:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4AC3A690D for ; Mon, 21 Sep 2009 22:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVtmZCOUZaUB for ; Mon, 21 Sep 2009 22:19:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9D64A3A68A5 for ; Mon, 21 Sep 2009 22:19:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEANf7t0qrR7PD/2dsb2JhbACCKiu6NohQAY8oBYQb X-IronPort-AV: E=Sophos;i="4.44,429,1249257600"; d="scan'208,217";a="244925331" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2009 05:20:29 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8M5KTmK021443; Mon, 21 Sep 2009 22:20:29 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8M5KTu5008365; Tue, 22 Sep 2009 05:20:29 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 01:20:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA3B44.65CC868B" Date: Tue, 22 Sep 2009 01:20:25 -0400 Message-ID: In-Reply-To: <014801ca3b38$51ab7940$f5026bc0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681A References: <014801ca3b38$51ab7940$f5026bc0$@com> From: "Sanjay Sinha (sanjsinh)" To: "Linyi TIAN" , X-OriginalArrivalTime: 22 Sep 2009 05:20:28.0939 (UTC) FILETIME=[660C7DB0:01CA3B44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8689; t=1253596829; x=1254460829; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20When=20to=20use=20SIP=20INF O=20and=20SIP=20INFO-Package |Sender:=20; bh=2m2i6rHaN4/gIjg0VOz7gF5Tav/6OMOq6jOQ9NrtJjI=; b=rRiM2L5mzr4fjSi/N9f1z2Wh4hJ+94HUlccYyO7X8Vq3IdLjOeyHWiwn0C ioKez7eD3XDKMjvnaaYOnFCSkxiLiMiX1VGgOT6CITfBkEBUOwqCZOiaPHIe Cyvd8mUzeM; Authentication-Results: sj-dkim-3; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 05:19:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3B44.65CC868B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe there were couple of usages which could use legacy INFO: tunnel ISDN content and provide out of band DTMF. All other should use the new info package. =20 Sanjay ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN Sent: Tuesday, September 22, 2009 9:24 AM To: sipcore@ietf.org Subject: [sipcore] When to use SIP INFO and SIP INFO-Package =09 =09 Hi, All =20 I have a general question about the guidance when to use SIP INFO and SIP INFO-Package. =20 If a MIME can clearly states its application usage, do we still need to use SIP INFO-Package? Is there any guidance on this? =20 Compared between the old SIP INFO and new SIP INFO (without info event framework), is "Info-Package" header the only difference? =20 Cheers, Linyi ------_=_NextPart_001_01CA3B44.65CC868B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe there were couple of usages which = could use=20 legacy INFO: tunnel ISDN content and provide out of band DTMF. All other = should=20 use the new info package.
 
Sanjay

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi=20 TIAN
Sent: Tuesday, September 22, 2009 9:24 AM
To: = sipcore@ietf.org
Subject: [sipcore] When to use SIP INFO and = SIP=20 INFO-Package

Hi, All

 

I have a general question = about the=20 guidance when to use SIP INFO and SIP = INFO-Package.

 

If a MIME can clearly states = its=20 application usage, do we still need to use SIP INFO-Package? Is there = any=20 guidance on this?

 

Compared between the old SIP = INFO and new=20 SIP INFO (without info event framework), is “Info-Package” = header the only=20 difference?

 

Cheers,

Linyi

= ------_=_NextPart_001_01CA3B44.65CC868B-- From tianlinyi@huawei.com Mon Sep 21 23:22:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAB33A6783 for ; Mon, 21 Sep 2009 23:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+LpW2xlgxTF for ; Mon, 21 Sep 2009 23:22:49 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 91E963A67B5 for ; Mon, 21 Sep 2009 23:22:49 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00L8L0FQB2@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 14:23:50 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00IYJ0FQVJ@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 14:23:50 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD007DF0FLH9@szxml06-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 14:23:50 +0800 (CST) Date: Tue, 22 Sep 2009 14:23:45 +0800 From: Linyi TIAN In-reply-to: To: "'Sanjay Sinha (sanjsinh)'" , sipcore@ietf.org Message-id: <016201ca3b4d$3fc6e380$bf54aa80$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MITSvCUKdQT49dNWgneVLg)" Content-language: zh-cn Thread-index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sA= References: <014801ca3b38$51ab7940$f5026bc0$@com> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 06:22:53 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_MITSvCUKdQT49dNWgneVLg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, All It is not clear to me why we need to use the new INFO method when the content type can clearly indicate its application usage. What is the benefit in this case for Info-Package header? I didn't see the difference with tunnel ISDN usage. Cheers, Linyi From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Sanjay Sinha (sanjsinh) Sent: Tuesday, September 22, 2009 1:20 PM To: Linyi TIAN; sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package I believe there were couple of usages which could use legacy INFO: tunnel ISDN content and provide out of band DTMF. All other should use the new info package. Sanjay _____ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN Sent: Tuesday, September 22, 2009 9:24 AM To: sipcore@ietf.org Subject: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, All I have a general question about the guidance when to use SIP INFO and SIP INFO-Package. If a MIME can clearly states its application usage, do we still need to use SIP INFO-Package? Is there any guidance on this? Compared between the old SIP INFO and new SIP INFO (without info event framework), is "Info-Package" header the only difference? Cheers, Linyi --Boundary_(ID_MITSvCUKdQT49dNWgneVLg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, All

 

It is not clear to me why we need to use the new INFO method = when the content type can clearly indicate its application usage. What is the benefit in this case for Info-Package header? I didn’t see the = difference with tunnel ISDN usage.

 

Cheers,

Linyi

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Sanjay Sinha = (sanjsinh)
Sent: Tuesday, September 22, 2009 1:20 PM
To: Linyi TIAN; sipcore@ietf.org
Subject: Re: [sipcore] When to use SIP INFO and SIP = INFO-Package

 

I believe there were couple of usages which could use legacy = INFO: tunnel ISDN content and provide out of band DTMF. All other should use = the new info package.

 

Sanjay

 

From:= sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Linyi TIAN
Sent: Tuesday, September 22, 2009 9:24 AM
To: sipcore@ietf.org
Subject: [sipcore] When to use SIP INFO and SIP = INFO-Package

Hi, All

 

I have a general question about the guidance when to use = SIP INFO and SIP INFO-Package.

 

If a MIME can clearly states its application usage, do we = still need to use SIP INFO-Package? Is there any guidance on = this?

 

Compared between the old SIP INFO and new SIP INFO (without = info event framework), is “Info-Package” header the only = difference?

 

Cheers,

Linyi

--Boundary_(ID_MITSvCUKdQT49dNWgneVLg)-- From christer.holmberg@ericsson.com Mon Sep 21 23:47:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DED3A67B5 for ; Mon, 21 Sep 2009 23:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.535 X-Spam-Level: X-Spam-Status: No, score=-5.535 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGYHn4LSMbe2 for ; Mon, 21 Sep 2009 23:47:19 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C3DF43A6783 for ; Mon, 21 Sep 2009 23:47:18 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-4d-4ab8733467d2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 76.D2.22406.43378BA4; Tue, 22 Sep 2009 08:48:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 08:46:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 08:46:49 +0200 Message-ID: In-Reply-To: <016201ca3b4d$3fc6e380$bf54aa80$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcA== References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Sanjay Sinha (sanjsinh)" , X-OriginalArrivalTime: 22 Sep 2009 06:46:50.0909 (UTC) FILETIME=[76BE5CD0:01CA3B50] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 06:47:20 -0000 Hi,=20 >It is not clear to me why we need to use the new INFO method when the content type can clearly indicate its application usage. What is the benefit in this case for Info-Package header? I didn't=20 >see the difference with tunnel ISDN usage. We had long discussions about that, and the outcome and compromise was the introduction of Info Packages. But, again, you are not required to change current INFO usages (without Packages). Regards, Christer =20 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Sanjay Sinha (sanjsinh) Sent: Tuesday, September 22, 2009 1:20 PM To: Linyi TIAN; sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package =20 I believe there were couple of usages which could use legacy INFO: tunnel ISDN content and provide out of band DTMF. All other should use the new info package. =20 Sanjay =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN Sent: Tuesday, September 22, 2009 9:24 AM To: sipcore@ietf.org Subject: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, All =20 I have a general question about the guidance when to use SIP INFO and SIP INFO-Package. =20 If a MIME can clearly states its application usage, do we still need to use SIP INFO-Package? Is there any guidance on this? =20 Compared between the old SIP INFO and new SIP INFO (without info event framework), is "Info-Package" header the only difference? =20 Cheers, Linyi From tianlinyi@huawei.com Tue Sep 22 00:23:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DF43A68C4 for ; Tue, 22 Sep 2009 00:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NreGVFB2SUXt for ; Tue, 22 Sep 2009 00:23:47 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 70A663A6858 for ; Tue, 22 Sep 2009 00:23:47 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00NLB3942V@szxga03-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 15:24:40 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD006P039477@szxga03-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 15:24:40 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD00H0B393CC@szxml06-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 15:24:39 +0800 (CST) Date: Tue, 22 Sep 2009 15:24:39 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , "'Sanjay Sinha (sanjsinh)'" , sipcore@ietf.org Message-id: <018e01ca3b55$bf298a30$3d7c9e90$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2A References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 07:23:48 -0000 Hi, Christer I was confused. In the scenario I described I don't see the need to use new SIP INFO method. What is the context for this compromise? As far as I understand there has to be benefit to reach compromise. It is obviously this is not the case, right? I hope this can be clarified in the new draft as a guidance. Maybe we can say when MIME is clear enough then old SIP INFO could be enough. When MIME is not clear enough or negotiation mechanism is needed then the new SIP INFO and framework is needed. Cheers, Linyi -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, September 22, 2009 2:47 PM To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, >It is not clear to me why we need to use the new INFO method when the content type can clearly indicate its application usage. What is the benefit in this case for Info-Package header? I didn't >see the difference with tunnel ISDN usage. We had long discussions about that, and the outcome and compromise was the introduction of Info Packages. But, again, you are not required to change current INFO usages (without Packages). Regards, Christer From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Sanjay Sinha (sanjsinh) Sent: Tuesday, September 22, 2009 1:20 PM To: Linyi TIAN; sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package I believe there were couple of usages which could use legacy INFO: tunnel ISDN content and provide out of band DTMF. All other should use the new info package. Sanjay ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN Sent: Tuesday, September 22, 2009 9:24 AM To: sipcore@ietf.org Subject: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, All I have a general question about the guidance when to use SIP INFO and SIP INFO-Package. If a MIME can clearly states its application usage, do we still need to use SIP INFO-Package? Is there any guidance on this? Compared between the old SIP INFO and new SIP INFO (without info event framework), is "Info-Package" header the only difference? Cheers, Linyi From christer.holmberg@ericsson.com Tue Sep 22 00:36:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72FD03A683D for ; Tue, 22 Sep 2009 00:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qHnhMRuENf8 for ; Tue, 22 Sep 2009 00:36:31 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EC9A73A6850 for ; Tue, 22 Sep 2009 00:36:30 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-84-4ab87ebc4f26 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 84.B6.22406.CBE78BA4; Tue, 22 Sep 2009 09:37:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:37:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 09:37:31 +0200 Message-ID: In-Reply-To: <018e01ca3b55$bf298a30$3d7c9e90$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2AAAB34bA= References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Sanjay Sinha (sanjsinh)" , X-OriginalArrivalTime: 22 Sep 2009 07:37:32.0575 (UTC) FILETIME=[8BB7C2F0:01CA3B57] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 07:36:32 -0000 Hi,=20 >I was confused. In the scenario I described I don't see the=20 >need to use new SIP INFO method. What is the context for this=20 >compromise? As far as I understand there has to be benefit to=20 >reach compromise. It is obviously this is not the case, right?=20 > >I hope this can be clarified in the new draft as a guidance.=20 >Maybe we can say when MIME is clear enough then old SIP INFO=20 >could be enough. When MIME is not clear enough or negotiation=20 >mechanism is needed then the new SIP INFO and framework is needed.=20 And how do you know that everyone will have the same understanding of the MIME as you? Now, I agree that for ISDN there probably is not an issue. Also, I think that ISDN tunneling with INFO already exists, so there should be no need to define an Info Package for that. But, the draft talks about sending a jpeg as an example. Even if you support jpegs, sending it without any associated context makes it quite difficult for the receiver to know what you want him to do with it. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, September 22, 2009 2:47 PM > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 >=20 > Hi,=20 >=20 > >It is not clear to me why we need to use the new INFO method when the > content type can clearly indicate its application usage. What is the > benefit in this case for Info-Package header? I didn't=20 > >see the difference with tunnel ISDN usage. >=20 > We had long discussions about that, and the outcome and compromise was > the introduction of Info Packages. >=20 > But, again, you are not required to change current INFO=20 > usages (without > Packages). >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > On Behalf Of Sanjay Sinha (sanjsinh) > Sent: Tuesday, September 22, 2009 1:20 PM > To: Linyi TIAN; sipcore@ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 > =20 >=20 > I believe there were couple of usages which could use legacy > INFO: tunnel ISDN content and provide out of band DTMF. All=20 > other should > use the new info package. >=20 > =20 >=20 > Sanjay >=20 > =20 >=20 > ________________________________ >=20 > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > Sent: Tuesday, September 22, 2009 9:24 AM > To: sipcore@ietf.org > Subject: [sipcore] When to use SIP INFO and SIP > INFO-Package >=20 > Hi, All >=20 > =20 >=20 > I have a general question about the guidance when to use > SIP INFO and SIP INFO-Package. >=20 > =20 >=20 > If a MIME can clearly states its application usage, do > we still need to use SIP INFO-Package? Is there any guidance on this? >=20 > =20 >=20 > Compared between the old SIP INFO and new SIP INFO > (without info event framework), is "Info-Package" header the only > difference? >=20 > =20 >=20 > Cheers, >=20 > Linyi >=20 >=20 From christer.holmberg@ericsson.com Tue Sep 22 00:42:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44C73A68C7 for ; Tue, 22 Sep 2009 00:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.559 X-Spam-Level: X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgsb4BhwzHiC for ; Tue, 22 Sep 2009 00:42:50 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 184633A69B1 for ; Tue, 22 Sep 2009 00:42:35 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-a3-4ab88029d756 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 3B.17.22406.92088BA4; Tue, 22 Sep 2009 09:43:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:43:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 09:43:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2AAAB34bAAADuUsA== References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com> From: "Christer Holmberg" To: "Christer Holmberg" , "Linyi TIAN" , "Sanjay Sinha (sanjsinh)" , X-OriginalArrivalTime: 22 Sep 2009 07:43:37.0111 (UTC) FILETIME=[64FF8A70:01CA3B58] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 07:42:52 -0000 In addition, IETF can not prevent you from using INFO in any way you want :) The reason we are providing the Info Package mechanism is to try to solve lots of the interop problems that have occured with the usage of legacy INFO. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 22. syyskuuta 2009 10:38 > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 >=20 > Hi,=20 >=20 > >I was confused. In the scenario I described I don't see the=20 > need to use=20 > >new SIP INFO method. What is the context for this=20 > compromise? As far as=20 > >I understand there has to be benefit to reach compromise. It is=20 > >obviously this is not the case, right? > > > >I hope this can be clarified in the new draft as a guidance.=20 > >Maybe we can say when MIME is clear enough then old SIP INFO=20 > could be=20 > >enough. When MIME is not clear enough or negotiation mechanism is=20 > >needed then the new SIP INFO and framework is needed. >=20 > And how do you know that everyone will have the same=20 > understanding of the MIME as you? >=20 > Now, I agree that for ISDN there probably is not an issue.=20 > Also, I think that ISDN tunneling with INFO already exists,=20 > so there should be no need to define an Info Package for that. >=20 > But, the draft talks about sending a jpeg as an example. Even=20 > if you support jpegs, sending it without any associated=20 > context makes it quite difficult for the receiver to know=20 > what you want him to do with it. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, September 22, 2009 2:47 PM > > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > >=20 > >=20 > > Hi, > >=20 > > >It is not clear to me why we need to use the new INFO=20 > method when the > > content type can clearly indicate its application usage.=20 > What is the=20 > > benefit in this case for Info-Package header? I didn't > > >see the difference with tunnel ISDN usage. > >=20 > > We had long discussions about that, and the outcome and=20 > compromise was=20 > > the introduction of Info Packages. > >=20 > > But, again, you are not required to change current INFO usages=20 > > (without Packages). > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > =20 > >=20 > > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Sanjay Sinha (sanjsinh) > > Sent: Tuesday, September 22, 2009 1:20 PM > > To: Linyi TIAN; sipcore@ietf.org > > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >=20 > > =20 > >=20 > > I believe there were couple of usages which could use legacy > > INFO: tunnel ISDN content and provide out of band DTMF. All other=20 > > should use the new info package. > >=20 > > =20 > >=20 > > Sanjay > >=20 > > =20 > >=20 > > ________________________________ > >=20 > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > > Sent: Tuesday, September 22, 2009 9:24 AM > > To: sipcore@ietf.org > > Subject: [sipcore] When to use SIP INFO and SIP=20 > INFO-Package > >=20 > > Hi, All > >=20 > > =20 > >=20 > > I have a general question about the guidance=20 > when to use SIP INFO=20 > > and SIP INFO-Package. > >=20 > > =20 > >=20 > > If a MIME can clearly states its application=20 > usage, do we still need=20 > > to use SIP INFO-Package? Is there any guidance on this? > >=20 > > =20 > >=20 > > Compared between the old SIP INFO and new SIP=20 > INFO (without info=20 > > event framework), is "Info-Package" header the only difference? > >=20 > > =20 > >=20 > > Cheers, > >=20 > > Linyi > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From tianlinyi@huawei.com Tue Sep 22 01:07:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E34A3A69B9 for ; Tue, 22 Sep 2009 01:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QsV1vUEepgR for ; Tue, 22 Sep 2009 01:07:33 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7ADFD3A695E for ; Tue, 22 Sep 2009 01:07:33 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD006W25AAQZ@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 16:08:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00C805AAPW@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 16:08:34 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD004TY5AA6S@szxml04-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 16:08:34 +0800 (CST) Date: Tue, 22 Sep 2009 16:08:34 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , "'Sanjay Sinha (sanjsinh)'" , sipcore@ietf.org Message-id: <019e01ca3b5b$e1b552e0$a51ff8a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2AAAB34bAAAQko8A== References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 08:07:34 -0000 Hi, Christer I agree with you MIMEs like JPEG is not enough and INFO package is needed. However I am talking about the case that MIME is clear enough. For example, if a SDO provides a detailed a specification for a Content Type for a particular usage then SIP INFO together with this MIME is enough. In this case I didn't see Info-Package header will help. There are some discussions in various SDOs about when we need to use this I-D and confusion comes. I hope IETF can clarify and give guidance on this. How about my suggestions as the guidance in last email? Cheers, Linyi -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, September 22, 2009 3:38 PM To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, >I was confused. In the scenario I described I don't see the >need to use new SIP INFO method. What is the context for this >compromise? As far as I understand there has to be benefit to >reach compromise. It is obviously this is not the case, right? > >I hope this can be clarified in the new draft as a guidance. >Maybe we can say when MIME is clear enough then old SIP INFO >could be enough. When MIME is not clear enough or negotiation >mechanism is needed then the new SIP INFO and framework is needed. And how do you know that everyone will have the same understanding of the MIME as you? Now, I agree that for ISDN there probably is not an issue. Also, I think that ISDN tunneling with INFO already exists, so there should be no need to define an Info Package for that. But, the draft talks about sending a jpeg as an example. Even if you support jpegs, sending it without any associated context makes it quite difficult for the receiver to know what you want him to do with it. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, September 22, 2009 2:47 PM > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > > Hi, > > >It is not clear to me why we need to use the new INFO method when the > content type can clearly indicate its application usage. What is the > benefit in this case for Info-Package header? I didn't > >see the difference with tunnel ISDN usage. > > We had long discussions about that, and the outcome and compromise was > the introduction of Info Packages. > > But, again, you are not required to change current INFO > usages (without > Packages). > > Regards, > > Christer > > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > On Behalf Of Sanjay Sinha (sanjsinh) > Sent: Tuesday, September 22, 2009 1:20 PM > To: Linyi TIAN; sipcore@ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > I believe there were couple of usages which could use legacy > INFO: tunnel ISDN content and provide out of band DTMF. All > other should > use the new info package. > > > > Sanjay > > > > ________________________________ > > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > Sent: Tuesday, September 22, 2009 9:24 AM > To: sipcore@ietf.org > Subject: [sipcore] When to use SIP INFO and SIP > INFO-Package > > Hi, All > > > > I have a general question about the guidance when to use > SIP INFO and SIP INFO-Package. > > > > If a MIME can clearly states its application usage, do > we still need to use SIP INFO-Package? Is there any guidance on this? > > > > Compared between the old SIP INFO and new SIP INFO > (without info event framework), is "Info-Package" header the only > difference? > > > > Cheers, > > Linyi > > From tianlinyi@huawei.com Tue Sep 22 02:02:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419B528C122 for ; Tue, 22 Sep 2009 02:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5zvMCeWHyWb for ; Tue, 22 Sep 2009 02:02:27 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 053C928C130 for ; Tue, 22 Sep 2009 02:02:27 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD006WE7TSQZ@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 17:03:29 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD007JM7TSK3@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 17:03:28 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD005FQ7TSS2@szxml06-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 17:03:28 +0800 (CST) Date: Tue, 22 Sep 2009 17:03:28 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , "'Sanjay Sinha (sanjsinh)'" , sipcore@ietf.org Message-id: <01b501ca3b63$8d013c70$a703b550$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2AAAB34bAAADuUsAACvqhw References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 09:02:28 -0000 Hi, Christer I understand the intention about solving IOP issues. I quite like the approach we have now in the I-D. However my concern is that we can't simply tell the industry that we should use new SIP INFO without any guidance or clear benefit. Not prevent people to abuse is not a good guidance at all. Since there are debate and confusion in various SDOs I believe it is better to write some guidance about the scenarios I described. Cheers, Linyi -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, September 22, 2009 3:44 PM To: Christer Holmberg; Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package In addition, IETF can not prevent you from using INFO in any way you want :) The reason we are providing the Info Package mechanism is to try to solve lots of the interop problems that have occured with the usage of legacy INFO. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 22. syyskuuta 2009 10:38 > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > Hi, > > >I was confused. In the scenario I described I don't see the > need to use > >new SIP INFO method. What is the context for this > compromise? As far as > >I understand there has to be benefit to reach compromise. It is > >obviously this is not the case, right? > > > >I hope this can be clarified in the new draft as a guidance. > >Maybe we can say when MIME is clear enough then old SIP INFO > could be > >enough. When MIME is not clear enough or negotiation mechanism is > >needed then the new SIP INFO and framework is needed. > > And how do you know that everyone will have the same > understanding of the MIME as you? > > Now, I agree that for ISDN there probably is not an issue. > Also, I think that ISDN tunneling with INFO already exists, > so there should be no need to define an Info Package for that. > > But, the draft talks about sending a jpeg as an example. Even > if you support jpegs, sending it without any associated > context makes it quite difficult for the receiver to know > what you want him to do with it. > > Regards, > > Christer > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, September 22, 2009 2:47 PM > > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > > > Hi, > > > > >It is not clear to me why we need to use the new INFO > method when the > > content type can clearly indicate its application usage. > What is the > > benefit in this case for Info-Package header? I didn't > > >see the difference with tunnel ISDN usage. > > > > We had long discussions about that, and the outcome and > compromise was > > the introduction of Info Packages. > > > > But, again, you are not required to change current INFO usages > > (without Packages). > > > > Regards, > > > > Christer > > > > > > > > > > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Sanjay Sinha (sanjsinh) > > Sent: Tuesday, September 22, 2009 1:20 PM > > To: Linyi TIAN; sipcore@ietf.org > > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > > > > > I believe there were couple of usages which could use legacy > > INFO: tunnel ISDN content and provide out of band DTMF. All other > > should use the new info package. > > > > > > > > Sanjay > > > > > > > > ________________________________ > > > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > > Sent: Tuesday, September 22, 2009 9:24 AM > > To: sipcore@ietf.org > > Subject: [sipcore] When to use SIP INFO and SIP > INFO-Package > > > > Hi, All > > > > > > > > I have a general question about the guidance > when to use SIP INFO > > and SIP INFO-Package. > > > > > > > > If a MIME can clearly states its application > usage, do we still need > > to use SIP INFO-Package? Is there any guidance on this? > > > > > > > > Compared between the old SIP INFO and new SIP > INFO (without info > > event framework), is "Info-Package" header the only difference? > > > > > > > > Cheers, > > > > Linyi > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Sep 22 02:07:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5023A69E0 for ; Tue, 22 Sep 2009 02:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrNfSA80Z5kN for ; Tue, 22 Sep 2009 02:07:20 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EDF793A69D9 for ; Tue, 22 Sep 2009 02:07:19 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-fe-4ab89405ce0b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 43.23.22406.50498BA4; Tue, 22 Sep 2009 11:08:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 11:07:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 11:07:52 +0200 Message-ID: In-Reply-To: <01b501ca3b63$8d013c70$a703b550$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2AAAB34bAAADuUsAACvqhwAAAsF3A= References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <01b501ca3b63$8d013c70$a703b550$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Sanjay Sinha (sanjsinh)" , X-OriginalArrivalTime: 22 Sep 2009 09:07:55.0297 (UTC) FILETIME=[2BE97910:01CA3B64] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 09:07:21 -0000 Hi, The draft tries to explain what the backgrund behind Info Packages is, and what the advantages of using Info Packages are. Regards, Christer =20 > -----Original Message----- > From: Linyi TIAN [mailto:tianlinyi@huawei.com]=20 > Sent: 22. syyskuuta 2009 12:03 > To: Christer Holmberg; 'Sanjay Sinha (sanjsinh)'; sipcore@ietf.org > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 > Hi, Christer >=20 > I understand the intention about solving IOP issues. I quite=20 > like the approach we have now in the I-D. >=20 > However my concern is that we can't simply tell the industry=20 > that we should use new SIP INFO without any guidance or clear=20 > benefit. Not prevent people to abuse is not a good guidance at all.=20 >=20 > Since there are debate and confusion in various SDOs I=20 > believe it is better to write some guidance about the=20 > scenarios I described. >=20 > Cheers, > Linyi >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, September 22, 2009 3:44 PM > To: Christer Holmberg; Linyi TIAN; Sanjay Sinha (sanjsinh);=20 > sipcore@ietf.org > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 >=20 > In addition, IETF can not prevent you from using INFO in any way you > want :) >=20 > The reason we are providing the Info Package mechanism is to try to > solve lots of the interop problems that have occured with the usage of > legacy INFO. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 22. syyskuuta 2009 10:38 > > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >=20 > >=20 > > Hi,=20 > >=20 > > >I was confused. In the scenario I described I don't see the=20 > > need to use=20 > > >new SIP INFO method. What is the context for this=20 > > compromise? As far as=20 > > >I understand there has to be benefit to reach compromise. It is=20 > > >obviously this is not the case, right? > > > > > >I hope this can be clarified in the new draft as a guidance.=20 > > >Maybe we can say when MIME is clear enough then old SIP INFO=20 > > could be=20 > > >enough. When MIME is not clear enough or negotiation mechanism is=20 > > >needed then the new SIP INFO and framework is needed. > >=20 > > And how do you know that everyone will have the same=20 > > understanding of the MIME as you? > >=20 > > Now, I agree that for ISDN there probably is not an issue.=20 > > Also, I think that ISDN tunneling with INFO already exists,=20 > > so there should be no need to define an Info Package for that. > >=20 > > But, the draft talks about sending a jpeg as an example. Even=20 > > if you support jpegs, sending it without any associated=20 > > context makes it quite difficult for the receiver to know=20 > > what you want him to do with it. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, September 22, 2009 2:47 PM > > > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > > > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > >=20 > > >=20 > > > Hi, > > >=20 > > > >It is not clear to me why we need to use the new INFO=20 > > method when the > > > content type can clearly indicate its application usage.=20 > > What is the=20 > > > benefit in this case for Info-Package header? I didn't > > > >see the difference with tunnel ISDN usage. > > >=20 > > > We had long discussions about that, and the outcome and=20 > > compromise was=20 > > > the introduction of Info Packages. > > >=20 > > > But, again, you are not required to change current INFO usages=20 > > > (without Packages). > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > > =20 > > >=20 > > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On=20 > > > Behalf Of Sanjay Sinha (sanjsinh) > > > Sent: Tuesday, September 22, 2009 1:20 PM > > > To: Linyi TIAN; sipcore@ietf.org > > > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > >=20 > > > =20 > > >=20 > > > I believe there were couple of usages which could use legacy > > > INFO: tunnel ISDN content and provide out of band DTMF. All other=20 > > > should use the new info package. > > >=20 > > > =20 > > >=20 > > > Sanjay > > >=20 > > > =20 > > >=20 > > > ________________________________ > > >=20 > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > > > Sent: Tuesday, September 22, 2009 9:24 AM > > > To: sipcore@ietf.org > > > Subject: [sipcore] When to use SIP INFO and SIP=20 > > INFO-Package > > >=20 > > > Hi, All > > >=20 > > > =20 > > >=20 > > > I have a general question about the guidance=20 > > when to use SIP INFO=20 > > > and SIP INFO-Package. > > >=20 > > > =20 > > >=20 > > > If a MIME can clearly states its application=20 > > usage, do we still need=20 > > > to use SIP INFO-Package? Is there any guidance on this? > > >=20 > > > =20 > > >=20 > > > Compared between the old SIP INFO and new SIP=20 > > INFO (without info=20 > > > event framework), is "Info-Package" header the only difference? > > >=20 > > > =20 > > >=20 > > > Cheers, > > >=20 > > > Linyi > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 >=20 From sanjsinh@cisco.com Tue Sep 22 02:18:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2583A6882 for ; Tue, 22 Sep 2009 02:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW8S0cdPQ48z for ; Tue, 22 Sep 2009 02:18:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9ED5628C0F6 for ; Tue, 22 Sep 2009 02:18:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOsyuEpAZnme/2dsb2JhbAC+C4hQAY9JBYQb X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="59280915" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Sep 2009 09:19:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8M9J9K7027774; Tue, 22 Sep 2009 05:19:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8M9J9va000263; Tue, 22 Sep 2009 09:19:09 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 05:19:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 05:19:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7OFFAUi0hFKv4TWCJNgLedu+w5gAC681AAAJB+sAAAMZlcAABTc2AAAB34bAAADuUsAACvqhwAAAsF3AAAGl0MA== References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <01b501ca3b63$8d013c70$a703b550$@com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Linyi TIAN" , X-OriginalArrivalTime: 22 Sep 2009 09:19:09.0443 (UTC) FILETIME=[BDBBFD30:01CA3B65] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6425; t=1253611149; x=1254475149; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20When=20to=20use=20SIP=20INF O=20and=20SIP=20INFO-Package |Sender:=20 |To:=20=22Christer=20Holmberg=22=20,=0A=20=20=20=20=20=20=20=20=22Linyi=20TIAN=22=20,=20; bh=EjgFq/9TCJj+BgA53Z5AVgqdsBkR7R7XImfGyHHbUrk=; b=r8H0juEJze4RL+/pISdxjoedm8mYO+wPP2vhn038t4Mvyxv/245KkKUE0+ C3iFA2cgkOiH5I9MEdb169RZvREBUNIeq19Lb2WA5ZNMEl9UE5VxUhXKyaRw ghSQSzx6be; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 09:18:08 -0000 Also you should probably look at the email archives from sip wg around Sept - Oct 2007. There was detailed discussion about Content-Type and Info package. Sanjay >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 >Sent: Tuesday, September 22, 2009 2:38 PM >To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org >Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > >Hi, > >The draft tries to explain what the backgrund behind Info=20 >Packages is, and what the advantages of using Info Packages are. > >Regards, > >Christer > > >=20 > >> -----Original Message----- >> From: Linyi TIAN [mailto:tianlinyi@huawei.com] >> Sent: 22. syyskuuta 2009 12:03 >> To: Christer Holmberg; 'Sanjay Sinha (sanjsinh)'; sipcore@ietf.org >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >>=20 >> Hi, Christer >>=20 >> I understand the intention about solving IOP issues. I quite=20 >like the=20 >> approach we have now in the I-D. >>=20 >> However my concern is that we can't simply tell the industry that we=20 >> should use new SIP INFO without any guidance or clear benefit. Not=20 >> prevent people to abuse is not a good guidance at all. >>=20 >> Since there are debate and confusion in various SDOs I believe it is=20 >> better to write some guidance about the scenarios I described. >>=20 >> Cheers, >> Linyi >>=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, September 22, 2009 3:44 PM >> To: Christer Holmberg; Linyi TIAN; Sanjay Sinha (sanjsinh);=20 >> sipcore@ietf.org >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >>=20 >>=20 >> In addition, IETF can not prevent you from using INFO in any way you=20 >> want :) >>=20 >> The reason we are providing the Info Package mechanism is to try to=20 >> solve lots of the interop problems that have occured with=20 >the usage of=20 >> legacy INFO. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: sipcore-bounces@ietf.org >> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> > Sent: 22. syyskuuta 2009 10:38 >> > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org >> > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> >=20 >> >=20 >> > Hi, >> >=20 >> > >I was confused. In the scenario I described I don't see the >> > need to use >> > >new SIP INFO method. What is the context for this >> > compromise? As far as >> > >I understand there has to be benefit to reach compromise. It is=20 >> > >obviously this is not the case, right? >> > > >> > >I hope this can be clarified in the new draft as a guidance.=20 >> > >Maybe we can say when MIME is clear enough then old SIP INFO >> > could be >> > >enough. When MIME is not clear enough or negotiation mechanism is=20 >> > >needed then the new SIP INFO and framework is needed. >> >=20 >> > And how do you know that everyone will have the same understanding=20 >> > of the MIME as you? >> >=20 >> > Now, I agree that for ISDN there probably is not an issue.=20 >> > Also, I think that ISDN tunneling with INFO already=20 >exists, so there=20 >> > should be no need to define an Info Package for that. >> >=20 >> > But, the draft talks about sending a jpeg as an example.=20 >Even if you=20 >> > support jpegs, sending it without any associated context makes it=20 >> > quite difficult for the receiver to know what you want him to do=20 >> > with it. >> >=20 >> > Regards, >> >=20 >> > Christer >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> > > Sent: Tuesday, September 22, 2009 2:47 PM >> > > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org >> > > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >> > >=20 >> > >=20 >> > > Hi, >> > >=20 >> > > >It is not clear to me why we need to use the new INFO >> > method when the >> > > content type can clearly indicate its application usage.=20 >> > What is the >> > > benefit in this case for Info-Package header? I didn't >> > > >see the difference with tunnel ISDN usage. >> > >=20 >> > > We had long discussions about that, and the outcome and >> > compromise was >> > > the introduction of Info Packages. >> > >=20 >> > > But, again, you are not required to change current INFO usages=20 >> > > (without Packages). >> > >=20 >> > > Regards, >> > >=20 >> > > Christer >> > >=20 >> > >=20 >> > > =20 >> > >=20 >> > > From: sipcore-bounces@ietf.org >> > [mailto:sipcore-bounces@ietf.org] On >> > > Behalf Of Sanjay Sinha (sanjsinh) >> > > Sent: Tuesday, September 22, 2009 1:20 PM >> > > To: Linyi TIAN; sipcore@ietf.org >> > > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> > >=20 >> > > =20 >> > >=20 >> > > I believe there were couple of usages which could use legacy >> > > INFO: tunnel ISDN content and provide out of band DTMF.=20 >All other=20 >> > > should use the new info package. >> > >=20 >> > > =20 >> > >=20 >> > > Sanjay >> > >=20 >> > > =20 >> > >=20 >> > > ________________________________ >> > >=20 >> > > From: sipcore-bounces@ietf.org=20 >> > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN >> > > Sent: Tuesday, September 22, 2009 9:24 AM >> > > To: sipcore@ietf.org >> > > Subject: [sipcore] When to use SIP INFO and SIP >> > INFO-Package >> > >=20 >> > > Hi, All >> > >=20 >> > > =20 >> > >=20 >> > > I have a general question about the guidance >> > when to use SIP INFO >> > > and SIP INFO-Package. >> > >=20 >> > > =20 >> > >=20 >> > > If a MIME can clearly states its application >> > usage, do we still need >> > > to use SIP INFO-Package? Is there any guidance on this? >> > >=20 >> > > =20 >> > >=20 >> > > Compared between the old SIP INFO and new SIP >> > INFO (without info >> > > event framework), is "Info-Package" header the only difference? >> > >=20 >> > > =20 >> > >=20 >> > > Cheers, >> > >=20 >> > > Linyi >> > >=20 >> > >=20 >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> >=20 >>=20 >>=20 > From pkyzivat@cisco.com Tue Sep 22 06:16:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDE93A6A55 for ; Tue, 22 Sep 2009 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR+jd1GAJgrL for ; Tue, 22 Sep 2009 06:16:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7EC463A6A4E for ; Tue, 22 Sep 2009 06:16:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO9quEpAZnmf/2dsb2JhbAC/OohPAY9tBYQb X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="59318772" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Sep 2009 13:17:09 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8MDH9Fp031484; Tue, 22 Sep 2009 09:17:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8MDH8b8029623; Tue, 22 Sep 2009 13:17:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:17:08 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 09:17:08 -0400 Message-ID: <4AB8CE55.8050302@cisco.com> Date: Tue, 22 Sep 2009 09:17:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Linyi TIAN References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> In-Reply-To: <019e01ca3b5b$e1b552e0$a51ff8a0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2009 13:17:08.0316 (UTC) FILETIME=[FC9B19C0:01CA3B86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4852; t=1253625429; x=1254489429; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20When=20to=20use=20SIP=20INF O=20and=20SIP=20INFO-Package |Sender:=20 |To:=20Linyi=20TIAN=20; bh=UNZtw/qDMhrZY0wp/AV6VqCkqO1GJ91IhmXZbOGZrOs=; b=vXC8OQoJP2VXSNoH/5Fps/fcZCO/EK0lWHNZ7aSz1HAbzySs3GTx0NlvfC ObEpImY89WLzzlSmlj6dj5kH0cDLujQYGBMuqncAf2HmnDd7gY3LP9PBuVf/ CO9Nvt6JmI; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "'Sanjay Sinha \(sanjsinh\)'" , sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:16:07 -0000 If you attempt to use INFO without an info-package, then you also have all the other limitations of legacy info use. That usage is quite under-specified. You can of course do whatever you want. But your usage will essentially be proprietary. *Where* are you going to specify the meaning of that content-type with respect to INFO? How will someone you end up interoperating with discover that specification? How will you know if they understood it or not? The info package mechanism addresses those kinds of issues. Thanks, Paul Linyi TIAN wrote: > Hi, Christer > > I agree with you MIMEs like JPEG is not enough and INFO package is needed. > However I am talking about the case that MIME is clear enough. For example, > if a SDO provides a detailed a specification for a Content Type for a > particular usage then SIP INFO together with this MIME is enough. > > In this case I didn't see Info-Package header will help. There are some > discussions in various SDOs about when we need to use this I-D and confusion > comes. I hope IETF can clarify and give guidance on this. > > How about my suggestions as the guidance in last email? > > Cheers, > Linyi > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, September 22, 2009 3:38 PM > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > > Hi, > >> I was confused. In the scenario I described I don't see the >> need to use new SIP INFO method. What is the context for this >> compromise? As far as I understand there has to be benefit to >> reach compromise. It is obviously this is not the case, right? >> >> I hope this can be clarified in the new draft as a guidance. >> Maybe we can say when MIME is clear enough then old SIP INFO >> could be enough. When MIME is not clear enough or negotiation >> mechanism is needed then the new SIP INFO and framework is needed. > > And how do you know that everyone will have the same understanding of > the MIME as you? > > Now, I agree that for ISDN there probably is not an issue. Also, I think > that ISDN tunneling with INFO already exists, so there should be no need > to define an Info Package for that. > > But, the draft talks about sending a jpeg as an example. Even if you > support jpegs, sending it without any associated context makes it quite > difficult for the receiver to know what you want him to do with it. > > Regards, > > Christer > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, September 22, 2009 2:47 PM >> To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> >> Hi, >> >>> It is not clear to me why we need to use the new INFO method when the >> content type can clearly indicate its application usage. What is the >> benefit in this case for Info-Package header? I didn't >>> see the difference with tunnel ISDN usage. >> We had long discussions about that, and the outcome and compromise was >> the introduction of Info Packages. >> >> But, again, you are not required to change current INFO >> usages (without >> Packages). >> >> Regards, >> >> Christer >> >> >> >> >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] >> On Behalf Of Sanjay Sinha (sanjsinh) >> Sent: Tuesday, September 22, 2009 1:20 PM >> To: Linyi TIAN; sipcore@ietf.org >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> >> >> I believe there were couple of usages which could use legacy >> INFO: tunnel ISDN content and provide out of band DTMF. All >> other should >> use the new info package. >> >> >> >> Sanjay >> >> >> >> ________________________________ >> >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN >> Sent: Tuesday, September 22, 2009 9:24 AM >> To: sipcore@ietf.org >> Subject: [sipcore] When to use SIP INFO and SIP >> INFO-Package >> >> Hi, All >> >> >> >> I have a general question about the guidance when to use >> SIP INFO and SIP INFO-Package. >> >> >> >> If a MIME can clearly states its application usage, do >> we still need to use SIP INFO-Package? Is there any guidance on this? >> >> >> >> Compared between the old SIP INFO and new SIP INFO >> (without info event framework), is "Info-Package" header the only >> difference? >> >> >> >> Cheers, >> >> Linyi >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From tianlinyi@huawei.com Tue Sep 22 08:25:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1773A691C for ; Tue, 22 Sep 2009 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLlX01m6wgQV for ; Tue, 22 Sep 2009 08:25:58 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B45D93A6765 for ; Tue, 22 Sep 2009 08:25:57 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD002R3PKQ4E@szxga04-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 23:26:51 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00KBTPKQJD@szxga04-in.huawei.com> for sipcore@ietf.org; Tue, 22 Sep 2009 23:26:50 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [113.87.235.138]) by szxmc04-in.huawei.com (mshttpd); Tue, 22 Sep 2009 23:26:50 +0800 Date: Tue, 22 Sep 2009 23:26:50 +0800 From: tianlinyi 34932 In-reply-to: <4AB8CE55.8050302@cisco.com> To: Paul Kyzivat Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_DFuNlXtFFpRvMq/sP9o9hQ)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> Cc: "'Sanjay Sinha \(sanjsinh\)'" , sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:25:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DFuNlXtFFpRvMq/sP9o9hQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C Paul As i said there is specification clearly states the usage of Content type= and a registration with this Content Type will be provided=2E The specif= ication will also mention how it will be used in SIP INFO=2C why it is st= ill un-specified=3F For example=2C if 3GPP defines the content type and its usage with SIP IN= FO in a specification why INFO package hearder should be used=3F I didn=27= t see any IOP problem on this approach=2E Cheers=2C Linyi *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Paul Kyzivat =3Cpkyzivat=40cisco=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =BE=C5=D4=C2 22=C8=D5=2C 2009 =CF=C2= =CE=E79=3A17 =D6=F7=CC=E2=3A Re=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-Pac= kage =CA=D5=BC=FE=C8=CB=3A Linyi TIAN =3Ctianlinyi=40huawei=2Ecom=3E =B3=AD=CB=CD=3A =27Christer Holmberg=27 =3Cchrister=2Eholmberg=40ericsson= =2Ecom=3E=2C =22=27Sanjay Sinha (sanjsinh)=27=22 =3Csanjsinh=40cisco=2Eco= m=3E=2C sipcore=40ietf=2Eorg =3E If you attempt to use INFO without an info-package=2C then you also = =3E have = =3E all the other limitations of legacy info use=2E That usage is quite = =3E under-specified=2E You can of course do whatever you want=2E But your= = =3E usage = =3E will essentially be proprietary=2E =3E = =3E *Where* are you going to specify the meaning of that content-type = =3E with = =3E respect to INFO=3F How will someone you end up interoperating with = =3E discover that specification=3F How will you know if they understood = =3E it or not=3F =3E = =3E The info package mechanism addresses those kinds of issues=2E =3E = =3E Thanks=2C =3E Paul =3E = =3E Linyi TIAN wrote=3A =3E =3E Hi=2C Christer =3E =3E = =3E =3E I agree with you MIMEs like JPEG is not enough and INFO package = =3E is needed=2E =3E =3E However I am talking about the case that MIME is clear enough=2E = =3E For example=2C =3E =3E if a SDO provides a detailed a specification for a Content Type = =3E for a =3E =3E particular usage then SIP INFO together with this MIME is enough=2E= =3E =3E = =3E =3E In this case I didn=27t see Info-Package header will help=2E Ther= e = =3E are some =3E =3E discussions in various SDOs about when we need to use this I-D = =3E and confusion =3E =3E comes=2E I hope IETF can clarify and give guidance on this=2E = =3E =3E = =3E =3E How about my suggestions as the guidance in last email=3F = =3E =3E = =3E =3E Cheers=2C =3E =3E Linyi =3E =3E = =3E =3E -----Original Message----- =3E =3E From=3A Christer Holmberg =5Bmailto=3Achrister=2Eholmberg=40erics= son=2Ecom=5D = =3E =3E Sent=3A Tuesday=2C September 22=2C 2009 3=3A38 PM =3E =3E To=3A Linyi TIAN=3B Sanjay Sinha (sanjsinh)=3B sipcore=40ietf=2Eo= rg =3E =3E Subject=3A RE=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-= Package =3E =3E = =3E =3E = =3E =3E Hi=2C = =3E =3E = =3E =3E=3E I was confused=2E In the scenario I described I don=27t see th= e = =3E =3E=3E need to use new SIP INFO method=2E What is the context for thi= s = =3E =3E=3E compromise=3F As far as I understand there has to be benefit t= o = =3E =3E=3E reach compromise=2E It is obviously this is not the case=2C ri= ght=3F = =3E =3E=3E =3E =3E=3E I hope this can be clarified in the new draft as a guidance=2E= = =3E =3E=3E Maybe we can say when MIME is clear enough then old SIP INFO = =3E =3E=3E could be enough=2E When MIME is not clear enough or negotiatio= n = =3E =3E=3E mechanism is needed then the new SIP INFO and framework is = =3E needed=2E = =3E =3E = =3E =3E And how do you know that everyone will have the same = =3E understanding of =3E =3E the MIME as you=3F =3E =3E = =3E =3E Now=2C I agree that for ISDN there probably is not an issue=2E Al= so=2C = =3E I think =3E =3E that ISDN tunneling with INFO already exists=2C so there should b= e = =3E no need =3E =3E to define an Info Package for that=2E =3E =3E = =3E =3E But=2C the draft talks about sending a jpeg as an example=2E Even= if you =3E =3E support jpegs=2C sending it without any associated context makes = =3E it quite =3E =3E difficult for the receiver to know what you want him to do with i= t=2E =3E =3E = =3E =3E Regards=2C =3E =3E = =3E =3E Christer =3E =3E = =3E =3E = =3E =3E=3E -----Original Message----- =3E =3E=3E From=3A Christer Holmberg =5Bmailto=3Achrister=2Eholmberg=40er= icsson=2Ecom=5D =3E =3E=3E Sent=3A Tuesday=2C September 22=2C 2009 2=3A47 PM =3E =3E=3E To=3A Linyi TIAN=3B Sanjay Sinha (sanjsinh)=3B sipcore=40ietf=2E= org =3E =3E=3E Subject=3A RE=3A =5Bsipcore=5D When to use SIP INFO and SIP IN= FO-Package =3E =3E=3E =3E =3E=3E =3E =3E=3E Hi=2C = =3E =3E=3E =3E =3E=3E=3E It is not clear to me why we need to use the new INFO metho= d = =3E when the =3E =3E=3E content type can clearly indicate its application usage=2E Wha= t = =3E is the =3E =3E=3E benefit in this case for Info-Package header=3F I didn=27t = =3E =3E=3E=3E see the difference with tunnel ISDN usage=2E =3E =3E=3E We had long discussions about that=2C and the outcome and = =3E compromise was =3E =3E=3E the introduction of Info Packages=2E =3E =3E=3E =3E =3E=3E But=2C again=2C you are not required to change current INFO = =3E =3E=3E usages (without =3E =3E=3E Packages)=2E =3E =3E=3E =3E =3E=3E Regards=2C =3E =3E=3E =3E =3E=3E Christer =3E =3E=3E =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E From=3A sipcore-bounces=40ietf=2Eorg =5Bmailto=3Asipcore-boun= ces=40ietf=2Eorg=5D =3E =3E=3E On Behalf Of Sanjay Sinha (sanjsinh) =3E =3E=3E Sent=3A Tuesday=2C September 22=2C 2009 1=3A20 PM =3E =3E=3E To=3A Linyi TIAN=3B sipcore=40ietf=2Eorg =3E =3E=3E Subject=3A Re=3A =5Bsipcore=5D When to use SIP INFO and SIP I= NFO-Package =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E I believe there were couple of usages which could use legacy =3E =3E=3E INFO=3A tunnel ISDN content and provide out of band DTMF=2E Al= l = =3E =3E=3E other should =3E =3E=3E use the new info package=2E =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E Sanjay =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E=3E =3E =3E=3E From=3A sipcore-bounces=40ietf=2Eorg =3E =3E=3E =5Bmailto=3Asipcore-bounces=40ietf=2Eorg=5D On Behalf Of Linyi= TIAN =3E =3E=3E Sent=3A Tuesday=2C September 22=2C 2009 9=3A24 AM =3E =3E=3E To=3A sipcore=40ietf=2Eorg =3E =3E=3E Subject=3A =5Bsipcore=5D When to use SIP INFO and SIP= =3E =3E=3E INFO-Package =3E =3E=3E =3E =3E=3E Hi=2C All =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E I have a general question about the guidance when to = use =3E =3E=3E SIP INFO and SIP INFO-Package=2E =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E If a MIME can clearly states its application usage=2C= do =3E =3E=3E we still need to use SIP INFO-Package=3F Is there any guidance= on = =3E this=3F=3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E Compared between the old SIP INFO and new SIP INFO =3E =3E=3E (without info event framework)=2C is =22Info-Package=22 header= the only =3E =3E=3E difference=3F =3E =3E=3E =3E =3E=3E = =3E =3E=3E =3E =3E=3E Cheers=2C =3E =3E=3E =3E =3E=3E Linyi =3E =3E=3E =3E =3E=3E =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E sipcore mailing list =3E =3E sipcore=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/sipcore =3E =3E = =3E --Boundary_(ID_DFuNlXtFFpRvMq/sP9o9hQ) Content-type: text/x-vcard; name=t34932.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=t34932.vcf Content-description: Card for tianlinyi 34932 begin:vcard n:34932;tianlinyi fn:tianlinyi 34932 version:2.1 email;internet:tianlinyi@huawei.com end:vcard --Boundary_(ID_DFuNlXtFFpRvMq/sP9o9hQ)-- From dean.willis@softarmor.com Tue Sep 22 11:22:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2A728C147 for ; Tue, 22 Sep 2009 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajRdUKlBQgLJ for ; Tue, 22 Sep 2009 11:22:59 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D24F628C10A for ; Tue, 22 Sep 2009 11:22:58 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8MINtFb005776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Sep 2009 13:23:57 -0500 Message-Id: <0F0D1754-C58E-4E07-93D1-8D762AF1D5E1@softarmor.com> From: Dean Willis To: Linyi TIAN In-Reply-To: <014801ca3b38$51ab7940$f5026bc0$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Sep 2009 13:23:50 -0500 References: <014801ca3b38$51ab7940$f5026bc0$@com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 18:22:59 -0000 On Sep 21, 2009, at 10:54 PM, Linyi TIAN wrote: > > > If a MIME can clearly states its application usage, do we still need > to use SIP INFO-Package? Is there any guidance on this? > This is somewhat like asking "If carrier pigeons can fly me to the IETF meeting, do I need to buy an airplane ticket?" We've debated at great length, and have not found a case wherein the "MIME clearly states its application usage" really works with SIP. I suppose one might define new "SIP-only" MIME types that are limited in this way, but this clashes with the fundamental philosophy of MIME types as describing "what a thing is", rather than "what you should do with this thing". So the answer is: all new usages will need to define SIP INFO packages. -- Dean From dean.willis@softarmor.com Tue Sep 22 11:39:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6DF3A67A7 for ; Tue, 22 Sep 2009 11:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWIm2+Z+Ovzl for ; Tue, 22 Sep 2009 11:39:08 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 318983A67FE for ; Tue, 22 Sep 2009 11:39:08 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8MIe170006026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Sep 2009 13:40:02 -0500 Message-Id: <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> From: Dean Willis To: tianlinyi 34932 In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Sep 2009 13:39:55 -0500 References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "'Sanjay Sinha \(sanjsinh\)'" , sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 18:39:09 -0000 On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote: > Hi, Paul > > As i said there is specification clearly states the usage of Content > type and a registration with this Content Type will be provided. The > specification will also mention how it will be used in SIP INFO, why > it is still un-specified? > > For example, if 3GPP defines the content type and its usage with SIP > INFO in a specification why INFO package hearder should be used? I > didn't see any IOP problem on this approach. > If 3GPP were to define a new MIME type that is only used in SIP INFO messages, then you are correct in that the INFO package framework would add little value. However, this is not how MIME types work. The MIME type model defines only "what an object is", not "how the object can be used". To negotiate around "how the object will be used in this application", we need a higher-level of specification and negotiation. IN SIP INFO messages, the INFO package definition provides that level of specification and negotiation. The MIME registration process doesn't register things like "This MIME type can only be used in a SIP INFO message in accordance with the foobar application as documented in 3GPP TS 99.411." And if somebody tried to register such a restricted MIME type, I'd hope the ietf-types people would say "no." Of course, there's no guarantee that no broken types are going to be registered (especially in vendor trees), but certainly the majority of existing types aren't broken like this. Once a type is defined, objects os that type can br transported in email, HTTP requests, SIP INFO, NOTIFY, and other requests messages, stored in Windows registries, and so on, in countless application scenarios that the MIME type registration has no way of predicting or controlling. To constrain this diversity in a useful way in the context of NOTIFY messages within the SIP protocol, we have historically use event packages, and found this approach to work quite well. Going forward, in the context of INFO messages within the SIP protocol, we will use INFO packages for the same reasons. -- Dean From christer.holmberg@ericsson.com Tue Sep 22 12:53:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0FF3A6867 for ; Tue, 22 Sep 2009 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.59 X-Spam-Level: X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSOdD5MjmAhk for ; Tue, 22 Sep 2009 12:53:13 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 75C1C3A6978 for ; Tue, 22 Sep 2009 12:53:12 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-dc-4ab92b6671b7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D9.01.22406.66B29BA4; Tue, 22 Sep 2009 21:54:15 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 21:52:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 21:52:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco7mR4w7KkD3LBVRJilh/0BV+jZcgAJEbj5 References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> From: "Christer Holmberg" To: "tianlinyi 34932" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Sep 2009 19:52:52.0695 (UTC) FILETIME=[455BCE70:01CA3BBE] X-Brightmail-Tracker: AAAAAA== Cc: "Sanjay Sinha \(sanjsinh\)" , sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 19:53:14 -0000 Hi, =20 If you can ensure that the INFO will only reach IMS user agents, and = that there will be no other usage of the Content Type, then you can do = that. In controlled environments it is always easier to make sure = everyone has the same "understanding" of things. =20 Please note, though, that 3GPP IMS has adopted the Info Package draft. =20 Regards, =20 Christer ________________________________ From: tianlinyi 34932 [mailto:tianlinyi@huawei.com] Sent: Tue 22/09/2009 17:26 To: Paul Kyzivat Cc: Christer Holmberg; 'Sanjay Sinha (sanjsinh)'; sipcore@ietf.org Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, Paul As i said there is specification clearly states the usage of Content = type and a registration with this Content Type will be provided. The = specification will also mention how it will be used in SIP INFO, why it = is still un-specified? For example, if 3GPP defines the content type and its usage with SIP = INFO in a specification why INFO package hearder should be used? I = didn't see any IOP problem on this approach. Cheers, Linyi *************************************************************************= ***************** This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained here in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient(s) is prohibited. If you receive this email in error, please = notify the sender by phone or email immediately and delete it! = *************************************************************************= **************** ----- ??? ----- ???: Paul Kyzivat ??: ???, ?? 22?, 2009 ??9:17 ??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package ???: Linyi TIAN ??: 'Christer Holmberg' , "'Sanjay Sinha = (sanjsinh)'" , sipcore@ietf.org > If you attempt to use INFO without an info-package, then you also > have > all the other limitations of legacy info use. That usage is quite > under-specified. You can of course do whatever you want. But your > usage > will essentially be proprietary. > > *Where* are you going to specify the meaning of that content-type > with > respect to INFO? How will someone you end up interoperating with > discover that specification? How will you know if they understood > it or not? > > The info package mechanism addresses those kinds of issues. > > Thanks, > Paul > > Linyi TIAN wrote: > > Hi, Christer > > > > I agree with you MIMEs like JPEG is not enough and INFO package > is needed. > > However I am talking about the case that MIME is clear enough. > For example, > > if a SDO provides a detailed a specification for a Content Type > for a > > particular usage then SIP INFO together with this MIME is enough. > > > > In this case I didn't see Info-Package header will help. There > are some > > discussions in various SDOs about when we need to use this I-D > and confusion > > comes. I hope IETF can clarify and give guidance on this. > > > > How about my suggestions as the guidance in last email? > > > > Cheers, > > Linyi > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, September 22, 2009 3:38 PM > > To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > > > Hi, > > > >> I was confused. In the scenario I described I don't see the > >> need to use new SIP INFO method. What is the context for this > >> compromise? As far as I understand there has to be benefit to > >> reach compromise. It is obviously this is not the case, right? > >> > >> I hope this can be clarified in the new draft as a guidance. > >> Maybe we can say when MIME is clear enough then old SIP INFO > >> could be enough. When MIME is not clear enough or negotiation > >> mechanism is needed then the new SIP INFO and framework is > needed. > > > > And how do you know that everyone will have the same > understanding of > > the MIME as you? > > > > Now, I agree that for ISDN there probably is not an issue. Also, > I think > > that ISDN tunneling with INFO already exists, so there should be > no need > > to define an Info Package for that. > > > > But, the draft talks about sending a jpeg as an example. Even if you > > support jpegs, sending it without any associated context makes > it quite > > difficult for the receiver to know what you want him to do with it. > > > > Regards, > > > > Christer > > > > > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Tuesday, September 22, 2009 2:47 PM > >> To: Linyi TIAN; Sanjay Sinha (sanjsinh); sipcore@ietf.org > >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> > >> Hi, > >> > >>> It is not clear to me why we need to use the new INFO method > when the > >> content type can clearly indicate its application usage. What > is the > >> benefit in this case for Info-Package header? I didn't > >>> see the difference with tunnel ISDN usage. > >> We had long discussions about that, and the outcome and > compromise was > >> the introduction of Info Packages. > >> > >> But, again, you are not required to change current INFO > >> usages (without > >> Packages). > >> > >> Regards, > >> > >> Christer > >> > >> > >> =20 > >> > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > >> On Behalf Of Sanjay Sinha (sanjsinh) > >> Sent: Tuesday, September 22, 2009 1:20 PM > >> To: Linyi TIAN; sipcore@ietf.org > >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> =20 > >> > >> I believe there were couple of usages which could use legacy > >> INFO: tunnel ISDN content and provide out of band DTMF. All > >> other should > >> use the new info package. > >> > >> =20 > >> > >> Sanjay > >> > >> =20 > >> > >> ________________________________ > >> > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > >> Sent: Tuesday, September 22, 2009 9:24 AM > >> To: sipcore@ietf.org > >> Subject: [sipcore] When to use SIP INFO and SIP > >> INFO-Package > >> > >> Hi, All > >> > >> =20 > >> > >> I have a general question about the guidance when to use > >> SIP INFO and SIP INFO-Package. > >> > >> =20 > >> > >> If a MIME can clearly states its application usage, do > >> we still need to use SIP INFO-Package? Is there any guidance on > this?>> > >> =20 > >> > >> Compared between the old SIP INFO and new SIP INFO > >> (without info event framework), is "Info-Package" header the only > >> difference? > >> > >> =20 > >> > >> Cheers, > >> > >> Linyi > >> > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > From christian.vogt@ericsson.com Tue Sep 22 14:01:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D1728C0D9; Tue, 22 Sep 2009 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoXGCHB7J+Tq; Tue, 22 Sep 2009 14:01:06 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 6828F3A6A02; Tue, 22 Sep 2009 14:01:06 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n8ML1ubV029792; Tue, 22 Sep 2009 16:01:57 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:01:47 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 16:01:43 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 22 Sep 2009 17:01:41 -0400 From: Christian Vogt To: Gen-ART Mailing List , "sipcore@ietf.org" Date: Tue, 22 Sep 2009 17:01:32 -0400 Thread-Topic: Gen-ART review of draft-ietf-sipcore-presence-scaling-requirements-02 Thread-Index: Aco7x+GxEitrHkckTdCE0XVl4GXubA== Message-ID: <572B7D13-422D-412E-8D9C-A07693B629E3@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Sep 2009 21:01:43.0107 (UTC) FILETIME=[E346A930:01CA3BC7] X-Mailman-Approved-At: Tue, 22 Sep 2009 14:34:36 -0700 Cc: "RjS@nostrum.com" , "vs2140@cs.columbia.edu" , "avshalom@il.ibm.com" , "aoki@aol.net" , "hgs+ecrit@cs.columbia.edu" , Gonzalo Camarillo , "Sriram.Parameswar@microsoft.com" Subject: [sipcore] Gen-ART review of draft-ietf-sipcore-presence-scaling-requirements-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 21:01:08 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document..........: draft-ietf-sipcore-presence-scaling-requirements-02 Reviewer..........: Christian Vogt Review date.......: September 22, 2009 IESG Telechat date: September 24, 2009 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This document describes requirements for SIP/SIMPLE optimizations, primarily to address scalability issues that have been observed for SIP/SIMPLE deployments. The document is well-written and concise, and it is basically ready for publication. Two comments, though, which the authors may want to consider: - It would be worth mentioning in the introduction of the document what the expected result of this document should be. Obviously, we are expecting (or hoping for) an improvement in the scalability of SIP/SIMPLE, but this should be made explicit. Also, do we have estimates of how much SIP/SIMPLE will improve? - The document only talks about "optimizations" to which the defined requirement should apply. How about other types of protocol enhancements, such as functional extensions? Wouldn't the defined requirements apply to those just as well? Good luck with the publication! - Christian From tianlinyi@huawei.com Tue Sep 22 17:53:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4893A694C for ; Tue, 22 Sep 2009 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s10b0rYKrsIk for ; Tue, 22 Sep 2009 17:53:18 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 07B823A6879 for ; Tue, 22 Sep 2009 17:53:17 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE0086LFUC8H@szxga03-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 08:54:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE005HZFUCZW@szxga03-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 08:54:12 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQE0034KFUBDH@szxml04-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 08:54:12 +0800 (CST) Date: Wed, 23 Sep 2009 08:54:11 +0800 From: Linyi TIAN In-reply-to: <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> To: 'Dean Willis' Message-id: <02d601ca3be8$5d818060$18848120$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco7tC2tsaK6KlfwS9WymGL/3LA7ngAMyiEA References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> Cc: "'Sanjay Sinha \(sanjsinh\)'" , sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 00:53:19 -0000 Hi, Dean Willis, et al. I have to say I like your answers which clarify my doubts. May I suggest adding some words in " 6. Legacy Uses of INFO" to clarify the new SIP INFO Package approach and Content Type Approach? Maybe in the introduction section we can add more information about the Content Type approach. I mean not only talking about the JPEG example. Even in controlled Content-Type there maybe issues too as Dean said. Current working in introduction section leads me to think about new method is only applicable for not-controlled Conent-Type. Quote from Dean's email, rewording maybe needed--------------------------------------------------------------------- The MIME type model defines only "what an object is", not "how the object can be used". To negotiate around "how the object will be used in this application", we need a higher-level of specification and negotiation. IN SIP INFO messages, the INFO package definition provides that level of specification and negotiation. in countless application scenarios that the MIME type registration has no way of predicting or controlling. To constrain this diversity in a useful way in the context of NOTIFY messages within the SIP protocol, we have historically use event packages, and found this approach to work quite well. Going forward, in the context of INFO messages within the SIP protocol, we will use INFO packages for the same reasons. Cheers, Linyi -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, September 23, 2009 2:40 AM To: tianlinyi 34932 Cc: 'Sanjay Sinha (sanjsinh)'; sipcore@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote: > Hi, Paul > > As i said there is specification clearly states the usage of Content > type and a registration with this Content Type will be provided. The > specification will also mention how it will be used in SIP INFO, why > it is still un-specified? > > For example, if 3GPP defines the content type and its usage with SIP > INFO in a specification why INFO package hearder should be used? I > didn't see any IOP problem on this approach. > If 3GPP were to define a new MIME type that is only used in SIP INFO messages, then you are correct in that the INFO package framework would add little value. However, this is not how MIME types work. The MIME type model defines only "what an object is", not "how the object can be used". To negotiate around "how the object will be used in this application", we need a higher-level of specification and negotiation. IN SIP INFO messages, the INFO package definition provides that level of specification and negotiation. The MIME registration process doesn't register things like "This MIME type can only be used in a SIP INFO message in accordance with the foobar application as documented in 3GPP TS 99.411." And if somebody tried to register such a restricted MIME type, I'd hope the ietf-types people would say "no." Of course, there's no guarantee that no broken types are going to be registered (especially in vendor trees), but certainly the majority of existing types aren't broken like this. Once a type is defined, objects os that type can br transported in email, HTTP requests, SIP INFO, NOTIFY, and other requests messages, stored in Windows registries, and so on, in countless application scenarios that the MIME type registration has no way of predicting or controlling. To constrain this diversity in a useful way in the context of NOTIFY messages within the SIP protocol, we have historically use event packages, and found this approach to work quite well. Going forward, in the context of INFO messages within the SIP protocol, we will use INFO packages for the same reasons. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From eburger@standardstrack.com Tue Sep 22 19:50:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95713A69E9 for ; Tue, 22 Sep 2009 19:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, SARE_NETPROD=0.111] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exAy4gb093cR; Tue, 22 Sep 2009 19:50:50 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 6DACE3A6820; Tue, 22 Sep 2009 19:50:46 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.25.204]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MqHxB-0007of-Ib; Tue, 22 Sep 2009 19:51:37 -0700 From: Eric Burger To: Linyi Tian In-Reply-To: <02d601ca3be8$5d818060$18848120$@com> References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> Message-Id: <028096A8-801E-40B7-856C-7FE8ABACA130@standardstrack.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Sep 2009 22:51:41 -0400 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: ietf-types@iana.org, SIPCORE , ietf-types@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 02:50:52 -0000 How about this: 1. If someone tries to register a MIME type that will "only" be used for SIP, there is a near 100% likelihood the registration will not pass expert review. Thus you will not have a standard INFO usage. Dean explains why: MIME describes multimedia content. MIME does not describe multimedia use. 2. If someone tries to document a *new* legacy use of INFO that does not use the INFO Framework, there is a near 100% likelihood the document will neither pass expert review nor succeed as an individual informational submission, as the INFO Framework draft makes clear why such documentation may harm the Internet. [Old legacy usages were encouraged to be published, but the only usage that I know of that anyone will publish the IETF has not published yet is MSML, and that is stuck behind two drafts in final, final edits in MEDIACTRL.] 3. IETF will use the INFO Framework for all new INFO usages. Any proprietary use of INFO that does not use the INFO Framework will not be an IETF standard. 4. 3GPP (IMS) will use the INFO Framework. Any proprietary use of INFO that does not use the INFO Framework will not be an IMS standard. 5. All of your competitors will do their best to advertise how your product is totally proprietary and is likely to fail in the field. Moreover, your competitors will advertise how your product can harm the Internet. Finally, if someone *does* register your "magic MIME type", which is something that is quite possible to happen, *YOUR* customers will have to replace / upgrade / remove *YOUR* equipment. Most customers in the telecom space will see that and immediately tell you to build to the standards. Said differently, your product managers will not be very happy with someone who suggests one builds a product one cannot sell or even give away. Given the above, like many people have said, the legacy INFO method "works," in that you can build a non-interoperable, non-standard, totally proprietary, should not be connected to the Internet product. I would also offer such products are a little bit outside the charter of the IETF. We work to build interoperable, standards-based, open, Internet products that people can use safely. Even 3GPP and the ITU-T, for all of the ills many in the IETF would accuse them of, would not consider such a proposal. On Sep 22, 2009, at 8:54 PM, Linyi TIAN wrote: > Hi, Dean Willis, et al. > > I have to say I like your answers which clarify my doubts. May I > suggest > adding some words in " 6. Legacy Uses of INFO" to clarify the new > SIP INFO > Package approach and Content Type Approach? Maybe in the introduction > section we can add more information about the Content Type approach. > I mean > not only talking about the JPEG example. Even in controlled Content- > Type > there maybe issues too as Dean said. > > Current working in introduction section leads me to think about new > method > is only applicable for not-controlled Conent-Type. > > Quote from Dean's email, rewording maybe > needed > --------------------------------------------------------------------- > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > in countless application scenarios that the MIME type registration > has no > way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > Cheers, > Linyi > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > Of Dean Willis > Sent: Wednesday, September 23, 2009 2:40 AM > To: tianlinyi 34932 > Cc: 'Sanjay Sinha (sanjsinh)'; sipcore@ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote: > >> Hi, Paul >> >> As i said there is specification clearly states the usage of Content >> type and a registration with this Content Type will be provided. The >> specification will also mention how it will be used in SIP INFO, why >> it is still un-specified? >> >> For example, if 3GPP defines the content type and its usage with SIP >> INFO in a specification why INFO package hearder should be used? I >> didn't see any IOP problem on this approach. >> > > > If 3GPP were to define a new MIME type that is only used in SIP INFO > messages, then you are correct in that the INFO package framework > would add little value. > > However, this is not how MIME types work. > > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > The MIME registration process doesn't register things like "This MIME > type can only be used in a SIP INFO message in accordance with the > foobar application as documented in 3GPP TS 99.411." And if somebody > tried to register such a restricted MIME type, I'd hope the ietf-types > people would say "no." Of course, there's no guarantee that no > broken types are going to be registered (especially in vendor trees), > but certainly the majority of existing types aren't broken like this. > Once a type is defined, objects os that type can br transported in > email, HTTP requests, SIP INFO, NOTIFY, and other requests messages, > stored in Windows registries, and so on, in countless application > scenarios that the MIME type registration has no way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Tue Sep 22 20:52:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAB53A690A for ; Tue, 22 Sep 2009 20:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5F-15Xyc4mR for ; Tue, 22 Sep 2009 20:52:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C621C3A6874 for ; Tue, 22 Sep 2009 20:52:25 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8N3rMEg009945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Sep 2009 22:53:24 -0500 Message-Id: <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> From: Dean Willis To: Linyi TIAN In-Reply-To: <02d601ca3be8$5d818060$18848120$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Sep 2009 22:53:16 -0500 References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:52:27 -0000 On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > Hi, Dean Willis, et al. > > I have to say I like your answers which clarify my doubts. May I > suggest > adding some words in " 6. Legacy Uses of INFO" to clarify the new > SIP INFO > Package approach and Content Type Approach? Maybe in the introduction > section we can add more information about the Content Type approach. > I mean > not only talking about the JPEG example. Even in controlled Content- > Type > there maybe issues too as Dean said. We've tried to do this in the Introduction to draft-itf-sipcore-info- events-00. The text currently says: > While INFO has been widely adopted for specific application use > cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither > defined a negotiation mechanism nor a means by which to explicitly > indicate the type of application information contained in the INFO > message. This led to problems associated with static configuration. > In addition, the industry realized there was a potential for > interoperability problems due to undefined content syntax and > semantics. This draft addresses these deficiencies and provides a > framework for explicit negotiation of capabilities and content > context using "Info Packages". > The INFO method as defined by RFC 2976 did not provide any context > for the information the request carried. While it may sometimes be > clear what the content is based on the Content-Type, this is only > true where there is only one contextual usage of the content-type. > For example, if the Content-Type is "image/jpeg", the MIME-attached > content is a JPEG image. However, there are many useful ways a UAS > can render an image. Said differently, there are different contexts > for an image in SIP. The image could be a caller-id picture, a > contact icon, a photo for sharing, and so on. The sender does not > know which image to send to the receiver if the receiver supports an > image content type. Likewise, the receiver does not know the > context of an image the client is sending if the receiver supports > receiving more than one image content type. Thus, we need a well > defined and documented statement of what the information sent is > for. This situation is identical to the context issue in Internet > Mail [RFC3458]. RFC 3458 goes into this and other issues in detail. I would not object to adding material here to further illustrate why Content-Type alone is insufficient, assuming we can find a way to say it that doesn't further confuse the reader. Of course, I'm not the editor of the document, so I can only suggest this as a contributor to the working group. Likewise, you suggested modifying Section 6, Legacy Uses of Info. This section starts with: Several RFC-defined and other standards-defined uses of RFC 2976 INFO [RFC2976] exist and are in use, as well as numerous proprietary uses. Appendix B describes some of these usages. By definition, identifying such uses has relied on either static local configuration or implicit context determination based on the body Content-Type or Content-Disposition value or some proprietary mechanism. This draft cannot forbid nor avoid such uses, since local configuration can always override standardized mechanisms. From what I understand, you are proposing to add some text here that essentially explains how Content-Type combined with local configuration provided adequate context for the legacy usages of INFO. In other words, describing how the constrained environment of RFC 2976 prevented users from encountering the kinds of problems that INFO- package is attempting to prevent. I can see that such text might be usefully added here, if we can find a way to say it that doesn't leave the average reader even more confused. -- Dean From tianlinyi@huawei.com Tue Sep 22 21:52:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9743A6955 for ; Tue, 22 Sep 2009 21:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuZtF6f88P6E for ; Tue, 22 Sep 2009 21:52:28 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 349833A691A for ; Tue, 22 Sep 2009 21:52:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE00BCIQWVRG@szxga03-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 12:53:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE00JI0QWV29@szxga03-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 12:53:19 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQE00FQ6QWVSP@szxml04-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 12:53:19 +0800 (CST) Date: Wed, 23 Sep 2009 12:53:19 +0800 From: Linyi TIAN In-reply-to: <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> To: 'Dean Willis' Message-id: <02e701ca3c09$c560ad20$50220760$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco8AWwdsZDQWBb1Qmysdle7eDsEnwAB+q/A References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> Cc: 'SIPCORE' Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 04:52:29 -0000 Hi, Dean If you read the following text in introduction section, it may be understood as when the Content-Type indicates one contextual usage then SIP INFO Package is not needed. That is what we are debating in other SDOs. While it may sometimes be clear what the content is based on the Content-Type, this is only true where there is only one contextual usage of the content-type. This is why I ask questions here and want the author to clarify it in the I-D. I hope our concerns can be take into account in next revision, e.g. update the introduction and section 6. Cheers, Linyi -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, September 23, 2009 11:53 AM To: Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > Hi, Dean Willis, et al. > > I have to say I like your answers which clarify my doubts. May I > suggest > adding some words in " 6. Legacy Uses of INFO" to clarify the new > SIP INFO > Package approach and Content Type Approach? Maybe in the introduction > section we can add more information about the Content Type approach. > I mean > not only talking about the JPEG example. Even in controlled Content- > Type > there maybe issues too as Dean said. We've tried to do this in the Introduction to draft-itf-sipcore-info- events-00. The text currently says: > While INFO has been widely adopted for specific application use > cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither > defined a negotiation mechanism nor a means by which to explicitly > indicate the type of application information contained in the INFO > message. This led to problems associated with static configuration. > In addition, the industry realized there was a potential for > interoperability problems due to undefined content syntax and > semantics. This draft addresses these deficiencies and provides a > framework for explicit negotiation of capabilities and content > context using "Info Packages". > The INFO method as defined by RFC 2976 did not provide any context > for the information the request carried. While it may sometimes be > clear what the content is based on the Content-Type, this is only > true where there is only one contextual usage of the content-type. > For example, if the Content-Type is "image/jpeg", the MIME-attached > content is a JPEG image. However, there are many useful ways a UAS > can render an image. Said differently, there are different contexts > for an image in SIP. The image could be a caller-id picture, a > contact icon, a photo for sharing, and so on. The sender does not > know which image to send to the receiver if the receiver supports an > image content type. Likewise, the receiver does not know the > context of an image the client is sending if the receiver supports > receiving more than one image content type. Thus, we need a well > defined and documented statement of what the information sent is > for. This situation is identical to the context issue in Internet > Mail [RFC3458]. RFC 3458 goes into this and other issues in detail. I would not object to adding material here to further illustrate why Content-Type alone is insufficient, assuming we can find a way to say it that doesn't further confuse the reader. Of course, I'm not the editor of the document, so I can only suggest this as a contributor to the working group. Likewise, you suggested modifying Section 6, Legacy Uses of Info. This section starts with: Several RFC-defined and other standards-defined uses of RFC 2976 INFO [RFC2976] exist and are in use, as well as numerous proprietary uses. Appendix B describes some of these usages. By definition, identifying such uses has relied on either static local configuration or implicit context determination based on the body Content-Type or Content-Disposition value or some proprietary mechanism. This draft cannot forbid nor avoid such uses, since local configuration can always override standardized mechanisms. From what I understand, you are proposing to add some text here that essentially explains how Content-Type combined with local configuration provided adequate context for the legacy usages of INFO. In other words, describing how the constrained environment of RFC 2976 prevented users from encountering the kinds of problems that INFO- package is attempting to prevent. I can see that such text might be usefully added here, if we can find a way to say it that doesn't leave the average reader even more confused. -- Dean From tianlinyi@huawei.com Tue Sep 22 21:55:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA373A691A for ; Tue, 22 Sep 2009 21:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_NETPROD=0.111] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5anE8YA0kaL9; Tue, 22 Sep 2009 21:55:24 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 8DD513A6864; Tue, 22 Sep 2009 21:55:24 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE005QNR1VCN@szxga01-in.huawei.com>; Wed, 23 Sep 2009 12:56:19 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE00E4JR1V1Z@szxga01-in.huawei.com>; Wed, 23 Sep 2009 12:56:19 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQE00I2NR1U86@szxml04-in.huawei.com>; Wed, 23 Sep 2009 12:56:19 +0800 (CST) Date: Wed, 23 Sep 2009 12:56:18 +0800 From: Linyi TIAN In-reply-to: <028096A8-801E-40B7-856C-7FE8ABACA130@standardstrack.com> To: 'Eric Burger' Message-id: <02e801ca3c0a$3037e730$90a7b590$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco7+PpBiAuU99vJS5qtdilTrgTZ5QAEQ9oA References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <028096A8-801E-40B7-856C-7FE8ABACA130@standardstrack.com> Cc: ietf-types@iana.org, 'SIPCORE' , ietf-types@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 04:55:26 -0000 You misunderstood my intention. Please see my response to Dean about adding some text to further explain the benefit for SIP INFO FW and the issue for SIP INFO. Cheers, Linyi -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger Sent: Wednesday, September 23, 2009 10:52 AM To: Linyi Tian Cc: ietf-types@iana.org; SIPCORE; ietf-types@ietf.org Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package How about this: 1. If someone tries to register a MIME type that will "only" be used for SIP, there is a near 100% likelihood the registration will not pass expert review. Thus you will not have a standard INFO usage. Dean explains why: MIME describes multimedia content. MIME does not describe multimedia use. 2. If someone tries to document a *new* legacy use of INFO that does not use the INFO Framework, there is a near 100% likelihood the document will neither pass expert review nor succeed as an individual informational submission, as the INFO Framework draft makes clear why such documentation may harm the Internet. [Old legacy usages were encouraged to be published, but the only usage that I know of that anyone will publish the IETF has not published yet is MSML, and that is stuck behind two drafts in final, final edits in MEDIACTRL.] 3. IETF will use the INFO Framework for all new INFO usages. Any proprietary use of INFO that does not use the INFO Framework will not be an IETF standard. 4. 3GPP (IMS) will use the INFO Framework. Any proprietary use of INFO that does not use the INFO Framework will not be an IMS standard. 5. All of your competitors will do their best to advertise how your product is totally proprietary and is likely to fail in the field. Moreover, your competitors will advertise how your product can harm the Internet. Finally, if someone *does* register your "magic MIME type", which is something that is quite possible to happen, *YOUR* customers will have to replace / upgrade / remove *YOUR* equipment. Most customers in the telecom space will see that and immediately tell you to build to the standards. Said differently, your product managers will not be very happy with someone who suggests one builds a product one cannot sell or even give away. Given the above, like many people have said, the legacy INFO method "works," in that you can build a non-interoperable, non-standard, totally proprietary, should not be connected to the Internet product. I would also offer such products are a little bit outside the charter of the IETF. We work to build interoperable, standards-based, open, Internet products that people can use safely. Even 3GPP and the ITU-T, for all of the ills many in the IETF would accuse them of, would not consider such a proposal. On Sep 22, 2009, at 8:54 PM, Linyi TIAN wrote: > Hi, Dean Willis, et al. > > I have to say I like your answers which clarify my doubts. May I > suggest > adding some words in " 6. Legacy Uses of INFO" to clarify the new > SIP INFO > Package approach and Content Type Approach? Maybe in the introduction > section we can add more information about the Content Type approach. > I mean > not only talking about the JPEG example. Even in controlled Content- > Type > there maybe issues too as Dean said. > > Current working in introduction section leads me to think about new > method > is only applicable for not-controlled Conent-Type. > > Quote from Dean's email, rewording maybe > needed > --------------------------------------------------------------------- > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > in countless application scenarios that the MIME type registration > has no > way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > Cheers, > Linyi > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > Of Dean Willis > Sent: Wednesday, September 23, 2009 2:40 AM > To: tianlinyi 34932 > Cc: 'Sanjay Sinha (sanjsinh)'; sipcore@ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote: > >> Hi, Paul >> >> As i said there is specification clearly states the usage of Content >> type and a registration with this Content Type will be provided. The >> specification will also mention how it will be used in SIP INFO, why >> it is still un-specified? >> >> For example, if 3GPP defines the content type and its usage with SIP >> INFO in a specification why INFO package hearder should be used? I >> didn't see any IOP problem on this approach. >> > > > If 3GPP were to define a new MIME type that is only used in SIP INFO > messages, then you are correct in that the INFO package framework > would add little value. > > However, this is not how MIME types work. > > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > The MIME registration process doesn't register things like "This MIME > type can only be used in a SIP INFO message in accordance with the > foobar application as documented in 3GPP TS 99.411." And if somebody > tried to register such a restricted MIME type, I'd hope the ietf-types > people would say "no." Of course, there's no guarantee that no > broken types are going to be registered (especially in vendor trees), > but certainly the majority of existing types aren't broken like this. > Once a type is defined, objects os that type can br transported in > email, HTTP requests, SIP INFO, NOTIFY, and other requests messages, > stored in Windows registries, and so on, in countless application > scenarios that the MIME type registration has no way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Sep 22 21:57:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AE13A6864 for ; Tue, 22 Sep 2009 21:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.6 X-Spam-Level: X-Spam-Status: No, score=-5.6 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRYhFJJ5t-Mt for ; Tue, 22 Sep 2009 21:57:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6A8013A69AF for ; Tue, 22 Sep 2009 21:57:28 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-83-4ab9aaf8a131 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F5.56.15624.8FAA9BA4; Wed, 23 Sep 2009 06:58:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 06:57:33 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 23 Sep 2009 06:57:32 +0200 Message-ID: In-Reply-To: <02e701ca3c09$c560ad20$50220760$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco8AWwdsZDQWBb1Qmysdle7eDsEnwAB+q/AAAAnrFA= References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Dean Willis" X-OriginalArrivalTime: 23 Sep 2009 04:57:33.0773 (UTC) FILETIME=[5CCC8FD0:01CA3C0A] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 04:57:30 -0000 Hi, There will be a new version of the draft shortly, where some re-wording/clarification has been done. Let's see if it is more clear there. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > Sent: 23. syyskuuta 2009 7:53 > To: 'Dean Willis' > Cc: 'SIPCORE' > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 > Hi, Dean >=20 > If you read the following text in introduction section, it=20 > may be understood as when the Content-Type indicates one=20 > contextual usage then SIP INFO Package is not needed. That is=20 > what we are debating in other SDOs.=20 > While it may sometimes be clear what the content is based on=20 > the Content-Type, this is only true where there is only one=20 > contextual usage of the content-type. >=20 > This is why I ask questions here and want the author to=20 > clarify it in the I-D. I hope our concerns can be take into=20 > account in next revision, e.g. > update the introduction and section 6. >=20 > Cheers, > Linyi >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 >=20 > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: >=20 > > Hi, Dean Willis, et al. > > > > I have to say I like your answers which clarify my doubts. May I =20 > > suggest > > adding some words in " 6. Legacy Uses of INFO" to clarify the new =20 > > SIP INFO > > Package approach and Content Type Approach? Maybe in the=20 > introduction > > section we can add more information about the Content Type=20 > approach. =20 > > I mean > > not only talking about the JPEG example. Even in controlled=20 > Content-=20 > > Type > > there maybe issues too as Dean said. >=20 >=20 >=20 > We've tried to do this in the Introduction to draft-itf-sipcore-info-=20 > events-00. The text currently says: >=20 > > While INFO has been widely adopted for specific application use =20 > > cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither =20 > > defined a negotiation mechanism nor a means by which to explicitly =20 > > indicate the type of application information contained in the INFO =20 > > message. This led to problems associated with static=20 > configuration. =20 > > In addition, the industry realized there was a potential for =20 > > interoperability problems due to undefined content syntax and =20 > > semantics. This draft addresses these deficiencies and provides a =20 > > framework for explicit negotiation of capabilities and content =20 > > context using "Info Packages". >=20 >=20 > > The INFO method as defined by RFC 2976 did not provide any context =20 > > for the information the request carried. While it may=20 > sometimes be =20 > > clear what the content is based on the Content-Type, this is only =20 > > true where there is only one contextual usage of the content-type. =20 > > For example, if the Content-Type is "image/jpeg", the=20 > MIME-attached =20 > > content is a JPEG image. However, there are many useful=20 > ways a UAS =20 > > can render an image. Said differently, there are different=20 > contexts =20 > > for an image in SIP. The image could be a caller-id picture, a =20 > > contact icon, a photo for sharing, and so on. The sender does not =20 > > know which image to send to the receiver if the receiver=20 > supports an =20 > > image content type. Likewise, the receiver does not know the =20 > > context of an image the client is sending if the receiver supports =20 > > receiving more than one image content type. Thus, we need a well =20 > > defined and documented statement of what the information sent is =20 > > for. This situation is identical to the context issue in Internet =20 > > Mail [RFC3458]. RFC 3458 goes into this and other issues in detail. >=20 >=20 > I would not object to adding material here to further illustrate why =20 > Content-Type alone is insufficient, assuming we can find a=20 > way to say =20 > it that doesn't further confuse the reader. Of course, I'm not the =20 > editor of the document, so I can only suggest this as a=20 > contributor to =20 > the working group. >=20 > Likewise, you suggested modifying Section 6, Legacy Uses of=20 > Info. This =20 > section starts with: >=20 > Several RFC-defined and other standards-defined uses of RFC 2976 =20 > INFO > [RFC2976] exist and are in use, as well as numerous proprietary =20 > uses. > Appendix B describes some of these usages. By definition, > identifying such uses has relied on either static local =20 > configuration > or implicit context determination based on the body=20 > Content-Type or > Content-Disposition value or some proprietary mechanism. =20 > This draft > cannot forbid nor avoid such uses, since local configuration can > always override standardized mechanisms. >=20 > From what I understand, you are proposing to add some text=20 > here that =20 > essentially explains how Content-Type combined with local =20 > configuration provided adequate context for the legacy usages=20 > of INFO. =20 > In other words, describing how the constrained environment of=20 > RFC 2976 =20 > prevented users from encountering the kinds of problems that INFO-=20 > package is attempting to prevent. I can see that such text might be =20 > usefully added here, if we can find a way to say it that=20 > doesn't leave =20 > the average reader even more confused. >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From eburger@standardstrack.com Wed Sep 23 03:26:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A68228C0F6 for ; Wed, 23 Sep 2009 03:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEDvhft1CNS8 for ; Wed, 23 Sep 2009 03:26:52 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 6046028C0E9 for ; Wed, 23 Sep 2009 03:26:52 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.25.204]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MqP4Y-00049h-3c; Wed, 23 Sep 2009 03:27:42 -0700 Message-Id: <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> From: Eric Burger To: Linyi TIAN In-Reply-To: <02e701ca3c09$c560ad20$50220760$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Sep 2009 06:27:50 -0400 References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 10:26:53 -0000 Now I think I understand. Do we agree the request is to make it very, very, very clear that new usages of INFO outside the INFO Framework is not only a bad idea but will not be tolerated? If so, I think we can figure out some wording for that. On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > You misunderstood my intention. Please see my response to Dean about > adding > some text to further explain the benefit for SIP INFO FW and the > issue for > SIP INFO. > > Cheers, > Linyi On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > Hi, Dean > > If you read the following text in introduction section, it may be > understood > as when the Content-Type indicates one contextual usage then SIP INFO > Package is not needed. That is what we are debating in other SDOs. > While it may sometimes be clear what the content is based on the > Content-Type, this is only true where there is only one contextual > usage of > the content-type. > > This is why I ask questions here and want the author to clarify it > in the > I-D. I hope our concerns can be take into account in next revision, > e.g. > update the introduction and section 6. > > Cheers, > Linyi > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >> Hi, Dean Willis, et al. >> >> I have to say I like your answers which clarify my doubts. May I >> suggest >> adding some words in " 6. Legacy Uses of INFO" to clarify the new >> SIP INFO >> Package approach and Content Type Approach? Maybe in the introduction >> section we can add more information about the Content Type approach. >> I mean >> not only talking about the JPEG example. Even in controlled Content- >> Type >> there maybe issues too as Dean said. > > > > We've tried to do this in the Introduction to draft-itf-sipcore-info- > events-00. The text currently says: > >> While INFO has been widely adopted for specific application use >> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither >> defined a negotiation mechanism nor a means by which to explicitly >> indicate the type of application information contained in the INFO >> message. This led to problems associated with static configuration. >> In addition, the industry realized there was a potential for >> interoperability problems due to undefined content syntax and >> semantics. This draft addresses these deficiencies and provides a >> framework for explicit negotiation of capabilities and content >> context using "Info Packages". > > >> The INFO method as defined by RFC 2976 did not provide any context >> for the information the request carried. While it may sometimes be >> clear what the content is based on the Content-Type, this is only >> true where there is only one contextual usage of the content-type. >> For example, if the Content-Type is "image/jpeg", the MIME-attached >> content is a JPEG image. However, there are many useful ways a UAS >> can render an image. Said differently, there are different contexts >> for an image in SIP. The image could be a caller-id picture, a >> contact icon, a photo for sharing, and so on. The sender does not >> know which image to send to the receiver if the receiver supports an >> image content type. Likewise, the receiver does not know the >> context of an image the client is sending if the receiver supports >> receiving more than one image content type. Thus, we need a well >> defined and documented statement of what the information sent is >> for. This situation is identical to the context issue in Internet >> Mail [RFC3458]. RFC 3458 goes into this and other issues in detail. > > > I would not object to adding material here to further illustrate why > Content-Type alone is insufficient, assuming we can find a way to say > it that doesn't further confuse the reader. Of course, I'm not the > editor of the document, so I can only suggest this as a contributor to > the working group. > > Likewise, you suggested modifying Section 6, Legacy Uses of Info. This > section starts with: > > Several RFC-defined and other standards-defined uses of RFC 2976 > INFO > [RFC2976] exist and are in use, as well as numerous proprietary > uses. > Appendix B describes some of these usages. By definition, > identifying such uses has relied on either static local > configuration > or implicit context determination based on the body Content-Type or > Content-Disposition value or some proprietary mechanism. This > draft > cannot forbid nor avoid such uses, since local configuration can > always override standardized mechanisms. > > From what I understand, you are proposing to add some text here that > essentially explains how Content-Type combined with local > configuration provided adequate context for the legacy usages of INFO. > In other words, describing how the constrained environment of RFC 2976 > prevented users from encountering the kinds of problems that INFO- > package is attempting to prevent. I can see that such text might be > usefully added here, if we can find a way to say it that doesn't leave > the average reader even more confused. > > -- > Dean > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Sep 23 04:14:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E713A68F2 for ; Wed, 23 Sep 2009 04:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv-WqFexZflq for ; Wed, 23 Sep 2009 04:14:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5E75C3A68BE for ; Wed, 23 Sep 2009 04:14:49 -0700 (PDT) X-AuditID: c1b4fb3e-b7c03ae0000055e7-e0-4aba033e3a11 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CA.D7.21991.E330ABA4; Wed, 23 Sep 2009 13:15:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 13:14:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Sep 2009 13:12:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco8OIfhRY4kjKHHRuWTiSrHc0PZKQABkNFj References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com><02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> From: "Christer Holmberg" To: "Eric Burger" , "Linyi TIAN" X-OriginalArrivalTime: 23 Sep 2009 11:14:20.0508 (UTC) FILETIME=[FF7691C0:01CA3C3E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 11:14:51 -0000 There is text in the draft which says that, for backward compability = purpose, legacy usage of INFO is allowed. If needed, we can simply add a = statement saying: "Any new usage of INFO MUST use the Info Package = mechanism". =20 Regards, =20 Christer ________________________________ From: sipcore-bounces@ietf.org on behalf of Eric Burger Sent: Wed 9/23/2009 12:27 PM To: Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Now I think I understand. Do we agree the request is to make it very,=20 very, very clear that new usages of INFO outside the INFO Framework is=20 not only a bad idea but will not be tolerated? If so, I think we can=20 figure out some wording for that. On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > You misunderstood my intention. Please see my response to Dean about=20 > adding > some text to further explain the benefit for SIP INFO FW and the=20 > issue for > SIP INFO. > > Cheers, > Linyi On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > Hi, Dean > > If you read the following text in introduction section, it may be=20 > understood > as when the Content-Type indicates one contextual usage then SIP INFO > Package is not needed. That is what we are debating in other SDOs. > While it may sometimes be clear what the content is based on the > Content-Type, this is only true where there is only one contextual=20 > usage of > the content-type. > > This is why I ask questions here and want the author to clarify it=20 > in the > I-D. I hope our concerns can be take into account in next revision,=20 > e.g. > update the introduction and section 6. > > Cheers, > Linyi > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >> Hi, Dean Willis, et al. >> >> I have to say I like your answers which clarify my doubts. May I >> suggest >> adding some words in " 6. Legacy Uses of INFO" to clarify the new >> SIP INFO >> Package approach and Content Type Approach? Maybe in the introduction >> section we can add more information about the Content Type approach. >> I mean >> not only talking about the JPEG example. Even in controlled Content- >> Type >> there maybe issues too as Dean said. > > > > We've tried to do this in the Introduction to draft-itf-sipcore-info- > events-00. The text currently says: > >> While INFO has been widely adopted for specific application use >> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither >> defined a negotiation mechanism nor a means by which to explicitly >> indicate the type of application information contained in the INFO >> message. This led to problems associated with static configuration. >> In addition, the industry realized there was a potential for >> interoperability problems due to undefined content syntax and >> semantics. This draft addresses these deficiencies and provides a >> framework for explicit negotiation of capabilities and content >> context using "Info Packages". > > >> The INFO method as defined by RFC 2976 did not provide any context >> for the information the request carried. While it may sometimes be >> clear what the content is based on the Content-Type, this is only >> true where there is only one contextual usage of the content-type. >> For example, if the Content-Type is "image/jpeg", the MIME-attached >> content is a JPEG image. However, there are many useful ways a UAS >> can render an image. Said differently, there are different contexts >> for an image in SIP. The image could be a caller-id picture, a >> contact icon, a photo for sharing, and so on. The sender does not >> know which image to send to the receiver if the receiver supports an >> image content type. Likewise, the receiver does not know the >> context of an image the client is sending if the receiver supports >> receiving more than one image content type. Thus, we need a well >> defined and documented statement of what the information sent is >> for. This situation is identical to the context issue in Internet >> Mail [RFC3458]. RFC 3458 goes into this and other issues in detail. > > > I would not object to adding material here to further illustrate why > Content-Type alone is insufficient, assuming we can find a way to say > it that doesn't further confuse the reader. Of course, I'm not the > editor of the document, so I can only suggest this as a contributor to > the working group. > > Likewise, you suggested modifying Section 6, Legacy Uses of Info. This > section starts with: > > Several RFC-defined and other standards-defined uses of RFC 2976 > INFO > [RFC2976] exist and are in use, as well as numerous proprietary > uses. > Appendix B describes some of these usages. By definition, > identifying such uses has relied on either static local > configuration > or implicit context determination based on the body Content-Type or > Content-Disposition value or some proprietary mechanism. This=20 > draft > cannot forbid nor avoid such uses, since local configuration can > always override standardized mechanisms. > > From what I understand, you are proposing to add some text here that > essentially explains how Content-Type combined with local > configuration provided adequate context for the legacy usages of INFO. > In other words, describing how the constrained environment of RFC 2976 > prevented users from encountering the kinds of problems that INFO- > package is attempting to prevent. I can see that such text might be > usefully added here, if we can find a way to say it that doesn't leave > the average reader even more confused. > > -- > Dean > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From george.foti@ericsson.com Wed Sep 23 04:42:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92003A6A0F for ; Wed, 23 Sep 2009 04:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtRxqCyEj5wT for ; Wed, 23 Sep 2009 04:42:48 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6E97D3A679C for ; Wed, 23 Sep 2009 04:42:48 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8NBhf9g031983; Wed, 23 Sep 2009 06:43:44 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 06:43:34 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 06:43:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 23 Sep 2009 07:43:33 -0400 From: George Foti To: Christer Holmberg , Eric Burger , Linyi TIAN Date: Wed, 23 Sep 2009 07:43:31 -0400 Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco8OIfhRY4kjKHHRuWTiSrHc0PZKQABkNFjAAEFGcA= Message-ID: References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com><02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Sep 2009 11:43:34.0067 (UTC) FILETIME=[14AA7030:01CA3C43] Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 11:42:49 -0000 Yes, I would like a statement that explicitly disallows any usage of INFO o= utside the framework. Than we don't have to rehash this discussion once more. Rgds. George Foti Ericsson Canada =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, September 23, 2009 7:13 AM To: Eric Burger; Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package There is text in the draft which says that, for backward compability purpos= e, legacy usage of INFO is allowed. If needed, we can simply add a statemen= t saying: "Any new usage of INFO MUST use the Info Package mechanism". =20 Regards, =20 Christer ________________________________ From: sipcore-bounces@ietf.org on behalf of Eric Burger Sent: Wed 9/23/2009 12:27 PM To: Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Now I think I understand. Do we agree the request is to make it very, very= , very clear that new usages of INFO outside the INFO Framework is not only= a bad idea but will not be tolerated? If so, I think we can figure out so= me wording for that. On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > You misunderstood my intention. Please see my response to Dean about=20 > adding some text to further explain the benefit for SIP INFO FW and=20 > the issue for SIP INFO. > > Cheers, > Linyi On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > Hi, Dean > > If you read the following text in introduction section, it may be=20 > understood as when the Content-Type indicates one contextual usage=20 > then SIP INFO Package is not needed. That is what we are debating in=20 > other SDOs. > While it may sometimes be clear what the content is based on the=20 > Content-Type, this is only true where there is only one contextual=20 > usage of the content-type. > > This is why I ask questions here and want the author to clarify it in=20 > the I-D. I hope our concerns can be take into account in next=20 > revision, e.g. > update the introduction and section 6. > > Cheers, > Linyi > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >> Hi, Dean Willis, et al. >> >> I have to say I like your answers which clarify my doubts. May I=20 >> suggest adding some words in " 6. Legacy Uses of INFO" to clarify=20 >> the new SIP INFO Package approach and Content Type Approach? Maybe in=20 >> the introduction section we can add more information about the=20 >> Content Type approach. >> I mean >> not only talking about the JPEG example. Even in controlled Content-=20 >> Type there maybe issues too as Dean said. > > > > We've tried to do this in the Introduction to draft-itf-sipcore-info-=20 > events-00. The text currently says: > >> While INFO has been widely adopted for specific application use=20 >> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither=20 >> defined a negotiation mechanism nor a means by which to explicitly=20 >> indicate the type of application information contained in the INFO=20 >> message. This led to problems associated with static configuration. >> In addition, the industry realized there was a potential for=20 >> interoperability problems due to undefined content syntax and=20 >> semantics. This draft addresses these deficiencies and provides a=20 >> framework for explicit negotiation of capabilities and content=20 >> context using "Info Packages". > > >> The INFO method as defined by RFC 2976 did not provide any context=20 >> for the information the request carried. While it may sometimes be=20 >> clear what the content is based on the Content-Type, this is only=20 >> true where there is only one contextual usage of the content-type. >> For example, if the Content-Type is "image/jpeg", the MIME-attached=20 >> content is a JPEG image. However, there are many useful ways a UAS=20 >> can render an image. Said differently, there are different contexts=20 >> for an image in SIP. The image could be a caller-id picture, a=20 >> contact icon, a photo for sharing, and so on. The sender does not=20 >> know which image to send to the receiver if the receiver supports an=20 >> image content type. Likewise, the receiver does not know the context=20 >> of an image the client is sending if the receiver supports receiving=20 >> more than one image content type. Thus, we need a well defined and=20 >> documented statement of what the information sent is for. This=20 >> situation is identical to the context issue in Internet Mail=20 >> [RFC3458]. RFC 3458 goes into this and other issues in detail. > > > I would not object to adding material here to further illustrate why=20 > Content-Type alone is insufficient, assuming we can find a way to say=20 > it that doesn't further confuse the reader. Of course, I'm not the=20 > editor of the document, so I can only suggest this as a contributor to=20 > the working group. > > Likewise, you suggested modifying Section 6, Legacy Uses of Info. This=20 > section starts with: > > Several RFC-defined and other standards-defined uses of RFC 2976=20 > INFO > [RFC2976] exist and are in use, as well as numerous proprietary=20 > uses. > Appendix B describes some of these usages. By definition, > identifying such uses has relied on either static local=20 > configuration > or implicit context determination based on the body Content-Type or > Content-Disposition value or some proprietary mechanism. This=20 > draft > cannot forbid nor avoid such uses, since local configuration can > always override standardized mechanisms. > > From what I understand, you are proposing to add some text here that=20 > essentially explains how Content-Type combined with local=20 > configuration provided adequate context for the legacy usages of INFO. > In other words, describing how the constrained environment of RFC 2976=20 > prevented users from encountering the kinds of problems that INFO-=20 > package is attempting to prevent. I can see that such text might be=20 > usefully added here, if we can find a way to say it that doesn't leave=20 > the average reader even more confused. > > -- > Dean > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From george.foti@ericsson.com Wed Sep 23 05:57:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384203A6883 for ; Wed, 23 Sep 2009 05:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahxVCLadnO57 for ; Wed, 23 Sep 2009 05:57:27 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DBA043A6881 for ; Wed, 23 Sep 2009 05:57:26 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8NCwRU4015040; Wed, 23 Sep 2009 07:58:28 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 07:58:14 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 07:58:14 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 23 Sep 2009 08:58:13 -0400 From: George Foti To: Christer Holmberg , Eric Burger , Linyi TIAN Date: Wed, 23 Sep 2009 08:58:12 -0400 Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco8OIfhRY4kjKHHRuWTiSrHc0PZKQABkNFjAAEFGcAAAmH7SQAAOIew Message-ID: References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com><02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Sep 2009 12:58:14.0124 (UTC) FILETIME=[82FCE2C0:01CA3C4D] Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 12:57:28 -0000 Hi Christer, Yes, I am referring to including an explicit statement disallowing any NEW = info usage outside the Info event framework. Thanks George -----Original Message----- From: Christer Holmberg=20 Sent: Wednesday, September 23, 2009 8:50 AM To: George Foti; Eric Burger; Linyi TIAN Cc: SIPCORE Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, Just to clarify that you are allowed to use existing legacy INFO usages, if= such have already been specified. For example, if you want to support ISUP tunnelling it is perfectly ok to u= se the current mechanisms. You are not required to define an Info Package f= or that. BUT, if you are specifying a *NEW* INFO usage, then you MUST use the Info P= ackage framework. Regards, Christer -----Original Message----- From: George Foti Sent: Wed 9/23/2009 1:43 PM To: Christer Holmberg; Eric Burger; Linyi TIAN Cc: SIPCORE Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package =20 Yes, I would like a statement that explicitly disallows any usage of INFO o= utside the framework. Than we don't have to rehash this discussion once more. Rgds. George Foti Ericsson Canada =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, September 23, 2009 7:13 AM To: Eric Burger; Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package There is text in the draft which says that, for backward compability purpos= e, legacy usage of INFO is allowed. If needed, we can simply add a statemen= t saying: "Any new usage of INFO MUST use the Info Package mechanism". =20 Regards, =20 Christer ________________________________ From: sipcore-bounces@ietf.org on behalf of Eric Burger Sent: Wed 9/23/2009 12:27 PM To: Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Now I think I understand. Do we agree the request is to make it very, very= , very clear that new usages of INFO outside the INFO Framework is not only= a bad idea but will not be tolerated? If so, I think we can figure out so= me wording for that. On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > You misunderstood my intention. Please see my response to Dean about=20 > adding some text to further explain the benefit for SIP INFO FW and=20 > the issue for SIP INFO. > > Cheers, > Linyi On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > Hi, Dean > > If you read the following text in introduction section, it may be=20 > understood as when the Content-Type indicates one contextual usage=20 > then SIP INFO Package is not needed. That is what we are debating in=20 > other SDOs. > While it may sometimes be clear what the content is based on the=20 > Content-Type, this is only true where there is only one contextual=20 > usage of the content-type. > > This is why I ask questions here and want the author to clarify it in=20 > the I-D. I hope our concerns can be take into account in next=20 > revision, e.g. > update the introduction and section 6. > > Cheers, > Linyi > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >> Hi, Dean Willis, et al. >> >> I have to say I like your answers which clarify my doubts. May I=20 >> suggest adding some words in " 6. Legacy Uses of INFO" to clarify=20 >> the new SIP INFO Package approach and Content Type Approach? Maybe in=20 >> the introduction section we can add more information about the=20 >> Content Type approach. >> I mean >> not only talking about the JPEG example. Even in controlled Content-=20 >> Type there maybe issues too as Dean said. > > > > We've tried to do this in the Introduction to draft-itf-sipcore-info-=20 > events-00. The text currently says: > >> While INFO has been widely adopted for specific application use=20 >> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither=20 >> defined a negotiation mechanism nor a means by which to explicitly=20 >> indicate the type of application information contained in the INFO=20 >> message. This led to problems associated with static configuration. >> In addition, the industry realized there was a potential for=20 >> interoperability problems due to undefined content syntax and=20 >> semantics. This draft addresses these deficiencies and provides a=20 >> framework for explicit negotiation of capabilities and content=20 >> context using "Info Packages". > > >> The INFO method as defined by RFC 2976 did not provide any context=20 >> for the information the request carried. While it may sometimes be=20 >> clear what the content is based on the Content-Type, this is only=20 >> true where there is only one contextual usage of the content-type. >> For example, if the Content-Type is "image/jpeg", the MIME-attached=20 >> content is a JPEG image. However, there are many useful ways a UAS=20 >> can render an image. Said differently, there are different contexts=20 >> for an image in SIP. The image could be a caller-id picture, a=20 >> contact icon, a photo for sharing, and so on. The sender does not=20 >> know which image to send to the receiver if the receiver supports an=20 >> image content type. Likewise, the receiver does not know the context=20 >> of an image the client is sending if the receiver supports receiving=20 >> more than one image content type. Thus, we need a well defined and=20 >> documented statement of what the information sent is for. This=20 >> situation is identical to the context issue in Internet Mail=20 >> [RFC3458]. RFC 3458 goes into this and other issues in detail. > > > I would not object to adding material here to further illustrate why=20 > Content-Type alone is insufficient, assuming we can find a way to say=20 > it that doesn't further confuse the reader. Of course, I'm not the=20 > editor of the document, so I can only suggest this as a contributor to=20 > the working group. > > Likewise, you suggested modifying Section 6, Legacy Uses of Info. This=20 > section starts with: > > Several RFC-defined and other standards-defined uses of RFC 2976=20 > INFO > [RFC2976] exist and are in use, as well as numerous proprietary=20 > uses. > Appendix B describes some of these usages. By definition, > identifying such uses has relied on either static local=20 > configuration > or implicit context determination based on the body Content-Type or > Content-Disposition value or some proprietary mechanism. This=20 > draft > cannot forbid nor avoid such uses, since local configuration can > always override standardized mechanisms. > > From what I understand, you are proposing to add some text here that=20 > essentially explains how Content-Type combined with local=20 > configuration provided adequate context for the legacy usages of INFO. > In other words, describing how the constrained environment of RFC 2976=20 > prevented users from encountering the kinds of problems that INFO-=20 > package is attempting to prevent. I can see that such text might be=20 > usefully added here, if we can find a way to say it that doesn't leave=20 > the average reader even more confused. > > -- > Dean > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Wed Sep 23 06:23:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A812D3A6881 for ; Wed, 23 Sep 2009 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKMT7rF2-7iZ for ; Wed, 23 Sep 2009 06:23:15 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id D68CE3A67B3 for ; Wed, 23 Sep 2009 06:23:14 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n8NDODei025863; Wed, 23 Sep 2009 15:24:13 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n8NDOCUg023036; Wed, 23 Sep 2009 15:24:12 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.159]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Wed, 23 Sep 2009 15:24:11 +0200 From: "Elwell, John" To: Francois Audet , Shida Schubert Date: Wed, 23 Sep 2009 15:23:56 +0200 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoxzpJ3WJP2FLpZQzKpW4UdSLDk8QAaloZgAoXTAbA= Message-ID: <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , "sipcore@ietf.org" , Hadriel Kaplan , Dean Willis , "Elwell, John" , Drage , Keith Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:23:16 -0000 If we want to find specific things like freephone numbers, I think they do = need to be explicitly marked, perhaps along the lines that Shida has sugges= ted. - Example 1: Call from A to B, which is forwarded to freephone number C, wh= ich resolves to D, which resolves to contact E. - Example 2: Call from A to freephone number B, which resolves to C, which = is then forwarded to D, which resolves to contact E. These two examples illustrate that the freephone URI cannot be found at any= fixed place in the sequence, so explicit marking would seem to be necessar= y. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 10 September 2009 18:06 > To: Shida Schubert > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean=20 > Willis; Elwell, John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > Ok, thanks. >=20 > Let's wait for more input on this before we go for another rev of the > draft.=20 >=20 > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > > Sent: Wednesday, September 09, 2009 21:24 > > To: Audet, Francois (SC100:3055) > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; Hadriel=20 > > Kaplan; Dean Willis; Elwell, John; Keith Drage > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >=20 > >=20 > > I think the following could work for Freephone(toll-free),=20 > > AFAIK all is needed for freephone was the mp tag and some=20 > > guidance on where to look for a toll-free. > >=20 > > I believe that solving the problem of toll-free is really=20 > > determining the current target of the request, which I=20 > > believe is what mp is trying to address. Generally if the=20 > > incoming request is delivered via toll-free, then an entry=20 > > before the last mp(mapped-to) is likely to be a toll-free=20 > > number (mapped-from). > >=20 > > Although, without globally deterministic way to mark the=20 > > toll-free, it's hard for it to work across countries as=20 > > different countries have different toll-free prefixes. > > (Here in Japan, it's 0120-xxx and not 1-800). > >=20 > > We could though, possibly define a service URN or some tags=20 > > for typical services that are out there and tag HI-entry=20 > > representing such service with service URN that we define. > >=20 > > History-Info: =20 > > < > > sip:DirectoryAssistance > > @example.com>;index=3D1;service=3Durn:service:directory-assistance > > History-Info: ;index=3D1.1;mp=3D= 1 > > History-Info: ;index=3D1.1.1;rc=3D1 > > History-Info: ;index=3D1.1.2;rc=3D2 > >=20 > > Regards > > Shida > >=20 > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > >=20 > > > I guess the summary is that we are kind of stalled on some of the=20 > > > issues, in particular the aor tag issue. It seems that a=20 > > significant=20 > > > fraction of people do not believe that an AOR is deterministic=20 > > > construct that is worthy of being tagged as such. > > > > > > In my background (which is an Enterprise software/telephony=20 > > > background), "users" have accounts. An AOR is the series of=20 > > addresses=20 > > > corresponding to these accounts, along with any aliases=20 > > (such as phone=20 > > > numbers expressed in SIP/TEL format). To me, AORs are not=20 > > this fluffy=20 > > > concept that others on the list have made it up to be. > > > > > > But in any case, I don't think we'll be able to reach a=20 > > concensus on=20 > > > it. > > > > > > I believe that we need to step back and find a different=20 > > way to skin=20 > > > this cat. > > > > > > Going back to the requirements of WHAT we are really trying=20 > > to solve=20 > > > at the > > > UAS: > > > > > > 1) Tagging the last address (including parameters) that=20 > was used in > > > a Request-URI before being replaced by the Contact. > > > i.e., the target-uri problem > > > 1a) It has been argued that sometimes with the=20 > > target-uri problem > > > you may actually be looking for the first address (and > > > parameters) > > > as opposed to the last one. > > > > > > 2) Tagging addresses that represents a DIFFERENT=20 > user/resource, as a > > > result of re-targeting. > > > i.e., the re-targeting problem (voicemail, IVR, etc.) > > > > > > We could potentially solve those two by having tags for=20 > > "mapped" and=20 > > > "contacts", and use a pointer to the index of what it is=20 > > mapped from=20 > > > (I guess we could do forward pointing instead of backward=20 > pointing,=20 > > > but then forking would be more cumbersome). > > > > > > Having the tag pointing to the index would remove ambiguity=20 > > if entries=20 > > > are removed by a proxy, etc. > > > > > > So, if I take a specific example of a call to bob being=20 > > redirected to=20 > > > carol, the HI would look like > > > this: > > > > > > History-Info: ;index=3D1; > > > History-Info: ;\ > > > index=3D1.1;rc=3D1 > > > History-Info: ;index=3D2;mp=3D1 > > > History-Info: ;index=3D2.1;rc=3D2 > > > > > > For problem 1 (target-uri), the UAS would look at the last rc tag=20 > > > which is it's registered contact, and see what it points=20 > to (i.e.,=20 > > > index 2). > > > Index 2 is therefore > > > the last target-uri. > > > > > > For problem 2 (redirection), the UAS looks for the last=20 > mp tag (it=20 > > > points to index 1). > > > Index 1 (bob) is therefore the "redirecting" number.=20 > Alternatively,=20 > > > the UAS may look for the FIRST retargeting (many voicemail=20 > > work with=20 > > > the first one). > > > > > > Anyways, this is just brainstorming (and it notably doesn't=20 > > solve - I=20 > > > think - the Freephone/1-800 number problem). > > > > > > Ideas? > > > > > > > > >> -----Original Message----- > > >> From: Adam Roach [mailto:adam@nostrum.com] > > >> Sent: Tuesday, September 08, 2009 15:46 > > >> To: sipcore@ietf.org > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith=20 > Drage; Jon=20 > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox;=20 > Dean Willis > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > >> > > >> Just a quick reminder that we discussed this vigorously in=20 > > Stockholm=20 > > >> without reaching any conclusion. To help spur things=20 > > along, here's a=20 > > >> summary of the arguments made during that discussion: > > >> > > >> > > >> http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > > >> 201:%20AOR%20tag > > >> > > >> Please resume discussion on the list, and see if we can=20 > reach any=20 > > >> sort of rough agreement. > > >> > > >> /a > > >> > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dean.willis@softarmor.com Wed Sep 23 06:39:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E368828C11E for ; Wed, 23 Sep 2009 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHMAXQaaorDd for ; Wed, 23 Sep 2009 06:39:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2BB0B28C101 for ; Wed, 23 Sep 2009 06:39:26 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8NDeMmt014678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Sep 2009 08:40:26 -0500 Message-Id: <223C0060-1FFC-40FD-BEDC-4920578AA1D9@softarmor.com> From: Dean Willis To: Eric Burger In-Reply-To: <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Sep 2009 08:40:16 -0500 References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Linyi TIAN Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:39:27 -0000 On Sep 23, 2009, at 5:27 AM, Eric Burger wrote: > Now I think I understand. Do we agree the request is to make it > very, very, very clear that new usages of INFO outside the INFO > Framework is not only a bad idea but will not be tolerated? If so, > I think we can figure out some wording for that. That, and WHY this is so, and also describing how the "legacy" usages contact has to be deduced from the content-type and local configuration data in more detail. -- Dean From AVSHALOM@il.ibm.com Wed Sep 23 06:49:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0245228C105; Wed, 23 Sep 2009 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[AWL=-1.604, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzQXJKt3MTQm; Wed, 23 Sep 2009 06:49:22 -0700 (PDT) Received: from mtagate6.de.ibm.com (mtagate6.de.ibm.com [195.212.17.166]) by core3.amsl.com (Postfix) with ESMTP id 66BCA3A659A; Wed, 23 Sep 2009 06:49:22 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8NDoR1S006083; Wed, 23 Sep 2009 13:50:27 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8NDoRuL2777126; Wed, 23 Sep 2009 15:50:27 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8NDoQHO028892; Wed, 23 Sep 2009 15:50:27 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8NDoQts028887; Wed, 23 Sep 2009 15:50:26 +0200 In-Reply-To: <572B7D13-422D-412E-8D9C-A07693B629E3@ericsson.com> References: <572B7D13-422D-412E-8D9C-A07693B629E3@ericsson.com> To: Christian Vogt MIME-Version: 1.0 X-KeepSent: E508A652:BC131017-C225763A:0049DFD5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Wed, 23 Sep 2009 16:50:25 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 23/09/2009 16:50:26, Serialize complete at 23/09/2009 16:50:26 Content-Type: multipart/alternative; boundary="=_alternative 004B8AB0C225763A_=" Cc: "RjS@nostrum.com" , "vs2140@cs.columbia.edu" , "aoki@aol.net" , "hgs+ecrit@cs.columbia.edu" , Gen-ART Mailing List , "sipcore@ietf.org" , "Sriram.Parameswar@microsoft.com" Subject: Re: [sipcore] [Gen-art] Gen-ART review of draft-ietf-sipcore-presence-scaling-requirements-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:49:24 -0000 This is a multipart message in MIME format. --=_alternative 004B8AB0C225763A_= Content-Type: text/plain; charset="US-ASCII" Thanks for your review. Comments inline. --Avshalom gen-art-bounces@ietf.org wrote on 23/09/2009 12:01:32 AM: > From: > > Christian Vogt > > To: > > Gen-ART Mailing List , "sipcore@ietf.org" > > Cc: > > "RjS@nostrum.com" , "vs2140@cs.columbia.edu" > , Avshalom Houri/Haifa/IBM@IBMIL, > "aoki@aol.net" , "hgs+ecrit@cs.columbia.edu" +ecrit@cs.columbia.edu>, "Sriram.Parameswar@microsoft.com" > > > Date: > > 23/09/2009 12:02 AM > > Subject: > > [Gen-art] Gen-ART review of draft-ietf-sipcore-presence-scaling- > requirements-02 > > Sent by: > > gen-art-bounces@ietf.org > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > > Document..........: draft-ietf-sipcore-presence-scaling-requirements-02 > Reviewer..........: Christian Vogt > Review date.......: September 22, 2009 > IESG Telechat date: September 24, 2009 > > > Summary: This draft is basically ready for publication, but has nits > that should be fixed before publication. > > > This document describes requirements for SIP/SIMPLE optimizations, > primarily to address scalability issues that have been observed for > SIP/SIMPLE deployments. > > The document is well-written and concise, and it is basically ready for > publication. Two comments, though, which the authors may want to > consider: > > - It would be worth mentioning in the introduction of the document what > the expected result of this document should be. Obviously, we are > expecting (or hoping for) an improvement in the scalability of > SIP/SIMPLE, but this should be made explicit. Also, do we have > estimates of how much SIP/SIMPLE will improve? These are defined by the requirements themselves specifically in 3.3. It is not possible to know how much the protocol will improve until we will have actual requirements that we will be able to analyze. > > - The document only talks about "optimizations" to which the defined > requirement should apply. How about other types of protocol > enhancements, such as functional extensions? Wouldn't the defined > requirements apply to those just as well? No. Functional requirements are not in the scope of this document. > > Good luck with the publication! > > - Christian > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --=_alternative 004B8AB0C225763A_= Content-Type: text/html; charset="US-ASCII" Thanks for your review. Comments inline.

--Avshalom

gen-art-bounces@ietf.org wrote on 23/09/2009 12:01:32 AM:

> From:
>
> Christian Vogt <christian.vogt@ericsson.com>
>
> To:
>
> Gen-ART Mailing List <gen-art@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>
>
> Cc:
>
> "RjS@nostrum.com" <RjS@nostrum.com>, "vs2140@cs.columbia.edu"
> <vs2140@cs.columbia.edu>, Avshalom Houri/Haifa/IBM@IBMIL,
> "aoki@aol.net" <aoki@aol.net>, "hgs+ecrit@cs.columbia.edu" <hgs
> +ecrit@cs.columbia.edu>, "Sriram.Parameswar@microsoft.com"
> <Sriram.Parameswar@microsoft.com>
>
> Date:
>
> 23/09/2009 12:02 AM
>
> Subject:
>
> [Gen-art] Gen-ART review of draft-ietf-sipcore-presence-scaling-
> requirements-02
>
> Sent by:
>
> gen-art-bounces@ietf.org
>
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
>
> Document..........:  draft-ietf-sipcore-presence-scaling-requirements-02
> Reviewer..........:  Christian Vogt
> Review date.......:  September 22, 2009
> IESG Telechat date:  September 24, 2009
>
>
> Summary:  This draft is basically ready for publication, but has nits
>            that should be fixed before publication.
>
>
> This document describes requirements for SIP/SIMPLE optimizations,
> primarily to address scalability issues that have been observed for
> SIP/SIMPLE deployments.
>
> The document is well-written and concise, and it is basically ready for
> publication.  Two comments, though, which the authors may want to
> consider:
>
> - It would be worth mentioning in the introduction of the document what
>    the expected result of this document should be.  Obviously, we are
>    expecting (or hoping for) an improvement in the scalability of
>    SIP/SIMPLE, but this should be made explicit.  Also, do we have
>    estimates of how much SIP/SIMPLE will improve?

These are defined by the requirements themselves specifically in 3.3.
It is not possible to know how much the protocol will improve until we
will have actual requirements that we will be able to analyze.

>
> - The document only talks about "optimizations" to which the defined
>    requirement should apply.  How about other types of protocol
>    enhancements, such as functional extensions?  Wouldn't the defined
>    requirements apply to those just as well?

No. Functional requirements are not in the scope of this document.
>
> Good luck with the publication!
>
> - Christian
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
 --=_alternative 004B8AB0C225763A_=-- From tianlinyi@huawei.com Wed Sep 23 07:05:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C964D3A68A0 for ; Wed, 23 Sep 2009 07:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj21WebusfMu for ; Wed, 23 Sep 2009 07:05:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 14F553A659A for ; Wed, 23 Sep 2009 07:05:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00JS7GJCG7@szxga03-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 22:06:48 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00IFAGJCC1@szxga03-in.huawei.com> for sipcore@ietf.org; Wed, 23 Sep 2009 22:06:48 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [119.136.82.65]) by szxmc04-in.huawei.com (mshttpd); Wed, 23 Sep 2009 22:06:48 +0800 Date: Wed, 23 Sep 2009 22:06:48 +0800 From: tianlinyi 34932 In-reply-to: To: George Foti Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_jRFZDWz35CkcI/jcX5NlQA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:05:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jRFZDWz35CkcI/jcX5NlQA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C George I don=27t believe this could be mandated in this I-D=2E If there is no IO= P issue for old INFO or potential INFO with clear specification it is fre= e for them to use=2E Guidance will be enough=2E = Cheers=2C Linyi *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A George Foti =3Cgeorge=2Efoti=40ericsson=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =BE=C5=D4=C2 23=C8=D5=2C 2009 =CF=C2= =CE=E78=3A59 =D6=F7=CC=E2=3A Re=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-Pac= kage =CA=D5=BC=FE=C8=CB=3A Christer Holmberg =3Cchrister=2Eholmberg=40ericsson= =2Ecom=3E=2C Eric Burger =3Ceburger=40standardstrack=2Ecom=3E=2C Linyi TI= AN =3Ctianlinyi=40huawei=2Ecom=3E =B3=AD=CB=CD=3A SIPCORE =3Csipcore=40ietf=2Eorg=3E =3E Hi Christer=2C =3E = =3E Yes=2C I am referring to including an explicit statement disallowing = =3E any NEW info usage outside the Info event framework=2E =3E Thanks =3E = =3E George =3E = =3E = =3E -----Original Message----- =3E From=3A Christer Holmberg = =3E Sent=3A Wednesday=2C September 23=2C 2009 8=3A50 AM =3E To=3A George Foti=3B Eric Burger=3B Linyi TIAN =3E Cc=3A SIPCORE =3E Subject=3A RE=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-Pack= age =3E = =3E = =3E Hi=2C =3E = =3E Just to clarify that you are allowed to use existing legacy INFO = =3E usages=2C if such have already been specified=2E =3E = =3E For example=2C if you want to support ISUP tunnelling it is = =3E perfectly ok to use the current mechanisms=2E You are not required = =3E to define an Info Package for that=2E =3E = =3E BUT=2C if you are specifying a *NEW* INFO usage=2C then you MUST use = =3E the Info Package framework=2E =3E = =3E Regards=2C =3E = =3E Christer =3E = =3E = =3E -----Original Message----- =3E From=3A George Foti =3E Sent=3A Wed 9/23/2009 1=3A43 PM =3E To=3A Christer Holmberg=3B Eric Burger=3B Linyi TIAN =3E Cc=3A SIPCORE =3E Subject=3A RE=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-Pack= age =3E = =3E Yes=2C I would like a statement that explicitly disallows any usage = =3E of INFO outside the framework=2E =3E Than we don=27t have to rehash this discussion once more=2E =3E = =3E = =3E Rgds=2E =3E = =3E George Foti =3E Ericsson Canada =3E = =3E = =3E -----Original Message----- =3E From=3A sipcore-bounces=40ietf=2Eorg =5Bmailto=3Asipcore-bounces=40ie= tf=2Eorg=5D = =3E On Behalf Of Christer Holmberg =3E Sent=3A Wednesday=2C September 23=2C 2009 7=3A13 AM =3E To=3A Eric Burger=3B Linyi TIAN =3E Cc=3A SIPCORE =3E Subject=3A Re=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-Pack= age =3E = =3E There is text in the draft which says that=2C for backward = =3E compability purpose=2C legacy usage of INFO is allowed=2E If needed=2C= = =3E we can simply add a statement saying=3A =22Any new usage of INFO MUST= = =3E use the Info Package mechanism=22=2E =3E = =3E Regards=2C =3E = =3E Christer =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E = =3E From=3A sipcore-bounces=40ietf=2Eorg on behalf of Eric Burger =3E Sent=3A Wed 9/23/2009 12=3A27 PM =3E To=3A Linyi TIAN =3E Cc=3A SIPCORE =3E Subject=3A Re=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-Pack= age =3E = =3E = =3E = =3E Now I think I understand=2E Do we agree the request is to make it = =3E very=2C very=2C very clear that new usages of INFO outside the INFO = =3E Framework is not only a bad idea but will not be tolerated=3F If = =3E so=2C I think we can figure out some wording for that=2E =3E = =3E On Sep 23=2C 2009=2C at 12=3A56 AM=2C Linyi TIAN wrote=3A =3E = =3E =3E You misunderstood my intention=2E Please see my response to Dean = =3E about = =3E =3E adding some text to further explain the benefit for SIP INFO FW = =3E and = =3E =3E the issue for SIP INFO=2E =3E =3E =3E =3E Cheers=2C =3E =3E Linyi =3E = =3E On Sep 23=2C 2009=2C at 12=3A53 AM=2C Linyi TIAN wrote=3A =3E = =3E =3E Hi=2C Dean =3E =3E =3E =3E If you read the following text in introduction section=2C it may = =3E be = =3E =3E understood as when the Content-Type indicates one contextual = =3E usage = =3E =3E then SIP INFO Package is not needed=2E That is what we are = =3E debating in = =3E =3E other SDOs=2E =3E =3E While it may sometimes be clear what the content is based on the = =3E =3E Content-Type=2C this is only true where there is only one = =3E contextual = =3E =3E usage of the content-type=2E =3E =3E =3E =3E This is why I ask questions here and want the author to clarify = =3E it in = =3E =3E the I-D=2E I hope our concerns can be take into account in next = =3E =3E revision=2C e=2Eg=2E =3E =3E update the introduction and section 6=2E =3E =3E =3E =3E Cheers=2C =3E =3E Linyi =3E =3E =3E =3E -----Original Message----- =3E =3E From=3A Dean Willis =5Bmailto=3Adean=2Ewillis=40softarmor=2Ecom=5D= =3E =3E Sent=3A Wednesday=2C September 23=2C 2009 11=3A53 AM =3E =3E To=3A Linyi TIAN =3E =3E Cc=3A SIPCORE =3E =3E Subject=3A Re=3A =5Bsipcore=5D When to use SIP INFO and SIP INFO-= Package =3E =3E =3E =3E =3E =3E On Sep 22=2C 2009=2C at 7=3A54 PM=2C Linyi TIAN wrote=3A =3E =3E =3E =3E=3E Hi=2C Dean Willis=2C et al=2E =3E =3E=3E =3E =3E=3E I have to say I like your answers which clarify my doubts=2E M= ay = =3E I = =3E =3E=3E suggest adding some words in =22 6=2E Legacy Uses of INFO=22 = to = =3E clarify = =3E =3E=3E the new SIP INFO Package approach and Content Type Approach=3F= = =3E Maybe in = =3E =3E=3E the introduction section we can add more information about the= = =3E =3E=3E Content Type approach=2E =3E =3E=3E I mean =3E =3E=3E not only talking about the JPEG example=2E Even in controlled = =3E Content- = =3E =3E=3E Type there maybe issues too as Dean said=2E =3E =3E =3E =3E =3E =3E =3E =3E We=27ve tried to do this in the Introduction to draft-itf-sipcore= - =3E info- = =3E =3E events-00=2E The text currently says=3A =3E =3E =3E =3E=3E While INFO has been widely adopted for specific application us= e = =3E =3E=3E cases=2C such as ISUP and DTMF exchange=2C RFC 2976 =5BRFC2976= =5D = =3E neither = =3E =3E=3E defined a negotiation mechanism nor a means by which to = =3E explicitly = =3E =3E=3E indicate the type of application information contained in the = =3E INFO = =3E =3E=3E message=2E This led to problems associated with static = =3E configuration=2E=3E=3E In addition=2C the industry realized there was= a = =3E potential for = =3E =3E=3E interoperability problems due to undefined content syntax and = =3E =3E=3E semantics=2E This draft addresses these deficiencies and = =3E provides a = =3E =3E=3E framework for explicit negotiation of capabilities and content= = =3E =3E=3E context using =22Info Packages=22=2E =3E =3E =3E =3E =3E =3E=3E The INFO method as defined by RFC 2976 did not provide any = =3E context = =3E =3E=3E for the information the request carried=2E While it may = =3E sometimes be = =3E =3E=3E clear what the content is based on the Content-Type=2C this is= = =3E only = =3E =3E=3E true where there is only one contextual usage of the content-t= ype=2E =3E =3E=3E For example=2C if the Content-Type is =22image/jpeg=22=2C the = MIME- =3E attached = =3E =3E=3E content is a JPEG image=2E However=2C there are many useful w= ays a = =3E UAS = =3E =3E=3E can render an image=2E Said differently=2C there are differen= t = =3E contexts = =3E =3E=3E for an image in SIP=2E The image could be a caller-id picture= =2C a = =3E =3E=3E contact icon=2C a photo for sharing=2C and so on=2E The sende= r does = =3E not = =3E =3E=3E know which image to send to the receiver if the receiver = =3E supports an = =3E =3E=3E image content type=2E Likewise=2C the receiver does not know = the = =3E context = =3E =3E=3E of an image the client is sending if the receiver supports = =3E receiving = =3E =3E=3E more than one image content type=2E Thus=2C we need a well de= fined = =3E and = =3E =3E=3E documented statement of what the information sent is for=2E T= his = =3E =3E=3E situation is identical to the context issue in Internet Mail = =3E =3E=3E =5BRFC3458=5D=2E RFC 3458 goes into this and other issues in = detail=2E =3E =3E =3E =3E =3E =3E I would not object to adding material here to further illustrate = =3E why = =3E =3E Content-Type alone is insufficient=2C assuming we can find a way = =3E to say = =3E =3E it that doesn=27t further confuse the reader=2E Of course=2C I=27= m not = =3E the = =3E =3E editor of the document=2C so I can only suggest this as a = =3E contributor to = =3E =3E the working group=2E =3E =3E =3E =3E Likewise=2C you suggested modifying Section 6=2C Legacy Uses of = =3E Info=2E This = =3E =3E section starts with=3A =3E =3E =3E =3E Several RFC-defined and other standards-defined uses of RFC = =3E 2976 = =3E =3E INFO =3E =3E =5BRFC2976=5D exist and are in use=2C as well as numerous = =3E proprietary = =3E =3E uses=2E =3E =3E Appendix B describes some of these usages=2E By definition=2C= =3E =3E identifying such uses has relied on either static local = =3E =3E configuration =3E =3E or implicit context determination based on the body Content- =3E Type or =3E =3E Content-Disposition value or some proprietary mechanism=2E = =3E This = =3E =3E draft =3E =3E cannot forbid nor avoid such uses=2C since local configuration= can =3E =3E always override standardized mechanisms=2E =3E =3E =3E =3E From what I understand=2C you are proposing to add some text here= = =3E that = =3E =3E essentially explains how Content-Type combined with local = =3E =3E configuration provided adequate context for the legacy usages of = =3E INFO=2E=3E In other words=2C describing how the constrained environme= nt = =3E of RFC 2976 = =3E =3E prevented users from encountering the kinds of problems that = =3E INFO- = =3E =3E package is attempting to prevent=2E I can see that such text migh= t = =3E be = =3E =3E usefully added here=2C if we can find a way to say it that doesn=27= t = =3E leave = =3E =3E the average reader even more confused=2E =3E =3E =3E =3E -- =3E =3E Dean =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E sipcore mailing list =3E =3E sipcore=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/sipcore =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E sipcore mailing list =3E sipcore=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/sipcore =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E sipcore mailing list =3E sipcore=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/sipcore =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E sipcore mailing list =3E sipcore=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/sipcore =3E --Boundary_(ID_jRFZDWz35CkcI/jcX5NlQA) Content-type: text/x-vcard; name=t34932.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=t34932.vcf Content-description: Card for tianlinyi 34932 begin:vcard n:34932;tianlinyi fn:tianlinyi 34932 version:2.1 email;internet:tianlinyi@huawei.com end:vcard --Boundary_(ID_jRFZDWz35CkcI/jcX5NlQA)-- From christer.holmberg@ericsson.com Wed Sep 23 07:09:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07BD3A6835 for ; Wed, 23 Sep 2009 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScXucFZzgike for ; Wed, 23 Sep 2009 07:09:05 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D40463A692C for ; Wed, 23 Sep 2009 07:09:04 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-95-4aba298a3ff8 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 09.D8.22406.A892ABA4; Wed, 23 Sep 2009 15:58:34 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 14:53:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Sep 2009 14:50:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco8OIfhRY4kjKHHRuWTiSrHc0PZKQABkNFjAAEFGcAAAmH7SQ== References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com><02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> From: "Christer Holmberg" To: "George Foti" , "Eric Burger" , "Linyi TIAN" X-OriginalArrivalTime: 23 Sep 2009 12:53:13.0818 (UTC) FILETIME=[CFFDD3A0:01CA3C4C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:09:06 -0000 Hi, Just to clarify that you are allowed to use existing legacy INFO usages, = if such have already been specified. For example, if you want to support ISUP tunnelling it is perfectly ok = to use the current mechanisms. You are not required to define an Info = Package for that. BUT, if you are specifying a *NEW* INFO usage, then you MUST use the = Info Package framework. Regards, Christer -----Original Message----- From: George Foti Sent: Wed 9/23/2009 1:43 PM To: Christer Holmberg; Eric Burger; Linyi TIAN Cc: SIPCORE Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package =20 Yes, I would like a statement that explicitly disallows any usage of = INFO outside the framework. Than we don't have to rehash this discussion once more. Rgds. George Foti Ericsson Canada =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Christer Holmberg Sent: Wednesday, September 23, 2009 7:13 AM To: Eric Burger; Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package There is text in the draft which says that, for backward compability = purpose, legacy usage of INFO is allowed. If needed, we can simply add a = statement saying: "Any new usage of INFO MUST use the Info Package = mechanism". =20 Regards, =20 Christer ________________________________ From: sipcore-bounces@ietf.org on behalf of Eric Burger Sent: Wed 9/23/2009 12:27 PM To: Linyi TIAN Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Now I think I understand. Do we agree the request is to make it very, = very, very clear that new usages of INFO outside the INFO Framework is = not only a bad idea but will not be tolerated? If so, I think we can = figure out some wording for that. On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > You misunderstood my intention. Please see my response to Dean about=20 > adding some text to further explain the benefit for SIP INFO FW and=20 > the issue for SIP INFO. > > Cheers, > Linyi On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > Hi, Dean > > If you read the following text in introduction section, it may be=20 > understood as when the Content-Type indicates one contextual usage=20 > then SIP INFO Package is not needed. That is what we are debating in=20 > other SDOs. > While it may sometimes be clear what the content is based on the=20 > Content-Type, this is only true where there is only one contextual=20 > usage of the content-type. > > This is why I ask questions here and want the author to clarify it in=20 > the I-D. I hope our concerns can be take into account in next=20 > revision, e.g. > update the introduction and section 6. > > Cheers, > Linyi > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >> Hi, Dean Willis, et al. >> >> I have to say I like your answers which clarify my doubts. May I=20 >> suggest adding some words in " 6. Legacy Uses of INFO" to clarify=20 >> the new SIP INFO Package approach and Content Type Approach? Maybe in = >> the introduction section we can add more information about the=20 >> Content Type approach. >> I mean >> not only talking about the JPEG example. Even in controlled Content-=20 >> Type there maybe issues too as Dean said. > > > > We've tried to do this in the Introduction to draft-itf-sipcore-info-=20 > events-00. The text currently says: > >> While INFO has been widely adopted for specific application use=20 >> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither=20 >> defined a negotiation mechanism nor a means by which to explicitly=20 >> indicate the type of application information contained in the INFO=20 >> message. This led to problems associated with static configuration. >> In addition, the industry realized there was a potential for=20 >> interoperability problems due to undefined content syntax and=20 >> semantics. This draft addresses these deficiencies and provides a=20 >> framework for explicit negotiation of capabilities and content=20 >> context using "Info Packages". > > >> The INFO method as defined by RFC 2976 did not provide any context=20 >> for the information the request carried. While it may sometimes be=20 >> clear what the content is based on the Content-Type, this is only=20 >> true where there is only one contextual usage of the content-type. >> For example, if the Content-Type is "image/jpeg", the MIME-attached=20 >> content is a JPEG image. However, there are many useful ways a UAS=20 >> can render an image. Said differently, there are different contexts=20 >> for an image in SIP. The image could be a caller-id picture, a=20 >> contact icon, a photo for sharing, and so on. The sender does not=20 >> know which image to send to the receiver if the receiver supports an=20 >> image content type. Likewise, the receiver does not know the context = >> of an image the client is sending if the receiver supports receiving=20 >> more than one image content type. Thus, we need a well defined and=20 >> documented statement of what the information sent is for. This=20 >> situation is identical to the context issue in Internet Mail=20 >> [RFC3458]. RFC 3458 goes into this and other issues in detail. > > > I would not object to adding material here to further illustrate why=20 > Content-Type alone is insufficient, assuming we can find a way to say=20 > it that doesn't further confuse the reader. Of course, I'm not the=20 > editor of the document, so I can only suggest this as a contributor to = > the working group. > > Likewise, you suggested modifying Section 6, Legacy Uses of Info. This = > section starts with: > > Several RFC-defined and other standards-defined uses of RFC 2976=20 > INFO > [RFC2976] exist and are in use, as well as numerous proprietary=20 > uses. > Appendix B describes some of these usages. By definition, > identifying such uses has relied on either static local=20 > configuration > or implicit context determination based on the body Content-Type or > Content-Disposition value or some proprietary mechanism. This=20 > draft > cannot forbid nor avoid such uses, since local configuration can > always override standardized mechanisms. > > From what I understand, you are proposing to add some text here that=20 > essentially explains how Content-Type combined with local=20 > configuration provided adequate context for the legacy usages of INFO. > In other words, describing how the constrained environment of RFC 2976 = > prevented users from encountering the kinds of problems that INFO-=20 > package is attempting to prevent. I can see that such text might be=20 > usefully added here, if we can find a way to say it that doesn't leave = > the average reader even more confused. > > -- > Dean > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Sep 23 10:40:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C3C3A6891 for ; Wed, 23 Sep 2009 10:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC0FAMvEPlxR for ; Wed, 23 Sep 2009 10:40:55 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 59E9D3A6814 for ; Wed, 23 Sep 2009 10:40:54 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-3a-4aba5de77e29 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B7.52.15624.7ED5ABA4; Wed, 23 Sep 2009 19:41:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 19:40:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Sep 2009 19:40:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco8V05D53V71cPRSVKcojd8n8/BiwAHHZ4i References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> From: "Christer Holmberg" To: "tianlinyi 34932" , "George Foti" X-OriginalArrivalTime: 23 Sep 2009 17:40:50.0289 (UTC) FILETIME=[FDA65610:01CA3C74] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:40:58 -0000 Hi, =20 The idea is that the I-P draft replaces the existing RFC. For backward = compability it allows existing RFC based solutions, but the idea is that = any new usage DOES use the I-P mechanism. =20 Since you will have to describe the semantics etc of the new usage = anyway, I really don't see the problem is in doing it in the form of an = I-P. Just because, for a specific use-case, you may not need all = "features" of the I-P mechanism, I think it is much better to use a = single mechanism. =20 Just for my interest: is there some specific new usage you have in mind, = where you would like to use legacy INFO? =20 Regards, =20 Christer ________________________________ From: tianlinyi 34932 [mailto:tianlinyi@huawei.com] Sent: Wed 23/09/2009 16:06 To: George Foti Cc: Christer Holmberg; Eric Burger; SIPCORE Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, George I don't believe this could be mandated in this I-D. If there is no IOP = issue for old INFO or potential INFO with clear specification it is free = for them to use. Guidance will be enough. Cheers, Linyi *************************************************************************= ***************** This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained here in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient(s) is prohibited. If you receive this email in error, please = notify the sender by phone or email immediately and delete it! = *************************************************************************= **************** ----- ??? ----- ???: George Foti ??: ???, ?? 23?, 2009 ??8:59 ??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package ???: Christer Holmberg , Eric Burger = , Linyi TIAN ??: SIPCORE > Hi Christer, > > Yes, I am referring to including an explicit statement disallowing > any NEW info usage outside the Info event framework. > Thanks > > George > > > -----Original Message----- > From: Christer Holmberg > Sent: Wednesday, September 23, 2009 8:50 AM > To: George Foti; Eric Burger; Linyi TIAN > Cc: SIPCORE > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > > Hi, > > Just to clarify that you are allowed to use existing legacy INFO > usages, if such have already been specified. > > For example, if you want to support ISUP tunnelling it is > perfectly ok to use the current mechanisms. You are not required > to define an Info Package for that. > > BUT, if you are specifying a *NEW* INFO usage, then you MUST use > the Info Package framework. > > Regards, > > Christer > > > -----Original Message----- > From: George Foti > Sent: Wed 9/23/2009 1:43 PM > To: Christer Holmberg; Eric Burger; Linyi TIAN > Cc: SIPCORE > Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > > Yes, I would like a statement that explicitly disallows any usage > of INFO outside the framework. > Than we don't have to rehash this discussion once more. > > > Rgds. > > George Foti > Ericsson Canada > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > On Behalf Of Christer Holmberg > Sent: Wednesday, September 23, 2009 7:13 AM > To: Eric Burger; Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > There is text in the draft which says that, for backward > compability purpose, legacy usage of INFO is allowed. If needed, > we can simply add a statement saying: "Any new usage of INFO MUST > use the Info Package mechanism". > > Regards, > > Christer > > ________________________________ > > From: sipcore-bounces@ietf.org on behalf of Eric Burger > Sent: Wed 9/23/2009 12:27 PM > To: Linyi TIAN > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > Now I think I understand. Do we agree the request is to make it > very, very, very clear that new usages of INFO outside the INFO > Framework is not only a bad idea but will not be tolerated? If > so, I think we can figure out some wording for that. > > On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > > > You misunderstood my intention. Please see my response to Dean > about > > adding some text to further explain the benefit for SIP INFO FW > and > > the issue for SIP INFO. > > > > Cheers, > > Linyi > > On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > > > Hi, Dean > > > > If you read the following text in introduction section, it may > be > > understood as when the Content-Type indicates one contextual > usage > > then SIP INFO Package is not needed. That is what we are > debating in > > other SDOs. > > While it may sometimes be clear what the content is based on the > > Content-Type, this is only true where there is only one > contextual > > usage of the content-type. > > > > This is why I ask questions here and want the author to clarify > it in > > the I-D. I hope our concerns can be take into account in next > > revision, e.g. > > update the introduction and section 6. > > > > Cheers, > > Linyi > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, September 23, 2009 11:53 AM > > To: Linyi TIAN > > Cc: SIPCORE > > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > > > On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > > > >> Hi, Dean Willis, et al. > >> > >> I have to say I like your answers which clarify my doubts. May > I > >> suggest adding some words in " 6. Legacy Uses of INFO" to > clarify > >> the new SIP INFO Package approach and Content Type Approach? > Maybe in > >> the introduction section we can add more information about the > >> Content Type approach. > >> I mean > >> not only talking about the JPEG example. Even in controlled > Content- > >> Type there maybe issues too as Dean said. > > > > > > > > We've tried to do this in the Introduction to draft-itf-sipcore- > info- > > events-00. The text currently says: > > > >> While INFO has been widely adopted for specific application use > >> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] > neither > >> defined a negotiation mechanism nor a means by which to > explicitly > >> indicate the type of application information contained in the > INFO > >> message. This led to problems associated with static > configuration.>> In addition, the industry realized there was a > potential for > >> interoperability problems due to undefined content syntax and > >> semantics. This draft addresses these deficiencies and > provides a > >> framework for explicit negotiation of capabilities and content > >> context using "Info Packages". > > > > > >> The INFO method as defined by RFC 2976 did not provide any > context > >> for the information the request carried. While it may > sometimes be > >> clear what the content is based on the Content-Type, this is > only > >> true where there is only one contextual usage of the content-type. > >> For example, if the Content-Type is "image/jpeg", the MIME- > attached > >> content is a JPEG image. However, there are many useful ways a > UAS > >> can render an image. Said differently, there are different > contexts > >> for an image in SIP. The image could be a caller-id picture, a > >> contact icon, a photo for sharing, and so on. The sender does > not > >> know which image to send to the receiver if the receiver > supports an > >> image content type. Likewise, the receiver does not know the > context > >> of an image the client is sending if the receiver supports > receiving > >> more than one image content type. Thus, we need a well defined > and > >> documented statement of what the information sent is for. This > >> situation is identical to the context issue in Internet Mail > >> [RFC3458]. RFC 3458 goes into this and other issues in detail. > > > > > > I would not object to adding material here to further illustrate > why > > Content-Type alone is insufficient, assuming we can find a way > to say > > it that doesn't further confuse the reader. Of course, I'm not > the > > editor of the document, so I can only suggest this as a > contributor to > > the working group. > > > > Likewise, you suggested modifying Section 6, Legacy Uses of > Info. This > > section starts with: > > > > Several RFC-defined and other standards-defined uses of RFC > 2976 > > INFO > > [RFC2976] exist and are in use, as well as numerous > proprietary > > uses. > > Appendix B describes some of these usages. By definition, > > identifying such uses has relied on either static local > > configuration > > or implicit context determination based on the body Content- > Type or > > Content-Disposition value or some proprietary mechanism.=20 > This > > draft > > cannot forbid nor avoid such uses, since local configuration can > > always override standardized mechanisms. > > > > From what I understand, you are proposing to add some text here > that > > essentially explains how Content-Type combined with local > > configuration provided adequate context for the legacy usages of > INFO.> In other words, describing how the constrained environment > of RFC 2976 > > prevented users from encountering the kinds of problems that > INFO- > > package is attempting to prevent. I can see that such text might > be > > usefully added here, if we can find a way to say it that doesn't > leave > > the average reader even more confused. > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From AUDET@nortel.com Wed Sep 23 14:07:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC1E3A67E2 for ; Wed, 23 Sep 2009 14:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPAo0qYr5zTk for ; Wed, 23 Sep 2009 14:07:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3C0FC3A6839 for ; Wed, 23 Sep 2009 14:07:32 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8NL8SS12843; Wed, 23 Sep 2009 21:08:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Sep 2009 16:08:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> In-Reply-To: <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoxzpJ3WJP2FLpZQzKpW4UdSLDk8QAaloZgAoXTAbAAEFUrEA== References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com><9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com><9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com><4AA6DEA7.7090403@nostrum.com><1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com><8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Shida Schubert" Cc: Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 21:07:33 -0000 Can you give me an example of how the tags would look like? Also, and you clarify what you mean by "forward" vs "resolve"? I am assuming you are using "forward" in the traditional "telephony" way, i.e., it is retargeted to another user, as opposed to "request forwarding" which what you used for "resolving". Is this correct? > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, September 23, 2009 06:24 > To: Audet, Francois (SC100:3055); Shida Schubert > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean=20 > Willis; Elwell, John; Keith Drage > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > If we want to find specific things like freephone numbers, I=20 > think they do need to be explicitly marked, perhaps along the=20 > lines that Shida has suggested. > - Example 1: Call from A to B, which is forwarded to=20 > freephone number C, which resolves to D, which resolves to contact E. > - Example 2: Call from A to freephone number B, which=20 > resolves to C, which is then forwarded to D, which resolves=20 > to contact E. >=20 > These two examples illustrate that the freephone URI cannot=20 > be found at any fixed place in the sequence, so explicit=20 > marking would seem to be necessary. >=20 > John >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > > Sent: 10 September 2009 18:06 > > To: Shida Schubert > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis;=20 > > Elwell, John; Keith Drage > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >=20 > > Ok, thanks. > >=20 > > Let's wait for more input on this before we go for another=20 > rev of the=20 > > draft. > >=20 > > > -----Original Message----- > > > From: Shida Schubert [mailto:shida@ntt-at.com] > > > Sent: Wednesday, September 09, 2009 21:24 > > > To: Audet, Francois (SC100:3055) > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox;=20 > Hadriel Kaplan;=20 > > > Dean Willis; Elwell, John; Keith Drage > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > >=20 > > > I think the following could work for=20 > Freephone(toll-free), AFAIK=20 > > > all is needed for freephone was the mp tag and some guidance on=20 > > > where to look for a toll-free. > > >=20 > > > I believe that solving the problem of toll-free is really=20 > > > determining the current target of the request, which I believe is=20 > > > what mp is trying to address. Generally if the incoming=20 > request is=20 > > > delivered via toll-free, then an entry before the last=20 > mp(mapped-to)=20 > > > is likely to be a toll-free number (mapped-from). > > >=20 > > > Although, without globally deterministic way to mark the=20 > toll-free,=20 > > > it's hard for it to work across countries as different countries=20 > > > have different toll-free prefixes. > > > (Here in Japan, it's 0120-xxx and not 1-800). > > >=20 > > > We could though, possibly define a service URN or some tags for=20 > > > typical services that are out there and tag HI-entry representing=20 > > > such service with service URN that we define. > > >=20 > > > History-Info: =20 > > > < > > > sip:DirectoryAssistance > > > @example.com>;index=3D1;service=3Durn:service:directory-assistance > > > History-Info:=20 > ;index=3D1.1;mp=3D1 > > > History-Info: ;index=3D1.1.1;rc=3D1 > > > History-Info: ;index=3D1.1.2;rc=3D2 > > >=20 > > > Regards > > > Shida > > >=20 > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > > >=20 > > > > I guess the summary is that we are kind of stalled on=20 > some of the=20 > > > > issues, in particular the aor tag issue. It seems that a > > > significant > > > > fraction of people do not believe that an AOR is deterministic=20 > > > > construct that is worthy of being tagged as such. > > > > > > > > In my background (which is an Enterprise software/telephony=20 > > > > background), "users" have accounts. An AOR is the series of > > > addresses > > > > corresponding to these accounts, along with any aliases > > > (such as phone > > > > numbers expressed in SIP/TEL format). To me, AORs are not > > > this fluffy > > > > concept that others on the list have made it up to be. > > > > > > > > But in any case, I don't think we'll be able to reach a > > > concensus on > > > > it. > > > > > > > > I believe that we need to step back and find a different > > > way to skin > > > > this cat. > > > > > > > > Going back to the requirements of WHAT we are really trying > > > to solve > > > > at the > > > > UAS: > > > > > > > > 1) Tagging the last address (including parameters) that > > was used in > > > > a Request-URI before being replaced by the Contact. > > > > i.e., the target-uri problem > > > > 1a) It has been argued that sometimes with the > > > target-uri problem > > > > you may actually be looking for the first=20 > address (and > > > > parameters) > > > > as opposed to the last one. > > > > > > > > 2) Tagging addresses that represents a DIFFERENT > > user/resource, as a > > > > result of re-targeting. > > > > i.e., the re-targeting problem (voicemail, IVR, etc.) > > > > > > > > We could potentially solve those two by having tags for > > > "mapped" and > > > > "contacts", and use a pointer to the index of what it is > > > mapped from > > > > (I guess we could do forward pointing instead of backward > > pointing, > > > > but then forking would be more cumbersome). > > > > > > > > Having the tag pointing to the index would remove ambiguity > > > if entries > > > > are removed by a proxy, etc. > > > > > > > > So, if I take a specific example of a call to bob being > > > redirected to > > > > carol, the HI would look like > > > > this: > > > > > > > > History-Info: ;index=3D1; > > > > History-Info: ;\ > > > > index=3D1.1;rc=3D1 > > > > History-Info: ;index=3D2;mp=3D1 > > > > History-Info: ;index=3D2.1;rc=3D2 > > > > > > > > For problem 1 (target-uri), the UAS would look at the=20 > last rc tag=20 > > > > which is it's registered contact, and see what it points > > to (i.e., > > > > index 2). > > > > Index 2 is therefore > > > > the last target-uri. > > > > > > > > For problem 2 (redirection), the UAS looks for the last > > mp tag (it > > > > points to index 1). > > > > Index 1 (bob) is therefore the "redirecting" number.=20 > > Alternatively, > > > > the UAS may look for the FIRST retargeting (many voicemail > > > work with > > > > the first one). > > > > > > > > Anyways, this is just brainstorming (and it notably doesn't > > > solve - I > > > > think - the Freephone/1-800 number problem). > > > > > > > > Ideas? > > > > > > > > > > > >> -----Original Message----- > > > >> From: Adam Roach [mailto:adam@nostrum.com] > > > >> Sent: Tuesday, September 08, 2009 15:46 > > > >> To: sipcore@ietf.org > > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith > > Drage; Jon > > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; > > Dean Willis > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > >> > > > >> Just a quick reminder that we discussed this vigorously in > > > Stockholm > > > >> without reaching any conclusion. To help spur things > > > along, here's a > > > >> summary of the arguments made during that discussion: > > > >> > > > >> > > > >> http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > > > >> 201:%20AOR%20tag > > > >> > > > >> Please resume discussion on the list, and see if we can > > reach any > > > >> sort of rough agreement. > > > >> > > > >> /a > > > >> > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From pkyzivat@cisco.com Wed Sep 23 15:14:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6161F3A6804 for ; Wed, 23 Sep 2009 15:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBPzkAixoGXZ for ; Wed, 23 Sep 2009 15:14:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D47153A6852 for ; Wed, 23 Sep 2009 15:14:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF06ukqrR7O6/2dsb2JhbAC+aYhPASsIj0oFgkAIgVM X-IronPort-AV: E=Sophos;i="4.44,440,1249257600"; d="scan'208";a="207641807" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2009 22:15:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8NMFIE8004255; Wed, 23 Sep 2009 15:15:18 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8NMF42m027601; Wed, 23 Sep 2009 22:15:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 18:15:17 -0400 Received: from [161.44.182.195] ([161.44.182.195]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 18:15:16 -0400 Message-ID: <4ABA9DF5.3040207@cisco.com> Date: Wed, 23 Sep 2009 18:15:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <014801ca3b38$51ab7940$f5026bc0$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2009 22:15:16.0931 (UTC) FILETIME=[54888130:01CA3C9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11087; t=1253744118; x=1254608118; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20When=20to=20use=20SIP=20INF O=20and=20SIP=20INFO-Package |Sender:=20; bh=QAiWRvLCUjwr6GZ+D/y4jsLnRCTO0am5eo1Ed62+TeI=; b=z0hQWkfXWRaL/364qaCyV8IbT4LTrbaBeCZ2cxbsnA8ZYpnKkivprCTbLc yN2xPtvVBlTOs/ClCwl2/N2c/1Huvy+OXQQ/TV1Vh2borUeoyXZX0yLqFN26 Jf6efEmFAE; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: George Foti , SIPCORE , tianlinyi 34932 Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 22:14:13 -0000 Christer Holmberg wrote: > Hi, > > The idea is that the I-P draft replaces the existing RFC. For backward compability it allows existing RFC based solutions, but the idea is that any new usage DOES use the I-P mechanism. > > Since you will have to describe the semantics etc of the new usage anyway, I really don't see the problem is in doing it in the form of an I-P. Just because, for a specific use-case, you may not need all "features" of the I-P mechanism, I think it is much better to use a single mechanism. > > Just for my interest: is there some specific new usage you have in mind, where you would like to use legacy INFO? And I saw mention that this was involved with another SDO. Can you say which one? Thanks, Paul > Regards, > > Christer > > ________________________________ > > From: tianlinyi 34932 [mailto:tianlinyi@huawei.com] > Sent: Wed 23/09/2009 16:06 > To: George Foti > Cc: Christer Holmberg; Eric Burger; SIPCORE > Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > Hi, George > > I don't believe this could be mandated in this I-D. If there is no IOP issue for old INFO or potential INFO with clear specification it is free for them to use. Guidance will be enough. > > Cheers, > Linyi > > ****************************************************************************************** > This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email > immediately and delete it! > ***************************************************************************************** > > ----- ??? ----- > ???: George Foti > ??: ???, ?? 23?, 2009 ??8:59 > ??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > ???: Christer Holmberg , Eric Burger , Linyi TIAN > ??: SIPCORE > >> Hi Christer, >> >> Yes, I am referring to including an explicit statement disallowing >> any NEW info usage outside the Info event framework. >> Thanks >> >> George >> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Wednesday, September 23, 2009 8:50 AM >> To: George Foti; Eric Burger; Linyi TIAN >> Cc: SIPCORE >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> >> Hi, >> >> Just to clarify that you are allowed to use existing legacy INFO >> usages, if such have already been specified. >> >> For example, if you want to support ISUP tunnelling it is >> perfectly ok to use the current mechanisms. You are not required >> to define an Info Package for that. >> >> BUT, if you are specifying a *NEW* INFO usage, then you MUST use >> the Info Package framework. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: George Foti >> Sent: Wed 9/23/2009 1:43 PM >> To: Christer Holmberg; Eric Burger; Linyi TIAN >> Cc: SIPCORE >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> Yes, I would like a statement that explicitly disallows any usage >> of INFO outside the framework. >> Than we don't have to rehash this discussion once more. >> >> >> Rgds. >> >> George Foti >> Ericsson Canada >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] >> On Behalf Of Christer Holmberg >> Sent: Wednesday, September 23, 2009 7:13 AM >> To: Eric Burger; Linyi TIAN >> Cc: SIPCORE >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> There is text in the draft which says that, for backward >> compability purpose, legacy usage of INFO is allowed. If needed, >> we can simply add a statement saying: "Any new usage of INFO MUST >> use the Info Package mechanism". >> >> Regards, >> >> Christer >> >> ________________________________ >> >> From: sipcore-bounces@ietf.org on behalf of Eric Burger >> Sent: Wed 9/23/2009 12:27 PM >> To: Linyi TIAN >> Cc: SIPCORE >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> >> >> Now I think I understand. Do we agree the request is to make it >> very, very, very clear that new usages of INFO outside the INFO >> Framework is not only a bad idea but will not be tolerated? If >> so, I think we can figure out some wording for that. >> >> On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: >> >>> You misunderstood my intention. Please see my response to Dean >> about >>> adding some text to further explain the benefit for SIP INFO FW >> and >>> the issue for SIP INFO. >>> >>> Cheers, >>> Linyi >> On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: >> >>> Hi, Dean >>> >>> If you read the following text in introduction section, it may >> be >>> understood as when the Content-Type indicates one contextual >> usage >>> then SIP INFO Package is not needed. That is what we are >> debating in >>> other SDOs. >>> While it may sometimes be clear what the content is based on the >>> Content-Type, this is only true where there is only one >> contextual >>> usage of the content-type. >>> >>> This is why I ask questions here and want the author to clarify >> it in >>> the I-D. I hope our concerns can be take into account in next >>> revision, e.g. >>> update the introduction and section 6. >>> >>> Cheers, >>> Linyi >>> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Wednesday, September 23, 2009 11:53 AM >>> To: Linyi TIAN >>> Cc: SIPCORE >>> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >>> >>> >>> On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: >>> >>>> Hi, Dean Willis, et al. >>>> >>>> I have to say I like your answers which clarify my doubts. May >> I >>>> suggest adding some words in " 6. Legacy Uses of INFO" to >> clarify >>>> the new SIP INFO Package approach and Content Type Approach? >> Maybe in >>>> the introduction section we can add more information about the >>>> Content Type approach. >>>> I mean >>>> not only talking about the JPEG example. Even in controlled >> Content- >>>> Type there maybe issues too as Dean said. >>> >>> >>> We've tried to do this in the Introduction to draft-itf-sipcore- >> info- >>> events-00. The text currently says: >>> >>>> While INFO has been widely adopted for specific application use >>>> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] >> neither >>>> defined a negotiation mechanism nor a means by which to >> explicitly >>>> indicate the type of application information contained in the >> INFO >>>> message. This led to problems associated with static >> configuration.>> In addition, the industry realized there was a >> potential for >>>> interoperability problems due to undefined content syntax and >>>> semantics. This draft addresses these deficiencies and >> provides a >>>> framework for explicit negotiation of capabilities and content >>>> context using "Info Packages". >>> >>>> The INFO method as defined by RFC 2976 did not provide any >> context >>>> for the information the request carried. While it may >> sometimes be >>>> clear what the content is based on the Content-Type, this is >> only >>>> true where there is only one contextual usage of the content-type. >>>> For example, if the Content-Type is "image/jpeg", the MIME- >> attached >>>> content is a JPEG image. However, there are many useful ways a >> UAS >>>> can render an image. Said differently, there are different >> contexts >>>> for an image in SIP. The image could be a caller-id picture, a >>>> contact icon, a photo for sharing, and so on. The sender does >> not >>>> know which image to send to the receiver if the receiver >> supports an >>>> image content type. Likewise, the receiver does not know the >> context >>>> of an image the client is sending if the receiver supports >> receiving >>>> more than one image content type. Thus, we need a well defined >> and >>>> documented statement of what the information sent is for. This >>>> situation is identical to the context issue in Internet Mail >>>> [RFC3458]. RFC 3458 goes into this and other issues in detail. >>> >>> I would not object to adding material here to further illustrate >> why >>> Content-Type alone is insufficient, assuming we can find a way >> to say >>> it that doesn't further confuse the reader. Of course, I'm not >> the >>> editor of the document, so I can only suggest this as a >> contributor to >>> the working group. >>> >>> Likewise, you suggested modifying Section 6, Legacy Uses of >> Info. This >>> section starts with: >>> >>> Several RFC-defined and other standards-defined uses of RFC >> 2976 >>> INFO >>> [RFC2976] exist and are in use, as well as numerous >> proprietary >>> uses. >>> Appendix B describes some of these usages. By definition, >>> identifying such uses has relied on either static local >>> configuration >>> or implicit context determination based on the body Content- >> Type or >>> Content-Disposition value or some proprietary mechanism. >> This >>> draft >>> cannot forbid nor avoid such uses, since local configuration can >>> always override standardized mechanisms. >>> >>> From what I understand, you are proposing to add some text here >> that >>> essentially explains how Content-Type combined with local >>> configuration provided adequate context for the legacy usages of >> INFO.> In other words, describing how the constrained environment >> of RFC 2976 >>> prevented users from encountering the kinds of problems that >> INFO- >>> package is attempting to prevent. I can see that such text might >> be >>> usefully added here, if we can find a way to say it that doesn't >> leave >>> the average reader even more confused. >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Wed Sep 23 23:21:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C453A687C for ; Wed, 23 Sep 2009 23:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea4vkXi4wXal for ; Wed, 23 Sep 2009 23:21:22 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 4B72C3A67C2 for ; Wed, 23 Sep 2009 23:21:21 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n8O6MLsj020021; Thu, 24 Sep 2009 08:22:22 +0200 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n8O6ML7P029710; Thu, 24 Sep 2009 08:22:21 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.159]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Thu, 24 Sep 2009 08:22:20 +0200 From: "Elwell, John" To: Francois Audet , Shida Schubert Date: Thu, 24 Sep 2009 08:22:18 +0200 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoxzpJ3WJP2FLpZQzKpW4UdSLDk8QAaloZgAoXTAbAAEFUrEAATWZ1w Message-ID: <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com><9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com><9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com><4AA6DEA7.7090403@nostrum.com><1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com><8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , "sipcore@ietf.org" , Hadriel Kaplan , Dean Willis , "Elwell, John" , Drage , Keith Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 06:21:24 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 23 September 2009 22:08 > To: Elwell, John; Shida Schubert > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean=20 > Willis; Elwell, John; Keith Drage > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > Can you give me an example of how the tags would look like? [JRE] Without an explicit indication of freephone, all URIs from B onwards = would be tagged as mapped, except E, which is registered contact. So withou= t the explicit indication of freephone, how does the UAS know which is the = freephone number? >=20 > Also, and you clarify what you mean by "forward" vs "resolve"? >=20 > I am assuming you are using "forward" in the traditional > "telephony" way, i.e., it is retargeted to another user, as opposed > to "request forwarding" which what you used for "resolving". Is this > correct? [JRE] Yes. John >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Wednesday, September 23, 2009 06:24 > > To: Audet, Francois (SC100:3055); Shida Schubert > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean=20 > > Willis; Elwell, John; Keith Drage > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > > If we want to find specific things like freephone numbers, I=20 > > think they do need to be explicitly marked, perhaps along the=20 > > lines that Shida has suggested. > > - Example 1: Call from A to B, which is forwarded to=20 > > freephone number C, which resolves to D, which resolves to=20 > contact E. > > - Example 2: Call from A to freephone number B, which=20 > > resolves to C, which is then forwarded to D, which resolves=20 > > to contact E. > >=20 > > These two examples illustrate that the freephone URI cannot=20 > > be found at any fixed place in the sequence, so explicit=20 > > marking would seem to be necessary. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > > > Sent: 10 September 2009 18:06 > > > To: Shida Schubert > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis;=20 > > > Elwell, John; Keith Drage > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > > Ok, thanks. > > >=20 > > > Let's wait for more input on this before we go for another=20 > > rev of the=20 > > > draft. > > >=20 > > > > -----Original Message----- > > > > From: Shida Schubert [mailto:shida@ntt-at.com] > > > > Sent: Wednesday, September 09, 2009 21:24 > > > > To: Audet, Francois (SC100:3055) > > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox;=20 > > Hadriel Kaplan;=20 > > > > Dean Willis; Elwell, John; Keith Drage > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > >=20 > > > >=20 > > > > I think the following could work for=20 > > Freephone(toll-free), AFAIK=20 > > > > all is needed for freephone was the mp tag and some guidance on=20 > > > > where to look for a toll-free. > > > >=20 > > > > I believe that solving the problem of toll-free is really=20 > > > > determining the current target of the request, which I=20 > believe is=20 > > > > what mp is trying to address. Generally if the incoming=20 > > request is=20 > > > > delivered via toll-free, then an entry before the last=20 > > mp(mapped-to)=20 > > > > is likely to be a toll-free number (mapped-from). > > > >=20 > > > > Although, without globally deterministic way to mark the=20 > > toll-free,=20 > > > > it's hard for it to work across countries as different=20 > countries=20 > > > > have different toll-free prefixes. > > > > (Here in Japan, it's 0120-xxx and not 1-800). > > > >=20 > > > > We could though, possibly define a service URN or=20 > some tags for=20 > > > > typical services that are out there and tag HI-entry=20 > representing=20 > > > > such service with service URN that we define. > > > >=20 > > > > History-Info: =20 > > > > < > > > > sip:DirectoryAssistance > > > > @example.com>;index=3D1;service=3Durn:service:directory-assistance > > > > History-Info:=20 > > ;index=3D1.1;mp=3D1 > > > > History-Info: ;index=3D1.1.1;rc=3D1 > > > > History-Info: ;index=3D1.1.2;rc=3D2 > > > >=20 > > > > Regards > > > > Shida > > > >=20 > > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > > > >=20 > > > > > I guess the summary is that we are kind of stalled on=20 > > some of the=20 > > > > > issues, in particular the aor tag issue. It seems that a > > > > significant > > > > > fraction of people do not believe that an AOR is=20 > deterministic=20 > > > > > construct that is worthy of being tagged as such. > > > > > > > > > > In my background (which is an Enterprise software/telephony=20 > > > > > background), "users" have accounts. An AOR is the series of > > > > addresses > > > > > corresponding to these accounts, along with any aliases > > > > (such as phone > > > > > numbers expressed in SIP/TEL format). To me, AORs are not > > > > this fluffy > > > > > concept that others on the list have made it up to be. > > > > > > > > > > But in any case, I don't think we'll be able to reach a > > > > concensus on > > > > > it. > > > > > > > > > > I believe that we need to step back and find a different > > > > way to skin > > > > > this cat. > > > > > > > > > > Going back to the requirements of WHAT we are really trying > > > > to solve > > > > > at the > > > > > UAS: > > > > > > > > > > 1) Tagging the last address (including parameters) that > > > was used in > > > > > a Request-URI before being replaced by the Contact. > > > > > i.e., the target-uri problem > > > > > 1a) It has been argued that sometimes with the > > > > target-uri problem > > > > > you may actually be looking for the first=20 > > address (and > > > > > parameters) > > > > > as opposed to the last one. > > > > > > > > > > 2) Tagging addresses that represents a DIFFERENT > > > user/resource, as a > > > > > result of re-targeting. > > > > > i.e., the re-targeting problem (voicemail, IVR, etc.) > > > > > > > > > > We could potentially solve those two by having tags for > > > > "mapped" and > > > > > "contacts", and use a pointer to the index of what it is > > > > mapped from > > > > > (I guess we could do forward pointing instead of backward > > > pointing, > > > > > but then forking would be more cumbersome). > > > > > > > > > > Having the tag pointing to the index would remove ambiguity > > > > if entries > > > > > are removed by a proxy, etc. > > > > > > > > > > So, if I take a specific example of a call to bob being > > > > redirected to > > > > > carol, the HI would look like > > > > > this: > > > > > > > > > > History-Info: ;index=3D1; > > > > > History-Info: ;\ > > > > > index=3D1.1;rc=3D1 > > > > > History-Info: ;index=3D2;mp=3D1 > > > > > History-Info: ;index=3D2.1;rc=3D2 > > > > > > > > > > For problem 1 (target-uri), the UAS would look at the=20 > > last rc tag=20 > > > > > which is it's registered contact, and see what it points > > > to (i.e., > > > > > index 2). > > > > > Index 2 is therefore > > > > > the last target-uri. > > > > > > > > > > For problem 2 (redirection), the UAS looks for the last > > > mp tag (it > > > > > points to index 1). > > > > > Index 1 (bob) is therefore the "redirecting" number.=20 > > > Alternatively, > > > > > the UAS may look for the FIRST retargeting (many voicemail > > > > work with > > > > > the first one). > > > > > > > > > > Anyways, this is just brainstorming (and it notably doesn't > > > > solve - I > > > > > think - the Freephone/1-800 number problem). > > > > > > > > > > Ideas? > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Adam Roach [mailto:adam@nostrum.com] > > > > >> Sent: Tuesday, September 08, 2009 15:46 > > > > >> To: sipcore@ietf.org > > > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith > > > Drage; Jon > > > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; > > > Dean Willis > > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > >> > > > > >> Just a quick reminder that we discussed this vigorously in > > > > Stockholm > > > > >> without reaching any conclusion. To help spur things > > > > along, here's a > > > > >> summary of the arguments made during that discussion: > > > > >> > > > > >> > > > > >>=20 > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > > > > >> 201:%20AOR%20tag > > > > >> > > > > >> Please resume discussion on the list, and see if we can > > > reach any > > > > >> sort of rough agreement. > > > > >> > > > > >> /a > > > > >> > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > >=20 > > > >=20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > >=20 > = From eburger@standardstrack.com Thu Sep 24 04:50:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17A83A67C1 for ; Thu, 24 Sep 2009 04:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3faMxiirHjw for ; Thu, 24 Sep 2009 04:50:32 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 2E57A3A677C for ; Thu, 24 Sep 2009 04:50:32 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.25.202]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MqmrG-0000fR-Ll; Thu, 24 Sep 2009 04:51:35 -0700 Message-Id: From: Eric Burger To: tianlinyi 34932 In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 07:51:31 -0400 References: <014801ca3b38$51ab7940$f5026bc0$@com> <016201ca3b4d$3fc6e380$bf54aa80$@com> <018e01ca3b55$bf298a30$3d7c9e90$@com> <019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com> <388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com> <02d601ca3be8$5d818060$18848120$@com> <9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com> <02e701ca3c09$c560ad20$50220760$@com> <18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 11:50:33 -0000 The primary reason we are in the INFO mess in the first place is the old, legacy INFO specification allowed people to create usages that "worked for them" yet had no way of indicating what the usage is, so that it would be impossible to have interoperable UAs that happened to use more than one INFO usage. I strongly disagree with the sentiment that if you happen to not need all of the features of the INFO Framework that you might want to use the INFO Framework anyway because it is not too hard. Rather, if you do not use the INFO Framework, YOU ARE HARMING THE INTERNET BY HARMING INTEROPERABILITY. The interoperability here is not your implementation of your INFO usage. It is the interoperability of your UA with other UAs that have other INFO usages. Life is good if you only talk to yourself or you do not use INFO. In the real world, you presumably talk to other devices, many of which will not be under your control. Use of the INFO Framework, therefore, is mandatory, not just a good idea. That said, unfortunately I have to agree with Linyi - there is no protocol way of saying 'you MUST write the correct document.' That is not a protocol thing. However, IANA and the SIP expert group are now aware of this issue, and that[ has the same effect as a ban on new INFO usages outside the INFO Framework. On Sep 23, 2009, at 1:40 PM, Christer Holmberg wrote: > Hi, > > The idea is that the I-P draft replaces the existing RFC. For > backward compability it allows existing RFC based solutions, but the > idea is that any new usage DOES use the I-P mechanism. > > Since you will have to describe the semantics etc of the new usage > anyway, I really don't see the problem is in doing it in the form of > an I-P. Just because, for a specific use-case, you may not need all > "features" of the I-P mechanism, I think it is much better to use a > single mechanism. > > Just for my interest: is there some specific new usage you have in > mind, where you would like to use legacy INFO? > > Regards, > > Christer > > ________________________________ > > From: tianlinyi 34932 [mailto:tianlinyi@huawei.com] > Sent: Wed 23/09/2009 16:06 > To: George Foti > Cc: Christer Holmberg; Eric Burger; SIPCORE > Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > Hi, George > > I don't believe this could be mandated in this I-D. If there is no > IOP issue for old INFO or potential INFO with clear specification it > is free for them to use. Guidance will be enough. > > Cheers, > Linyi > > ****************************************************************************************** > This email and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose > address is listed above. Any use of the information contained here > in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than > the intended recipient(s) is prohibited. If you receive this email > in error, please notify the sender by phone or email > immediately and delete it! > ***************************************************************************************** > > ----- ??? ----- > ???: George Foti > ??: ???, ?? 23?, 2009 ??8:59 > ??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > ???: Christer Holmberg , Eric Burger > , Linyi TIAN > ??: SIPCORE > >> Hi Christer, >> >> Yes, I am referring to including an explicit statement disallowing >> any NEW info usage outside the Info event framework. >> Thanks >> >> George >> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Wednesday, September 23, 2009 8:50 AM >> To: George Foti; Eric Burger; Linyi TIAN >> Cc: SIPCORE >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> >> Hi, >> >> Just to clarify that you are allowed to use existing legacy INFO >> usages, if such have already been specified. >> >> For example, if you want to support ISUP tunnelling it is >> perfectly ok to use the current mechanisms. You are not required >> to define an Info Package for that. >> >> BUT, if you are specifying a *NEW* INFO usage, then you MUST use >> the Info Package framework. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: George Foti >> Sent: Wed 9/23/2009 1:43 PM >> To: Christer Holmberg; Eric Burger; Linyi TIAN >> Cc: SIPCORE >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> Yes, I would like a statement that explicitly disallows any usage >> of INFO outside the framework. >> Than we don't have to rehash this discussion once more. >> >> >> Rgds. >> >> George Foti >> Ericsson Canada >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] >> On Behalf Of Christer Holmberg >> Sent: Wednesday, September 23, 2009 7:13 AM >> To: Eric Burger; Linyi TIAN >> Cc: SIPCORE >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> There is text in the draft which says that, for backward >> compability purpose, legacy usage of INFO is allowed. If needed, >> we can simply add a statement saying: "Any new usage of INFO MUST >> use the Info Package mechanism". >> >> Regards, >> >> Christer >> >> ________________________________ >> >> From: sipcore-bounces@ietf.org on behalf of Eric Burger >> Sent: Wed 9/23/2009 12:27 PM >> To: Linyi TIAN >> Cc: SIPCORE >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >> >> >> >> Now I think I understand. Do we agree the request is to make it >> very, very, very clear that new usages of INFO outside the INFO >> Framework is not only a bad idea but will not be tolerated? If >> so, I think we can figure out some wording for that. >> >> On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: >> >>> You misunderstood my intention. Please see my response to Dean >> about >>> adding some text to further explain the benefit for SIP INFO FW >> and >>> the issue for SIP INFO. >>> >>> Cheers, >>> Linyi >> >> On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: >> >>> Hi, Dean >>> >>> If you read the following text in introduction section, it may >> be >>> understood as when the Content-Type indicates one contextual >> usage >>> then SIP INFO Package is not needed. That is what we are >> debating in >>> other SDOs. >>> While it may sometimes be clear what the content is based on the >>> Content-Type, this is only true where there is only one >> contextual >>> usage of the content-type. >>> >>> This is why I ask questions here and want the author to clarify >> it in >>> the I-D. I hope our concerns can be take into account in next >>> revision, e.g. >>> update the introduction and section 6. >>> >>> Cheers, >>> Linyi >>> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Wednesday, September 23, 2009 11:53 AM >>> To: Linyi TIAN >>> Cc: SIPCORE >>> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >>> >>> >>> On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: >>> >>>> Hi, Dean Willis, et al. >>>> >>>> I have to say I like your answers which clarify my doubts. May >> I >>>> suggest adding some words in " 6. Legacy Uses of INFO" to >> clarify >>>> the new SIP INFO Package approach and Content Type Approach? >> Maybe in >>>> the introduction section we can add more information about the >>>> Content Type approach. >>>> I mean >>>> not only talking about the JPEG example. Even in controlled >> Content- >>>> Type there maybe issues too as Dean said. >>> >>> >>> >>> We've tried to do this in the Introduction to draft-itf-sipcore- >> info- >>> events-00. The text currently says: >>> >>>> While INFO has been widely adopted for specific application use >>>> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] >> neither >>>> defined a negotiation mechanism nor a means by which to >> explicitly >>>> indicate the type of application information contained in the >> INFO >>>> message. This led to problems associated with static >> configuration.>> In addition, the industry realized there was a >> potential for >>>> interoperability problems due to undefined content syntax and >>>> semantics. This draft addresses these deficiencies and >> provides a >>>> framework for explicit negotiation of capabilities and content >>>> context using "Info Packages". >>> >>> >>>> The INFO method as defined by RFC 2976 did not provide any >> context >>>> for the information the request carried. While it may >> sometimes be >>>> clear what the content is based on the Content-Type, this is >> only >>>> true where there is only one contextual usage of the content-type. >>>> For example, if the Content-Type is "image/jpeg", the MIME- >> attached >>>> content is a JPEG image. However, there are many useful ways a >> UAS >>>> can render an image. Said differently, there are different >> contexts >>>> for an image in SIP. The image could be a caller-id picture, a >>>> contact icon, a photo for sharing, and so on. The sender does >> not >>>> know which image to send to the receiver if the receiver >> supports an >>>> image content type. Likewise, the receiver does not know the >> context >>>> of an image the client is sending if the receiver supports >> receiving >>>> more than one image content type. Thus, we need a well defined >> and >>>> documented statement of what the information sent is for. This >>>> situation is identical to the context issue in Internet Mail >>>> [RFC3458]. RFC 3458 goes into this and other issues in detail. >>> >>> >>> I would not object to adding material here to further illustrate >> why >>> Content-Type alone is insufficient, assuming we can find a way >> to say >>> it that doesn't further confuse the reader. Of course, I'm not >> the >>> editor of the document, so I can only suggest this as a >> contributor to >>> the working group. >>> >>> Likewise, you suggested modifying Section 6, Legacy Uses of >> Info. This >>> section starts with: >>> >>> Several RFC-defined and other standards-defined uses of RFC >> 2976 >>> INFO >>> [RFC2976] exist and are in use, as well as numerous >> proprietary >>> uses. >>> Appendix B describes some of these usages. By definition, >>> identifying such uses has relied on either static local >>> configuration >>> or implicit context determination based on the body Content- >> Type or >>> Content-Disposition value or some proprietary mechanism. >> This >>> draft >>> cannot forbid nor avoid such uses, since local configuration can >>> always override standardized mechanisms. >>> >>> From what I understand, you are proposing to add some text here >> that >>> essentially explains how Content-Type combined with local >>> configuration provided adequate context for the legacy usages of >> INFO.> In other words, describing how the constrained environment >> of RFC 2976 >>> prevented users from encountering the kinds of problems that >> INFO- >>> package is attempting to prevent. I can see that such text might >> be >>> usefully added here, if we can find a way to say it that doesn't >> leave >>> the average reader even more confused. >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From christer.holmberg@ericsson.com Thu Sep 24 04:59:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E573A68BE for ; Thu, 24 Sep 2009 04:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKtN1iT6Ezf1 for ; Thu, 24 Sep 2009 04:59:40 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2919E3A69BD for ; Thu, 24 Sep 2009 04:59:39 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-a7-4abb5f6e9580 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B4.A2.22406.E6F5BBA4; Thu, 24 Sep 2009 14:00:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 13:59:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Sep 2009 13:59:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco9DWZgNc3lcM4QQUaIZTQA5pGQ7gAAIolA References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com><02e701ca3c09$c560ad20$50220760$@com><18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> From: "Christer Holmberg" To: "Eric Burger" , "tianlinyi 34932" X-OriginalArrivalTime: 24 Sep 2009 11:59:57.0828 (UTC) FILETIME=[89723440:01CA3D0E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 11:59:41 -0000 Hi, I agree with Eric. There is no protocol way of saying "you MUST write to correct document", but the I-P draft does provide guidance on what type of information that an I-P description shall contain. Time will show whether that is enough, but choosing not to use it in the first place is for sure not going to make anything better... Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > Sent: 24. syyskuuta 2009 14:52 > To: tianlinyi 34932 > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package >=20 > The primary reason we are in the INFO mess in the first place=20 > is the old, legacy INFO specification allowed people to=20 > create usages that "worked for them" yet had no way of=20 > indicating what the usage is, so that it would be impossible=20 > to have interoperable UAs that happened to use more than one=20 > INFO usage. >=20 > I strongly disagree with the sentiment that if you happen to=20 > not need all of the features of the INFO Framework that you=20 > might want to use the INFO Framework anyway because it is not=20 > too hard. Rather, if you do not use the INFO Framework, YOU=20 > ARE HARMING THE INTERNET BY HARMING INTEROPERABILITY. >=20 > The interoperability here is not your implementation of your=20 > INFO usage. It is the interoperability of your UA with other=20 > UAs that have other INFO usages. Life is good if you only=20 > talk to yourself or you do not use INFO. In the real world,=20 > you presumably talk to other devices, many of which will not=20 > be under your control. >=20 > Use of the INFO Framework, therefore, is mandatory, not just=20 > a good idea. >=20 > That said, unfortunately I have to agree with Linyi - there=20 > is no protocol way of saying 'you MUST write the correct=20 > document.' That is not a protocol thing. However, IANA and=20 > the SIP expert group are now aware of this issue, and that[=20 > has the same effect as a ban on new INFO usages outside the=20 > INFO Framework. >=20 > On Sep 23, 2009, at 1:40 PM, Christer Holmberg wrote: >=20 > > Hi, > > > > The idea is that the I-P draft replaces the existing RFC.=20 > For backward=20 > > compability it allows existing RFC based solutions, but the idea is=20 > > that any new usage DOES use the I-P mechanism. > > > > Since you will have to describe the semantics etc of the new usage=20 > > anyway, I really don't see the problem is in doing it in=20 > the form of=20 > > an I-P. Just because, for a specific use-case, you may not need all=20 > > "features" of the I-P mechanism, I think it is much better to use a=20 > > single mechanism. > > > > Just for my interest: is there some specific new usage you have in=20 > > mind, where you would like to use legacy INFO? > > > > Regards, > > > > Christer > > > > ________________________________ > > > > From: tianlinyi 34932 [mailto:tianlinyi@huawei.com] > > Sent: Wed 23/09/2009 16:06 > > To: George Foti > > Cc: Christer Holmberg; Eric Burger; SIPCORE > > Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > > > > > Hi, George > > > > I don't believe this could be mandated in this I-D. If=20 > there is no IOP=20 > > issue for old INFO or potential INFO with clear specification it is=20 > > free for them to use. Guidance will be enough. > > > > Cheers, > > Linyi > > > >=20 > ********************************************************************** > > ******************** This email and its attachments contain=20 > > confidential information from HUAWEI, which is intended=20 > only for the=20 > > person or entity whose address is listed above. Any use of the=20 > > information contained here in any way (including, but not=20 > limited to,=20 > > total or partial disclosure, reproduction, or dissemination) by=20 > > persons other than the intended recipient(s) is prohibited. If you=20 > > receive this email in error, please notify the sender by phone or=20 > > email immediately and delete it! > >=20 > ********************************************************************** > > ******************* > > > > ----- ??? ----- > > ???: George Foti > > ??: ???, ?? 23?, 2009 ??8:59 > > ??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > ???: Christer Holmberg ,=20 > Eric Burger=20 > > , Linyi TIAN > > ??: SIPCORE > > > >> Hi Christer, > >> > >> Yes, I am referring to including an explicit statement disallowing=20 > >> any NEW info usage outside the Info event framework. > >> Thanks > >> > >> George > >> > >> > >> -----Original Message----- > >> From: Christer Holmberg > >> Sent: Wednesday, September 23, 2009 8:50 AM > >> To: George Foti; Eric Burger; Linyi TIAN > >> Cc: SIPCORE > >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> > >> Hi, > >> > >> Just to clarify that you are allowed to use existing legacy INFO=20 > >> usages, if such have already been specified. > >> > >> For example, if you want to support ISUP tunnelling it is=20 > perfectly=20 > >> ok to use the current mechanisms. You are not required to=20 > define an=20 > >> Info Package for that. > >> > >> BUT, if you are specifying a *NEW* INFO usage, then you=20 > MUST use the=20 > >> Info Package framework. > >> > >> Regards, > >> > >> Christer > >> > >> > >> -----Original Message----- > >> From: George Foti > >> Sent: Wed 9/23/2009 1:43 PM > >> To: Christer Holmberg; Eric Burger; Linyi TIAN > >> Cc: SIPCORE > >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> Yes, I would like a statement that explicitly disallows=20 > any usage of=20 > >> INFO outside the framework. > >> Than we don't have to rehash this discussion once more. > >> > >> > >> Rgds. > >> > >> George Foti > >> Ericsson Canada > >> > >> > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On=20 > >> Behalf Of Christer Holmberg > >> Sent: Wednesday, September 23, 2009 7:13 AM > >> To: Eric Burger; Linyi TIAN > >> Cc: SIPCORE > >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> There is text in the draft which says that, for backward=20 > compability=20 > >> purpose, legacy usage of INFO is allowed. If needed, we can simply=20 > >> add a statement saying: "Any new usage of INFO MUST use the Info=20 > >> Package mechanism". > >> > >> Regards, > >> > >> Christer > >> > >> ________________________________ > >> > >> From: sipcore-bounces@ietf.org on behalf of Eric Burger > >> Sent: Wed 9/23/2009 12:27 PM > >> To: Linyi TIAN > >> Cc: SIPCORE > >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> > >> > >> Now I think I understand. Do we agree the request is to make it=20 > >> very, very, very clear that new usages of INFO outside the INFO=20 > >> Framework is not only a bad idea but will not be=20 > tolerated? If so, I=20 > >> think we can figure out some wording for that. > >> > >> On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > >> > >>> You misunderstood my intention. Please see my response to Dean > >> about > >>> adding some text to further explain the benefit for SIP INFO FW > >> and > >>> the issue for SIP INFO. > >>> > >>> Cheers, > >>> Linyi > >> > >> On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > >> > >>> Hi, Dean > >>> > >>> If you read the following text in introduction section, it may > >> be > >>> understood as when the Content-Type indicates one contextual > >> usage > >>> then SIP INFO Package is not needed. That is what we are > >> debating in > >>> other SDOs. > >>> While it may sometimes be clear what the content is based on the=20 > >>> Content-Type, this is only true where there is only one > >> contextual > >>> usage of the content-type. > >>> > >>> This is why I ask questions here and want the author to clarify > >> it in > >>> the I-D. I hope our concerns can be take into account in next=20 > >>> revision, e.g. > >>> update the introduction and section 6. > >>> > >>> Cheers, > >>> Linyi > >>> > >>> -----Original Message----- > >>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>> Sent: Wednesday, September 23, 2009 11:53 AM > >>> To: Linyi TIAN > >>> Cc: SIPCORE > >>> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >>> > >>> > >>> On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >>> > >>>> Hi, Dean Willis, et al. > >>>> > >>>> I have to say I like your answers which clarify my doubts. May > >> I > >>>> suggest adding some words in " 6. Legacy Uses of INFO" to > >> clarify > >>>> the new SIP INFO Package approach and Content Type Approach? > >> Maybe in > >>>> the introduction section we can add more information about the=20 > >>>> Content Type approach. > >>>> I mean > >>>> not only talking about the JPEG example. Even in controlled > >> Content- > >>>> Type there maybe issues too as Dean said. > >>> > >>> > >>> > >>> We've tried to do this in the Introduction to draft-itf-sipcore- > >> info- > >>> events-00. The text currently says: > >>> > >>>> While INFO has been widely adopted for specific application use=20 > >>>> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] > >> neither > >>>> defined a negotiation mechanism nor a means by which to > >> explicitly > >>>> indicate the type of application information contained in the > >> INFO > >>>> message. This led to problems associated with static > >> configuration.>> In addition, the industry realized there was a=20 > >> potential for > >>>> interoperability problems due to undefined content syntax and=20 > >>>> semantics. This draft addresses these deficiencies and > >> provides a > >>>> framework for explicit negotiation of capabilities and content=20 > >>>> context using "Info Packages". > >>> > >>> > >>>> The INFO method as defined by RFC 2976 did not provide any > >> context > >>>> for the information the request carried. While it may > >> sometimes be > >>>> clear what the content is based on the Content-Type, this is > >> only > >>>> true where there is only one contextual usage of the=20 > content-type. > >>>> For example, if the Content-Type is "image/jpeg", the MIME- > >> attached > >>>> content is a JPEG image. However, there are many useful ways a > >> UAS > >>>> can render an image. Said differently, there are different > >> contexts > >>>> for an image in SIP. The image could be a caller-id picture, a=20 > >>>> contact icon, a photo for sharing, and so on. The sender does > >> not > >>>> know which image to send to the receiver if the receiver > >> supports an > >>>> image content type. Likewise, the receiver does not know the > >> context > >>>> of an image the client is sending if the receiver supports > >> receiving > >>>> more than one image content type. Thus, we need a well defined > >> and > >>>> documented statement of what the information sent is for. This=20 > >>>> situation is identical to the context issue in Internet Mail=20 > >>>> [RFC3458]. RFC 3458 goes into this and other issues in detail. > >>> > >>> > >>> I would not object to adding material here to further illustrate > >> why > >>> Content-Type alone is insufficient, assuming we can find a way > >> to say > >>> it that doesn't further confuse the reader. Of course, I'm not > >> the > >>> editor of the document, so I can only suggest this as a > >> contributor to > >>> the working group. > >>> > >>> Likewise, you suggested modifying Section 6, Legacy Uses of > >> Info. This > >>> section starts with: > >>> > >>> Several RFC-defined and other standards-defined uses of RFC > >> 2976 > >>> INFO > >>> [RFC2976] exist and are in use, as well as numerous > >> proprietary > >>> uses. > >>> Appendix B describes some of these usages. By definition, > >>> identifying such uses has relied on either static local=20 > >>> configuration > >>> or implicit context determination based on the body Content- > >> Type or > >>> Content-Disposition value or some proprietary mechanism. > >> This > >>> draft > >>> cannot forbid nor avoid such uses, since local configuration can > >>> always override standardized mechanisms. > >>> > >>> From what I understand, you are proposing to add some text here > >> that > >>> essentially explains how Content-Type combined with local=20 > >>> configuration provided adequate context for the legacy usages of > >> INFO.> In other words, describing how the constrained=20 > environment of=20 > >> RFC 2976 > >>> prevented users from encountering the kinds of problems that > >> INFO- > >>> package is attempting to prevent. I can see that such text might > >> be > >>> usefully added here, if we can find a way to say it that doesn't > >> leave > >>> the average reader even more confused. > >>> > >>> -- > >>> Dean > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From george.foti@ericsson.com Thu Sep 24 06:56:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E8128C0F0 for ; Thu, 24 Sep 2009 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h32GjOnw9ero for ; Thu, 24 Sep 2009 06:56:33 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id ADE9E3A6A24 for ; Thu, 24 Sep 2009 06:56:33 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8ODvZLG013406; Thu, 24 Sep 2009 08:57:38 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 08:57:34 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 08:57:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 24 Sep 2009 09:57:33 -0400 From: George Foti To: Christer Holmberg , Eric Burger , tianlinyi 34932 Date: Thu, 24 Sep 2009 09:57:31 -0400 Thread-Topic: [sipcore] When to use SIP INFO and SIP INFO-Package Thread-Index: Aco9DWZgNc3lcM4QQUaIZTQA5pGQ7gAAIolAAAQyqcA= Message-ID: References: <014801ca3b38$51ab7940$f5026bc0$@com><016201ca3b4d$3fc6e380$bf54aa80$@com><018e01ca3b55$bf298a30$3d7c9e90$@com><019e01ca3b5b$e1b552e0$a51ff8a0$@com> <4AB8CE55.8050302@cisco.com><388EFD61-C534-4B9D-83AB-83C8432A51E7@softarmor.com><02d601ca3be8$5d818060$18848120$@com><9804F8EB-D0E6-4928-8871-AB3F38292C03@softarmor.com><02e701ca3c09$c560ad20$50220760$@com><18A1C698-FEBA-4B1B-8596-EE65CD3A97F2@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Sep 2009 13:57:34.0195 (UTC) FILETIME=[F75E5C30:01CA3D1E] Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 13:56:35 -0000 I hope that IANA does not register things that promotes the legacy usage of= INFO. -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Thursday, September 24, 2009 8:00 AM To: Eric Burger; tianlinyi 34932 Cc: SIPCORE Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package Hi, I agree with Eric. There is no protocol way of saying "you MUST write to correct document", bu= t the I-P draft does provide guidance on what type of information that an I= -P description shall contain. Time will show whether that is enough, but ch= oosing not to use it in the first place is for sure not going to make anyth= ing better... Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > Sent: 24. syyskuuta 2009 14:52 > To: tianlinyi 34932 > Cc: SIPCORE > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > The primary reason we are in the INFO mess in the first place is the > old, legacy INFO specification allowed people to create usages that > "worked for them" yet had no way of indicating what the usage is, so > that it would be impossible to have interoperable UAs that happened to > use more than one INFO usage. > > I strongly disagree with the sentiment that if you happen to not need > all of the features of the INFO Framework that you might want to use > the INFO Framework anyway because it is not too hard. Rather, if you > do not use the INFO Framework, YOU ARE HARMING THE INTERNET BY HARMING > INTEROPERABILITY. > > The interoperability here is not your implementation of your INFO > usage. It is the interoperability of your UA with other UAs that have > other INFO usages. Life is good if you only talk to yourself or you > do not use INFO. In the real world, you presumably talk to other > devices, many of which will not be under your control. > > Use of the INFO Framework, therefore, is mandatory, not just a good > idea. > > That said, unfortunately I have to agree with Linyi - there is no > protocol way of saying 'you MUST write the correct document.' That is > not a protocol thing. However, IANA and the SIP expert group are now > aware of this issue, and that[ has the same effect as a ban on new > INFO usages outside the INFO Framework. > > On Sep 23, 2009, at 1:40 PM, Christer Holmberg wrote: > > > Hi, > > > > The idea is that the I-P draft replaces the existing RFC. > For backward > > compability it allows existing RFC based solutions, but the idea is > > that any new usage DOES use the I-P mechanism. > > > > Since you will have to describe the semantics etc of the new usage > > anyway, I really don't see the problem is in doing it in > the form of > > an I-P. Just because, for a specific use-case, you may not need all > > "features" of the I-P mechanism, I think it is much better to use a > > single mechanism. > > > > Just for my interest: is there some specific new usage you have in > > mind, where you would like to use legacy INFO? > > > > Regards, > > > > Christer > > > > ________________________________ > > > > From: tianlinyi 34932 [mailto:tianlinyi@huawei.com] > > Sent: Wed 23/09/2009 16:06 > > To: George Foti > > Cc: Christer Holmberg; Eric Burger; SIPCORE > > Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > > > > > > Hi, George > > > > I don't believe this could be mandated in this I-D. If > there is no IOP > > issue for old INFO or potential INFO with clear specification it is > > free for them to use. Guidance will be enough. > > > > Cheers, > > Linyi > > > > > ********************************************************************** > > ******************** This email and its attachments contain > > confidential information from HUAWEI, which is intended > only for the > > person or entity whose address is listed above. Any use of the > > information contained here in any way (including, but not > limited to, > > total or partial disclosure, reproduction, or dissemination) by > > persons other than the intended recipient(s) is prohibited. If you > > receive this email in error, please notify the sender by phone or > > email immediately and delete it! > > > ********************************************************************** > > ******************* > > > > ----- ??? ----- > > ???: George Foti > > ??: ???, ?? 23?, 2009 ??8:59 > > ??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > ???: Christer Holmberg , > Eric Burger > > , Linyi TIAN > > ??: SIPCORE > > > >> Hi Christer, > >> > >> Yes, I am referring to including an explicit statement disallowing > >> any NEW info usage outside the Info event framework. > >> Thanks > >> > >> George > >> > >> > >> -----Original Message----- > >> From: Christer Holmberg > >> Sent: Wednesday, September 23, 2009 8:50 AM > >> To: George Foti; Eric Burger; Linyi TIAN > >> Cc: SIPCORE > >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> > >> Hi, > >> > >> Just to clarify that you are allowed to use existing legacy INFO > >> usages, if such have already been specified. > >> > >> For example, if you want to support ISUP tunnelling it is > perfectly > >> ok to use the current mechanisms. You are not required to > define an > >> Info Package for that. > >> > >> BUT, if you are specifying a *NEW* INFO usage, then you > MUST use the > >> Info Package framework. > >> > >> Regards, > >> > >> Christer > >> > >> > >> -----Original Message----- > >> From: George Foti > >> Sent: Wed 9/23/2009 1:43 PM > >> To: Christer Holmberg; Eric Burger; Linyi TIAN > >> Cc: SIPCORE > >> Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> Yes, I would like a statement that explicitly disallows > any usage of > >> INFO outside the framework. > >> Than we don't have to rehash this discussion once more. > >> > >> > >> Rgds. > >> > >> George Foti > >> Ericsson Canada > >> > >> > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On > >> Behalf Of Christer Holmberg > >> Sent: Wednesday, September 23, 2009 7:13 AM > >> To: Eric Burger; Linyi TIAN > >> Cc: SIPCORE > >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> There is text in the draft which says that, for backward > compability > >> purpose, legacy usage of INFO is allowed. If needed, we can simply > >> add a statement saying: "Any new usage of INFO MUST use the Info > >> Package mechanism". > >> > >> Regards, > >> > >> Christer > >> > >> ________________________________ > >> > >> From: sipcore-bounces@ietf.org on behalf of Eric Burger > >> Sent: Wed 9/23/2009 12:27 PM > >> To: Linyi TIAN > >> Cc: SIPCORE > >> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >> > >> > >> > >> Now I think I understand. Do we agree the request is to make it > >> very, very, very clear that new usages of INFO outside the INFO > >> Framework is not only a bad idea but will not be > tolerated? If so, I > >> think we can figure out some wording for that. > >> > >> On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote: > >> > >>> You misunderstood my intention. Please see my response to Dean > >> about > >>> adding some text to further explain the benefit for SIP INFO FW > >> and > >>> the issue for SIP INFO. > >>> > >>> Cheers, > >>> Linyi > >> > >> On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote: > >> > >>> Hi, Dean > >>> > >>> If you read the following text in introduction section, it may > >> be > >>> understood as when the Content-Type indicates one contextual > >> usage > >>> then SIP INFO Package is not needed. That is what we are > >> debating in > >>> other SDOs. > >>> While it may sometimes be clear what the content is based on the > >>> Content-Type, this is only true where there is only one > >> contextual > >>> usage of the content-type. > >>> > >>> This is why I ask questions here and want the author to clarify > >> it in > >>> the I-D. I hope our concerns can be take into account in next > >>> revision, e.g. > >>> update the introduction and section 6. > >>> > >>> Cheers, > >>> Linyi > >>> > >>> -----Original Message----- > >>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>> Sent: Wednesday, September 23, 2009 11:53 AM > >>> To: Linyi TIAN > >>> Cc: SIPCORE > >>> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > >>> > >>> > >>> On Sep 22, 2009, at 7:54 PM, Linyi TIAN wrote: > >>> > >>>> Hi, Dean Willis, et al. > >>>> > >>>> I have to say I like your answers which clarify my doubts. May > >> I > >>>> suggest adding some words in " 6. Legacy Uses of INFO" to > >> clarify > >>>> the new SIP INFO Package approach and Content Type Approach? > >> Maybe in > >>>> the introduction section we can add more information about the > >>>> Content Type approach. > >>>> I mean > >>>> not only talking about the JPEG example. Even in controlled > >> Content- > >>>> Type there maybe issues too as Dean said. > >>> > >>> > >>> > >>> We've tried to do this in the Introduction to draft-itf-sipcore- > >> info- > >>> events-00. The text currently says: > >>> > >>>> While INFO has been widely adopted for specific application use > >>>> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] > >> neither > >>>> defined a negotiation mechanism nor a means by which to > >> explicitly > >>>> indicate the type of application information contained in the > >> INFO > >>>> message. This led to problems associated with static > >> configuration.>> In addition, the industry realized there was a > >> potential for > >>>> interoperability problems due to undefined content syntax and > >>>> semantics. This draft addresses these deficiencies and > >> provides a > >>>> framework for explicit negotiation of capabilities and content > >>>> context using "Info Packages". > >>> > >>> > >>>> The INFO method as defined by RFC 2976 did not provide any > >> context > >>>> for the information the request carried. While it may > >> sometimes be > >>>> clear what the content is based on the Content-Type, this is > >> only > >>>> true where there is only one contextual usage of the > content-type. > >>>> For example, if the Content-Type is "image/jpeg", the MIME- > >> attached > >>>> content is a JPEG image. However, there are many useful ways a > >> UAS > >>>> can render an image. Said differently, there are different > >> contexts > >>>> for an image in SIP. The image could be a caller-id picture, a > >>>> contact icon, a photo for sharing, and so on. The sender does > >> not > >>>> know which image to send to the receiver if the receiver > >> supports an > >>>> image content type. Likewise, the receiver does not know the > >> context > >>>> of an image the client is sending if the receiver supports > >> receiving > >>>> more than one image content type. Thus, we need a well defined > >> and > >>>> documented statement of what the information sent is for. This > >>>> situation is identical to the context issue in Internet Mail > >>>> [RFC3458]. RFC 3458 goes into this and other issues in detail. > >>> > >>> > >>> I would not object to adding material here to further illustrate > >> why > >>> Content-Type alone is insufficient, assuming we can find a way > >> to say > >>> it that doesn't further confuse the reader. Of course, I'm not > >> the > >>> editor of the document, so I can only suggest this as a > >> contributor to > >>> the working group. > >>> > >>> Likewise, you suggested modifying Section 6, Legacy Uses of > >> Info. This > >>> section starts with: > >>> > >>> Several RFC-defined and other standards-defined uses of RFC > >> 2976 > >>> INFO > >>> [RFC2976] exist and are in use, as well as numerous > >> proprietary > >>> uses. > >>> Appendix B describes some of these usages. By definition, > >>> identifying such uses has relied on either static local > >>> configuration > >>> or implicit context determination based on the body Content- > >> Type or > >>> Content-Disposition value or some proprietary mechanism. > >> This > >>> draft > >>> cannot forbid nor avoid such uses, since local configuration can > >>> always override standardized mechanisms. > >>> > >>> From what I understand, you are proposing to add some text here > >> that > >>> essentially explains how Content-Type combined with local > >>> configuration provided adequate context for the legacy usages of > >> INFO.> In other words, describing how the constrained > environment of > >> RFC 2976 > >>> prevented users from encountering the kinds of problems that > >> INFO- > >>> package is attempting to prevent. I can see that such text might > >> be > >>> usefully added here, if we can find a way to say it that doesn't > >> leave > >>> the average reader even more confused. > >>> > >>> -- > >>> Dean > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Thu Sep 24 08:49:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D643A679F for ; Thu, 24 Sep 2009 08:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e16n8YD4ndsn for ; Thu, 24 Sep 2009 08:49:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B83CA3A62C1 for ; Thu, 24 Sep 2009 08:49:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8OFoKS22793; Thu, 24 Sep 2009 15:50:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Sep 2009 10:50:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> In-Reply-To: <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoxzpJ3WJP2FLpZQzKpW4UdSLDk8QAaloZgAoXTAbAAEFUrEAATWZ1wABPQ1uA= References: <4A5FAF4E.4030901@cisco.com><9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com><9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com><9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com><4AA6DEA7.7090403@nostrum.com><1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com><8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Shida Schubert" Cc: Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 15:49:25 -0000 So, your proposal is that we have a "mapped" tag and a "freephone" tag? Is this correct? Perhaps just having an explicit "label" (as opposed to a "tag") is the way to go. Perhaps us trying to make it more complicated than it really is ain't a good idea after all. The "label" would be a string that allows us to describe the=20 address. "mapped", "freephone", maybe others, would be the=20 values we would define.=20 Other views? > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, September 23, 2009 23:22 > To: Audet, Francois (SC100:3055); Shida Schubert > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean=20 > Willis; Elwell, John; Keith Drage > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 23 September 2009 22:08 > > To: Elwell, John; Shida Schubert > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis;=20 > > Elwell, John; Keith Drage > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > > Can you give me an example of how the tags would look like? > [JRE] Without an explicit indication of freephone, all URIs=20 > from B onwards would be tagged as mapped, except E, which is=20 > registered contact. So without the explicit indication of=20 > freephone, how does the UAS know which is the freephone number? >=20 > >=20 > > Also, and you clarify what you mean by "forward" vs "resolve"? > >=20 > > I am assuming you are using "forward" in the traditional=20 > "telephony"=20 > > way, i.e., it is retargeted to another user, as opposed to "request=20 > > forwarding" which what you used for "resolving". Is this correct? > [JRE] Yes. >=20 > John >=20 >=20 > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, September 23, 2009 06:24 > > > To: Audet, Francois (SC100:3055); Shida Schubert > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis;=20 > > > Elwell, John; Keith Drage > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > > If we want to find specific things like freephone=20 > numbers, I think=20 > > > they do need to be explicitly marked, perhaps along the=20 > lines that=20 > > > Shida has suggested. > > > - Example 1: Call from A to B, which is forwarded to freephone=20 > > > number C, which resolves to D, which resolves to > > contact E. > > > - Example 2: Call from A to freephone number B, which=20 > resolves to C,=20 > > > which is then forwarded to D, which resolves to contact E. > > >=20 > > > These two examples illustrate that the freephone URI=20 > cannot be found=20 > > > at any fixed place in the sequence, so explicit marking=20 > would seem=20 > > > to be necessary. > > >=20 > > > John > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > > > > Sent: 10 September 2009 18:06 > > > > To: Shida Schubert > > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > > Dean Willis; > > > > Elwell, John; Keith Drage > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > >=20 > > > > Ok, thanks. > > > >=20 > > > > Let's wait for more input on this before we go for another > > > rev of the > > > > draft. > > > >=20 > > > > > -----Original Message----- > > > > > From: Shida Schubert [mailto:shida@ntt-at.com] > > > > > Sent: Wednesday, September 09, 2009 21:24 > > > > > To: Audet, Francois (SC100:3055) > > > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; > > > Hadriel Kaplan; > > > > > Dean Willis; Elwell, John; Keith Drage > > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > >=20 > > > > >=20 > > > > > I think the following could work for > > > Freephone(toll-free), AFAIK > > > > > all is needed for freephone was the mp tag and some=20 > guidance on=20 > > > > > where to look for a toll-free. > > > > >=20 > > > > > I believe that solving the problem of toll-free is really=20 > > > > > determining the current target of the request, which I > > believe is > > > > > what mp is trying to address. Generally if the incoming > > > request is > > > > > delivered via toll-free, then an entry before the last > > > mp(mapped-to) > > > > > is likely to be a toll-free number (mapped-from). > > > > >=20 > > > > > Although, without globally deterministic way to mark the > > > toll-free, > > > > > it's hard for it to work across countries as different > > countries > > > > > have different toll-free prefixes. > > > > > (Here in Japan, it's 0120-xxx and not 1-800). > > > > >=20 > > > > > We could though, possibly define a service URN or > > some tags for > > > > > typical services that are out there and tag HI-entry > > representing > > > > > such service with service URN that we define. > > > > >=20 > > > > > History-Info: =20 > > > > > < > > > > > sip:DirectoryAssistance > > > > > = @example.com>;index=3D1;service=3Durn:service:directory-assistance > > > > > History-Info:=20 > > > ;index=3D1.1;mp=3D1 > > > > > History-Info: = ;index=3D1.1.1;rc=3D1 > > > > > History-Info: = ;index=3D1.1.2;rc=3D2 > > > > >=20 > > > > > Regards > > > > > Shida > > > > >=20 > > > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > > > > >=20 > > > > > > I guess the summary is that we are kind of stalled on > > > some of the > > > > > > issues, in particular the aor tag issue. It seems that a > > > > > significant > > > > > > fraction of people do not believe that an AOR is > > deterministic > > > > > > construct that is worthy of being tagged as such. > > > > > > > > > > > > In my background (which is an Enterprise software/telephony=20 > > > > > > background), "users" have accounts. An AOR is the series of > > > > > addresses > > > > > > corresponding to these accounts, along with any aliases > > > > > (such as phone > > > > > > numbers expressed in SIP/TEL format). To me, AORs are not > > > > > this fluffy > > > > > > concept that others on the list have made it up to be. > > > > > > > > > > > > But in any case, I don't think we'll be able to reach a > > > > > concensus on > > > > > > it. > > > > > > > > > > > > I believe that we need to step back and find a different > > > > > way to skin > > > > > > this cat. > > > > > > > > > > > > Going back to the requirements of WHAT we are really trying > > > > > to solve > > > > > > at the > > > > > > UAS: > > > > > > > > > > > > 1) Tagging the last address (including parameters) that > > > > was used in > > > > > > a Request-URI before being replaced by the Contact. > > > > > > i.e., the target-uri problem > > > > > > 1a) It has been argued that sometimes with the > > > > > target-uri problem > > > > > > you may actually be looking for the first > > > address (and > > > > > > parameters) > > > > > > as opposed to the last one. > > > > > > > > > > > > 2) Tagging addresses that represents a DIFFERENT > > > > user/resource, as a > > > > > > result of re-targeting. > > > > > > i.e., the re-targeting problem (voicemail, IVR, etc.) > > > > > > > > > > > > We could potentially solve those two by having tags for > > > > > "mapped" and > > > > > > "contacts", and use a pointer to the index of what it is > > > > > mapped from > > > > > > (I guess we could do forward pointing instead of backward > > > > pointing, > > > > > > but then forking would be more cumbersome). > > > > > > > > > > > > Having the tag pointing to the index would remove ambiguity > > > > > if entries > > > > > > are removed by a proxy, etc. > > > > > > > > > > > > So, if I take a specific example of a call to bob being > > > > > redirected to > > > > > > carol, the HI would look like > > > > > > this: > > > > > > > > > > > > History-Info: ;index=3D1; > > > > > > History-Info: = ;\ > > > > > > index=3D1.1;rc=3D1 > > > > > > History-Info: ;index=3D2;mp=3D1 > > > > > > History-Info: ;index=3D2.1;rc=3D2 > > > > > > > > > > > > For problem 1 (target-uri), the UAS would look at the > > > last rc tag > > > > > > which is it's registered contact, and see what it points > > > > to (i.e., > > > > > > index 2). > > > > > > Index 2 is therefore > > > > > > the last target-uri. > > > > > > > > > > > > For problem 2 (redirection), the UAS looks for the last > > > > mp tag (it > > > > > > points to index 1). > > > > > > Index 1 (bob) is therefore the "redirecting" number.=20 > > > > Alternatively, > > > > > > the UAS may look for the FIRST retargeting (many voicemail > > > > > work with > > > > > > the first one). > > > > > > > > > > > > Anyways, this is just brainstorming (and it notably doesn't > > > > > solve - I > > > > > > think - the Freephone/1-800 number problem). > > > > > > > > > > > > Ideas? > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Adam Roach [mailto:adam@nostrum.com] > > > > > >> Sent: Tuesday, September 08, 2009 15:46 > > > > > >> To: sipcore@ietf.org > > > > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith > > > > Drage; Jon > > > > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; > > > > Dean Willis > > > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > > >> > > > > > >> Just a quick reminder that we discussed this vigorously in > > > > > Stockholm > > > > > >> without reaching any conclusion. To help spur things > > > > > along, here's a > > > > > >> summary of the arguments made during that discussion: > > > > > >> > > > > > >> > > > > > >>=20 > > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > > > > > >> 201:%20AOR%20tag > > > > > >> > > > > > >> Please resume discussion on the list, and see if we can > > > > reach any > > > > > >> sort of rough agreement. > > > > > >> > > > > > >> /a > > > > > >> > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > >=20 > > > > >=20 > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > >=20 > > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Thu Sep 24 11:26:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66C63A67BD for ; Thu, 24 Sep 2009 11:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=1.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN789+TwlM11 for ; Thu, 24 Sep 2009 11:26:10 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 9693928C134 for ; Thu, 24 Sep 2009 11:26:09 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so417973eye.51 for ; Thu, 24 Sep 2009 11:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=W1VZHgj7ZAngKjWjyrGpHQ7qg2JUEf2O4ZjFy6snaKc=; b=UZRhgj0RGl5Xh2NszskIiVQI5lT2C4IRP+/LMi3TTEZZcZ1l1CPwFgC/ocCpp3Ssuo 59mx315BUzTzxrSv4IxkN8SktHJ1ARMujy4zmVqrGK6cwQhHUuLaPi+JVMjAPbjttQ32 +uHNKZN+CIaN9ESVTho51uUwgLdA+yibT7qYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=kV1AyCAVo7vpPEnjlQG6Az6Yw9K10FSutNws/s8/9kTwDKj3FANrHca51lSRkErjBI xZ+vZI/k1eJcGX5Ixn+kfzG2KShryr1fcw3mgJSAxNbfxc2Xe0mHyiNn1ZNScaCWBwsx nrP0Rjm1Z6eWf7CfewZHW2W8KVwg9GNnnuyDs= MIME-Version: 1.0 Received: by 10.211.146.31 with SMTP id y31mr7912650ebn.72.1253816835250; Thu, 24 Sep 2009 11:27:15 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> Date: Thu, 24 Sep 2009 20:27:15 +0200 Message-ID: <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet , "Elwell, John" , Shida Schubert , Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:26:11 -0000 I thought 4244bis was to be about generic mechanism. Findin g the adressed target may result in obtaining the Freephone number, but also any other addressed target like for example a premium number. However a freephone tag is service specific. Im surprised we are looping back i thought we passed that stage. /hans erik 2009/9/24, Francois Audet : > So, your proposal is that we have a "mapped" tag and a "freephone" tag? > > Is this correct? > > Perhaps just having an explicit "label" (as opposed to a "tag") is the > way to go. Perhaps us trying to make it more complicated than it really > is ain't a good idea after all. > > The "label" would be a string that allows us to describe the > address. "mapped", "freephone", maybe others, would be the > values we would define. > > Other views? > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Wednesday, September 23, 2009 23:22 >> To: Audet, Francois (SC100:3055); Shida Schubert >> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean >> Willis; Elwell, John; Keith Drage >> Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> >> >> >> > -----Original Message----- >> > From: Francois Audet [mailto:audet@nortel.com] >> > Sent: 23 September 2009 22:08 >> > To: Elwell, John; Shida Schubert >> > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; >> > Elwell, John; Keith Drage >> > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> > >> > Can you give me an example of how the tags would look like? >> [JRE] Without an explicit indication of freephone, all URIs >> from B onwards would be tagged as mapped, except E, which is >> registered contact. So without the explicit indication of >> freephone, how does the UAS know which is the freephone number? >> >> > >> > Also, and you clarify what you mean by "forward" vs "resolve"? >> > >> > I am assuming you are using "forward" in the traditional >> "telephony" >> > way, i.e., it is retargeted to another user, as opposed to "request >> > forwarding" which what you used for "resolving". Is this correct? >> [JRE] Yes. >> >> John >> >> >> > >> > > -----Original Message----- >> > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> > > Sent: Wednesday, September 23, 2009 06:24 >> > > To: Audet, Francois (SC100:3055); Shida Schubert >> > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> Dean Willis; >> > > Elwell, John; Keith Drage >> > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> > > >> > > If we want to find specific things like freephone >> numbers, I think >> > > they do need to be explicitly marked, perhaps along the >> lines that >> > > Shida has suggested. >> > > - Example 1: Call from A to B, which is forwarded to freephone >> > > number C, which resolves to D, which resolves to >> > contact E. >> > > - Example 2: Call from A to freephone number B, which >> resolves to C, >> > > which is then forwarded to D, which resolves to contact E. >> > > >> > > These two examples illustrate that the freephone URI >> cannot be found >> > > at any fixed place in the sequence, so explicit marking >> would seem >> > > to be necessary. >> > > >> > > John >> > > >> > > >> > > > -----Original Message----- >> > > > From: sipcore-bounces@ietf.org >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet >> > > > Sent: 10 September 2009 18:06 >> > > > To: Shida Schubert >> > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> > Dean Willis; >> > > > Elwell, John; Keith Drage >> > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> > > > >> > > > Ok, thanks. >> > > > >> > > > Let's wait for more input on this before we go for another >> > > rev of the >> > > > draft. >> > > > >> > > > > -----Original Message----- >> > > > > From: Shida Schubert [mailto:shida@ntt-at.com] >> > > > > Sent: Wednesday, September 09, 2009 21:24 >> > > > > To: Audet, Francois (SC100:3055) >> > > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; >> > > Hadriel Kaplan; >> > > > > Dean Willis; Elwell, John; Keith Drage >> > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> > > > > >> > > > > >> > > > > I think the following could work for >> > > Freephone(toll-free), AFAIK >> > > > > all is needed for freephone was the mp tag and some >> guidance on >> > > > > where to look for a toll-free. >> > > > > >> > > > > I believe that solving the problem of toll-free is really >> > > > > determining the current target of the request, which I >> > believe is >> > > > > what mp is trying to address. Generally if the incoming >> > > request is >> > > > > delivered via toll-free, then an entry before the last >> > > mp(mapped-to) >> > > > > is likely to be a toll-free number (mapped-from). >> > > > > >> > > > > Although, without globally deterministic way to mark the >> > > toll-free, >> > > > > it's hard for it to work across countries as different >> > countries >> > > > > have different toll-free prefixes. >> > > > > (Here in Japan, it's 0120-xxx and not 1-800). >> > > > > >> > > > > We could though, possibly define a service URN or >> > some tags for >> > > > > typical services that are out there and tag HI-entry >> > representing >> > > > > such service with service URN that we define. >> > > > > >> > > > > History-Info: >> > > > > < >> > > > > sip:DirectoryAssistance >> > > > > @example.com>;index=3D1;service=3Durn:service:directory-assistan= ce >> > > > > History-Info: >> > > ;index=3D1.1;mp=3D1 >> > > > > History-Info: ;index=3D1.1.1;rc=3D1 >> > > > > History-Info: ;index=3D1.1.2;rc=3D2 >> > > > > >> > > > > Regards >> > > > > Shida >> > > > > >> > > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: >> > > > > >> > > > > > I guess the summary is that we are kind of stalled on >> > > some of the >> > > > > > issues, in particular the aor tag issue. It seems that a >> > > > > significant >> > > > > > fraction of people do not believe that an AOR is >> > deterministic >> > > > > > construct that is worthy of being tagged as such. >> > > > > > >> > > > > > In my background (which is an Enterprise software/telephony >> > > > > > background), "users" have accounts. An AOR is the series of >> > > > > addresses >> > > > > > corresponding to these accounts, along with any aliases >> > > > > (such as phone >> > > > > > numbers expressed in SIP/TEL format). To me, AORs are not >> > > > > this fluffy >> > > > > > concept that others on the list have made it up to be. >> > > > > > >> > > > > > But in any case, I don't think we'll be able to reach a >> > > > > concensus on >> > > > > > it. >> > > > > > >> > > > > > I believe that we need to step back and find a different >> > > > > way to skin >> > > > > > this cat. >> > > > > > >> > > > > > Going back to the requirements of WHAT we are really trying >> > > > > to solve >> > > > > > at the >> > > > > > UAS: >> > > > > > >> > > > > > 1) Tagging the last address (including parameters) that >> > > > was used in >> > > > > > a Request-URI before being replaced by the Contact. >> > > > > > i.e., the target-uri problem >> > > > > > 1a) It has been argued that sometimes with the >> > > > > target-uri problem >> > > > > > you may actually be looking for the first >> > > address (and >> > > > > > parameters) >> > > > > > as opposed to the last one. >> > > > > > >> > > > > > 2) Tagging addresses that represents a DIFFERENT >> > > > user/resource, as a >> > > > > > result of re-targeting. >> > > > > > i.e., the re-targeting problem (voicemail, IVR, etc.) >> > > > > > >> > > > > > We could potentially solve those two by having tags for >> > > > > "mapped" and >> > > > > > "contacts", and use a pointer to the index of what it is >> > > > > mapped from >> > > > > > (I guess we could do forward pointing instead of backward >> > > > pointing, >> > > > > > but then forking would be more cumbersome). >> > > > > > >> > > > > > Having the tag pointing to the index would remove ambiguity >> > > > > if entries >> > > > > > are removed by a proxy, etc. >> > > > > > >> > > > > > So, if I take a specific example of a call to bob being >> > > > > redirected to >> > > > > > carol, the HI would look like >> > > > > > this: >> > > > > > >> > > > > > History-Info: ;index=3D1; >> > > > > > History-Info: = ;\ >> > > > > > index=3D1.1;rc=3D1 >> > > > > > History-Info: ;index=3D2;mp=3D1 >> > > > > > History-Info: ;index=3D2.1;rc=3D2 >> > > > > > >> > > > > > For problem 1 (target-uri), the UAS would look at the >> > > last rc tag >> > > > > > which is it's registered contact, and see what it points >> > > > to (i.e., >> > > > > > index 2). >> > > > > > Index 2 is therefore >> > > > > > the last target-uri. >> > > > > > >> > > > > > For problem 2 (redirection), the UAS looks for the last >> > > > mp tag (it >> > > > > > points to index 1). >> > > > > > Index 1 (bob) is therefore the "redirecting" number. >> > > > Alternatively, >> > > > > > the UAS may look for the FIRST retargeting (many voicemail >> > > > > work with >> > > > > > the first one). >> > > > > > >> > > > > > Anyways, this is just brainstorming (and it notably doesn't >> > > > > solve - I >> > > > > > think - the Freephone/1-800 number problem). >> > > > > > >> > > > > > Ideas? >> > > > > > >> > > > > > >> > > > > >> -----Original Message----- >> > > > > >> From: Adam Roach [mailto:adam@nostrum.com] >> > > > > >> Sent: Tuesday, September 08, 2009 15:46 >> > > > > >> To: sipcore@ietf.org >> > > > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith >> > > > Drage; Jon >> > > > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; >> > > > Dean Willis >> > > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> > > > > >> >> > > > > >> Just a quick reminder that we discussed this vigorously in >> > > > > Stockholm >> > > > > >> without reaching any conclusion. To help spur things >> > > > > along, here's a >> > > > > >> summary of the arguments made during that discussion: >> > > > > >> >> > > > > >> >> > > > > >> >> > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% >> > > > > >> 201:%20AOR%20tag >> > > > > >> >> > > > > >> Please resume discussion on the list, and see if we can >> > > > reach any >> > > > > >> sort of rough agreement. >> > > > > >> >> > > > > >> /a >> > > > > >> >> > > > > > _______________________________________________ >> > > > > > sipcore mailing list >> > > > > > sipcore@ietf.org >> > > > > > https://www.ietf.org/mailman/listinfo/sipcore >> > > > > >> > > > > >> > > > _______________________________________________ >> > > > sipcore mailing list >> > > > sipcore@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/sipcore >> > > > >> > > >> > >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --=20 Von meinen Mobilger=E4t aus gesendet /Hans Erik van Elburg From AUDET@nortel.com Thu Sep 24 11:37:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848333A6AA3 for ; Thu, 24 Sep 2009 11:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Vl5h9Kzy7F for ; Thu, 24 Sep 2009 11:37:14 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 933863A6967 for ; Thu, 24 Sep 2009 11:37:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8OIcCS14371; Thu, 24 Sep 2009 18:38:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Sep 2009 13:37:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: Aco9RKYztE7ybbJLRKOGsJM7CkYxGwAALNiQ References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> <4AA6DEA7.7090403@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Elwell, John" , "Shida Schubert" , "Jonathan Lennox" , , "Hadriel Kaplan" , "Dean Willis" , "Elwell, John" , "Keith Drage" Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:37:15 -0000 Oh, I'm not surprised at all... This is the IETF after all! :-)=20 In any case, it was pretty loud in clear in Stockholm that people didn't = like the idea of using an AOR tag.=20 The mapped tag would be quite generic. It's really "freephone" that = seems to be a weird corner case that people seem to think it's worth solving.=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: Thursday, September 24, 2009 11:27 > To: Audet, Francois (SC100:3055); Elwell, John; Shida=20 > Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis; Elwell, John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > I thought 4244bis was to be about generic mechanism. Findin g=20 > the adressed target may result in obtaining the Freephone=20 > number, but also any other addressed target like for example=20 > a premium number. However a freephone tag is service=20 > specific. Im surprised we are looping back i thought we=20 > passed that stage. > /hans erik >=20 > 2009/9/24, Francois Audet : > > So, your proposal is that we have a "mapped" tag and a=20 > "freephone" tag? > > > > Is this correct? > > > > Perhaps just having an explicit "label" (as opposed to a=20 > "tag") is the=20 > > way to go. Perhaps us trying to make it more complicated than it=20 > > really is ain't a good idea after all. > > > > The "label" would be a string that allows us to describe=20 > the address.=20 > > "mapped", "freephone", maybe others, would be the values we would=20 > > define. > > > > Other views? > > > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Wednesday, September 23, 2009 23:22 > >> To: Audet, Francois (SC100:3055); Shida Schubert > >> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis;=20 > >> Elwell, John; Keith Drage > >> Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >> > >> > >> > >> > -----Original Message----- > >> > From: Francois Audet [mailto:audet@nortel.com] > >> > Sent: 23 September 2009 22:08 > >> > To: Elwell, John; Shida Schubert > >> > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis;=20 > >> > Elwell, John; Keith Drage > >> > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >> > > >> > Can you give me an example of how the tags would look like? > >> [JRE] Without an explicit indication of freephone, all URIs from B=20 > >> onwards would be tagged as mapped, except E, which is registered=20 > >> contact. So without the explicit indication of freephone, how does=20 > >> the UAS know which is the freephone number? > >> > >> > > >> > Also, and you clarify what you mean by "forward" vs "resolve"? > >> > > >> > I am assuming you are using "forward" in the traditional > >> "telephony" > >> > way, i.e., it is retargeted to another user, as opposed=20 > to "request=20 > >> > forwarding" which what you used for "resolving". Is this correct? > >> [JRE] Yes. > >> > >> John > >> > >> > >> > > >> > > -----Original Message----- > >> > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> > > Sent: Wednesday, September 23, 2009 06:24 > >> > > To: Audet, Francois (SC100:3055); Shida Schubert > >> > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> Dean Willis; > >> > > Elwell, John; Keith Drage > >> > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >> > > > >> > > If we want to find specific things like freephone > >> numbers, I think > >> > > they do need to be explicitly marked, perhaps along the > >> lines that > >> > > Shida has suggested. > >> > > - Example 1: Call from A to B, which is forwarded to freephone=20 > >> > > number C, which resolves to D, which resolves to > >> > contact E. > >> > > - Example 2: Call from A to freephone number B, which > >> resolves to C, > >> > > which is then forwarded to D, which resolves to contact E. > >> > > > >> > > These two examples illustrate that the freephone URI > >> cannot be found > >> > > at any fixed place in the sequence, so explicit marking > >> would seem > >> > > to be necessary. > >> > > > >> > > John > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: sipcore-bounces@ietf.org > >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > >> > > > Sent: 10 September 2009 18:06 > >> > > > To: Shida Schubert > >> > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> > Dean Willis; > >> > > > Elwell, John; Keith Drage > >> > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > > > > >> > > > Ok, thanks. > >> > > > > >> > > > Let's wait for more input on this before we go for another > >> > > rev of the > >> > > > draft. > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Shida Schubert [mailto:shida@ntt-at.com] > >> > > > > Sent: Wednesday, September 09, 2009 21:24 > >> > > > > To: Audet, Francois (SC100:3055) > >> > > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; > >> > > Hadriel Kaplan; > >> > > > > Dean Willis; Elwell, John; Keith Drage > >> > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > > > > > >> > > > > > >> > > > > I think the following could work for > >> > > Freephone(toll-free), AFAIK > >> > > > > all is needed for freephone was the mp tag and some > >> guidance on > >> > > > > where to look for a toll-free. > >> > > > > > >> > > > > I believe that solving the problem of toll-free=20 > is really=20 > >> > > > > determining the current target of the request, which I > >> > believe is > >> > > > > what mp is trying to address. Generally if the incoming > >> > > request is > >> > > > > delivered via toll-free, then an entry before the last > >> > > mp(mapped-to) > >> > > > > is likely to be a toll-free number (mapped-from). > >> > > > > > >> > > > > Although, without globally deterministic way to mark the > >> > > toll-free, > >> > > > > it's hard for it to work across countries as different > >> > countries > >> > > > > have different toll-free prefixes. > >> > > > > (Here in Japan, it's 0120-xxx and not 1-800). > >> > > > > > >> > > > > We could though, possibly define a service URN or > >> > some tags for > >> > > > > typical services that are out there and tag HI-entry > >> > representing > >> > > > > such service with service URN that we define. > >> > > > > > >> > > > > History-Info: > >> > > > > < > >> > > > > sip:DirectoryAssistance > >> > > > >=20 > @example.com>;index=3D1;service=3Durn:service:directory-assistance > >> > > > > History-Info: > >> > > ;index=3D1.1;mp=3D1 > >> > > > > History-Info:=20 > ;index=3D1.1.1;rc=3D1 > >> > > > > History-Info: = ;index=3D1.1.2;rc=3D2 > >> > > > > > >> > > > > Regards > >> > > > > Shida > >> > > > > > >> > > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > >> > > > > > >> > > > > > I guess the summary is that we are kind of stalled on > >> > > some of the > >> > > > > > issues, in particular the aor tag issue. It seems that a > >> > > > > significant > >> > > > > > fraction of people do not believe that an AOR is > >> > deterministic > >> > > > > > construct that is worthy of being tagged as such. > >> > > > > > > >> > > > > > In my background (which is an Enterprise=20 > software/telephony=20 > >> > > > > > background), "users" have accounts. An AOR is=20 > the series of > >> > > > > addresses > >> > > > > > corresponding to these accounts, along with any aliases > >> > > > > (such as phone > >> > > > > > numbers expressed in SIP/TEL format). To me, AORs are not > >> > > > > this fluffy > >> > > > > > concept that others on the list have made it up to be. > >> > > > > > > >> > > > > > But in any case, I don't think we'll be able to reach a > >> > > > > concensus on > >> > > > > > it. > >> > > > > > > >> > > > > > I believe that we need to step back and find a different > >> > > > > way to skin > >> > > > > > this cat. > >> > > > > > > >> > > > > > Going back to the requirements of WHAT we are=20 > really trying > >> > > > > to solve > >> > > > > > at the > >> > > > > > UAS: > >> > > > > > > >> > > > > > 1) Tagging the last address (including parameters) that > >> > > > was used in > >> > > > > > a Request-URI before being replaced by the Contact. > >> > > > > > i.e., the target-uri problem > >> > > > > > 1a) It has been argued that sometimes with the > >> > > > > target-uri problem > >> > > > > > you may actually be looking for the first > >> > > address (and > >> > > > > > parameters) > >> > > > > > as opposed to the last one. > >> > > > > > > >> > > > > > 2) Tagging addresses that represents a DIFFERENT > >> > > > user/resource, as a > >> > > > > > result of re-targeting. > >> > > > > > i.e., the re-targeting problem (voicemail, IVR, etc.) > >> > > > > > > >> > > > > > We could potentially solve those two by having tags for > >> > > > > "mapped" and > >> > > > > > "contacts", and use a pointer to the index of what it is > >> > > > > mapped from > >> > > > > > (I guess we could do forward pointing instead of backward > >> > > > pointing, > >> > > > > > but then forking would be more cumbersome). > >> > > > > > > >> > > > > > Having the tag pointing to the index would=20 > remove ambiguity > >> > > > > if entries > >> > > > > > are removed by a proxy, etc. > >> > > > > > > >> > > > > > So, if I take a specific example of a call to bob being > >> > > > > redirected to > >> > > > > > carol, the HI would look like > >> > > > > > this: > >> > > > > > > >> > > > > > History-Info: ;index=3D1; > >> > > > > > History-Info:=20 > ;\ > >> > > > > > index=3D1.1;rc=3D1 > >> > > > > > History-Info: = ;index=3D2;mp=3D1 > >> > > > > > History-Info: = ;index=3D2.1;rc=3D2 > >> > > > > > > >> > > > > > For problem 1 (target-uri), the UAS would look at the > >> > > last rc tag > >> > > > > > which is it's registered contact, and see what it points > >> > > > to (i.e., > >> > > > > > index 2). > >> > > > > > Index 2 is therefore > >> > > > > > the last target-uri. > >> > > > > > > >> > > > > > For problem 2 (redirection), the UAS looks for the last > >> > > > mp tag (it > >> > > > > > points to index 1). > >> > > > > > Index 1 (bob) is therefore the "redirecting" number. > >> > > > Alternatively, > >> > > > > > the UAS may look for the FIRST retargeting (many=20 > voicemail > >> > > > > work with > >> > > > > > the first one). > >> > > > > > > >> > > > > > Anyways, this is just brainstorming (and it=20 > notably doesn't > >> > > > > solve - I > >> > > > > > think - the Freephone/1-800 number problem). > >> > > > > > > >> > > > > > Ideas? > >> > > > > > > >> > > > > > > >> > > > > >> -----Original Message----- > >> > > > > >> From: Adam Roach [mailto:adam@nostrum.com] > >> > > > > >> Sent: Tuesday, September 08, 2009 15:46 > >> > > > > >> To: sipcore@ietf.org > >> > > > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith > >> > > > Drage; Jon > >> > > > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; > >> > > > Dean Willis > >> > > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > > > > >> > >> > > > > >> Just a quick reminder that we discussed this=20 > vigorously in > >> > > > > Stockholm > >> > > > > >> without reaching any conclusion. To help spur things > >> > > > > along, here's a > >> > > > > >> summary of the arguments made during that discussion: > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > >> > > > > >> 201:%20AOR%20tag > >> > > > > >> > >> > > > > >> Please resume discussion on the list, and see if we can > >> > > > reach any > >> > > > > >> sort of rough agreement. > >> > > > > >> > >> > > > > >> /a > >> > > > > >> > >> > > > > > _______________________________________________ > >> > > > > > sipcore mailing list > >> > > > > > sipcore@ietf.org > >> > > > > > https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > > >> > > > > > >> > > > _______________________________________________ > >> > > > sipcore mailing list > >> > > > sipcore@ietf.org > >> > > > https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > >> > > > >> > > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > -- > Von meinen Mobilger=E4t aus gesendet >=20 > /Hans Erik van Elburg >=20 From ietf.hanserik@gmail.com Thu Sep 24 11:46:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43EF28C168 for ; Thu, 24 Sep 2009 11:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+9iNeEgFA6q for ; Thu, 24 Sep 2009 11:46:38 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9608C28C114 for ; Thu, 24 Sep 2009 11:46:37 -0700 (PDT) Received: by ewy28 with SMTP id 28so2540267ewy.42 for ; Thu, 24 Sep 2009 11:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IbsFjmP9DlvR1rTynV9Z/B/J8a/v6gmSdTs3lgul/N4=; b=S1NAihIjGbSd39y187/zWDkwqvRQuV7Vf2yXM30B2vFaq4IKtGCsU8dFK91a3+ceU1 3IgYjJ1x459zJXxEhuxKk+8Hkv05RTs2O/Y4YYyKJbolENz+L1HXaz1BApQYfFQdrXki i1Zfc9WxGEomdmFG4xL7IpEOqcbCBiV62oap0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=J6UW+RcbiaE7i4GTqs5i7AMR0flv3WbZg63y0JxHW91bNdsk3pl0a+kZnmI+sYbz0B k9WPCWyB0vdTlTc866k/T+rnyYb7+ym6qAK8sXq2W0RdnXCVnmg9sIyJQ5GIzplVtiBH kTBFqG5ehJd+ZOXCzFt/SYPx9FfWyY7ae7ef0= MIME-Version: 1.0 Received: by 10.211.147.10 with SMTP id z10mr4485648ebn.61.1253818062118; Thu, 24 Sep 2009 11:47:42 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> Date: Thu, 24 Sep 2009 20:47:42 +0200 Message-ID: <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet , "Elwell, John" , Shida Schubert , Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:46:39 -0000 Yes got that, but that does not justify a service specific tag in 4244bis. /hans erik 2009/9/24, Francois Audet : > Oh, I'm not surprised at all... This is the IETF after all! > :-) > > In any case, it was pretty loud in clear in Stockholm that people didn't > like > the idea of using an AOR tag. > > The mapped tag would be quite generic. It's really "freephone" that seems= to > be a weird corner case that people seem to think it's worth solving. > > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Thursday, September 24, 2009 11:27 >> To: Audet, Francois (SC100:3055); Elwell, John; Shida >> Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> Dean Willis; Elwell, John; Keith Drage >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> I thought 4244bis was to be about generic mechanism. Findin g >> the adressed target may result in obtaining the Freephone >> number, but also any other addressed target like for example >> a premium number. However a freephone tag is service >> specific. Im surprised we are looping back i thought we >> passed that stage. >> /hans erik >> >> 2009/9/24, Francois Audet : >> > So, your proposal is that we have a "mapped" tag and a >> "freephone" tag? >> > >> > Is this correct? >> > >> > Perhaps just having an explicit "label" (as opposed to a >> "tag") is the >> > way to go. Perhaps us trying to make it more complicated than it >> > really is ain't a good idea after all. >> > >> > The "label" would be a string that allows us to describe >> the address. >> > "mapped", "freephone", maybe others, would be the values we would >> > define. >> > >> > Other views? >> > >> >> -----Original Message----- >> >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >> Sent: Wednesday, September 23, 2009 23:22 >> >> To: Audet, Francois (SC100:3055); Shida Schubert >> >> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> Dean Willis; >> >> Elwell, John; Keith Drage >> >> Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> >> >> >> >> >> >> >> > -----Original Message----- >> >> > From: Francois Audet [mailto:audet@nortel.com] >> >> > Sent: 23 September 2009 22:08 >> >> > To: Elwell, John; Shida Schubert >> >> > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> Dean Willis; >> >> > Elwell, John; Keith Drage >> >> > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> >> > >> >> > Can you give me an example of how the tags would look like? >> >> [JRE] Without an explicit indication of freephone, all URIs from B >> >> onwards would be tagged as mapped, except E, which is registered >> >> contact. So without the explicit indication of freephone, how does >> >> the UAS know which is the freephone number? >> >> >> >> > >> >> > Also, and you clarify what you mean by "forward" vs "resolve"? >> >> > >> >> > I am assuming you are using "forward" in the traditional >> >> "telephony" >> >> > way, i.e., it is retargeted to another user, as opposed >> to "request >> >> > forwarding" which what you used for "resolving". Is this correct? >> >> [JRE] Yes. >> >> >> >> John >> >> >> >> >> >> > >> >> > > -----Original Message----- >> >> > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >> > > Sent: Wednesday, September 23, 2009 06:24 >> >> > > To: Audet, Francois (SC100:3055); Shida Schubert >> >> > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> >> Dean Willis; >> >> > > Elwell, John; Keith Drage >> >> > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> >> > > >> >> > > If we want to find specific things like freephone >> >> numbers, I think >> >> > > they do need to be explicitly marked, perhaps along the >> >> lines that >> >> > > Shida has suggested. >> >> > > - Example 1: Call from A to B, which is forwarded to freephone >> >> > > number C, which resolves to D, which resolves to >> >> > contact E. >> >> > > - Example 2: Call from A to freephone number B, which >> >> resolves to C, >> >> > > which is then forwarded to D, which resolves to contact E. >> >> > > >> >> > > These two examples illustrate that the freephone URI >> >> cannot be found >> >> > > at any fixed place in the sequence, so explicit marking >> >> would seem >> >> > > to be necessary. >> >> > > >> >> > > John >> >> > > >> >> > > >> >> > > > -----Original Message----- >> >> > > > From: sipcore-bounces@ietf.org >> >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet >> >> > > > Sent: 10 September 2009 18:06 >> >> > > > To: Shida Schubert >> >> > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> >> > Dean Willis; >> >> > > > Elwell, John; Keith Drage >> >> > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> > > > >> >> > > > Ok, thanks. >> >> > > > >> >> > > > Let's wait for more input on this before we go for another >> >> > > rev of the >> >> > > > draft. >> >> > > > >> >> > > > > -----Original Message----- >> >> > > > > From: Shida Schubert [mailto:shida@ntt-at.com] >> >> > > > > Sent: Wednesday, September 09, 2009 21:24 >> >> > > > > To: Audet, Francois (SC100:3055) >> >> > > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; >> >> > > Hadriel Kaplan; >> >> > > > > Dean Willis; Elwell, John; Keith Drage >> >> > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> > > > > >> >> > > > > >> >> > > > > I think the following could work for >> >> > > Freephone(toll-free), AFAIK >> >> > > > > all is needed for freephone was the mp tag and some >> >> guidance on >> >> > > > > where to look for a toll-free. >> >> > > > > >> >> > > > > I believe that solving the problem of toll-free >> is really >> >> > > > > determining the current target of the request, which I >> >> > believe is >> >> > > > > what mp is trying to address. Generally if the incoming >> >> > > request is >> >> > > > > delivered via toll-free, then an entry before the last >> >> > > mp(mapped-to) >> >> > > > > is likely to be a toll-free number (mapped-from). >> >> > > > > >> >> > > > > Although, without globally deterministic way to mark the >> >> > > toll-free, >> >> > > > > it's hard for it to work across countries as different >> >> > countries >> >> > > > > have different toll-free prefixes. >> >> > > > > (Here in Japan, it's 0120-xxx and not 1-800). >> >> > > > > >> >> > > > > We could though, possibly define a service URN or >> >> > some tags for >> >> > > > > typical services that are out there and tag HI-entry >> >> > representing >> >> > > > > such service with service URN that we define. >> >> > > > > >> >> > > > > History-Info: >> >> > > > > < >> >> > > > > sip:DirectoryAssistance >> >> > > > > >> @example.com>;index=3D1;service=3Durn:service:directory-assistance >> >> > > > > History-Info: >> >> > > ;index=3D1.1;mp=3D1 >> >> > > > > History-Info: >> ;index=3D1.1.1;rc=3D1 >> >> > > > > History-Info: ;index=3D1.1.2;rc= =3D2 >> >> > > > > >> >> > > > > Regards >> >> > > > > Shida >> >> > > > > >> >> > > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: >> >> > > > > >> >> > > > > > I guess the summary is that we are kind of stalled on >> >> > > some of the >> >> > > > > > issues, in particular the aor tag issue. It seems that a >> >> > > > > significant >> >> > > > > > fraction of people do not believe that an AOR is >> >> > deterministic >> >> > > > > > construct that is worthy of being tagged as such. >> >> > > > > > >> >> > > > > > In my background (which is an Enterprise >> software/telephony >> >> > > > > > background), "users" have accounts. An AOR is >> the series of >> >> > > > > addresses >> >> > > > > > corresponding to these accounts, along with any aliases >> >> > > > > (such as phone >> >> > > > > > numbers expressed in SIP/TEL format). To me, AORs are not >> >> > > > > this fluffy >> >> > > > > > concept that others on the list have made it up to be. >> >> > > > > > >> >> > > > > > But in any case, I don't think we'll be able to reach a >> >> > > > > concensus on >> >> > > > > > it. >> >> > > > > > >> >> > > > > > I believe that we need to step back and find a different >> >> > > > > way to skin >> >> > > > > > this cat. >> >> > > > > > >> >> > > > > > Going back to the requirements of WHAT we are >> really trying >> >> > > > > to solve >> >> > > > > > at the >> >> > > > > > UAS: >> >> > > > > > >> >> > > > > > 1) Tagging the last address (including parameters) that >> >> > > > was used in >> >> > > > > > a Request-URI before being replaced by the Contact. >> >> > > > > > i.e., the target-uri problem >> >> > > > > > 1a) It has been argued that sometimes with the >> >> > > > > target-uri problem >> >> > > > > > you may actually be looking for the first >> >> > > address (and >> >> > > > > > parameters) >> >> > > > > > as opposed to the last one. >> >> > > > > > >> >> > > > > > 2) Tagging addresses that represents a DIFFERENT >> >> > > > user/resource, as a >> >> > > > > > result of re-targeting. >> >> > > > > > i.e., the re-targeting problem (voicemail, IVR, etc.) >> >> > > > > > >> >> > > > > > We could potentially solve those two by having tags for >> >> > > > > "mapped" and >> >> > > > > > "contacts", and use a pointer to the index of what it is >> >> > > > > mapped from >> >> > > > > > (I guess we could do forward pointing instead of backward >> >> > > > pointing, >> >> > > > > > but then forking would be more cumbersome). >> >> > > > > > >> >> > > > > > Having the tag pointing to the index would >> remove ambiguity >> >> > > > > if entries >> >> > > > > > are removed by a proxy, etc. >> >> > > > > > >> >> > > > > > So, if I take a specific example of a call to bob being >> >> > > > > redirected to >> >> > > > > > carol, the HI would look like >> >> > > > > > this: >> >> > > > > > >> >> > > > > > History-Info: ;index=3D1; >> >> > > > > > History-Info: >> ;\ >> >> > > > > > index=3D1.1;rc=3D1 >> >> > > > > > History-Info: ;index=3D2;mp=3D1 >> >> > > > > > History-Info: ;index=3D2.1;rc=3D2 >> >> > > > > > >> >> > > > > > For problem 1 (target-uri), the UAS would look at the >> >> > > last rc tag >> >> > > > > > which is it's registered contact, and see what it points >> >> > > > to (i.e., >> >> > > > > > index 2). >> >> > > > > > Index 2 is therefore >> >> > > > > > the last target-uri. >> >> > > > > > >> >> > > > > > For problem 2 (redirection), the UAS looks for the last >> >> > > > mp tag (it >> >> > > > > > points to index 1). >> >> > > > > > Index 1 (bob) is therefore the "redirecting" number. >> >> > > > Alternatively, >> >> > > > > > the UAS may look for the FIRST retargeting (many >> voicemail >> >> > > > > work with >> >> > > > > > the first one). >> >> > > > > > >> >> > > > > > Anyways, this is just brainstorming (and it >> notably doesn't >> >> > > > > solve - I >> >> > > > > > think - the Freephone/1-800 number problem). >> >> > > > > > >> >> > > > > > Ideas? >> >> > > > > > >> >> > > > > > >> >> > > > > >> -----Original Message----- >> >> > > > > >> From: Adam Roach [mailto:adam@nostrum.com] >> >> > > > > >> Sent: Tuesday, September 08, 2009 15:46 >> >> > > > > >> To: sipcore@ietf.org >> >> > > > > >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith >> >> > > > Drage; Jon >> >> > > > > >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; >> >> > > > Dean Willis >> >> > > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> > > > > >> >> >> > > > > >> Just a quick reminder that we discussed this >> vigorously in >> >> > > > > Stockholm >> >> > > > > >> without reaching any conclusion. To help spur things >> >> > > > > along, here's a >> >> > > > > >> summary of the arguments made during that discussion: >> >> > > > > >> >> >> > > > > >> >> >> > > > > >> >> >> > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% >> >> > > > > >> 201:%20AOR%20tag >> >> > > > > >> >> >> > > > > >> Please resume discussion on the list, and see if we can >> >> > > > reach any >> >> > > > > >> sort of rough agreement. >> >> > > > > >> >> >> > > > > >> /a >> >> > > > > >> >> >> > > > > > _______________________________________________ >> >> > > > > > sipcore mailing list >> >> > > > > > sipcore@ietf.org >> >> > > > > > https://www.ietf.org/mailman/listinfo/sipcore >> >> > > > > >> >> > > > > >> >> > > > _______________________________________________ >> >> > > > sipcore mailing list >> >> > > > sipcore@ietf.org >> >> > > > https://www.ietf.org/mailman/listinfo/sipcore >> >> > > > >> >> > > >> >> > >> >> >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> > >> >> -- >> Von meinen Mobilger=E4t aus gesendet >> >> /Hans Erik van Elburg >> > --=20 Von meinen Mobilger=E4t aus gesendet /Hans Erik van Elburg From AUDET@nortel.com Thu Sep 24 11:47:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F5228C176 for ; Thu, 24 Sep 2009 11:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPkVbc4GE1Gc for ; Thu, 24 Sep 2009 11:47:53 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7653728C13C for ; Thu, 24 Sep 2009 11:47:53 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n8OImq807135; Thu, 24 Sep 2009 18:48:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Sep 2009 13:48:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: Aco9R4GeAIwVLDZETIOWmO8Ljs1v0wAABMpA References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Elwell, John" , "Shida Schubert" , "Jonathan Lennox" , , "Hadriel Kaplan" , "Dean Willis" , "Elwell, John" , "Keith Drage" Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:47:54 -0000 Other idea? (I really don't care personally about "freephone"...)=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: Thursday, September 24, 2009 11:48 > To: Audet, Francois (SC100:3055); Elwell, John; Shida=20 > Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis; Elwell, John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > Yes got that, but that does not justify a service specific=20 > tag in 4244bis. > /hans erik >=20 From john.elwell@siemens-enterprise.com Thu Sep 24 12:52:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940FE3A68F7 for ; Thu, 24 Sep 2009 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKnoVNGusIU5 for ; Thu, 24 Sep 2009 12:52:00 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 48A633A68C8 for ; Thu, 24 Sep 2009 12:51:58 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n8OJr0qt031326; Thu, 24 Sep 2009 21:53:00 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n8OJqxi2022735; Thu, 24 Sep 2009 21:52:59 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.159]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 24 Sep 2009 21:52:58 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Francois Audet , Shida Schubert , Jonathan Lennox , "sipcore@ietf.org" , Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Date: Thu, 24 Sep 2009 21:52:58 +0200 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: Aco9R3+22Y7gveYBSLKozRrslvmRhwACFN9Q Message-ID: <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> In-Reply-To: <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:52:01 -0000 Just to be clear, I do not have a specific requirement for finding the free= phone number. I was merely pointing out that it seems very difficult to sol= ve using a generic mechanism. I think the latest proposal for just indicating mp or rc is more feasible t= han the earlier AOR-based proposal. Whether it is sufficiently robust (dete= rministic) I am not sure. John > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 24 September 2009 19:48 > To: Francois Audet; Elwell, John; Shida Schubert; Jonathan > Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; > Elwell, John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > Yes got that, but that does not justify a service specific > tag in 4244bis. > /hans erik > > 2009/9/24, Francois Audet : > > Oh, I'm not surprised at all... This is the IETF after all! > > :-) > > > > In any case, it was pretty loud in clear in Stockholm that > people didn't > > like > > the idea of using an AOR tag. > > > > The mapped tag would be quite generic. It's really > "freephone" that seems to > > be a weird corner case that people seem to think it's worth solving. > > > > > >> -----Original Message----- > >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > >> Sent: Thursday, September 24, 2009 11:27 > >> To: Audet, Francois (SC100:3055); Elwell, John; Shida > >> Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> Dean Willis; Elwell, John; Keith Drage > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > >> I thought 4244bis was to be about generic mechanism. Findin g > >> the adressed target may result in obtaining the Freephone > >> number, but also any other addressed target like for example > >> a premium number. However a freephone tag is service > >> specific. Im surprised we are looping back i thought we > >> passed that stage. > >> /hans erik > >> > >> 2009/9/24, Francois Audet : > >> > So, your proposal is that we have a "mapped" tag and a > >> "freephone" tag? > >> > > >> > Is this correct? > >> > > >> > Perhaps just having an explicit "label" (as opposed to a > >> "tag") is the > >> > way to go. Perhaps us trying to make it more complicated than it > >> > really is ain't a good idea after all. > >> > > >> > The "label" would be a string that allows us to describe > >> the address. > >> > "mapped", "freephone", maybe others, would be the values we would > >> > define. > >> > > >> > Other views? > >> > > >> >> -----Original Message----- > >> >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> >> Sent: Wednesday, September 23, 2009 23:22 > >> >> To: Audet, Francois (SC100:3055); Shida Schubert > >> >> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> Dean Willis; > >> >> Elwell, John; Keith Drage > >> >> Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >> >> > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: Francois Audet [mailto:audet@nortel.com] > >> >> > Sent: 23 September 2009 22:08 > >> >> > To: Elwell, John; Shida Schubert > >> >> > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> Dean Willis; > >> >> > Elwell, John; Keith Drage > >> >> > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >> >> > > >> >> > Can you give me an example of how the tags would look like? > >> >> [JRE] Without an explicit indication of freephone, all > URIs from B > >> >> onwards would be tagged as mapped, except E, which is registered > >> >> contact. So without the explicit indication of > freephone, how does > >> >> the UAS know which is the freephone number? > >> >> > >> >> > > >> >> > Also, and you clarify what you mean by "forward" vs "resolve"? > >> >> > > >> >> > I am assuming you are using "forward" in the traditional > >> >> "telephony" > >> >> > way, i.e., it is retargeted to another user, as opposed > >> to "request > >> >> > forwarding" which what you used for "resolving". Is > this correct? > >> >> [JRE] Yes. > >> >> > >> >> John > >> >> > >> >> > >> >> > > >> >> > > -----Original Message----- > >> >> > > From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > >> >> > > Sent: Wednesday, September 23, 2009 06:24 > >> >> > > To: Audet, Francois (SC100:3055); Shida Schubert > >> >> > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> >> Dean Willis; > >> >> > > Elwell, John; Keith Drage > >> >> > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >> >> > > > >> >> > > If we want to find specific things like freephone > >> >> numbers, I think > >> >> > > they do need to be explicitly marked, perhaps along the > >> >> lines that > >> >> > > Shida has suggested. > >> >> > > - Example 1: Call from A to B, which is forwarded > to freephone > >> >> > > number C, which resolves to D, which resolves to > >> >> > contact E. > >> >> > > - Example 2: Call from A to freephone number B, which > >> >> resolves to C, > >> >> > > which is then forwarded to D, which resolves to contact E. > >> >> > > > >> >> > > These two examples illustrate that the freephone URI > >> >> cannot be found > >> >> > > at any fixed place in the sequence, so explicit marking > >> >> would seem > >> >> > > to be necessary. > >> >> > > > >> >> > > John > >> >> > > > >> >> > > > >> >> > > > -----Original Message----- > >> >> > > > From: sipcore-bounces@ietf.org > >> >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > Francois Audet > >> >> > > > Sent: 10 September 2009 18:06 > >> >> > > > To: Shida Schubert > >> >> > > > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >> >> > Dean Willis; > >> >> > > > Elwell, John; Keith Drage > >> >> > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> >> > > > > >> >> > > > Ok, thanks. > >> >> > > > > >> >> > > > Let's wait for more input on this before we go for another > >> >> > > rev of the > >> >> > > > draft. > >> >> > > > > >> >> > > > > -----Original Message----- > >> >> > > > > From: Shida Schubert [mailto:shida@ntt-at.com] > >> >> > > > > Sent: Wednesday, September 09, 2009 21:24 > >> >> > > > > To: Audet, Francois (SC100:3055) > >> >> > > > > Cc: Adam Roach; sipcore@ietf.org; Jonathan Lennox; > >> >> > > Hadriel Kaplan; > >> >> > > > > Dean Willis; Elwell, John; Keith Drage > >> >> > > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> >> > > > > > >> >> > > > > > >> >> > > > > I think the following could work for > >> >> > > Freephone(toll-free), AFAIK > >> >> > > > > all is needed for freephone was the mp tag and some > >> >> guidance on > >> >> > > > > where to look for a toll-free. > >> >> > > > > > >> >> > > > > I believe that solving the problem of toll-free > >> is really > >> >> > > > > determining the current target of the request, which I > >> >> > believe is > >> >> > > > > what mp is trying to address. Generally if the incoming > >> >> > > request is > >> >> > > > > delivered via toll-free, then an entry before the last > >> >> > > mp(mapped-to) > >> >> > > > > is likely to be a toll-free number (mapped-from). > >> >> > > > > > >> >> > > > > Although, without globally deterministic way to mark the > >> >> > > toll-free, > >> >> > > > > it's hard for it to work across countries as different > >> >> > countries > >> >> > > > > have different toll-free prefixes. > >> >> > > > > (Here in Japan, it's 0120-xxx and not 1-800). > >> >> > > > > > >> >> > > > > We could though, possibly define a service URN or > >> >> > some tags for > >> >> > > > > typical services that are out there and tag HI-entry > >> >> > representing > >> >> > > > > such service with service URN that we define. > >> >> > > > > > >> >> > > > > History-Info: > >> >> > > > > < > >> >> > > > > sip:DirectoryAssistance > >> >> > > > > > >> @example.com>;index=3D1;service=3Durn:service:directory-assistance > >> >> > > > > History-Info: > >> >> > > ;index=3D1.1;mp=3D1 > >> >> > > > > History-Info: > >> ;index=3D1.1.1;rc=3D1 > >> >> > > > > History-Info: > ;index=3D1.1.2;rc=3D2 > >> >> > > > > > >> >> > > > > Regards > >> >> > > > > Shida > >> >> > > > > > >> >> > > > > On Sep 10, 2009, at 8:41 AM, Francois Audet wrote: > >> >> > > > > > >> >> > > > > > I guess the summary is that we are kind of stalled on > >> >> > > some of the > >> >> > > > > > issues, in particular the aor tag issue. It > seems that a > >> >> > > > > significant > >> >> > > > > > fraction of people do not believe that an AOR is > >> >> > deterministic > >> >> > > > > > construct that is worthy of being tagged as such. > >> >> > > > > > > >> >> > > > > > In my background (which is an Enterprise > >> software/telephony > >> >> > > > > > background), "users" have accounts. An AOR is > >> the series of > >> >> > > > > addresses > >> >> > > > > > corresponding to these accounts, along with > any aliases > >> >> > > > > (such as phone > >> >> > > > > > numbers expressed in SIP/TEL format). To me, > AORs are not > >> >> > > > > this fluffy > >> >> > > > > > concept that others on the list have made it up to be. > >> >> > > > > > > >> >> > > > > > But in any case, I don't think we'll be able > to reach a > >> >> > > > > concensus on > >> >> > > > > > it. > >> >> > > > > > > >> >> > > > > > I believe that we need to step back and find > a different > >> >> > > > > way to skin > >> >> > > > > > this cat. > >> >> > > > > > > >> >> > > > > > Going back to the requirements of WHAT we are > >> really trying > >> >> > > > > to solve > >> >> > > > > > at the > >> >> > > > > > UAS: > >> >> > > > > > > >> >> > > > > > 1) Tagging the last address (including > parameters) that > >> >> > > > was used in > >> >> > > > > > a Request-URI before being replaced by the Contact. > >> >> > > > > > i.e., the target-uri problem > >> >> > > > > > 1a) It has been argued that sometimes with the > >> >> > > > > target-uri problem > >> >> > > > > > you may actually be looking for the first > >> >> > > address (and > >> >> > > > > > parameters) > >> >> > > > > > as opposed to the last one. > >> >> > > > > > > >> >> > > > > > 2) Tagging addresses that represents a DIFFERENT > >> >> > > > user/resource, as a > >> >> > > > > > result of re-targeting. > >> >> > > > > > i.e., the re-targeting problem (voicemail, > IVR, etc.) > >> >> > > > > > > >> >> > > > > > We could potentially solve those two by > having tags for > >> >> > > > > "mapped" and > >> >> > > > > > "contacts", and use a pointer to the index of > what it is > >> >> > > > > mapped from > >> >> > > > > > (I guess we could do forward pointing instead > of backward > >> >> > > > pointing, > >> >> > > > > > but then forking would be more cumbersome). > >> >> > > > > > > >> >> > > > > > Having the tag pointing to the index would > >> remove ambiguity > >> >> > > > > if entries > >> >> > > > > > are removed by a proxy, etc. > >> >> > > > > > > >> >> > > > > > So, if I take a specific example of a call to > bob being > >> >> > > > > redirected to > >> >> > > > > > carol, the HI would look like > >> >> > > > > > this: > >> >> > > > > > > >> >> > > > > > History-Info: ;index=3D1; > >> >> > > > > > History-Info: > >> ;\ > >> >> > > > > > index=3D1.1;rc=3D1 > >> >> > > > > > History-Info: ;index=3D2;mp=3D= 1 > >> >> > > > > > History-Info: ;index=3D2.1;rc=3D= 2 > >> >> > > > > > > >> >> > > > > > For problem 1 (target-uri), the UAS would look at the > >> >> > > last rc tag > >> >> > > > > > which is it's registered contact, and see > what it points > >> >> > > > to (i.e., > >> >> > > > > > index 2). > >> >> > > > > > Index 2 is therefore > >> >> > > > > > the last target-uri. > >> >> > > > > > > >> >> > > > > > For problem 2 (redirection), the UAS looks > for the last > >> >> > > > mp tag (it > >> >> > > > > > points to index 1). > >> >> > > > > > Index 1 (bob) is therefore the "redirecting" number. > >> >> > > > Alternatively, > >> >> > > > > > the UAS may look for the FIRST retargeting (many > >> voicemail > >> >> > > > > work with > >> >> > > > > > the first one). > >> >> > > > > > > >> >> > > > > > Anyways, this is just brainstorming (and it > >> notably doesn't > >> >> > > > > solve - I > >> >> > > > > > think - the Freephone/1-800 number problem). > >> >> > > > > > > >> >> > > > > > Ideas? > >> >> > > > > > > >> >> > > > > > > >> >> > > > > >> -----Original Message----- > >> >> > > > > >> From: Adam Roach [mailto:adam@nostrum.com] > >> >> > > > > >> Sent: Tuesday, September 08, 2009 15:46 > >> >> > > > > >> To: sipcore@ietf.org > >> >> > > > > >> Cc: Hadriel Kaplan; Audet, Francois > (SC100:3055); Keith > >> >> > > > Drage; Jon > >> >> > > > > >> Peterson; Elwell, John; Robert Sparks; > Jonathan Lennox; > >> >> > > > Dean Willis > >> >> > > > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> >> > > > > >> > >> >> > > > > >> Just a quick reminder that we discussed this > >> vigorously in > >> >> > > > > Stockholm > >> >> > > > > >> without reaching any conclusion. To help spur things > >> >> > > > > along, here's a > >> >> > > > > >> summary of the arguments made during that discussion: > >> >> > > > > >> > >> >> > > > > >> > >> >> > > > > >> > >> >> > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue% > >> >> > > > > >> 201:%20AOR%20tag > >> >> > > > > >> > >> >> > > > > >> Please resume discussion on the list, and > see if we can > >> >> > > > reach any > >> >> > > > > >> sort of rough agreement. > >> >> > > > > >> > >> >> > > > > >> /a > >> >> > > > > >> > >> >> > > > > > _______________________________________________ > >> >> > > > > > sipcore mailing list > >> >> > > > > > sipcore@ietf.org > >> >> > > > > > https://www.ietf.org/mailman/listinfo/sipcore > >> >> > > > > > >> >> > > > > > >> >> > > > _______________________________________________ > >> >> > > > sipcore mailing list > >> >> > > > sipcore@ietf.org > >> >> > > > https://www.ietf.org/mailman/listinfo/sipcore > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > _______________________________________________ > >> > sipcore mailing list > >> > sipcore@ietf.org > >> > https://www.ietf.org/mailman/listinfo/sipcore > >> > > >> > >> -- > >> Von meinen Mobilger=E4t aus gesendet > >> > >> /Hans Erik van Elburg > >> > > > > -- > Von meinen Mobilger=E4t aus gesendet > > /Hans Erik van Elburg > From dwillis@greycouncil.com Thu Sep 24 14:08:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE443A67DB for ; Thu, 24 Sep 2009 14:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glv5--zQeStz for ; Thu, 24 Sep 2009 14:08:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 912163A6826 for ; Thu, 24 Sep 2009 14:08:46 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8OL9rpH030465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Sep 2009 16:09:55 -0500 Message-Id: <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> From: Dean Willis To: "Elwell, John" In-Reply-To: <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 16:09:47 -0500 References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 24 Sep 2009 14:10:00 -0700 Cc: SIPCORE Subject: [sipcore] Route registration (was Re: rfc4244bis: what is an AoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:08:47 -0000 On Sep 24, 2009, at 2:52 PM, Elwell, John wrote: > Just to be clear, I do not have a specific requirement for finding > the freephone number. I was merely pointing out that it seems very > difficult to solve using a generic mechanism. My general philosophy is that if something is appearing to be hard to solve, perhaps we're going about it entirely the wrong way. For example: Perhaps freephone routing shouldn't be handled by SIP retargeting or rerouting mechanisms like contact-routing. Perhaps it could be handled entirely by SIP rerouting operations. There are a lot of forms this can take. One might be in the area of doing something analogous to REGISTER that registers a "route", not a "contact". Such a "route registration" might be wildcard prefixable, which would also handle the "domain registration" case being raised by Alan Johnston and Richard Shockey. Further, it could eliminate much of the unanticipated respondent problem of contact routing (as we have no current way to determine whether contact-routing is rerouting or retargeting). Oddly enough, this solution also preserves URI parameters of all sorts . . . The difference between "contact routing" and just "routing" in a proxy is straightforward. If the next-hop URL is a "contact", we use RFC 3261 contact-routing procedures, replacing the request-URI with the registered contact. If however the next-hop URL is a "route", we use RFC 3261 loose-route procedures and push the URL onto the route stack and ship out the request with an unmodified request URI. Net result, the request is delivered to the next hop with an unmodified URL, ostensibly including the freephone number. If the next hop is terminal (the UAS), it of course needs to be able to recognize the freephone number as belonging to it, but that seems to be a requirement of all the things that require looking for a freephone number in the H_I stack anyhow. Handling freephone termination on legacy contact-registering devices would require fronting them with a "routing-aware" B2BUA, which seems imminently doable. The simplest approach might be a flag on the contact-value in a REGISTER request that indicates the thing being registered is a route, not a contact. Or a new header field could be used instead of Contact. This does raise some interesting questions about route authorization/authentication, but there should be a lot of work we could fall back on here. -- Dean From tianlinyi@huawei.com Thu Sep 24 20:13:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FD93A6847 for ; Thu, 24 Sep 2009 20:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lupJ2fLUoUEa for ; Thu, 24 Sep 2009 20:13:32 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B076B3A659C for ; Thu, 24 Sep 2009 20:13:31 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI004D7BO3MG@szxga02-in.huawei.com> for sipcore@ietf.org; Fri, 25 Sep 2009 11:14:28 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI00KLJBO3ZV@szxga02-in.huawei.com> for sipcore@ietf.org; Fri, 25 Sep 2009 11:14:27 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQI002BIBO36V@szxml06-in.huawei.com> for sipcore@ietf.org; Fri, 25 Sep 2009 11:14:27 +0800 (CST) Date: Fri, 25 Sep 2009 11:14:26 +0800 From: Linyi TIAN To: 'SIPCORE' Message-id: <022201ca3d8e$4a20e2c0$de62a840$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Hw8Lae0qCzY5CqZa7x2jjA)" Content-language: zh-cn Thread-index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVA== Subject: [sipcore] (Info event) Questions about Willingness and Capability negotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 03:13:38 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_Hw8Lae0qCzY5CqZa7x2jjA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Experts When I further dig the SIP INFO Event I-D, one thing puzzled me is the willingness and capability negotiation (Recv-Info header). In section 4.1 (Paragraph 5) The UAC may send INFO requests once the UAS has sent the Recv-Info header field value, indicating what the UAS supports. [Linyi] Here it says "MAY send" and "indicate it supports" rather than Willingness. In section 3.2 (Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil', the UAC MUST NOT send any INFO methods that contain Info Packages. (Paragraph 7) The presence of the Recv-Info header in a message is sufficient to indicate support for this version of INFO. [Linyi] From the first bullet it is clear that Recv-Info is used to indicate willingness. It is also used to indicate for support INFO package and framework. In section 4.1: (Paragraph 3) In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send an INFO without an Info-Package header field and a body appropriate to the said legacy usage. [Linyi] Is it possible to send Info Package without Recv-Info? I have a use case as follows. For example, if the UAS wants to perform Configuration/Administration task on the UAC it can send Info Package at any time without the UAC indicating whether it wants to be configured. In this case if the UAC does not support the Info Package it can return appropriate SIP error code. Then the SIP code will be used to indicate whether UAC supports the new SIP INFO method. Recv-Info will be used to indicate the willingness whether it wants to receive the package. The two mechanisms will be separated and could be used appropriately depending on the use cases. In section 3.2 (Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package until the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) with a Recv-Info header listing the given Info Package. [Linyi] I don't see strong reason to bundle them together. Here is my view and proposal: The I-D introduce three things: 1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO method 2. SIP INFO Framework which provides a negotiation mechanism via Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the willingness to receive packages 3. Use appropriate SIP code to indicate whether UAC supports a specific Info package SIP INFO Package can be used independently with SIP INFO Framework. By using this approach, we still have solve the IOP issues for old SIP INFO and good mechanism for negotiation of Capability and Willingness. It will accelerate the adoption of new SIP INFO method and provides smooth migration path for old SIP INFO methods to be moved to new one. I am looking forward to your expert comments and feedback. Cheers, Linyi --Boundary_(ID_Hw8Lae0qCzY5CqZa7x2jjA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, Experts

 

When I further dig the SIP INFO Event I-D, one thing puzzled me is the willingness and capability negotiation (Recv-Info header).

 

In section 4.1

(Paragraph 5) The UAC may send INFO requests once the UAS has sent the Recv-Info header field value, indicating what the UAS supports.

[Linyi] Here it says “MAY send” and “indicate it supports” rather than Willingness.

 

In section 3.2

(Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil', the UAC

   MUST NOT send any INFO methods that contain Info Packages.

(Paragraph 7) The presence of the Recv-Info header in a message is sufficient to indicate support for this version of INFO.

[Linyi] From the first bullet it is clear that Recv-Info is used to indicate willingness. It is also used to indicate for support INFO package and framework.

 

In section 4.1:

(Paragraph 3) In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send an INFO without an Info-Package header field and a body appropriate to the said legacy usage.

[Linyi] Is it possible to send Info Package without Recv-Info? I have a use case as follows. For example, if the UAS wants to perform Configuration/Administration task on the UAC it can send Info Package at any time without the UAC indicating whether it wants to be configured. In this case if the UAC does not support the Info Package it can return appropriate SIP error code.

       Then the SIP code will be used to indicate whether UAC supports the new SIP INFO method. Recv-Info will be used to indicate the willingness whether it wants to receive the package. The two mechanisms will be separated and could be used appropriately depending on the use cases.

 

In section 3.2

(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package until the UAC receives an "INVITE dialog usage" request or response (for

   session establishment or target refresh) with a Recv-Info header listing the given Info Package.

[Linyi] I don’t see strong reason to bundle them together. Here is my view and proposal:

The I-D introduce three things:

1.    SIP INFO Package (new SIP INFO method) to replace old SIP INFO method

2.    SIP INFO Framework which provides a negotiation mechanism via Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the willingness to receive packages

3. Use appropriate SIP code to indicate whether UAC supports a specific Info package

 

SIP INFO Package can be used independently with SIP INFO Framework.

 

By using this approach, we still have solve the IOP issues for old SIP INFO and good mechanism for negotiation of Capability and Willingness. It will accelerate the adoption of new SIP INFO method and provides smooth migration path for old SIP INFO methods to be moved to new one.

 

I am looking forward to your expert comments and feedback.

 

Cheers,

Linyi

--Boundary_(ID_Hw8Lae0qCzY5CqZa7x2jjA)-- From christer.holmberg@ericsson.com Thu Sep 24 22:58:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FE628C0EB for ; Thu, 24 Sep 2009 22:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzF5vS1TkCLf for ; Thu, 24 Sep 2009 22:58:08 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B5ECC3A682D for ; Thu, 24 Sep 2009 22:58:07 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-e3-4abc5c34410f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 0B.E9.22406.43C5CBA4; Fri, 25 Sep 2009 07:59:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 07:59:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Sep 2009 07:59:15 +0200 Message-ID: In-Reply-To: <022201ca3d8e$4a20e2c0$de62a840$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Thread-Index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVAAFJJMQ References: <022201ca3d8e$4a20e2c0$de62a840$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "SIPCORE" X-OriginalArrivalTime: 25 Sep 2009 05:59:15.0568 (UTC) FILETIME=[50112700:01CA3DA5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 05:58:09 -0000 Hi,=20 =20 >When I further dig the SIP INFO Event I-D, one thing puzzled me is the willingness and capability negotiation (Recv-Info header). > >In section 4.1 > >(Paragraph 5) The UAC may send INFO requests once the UAS has sent the Recv-Info header field value, indicating what the UAS supports. > >[Linyi] Here it says "MAY send" and "indicate it supports" rather than Willingness. We have received the same comments from others, and in the next version it will talk about "willingness to receive". >In section 3.2=20 > >(Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil', the UAC MUST NOT send any INFO methods that contain Info Packages. > >(Paragraph 7) The presence of the Recv-Info header in a message is sufficient to indicate support for this version of INFO. > >[Linyi] From the first bullet it is clear that Recv-Info is used to indicate willingness. It is also used to indicate for support INFO package and framework. Yes. >In section 4.1: > >(Paragraph 3) In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send=20 >an INFO without an Info-Package header field and a body appropriate to the said legacy usage. Yes. >[Linyi] Is it possible to send Info Package without Recv-Info? I have a use case as follows. For example, if the UAS wants to perform Configuration/Administration task on the UAC it can send=20 >Info Package at any time without the UAC indicating whether it wants to be configured. In this case if the UAC does not support the Info Package it can return appropriate SIP error code.=20 > >Then the SIP code will be used to indicate whether UAC supports the new SIP INFO method. Recv-Info will be used to indicate the willingness whether it wants to receive the package. The two=20 >mechanisms will be separated and could be used appropriately depending on the use cases. The idea is that Info Packages are sent ONLY if the other party has indicated willingess to receive them (which at the same time is an indication that your support the I-P mechanism). Again, that is one of the main purpose of I-P: to be able to explicitly indciate what you want to receive, instead of relying on assumptions, static configurations etc. =09 >In section 3.2 > >(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package until the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) with a=20 >Recv-Info header listing the given Info Package. > >[Linyi] I don't see strong reason to bundle them together. Here is my view and proposal: > >The I-D introduce three things:=20 > >1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO method > >2. SIP INFO Framework which provides a negotiation mechanism via Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the willingness to receive packages > >3. Use appropriate SIP code to indicate whether UAC supports a specific Info package You use Recv-Info to indicate what you are willing to receive. I see no reason why you then should send some other I-P (you are still allowed to use legacy INFOs, for which there are no I-Ps) >SIP INFO Package can be used independently with SIP INFO Framework.=20 SIP I-P IS part of the framework. >By using this approach, we still have solve the IOP issues for old SIP INFO and good mechanism for negotiation of Capability and Willingness. It will accelerate the adoption of new SIP INFO=20 >method and provides smooth migration path for old SIP INFO methods to be moved to new one. I don't see how it will accelerate anything - I think it will confuse people even more... If you implement support of an I-P, I don't think it is that much extra to implement support of the Recv-Info header. Regards, Christer =20 From tianlinyi@huawei.com Fri Sep 25 00:15:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DC23A683F for ; Fri, 25 Sep 2009 00:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFn0Gx3rMd64 for ; Fri, 25 Sep 2009 00:15:09 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 431903A687C for ; Fri, 25 Sep 2009 00:15:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI00FGDMV5LE@szxga02-in.huawei.com> for sipcore@ietf.org; Fri, 25 Sep 2009 15:16:17 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI002NFMV500@szxga02-in.huawei.com> for sipcore@ietf.org; Fri, 25 Sep 2009 15:16:17 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQI00MNSMV4LY@szxml06-in.huawei.com> for sipcore@ietf.org; Fri, 25 Sep 2009 15:16:17 +0800 (CST) Date: Fri, 25 Sep 2009 15:16:16 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , 'SIPCORE' Message-id: <024801ca3db0$12984d30$37c8e790$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVAAFJJMQAAJy1SA= References: <022201ca3d8e$4a20e2c0$de62a840$@com> Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 07:15:10 -0000 I agree Recv-Info is perfect for indicating the willingness. But it looks strange to use Recv-Info header to indicate the capability support. I guess it is better to be indicated using SIP code. For the case I described, if the UAS wants to perform some application level configuration/administration task, it can send the INFO package directly without receiving Recv-Info header from UAC. What I mean is that in this approach SIP INFO package can be used independently with Recv-Info. If the use case needs to negotiate the willingness then use them together. If no willingness needed then use new SIP INFO method alone. Does it make sense? Cheers, Linyi -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, September 25, 2009 1:59 PM To: Linyi TIAN; SIPCORE Subject: RE: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Hi, >When I further dig the SIP INFO Event I-D, one thing puzzled me is the willingness and capability negotiation (Recv-Info header). > >In section 4.1 > >(Paragraph 5) The UAC may send INFO requests once the UAS has sent the Recv-Info header field value, indicating what the UAS supports. > >[Linyi] Here it says "MAY send" and "indicate it supports" rather than Willingness. We have received the same comments from others, and in the next version it will talk about "willingness to receive". >In section 3.2 > >(Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil', the UAC MUST NOT send any INFO methods that contain Info Packages. > >(Paragraph 7) The presence of the Recv-Info header in a message is sufficient to indicate support for this version of INFO. > >[Linyi] From the first bullet it is clear that Recv-Info is used to indicate willingness. It is also used to indicate for support INFO package and framework. Yes. >In section 4.1: > >(Paragraph 3) In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send >an INFO without an Info-Package header field and a body appropriate to the said legacy usage. Yes. >[Linyi] Is it possible to send Info Package without Recv-Info? I have a use case as follows. For example, if the UAS wants to perform Configuration/Administration task on the UAC it can send >Info Package at any time without the UAC indicating whether it wants to be configured. In this case if the UAC does not support the Info Package it can return appropriate SIP error code. > >Then the SIP code will be used to indicate whether UAC supports the new SIP INFO method. Recv-Info will be used to indicate the willingness whether it wants to receive the package. The two >mechanisms will be separated and could be used appropriately depending on the use cases. The idea is that Info Packages are sent ONLY if the other party has indicated willingess to receive them (which at the same time is an indication that your support the I-P mechanism). Again, that is one of the main purpose of I-P: to be able to explicitly indciate what you want to receive, instead of relying on assumptions, static configurations etc. >In section 3.2 > >(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package until the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) with a >Recv-Info header listing the given Info Package. > >[Linyi] I don't see strong reason to bundle them together. Here is my view and proposal: > >The I-D introduce three things: > >1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO method > >2. SIP INFO Framework which provides a negotiation mechanism via Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the willingness to receive packages > >3. Use appropriate SIP code to indicate whether UAC supports a specific Info package You use Recv-Info to indicate what you are willing to receive. I see no reason why you then should send some other I-P (you are still allowed to use legacy INFOs, for which there are no I-Ps) >SIP INFO Package can be used independently with SIP INFO Framework. SIP I-P IS part of the framework. >By using this approach, we still have solve the IOP issues for old SIP INFO and good mechanism for negotiation of Capability and Willingness. It will accelerate the adoption of new SIP INFO >method and provides smooth migration path for old SIP INFO methods to be moved to new one. I don't see how it will accelerate anything - I think it will confuse people even more... If you implement support of an I-P, I don't think it is that much extra to implement support of the Recv-Info header. Regards, Christer From christer.holmberg@ericsson.com Fri Sep 25 03:28:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BEE3A6A2A for ; Fri, 25 Sep 2009 03:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHPyOrzJ-nZO for ; Fri, 25 Sep 2009 03:28:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 927063A67B4 for ; Fri, 25 Sep 2009 03:28:26 -0700 (PDT) X-AuditID: c1b4fb3e-b7c03ae0000055e7-fa-4abc9b4b1988 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B8.7F.21991.B4B9CBA4; Fri, 25 Sep 2009 12:28:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 12:28:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Sep 2009 12:28:26 +0200 Message-ID: In-Reply-To: <024801ca3db0$12984d30$37c8e790$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Thread-Index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVAAFJJMQAAJy1SAAB0XHMA== References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "SIPCORE" X-OriginalArrivalTime: 25 Sep 2009 10:28:26.0709 (UTC) FILETIME=[EAE5B050:01CA3DCA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 10:28:28 -0000 Hi,=20 >I agree Recv-Info is perfect for indicating the willingness.=20 >But it looks strange to use Recv-Info header to indicate the=20 >capability support. I guess it is better to be indicated=20 >using SIP code.=20 There IS an error code, 469, which is used if one receives an IP which it does not support (or want to receive). BUT, that error code is for error/race-condition cases - it is NOT a genral mechanism to figure out what the other is willing to receive.=20 >For the case I described, if the UAS wants to perform some=20 >application level configuration/administration task, it can=20 >send the INFO package directly without receiving Recv-Info=20 >header from UAC.=20 Why can't the UAC indicate willingess to receive the conf/adm package, if it supports it???? Again, there is a reason for having Recv-Info, and that is to avoid sending of stuff which the other does not support. Based on your proposal, it is ok to use I-Ps even if the remote party hasn't indicated willingess to receive them, and that is very confusing in my opinion - and it's bad protocol design.=20 >What I mean is that in this approach SIP INFO package can be=20 >used independently with Recv-Info. If the use case needs to=20 >negotiate the willingness then use them together. If no=20 >willingness needed then use new SIP INFO method alone. Does=20 >it make sense? No, at least not in my ears. We have had lenghty discussions about this, and I would not like to change it unless you can show that what we have now doesn't work. But, as always, if the group decides to do as you propose, I will of course accept it. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, September 25, 2009 1:59 PM > To: Linyi TIAN; SIPCORE > Subject: RE: [sipcore] (Info event) Questions about=20 > Willingness and Capabilitynegotiation >=20 >=20 > Hi,=20 > =20 >=20 > >When I further dig the SIP INFO Event I-D, one thing puzzled=20 > me is the > willingness and capability negotiation (Recv-Info header). > > > >In section 4.1 > > > >(Paragraph 5) The UAC may send INFO requests once the UAS=20 > has sent the > Recv-Info header field value, indicating what the UAS supports. > > > >[Linyi] Here it says "MAY send" and "indicate it supports"=20 > rather than > Willingness. >=20 > We have received the same comments from others, and in the=20 > next version > it will talk about "willingness to receive". >=20 >=20 > >In section 3.2=20 > > > >(Paragraph 3) If the UAC receives a Recv-Info header with the value > 'nil', the UAC MUST NOT send any INFO methods that contain Info > Packages. > > > >(Paragraph 7) The presence of the Recv-Info header in a message is > sufficient to indicate support for this version of INFO. > > > >[Linyi] From the first bullet it is clear that Recv-Info is used to > indicate willingness. It is also used to indicate for support INFO > package and framework. >=20 > Yes. >=20 >=20 > >In section 4.1: > > > >(Paragraph 3) In this case, if the UAS has never offered a Recv-Info > header or never offered a Recv-Info header with a package of a similar > function to the legacy INFO usage, the UAC MAY send=20 > >an INFO without an Info-Package header field and a body=20 > appropriate to > the said legacy usage. >=20 > Yes. >=20 > >[Linyi] Is it possible to send Info Package without=20 > Recv-Info? I have a > use case as follows. For example, if the UAS wants to perform > Configuration/Administration task on the UAC it can send=20 > >Info Package at any time without the UAC indicating whether=20 > it wants to > be configured. In this case if the UAC does not support the=20 > Info Package > it can return appropriate SIP error code.=20 > > > >Then the SIP code will be used to indicate whether UAC=20 > supports the new > SIP INFO method. Recv-Info will be used to indicate the willingness > whether it wants to receive the package. The two=20 > >mechanisms will be separated and could be used appropriately=20 > depending > on the use cases. >=20 > The idea is that Info Packages are sent ONLY if the other party has > indicated willingess to receive them (which at the same time is an > indication that your support the I-P mechanism). >=20 > Again, that is one of the main purpose of I-P: to be able to=20 > explicitly > indciate what you want to receive, instead of relying on assumptions, > static configurations etc. > =09 > >In section 3.2 > > > >(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO > package until the UAC receives an "INVITE dialog usage" request or > response (for session establishment or target refresh) with a=20 > >Recv-Info header listing the given Info Package. > > > >[Linyi] I don't see strong reason to bundle them together. Here is my > view and proposal: > > > >The I-D introduce three things:=20 > > > >1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO > method > > > >2. SIP INFO Framework which provides a negotiation mechanism via > Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the > willingness to receive packages > > > >3. Use appropriate SIP code to indicate whether UAC supports a > specific Info package >=20 > You use Recv-Info to indicate what you are willing to=20 > receive. I see no > reason why you then should send some other I-P (you are still=20 > allowed to > use legacy INFOs, for which there are no I-Ps) >=20 > >SIP INFO Package can be used independently with SIP INFO Framework.=20 >=20 > SIP I-P IS part of the framework. >=20 > >By using this approach, we still have solve the IOP issues=20 > for old SIP > INFO and good mechanism for negotiation of Capability and Willingness. > It will accelerate the adoption of new SIP INFO=20 > >method and provides smooth migration path for old SIP INFO methods to > be moved to new one. >=20 > I don't see how it will accelerate anything - I think it will confuse > people even more... If you implement support of an I-P, I=20 > don't think it > is that much extra to implement support of the Recv-Info header. >=20 >=20 > Regards, >=20 > Christer > =20 >=20 >=20 From dean.willis@softarmor.com Fri Sep 25 15:51:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2863A6963 for ; Fri, 25 Sep 2009 15:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwoPUql26Xvb for ; Fri, 25 Sep 2009 15:51:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4F28E3A68F7 for ; Fri, 25 Sep 2009 15:51:47 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8PMqmQG010230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2009 17:52:50 -0500 Message-Id: <85218FE9-DBE0-4CB3-962E-985B75CB09C5@softarmor.com> From: Dean Willis To: Linyi TIAN In-Reply-To: <024801ca3db0$12984d30$37c8e790$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 25 Sep 2009 17:52:42 -0500 References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> X-Mailer: Apple Mail (2.936) Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 22:51:48 -0000 On Sep 25, 2009, at 2:16 AM, Linyi TIAN wrote: > I agree Recv-Info is perfect for indicating the willingness. But it > looks > strange to use Recv-Info header to indicate the capability support. > I guess > it is better to be indicated using SIP code. > > For the case I described, if the UAS wants to perform some > application level > configuration/administration task, it can send the INFO package > directly > without receiving Recv-Info header from UAC. > > What I mean is that in this approach SIP INFO package can be used > independently with Recv-Info. If the use case needs to negotiate the > willingness then use them together. If no willingness needed then > use new > SIP INFO method alone. Does it make sense? I'm pretty sure I don't understand, so no, it doesn't make sense to me yet. -- Dean From tianlinyi@huawei.com Sat Sep 26 17:45:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66923A6875 for ; Sat, 26 Sep 2009 17:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLzDWcep0PP8 for ; Sat, 26 Sep 2009 17:45:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 59F313A67D7 for ; Sat, 26 Sep 2009 17:45:42 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQL00EQ3U66EA@szxga03-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 08:46:55 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQL00BBNU6643@szxga03-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 08:46:54 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQL00MB6U66KJ@szxml06-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 08:46:54 +0800 (CST) Date: Sun, 27 Sep 2009 08:46:54 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , 'SIPCORE' Message-id: <032701ca3f0c$026ac6b0$07405410$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVAAFJJMQAAJy1SAAB0XHMABQb7eA References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 00:45:43 -0000 Hi, Christer There is a discussion in OIPF about the Timer Configuration. You can ask George about the background. In 3GPP solution if a SIP INVITE is sent from UAC, the UAS can send one XML document within SIP 200 OK to change the timer. We think this is a simple mechanism. On the other hand this is a configuration and administration task which does not need the UAC to indicate the willingness to be configured. It should be always available. If Recv-Info header can be decoupled with new SIP INFO, it could be ok to use it for this function. Timer modification function should be always available which means the UAC always support it. It does not require the UAC to indicate it supports using Recv-Info nor indicate it is willing to be changed. Therefore we believe for this function it is abusing the SIP INFO framework. It will also cause different implementation in TISPAN/3GPP/OIPF. We are not saying any SDO should not support SIP INFO framework. We do see benefit for this I-D but that does not necessary mean we should use it everywhere and abuse it. It should depend on the use cases. However this discussion is better to be done in other SDOs. In IETF, the current draft is really confusing about capability support and indicating willingness. Recv-Info header is used to indicate the support for SIP INFO framework. It is also used to indicate willingness. The error 469 was for that purpose as well. We think two concepts are not the same and should be clearly described. Cheers, Linyi -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Friday, September 25, 2009 6:28 PM To: Linyi TIAN; SIPCORE Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Hi, >I agree Recv-Info is perfect for indicating the willingness. >But it looks strange to use Recv-Info header to indicate the >capability support. I guess it is better to be indicated >using SIP code. There IS an error code, 469, which is used if one receives an IP which it does not support (or want to receive). BUT, that error code is for error/race-condition cases - it is NOT a genral mechanism to figure out what the other is willing to receive. >For the case I described, if the UAS wants to perform some >application level configuration/administration task, it can >send the INFO package directly without receiving Recv-Info >header from UAC. Why can't the UAC indicate willingess to receive the conf/adm package, if it supports it???? Again, there is a reason for having Recv-Info, and that is to avoid sending of stuff which the other does not support. Based on your proposal, it is ok to use I-Ps even if the remote party hasn't indicated willingess to receive them, and that is very confusing in my opinion - and it's bad protocol design. >What I mean is that in this approach SIP INFO package can be >used independently with Recv-Info. If the use case needs to >negotiate the willingness then use them together. If no >willingness needed then use new SIP INFO method alone. Does >it make sense? No, at least not in my ears. We have had lenghty discussions about this, and I would not like to change it unless you can show that what we have now doesn't work. But, as always, if the group decides to do as you propose, I will of course accept it. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, September 25, 2009 1:59 PM > To: Linyi TIAN; SIPCORE > Subject: RE: [sipcore] (Info event) Questions about > Willingness and Capabilitynegotiation > > > Hi, > > > >When I further dig the SIP INFO Event I-D, one thing puzzled > me is the > willingness and capability negotiation (Recv-Info header). > > > >In section 4.1 > > > >(Paragraph 5) The UAC may send INFO requests once the UAS > has sent the > Recv-Info header field value, indicating what the UAS supports. > > > >[Linyi] Here it says "MAY send" and "indicate it supports" > rather than > Willingness. > > We have received the same comments from others, and in the > next version > it will talk about "willingness to receive". > > > >In section 3.2 > > > >(Paragraph 3) If the UAC receives a Recv-Info header with the value > 'nil', the UAC MUST NOT send any INFO methods that contain Info > Packages. > > > >(Paragraph 7) The presence of the Recv-Info header in a message is > sufficient to indicate support for this version of INFO. > > > >[Linyi] From the first bullet it is clear that Recv-Info is used to > indicate willingness. It is also used to indicate for support INFO > package and framework. > > Yes. > > > >In section 4.1: > > > >(Paragraph 3) In this case, if the UAS has never offered a Recv-Info > header or never offered a Recv-Info header with a package of a similar > function to the legacy INFO usage, the UAC MAY send > >an INFO without an Info-Package header field and a body > appropriate to > the said legacy usage. > > Yes. > > >[Linyi] Is it possible to send Info Package without > Recv-Info? I have a > use case as follows. For example, if the UAS wants to perform > Configuration/Administration task on the UAC it can send > >Info Package at any time without the UAC indicating whether > it wants to > be configured. In this case if the UAC does not support the > Info Package > it can return appropriate SIP error code. > > > >Then the SIP code will be used to indicate whether UAC > supports the new > SIP INFO method. Recv-Info will be used to indicate the willingness > whether it wants to receive the package. The two > >mechanisms will be separated and could be used appropriately > depending > on the use cases. > > The idea is that Info Packages are sent ONLY if the other party has > indicated willingess to receive them (which at the same time is an > indication that your support the I-P mechanism). > > Again, that is one of the main purpose of I-P: to be able to > explicitly > indciate what you want to receive, instead of relying on assumptions, > static configurations etc. > > >In section 3.2 > > > >(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO > package until the UAC receives an "INVITE dialog usage" request or > response (for session establishment or target refresh) with a > >Recv-Info header listing the given Info Package. > > > >[Linyi] I don't see strong reason to bundle them together. Here is my > view and proposal: > > > >The I-D introduce three things: > > > >1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO > method > > > >2. SIP INFO Framework which provides a negotiation mechanism via > Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the > willingness to receive packages > > > >3. Use appropriate SIP code to indicate whether UAC supports a > specific Info package > > You use Recv-Info to indicate what you are willing to > receive. I see no > reason why you then should send some other I-P (you are still > allowed to > use legacy INFOs, for which there are no I-Ps) > > >SIP INFO Package can be used independently with SIP INFO Framework. > > SIP I-P IS part of the framework. > > >By using this approach, we still have solve the IOP issues > for old SIP > INFO and good mechanism for negotiation of Capability and Willingness. > It will accelerate the adoption of new SIP INFO > >method and provides smooth migration path for old SIP INFO methods to > be moved to new one. > > I don't see how it will accelerate anything - I think it will confuse > people even more... If you implement support of an I-P, I > don't think it > is that much extra to implement support of the Recv-Info header. > > > Regards, > > Christer > > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From tianlinyi@huawei.com Sat Sep 26 17:59:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB683A6804 for ; Sat, 26 Sep 2009 17:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkZobUHvMzjR for ; Sat, 26 Sep 2009 17:59:35 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D00D13A67D7 for ; Sat, 26 Sep 2009 17:59:34 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQL00ELAUT04X@szxga02-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 09:00:37 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQL00KUZUT0N1@szxga02-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 09:00:36 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQL00MP2UT0KJ@szxml06-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 09:00:36 +0800 (CST) Date: Sun, 27 Sep 2009 09:00:36 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , 'SIPCORE' Message-id: <032901ca3f0d$ec672d70$c5358850$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVAAFJJMQAFrB0YA= References: <022201ca3d8e$4a20e2c0$de62a840$@com> Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 00:59:36 -0000 Both Recv-Info and 469 was used to indicate capability support and willingness. That was confusing thing. If Recv-Info is only used to indicate willingness there would be several scenarios: 1. UAC indicates willingness to receive INFO package by Recv-Info, then UAS sends INFO. 2. UAC indicates 'nil' in Recv-Info, then UAS MUST NOT send INFO. 3. UAC didn't send Recv-Info but the UAS wants to send SIP INFO. In this case if UAC supports and would like to consume it then it will be ok. If it does not support, return 415 (or 469??) . If it supports but doesn't want to consume it, return 469 as appropriate. Would this be better? Cheers, Linyi -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Friday, September 25, 2009 1:59 PM To: Linyi TIAN; SIPCORE Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Hi, >When I further dig the SIP INFO Event I-D, one thing puzzled me is the willingness and capability negotiation (Recv-Info header). > >In section 4.1 > >(Paragraph 5) The UAC may send INFO requests once the UAS has sent the Recv-Info header field value, indicating what the UAS supports. > >[Linyi] Here it says "MAY send" and "indicate it supports" rather than Willingness. We have received the same comments from others, and in the next version it will talk about "willingness to receive". >In section 3.2 > >(Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil', the UAC MUST NOT send any INFO methods that contain Info Packages. > >(Paragraph 7) The presence of the Recv-Info header in a message is sufficient to indicate support for this version of INFO. > >[Linyi] From the first bullet it is clear that Recv-Info is used to indicate willingness. It is also used to indicate for support INFO package and framework. Yes. >In section 4.1: > >(Paragraph 3) In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send >an INFO without an Info-Package header field and a body appropriate to the said legacy usage. Yes. >[Linyi] Is it possible to send Info Package without Recv-Info? I have a use case as follows. For example, if the UAS wants to perform Configuration/Administration task on the UAC it can send >Info Package at any time without the UAC indicating whether it wants to be configured. In this case if the UAC does not support the Info Package it can return appropriate SIP error code. > >Then the SIP code will be used to indicate whether UAC supports the new SIP INFO method. Recv-Info will be used to indicate the willingness whether it wants to receive the package. The two >mechanisms will be separated and could be used appropriately depending on the use cases. The idea is that Info Packages are sent ONLY if the other party has indicated willingess to receive them (which at the same time is an indication that your support the I-P mechanism). Again, that is one of the main purpose of I-P: to be able to explicitly indciate what you want to receive, instead of relying on assumptions, static configurations etc. >In section 3.2 > >(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package until the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) with a >Recv-Info header listing the given Info Package. > >[Linyi] I don't see strong reason to bundle them together. Here is my view and proposal: > >The I-D introduce three things: > >1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO method > >2. SIP INFO Framework which provides a negotiation mechanism via Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the willingness to receive packages > >3. Use appropriate SIP code to indicate whether UAC supports a specific Info package You use Recv-Info to indicate what you are willing to receive. I see no reason why you then should send some other I-P (you are still allowed to use legacy INFOs, for which there are no I-Ps) >SIP INFO Package can be used independently with SIP INFO Framework. SIP I-P IS part of the framework. >By using this approach, we still have solve the IOP issues for old SIP INFO and good mechanism for negotiation of Capability and Willingness. It will accelerate the adoption of new SIP INFO >method and provides smooth migration path for old SIP INFO methods to be moved to new one. I don't see how it will accelerate anything - I think it will confuse people even more... If you implement support of an I-P, I don't think it is that much extra to implement support of the Recv-Info header. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Sat Sep 26 18:59:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E533A67B2 for ; Sat, 26 Sep 2009 18:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymS6KnYGVLe3 for ; Sat, 26 Sep 2009 18:59:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2BE3A3A68CE for ; Sat, 26 Sep 2009 18:59:13 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8R20GE0020615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 26 Sep 2009 21:00:18 -0500 Message-Id: From: Dean Willis To: Linyi TIAN In-Reply-To: <032701ca3f0c$026ac6b0$07405410$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 26 Sep 2009 20:59:58 -0500 References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> X-Mailer: Apple Mail (2.936) Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 01:59:14 -0000 On Sep 26, 2009, at 7:46 PM, Linyi TIAN wrote: > In 3GPP solution if a SIP INVITE is sent from UAC, the UAS can send > one XML > document within SIP 200 OK to change the timer. We think this is a > simple > mechanism. On the other hand this is a configuration and > administration task > which does not need the UAC to indicate the willingness to be > configured. It > should be always available. I have to say Huh? If I understand the approach, it's about the strangest mechanism I can imagine. It's pretty much a violation of every SIP extensibility principle every discussed. Also, adding bodythings to response messages is a bad idea (read: pretty much completely forbidden) because we have no way to manage size and fragmentation on responses delivered over UDP. > If Recv-Info header can be decoupled with new SIP INFO, it could be > ok to > use it for this function. You mean you want to use Recv-Info in the INVITE request to tell the UAS it can send a special XML body back in the 200 OK? > > Timer modification function should be always available which means > the UAC > always support it. It does not require the UAC to indicate it > supports using > Recv-Info nor indicate it is willing to be changed. > Why would a UAC always support it? Not a single one of the UAs I currently have supports it. It seems like a totally proprietary hack that only a few 3GPP-compliant UAs would support. Definitely the kind of thing that requires feature negotiation. ... > > In IETF, the current draft is really confusing about capability > support and > indicating willingness. Recv-Info header is used to indicate the > support for > SIP INFO framework. It is also used to indicate willingness. The > error 469 > was for that purpose as well. We think two concepts are not the same > and > should be clearly described. 469 is a dialog-terminating error condition. It's much better to just not send the offending message because you know the other end isn't capable and willing than it is to make your dialog explode and die. -- Dean From tianlinyi@huawei.com Sat Sep 26 20:07:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE163A68A6 for ; Sat, 26 Sep 2009 20:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZLoFkh79iqS for ; Sat, 26 Sep 2009 20:07:22 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 908D93A681C for ; Sat, 26 Sep 2009 20:07:22 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQM004CO0Q2F0@szxga02-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 11:08:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQM00MC10Q2JR@szxga02-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 11:08:26 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQM004020Q1J9@szxml04-in.huawei.com> for sipcore@ietf.org; Sun, 27 Sep 2009 11:08:26 +0800 (CST) Date: Sun, 27 Sep 2009 11:08:25 +0800 From: Linyi TIAN In-reply-to: To: 'Dean Willis' Message-id: <000401ca3f1f$c7d8ca10$578a5e30$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco/Fkj/u5fWgHnHSvO0brJHsXZZNgACDL9w References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 03:07:23 -0000 Surprised to see you still working in Sunday. We work today because we switch one day for Chinese National Holiday:) Thanks for the guidance. This discussion is better to be directly to 3GPP or other SDOs. Let's continue the discussion on I-D itself. See inline response. Cheers, Linyi > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, September 27, 2009 10:00 AM > To: Linyi TIAN > Cc: 'Christer Holmberg'; 'SIPCORE' > Subject: Re: [sipcore] (Info event) Questions about Willingness and > Capabilitynegotiation > > > On Sep 26, 2009, at 7:46 PM, Linyi TIAN wrote: > > You mean you want to use Recv-Info in the INVITE request to tell the > UAS it can send a special XML body back in the 200 OK? > > > > Timer modification function should be always available which means > > the UAC > > always support it. It does not require the UAC to indicate it > > supports using > > Recv-Info nor indicate it is willing to be changed. > > > > Why would a UAC always support it? Not a single one of the UAs I > currently have supports it. It seems like a totally proprietary hack > that only a few 3GPP-compliant UAs would support. Definitely the kind > of thing that requires feature negotiation. [Linyi TIAN] Yes, it only works for 3GPP-compliant UAs. I mean in that context we already knows UA supports it why bother to send capability indication? For this administration function, I also don't see the need to show willingness. Why the UAC wants to say I don't want to be configured? I will wait to see the new version of the I-D before I post any new comments. For the time being, I understand what you mean. However I still think mixing the concepts between Capability Support and Willingness is not a good idea. > ... > > > > > In IETF, the current draft is really confusing about capability > > support and > > indicating willingness. Recv-Info header is used to indicate the > > support for > > SIP INFO framework. It is also used to indicate willingness. The > > error 469 > > was for that purpose as well. We think two concepts are not the same > > and > > should be clearly described. > > 469 is a dialog-terminating error condition. It's much better to just > not send the offending message because you know the other end isn't > capable and willing than it is to make your dialog explode and die. > > -- > Dean From christer.holmberg@ericsson.com Sun Sep 27 04:54:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF6B3A6962 for ; Sun, 27 Sep 2009 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.678 X-Spam-Level: X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH2UXs2hWCeN for ; Sun, 27 Sep 2009 04:54:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 148C43A6783 for ; Sun, 27 Sep 2009 04:54:42 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-f7-4abf52cc27e2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 20.B4.15624.CC25FBA4; Sun, 27 Sep 2009 13:55:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 13:55:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Sep 2009 13:55:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about Willingness andCapabilitynegotiation Thread-Index: Aco9jkmiO3Jv8c1ATWyP7ZyTpDhnVAAFJJMQAFrB0YAAFrIc4Q== References: <022201ca3d8e$4a20e2c0$de62a840$@com> <032901ca3f0d$ec672d70$c5358850$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "SIPCORE" X-OriginalArrivalTime: 27 Sep 2009 11:55:56.0214 (UTC) FILETIME=[78AC1560:01CA3F69] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] (Info event) Questions about Willingness andCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 11:54:45 -0000 Hi, >Both Recv-Info and 469 was used to indicate capability support and = willingness. That was confusing thing. =20 Why is that confusing??? We have a header to indicate what one is = willing to receive, and we have a response code to indicate that = something is not accepted. That's nothing new in SIP... >If Recv-Info is only used to indicate willingness there would be = several >scenarios: >1. UAC indicates willingness to receive INFO package by Recv-Info, then = UAS >sends INFO. =20 Yes. >2. UAC indicates 'nil' in Recv-Info, then UAS MUST NOT send INFO. =20 Yes. >3. UAC didn't send Recv-Info but the UAS wants to send SIP INFO. In = this >case if UAC supports and would like to consume it then it will be ok. = If it >does not support, return 415 (or 469??) . If it supports but doesn't = want to >consume it, return 469 as appropriate. =20 If the UAC supports and wants to consume it should indicate so using = Recv-Info. I don't see what the problem with that is... =20 Since the I-P spec defines both the I-P concept and the Recv-Info = header, there are no implementations out there which support Info = Packages, but not Recv-Info. So, if you implement support of a I-P you = also implement support of Recv-Info.=20 =20 It's the same reason why we have the Supported header. A UAS shall not = use an extension towards the UAC if the UAC hasn't indicated support = using an option-tag. =20 It's the same reason why we indicate codecs in the SDP. A UAS shall send = use a codec towards the UAC which the UAC hasn't indiated support for. =20 etc. =20 Regards, =20 Christer =20 =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Christer Holmberg Sent: Friday, September 25, 2009 1:59 PM To: Linyi TIAN; SIPCORE Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Hi, =20 >When I further dig the SIP INFO Event I-D, one thing puzzled me is the willingness and capability negotiation (Recv-Info header). > >In section 4.1 > >(Paragraph 5) The UAC may send INFO requests once the UAS has sent the Recv-Info header field value, indicating what the UAS supports. > >[Linyi] Here it says "MAY send" and "indicate it supports" rather than Willingness. We have received the same comments from others, and in the next version it will talk about "willingness to receive". >In section 3.2 > >(Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil', the UAC MUST NOT send any INFO methods that contain Info Packages. > >(Paragraph 7) The presence of the Recv-Info header in a message is sufficient to indicate support for this version of INFO. > >[Linyi] From the first bullet it is clear that Recv-Info is used to indicate willingness. It is also used to indicate for support INFO package and framework. Yes. >In section 4.1: > >(Paragraph 3) In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send >an INFO without an Info-Package header field and a body appropriate to the said legacy usage. Yes. >[Linyi] Is it possible to send Info Package without Recv-Info? I have a use case as follows. For example, if the UAS wants to perform Configuration/Administration task on the UAC it can send >Info Package at any time without the UAC indicating whether it wants to be configured. In this case if the UAC does not support the Info Package it can return appropriate SIP error code. > >Then the SIP code will be used to indicate whether UAC supports the new SIP INFO method. Recv-Info will be used to indicate the willingness whether it wants to receive the package. The two >mechanisms will be separated and could be used appropriately depending on the use cases. The idea is that Info Packages are sent ONLY if the other party has indicated willingess to receive them (which at the same time is an indication that your support the I-P mechanism). Again, that is one of the main purpose of I-P: to be able to explicitly indciate what you want to receive, instead of relying on assumptions, static configurations etc. =20 >In section 3.2 > >(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package until the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) with a >Recv-Info header listing the given Info Package. > >[Linyi] I don't see strong reason to bundle them together. Here is my view and proposal: > >The I-D introduce three things: > >1. SIP INFO Package (new SIP INFO method) to replace old SIP INFO method > >2. SIP INFO Framework which provides a negotiation mechanism via Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the willingness to receive packages > >3. Use appropriate SIP code to indicate whether UAC supports a specific Info package You use Recv-Info to indicate what you are willing to receive. I see no reason why you then should send some other I-P (you are still allowed to use legacy INFOs, for which there are no I-Ps) >SIP INFO Package can be used independently with SIP INFO Framework. SIP I-P IS part of the framework. >By using this approach, we still have solve the IOP issues for old SIP INFO and good mechanism for negotiation of Capability and Willingness. It will accelerate the adoption of new SIP INFO >method and provides smooth migration path for old SIP INFO methods to be moved to new one. I don't see how it will accelerate anything - I think it will confuse people even more... If you implement support of an I-P, I don't think it is that much extra to implement support of the Recv-Info header. Regards, Christer =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Sun Sep 27 05:14:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446333A6960 for ; Sun, 27 Sep 2009 05:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1QEOzJiQukU for ; Sun, 27 Sep 2009 05:14:26 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DAAB13A6835 for ; Sun, 27 Sep 2009 05:14:25 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-84-4abf576b5b3d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C9.99.22406.B675FBA4; Sun, 27 Sep 2009 14:15:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 14:14:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Sep 2009 14:14:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about Willingness andCapabilitynegotiation Thread-Index: Aco/Fkj/u5fWgHnHSvO0brJHsXZZNgACDL9wABLBK/8= References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Dean Willis" X-OriginalArrivalTime: 27 Sep 2009 12:14:53.0170 (UTC) FILETIME=[1E59CD20:01CA3F6C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] (Info event) Questions about Willingness andCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:14:27 -0000 Hi, >Surprised to see you still working in Sunday. We work today because we = switch one day for Chinese National Holiday:) We work because SIP is our life - sadly, one could say :) >Thanks for the guidance. This discussion is better to be directly to = 3GPP or other SDOs. Let's continue the discussion on I-D itself. See = inline response. >>You mean you want to use Recv-Info in the INVITE request to tell the = UAS it can send a special XML body back in the 200 OK? >> >>Timer modification function should be always available which means the = UAC always support it. It does not require the UAC to indicate it = supports using Recv-Info nor indicate it is willing to be changed. > > > >Why would a UAC always support it? Not a single one of the UAs I = currently have supports it. It seems like a totally proprietary hack = that only a few 3GPP-compliant UAs would support. Definitely the kind >of thing that requires feature negotiation. > >[Linyi TIAN] Yes, it only works for 3GPP-compliant UAs. I mean in that >context we already knows UA supports it why bother to send capability >indication? For this administration function, I also don't see the need = to >show willingness. Why the UAC wants to say I don't want to be = configured? First, an XML body in the 200 OK has absolutely NOTHING to do with the = I-P mechanism. You don't use Recv-Info to indicate what you can receive = in a 200 OK response - you use Recv-Info to indicate what you can = receive in an INFO request, only an INFO request, and nothing but an = INFO request. Second, in your case, the UAC should indicate support of the XML body = MIME using the Accept header. If it doesn't, and the UAS still sends the = XML body in the 200 OK the UAS does not behave according to 3261. If = 3GPP thinks that's ok, it's their choise. But, again, that has nothing = to do with the I-P mechanism. Thrid, for configuration and management, I would assume that indicating = willingess to receive is "hard coded" into the user equipment by the = operator and/or manufacturer, ie the user can not choose whehter he = wants to receive conf/mgmnt Info Packages. >I will wait to see the new version of the I-D before I post any new = comments. For the time being, I understand what you mean. However I = still think mixing the concepts between Capability Support and = Willingness is not >a good idea. You can use OPTIONS to determine/indicate general capability support. A = UA would normally indicate all Info Packages that it supports in the = OPTIONS request/response. But, still, that doesn't mean that one is free = to use them in a session - unless the UA explicitly indicate willingess = to receive them for that session. A new draft is on its way. We have taken a second look at it, to make = sure things are clear. But, feedback is of course welcome. But, the idea is still: if you want to receive something, you indicate = it. If someone then sends something else, it is an error case (or, a = race condition case). SDOs that want to be compliant with the mechanism = shall not send Info Packages for which willingness have not been = indicated. Regards, Christer =20 =20 > > In IETF, the current draft is really confusing about capability > > support and > > indicating willingness. Recv-Info header is used to indicate the > > support for > > SIP INFO framework. It is also used to indicate willingness. The > > error 469 > > was for that purpose as well. We think two concepts are not the same > > and > > should be clearly described. > > 469 is a dialog-terminating error condition. It's much better to just > not send the offending message because you know the other end isn't > capable and willing than it is to make your dialog explode and die. > > -- > Dean From christer.holmberg@ericsson.com Sun Sep 27 05:19:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBCE3A6899 for ; Sun, 27 Sep 2009 05:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RHm1hjdtcwT for ; Sun, 27 Sep 2009 05:19:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 279F73A6884 for ; Sun, 27 Sep 2009 05:19:26 -0700 (PDT) X-AuditID: c1b4fb3e-b7c03ae0000055e7-e2-4abf5898d93c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9D.E5.21991.8985FBA4; Sun, 27 Sep 2009 14:20:41 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 14:20:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Sep 2009 14:15:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Thread-Index: Aco/FkcG8GyCXpt0SvKARftJFyCjtgAVe7cm References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> From: "Christer Holmberg" To: "Dean Willis" , "Linyi TIAN" X-OriginalArrivalTime: 27 Sep 2009 12:20:13.0958 (UTC) FILETIME=[DD8E2A60:01CA3F6C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:19:28 -0000 =20 Hi, >>In 3GPP solution if a SIP INVITE is sent from UAC, the UAS can send = one XML >>document within SIP 200 OK to change the timer. We think this is a = simple >>mechanism. On the other hand this is a configuration and = administration task >>which does not need the UAC to indicate the willingness to be = configured. It >>should be always available. > >I have to say Huh? If I understand the approach, it's about the=20 >strangest mechanism I can imagine. It's pretty much a violation of=20 >every SIP extensibility principle every discussed. > >Also, adding bodythings to response messages is a bad idea (read:=20 >pretty much completely forbidden) because we have no way to manage=20 >size and fragmentation on responses delivered over UDP. =20 I agree. =20 In fact, I think 3GPP CT1 has a couple of ongoing use-cases where = solution alternatives to return data in SIP responses have been = presented. But, concern has been raised towards such solutions, due to = the UDP reason indicated by Dean. Regards, =20 Christer From drage@alcatel-lucent.com Sun Sep 27 14:47:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FDA3A691C for ; Sun, 27 Sep 2009 14:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yso7UO2kp8z7 for ; Sun, 27 Sep 2009 14:47:37 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 000803A62C1 for ; Sun, 27 Sep 2009 14:47:36 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n8RLmjpK004467 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 27 Sep 2009 23:48:45 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 27 Sep 2009 23:48:45 +0200 From: "DRAGE, Keith (Keith)" To: Dean Willis , Linyi TIAN Date: Sun, 27 Sep 2009 23:48:33 +0200 Thread-Topic: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation Thread-Index: Aco/Fk0t4N4N1ykEQzWNBPZi4HWROQApXqTQ Message-ID: References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about Willingness and Capabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 21:47:38 -0000 See below.=20 Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Sunday, September 27, 2009 3:00 AM > To: Linyi TIAN > Cc: 'SIPCORE' > Subject: Re: [sipcore] (Info event) Questions about=20 > Willingness and Capabilitynegotiation >=20 >=20 > On Sep 26, 2009, at 7:46 PM, Linyi TIAN wrote: >=20 > > In 3GPP solution if a SIP INVITE is sent from UAC, the UAS can send=20 > > one XML document within SIP 200 OK to change the timer. We=20 > think this=20 > > is a simple mechanism. On the other hand this is a=20 > configuration and=20 > > administration task which does not need the UAC to indicate the=20 > > willingness to be configured. It should be always available. >=20 > I have to say Huh? If I understand the approach, it's about=20 > the strangest mechanism I can imagine. It's pretty much a=20 > violation of every SIP extensibility principle every discussed. >=20 > Also, adding bodythings to response messages is a bad idea (read: =20 > pretty much completely forbidden) because we have no way to=20 > manage size and fragmentation on responses delivered over UDP. >=20 Moreover you have no means of indicating that the body was received as ther= e is no response to the response. Therefore essentially you are just using = the SIP message body as a transport mechanism, without any of the external = feature of SIP. Which leads to the question of why do you need to embed thi= s in SIP in the first place. > > If Recv-Info header can be decoupled with new SIP INFO, it=20 > could be ok=20 > > to use it for this function. >=20 >=20 > You mean you want to use Recv-Info in the INVITE request to=20 > tell the UAS it can send a special XML body back in the 200 OK? > > > > Timer modification function should be always available=20 > which means the=20 > > UAC always support it. It does not require the UAC to indicate it=20 > > supports using Recv-Info nor indicate it is willing to be changed. > > >=20 > Why would a UAC always support it? Not a single one of the=20 > UAs I currently have supports it. It seems like a totally=20 > proprietary hack that only a few 3GPP-compliant UAs would=20 > support. Definitely the kind of thing that requires feature=20 > negotiation. >=20 This has so far not been anywhere near 3GPP. > ... >=20 > > > > In IETF, the current draft is really confusing about capability=20 > > support and indicating willingness. Recv-Info header is used to=20 > > indicate the support for SIP INFO framework. It is also used to=20 > > indicate willingness. The error 469 was for that purpose as=20 > well. We=20 > > think two concepts are not the same and should be clearly described. >=20 > 469 is a dialog-terminating error condition. It's much better=20 > to just not send the offending message because you know the=20 > other end isn't capable and willing than it is to make your=20 > dialog explode and die. >=20 Yes, given that the main purpose of SIP is to establish your dialog, and th= e INFO transfer requirements at best can be regarded as auxiliary. If your = requirements put the precedence the other way round, why are you using SIP. > -- > Dean >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From tianlinyi@huawei.com Sun Sep 27 18:20:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4FA3A68E9 for ; Sun, 27 Sep 2009 18:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG9bZGxlXGfy for ; Sun, 27 Sep 2009 18:20:24 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 955B13A68B4 for ; Sun, 27 Sep 2009 18:20:24 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQN002L7QFU0H@szxga04-in.huawei.com> for sipcore@ietf.org; Mon, 28 Sep 2009 09:21:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQN00ARMQFU89@szxga04-in.huawei.com> for sipcore@ietf.org; Mon, 28 Sep 2009 09:21:30 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQN00M67QFUDG@szxml04-in.huawei.com> for sipcore@ietf.org; Mon, 28 Sep 2009 09:21:30 +0800 (CST) Date: Mon, 28 Sep 2009 09:21:30 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , 'Dean Willis' Message-id: <00ab01ca3fda$02551030$06ff3090$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco/Fkj/u5fWgHnHSvO0brJHsXZZNgACDL9wABLBK/8AHAr1oA== References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about Willingness andCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 01:20:25 -0000 > > Thrid, for configuration and management, I would assume that indicating willingess to > receive is "hard coded" into the user equipment by the operator and/or manufacturer, ie > the user can not choose whehter he wants to receive conf/mgmnt Info Packages. > [Linyi TIAN] Hard coded is one way. For this configuration feature, is SIP INFO framework the best mechanism to be used? Is there any other alternatives? From christer.holmberg@ericsson.com Mon Sep 28 00:04:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018B73A6835 for ; Mon, 28 Sep 2009 00:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9VW+36eQrh0 for ; Mon, 28 Sep 2009 00:04:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CC4B13A67D2 for ; Mon, 28 Sep 2009 00:04:00 -0700 (PDT) X-AuditID: c1b4fb3e-b7b0bae000006015-bb-4ac0602cf27b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 00.7C.24597.C2060CA4; Mon, 28 Sep 2009 09:05:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 09:05:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Sep 2009 09:03:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation Thread-Index: Aco/Fkj/u5fWgHnHSvO0brJHsXZZNgACDL9wABLBK/8AHAr1oAAMCuBW References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> <00ab01ca3fda$02551030$06ff3090$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Dean Willis" X-OriginalArrivalTime: 28 Sep 2009 07:05:16.0398 (UTC) FILETIME=[082518E0:01CA400A] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 07:04:02 -0000 You CAN NOT use the I-P mechanism to negotiate what you are going to = send in a 200 OK response.=20 As I said, in your case you should use the Accept header (eventhough = sending stuff in the 200 response in general is not a good idea, as = indicated by Dean). Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Linyi TIAN [mailto:tianlinyi@huawei.com] L=E4hetetty: ma 28.9.2009 3:21 Vastaanottaja: Christer Holmberg; 'Dean Willis' Kopio: 'SIPCORE' Aihe: RE: [sipcore] (Info event) Questions about = WillingnessandCapabilitynegotiation =20 >=20 > Thrid, for configuration and management, I would assume that = indicating willingess to > receive is "hard coded" into the user equipment by the operator and/or manufacturer, ie > the user can not choose whehter he wants to receive conf/mgmnt Info Packages. >=20 [Linyi TIAN] Hard coded is one way. For this configuration feature, is = SIP INFO framework the best mechanism to be used? Is there any other alternatives?=20 From tianlinyi@huawei.com Mon Sep 28 01:11:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C683A67AF for ; Mon, 28 Sep 2009 01:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMdJwnFTrGjw for ; Mon, 28 Sep 2009 01:11:41 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8623E3A63CB for ; Mon, 28 Sep 2009 01:11:41 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQO002ED9FIG7@szxga04-in.huawei.com> for sipcore@ietf.org; Mon, 28 Sep 2009 16:11:42 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQO001KC9FID0@szxga04-in.huawei.com> for sipcore@ietf.org; Mon, 28 Sep 2009 16:11:42 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQO009KJ9FHS0@szxml06-in.huawei.com> for sipcore@ietf.org; Mon, 28 Sep 2009 16:11:42 +0800 (CST) Date: Mon, 28 Sep 2009 16:11:41 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , 'Dean Willis' Message-id: <011d01ca4013$4fd22990$ef767cb0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco/Fkj/u5fWgHnHSvO0brJHsXZZNgACDL9wABLBK/8AHAr1oAAMCuBWAAJHUxA= References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> <00ab01ca3fda$02551030$06ff3090$@com> Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 08:11:42 -0000 > > You CAN NOT use the I-P mechanism to negotiate what you are going to send in a 200 > OK response. [Linyi TIAN] I never said I will use I-P to do this. I mean for this administration feature we may not use this I-D at all if Recv-Info is mandated. So please read my question again: > [Linyi TIAN] Hard coded is one way. For this configuration feature, is SIP > INFO framework the best mechanism to be used? Is there any other > alternatives? From christer.holmberg@ericsson.com Mon Sep 28 02:00:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B843A67FF for ; Mon, 28 Sep 2009 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vO6GvIs3xON for ; Mon, 28 Sep 2009 02:00:15 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8CE5E3A67F9 for ; Mon, 28 Sep 2009 02:00:14 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-38-4ac07b6ad065 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 17.D9.22406.A6B70CA4; Mon, 28 Sep 2009 11:01:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 11:01:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Sep 2009 11:01:29 +0200 Message-ID: In-Reply-To: <011d01ca4013$4fd22990$ef767cb0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation Thread-Index: Aco/Fkj/u5fWgHnHSvO0brJHsXZZNgACDL9wABLBK/8AHAr1oAAMCuBWAAJHUxAAAX/XgA== References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> <00ab01ca3fda$02551030$06ff3090$@com> <011d01ca4013$4fd22990$ef767cb0$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Dean Willis" X-OriginalArrivalTime: 28 Sep 2009 09:01:29.0832 (UTC) FILETIME=[44A2AE80:01CA401A] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 09:00:15 -0000 Hi,=20 >>You CAN NOT use the I-P mechanism to negotiate what you are going to send in a 200 OK response. > >[Linyi TIAN] I never said I will use I-P to do this. > >I mean for this administration feature we may not use this I-D at all if Recv-Info is mandated. So please read my question again: Your question was whether there are other alternatives for UA configuration, right? I think there are a number of other alternatives. In fact, I have never heard about INFO being used for UA configuration. INFOs can only be sent within a session, and that would mean that you can't configure the UA unless it has established a session... Or, are you talking about configuration which IS specific to the ongoing session? In any case, assuming you would use INFO, I still don't understand why can't use Recv-Info. If the UA is going to implement support of the I-P, why can't it implement support of the Recv-Info??? Regards, Christer From dean.willis@softarmor.com Mon Sep 28 12:43:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4AB3A69FE for ; Mon, 28 Sep 2009 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KrXf7McH5O3 for ; Mon, 28 Sep 2009 12:43:08 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 174403A6A07 for ; Mon, 28 Sep 2009 12:43:08 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8SJiBgv005731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2009 14:44:13 -0500 Message-Id: <3462E31D-532E-44A2-A99A-861A8C4D525E@softarmor.com> From: Dean Willis To: Linyi TIAN In-Reply-To: <011d01ca4013$4fd22990$ef767cb0$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 14:44:06 -0500 References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> <00ab01ca3fda$02551030$06ff3090$@com> <011d01ca4013$4fd22990$ef767cb0$@com> X-Mailer: Apple Mail (2.936) Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 19:43:09 -0000 On Sep 28, 2009, at 3:11 AM, Linyi TIAN wrote: >> >> You CAN NOT use the I-P mechanism to negotiate what you are going >> to send > in a 200 >> OK response. > > [Linyi TIAN] I never said I will use I-P to do this. > > I mean for this administration feature we may not use this I-D at > all if > Recv-Info is mandated. So please read my question again: > >> [Linyi TIAN] Hard coded is one way. For this configuration feature, >> is SIP >> INFO framework the best mechanism to be used? Is there any other >> alternatives? > > I'm guessing from my weak understanding of the proposal that either the SIP configuration framework or session policy framework might be closer to meeting your goals than an INFO package would be. See: http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15 http://tools.ietf.org/html/draft-ietf-sip-session-policy-framework-06 Specifically, if you are talking about a timer that is valid only for the current INVITE-initiated session, then the session-associated policy part of the session-policy draft would be most likely to be fruitful. If the timer is persistent across multiple sessions, then INFO would be completely wrong, and either the session-independent policy model of the session-policy draft might work, or the configuration framework. Or you could do what IETF and 3GPP probably should have done all along, which is to develop a straightforward HTTP/XML configuration model for SIP devices. -- Dean From mdolly@att.com Mon Sep 28 13:25:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418953A6933 for ; Mon, 28 Sep 2009 13:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEppJ3XLU07X for ; Mon, 28 Sep 2009 13:25:57 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 529973A682C for ; Mon, 28 Sep 2009 13:25:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1254169634!19616059!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 20820 invoked from network); 28 Sep 2009 20:27:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Sep 2009 20:27:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8SKREBQ020808 for ; Mon, 28 Sep 2009 16:27:14 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8SKR6ug020739 for ; Mon, 28 Sep 2009 16:27:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 28 Sep 2009 16:27:06 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4AAD@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions aboutWillingnessandCapabilitynegotiation Thread-Index: AcpAdCIytTVxLGoWQDuPf2S7KFa2DQABemzX From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sipcore@ietf.org Subject: Re: [sipcore] (Info event) Questions aboutWillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 20:25:58 -0000 TmVpdGhlciB3aWxsIGJlIGRlcGxveWVkDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0N CkZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyA8c2lwY29yZS1ib3VuY2VzQGlldGYub3Jn Pg0KVG86IExpbnlpIFRJQU4gPHRpYW5saW55aUBodWF3ZWkuY29tPg0KQ2M6ICdTSVBDT1JFJyA8 c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6IE1vbiBTZXAgMjggMTU6NDQ6MDYgMjAwOQ0KU3ViamVj dDogUmU6IFtzaXBjb3JlXSAoSW5mbyBldmVudCkgUXVlc3Rpb25zIGFib3V0V2lsbGluZ25lc3Nh bmRDYXBhYmlsaXR5bmVnb3RpYXRpb24NCg0KDQpPbiBTZXAgMjgsIDIwMDksIGF0IDM6MTEgQU0s IExpbnlpIFRJQU4gd3JvdGU6DQoNCj4+DQo+PiBZb3UgQ0FOIE5PVCB1c2UgdGhlIEktUCBtZWNo YW5pc20gdG8gbmVnb3RpYXRlIHdoYXQgeW91IGFyZSBnb2luZyAgDQo+PiB0byBzZW5kDQo+IGlu IGEgMjAwDQo+PiBPSyByZXNwb25zZS4NCj4NCj4gW0xpbnlpIFRJQU5dIEkgbmV2ZXIgc2FpZCBJ IHdpbGwgdXNlIEktUCB0byBkbyB0aGlzLg0KPg0KPiBJIG1lYW4gZm9yIHRoaXMgYWRtaW5pc3Ry YXRpb24gZmVhdHVyZSB3ZSBtYXkgbm90IHVzZSB0aGlzIEktRCBhdCAgDQo+IGFsbCBpZg0KPiBS ZWN2LUluZm8gaXMgbWFuZGF0ZWQuIFNvIHBsZWFzZSByZWFkIG15IHF1ZXN0aW9uIGFnYWluOg0K Pg0KPj4gW0xpbnlpIFRJQU5dIEhhcmQgY29kZWQgaXMgb25lIHdheS4gRm9yIHRoaXMgY29uZmln dXJhdGlvbiBmZWF0dXJlLCAgDQo+PiBpcyBTSVANCj4+IElORk8gZnJhbWV3b3JrIHRoZSBiZXN0 IG1lY2hhbmlzbSB0byBiZSB1c2VkPyBJcyB0aGVyZSBhbnkgb3RoZXINCj4+IGFsdGVybmF0aXZl cz8NCj4NCj4NCg0KSSdtIGd1ZXNzaW5nIGZyb20gbXkgd2VhayB1bmRlcnN0YW5kaW5nIG9mIHRo ZSBwcm9wb3NhbCB0aGF0IGVpdGhlciAgDQp0aGUgU0lQIGNvbmZpZ3VyYXRpb24gZnJhbWV3b3Jr IG9yIHNlc3Npb24gcG9saWN5IGZyYW1ld29yayBtaWdodCBiZSAgDQpjbG9zZXIgdG8gbWVldGlu ZyB5b3VyIGdvYWxzIHRoYW4gYW4gSU5GTyBwYWNrYWdlIHdvdWxkIGJlLg0KDQpTZWU6DQoNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwcGluZy1jb25maWctZnJhbWV3 b3JrLTE1DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwLXNlc3Np b24tcG9saWN5LWZyYW1ld29yay0wNg0KDQoNClNwZWNpZmljYWxseSwgaWYgeW91IGFyZSB0YWxr aW5nIGFib3V0IGEgdGltZXIgdGhhdCBpcyB2YWxpZCBvbmx5IGZvciAgDQp0aGUgY3VycmVudCBJ TlZJVEUtaW5pdGlhdGVkIHNlc3Npb24sIHRoZW4gdGhlIHNlc3Npb24tYXNzb2NpYXRlZCAgDQpw b2xpY3kgcGFydCBvZiB0aGUgc2Vzc2lvbi1wb2xpY3kgZHJhZnQgd291bGQgYmUgbW9zdCBsaWtl bHkgdG8gYmUgIA0KZnJ1aXRmdWwuDQoNCklmIHRoZSB0aW1lciBpcyBwZXJzaXN0ZW50IGFjcm9z cyBtdWx0aXBsZSBzZXNzaW9ucywgdGhlbiBJTkZPIHdvdWxkICANCmJlIGNvbXBsZXRlbHkgd3Jv bmcsIGFuZCBlaXRoZXIgdGhlIHNlc3Npb24taW5kZXBlbmRlbnQgcG9saWN5IG1vZGVsICANCm9m IHRoZSBzZXNzaW9uLXBvbGljeSBkcmFmdCBtaWdodCB3b3JrLCBvciB0aGUgY29uZmlndXJhdGlv biBmcmFtZXdvcmsuDQoNCk9yIHlvdSBjb3VsZCBkbyB3aGF0IElFVEYgYW5kIDNHUFAgcHJvYmFi bHkgc2hvdWxkIGhhdmUgZG9uZSBhbGwgIA0KYWxvbmcsIHdoaWNoIGlzIHRvIGRldmVsb3AgYSBz dHJhaWdodGZvcndhcmQgSFRUUC9YTUwgY29uZmlndXJhdGlvbiAgDQptb2RlbCBmb3IgU0lQIGRl dmljZXMuDQoNCi0tDQpEZWFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From tianlinyi@huawei.com Mon Sep 28 17:36:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A76D3A68E8 for ; Mon, 28 Sep 2009 17:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EupO-Vp0I8Pn for ; Mon, 28 Sep 2009 17:36:14 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1220C3A68F4 for ; Mon, 28 Sep 2009 17:36:10 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQP009FRJ26D2@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 29 Sep 2009 08:37:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQP004CUJ26RE@szxga01-in.huawei.com> for sipcore@ietf.org; Tue, 29 Sep 2009 08:37:18 +0800 (CST) Received: from t34932n ([10.168.86.46]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQP0007PJ26YB@szxml04-in.huawei.com> for sipcore@ietf.org; Tue, 29 Sep 2009 08:37:18 +0800 (CST) Date: Tue, 29 Sep 2009 08:37:18 +0800 From: Linyi TIAN In-reply-to: <3462E31D-532E-44A2-A99A-861A8C4D525E@softarmor.com> To: 'Dean Willis' Message-id: <021e01ca409c$ffcea8d0$ff6bfa70$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcpAdBXS2MSIXQw1RLSfhp0K3Lz7OgAJ81EQ References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> <00ab01ca3fda$02551030$06ff3090$@com> <011d01ca4013$4fd22990$ef767cb0$@com> <3462E31D-532E-44A2-A99A-861A8C4D525E@softarmor.com> Cc: 'SIPCORE' Subject: Re: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 00:36:15 -0000 > If the timer is persistent across multiple sessions, then INFO would > be completely wrong, and either the session-independent policy model > of the session-policy draft might work, or the configuration framework. [Linyi] You finally clarified my doubt. This is the guidance I am seeking for. The timer is to control the reporting frequency for watched content. So mostly the timer is persistent across multiple sessions. That's why I was thinking willingness is not needed for this configuration scenario and I believe there is an abuse for this I-D for this feature. What I heard in other SDO is that SIP INFO Framework is the only mechanism (or the correct one) to do this. I appreciate your effort to help clarify the alternatives. Cheers, Linyi > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, September 29, 2009 3:44 AM > To: Linyi TIAN > Cc: 'Christer Holmberg'; 'SIPCORE' > Subject: Re: [sipcore] (Info event) Questions about > WillingnessandCapabilitynegotiation > > > On Sep 28, 2009, at 3:11 AM, Linyi TIAN wrote: > > >> > >> You CAN NOT use the I-P mechanism to negotiate what you are going > >> to send > > in a 200 > >> OK response. > > > > [Linyi TIAN] I never said I will use I-P to do this. > > > > I mean for this administration feature we may not use this I-D at > > all if > > Recv-Info is mandated. So please read my question again: > > > >> [Linyi TIAN] Hard coded is one way. For this configuration feature, > >> is SIP > >> INFO framework the best mechanism to be used? Is there any other > >> alternatives? > > > > > > I'm guessing from my weak understanding of the proposal that either > the SIP configuration framework or session policy framework might be > closer to meeting your goals than an INFO package would be. > > See: > > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15 > > http://tools.ietf.org/html/draft-ietf-sip-session-policy-framework-06 > > > Specifically, if you are talking about a timer that is valid only for > the current INVITE-initiated session, then the session-associated > policy part of the session-policy draft would be most likely to be > fruitful. > > If the timer is persistent across multiple sessions, then INFO would > be completely wrong, and either the session-independent policy model > of the session-policy draft might work, or the configuration framework. > > Or you could do what IETF and 3GPP probably should have done all > along, which is to develop a straightforward HTTP/XML configuration > model for SIP devices. > > -- > Dean From pkyzivat@cisco.com Mon Sep 28 17:39:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1945B3A68B1 for ; Mon, 28 Sep 2009 17:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIqmEfbrrTbT for ; Mon, 28 Sep 2009 17:39:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 118513A681E for ; Mon, 28 Sep 2009 17:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2890; q=dns/txt; s=sjiport02001; t=1254184865; x=1255394465; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20Route=20registration=20(was=20Re:=20 rfc4244bis:=20what=20is=20an=0D=0A=20AoR?)|Date:=20Mon, =2028=20Sep=202009=2020:41:02=20-0400|Message-ID:=20<4AC1 579E.3090307@cisco.com>|To:=20Dean=20Willis=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20=20SIPCORE =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<0BC1DC 5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> |References:=20<4A5FAF4E.4030901@cisco.com>=09<1ECE0EB503 88174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> =09<8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com>=09<1 ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nor tel.com>=09<7402509E63C5A145A6095D46C179A5B705C6D11D@DEMC HP99E35MSX.ww902.siemens.net>=09<1ECE0EB50388174790F9694F 77522CCF203B1273@zrc2hxm0.corp.nortel.com>=09<7402509E63C 5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemen s.net>=09<1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hx m0.corp.nortel.com>=09<9ae56b1e0909241127k6ec043a7vcdec27 bf81bfa9c@mail.gmail.com>=09<1ECE0EB50388174790F9694F7752 2CCF203EF111@zrc2hxm0.corp.nortel.com>=09<9ae56b1e0909241 147w3e3662depe305f8f5e1e1900@mail.gmail.com>=09<7402509E6 3C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siem ens.net>=20<0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycoun cil.com>; bh=AgET6oiIJr+6LF8qooRmxY5W2nEfL/NQHEJgr2iSy2s=; b=JuyvETCeqCC+AGc35f/2az/ij2MwCH+cWQrS91Lhs/Ds5VCvSJDQtbgX ecPICaqm1loKAMlmM/Likfm4jf1AlQn9MwahqzlUQ2XxrY0VRLeQMXviJ o7DI3LTsdUCaXDQFDbrev36MR9HSLPdbe/9fJ7xhaQhFg5PVqCrxqli4W 4=; Authentication-Results: sj-iport-2.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAP0wEqrR7PE/2dsb2JhbADAJYhTAY5uBYQe X-IronPort-AV: E=Sophos;i="4.44,469,1249257600"; d="scan'208";a="209065072" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2009 00:41:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8T0f5sp022107; Mon, 28 Sep 2009 17:41:05 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8T0f48T020299; Tue, 29 Sep 2009 00:41:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 20:41:04 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 20:41:04 -0400 Message-ID: <4AC1579E.3090307@cisco.com> Date: Mon, 28 Sep 2009 20:41:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> In-Reply-To: <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2009 00:41:04.0372 (UTC) FILETIME=[867AD340:01CA409D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2890; t=1254184865; x=1255048865; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Route=20registration=20(was =20Re=3A=20rfc4244bis=3A=20what=20is=20an=0A=20AoR?) |Sender:=20; bh=AgET6oiIJr+6LF8qooRmxY5W2nEfL/NQHEJgr2iSy2s=; b=UYy/PDh02VslZNKx1t+i7rDKM2ADkLWQIqP7rzoQRWr5ULnfKgCXoWkBMW A2itDqU1JzyXsQ4KUmTLcC3UoEZCn6PybShforH1UzpoLW8kM2Ortq12mcBi DsVFbt+63t; Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is an AoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 00:39:47 -0000 Dean, IIUC you have just reinvented Jonathan's loose routing registration proposal. Thanks, Paul Dean Willis wrote: > > On Sep 24, 2009, at 2:52 PM, Elwell, John wrote: > >> Just to be clear, I do not have a specific requirement for finding the >> freephone number. I was merely pointing out that it seems very >> difficult to solve using a generic mechanism. > > My general philosophy is that if something is appearing to be hard to > solve, perhaps we're going about it entirely the wrong way. > > For example: Perhaps freephone routing shouldn't be handled by SIP > retargeting or rerouting mechanisms like contact-routing. Perhaps it > could be handled entirely by SIP rerouting operations. > > There are a lot of forms this can take. One might be in the area of > doing something analogous to REGISTER that registers a "route", not a > "contact". Such a "route registration" might be wildcard prefixable, > which would also handle the "domain registration" case being raised by > Alan Johnston and Richard Shockey. Further, it could eliminate much of > the unanticipated respondent problem of contact routing (as we have no > current way to determine whether contact-routing is rerouting or > retargeting). Oddly enough, this solution also preserves URI parameters > of all sorts . . . > > The difference between "contact routing" and just "routing" in a proxy > is straightforward. If the next-hop URL is a "contact", we use RFC 3261 > contact-routing procedures, replacing the request-URI with the > registered contact. If however the next-hop URL is a "route", we use RFC > 3261 loose-route procedures and push the URL onto the route stack and > ship out the request with an unmodified request URI. Net result, the > request is delivered to the next hop with an unmodified URL, ostensibly > including the freephone number. > > If the next hop is terminal (the UAS), it of course needs to be able to > recognize the freephone number as belonging to it, but that seems to be > a requirement of all the things that require looking for a freephone > number in the H_I stack anyhow. Handling freephone termination on legacy > contact-registering devices would require fronting them with a > "routing-aware" B2BUA, which seems imminently doable. > > The simplest approach might be a flag on the contact-value in a REGISTER > request that indicates the thing being registered is a route, not a > contact. Or a new header field could be used instead of Contact. This > does raise some interesting questions about route > authorization/authentication, but there should be a lot of work we could > fall back on here. > > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dean.willis@softarmor.com Mon Sep 28 20:50:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4406B3A6A33 for ; Mon, 28 Sep 2009 20:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX+hOLnjL6Pn for ; Mon, 28 Sep 2009 20:50:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6FA383A6A26 for ; Mon, 28 Sep 2009 20:50:39 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8T3oawr008743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2009 22:50:37 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <4AC1579E.3090307@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 22:50:30 -0500 References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is an AoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 03:50:40 -0000 On Sep 28, 2009, at 7:41 PM, Paul Kyzivat wrote: > Dean, > > IIUC you have just reinvented Jonathan's loose routing registration > proposal. > > Well, I'm trying to take a slightly different approach to it, primarily by applying it to the wildcard registration problem. I think I've also eliminated all the guesswork on subcases, making proxy behavior arguably more deterministic than it might have been in Jonathan's original proposal. And the questionable usage of Supported and Requires for negotiation is right out. There's also no need for confusing discussion of GRUU minting in the UA. The cleanest approach, in my current humble opinion (IMCHO), is to add a new SIP method that registers a route (or maybe multiple routes)" instead of registering a contact. We might think of this as analogous to BGP UPDATE route advertisements. I propose the RUPDATE method name for SIP. So, IIUC, I'd say "reprised" rather than "reinvented". But yeah, it owes a lot to JDR's work on ua-loose-route. Any benefit we get in terms of parameter delivery, retention of URI's etc. is actually just side-effect from cleaning up the semantic model of message routing. -- Dean From dean.willis@softarmor.com Mon Sep 28 21:37:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C1E3A6906 for ; Mon, 28 Sep 2009 21:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7+auXqyohpR for ; Mon, 28 Sep 2009 21:37:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0E3703A67D3 for ; Mon, 28 Sep 2009 21:37:26 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8T4cWkY009100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2009 23:38:36 -0500 Message-Id: <550E3029-32F3-4C42-AB13-10B89B4ABF4F@softarmor.com> From: Dean Willis To: "DOLLY, MARTIN C, ATTLABS" In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4AAD@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 23:38:26 -0500 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4AAD@gaalpa1msgusr7e.ugd.att.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org, tianlinyi@huawei.com Subject: Re: [sipcore] (Info event) Questions aboutWillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 04:37:27 -0000 On Sep 28, 2009, at 3:27 PM, DOLLY, MARTIN C, ATTLABS wrote: > Dean said: > >> I'm guessing from my weak understanding of the proposal that either >> the SIP configuration framework or session policy framework might >> be closer to meeting your goals than an INFO package would be. > > Neither will be deployed > Well, there is that little detail. However, reading these drafts might get us closer to an understanding of the actual goal here, and could suggest a way to make it happen that is better than relying on spurious-INFO-messages-from-heaven. So the question is: Is the problem Linyi is working to solve more like one of these drafts than it is like what we think INFO packages were meant to do? -- Dean From christer.holmberg@ericsson.com Tue Sep 29 00:02:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DCDA3A6A47 for ; Tue, 29 Sep 2009 00:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVbVBPEF3yhM for ; Tue, 29 Sep 2009 00:02:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 07A243A680E for ; Tue, 29 Sep 2009 00:02:23 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-9c-4ac1b14d1d4a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 36.1F.15624.D41B1CA4; Tue, 29 Sep 2009 09:03:42 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 09:03:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Sep 2009 09:03:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation Thread-Index: AcpAdBXS2MSIXQw1RLSfhp0K3Lz7OgAJ81EQAA1+kBY= References: <022201ca3d8e$4a20e2c0$de62a840$@com> <024801ca3db0$12984d30$37c8e790$@com> <032701ca3f0c$026ac6b0$07405410$@com> <000401ca3f1f$c7d8ca10$578a5e30$@com> <00ab01ca3fda$02551030$06ff3090$@com> <011d01ca4013$4fd22990$ef767cb0$@com> <3462E31D-532E-44A2-A99A-861A8C4D525E@softarmor.com> <021e01ca409c$ffcea8d0$ff6bfa70$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "Dean Willis" X-OriginalArrivalTime: 29 Sep 2009 07:03:26.0612 (UTC) FILETIME=[F11ED540:01CA40D2] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 07:02:25 -0000 Hi, >>If the timer is persistent across multiple sessions, then INFO would >>be completely wrong, and either the session-independent policy model >>of the session-policy draft might work, or the configuration = framework. > >[Linyi] You finally clarified my doubt. This is the guidance I am = seeking >for. The timer is to control the reporting frequency for watched = content. So >mostly the timer is persistent across multiple sessions.=20 > >That's why I was thinking willingness is not needed for this = configuration >scenario and I believe there is an abuse for this I-D for this feature. = What >I heard in other SDO is that SIP INFO Framework is the only mechanism = (or >the correct one) to do this.=20 > >I appreciate your effort to help clarify the alternatives. I think there are two issues here: The FIRST one is how you want to use Info Packages, by sending packages = to clients who haven't indicated support of them. I hope we can agree = that it will not be allowed in the I-P spec. SECOND, you ask whether I-P is the most appropriate mechanism for your = use-case in the first place. Based on the discussion so far, that does = not seem to be the case. I guess you COULD use INFO, in which case the = UA would have to insert Recv-Info, but I think you should look into = other alternatives also. Regards, Christer > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, September 29, 2009 3:44 AM > To: Linyi TIAN > Cc: 'Christer Holmberg'; 'SIPCORE' > Subject: Re: [sipcore] (Info event) Questions about > WillingnessandCapabilitynegotiation >=20 >=20 > On Sep 28, 2009, at 3:11 AM, Linyi TIAN wrote: >=20 > >> > >> You CAN NOT use the I-P mechanism to negotiate what you are going > >> to send > > in a 200 > >> OK response. > > > > [Linyi TIAN] I never said I will use I-P to do this. > > > > I mean for this administration feature we may not use this I-D at > > all if > > Recv-Info is mandated. So please read my question again: > > > >> [Linyi TIAN] Hard coded is one way. For this configuration feature, > >> is SIP > >> INFO framework the best mechanism to be used? Is there any other > >> alternatives? > > > > >=20 > I'm guessing from my weak understanding of the proposal that either > the SIP configuration framework or session policy framework might be > closer to meeting your goals than an INFO package would be. >=20 > See: >=20 > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15 >=20 > http://tools.ietf.org/html/draft-ietf-sip-session-policy-framework-06 >=20 >=20 > Specifically, if you are talking about a timer that is valid only for > the current INVITE-initiated session, then the session-associated > policy part of the session-policy draft would be most likely to be > fruitful. >=20 > If the timer is persistent across multiple sessions, then INFO would > be completely wrong, and either the session-independent policy model > of the session-policy draft might work, or the configuration = framework. >=20 > Or you could do what IETF and 3GPP probably should have done all > along, which is to develop a straightforward HTTP/XML configuration > model for SIP devices. >=20 > -- > Dean From root@core3.amsl.com Tue Sep 29 03:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CD5653A6857; Tue, 29 Sep 2009 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090929101501.CD5653A6857@core3.amsl.com> Date: Tue, 29 Sep 2009 03:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 10:15:01 -0000 --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 Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : E. Burger, et al. Filename : draft-ietf-sipcore-info-events-01.txt Pages : 33 Date : 2009-09-29 This document provides new semantics for the SIP INFO method of RFC 2976. These new semantics defined here are fully backwards compatible with the old semantics. Core to the new semantics is a mechanism for defining, indicating support of, and exchanging Info Packages that use the INFO method. Applications that need to exchange application information within a SIP invite usage dialog (RFC 5057), can use these Info Packages. This document replaces RFC 2976 but still allows existing legacy INFO usages as defined in RFC 2976. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-info-events-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-29031158.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Tue Sep 29 03:20:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747733A67AA for ; Tue, 29 Sep 2009 03:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlmFYYmyEaSd for ; Tue, 29 Sep 2009 03:20:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CADEE3A6812 for ; Tue, 29 Sep 2009 03:20:55 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-33-4ac1dfb1607c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 29.DF.15624.1BFD1CA4; Tue, 29 Sep 2009 12:21:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 12:21:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA40EE.A04EE155" Date: Tue, 29 Sep 2009 12:21:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-01 Thread-Index: AcpA7p/1L8xj8zCwSuGtNUkRn33/hw== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 29 Sep 2009 10:21:37.0151 (UTC) FILETIME=[A06F18F0:01CA40EE] X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan , Gonzalo Camarillo Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 10:20:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA40EE.A04EE155 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable INFO lovers, INFO haters, and those who couldn't care less, Based on the earlier comments, WGLC comments, and the recent discussions, we've put together a new version of the info events draft. The comments we have got indicated confusion and inconsistancy about the terminology used (UAC/UAC, negotiation etc etc etc). We've really worked hard trying to fix that in the new version. However, that has meant quite big editorial changes in some places, so I really request people that have provided comments on earlier versions (and maybe even got their comments implemented later) to take a look and make sure they are ok with the text. You can also get the draft from: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-01 .txt Regards, Christer ------_=_NextPart_001_01CA40EE.A04EE155 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sipcore-info-events-01

INFO lovers, INFO haters, and those who = couldn't care less,

Based on the earlier comments, WGLC = comments, and the recent discussions, we've put together a new version = of the info events draft.

The comments we have got indicated = confusion and inconsistancy about the terminology used (UAC/UAC, = negotiation etc etc etc). We've really worked hard trying to fix that in = the new version. However, that has meant quite big editorial changes in = some places, so I really request people that have provided comments on = earlier versions (and maybe even got their comments implemented later) = to take a look and make sure they are ok with the text.

You can also get the draft from:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-= info-events-01.txt

Regards,

Christer

------_=_NextPart_001_01CA40EE.A04EE155-- From rjsparks@nostrum.com Tue Sep 29 11:36:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD78E28C170 for ; Tue, 29 Sep 2009 11:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-em+MEIJhUL for ; Tue, 29 Sep 2009 11:36:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D903E28C154 for ; Tue, 29 Sep 2009 11:36:14 -0700 (PDT) Received: from [192.168.2.2] (pool-173-71-53-15.dllstx.fios.verizon.net [173.71.53.15]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8TIbY0P003001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Sep 2009 13:37:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <4C1AFD39-F076-43C8-A73E-1867389C0FF8@nostrum.com> From: Robert Sparks To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-9-1064346966 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Sep 2009 13:37:33 -0500 References: <72A0E3C5-322B-4FEE-B565-9659581BBFC4@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.53.15 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: Several questions/suggestions from my review of draft-ietf-pmol-sip-perf-metrics-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 18:36:18 -0000 --Apple-Mail-9-1064346966 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit For those of you here who haven't been following PMOL, the group is finishing the definition of a set of end-to-end performance metrics for SIP. Here are some questions I just asked that group to look at. Please look them over - if they cause you to think of anything I've missed, please let me know (or better, join the discussion). Thanks, RjS Begin forwarded message: > From: Robert Sparks > Date: September 29, 2009 1:31:50 PM CDT > To: pmol@ietf.org > Cc: pmol-chairs@tools.ietf.org, Dan Romascanu > Subject: Several questions/suggestions from my review of draft-ietf- > pmol-sip-perf-metrics-04 > > Hi All - > > I have several concerns about draft-ietf-pmol-sip-perf-metrics that > I would like to discuss. > I've asked for a dedicated RAI-review of this document, so there may > be additional comments > later, but I wanted to get these to you now so we can start working > through them. > > These comments are more-or-less in document order, with a couple of > nits moved to the end. > I've numbered them to help split responses into threads later. When > replying to just one of the > items below, please change the subject line to indicate what you're > replying to. > > Thanks, > > RjS > > -------------------------------------------------------------------------------------------------- > > 1 The document should more carefully describe its scope (and consider > changing its title). This document focuses on the use of SIP for > simple telephony and relies on measurements in earlier telephony > networks for guidance. But telephony is only one use of SIP. These > aren't the same metrics that would be most useful for observing a > network that was involved primarily in setting up MSRP sessions for > file transfer, for instance. A eventual set of generic SIP > performance metrics will need to focus on the primitives rather than > artifacts from any particular application. > > 2 That said, I'm skeptical of the utility of many of these metrics > even > for monitoring systems that are focusing only on delivering basic > telephony. Has the group surveyed operators to see what they're > measuring, what they're finding useful, and what they're just > throwing away? Some additional text motivating why this particular > set of metrics were chosen should be provided to help > operators/implementers choose which ones they are going to try to > use. > > 3 "Each session is identified by a unique Call-ID" is incorrect. You > need at least Call-ID, to-tag, and from-tag here. And to be pedantic, > you're describing the SIP dialog, not one of the sessions it manages. > The session is what is described by the Session Description Protocol. > The metrics in this draft are derived from signaling events, not > session events, and is making assumptions about how those correlate > for a simple voice call that may not be true for more advanced uses. > > 4 The document is inconsistent about whether the metrics will describe > any part of an early-dialog/early session. The introduction indicates > it won't and focuses on the delivery of a 200 OK, but there are > metrics that measure the arrival time of 180s. This should be > reconciled. Do take note that early sessions are pervasive in real > deployments at this point in time. > > 5 These metrics are intentionally designed to not measure (or be > perturbed by) the hop-hop retransmission mechanisms. This should be > made explicit. There should also be some discussion of the effect of > the end-to-end retransmission of 200OK/ACK on the metrics based on > those messages. > > 6 The document should consider the effects of the presence or absence > of the reliable-provisional extension on its metrics (some of the > metrics will be perturbed by a lost 18x that isn't sent reliably). > > 7 Using T1 and T4 as the timing interval measurement tokens is > unfortunate. SIP uses those symbols already to mean something > completely different. Is there a reason not to change these and avoid > the confusion that the collision will cause? > > 8 The document uses the terms UAC and UAS incorrectly. It is trying to > use them to mean the initiator and recipient of a simple phone call. > But the terms are roles scoped to a particular transaction, not to a > dialog. When an endpoint sends a BYE request, it is by definition > acting as a UAC. > > 9 The document uses the word "dialog" in a way that's not the same as > the formal term with the same name defined in RFC3261 and that will > lead to confusion. (A sequence of register requests and responses, > for example, are never part of any dialog. The INVITE/302/ACK > messages shown in the call setup flows are not part of any dialog.) > Please choose another word or phrase for this draft. I suggest > "message exchange". > > 10 The 3rd to last paragraph of section 4 should be expanded. I think > it's unlikely that implementers, especially those with other language > backgrounds, will understand the subtlety of the quotes around > "final". Enumerating the cases where you want the measurement to > span from the request of one transaction to the final response of > some other transaction will help. (I'm guessing you were primarily > considering redirection, but I suspect you also wanted to capture the > additional delay due to Requires-based negotiation or 488 > not-acceptable-here style re-attempts?). You may also want to > consider the effect of the negotiation phase of extensions like > session-timer on these metrics. > > 11 The document assumes that a registration will be DIGEST challenged. > That's a common deployment model, but it is not required. If other > authentication mechanics are used (such as SIP Identity), the RRD > metric, for example, becomes muddied. > > 12 In section 4.2, "Subsequent REGISTER retries are identified by the > same Call-ID" should say "identified by the same transaction > identifier (same topmost Via header field branch parameter value". > Completely different REGISTER transactions from a given registrant > are likely to have the same Call-ID. > > 13 The SRD metric definition in 4.3.1 ignores the effect of forking. > Unlike 200 OKs, where receiving multiple 200s in response to a single > INVITE only happens if a race is won, it is the _normal_ state of > affairs for a UAC to receive provisional responses from multiple > branches when a request forks. Deployed systems are increasingly > sending 18x responses reliably with an answer, establishing early > sessions, so when forking is present it is _highly_ likely that there > will be multiple 18x's from different branches arriving at the UA. > This section should provide guidance on what to report when this > happens. > > 14 The Failed Session Setup SRD claims to be useful in detecting > problems in downstream signaling functions. Please provide some text > or a reference supporting that claim. As written, this metric could > be dominated by how long the called user lets his phone ring. Is that > what was intended? You might consider separate treatment for 408s and > for explicit decline response codes. > > 15 What was the motivation for making MESSAGE special in section > 4.3.3. > Why didn't the group instead extend the concept to measuring _any_ > non-INVITE transaction (with the possible exception of CANCEL)? > > 16 In section 4.4, what does it mean to measure the delay in the > disconnect of a failed session completion? Without a successful > session completion, there can be no BYE. This section also begs the > very hard to answer question about what to do when BYEs receive > failure responses. It would be better to note that edge-case exists > and what, if anything, the metric is going to say about it if it > happens. > > 17 Section 4.5 is a particularly strong example of these metrics > focusing on the simple telephony application. It may even be falling > into the same traps that lead to trying to build fraud-resistant > billing based on the time difference between an INVITE and a BYE. > Some additional discussion noting that the metric doesn't capture > early media and recommendation on when to give up on seeing a BYE > would be useful. (Sometimes BYEs don't happen even when there is no > malicious intent.) > > 18 Trying to use Max-Forwards to determine how many hops a request > took > is going to produce incorrect results in any but the most simple of > network deployments (I would have expected this to be based on > counting Vias with a note pointing to the discussion on the problems > B2BUAs introduce). Proxies can reduce Max-Forwards by more than one. > There are many implementations in the wild that cap Max-Forwards. If > this metric remains as defined, you should also point out that > neither endpoint can calculate it. Some third entity will have to > collect information from each end to make this calculation. > > 19 The ratio metrics don't define (or convey) the interval that totals > are taken over. Are these supposed to be "# requests received since > this instance was manufactured' or "since last reboot" or "since last > reset of statistics" or something else? What is the implementation > supposed to report when the denominator of a ratio is 0? > > 20 Please add some discussion motivating why all 300s, 401, 402, and > 407 > are treated specially (vrs several other candidate 4xx and 6xx > responses) in sections like section 4.8. Were other codes considered? > If so, why were they rejected? > > 21 Section 4.9 seems to be implying that you can't receive a 500 class > response to a reINVITE which is not true. If you want this metric to > only reflect the results of initial INVITEs, more definition will be > needed. > > 22 ISA in section 4.10 claims that 408s indicate an overloaded state > in > a downstream element. Overload may induce 408s, but 408s do _not_ > indicate overload. Its possible to receive them just because someone > is not answering a phone. > > 23 In section 5, why where these correlation dimensions chosen. Was > the > Request-URI considered? If so, why was it rejected? > > 24 The treatment of forking in section 6.3 is insufficient. As noted > earlier, provisional messages establishing early sessions is becoming > common, and there will be multiple early sessions for a given INVITE > when there is forking. The recommendation to latch onto the "first" > 200 (or 18x) and ignore the others only marginally works for playing > media for simple telephony applications - we're seeing phones that > mix or present multiple lines, and applications that go beyond basic > phone calls (like file transfer) that make use of all the responses. > Trying to dodge the complexity as the current section does will lead > to metrics that don't reflect what the network is doing. > > 25 I'm a little surprised there is no discussion on privacy, > particularly on profiling the usage patterns of individuals or > organizations, in the security considerations section. > > 26 Nits: > 26.1 What does it mean in section 4.3.1 for the "user" to send the > first bit of a message? Suggest deleting "or user" from the > sentence. > 26.2 Section 4.11 has a stale internal pointer to a non-existant > section 3.5 I suspect it's trying to point back into 4 somewhere. > --Apple-Mail-9-1064346966 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable For those of you here who = haven't been following PMOL, the group is finishing the definition of a = set
of end-to-end = performance metrics for SIP.

Here = are some questions I just asked that group to look at. Please look them = over - if  they cause
you to think of anything I've = missed, please let me know (or better, join the = discussion).

Thanks,

RjS=

Begin forwarded message:

From: = Robert Sparks <rjsparks@nostrum.com>
Date: September 29, 2009 1:31:50 PM = CDT
=
Subject: = Several questions/suggestions from my review of = draft-ietf-pmol-sip-perf-metrics-04

Hi All = -

I have several concerns about draft-ietf-pmol-sip-perf-metrics = that I would like to discuss.
I've asked for a dedicated RAI-review = of this document, so there may be additional comments
later, but I = wanted to get these to you now so we can start working through = them.

These comments are more-or-less in document order, with a = couple of nits moved to the end.
I've numbered them to help split = responses into threads later. When replying to just one of the
items = below, please change the subject line to indicate what you're replying = to.

Thanks,

RjS

-------------------------------------= -------------------------------------------------------------

1 = The document should more carefully describe its scope (and consider
=  changing its title). This document focuses on the use of SIP = for
 simple telephony and relies on measurements in earlier = telephony
 networks for guidance.  But telephony is only = one use of SIP. These
 aren't the same metrics that would be = most useful for observing a
 network that was involved = primarily in setting up MSRP sessions for
 file transfer, for = instance. A eventual set of generic SIP
 performance metrics = will need to focus on the primitives rather than
 artifacts = from any particular application.

2 That said, I'm skeptical of = the utility of many of these metrics even
 for monitoring = systems that are focusing only on delivering basic
 telephony. = Has the group surveyed operators to see what they're
=  measuring, what they're finding useful, and what they're just
=  throwing away? Some additional text motivating why this = particular
 set of metrics were chosen should be provided to = help
 operators/implementers choose which ones they are going = to try to use.

3 "Each session is identified by a unique Call-ID" = is incorrect. You
 need at least Call-ID, to-tag, and from-tag = here. And to be pedantic,
 you're describing the SIP dialog, = not one of the sessions it manages.
 The session is what is = described by the Session Description Protocol.
 The metrics in = this draft are derived from signaling events, not
 session = events, and is making assumptions about how those correlate
=  for a simple voice call that may not be true for more advanced = uses.

4 The document is inconsistent about whether the metrics = will describe
 any part of an early-dialog/early session. The = introduction indicates
 it won't and focuses on the delivery of = a 200 OK, but there are
 metrics that measure the arrival time = of 180s. This should be
 reconciled. Do take note that early = sessions are pervasive in real
 deployments at this point in = time.

5 These metrics are intentionally designed to not measure = (or be
 perturbed by) the hop-hop retransmission mechanisms. = This should be
 made explicit. There should also be some = discussion of the effect of
 the end-to-end retransmission of = 200OK/ACK on the metrics based on
 those messages.

6 The = document should consider the effects of the presence or absence
=  of the reliable-provisional extension on its metrics (some of = the
 metrics will be perturbed by a lost 18x that isn't sent = reliably).

7 Using T1 and T4 as the timing interval measurement = tokens is
 unfortunate. SIP uses those symbols already to mean = something
 completely different. Is there a reason not to = change these and avoid
 the confusion that the collision will = cause?

8 The document uses the terms UAC and UAS incorrectly. It = is trying to
 use them to mean the initiator and recipient of a = simple phone call.
 But the terms are roles scoped to a = particular transaction, not to a
 dialog. When an endpoint = sends a BYE request, it is by definition
 acting as a = UAC.

9 The document uses the word "dialog" in a way that's not = the same as
 the formal term with the same name defined in = RFC3261 and that will
 lead to confusion. (A sequence of = register requests and responses,
 for example, are never part = of any dialog. The INVITE/302/ACK
 messages shown in the call = setup flows are not part of any dialog.)
 Please choose another = word or phrase for this draft. I suggest
 "message = exchange".

10 The 3rd to last paragraph of section 4 should be = expanded. I think
 it's unlikely that implementers, especially = those with other language
 backgrounds,  will understand = the subtlety of the quotes around
 "final".  Enumerating = the cases where you want the measurement to
 span from the = request of one transaction to the final response of
 some other = transaction will help. (I'm guessing you were primarily
=  considering redirection, but I suspect you also wanted to capture = the
 additional delay due to Requires-based negotiation or = 488
 not-acceptable-here style re-attempts?). You may also want = to
 consider the effect of the negotiation phase of extensions = like
 session-timer on these metrics.

11 The document = assumes that a registration will be DIGEST challenged.
 That's = a common deployment model, but it is not required. If other
=  authentication mechanics are used (such as SIP Identity), the = RRD
 metric, for example, becomes muddied.

12 In section = 4.2, "Subsequent REGISTER retries are identified by the
 same = Call-ID" should say "identified by the same transaction
=  identifier (same topmost Via header field branch parameter = value".
 Completely different REGISTER transactions from a = given registrant
 are likely to have the same = Call-ID.

13 The SRD metric definition in 4.3.1 ignores the effect = of forking.
 Unlike 200 OKs, where receiving multiple 200s in = response to a single
 INVITE only happens if a race is won, it = is the _normal_ state of
 affairs for a UAC to receive = provisional responses from multiple
 branches when a request = forks. Deployed systems are increasingly
 sending 18x responses = reliably with an answer, establishing early
 sessions, so when = forking is present it is _highly_ likely that there
 will be = multiple 18x's from different branches arriving at the UA.
=  This section should provide guidance on what to report when = this
 happens.

14 The Failed Session Setup SRD claims to = be useful in detecting
 problems in downstream signaling = functions. Please provide some text
 or a reference supporting = that claim. As written, this metric could
 be dominated by how = long the called user lets his phone ring. Is that
 what was = intended? You might consider separate treatment for 408s and
=  for explicit decline response codes.

15 What was the = motivation for making MESSAGE special in section 4.3.3.
 Why = didn't the group instead extend the concept to measuring _any_
=  non-INVITE transaction (with the possible exception of = CANCEL)?

16 In section 4.4, what does it mean to measure the = delay in the
 disconnect of a failed session completion? = Without a successful
 session completion, there can be no BYE. = This section also begs the
 very hard to answer question about = what to do when BYEs receive
 failure responses. It would be = better to note that edge-case exists
 and what, if anything, = the metric is going to say about it if it
 happens.

17 = Section 4.5 is a particularly strong example of these metrics
=  focusing on the simple telephony application. It may even be = falling
 into the same traps that lead to trying to build = fraud-resistant
 billing based on the time difference between = an INVITE and a BYE.
 Some additional discussion noting that = the metric doesn't capture
 early media and recommendation on = when to give up on seeing a BYE
 would be useful. (Sometimes = BYEs don't happen even when there is no
 malicious = intent.)

18 Trying to use Max-Forwards to determine how many hops = a request took
 is going to produce incorrect results in any = but the most simple of
 network deployments (I would have = expected this to be based on
 counting Vias with a note = pointing to the discussion on the problems
 B2BUAs introduce). = Proxies  can reduce Max-Forwards by more than one.
 There = are many implementations in the wild that cap Max-Forwards. If
=  this metric remains as defined, you should also point out that
=  neither endpoint can calculate it. Some third entity will have = to
 collect information from each end to make this = calculation.

19 The ratio metrics don't define (or convey) the = interval that totals
 are taken over. Are these supposed to be = "# requests received since
 this instance was manufactured' or = "since last reboot" or "since last
 reset of statistics" or = something else? What is the implementation
 supposed to report = when the denominator of a ratio is 0?

20 Please add some = discussion motivating why all 300s, 401, 402, and 407
 are = treated specially (vrs several other candidate 4xx and 6xx
=  responses) in sections like section 4.8. Were other codes = considered?
 If so, why were they rejected?

21 Section = 4.9 seems to be implying that you can't receive a 500 class
=  response to a reINVITE which is not true. If you want this metric = to
 only reflect the results of initial INVITEs, more = definition will be
 needed.

22 ISA in section 4.10 = claims that 408s indicate an overloaded state in
 a downstream = element. Overload may induce 408s, but 408s do _not_
 indicate = overload. Its possible to receive them just because someone
 is = not answering a phone.

23 In section 5, why where these = correlation dimensions chosen. Was the
 Request-URI considered? = If so, why was it rejected?

24 The treatment of forking in = section 6.3 is insufficient. As noted
 earlier, provisional = messages establishing early sessions is becoming
 common, and = there will be multiple early sessions for a given INVITE
 when = there is forking. The recommendation to latch onto the "first"
=  200 (or 18x) and ignore the others only marginally works for = playing
 media for simple telephony applications - we're seeing = phones that
 mix or present multiple lines, and applications = that go beyond basic
 phone calls (like file transfer) that = make use of all the responses.
 Trying to dodge the complexity = as the current section does will lead
 to metrics that don't = reflect what the network is doing.

25 I'm a little surprised = there is no discussion on privacy,
 particularly on profiling = the usage patterns of individuals or
 organizations, in the = security considerations section.

26 Nits:
=    26.1 What does it mean in section 4.3.1 for the "user" = to send the
     first bit of a message? = Suggest deleting "or user" from the
=      sentence.
   26.2 = Section 4.11 has a stale internal pointer to a non-existant
=      section 3.5 I suspect it's trying to point = back into 4 = somewhere.


= --Apple-Mail-9-1064346966-- From dworley@nortel.com Wed Sep 30 14:17:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01D43A680F for ; Wed, 30 Sep 2009 14:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2iKDRtH96UT for ; Wed, 30 Sep 2009 14:17:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F3B193A6992 for ; Wed, 30 Sep 2009 14:17:03 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8ULICN18481; Wed, 30 Sep 2009 21:18:12 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 17:18:10 -0400 From: "Dale Worley" To: BeckW@telekom.de In-Reply-To: <4A956CE47D1066408D5C7EB34368A51104CD2BBE@S4DE8PSAAQC.mitte.t-com.de> References: <4A956CE47D1066408D5C7EB34368A51104CD2BBE@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 30 Sep 2009 17:18:09 -0400 Message-Id: <1254345489.4375.38.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2009 21:18:10.0207 (UTC) FILETIME=[82F02AF0:01CA4213] Cc: sipcore@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: Re: [sipcore] [Sip-implementors] Initial NOTIFY without state information X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 21:17:05 -0000 On Tue, 2009-08-04 at 13:13 +0200, BeckW@telekom.de wrote: > What should a notifier send in its initial NOTIFY if it doesn't have > valid state information? As you've described below, the definition of the event package is supposed to contain that information. > Do end devices handle NOTIFYs with an empty body properly? A good question. I expect that any subscriber would handle missing bodies sensibly. But it's a complicated question what "proper" handling might be. > What is a "neutral state"? > RfC 3265: > 'Documents which define new event packages MUST define > this "neutral state" in such a way that makes sense for their application' > > If they only would. Eg. RfC 3842 (MWI) doesn't seem to contain any hint about it. A good point -- that's a deficiency in the specs. Dale From dworley@nortel.com Wed Sep 30 14:30:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC103A677C; Wed, 30 Sep 2009 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-O8offLJgWT; Wed, 30 Sep 2009 14:30:44 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 26E663A6359; Wed, 30 Sep 2009 14:30:44 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8ULVvN21238; Wed, 30 Sep 2009 21:31:57 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 17:31:56 -0400 From: "Dale Worley" To: "Szilagyi, Mike" In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Organization: Nortel Networks Date: Wed, 30 Sep 2009 17:31:56 -0400 Message-Id: <1254346316.4375.48.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 30 Sep 2009 21:31:56.0994 (UTC) FILETIME=[6FBDDA20:01CA4215] Cc: "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [sipcore] Requests sent within early dialog -- CSeq mgmt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 21:30:45 -0000 On Wed, 2009-08-26 at 17:10 -0400, Szilagyi, Mike wrote: > I=E2=80=99ve not been able to find definitive text regarding this issue s= o I=E2=80=99m > hoping someone can provide clarification. If a request (INFO or > UPDATE) is sent on a dialog in the early state, how are the CSeq > numbers managed by the UAS. Here=E2=80=99s an example to demonstrate my > confusion: The model is that a CANCEL is not an independent transaction from the INVITE, in the way that the UPDATE is an independent transaction from the INVITE. Indeed, CANCEL isn't even routed the same way that the UPDATE is. A CANCEL transaction is sort of a "second half" of the INVITE transaction that it is canceling. That is why the CANCEL has the same CSeq as the INVITE. (Also, your example shows the UPDATE being sent by the UAC before it receives a non-100 response. That can't be done, since the UAC doesn't know the to-tag to use; there isn't an early dialog established at that point.) Dale