From ben@nostrum.com Tue Nov 1 12:01:51 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AED1F0D0A; Tue, 1 Nov 2011 12:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BXRktIDDwhv; Tue, 1 Nov 2011 12:01:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F51F0CD3; Tue, 1 Nov 2011 12:01:25 -0700 (PDT) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA1J1G8A005684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2011 14:01:18 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: Date: Tue, 1 Nov 2011 14:01:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9F4E0F23-DEE4-4BE6-97B7-49701F919E99@nostrum.com> References: <24518BC2-479A-4413-B69B-7DC5589751DC@nostrum.com> To: Alan Johnston X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 01 Nov 2011 12:15:10 -0700 Cc: "gen-art@ietf.org Review Team" , draft-ietf-cuss-sip-uui-reqs.all@tools.ietf.org, "Cuss@ietf.org" Subject: Re: [cuss] [Gen-art] Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:01:51 -0000 Hi Alan, That resolves all my concerns. However, it might be helpful to include = the two following explanations in the draft text. Thanks! Ben. On Oct 27, 2011, at 10:53 AM, Alan Johnston wrote: [=85] >>=20 >>=20 >> -- REQ-12:=20 >>=20 >> What degree of certainty is required here? (i.e. strong identity?) If = implied by the SIP dialog, does that impact expectations on what sort of = authn must happen at the SIP layer? >=20 > This is not meant to imply strong identity. And since UUI data can = appear in a response, there aren't really any strong methods available = with SIP. The UUI mechanism does not introduce stronger authorization = requirements for SIP, but instead the mechanism needs to be able to = utilize existing SIP approaches. >=20 >>=20 >> -- REQ 13: >>=20 >> I'm not sure I understand how this interacts with the ability for = intermediaries to remove UUI. Should this be detectable by the = endpoints? Or is that ability limited to the hop-by-hop case, or require = no integrity protection? >=20 > Yes, there are tradeoffs between this requirement and requirement = REQ-9. Hop-by-hop protection is one way to resolve this interaction. [=85]= From vkg@bell-labs.com Tue Nov 1 12:31:25 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADC51F0CC2 for ; Tue, 1 Nov 2011 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIfScQ5K+p8V for ; Tue, 1 Nov 2011 12:31:24 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B0D311F0CAE for ; Tue, 1 Nov 2011 12:31:24 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pA1JTopV009078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Nov 2011 14:29:50 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA1JTnaG031447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Nov 2011 14:29:50 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA1JTngM027477 for ; Tue, 1 Nov 2011 14:29:49 -0500 (CDT) Message-ID: <4EB04961.5020905@bell-labs.com> Date: Tue, 01 Nov 2011 14:32:49 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Draft meeting minutes for virtual interim 4 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:31:26 -0000 Folks: The draft minutes for the virtual interim meeting on Oct. 25 2011 are below. Please let me and Enrico know by Tuesday Nov 8, 2011 if these need any corrections. Thank you. CUSS WG Interim Meeting IV, Tue Oct 25. , 2011 12 participants on WebEx. Notes taken by Enrico Marocco and Laura Liess (thanks!) Administrivia: Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-4/Agenda.pdf - Agenda bashed, no changes. - CUSS req draft with IETF, and will be sent to IESG after the Taiwan IETF. - ISDN UUI Service Application Usage got matched to a draft (Keith Drage's draft). A WG -00 has been submitted. +----------------------------------------------------------------------------+ | There is no f2f meeting in Taipei, based on the agreement reached with | | respect to getting new versions of the mechanism and ISDN package draft | | out by Monday, Oct-31. Mechanism draft needs outside review, but | | ISDN package will need internal CUSS WG review only. Once the new rev- | | isions are out, the CUSS chairs will explicitly ping folks for a review of | | the drafts. Pursuant to these reviews, we may need another virtual | | interim meeting and then WGLC for both of these drafts. | +----------------------------------------------------------------------------+ Alan Johnston, Mechanism draft I-D: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-03 Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-4/cuss-mech.pdf - Editorial changes to draft (see slide 2-6). The changes were seen as beneficial by some WG attendees (Paul K.). Previous comments by WG (Keith D.) on source identity of UUI have been incorporated (see slide 5), comments by Paul K. have also been resolved (slide 7). - Keith asked whether we could have two different packages that use the same syntax with different semantics? Discussion ensued, and it was decided that the draft may need more exploration on the differences between packages and content. The package definition should call out the valid use of the content, so the discussion on syntax versus semantics should be put somewhere in the draft. Alan agreed to do so. - Discussion ensued on hex encoding (slide 8) and whether other encoding schemes should be provided (like string encoding). In the end, it was decided to levae it at hex encoding and not worry about other schemes for now and wait until a package comes along that may require other encoding schemes. Next steps are to close hex encoding issues, syntax versus semantics discussion, and review by a H-I info expert before going WGLC. Alan to get a new version out before Taipei I-D deadline. Most issues raised are clerical and editorial and may need f2f meeting time in Taipei. Keith Drage, Interworking ISDN Call Control User Information with SIP I-D: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-00 Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-4/isdn.pdf - Went through history of the draft until the adoption in WG. - Outlined issues (slides 4-7); none contested or needed any long discussion time by WG attendees. - Slide 8 (Issue 5) resulted in some discussion time regarding removal of diversion mechanism and whether the length limitation pertains to the package or the entire message. - Some discussion on what to do when the header field appears multiple times for the same package. One interpretation is that you can pick any of them. Other could mean that you pick all of the ones you support. Some choices need to be made on what sematics to apply to multiple headers. James reminded that at the last IETF meeting we decided not to worry about multiple headers due to this very complexity. However, at this point the ISDN UUI package is the only one, so it is hard to generalize based on one package. Alan will take a first cut to put some text in the mechanism draft on how to handle multiple headers and separate package syntax from semantics. The discussion belongs there and not the ISDN UUI draft. - Keith believes that pursuant to a full review by CUSS WG, the draft is ready for WGLC. ------------------------------------------------------------------- Raw notes from Enrico Marocco CUSS WG Virtual Interim Meeting October 25, 2011 Chairs: Vijay Gurbani Enrico Marocco Start time: 17:05 CEST Agenda ------ Vijay presents the agenda for today and the status of the WG. Keith: I expect the Taipei meeting to be confirmed today. Vijay: we'll decide at the end of the meeting if we need to meet in TW. Mechanism draft --------------- Alan Johnston presents version -03 of the mechanism draft. Terminology changes to make the use of "UUI data" and "package" consistent through the document Paul Kyzivat: I like it! Updated ABNF. Clarified that source identity is source or request or response, in From, To, P-A-ID. Keith Drage: this is not what we discussed in the past. I'd like to see text saying that the source of UUI is the source of the SIP message (either req or res). Alan: that is the intent of the text, read it and suggest changes if it does not sound like that to you. Keith: will do. Added the IANA considerations section. Open issue is about how packages define content types. Keith: could we have two different packages that use the same syntax with different semantics? Alan: content is about syntax, package is about semantics. Paul: may there be a case where multiple content types may be needed? Wondering whether there's value in having flexibility on that. Keith: most people usually use one content type only. Alan: when discussed in DISPATCH, people had concerns about passing blobs of data without saying what's in it. That's the case with ISDN. Do you think the draft needs more investigation about the difference between content and package? Paul: yes, the discussion about syntax and semantics is probably worth putting somewhere in the doc. Proposal to include text proposed by Paul to specify the hex encoding. Paul: if we go this far, should we also define other encodings? A string encoding? Alan: basically everyone uses hex today. James Rafferty: we've seen both text and hex, but nothing prevents converting a string to hex. Paul: if a conversion is needed in the ISDN, it can be done in the gateway. Keith: prefer to keep the gw simple, just have it copy UUI from ISDN to SIP and vice versa. Paul: there may be value in defining a string encoding, but don't feel strongly about that. Will add in the next version two things: syntax vs. semantics and details of hex encodings. Next review and hopefully WGLC. ISDN usage draft ---------------- Keith presents the freshly adopted version -00 of the ISDN usage draft. Terminology changes to align the ISDN usage draft to the mechanism one, plus some issues suggested on the list. Alan: is fine with removing the contributor's note at the end of section 3. Want to check whether people think this would define a valid package. Alan: what do you think about the removal of the diversion mechanism? Keith: there's no way to interworking it. Alan: for the multiple values, the ABNF in the mechanism right now forbids multiple header fields. If we want to allow them, we need to modify the ABNF to allow combined comma-separated header fields in the same header field. Paul: don't think 3261 says exactly that. Alan: we can say that if the header field appears multiple times, they are basically alternatives. James: at the last IETF meeting, we decided not to allow multiple headers, for complexity. Alan: but multiple headers defining alternative representation of the same UUI may make sense. That's something for the mechanism draft though. Paul: the mechanism should provide some indication about what package definitions can and should define. The document is basically ready for WG review, WGLC and so on. Paul: based on earlier discussion on encoding, it should be defined in such a way that is orthogonal to the content definition. Keith: it currently mandates hex encoding. Paul: and what about other possible encodings? Keith: that would break interoperability the way we have thought of so far. Alan: this ISDN usage is an example of why a package may want to restrict the encoding. Paul: I still think there's value in keeping content and encoding orthogonal, will take it to the list. [Further discussion on the content/encoding dichotomy, about e.g. whether coders or call-center admin or other standards bodies will be the one defining content.] Next steps ---------- Both Alan and Keith will be able to revise the drafts by the -0x deadline for Taipei. Keith: it would be very useful to have assigned reviewers from both CUSS and DISPATCH. Vijay: do we need to meet face to face in Taipei? Keith: for the ISDN document don't see a need. Alan: will we have reviews before TW? Vijay: unlikely. Alan: then would probably have little to discuss face to face. End time: 18:20 CEST --------------------------------------------------------------------- Raw notes from Laura Liess Notes CUSS interim Oct 25, 2011 Participants: Vijay, Enrico, Alan, Keith, James, Paul, Laura (I don’t know who pm was in the webex participants list) 1) Vijay’s presentation Note Well statement Agenda. Interim participants agree to the proposed agenda. Administrative issues. It is not quite clear if the time slot for the Taiwan meeting is needed. 2) Alan’s presentation on the UUI mechanism: Recent changes (slides 2-6): The participants agree to them. Slide 5: Keith pointed out that the source of the UUI is the source of the request or response. Issues raised on the list and Paul’s proposal for hex encoding (slides 7-9). Discussion about the need for more clarification on syntax vs. semantics and hex encoding (mainly Keith, Paul, Alan). Conclusion of the discussions on the raised issues: The next version of the draft will add text for: Syntax vs. semantics Details of hex encodings - Next steps: Alan will try to submit a new version of the draft before next Monday No need for a f2f meeting in Taiwan identified. 3) Keith’s presentation on the ISDN package History since last Ad-hoc (slides 2-3). No additional comments. Issue1: Alan: The change is OK. Issues 2 and 3: ??? Issue 4: Keith asked for suggestions. No suggestion for now. Issue 5: Discussion if some description is needed concerning multiple header fields. Alan: There was text on this in the past and it was removed. He offered to provide the text on this issue for the next version. Additional technical discussion: Paul:??? Alan: The ISDN-package has constraints to keep the gateway implementations simple. Next steps: Keith will try to revise the document till Monday No need for f2f meeting in Taiwan identified, further discussion on the list. After Taiwan, try to find more reviewers, also from other WGs. From vkg@bell-labs.com Tue Nov 1 12:47:43 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388311F0CBD for ; Tue, 1 Nov 2011 12:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68W9N-L7eqJD for ; Tue, 1 Nov 2011 12:47:42 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A158E1F0C36 for ; Tue, 1 Nov 2011 12:47:42 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pA1JjiBu010351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Nov 2011 14:45:44 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA1Jjhcv005073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Nov 2011 14:45:44 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA1JjhNU011589 for ; Tue, 1 Nov 2011 14:45:43 -0500 (CDT) Message-ID: <4EB04D1B.1070509@bell-labs.com> Date: Tue, 01 Nov 2011 14:48:43 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [cuss] Volunteers needed to review documents X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:47:43 -0000 Folks: Pursuant to the minutes from the last virtual interim meeting [1], it has been agreed to get volunteers to review the two pending documents. Neither of these documents have had a larger WG review, and we believe that both of them can benefit from such a review. Enrico and I will like to have at least one, and preferably two reviewers each for: http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/ The plan is to have a dedicated review of these drafts and address any shortcomings before doing a WGLC on them. The reviews will be due on or before Nov-30-2011. Please do let us know by the end of *this week* if you'd be able to review these drafts. Otherwise, we'd be in an unenviable position to randomly pick reviewers. Thank you in advance for your help! Vijay K. Gurbani and Enrico Marocco. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00302.html From keith.drage@alcatel-lucent.com Wed Nov 2 03:57:14 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3046A21F8BDB for ; Wed, 2 Nov 2011 03:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.157 X-Spam-Level: X-Spam-Status: No, score=-106.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RC5arzWrF8Q for ; Wed, 2 Nov 2011 03:57:13 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 73B181F0C91 for ; Wed, 2 Nov 2011 03:57:12 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA2At6o4018524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 2 Nov 2011 11:57:10 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 2 Nov 2011 11:56:43 +0100 From: "DRAGE, Keith (Keith)" To: "cuss@ietf.org" Date: Wed, 2 Nov 2011 11:56:41 +0100 Thread-Topic: draft-ietf-cuss-sip-uui-04 (SIP methods used) Thread-Index: AcyZTho8Sbnxf+2NQTKUQrjCpBVdow== Message-ID: 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.69 on 155.132.188.83 Subject: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:57:14 -0000 As far as I can find, the definitive text for which messages the User-to-Us= er header field can appear in is as follows: The User-to-User header field can be present in INVITE requests and responses only and in BYE requests and responses. Note that only end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and 3xx responses. 1) For the INVITE method, is this initial INVITEs only or does this include= reINVITE I have a vague feeling this reINVITE is needed because of the tra= nsfer scenarios but wanted to make sure. 2) For the refer scenarios mentioned in the CUSS requirements document, I a= ssume any inclusion is in the INVITE embedded within the REFER request - ra= ther than in the REFER request itself. Regards Keith From vkg@bell-labs.com Wed Nov 2 06:26:33 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E9D11E8090 for ; Wed, 2 Nov 2011 06:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhwjPRx4Tu3K for ; Wed, 2 Nov 2011 06:26:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84611E8089 for ; Wed, 2 Nov 2011 06:26:32 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pA2DQVM5014668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Nov 2011 08:26:31 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA2DQVh6005461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Nov 2011 08:26:31 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA2DQVYF017101 for ; Wed, 2 Nov 2011 08:26:31 -0500 (CDT) Message-ID: <4EB145BB.3010805@bell-labs.com> Date: Wed, 02 Nov 2011 08:29:31 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:26:33 -0000 On 11/02/2011 05:56 AM, DRAGE, Keith (Keith) wrote: > As far as I can find, the definitive text for which messages the > User-to-User header field can appear in is as follows: > > The User-to-User header field can be present in INVITE requests and > responses only and in BYE requests and responses. Note that only > end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and > 3xx responses. A bit orthogonal to Keith's main point of this email, but ... 3xx may not always be an end-to-end response. Proxies are allowed to recurse on a 3xx in rfc3261, and many do. So, UUIs in 3xx responses may not reach the intended recipient if the proxy recurses. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From alan.b.johnston@gmail.com Wed Nov 2 09:15:27 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A3421F9863 for ; Wed, 2 Nov 2011 09:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kX1cruYogT8 for ; Wed, 2 Nov 2011 09:15:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E72721F9831 for ; Wed, 2 Nov 2011 09:15:25 -0700 (PDT) Received: by eyg24 with SMTP id 24so326486eyg.31 for ; Wed, 02 Nov 2011 09:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H+kPfRzXRWe2QoHkZEvn3jJpgqZVWd6pO6HhtGk/hfI=; b=SLaapB436OOJD8daljhJ8W11r8bkZJ6TFUbtPYAz4kIkyPBUtERJCaZmYkbDh5kfX8 g9bGz7s0fsYDHxQu15mnud+ToIS+gdxOq3FVp5955v+2MeaVXaA94RP0fLdCRk5US9nI xE3w2cKeWOJn59jfj13xTlc/zZEooFq95I4Xo= MIME-Version: 1.0 Received: by 10.182.131.34 with SMTP id oj2mr1008383obb.71.1320250513339; Wed, 02 Nov 2011 09:15:13 -0700 (PDT) Received: by 10.182.117.98 with HTTP; Wed, 2 Nov 2011 09:15:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Nov 2011 11:15:13 -0500 Message-ID: From: Alan Johnston To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:15:27 -0000 Keith, You are correct in your statements below. I suspect inclusion in a re-INVITE would be necessary for some 3pcc scenarios as well. - Alan - On Wed, Nov 2, 2011 at 5:56 AM, DRAGE, Keith (Keith) wrote: > As far as I can find, the definitive text for which messages the User-to-= User header field can appear in is as follows: > > =A0 The User-to-User header field can be present in INVITE requests and > =A0 responses only and in BYE requests and responses. =A0Note that only > =A0 end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and > =A0 3xx responses. > > 1) =A0 =A0 =A0For the INVITE method, is this initial INVITEs only or does= this include reINVITE I have a vague feeling this reINVITE is needed becau= se of the transfer scenarios but wanted to make sure. > > 2) =A0 =A0 =A0For the refer scenarios mentioned in the CUSS requirements = document, I assume any inclusion is in the INVITE embedded within the REFER= request - rather than in the REFER request itself. > > Regards > > Keith > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Wed Nov 2 09:17:42 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429A411E8090 for ; Wed, 2 Nov 2011 09:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4uK4I8Kou-Q for ; Wed, 2 Nov 2011 09:17:41 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4941811E8083 for ; Wed, 2 Nov 2011 09:17:41 -0700 (PDT) Received: by bkat8 with SMTP id t8so370838bka.31 for ; Wed, 02 Nov 2011 09:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=f3uB4dBnaSnBq+3TeTzz2G/AvtQe3n9kM/8aTwRjAjM=; b=clQBsReuZgINyIkLYCGPatDTSTTjsLvy6IEnBBf2BJk55dpDU3k4IjMsdUH/rOwwrg C4FhbTan4Yy8x5Hp9UOf4KquTrM/YcuiDt0EfrHqGt68bUyushPr/xEeApC2z+MzXm/4 5jJJrezYFWEm3/v8sxYXajhA5sMel8uXvNYoU= MIME-Version: 1.0 Received: by 10.182.44.9 with SMTP id a9mr1016990obm.61.1320250659691; Wed, 02 Nov 2011 09:17:39 -0700 (PDT) Received: by 10.182.117.98 with HTTP; Wed, 2 Nov 2011 09:17:39 -0700 (PDT) In-Reply-To: <4EB145BB.3010805@bell-labs.com> References: <4EB145BB.3010805@bell-labs.com> Date: Wed, 2 Nov 2011 11:17:39 -0500 Message-ID: From: Alan Johnston To: "Vijay K. Gurbani" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:17:42 -0000 Vijay, You are also correct - RFC 3261 does allow a proxy to recurse on a 3xx in certain conditions. We can reword it so that this is not confusion. The intent is to not allow it in 100, 4xx, 5xx, and 6xx responses which are, by definition, sent hop-by-hop. - Alan - On Wed, Nov 2, 2011 at 8:29 AM, Vijay K. Gurbani wrote: > On 11/02/2011 05:56 AM, DRAGE, Keith (Keith) wrote: >> >> As far as I can find, the definitive text for which messages the >> User-to-User header field can appear in is as follows: >> >> =A0 The User-to-User header field can be present in INVITE requests and >> =A0 responses only and in BYE requests and responses. =A0Note that only >> =A0 end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and >> =A0 3xx responses. > > A bit orthogonal to Keith's main point of this email, but ... 3xx may > not always be an end-to-end response. =A0Proxies are allowed to recurse > on a 3xx in rfc3261, and many do. =A0So, UUIs in 3xx responses may not > reach the intended recipient if the proxy recurses. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: =A0 http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Wed Nov 2 09:24:01 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6451F0CC5 for ; Wed, 2 Nov 2011 09:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiaACGlRb1LH for ; Wed, 2 Nov 2011 09:24:01 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7661F0CC8 for ; Wed, 2 Nov 2011 09:24:00 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA2GNslc016221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Nov 2011 17:23:55 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 2 Nov 2011 17:23:55 +0100 From: "DRAGE, Keith (Keith)" To: Alan Johnston , "Gurbani, Vijay K (Vijay)" Date: Wed, 2 Nov 2011 17:23:53 +0100 Thread-Topic: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) Thread-Index: AcyZevwjl/TKbVqASSuQEvToX2c+SAAAIIgA Message-ID: References: <4EB145BB.3010805@bell-labs.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "cuss@ietf.org" Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:24:01 -0000 I would question whether we need it in 3xx at all. If we think of the UUI being delivered between applications, even if recurs= ion at a SIP proxy does not occur, surely the processing of a 3xx and gener= ation of a new INVITE based on the Contact would take place at the SIP leve= l, without necessarily revisiting the application. So even if the 3xx did go end-to-end, it could well never reach the applica= tion at the originating user. Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Alan Johnston > Sent: 02 November 2011 16:18 > To: Gurbani, Vijay K (Vijay) > Cc: cuss@ietf.org > Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) >=20 > Vijay, >=20 > You are also correct - RFC 3261 does allow a proxy to recurse on a 3xx > in certain conditions. We can reword it so that this is not > confusion. The intent is to not allow it in 100, 4xx, 5xx, and 6xx > responses which are, by definition, sent hop-by-hop. >=20 > - Alan - >=20 > On Wed, Nov 2, 2011 at 8:29 AM, Vijay K. Gurbani > wrote: > > On 11/02/2011 05:56 AM, DRAGE, Keith (Keith) wrote: > >> > >> As far as I can find, the definitive text for which messages the > >> User-to-User header field can appear in is as follows: > >> > >> =A0 The User-to-User header field can be present in INVITE requests an= d > >> =A0 responses only and in BYE requests and responses. =A0Note that onl= y > >> =A0 end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, a= nd > >> =A0 3xx responses. > > > > A bit orthogonal to Keith's main point of this email, but ... 3xx may > > not always be an end-to-end response. =A0Proxies are allowed to recurse > > on a 3xx in rfc3261, and many do. =A0So, UUIs in 3xx responses may not > > reach the intended recipient if the proxy recurses. > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > > Web: =A0 http://ect.bell-labs.com/who/vkg/ > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Wed Nov 2 09:28:10 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECA811E80C4 for ; Wed, 2 Nov 2011 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXo88eSGV2RR for ; Wed, 2 Nov 2011 09:28:09 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB0911E8090 for ; Wed, 2 Nov 2011 09:28:09 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pA2GS8bW021502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Nov 2011 11:28:08 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA2GS79e016505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Nov 2011 11:28:08 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA2GS7LK014931; Wed, 2 Nov 2011 11:28:07 -0500 (CDT) Message-ID: <4EB1704C.7030803@bell-labs.com> Date: Wed, 02 Nov 2011 11:31:08 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Alan Johnston References: <4EB145BB.3010805@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: cuss@ietf.org Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:28:10 -0000 On 11/02/2011 11:17 AM, Alan Johnston wrote: > Vijay, > > You are also correct - RFC 3261 does allow a proxy to recurse on a > 3xx in certain conditions. We can reword it so that this is not > confusion. Alan: Perfect. Thanks. > The intent is to not allow it in 100, 4xx, 5xx, and 6xx responses > which are, by definition, sent hop-by-hop. Yes, I gathered as much; but just to be sure that there are no ambiguities we should do some wordsmithing around 3xx. Some suggested text: OLD: The User-to-User header field can be present in INVITE requests and responses only and in BYE requests and responses. Note that only end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and 3xx responses. NEW: The User-to-User header field can be present in INVITE requests and responses only and in BYE requests and responses. Note that only end-to-end responses should be used, e.g. 1xx (excluding 100) and 2xx. SIP intermediaries can recurse on a 3xx response, so a User- to-User header field may not reach the intended recipient when using this class of responses. 4xx, 5xx, and 6xx responses have hop-by-hop semantics, thus should not be used to transport a User-to-User header field. Please feel free to change as needed. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Wed Nov 2 09:31:49 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C1721F9E2D for ; Wed, 2 Nov 2011 09:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFgAIgRM9lEH for ; Wed, 2 Nov 2011 09:31:48 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB321F99B3 for ; Wed, 2 Nov 2011 09:31:48 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pA2GVlPp023911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Nov 2011 11:31:48 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA2GVlWg017901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Nov 2011 11:31:47 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA2GVk2e019666 for ; Wed, 2 Nov 2011 11:31:47 -0500 (CDT) Message-ID: <4EB17127.6050906@bell-labs.com> Date: Wed, 02 Nov 2011 11:34:47 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: cuss@ietf.org References: <4EB145BB.3010805@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:31:49 -0000 On 11/02/2011 11:23 AM, DRAGE, Keith (Keith) wrote: > I would question whether we need it in 3xx at all. > > If we think of the UUI being delivered between applications, even if > recursion at a SIP proxy does not occur, surely the processing of a > 3xx and generation of a new INVITE based on the Contact would take > place at the SIP level, without necessarily revisiting the > application. > > So even if the 3xx did go end-to-end, it could well never reach the > application at the originating user. I think we are better off not making any such assumptions. I can imagine a UI on a SIP User Agent such that the user permission (or even an automaton permission) is sought before actually recursing. In such a case, the information associated with the 3xx does go to the TU layer. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From keith.drage@alcatel-lucent.com Wed Nov 2 09:37:44 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0189511E80C1 for ; Wed, 2 Nov 2011 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.163 X-Spam-Level: X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98wBDV+-jxZF for ; Wed, 2 Nov 2011 09:37:43 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 33FAD11E80AE for ; Wed, 2 Nov 2011 09:37:43 -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.14.3/8.14.3/ICT) with ESMTP id pA2GbbU8000720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Nov 2011 17:37:42 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 2 Nov 2011 17:37:41 +0100 From: "DRAGE, Keith (Keith)" To: "Gurbani, Vijay K (Vijay)" , "cuss@ietf.org" Date: Wed, 2 Nov 2011 17:37:40 +0100 Thread-Topic: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) Thread-Index: AcyZfPMZgPY+dWWNTRKgtZ7rDQVDAAAAIV/w Message-ID: References: <4EB145BB.3010805@bell-labs.com> <4EB17127.6050906@bell-labs.com> In-Reply-To: <4EB17127.6050906@bell-labs.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:37:44 -0000 But in my view it would also be equally valid for the 3xx to be received by= the SIP layer, and a new INVITE request generated automatically using the = data from the Contact and the original INVITE request (including UUI). As s= uch the sender of a 3xx cannot assume that UUI is delivered, even if it rea= ches the original UA. If we allow it, then I think this should also be reflected in the text. Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > Vijay K. Gurbani > Sent: 02 November 2011 16:35 > To: cuss@ietf.org > Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used) >=20 > On 11/02/2011 11:23 AM, DRAGE, Keith (Keith) wrote: > > I would question whether we need it in 3xx at all. > > > > If we think of the UUI being delivered between applications, even if > > recursion at a SIP proxy does not occur, surely the processing of a > > 3xx and generation of a new INVITE based on the Contact would take > > place at the SIP level, without necessarily revisiting the > > application. > > > > So even if the 3xx did go end-to-end, it could well never reach the > > application at the originating user. >=20 > I think we are better off not making any such assumptions. >=20 > I can imagine a UI on a SIP User Agent such that the user permission > (or even an automaton permission) is sought before actually recursing. >=20 > In such a case, the information associated with the 3xx does go to > the TU layer. >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From touch@isi.edu Fri Nov 4 13:42:44 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D01C11E8088; Fri, 4 Nov 2011 13:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9zCsiK--cFU; Fri, 4 Nov 2011 13:42:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD5211E8082; Fri, 4 Nov 2011 13:42:37 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id pA4KgJio022502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Nov 2011 13:42:19 -0700 (PDT) Message-ID: <4EB44E2B.6090608@isi.edu> Date: Fri, 04 Nov 2011 13:42:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "draft-ietf-cuss-sip-uui-reqs@tools.ietf.org" , "tsv-ads@tools.ietf.org" , IETF discussion list , CUSS@IETF.ORG References: <4E9ED4F2.7030302@isi.edu> In-Reply-To: <4E9ED4F2.7030302@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Fri, 04 Nov 2011 13:43:55 -0700 Cc: TSV Dir Subject: [cuss] TSVDIR review for draft-ietf-cuss-sip-uui-reqs X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 20:42:44 -0000 Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. We appreciate that this doc went through last call Oct 13; this request was received after that event. This document describes the issues in exchanging user-to-user call control information in SIP. There are no transport protocol issues in this document. The document does use the term "transport" frequently, most often as a verb meaning "exchange". I would encourage the authors to consider changing those uses to avoid confusion with "transport" as related to Layer 4 protocols. The one exception is the Overview (Sec 1) sentence, where the term "transport" is used. Here I would encourage the authors to use the term "session": ..."Providing informatoin and understanding of the UUI to the transport layer (SIP in this case) ... There are two additional issues: - the term "screen pop" in Sec 2.1 is unclear (do you mean "popup"?) - Sec 2.2 (Proxy Retargeting) talks about URI changes it's not clear whether the addresses referred to here are Transport Layer (e.g., IP addresses), or other addresses If these are transport layer addresses, there may be interactions with NATs and/or transport protocols that should be addressed. This section would benefit from a specific example as well. I would be glad to discuss these issues further if useful. Joe From alan.b.johnston@gmail.com Tue Nov 8 08:44:33 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2503221F8B73 for ; Tue, 8 Nov 2011 08:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46LLX7Ngqn8I for ; Tue, 8 Nov 2011 08:44:32 -0800 (PST) Received: from mail-dy0-f44.google.com (mail-dy0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41621F8B70 for ; Tue, 8 Nov 2011 08:44:32 -0800 (PST) Received: by dyl37 with SMTP id 37so32333dyl.31 for ; Tue, 08 Nov 2011 08:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZQliA/LJkfBiPlJytK9vdk/rtcXfctRRrNfu/EeHxqg=; b=NdTIA5CQrOhJkgtUn5XmhuKsNpLir4boZ9S3R5R8JY4Lagr67klD5japqGShHxvGIQ /7thwgSoBBzi1VmZW1jxmt4quZsX7BN4x39OQWb4HRGmP420qT80doGQqEKN4iRQms7f f2DICM2vvXUEYTYwV3By44ufAxry8vjJ7fW9U= MIME-Version: 1.0 Received: by 10.182.124.9 with SMTP id me9mr10347050obb.1.1320770670573; Tue, 08 Nov 2011 08:44:30 -0800 (PST) Received: by 10.182.117.98 with HTTP; Tue, 8 Nov 2011 08:44:30 -0800 (PST) Date: Tue, 8 Nov 2011 10:44:30 -0600 Message-ID: From: Alan Johnston To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [cuss] IESG Feedback on draft-ietf-cuss-sip-uui-reqs-07 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 16:44:33 -0000 All, The IESG has looked at our requirements draft and there are currently 2 DISCUSS and 2 COMMENTs: https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/ballot/ The good news is that they are all easy to resolve. Robert had a DISCUSS on clarifying the handling of redirections, much as we have discussed this on the list for the mechanism draft. I'll include some of the text we discussed there. He also wanted a clarification about whether there is a requirement that a UA be able to tell if UUI data has been removed from a request - I'll clarify that we do not have such a requirement. Russ had a DISCUSS saying he wanted two of my responses to Ben's review added to the draft. They related to identity, authorization, and hop-by-hop security. I'll include them in the next version. If anyone has any comments or questions on these changes, please send them to the list before next week - as soon as I-Ds can be submitted, I'll resubmit with these changes. - Alan - From vkg@bell-labs.com Tue Nov 8 09:16:56 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD79221F8B4D for ; Tue, 8 Nov 2011 09:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53t+zWVT6sRl for ; Tue, 8 Nov 2011 09:16:56 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id BA7D121F8B01 for ; Tue, 8 Nov 2011 09:16:41 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pA8HGflg010069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Nov 2011 11:16:41 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA8HGecl009394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Nov 2011 11:16:41 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA8HGeu2017156 for ; Tue, 8 Nov 2011 11:16:40 -0600 (CST) Message-ID: <4EB964B1.2010602@bell-labs.com> Date: Tue, 08 Nov 2011 11:19:45 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [cuss] IESG Feedback on draft-ietf-cuss-sip-uui-reqs-07 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:16:56 -0000 On 11/08/2011 10:44 AM, Alan Johnston wrote: > If anyone has any comments or questions on these changes, please > send them to the list before next week - as soon as I-Ds can be > submitted, I'll resubmit with these changes. Alan: Great. Please submit the I-Ds as soon as the blackout date has been lifted. Enrico and I have been able to solicit the services of Shida Schubert and Martin Dolly to provide expert reviews of the mechanism draft before we issue a WGLC (as discussed on the list [1]). Both Enrico and I will like to thank Shida and Martin for their time in reviewing the draft. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00303.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From keith.drage@alcatel-lucent.com Tue Nov 8 09:18:38 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9221F8B57 for ; Tue, 8 Nov 2011 09:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.061 X-Spam-Level: X-Spam-Status: No, score=-106.061 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEl6-YgBXnAI for ; Tue, 8 Nov 2011 09:18:37 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id A495D21F8B4D for ; Tue, 8 Nov 2011 09:18:37 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA8HIacM030699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Nov 2011 18:18:36 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 8 Nov 2011 18:18:36 +0100 From: "DRAGE, Keith (Keith)" To: "Gurbani, Vijay K (Vijay)" , "cuss@ietf.org" Date: Tue, 8 Nov 2011 18:18:35 +0100 Thread-Topic: [cuss] IESG Feedback on draft-ietf-cuss-sip-uui-reqs-07 Thread-Index: AcyeOjqGrApCVZ1VQtOMVe5ezn7MsQAAB9ig Message-ID: References: <4EB964B1.2010602@bell-labs.com> In-Reply-To: <4EB964B1.2010602@bell-labs.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [cuss] IESG Feedback on draft-ietf-cuss-sip-uui-reqs-07 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:18:38 -0000 It would nice to see a posting of the proposed text amendments. Can we do t= hat now so people have a change to look before the blackout. Keith=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > Behalf Of Vijay K. Gurbani > Sent: 08 November 2011 17:20 > To: cuss@ietf.org > Subject: Re: [cuss] IESG Feedback on draft-ietf-cuss-sip-uui-reqs-07 >=20 > On 11/08/2011 10:44 AM, Alan Johnston wrote: > > If anyone has any comments or questions on these changes,=20 > please send=20 > > them to the list before next week - as soon as I-Ds can be=20 > submitted,=20 > > I'll resubmit with these changes. >=20 > Alan: Great. Please submit the I-Ds as soon as the blackout=20 > date has been lifted. >=20 > Enrico and I have been able to solicit the services of Shida=20 > Schubert and Martin Dolly to provide expert reviews of the=20 > mechanism draft before we issue a WGLC (as discussed on the list [1]). >=20 > Both Enrico and I will like to thank Shida and Martin for=20 > their time in reviewing the draft. >=20 > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00303.html >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 > Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From vkg@bell-labs.com Fri Nov 11 08:38:15 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62F21F87FA for ; Fri, 11 Nov 2011 08:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPfF8Z8A6iLV for ; Fri, 11 Nov 2011 08:38:13 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B7AB421F86A1 for ; Fri, 11 Nov 2011 08:38:10 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pABGcAml015294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 Nov 2011 10:38:10 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pABGc9SL022595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Nov 2011 10:38:10 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pABGc9qW029989 for ; Fri, 11 Nov 2011 10:38:09 -0600 (CST) Message-ID: <4EBD502C.9000803@bell-labs.com> Date: Fri, 11 Nov 2011 10:41:16 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [cuss] Final minutes for Oct-25-2011 virtual interim X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 16:38:15 -0000 CUSS WG Interim Meeting IV, Tue Oct 25. , 2011 12 participants on WebEx. Notes taken by Enrico Marocco and Laura Liess (thanks!) Administrivia: Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-4/Agenda.pdf - Agenda bashed, no changes. - CUSS req draft with IETF, and will be sent to IESG after the Taiwan IETF. - ISDN UUI Service Application Usage got matched to a draft (Keith Drage's draft). A WG -00 has been submitted. Meeting summary: There is no f2f meeting in Taipei, based on the agreement reached with respect to getting new versions of the mechanism and ISDN package draft out by Monday, Oct-31. Mechanism draft needs outside review, but ISDN package will need internal CUSS WG review only. Once the new revisions are out, the CUSS chairs will explicitly ping folks for a review of the drafts. Pursuant to these reviews, we may need another virtual interim meeting and then WGLC for both of these drafts. Alan Johnston, Mechanism draft I-D: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-03 Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-4/cuss-mech.pdf - Editorial changes to draft (see slide 2-6). The changes were seen as beneficial by some WG attendees (Paul K.). Previous comments by WG (Keith D.) on source identity of UUI have been incorporated (see slide 5), comments by Paul K. have also been resolved (slide 7). - Keith asked whether we could have two different packages that use the same syntax with different semantics? Discussion ensued, and it was decided that the draft may need more exploration on the differences between packages and content. The package definition should call out the valid use of the content, so the discussion on syntax versus semantics should be put somewhere in the draft. Alan agreed to do so. - Discussion ensued on hex encoding (slide 8) and whether other encoding schemes should be provided (like string encoding). In the end, it was decided to levae it at hex encoding and not worry about other schemes for now and wait until a package comes along that may require other encoding schemes. Next steps are to close hex encoding issues, syntax versus semantics discussion, and review by a H-I info expert before going WGLC. Alan to get a new version out before Taipei I-D deadline. Most issues raised are clerical and editorial and may need f2f meeting time in Taipei. Keith Drage, Interworking ISDN Call Control User Information with SIP I-D: http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-00 Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-4/isdn.pdf - Went through history of the draft until the adoption in WG. - Outlined issues (slides 4-7); none contested or needed any long discussion time by WG attendees. - Slide 8 (Issue 5) resulted in some discussion time regarding removal of diversion mechanism and whether the length limitation pertains to the package or the entire message. - Some discussion on what to do when the header field appears multiple times for the same package. One interpretation is that you can pick any of them. Other could mean that you pick all of the ones you support. Some choices need to be made on what sematics to apply to multiple headers. James reminded that at the last IETF meeting we decided not to worry about multiple headers due to this very complexity. However, at this point the ISDN UUI package is the only one, so it is hard to generalize based on one package. Alan will take a first cut to put some text in the mechanism draft on how to handle multiple headers and separate package syntax from semantics. The discussion belongs there and not the ISDN UUI draft. - Keith believes that pursuant to a full review by CUSS WG, the draft is ready for WGLC. ------------------------------------------------------------------- Raw notes from Enrico Marocco CUSS WG Virtual Interim Meeting October 25, 2011 Chairs: Vijay Gurbani Enrico Marocco Start time: 17:05 CEST Agenda ------ Vijay presents the agenda for today and the status of the WG. Keith: I expect the Taipei meeting to be confirmed today. Vijay: we'll decide at the end of the meeting if we need to meet in TW. Mechanism draft --------------- Alan Johnston presents version -03 of the mechanism draft. Terminology changes to make the use of "UUI data" and "package" consistent through the document Paul Kyzivat: I like it! Updated ABNF. Clarified that source identity is source or request or response, in From, To, P-A-ID. Keith Drage: this is not what we discussed in the past. I'd like to see text saying that the source of UUI is the source of the SIP message (either req or res). Alan: that is the intent of the text, read it and suggest changes if it does not sound like that to you. Keith: will do. Added the IANA considerations section. Open issue is about how packages define content types. Keith: could we have two different packages that use the same syntax with different semantics? Alan: content is about syntax, package is about semantics. Paul: may there be a case where multiple content types may be needed? Wondering whether there's value in having flexibility on that. Keith: most people usually use one content type only. Alan: when discussed in DISPATCH, people had concerns about passing blobs of data without saying what's in it. That's the case with ISDN. Do you think the draft needs more investigation about the difference between content and package? Paul: yes, the discussion about syntax and semantics is probably worth putting somewhere in the doc. Proposal to include text proposed by Paul to specify the hex encoding. Paul: if we go this far, should we also define other encodings? A string encoding? Alan: basically everyone uses hex today. James Rafferty: we've seen both text and hex, but nothing prevents converting a string to hex. Paul: if a conversion is needed in the ISDN, it can be done in the gateway. Keith: prefer to keep the gw simple, just have it copy UUI from ISDN to SIP and vice versa. Paul: there may be value in defining a string encoding, but don't feel strongly about that. Will add in the next version two things: syntax vs. semantics and details of hex encodings. Next review and hopefully WGLC. ISDN usage draft ---------------- Keith presents the freshly adopted version -00 of the ISDN usage draft. Terminology changes to align the ISDN usage draft to the mechanism one, plus some issues suggested on the list. Alan: is fine with removing the contributor's note at the end of section 3. Want to check whether people think this would define a valid package. Alan: what do you think about the removal of the diversion mechanism? Keith: there's no way to interworking it. Alan: for the multiple values, the ABNF in the mechanism right now forbids multiple header fields. If we want to allow them, we need to modify the ABNF to allow combined comma-separated header fields in the same header field. Paul: don't think 3261 says exactly that. Alan: we can say that if the header field appears multiple times, they are basically alternatives. James: at the last IETF meeting, we decided not to allow multiple headers, for complexity. Alan: but multiple headers defining alternative representation of the same UUI may make sense. That's something for the mechanism draft though. Paul: the mechanism should provide some indication about what package definitions can and should define. The document is basically ready for WG review, WGLC and so on. Paul: based on earlier discussion on encoding, it should be defined in such a way that is orthogonal to the content definition. Keith: it currently mandates hex encoding. Paul: and what about other possible encodings? Keith: that would break interoperability the way we have thought of so far. Alan: this ISDN usage is an example of why a package may want to restrict the encoding. Paul: I still think there's value in keeping content and encoding orthogonal, will take it to the list. [Further discussion on the content/encoding dichotomy, about e.g. whether coders or call-center admin or other standards bodies will be the one defining content.] Next steps ---------- Both Alan and Keith will be able to revise the drafts by the -0x deadline for Taipei. Keith: it would be very useful to have assigned reviewers from both CUSS and DISPATCH. Vijay: do we need to meet face to face in Taipei? Keith: for the ISDN document don't see a need. Alan: will we have reviews before TW? Vijay: unlikely. Alan: then would probably have little to discuss face to face. End time: 18:20 CEST --------------------------------------------------------------------- Raw notes from Laura Liess Notes CUSS interim Oct 25, 2011 Participants: Vijay, Enrico, Alan, Keith, James, Paul, Laura (I don’t know who pm was in the webex participants list) 1) Vijay’s presentation Note Well statement Agenda. Interim participants agree to the proposed agenda. Administrative issues. It is not quite clear if the time slot for the Taiwan meeting is needed. 2) Alan’s presentation on the UUI mechanism: Recent changes (slides 2-6): The participants agree to them. Slide 5: Keith pointed out that the source of the UUI is the source of the request or response. Issues raised on the list and Paul’s proposal for hex encoding (slides 7-9). Discussion about the need for more clarification on syntax vs. semantics and hex encoding (mainly Keith, Paul, Alan). Conclusion of the discussions on the raised issues: The next version of the draft will add text for: Syntax vs. semantics Details of hex encodings - Next steps: Alan will try to submit a new version of the draft before next Monday No need for a f2f meeting in Taiwan identified. 3) Keith’s presentation on the ISDN package History since last Ad-hoc (slides 2-3). No additional comments. Issue1: Alan: The change is OK. Issues 2 and 3: ??? Issue 4: Keith asked for suggestions. No suggestion for now. Issue 5: Discussion if some description is needed concerning multiple header fields. Alan: There was text on this in the past and it was removed. He offered to provide the text on this issue for the next version. Additional technical discussion: Paul:??? Alan: The ISDN-package has constraints to keep the gateway implementations simple. Next steps: Keith will try to revise the document till Monday No need for f2f meeting in Taiwan identified, further discussion on the list. After Taiwan, try to find more reviewers, also from other WGs. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From shida@ntt-at.com Mon Nov 28 17:32:06 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656F011E810B for ; Mon, 28 Nov 2011 17:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRIKGZJVHyPN for ; Mon, 28 Nov 2011 17:32:06 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id EB00A11E810C for ; Mon, 28 Nov 2011 17:32:05 -0800 (PST) Received: from [125.197.203.231] (port=59879 helo=[192.168.1.11]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RVCYG-00006b-Hu for cuss@ietf.org; Mon, 28 Nov 2011 19:32:04 -0600 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2011 10:32:02 +0900 Message-Id: <6190982C-35A1-4371-B179-8C1A2BF21929@ntt-at.com> To: cuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) 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 X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-125-197-203-231.tky.mesh.ad.jp ([192.168.1.11]) [125.197.203.231]:59879 X-Source-Auth: shida@agnada.com X-Email-Count: 6 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Subject: [cuss] Review of draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 01:32:06 -0000 I was asked by chairs of this WG to review=20 draft-ietf-cuss-sip-uui.=20 Below are my comments=20 ** OVERALL *** The draft talks a lot about escaping the header.=20 We used the same terminology in rfc4244bis, but=20 after some discussion decided with "including/include". I think the reason was due to the fact that 3261 doesn't=20 use "escape" in that context.=20 I didn't see any issue with how the rfc4244bis is used. ** TECHNICAL *** 1. Will the behavior of the device be affected if the=20 source of UUI data is different from the assumed entity? I am assuming it doesn't as the inserterthere is an a priori = understanding ... of the UUI=20 data doesn't seem too be so important from the draft.=20 2. I think there is little or no text about the behavior=20 of entity receiving UUI data, encoding or package=20 that it doesn't understand. I am assuming it simply =20 ignores it but, I think this should be explicitly=20 stated somewhere in normative language.=20 3. Section 3 talks about UUI header being removed=20 by proxy/intermediary. But it is mute about intermediary=20 adding UUI header, leaving room for them to add it.=20 So what would happen if intermediary adds UUI header?=20 Who is the inserter? What does that mean? If we don't=20 see any use for intermediary adding the header, I think=20 we should say MUST NOT for intermediary.=20 4. I think normative text surrounding redirecting entity=20 adding user-to-user info be added.=20 5. When UAS redirects the request with=20 User-to-User: foo;package=3D1;encoding=3Dhex to a=20 contact with a User-to-User:bar;package=3D1;encoding=3Dhex.=20 I am assuming that you will end up with=20 User-to-User: foo;package=3D1;encoding=3Dhex, bar;package=3D1,encoding=3Dh= ex You end up with two uui data from two different entity.=20 Is this going to pose problem?=20 I guess if 4244bis was supported, this would be=20 logged and one can see that the latter was added by=20 an UAS which redirected the request.. Do we need to=20 add some text regarding this? Are the last value more=20 important than the one added by the originator of the=20 request? ** NITS *** Section 1 OLD : there is an a priori understanding ... NEW : there is a priori understanding ... Section 5 OLD : SIP UUI mechanism must publish a standard track. NEW : SIP UUI mechanism MUST publish a standard tack. OLD : some use case example examples. NEW : some use case examples.=20 OLD : Hex encoded UUI data must have an even... NEW : Hex encoded UUI data MUST have an even.. OLD : New "encoding" values must reference... NEW : New "encoding" values MUST reference.. OLD : New "content" values must describe... NEW : New "content" values MUST describe.. I hope this helps.=20 Regards Shida=20 From shida@ntt-at.com Mon Nov 28 17:11:15 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB38B11E80AC for ; Mon, 28 Nov 2011 17:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxVx3XjUQfXf for ; Mon, 28 Nov 2011 17:11:10 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id E8D7411E809C for ; Mon, 28 Nov 2011 17:11:06 -0800 (PST) Received: from [125.197.203.231] (port=58518 helo=[192.168.1.11]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RVCDp-0007n7-MA for cuss@ietf.org; Mon, 28 Nov 2011 19:10:58 -0600 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2011 10:10:55 +0900 Message-Id: <99469747-AF84-4BC3-8E82-11333BD2D4C4@ntt-at.com> To: cuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) 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 X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-125-197-203-231.tky.mesh.ad.jp ([192.168.1.11]) [125.197.203.231]:58518 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t X-Mailman-Approved-At: Tue, 29 Nov 2011 01:03:03 -0800 Subject: [cuss] Review of draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 01:11:15 -0000 I was asked by chairs of this WG to review=20 draft-ietf-cuss-sip-uui.=20 Below are my comments=20 ** OVERALL *** The draft talks a lot about escaping the header.=20 We used the same terminology in rfc4244bis, but=20 after some discussion decided with "including/include". I think the reason was due to the fact that 3261 doesn't=20 use "escape" in that context.=20 I didn't see any issue with how the rfc4244bis is used. =20 ** TECHNICAL *** 1. Will the behavior of the device be affected if the=20 source of UUI data is different from the assumed entity? I am assuming it doesn't as the inserterthere is an a priori = understanding ... of the UUI=20 data doesn't seem too be so important from the draft.=20 2. I think there is little or no text about the behavior=20 of entity receiving UUI data, encoding or package=20 that it doesn't understand. I am assuming it simply =20 ignores it but, I think this should be explicitly=20 stated somewhere in normative language.=20 3. Section 3 talks about UUI header being removed=20 by proxy/intermediary. But it is mute about intermediary=20 adding UUI header, leaving room for them to add it.=20 So what would happen if intermediary adds UUI header?=20 Who is the inserter? What does that mean? If we don't=20 see any use for intermediary adding the header, I think=20 we should say MUST NOT for intermediary.=20 4. I think normative text surrounding redirecting entity=20 adding user-to-user info be added.=20 5. When UAS redirects the request with=20 User-to-User: foo;package=3D1;encoding=3Dhex to a=20 contact with a User-to-User:bar;package=3D1;encoding=3Dhex.=20 I am assuming that you will end up with=20 =20 User-to-User: foo;package=3D1;encoding=3Dhex, = bar;package=3D1,encoding=3Dhex You end up with two uui data from two different entity.=20 Is this going to pose problem?=20 I guess if 4244bis was supported, this would be=20 logged and one can see that the latter was added by=20 an UAS which redirected the request.. Do we need to=20 add some text regarding this? Are the last value more=20 important than the one added by the originator of the=20 request? ** NITS *** Section 1 OLD : there is an a priori understanding ... NEW : there is a priori understanding ... Section 5 =20 OLD : SIP UUI mechanism must publish a standard track. NEW : SIP UUI mechanism MUST publish a standard tack. OLD : some use case example examples. NEW : some use case examples.=20 OLD : Hex encoded UUI data must have an even... NEW : Hex encoded UUI data MUST have an even.. OLD : New "encoding" values must reference... NEW : New "encoding" values MUST reference.. OLD : New "content" values must describe... NEW : New "content" values MUST describe.. I hope this helps.=20 Regards Shida=20