RE: [Sip] WGLC for referred-by
"Mary Barnes" <mbarnes@nortelnetworks.com> Fri, 20 June 2003 16:37 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16623 for <sip-archive@odin.ietf.org>; Fri, 20 Jun 2003 12:37:37 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KGbAV10064 for sip-archive@odin.ietf.org; Fri, 20 Jun 2003 12:37:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOso-0002bJ-Gh; Fri, 20 Jun 2003 12:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOsl-0002Zl-AA for sip@optimus.ietf.org; Fri, 20 Jun 2003 12:36:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16596 for <sip@ietf.org>; Fri, 20 Jun 2003 12:36:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TOsj-0006X3-00 for sip@ietf.org; Fri, 20 Jun 2003 12:36:57 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19TOsj-0006Wj-00 for sip@ietf.org; Fri, 20 Jun 2003 12:36:57 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KGaEx20585; Fri, 20 Jun 2003 11:36:14 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <NBYCT2NW>; Fri, 20 Jun 2003 11:36:14 -0500
Message-ID: <870397D7C140C84DB081B88396458DAF578A07@zrc2c000.us.nortel.com>
From: Mary Barnes <mbarnes@nortelnetworks.com>
To: 'Robert Sparks' <rsparks@dynamicsoft.com>, sip@ietf.org
Cc: Jon Peterson <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>, 'Rohan Mahy' <rohan@cisco.com>
Subject: RE: [Sip] WGLC for referred-by
Date: Fri, 20 Jun 2003 11:36:12 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
There were a couple points that I made on the list around the -01 version that don't seem to have been addressed http://www1.ietf.org/mail-archive/working-groups/sip/current/msg07955.html and I couldn't find that they had been responded to on the list in the archives: Editorial Nits: ------------------- - References: authid-body and cc-transfer need upversioning. Other items: -------------------------------------- - Section 2.3: Last paragraph: should this be a MUST (reject an otherwise well-formed request with an invalid token)? Reasonably, one should, but perhaps there are users that would still like to be able to decide themselves, thus I would suggest this be stated similar to the previous paragraph as: "The refer target SHOULD reject an otherwise well-formed request with an invalid Referred-By token (see Section 4) with a 429 error response. If the agent chooses to proceed with the request and provides any information from the Referred-By header to its user as part of processing the request, it MUST notify the user that the information was determined to be invalid." My reasoning is that it just seems that if an optional parm is mucked up (in general or from a security perspective), then following the adage of being generous in what you accept ...that whether to accept the request, provided that it is warned that it's bad, should still be up to the user. This also seems consistent with the MAYs in the previous 2 paragraphs. I do understand the reasoning that you'd want to let the Referrer know and that by allowing the request, you're actually bypassing the security put in place to keep the bad guys from mucking with the messages, but again since it's optional, it just seems that you can't make it stronger than a SHOULD. - Section 4.1: 2nd paragraph suggesting that "A target SHOULD verify the request...". I don't think this is useful since retargeting makes this check not meaningful. UNLESS, of course, you're using History-Info. With History-Info, you could verify that the Refer-To matches one of the Targeted-to-URIs (and of course, this implies that this information has all been sent securely, not mucked with by the proxies, etc.). Regards, Mary. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, June 19, 2003 1:39 PM To: sip@ietf.org Cc: rohan@cisco.com; Jon Peterson; Dean Willis; 'Robert Sparks' Subject: [Sip] WGLC for referred-by Hello Everyone, I would like to begin a Working Group last call on: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt WGLC will end on Friday July 18th. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] WGLC for referred-by Rohan Mahy
- RE: [Sip] WGLC for referred-by Mary Barnes
- RE: [Sip] WGLC for referred-by Robert Sparks
- RE: [Sip] WGLC for referred-by Mary Barnes