[martini] #51: Pick one Registrar processing behavior for received user portion in REGISTER

"martini issue tracker" <trac@tools.ietf.org> Fri, 16 July 2010 15:41 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAC53A682A for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level:
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, 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 f7K7mTOB+YMa for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:41:19 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A058F3A67F3 for <martini@ietf.org>; Fri, 16 Jul 2010 08:41:19 -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 1OZn2Z-0003qM-AA; Fri, 16 Jul 2010 08:41:31 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: martini 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: martini
Date: Fri, 16 Jul 2010 15:41:31 -0000
X-URL: http://tools.ietf.org/martini/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/51
Message-ID: <064.d6295c939ebe5a8090934dcf70e61119@tools.ietf.org>
X-Trac-Ticket-ID: 51
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@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: martini@ietf.org
Subject: [martini] #51: Pick one Registrar processing behavior for received user portion in REGISTER
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2010 15:41:20 -0000

#51: Pick one Registrar processing behavior for received user portion in
REGISTER
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  enhancement             |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  gin                     |     Version:  1.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 Section 5.2 says:
    A registrar that receives a Contact URI with both a "bnc" parameter
    and a user portion MUST either discard the user portion and process
    the request as if the parameter were not present or return a 400 (Bad
    Request) error in response (unless some other error code is more
    appropriate).

    Section 5.3 says:
    When a SIP-PBX registers with an SSP using a "bnc" contact, that
    contact MUST NOT include a "user" parameter.  An SSP registrar that
    receives a Contact URI with both a "bnc" parameter and a "user"
    parameter MUST either discard the "user" parameter and process the
    request as if the parameter were not present or return a 400 (Bad
    Request) error in response (unless some other error code is more
    appropriate).

 I think we need to pick one and only one behavior - having some Registrars
 accept these and others not leads to inconsistent interoperability among
 vendor equipment.  Since at some future time we may find a need for the
 user portion, but will probably want backwards-compatibility without
 failure at that time, I recommend for 5.2 we stipulate a Registrar
 compliant to this draft MUST discard and ignore the user portion and
 process the request as if the user portion were not present; and for 5.3
 the same for a "user" param.  This would also follow the mantra of strict
 on send, liberal on receipt.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/51>
martini <http://tools.ietf.org/martini/>