[sipcore] #12: Section 7 on Application Considerations needs work

"sipcore issue tracker" <trac@tools.ietf.org> Mon, 30 August 2010 19:02 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D743A69E0 for <sipcore@core3.amsl.com>; Mon, 30 Aug 2010 12:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZeF7zJ+vkTe for <sipcore@core3.amsl.com>; Mon, 30 Aug 2010 12:02:06 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 521903A69D4 for <sipcore@ietf.org>; Mon, 30 Aug 2010 12:02:03 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oq9co-0006Uh-4h; Mon, 30 Aug 2010 12:02:34 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: sipcore issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: hkaplan@acmepacket.com
X-Trac-Project: sipcore
Date: Mon, 30 Aug 2010 19:02:34 -0000
X-URL: http://tools.ietf.org/sipcore/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sipcore/trac/ticket/12
Message-ID: <064.89665f0da52766f4162641242eae3a7e@tools.ietf.org>
X-Trac-Ticket-ID: 12
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, sipcore@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: sipcore@ietf.org
Subject: [sipcore] #12: Section 7 on Application Considerations needs work
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 30 Aug 2010 19:02:07 -0000

#12: Section 7 on Application Considerations needs work
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  enhancement             |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 The thing I fear the most about H-I is that different UAS will process
 this thing and expect to see things a certain way, and applications will
 fail when they don't, and SBC vendors will once again be fixing the
 headers to make interop work.

 In that sense, I think Section 7 may be the most important section to get
 right.  In particular, items 2, 4 and 5 in this section are not
 necessarily true.  I will submit separate tickets on them.

 This ticket is for asking for additional text such as:
 "Implementers should make certain their applications do not expect
 specific H-I entries or index values to contain the information they need,
 because SIP requests may follow numerous paths with multiple request-URI
 rewriting cases in different deployments.  For example, there may be
 multiple "rc" entries due to forking, or multiple entries which are
 neither "rc" nor "mp" entries due to normal routing, or multiple "mp"
 entries due to multiple diverts.  H-I entries can be non-SIP URIs, such as
 TEL URIs.  Furthermore, H-I entry URIs may contain both URI parameters and
 URI user parameters which are unknown to the final UAS, which MUST be
 ignored for the purposes of identity matching."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/12>
sipcore <http://tools.ietf.org/sipcore/>