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

From: "martini issue tracker" <[email-masked]>
Date: Fri, 16 Jul 2010 15:41:31 -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/>