Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
"Andrew Allen" <aallen@rim.com> Tue, 21 June 2011 15:36 UTC
Return-Path: <aallen@rim.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D7811E8148 for <sipcore@ietfa.amsl.com>; Tue, 21 Jun 2011 08:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvYznxfYYH94 for <sipcore@ietfa.amsl.com>; Tue, 21 Jun 2011 08:36:02 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0998911E807E for <sipcore@ietf.org>; Tue, 21 Jun 2011 08:35:59 -0700 (PDT)
X-AuditID: 0a412830-b7b5cae000000ee1-96-4e00ba4ab1d6
Received: from XCH139CNC.rim.net (xch139cnc.rim.net [10.65.10.235]) by mhs061cnc.rim.net (SBG) with SMTP id 1B.B9.03809.A4AB00E4; Tue, 21 Jun 2011 15:35:38 +0000 (GMT)
Received: from XCH04ADS.rim.net ([10.67.10.91]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jun 2011 11:35:41 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3028.DF9D6C3E"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 21 Jun 2011 10:35:39 -0500
Message-ID: <56DC300C52125F46BA19D2D5CCEC4D70011162C4@XCH04ADS.rim.net>
In-Reply-To: <4DEC205A.5040503@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
thread-index: Acwj4WLMIxaV1i5ETwSDJeWbWUF+ngMRbVSg
References: <4DEC205A.5040503@cisco.com>
From: Andrew Allen <aallen@rim.com>
To: SIPCORE Chairs <sipcore-chairs@tools.ietf.org>, "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
X-OriginalArrivalTime: 21 Jun 2011 15:35:41.0221 (UTC) FILETIME=[E09E7D50:01CC3028]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsXC5cj1WtdrF4OfwfT9qhanXp1mtvj6YxOb A5PHkiU/mTy+XP7MFsAU1cBok5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdJFAwj/ujC3fJzEV3O9grHiz/z5LA+OW4i5GTg4JAROJdY9usEHYYhIX7q0H srk4hARWMko8O/+YGSQhJNDHKHHuZzmIzSygJXHkUhMjiM0rIChxcuYTFoh4uMSsKQegBulJ LFs8BSwuLGAl8fl+OzuIzSKgKvHzwDXWLkYOoF53iVm/zUHCnAKaEoe7JrJDtApKLJq9hxnm nn+7HoKNFBGwlni4/hIThG0ksepKEyvEaRoSuyd8BathAxr/5vgGRoiaKolP0yBOExKQlthx cg0jxMxgib5TB5gmMIrOQvLNLCTfzELyzSygS5mBvmnbyAgR1pZYtvA1M4StK/H/+RxmZPEF jOyrGAVzM4oNzAyT85L1ijJz9fJSSzYxgpOKhsEOxgl7tQ4xCnAwKvHwlqxj8BNiTSwrrsw9 xCjBwawkwpu8FSjEm5JYWZValB9fVJqTWnyI0RUYbhOZpbiT84EJL68k3tjAADdHSZxXdMEc XyGBdGBiy05NLUgtgpnDxMEp1cC4w0Lq853iaS8vC9+3DXpgvfLh/xXKiZaL/U/Me/P4S//H wzsPLBAS43idfUlV5/aiPRxXhLlWLvRM31zx7S/Xu1CerZ1Fv5/V33P5ySfELnbkOtek/XOe dmt++zYlsDtmJ0fKr11rHj+u5dNt29RaaHRTPPzSvvR5rAtvmjV091U0+AZ27eE5rcRSnJFo qMVcVJwIAKPq33FQAwAA
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2011 15:36:06 -0000
Seems I missed the WGLC deadline by a day or so but here are the comments from my review: Section 5 "mp": The hi-targeted-to-URI represents a user other than the user associated with the Request-URI in the incoming request that was retargeted. The term "user" here is confusing. Does it mean the human user (who might have multiple AoRs/URIs which may or may not be known to the retargeting proxy as AoRs/URIs that all map to the same human user)? When retargeting is the proxy supposed to assess whether the new target URI represents the same human user or not in order to determine whether to include the "mp" parameter or not? I'm not sure what terminology would be best but I think "user" is likely to cause confusion. The above issue also reoccurs in section 7 Section 15 "Entities that have not implemented this specification MUST ignore these parameters"? We can't make any normative requirements on entities that have not implemented this specification! Therefore the MUST should be removed. I think you mean to state that according to RFC 3261 and RFC 4244 entities that are not compliant with this specification will ignore these parameters. There is a backward compatibility concern which I think should be addressed. With 4244bis the URI in the Request-URI is now clearly to be included in the History-Info when the Request-URI is replaced by the Contact address. This was not the case in RFC 4244 where in many (if not most) implementations rewriting the request-URI with the Contact was not considered retargeting. Some existing UA implementations may have assumed that the last History-Info entry cannot be their own Contact Address but will always be their AoR. For example a UA may only look at the next highest History-Info header field from the bottom most one in order to determine whether the call arrived as a result of forwarding or not from within their home domain and what the URI was that it was forwarded from. Since outside the home domain of the UA up to now the use of History-Info has not been deterministic some UAs may have only looked at the last couple of History-Info header fields in order to determine what happened to the request after it arrived within their domain. In these kinds of scenarios having a proxy now add an additional History-Info header field (for the rewriting of the Request-URI to the Contact) in 4244bis may break the logic of such UAs. I am not saying we shouldn't do this but I think some text about such possible problems with existing implementations should be indicated in the backwards compatibility section. Section B.1 In this example, the Office and Home are not the same AOR as sip:bob@example.com, but rather different AORs that have been configured as alternate addresses for Bob in the proxy. In other words, Office and Bob are not bound through SIP Registration with Bob's AOR. The opportunity is missed to explain here that this means that the "rc" parameter is not added. I think it would help to understand if that was highlighted. FLOW F1 INVITE sip:alice@example.com should be INVITE sip:bob@example.com FLOW F5 Request-URI for the ACK looks wrong to me shouldn't it be bob@192.0.2.4? FLOW F6 The URI in the Request-URI and the URI in the bottom most History-Info header field are not the same (R-URI = office@192.0.2.3 and H-I = office@192.0.2.5). These should be the same - suggest change R-URI to office@192.0.2.5 so as to avoid need to change H-I in the other flows and also since 192.0.2.3 is Alice's UA!!. FLOW F13 Again Request-URI for the ACK looks wrong to me shouldn't it be home@192.0.2.6? Examples in B.2 and B.3 do not have the same level of detail as in B.1 or RFC 4244. Editorials Last paragraph of 10.1 .2 "compenent" should be "component" First and 2nd paragraph of 10.3 "add an hi-index"/"adds an hi-entry" should be "a" not "an" Regards Andrew From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Sunday, June 05, 2011 7:34 PM To: SIPCORE (Session Initiation Protocol Core) WG Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert Sparks Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis [as co-chair] The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis Any comments on the document should be sent to the SIPCORE mailing list. Thanks, Paul --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
- [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Adam Roach - SIPCORE Chair
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-… Adam Roach
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Elwell, John
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Elwell, John
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] H-I in 100 response (was REMINDER: … Elwell, John
- Re: [sipcore] H-I in 100 response (was REMINDER: … Paul Kyzivat
- Re: [sipcore] H-I in 100 response (was REMINDER: … DRAGE, Keith (Keith)
- Re: [sipcore] H-I in 100 response (was REMINDER: … Hadriel Kaplan
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- Re: [sipcore] H-I in 100 response (was REMINDER: … Victor Pascual Avila
- [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Christer Holmberg
- [sipcore] 4244bis-05: editorial comments Hadriel Kaplan
- Re: [sipcore] 4244bis-05: editorial comments Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Christer Holmberg
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Andrew Allen
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Cullen Jennings
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Andrew Allen
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert