[martini] #50: Review

"martini issue tracker" <trac@tools.ietf.org> Mon, 12 July 2010 13:28 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: martini issue tracker <trac@tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: john.elwell@siemens-enterprise.com
Date: Mon, 12 Jul 2010 13:28:15 -0000
Message-ID: <076.43826a138084943589b9f210badb7f38@tools.ietf.org>
Cc: martini@ietf.org
Subject: [martini] #50: Review

#50: Review
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:            
     Type:  defect                              |      Status:  new       
 Priority:  major                               |   Milestone:  milestone1
Component:  gin                                 |     Version:  1.0       
 Severity:  In WG Last Call                     |    Keywords:            
------------------------------------------------+---------------------------
 I have reviewed this document and it is ready to go, apart from the
 following minor issues and nits that should be corrected.

 1. "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 ..."
 It doesn't make sense. If the parameter were not present, one would expect
 a user portion to be present. I think this should say :
 "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 user portion were not present or ..."
                          ^^^^^^^^^^^^

 2. "Currently, the descriptions are somewhat informal, and omit some
    details for the sake of brevity.  If the MARTINI working group
    expresses interest in furthering the mechanism described by this
    document, they will be fleshed out with more detail and formality."
 This seems to be historic and should be deleted.

 3. "   When a UA registers with the SIP-PBX using GRUU procedures for a
    Contact, the SIP-PBX adds an "sg" parameter to the GRUU parameter it
    received from the SSP.  This "sg" parameter contains a disambiguation
    token that the SIP-PBX can use to route the request to the proper
    user agent."
 This isn't terribly clear. Rewording as follows might help:
 "When a UA registers a contact with the SIP-PBX using GRUU procedures, the
 SIP-PBX provides to the UA a public GRUU formed by adding an "sg"
 parameter to the GRUU parameter it received from the SSP.  This "sg"
 parameter contains a disambiguation token that the SIP-PBX can use to
 route inbound requests to the proper UA."

 4. "The SSP registrar then maps I_i to the "bnc" AOR template and
       instance ID using the database, a persistent hash-map or similar
       technology."
 This is the first use of the expression "AOR template and instance ID". We
 could do with some clarification, but I don't have a proposal. We have
 something that could be described as a template, but I would have
 considered that to be a contact template rather than an AOR template.

 5. "(1) The SIP-PBX registers with the SSP for a range of AORs.
        It includes the URI it expects to receive in the Request-URI
        in its "Contact" header field, and includes information that
        routes to the SIP-PBX in the "Path" header field."
 I think "the URI" should be changed to "the domain". Only the domain part
 of the REGISTER request's Contact header field will appear in the Request-
 URI of the inbound request.

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

[martini] #50: Review martini issue tracker
Re: [martini] #50: Review martini issue tracker