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