[sipcore] #43: Small fixes

"sipcore issue tracker" <trac@tools.ietf.org> Fri, 17 September 2010 17:35 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 034353A68B2 for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 10:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level:
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 8oVRz8UKYJfm for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 10:35:24 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6C9A33A6803 for <sipcore@ietf.org>; Fri, 17 Sep 2010 10:35:09 -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 1OweqR-0006Yw-JL; Fri, 17 Sep 2010 10:35:31 -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: worley@alum.mit.edu
X-Trac-Project: sipcore
Date: Fri, 17 Sep 2010 17:35:31 -0000
X-URL: http://tools.ietf.org/sipcore/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sipcore/trac/ticket/43
Message-ID: <061.a01c95ac1b7d3fe52101cc609a7c57d3@tools.ietf.org>
X-Trac-Ticket-ID: 43
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: worley@alum.mit.edu, 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] #43: Small fixes
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: Fri, 17 Sep 2010 17:35:26 -0000

#43: Small fixes
---------------------------------+------------------------------------------
 Reporter:  worley@…             |       Owner:     
     Type:  defect               |      Status:  new
 Priority:  minor                |   Milestone:     
Component:  rfc4244bis           |     Version:     
 Severity:  In WG Last Call      |    Keywords:     
---------------------------------+------------------------------------------
 This ticket is a collection of items that are either editorial nits
 (things that an editor might correct) or "minor" wording improvements
 (things that require content knowledge to fix but seem to have no
 interesting/controversial technical content).  Several of these have
 been consolidated from previous tickets (as noted).

 --- Ticket #30

 Stray double-quote:

     History-Info is a header field as defined by [RFC3261]. "It may

 Missing space:

     is set to a value of "mp".The "mp" attribute in the hi-target

 --- Ticket #33

 I see the sentence "The following summarizes the syntax..." -- this
 suggests that the actual syntax definition/specification is
 elsewhere. Do you mean "The following is the syntax..."?

 --- Ticket #31

 In section 6.1 is:

     The following rules apply:

     o There MUST be exactly one hi-index parameter per hi-entry.

     o There MUST be no more than one hi-target parameter.

     o There MAY be any number of hi-extension parameters.

     o The ABNF definitions for "generic-param" and "name-addr" are
     from [RFC3261].

 The fourth item is different from the first three and should be put
 elsewhere.

 The second and third items also need "... per hi-entry". But since
 that would apply that qualifier to all 3 of the remaining items in the
 list, it would be better to phrase it:

     The following rules apply to each hi-entry:

     o There MUST be exactly one hi-index parameter.

     o There MUST be no more than one hi-target parameter.

     o There MAY be any number of hi-extension parameters.

 --- Ticket #36

 Section 6.3.1 para 1 starts:

     This specification defines a new SIP/SIPS URI Parameter indicating
     the mechanism by which a new target for a request is determined.

 However the actual name of the parameter is not given until para 5. I
 suggest putting the name of the parameter into the first sentence of
 para 1.

 --- Ticket #39

 Section 6.3.1 para 5 is:

     The following defines the ABNF for the "hit" URI parameter:

 Please change this to:

     The ABNF for the "hit" URI parameter is:

 (The object of "define" is always a word or term that is defined; it
 is not the ABNF that is defined. Indeed, the ABNF *defines* the
 syntax of the "hit" URI parameter.)

 --- Ticket #17

 In section 3 is the odd phrase "any valid response" -- are there
 invalid responses? What is validity of responses? Better would be "any
 response", or probably more informatively, "any provisional or final
 response".

 --- Ticket #26

 In section 5.2 is "SHOULD forward captured History-Info in subsequent,
 provisional, and final responses to the request". I think that
 "subsequent" adds no meaning and should be removed.

 --- Ticket #22

 This:

     A UAC that does not want an hi-entry added due to privacy
     considerations MUST include a Privacy header with a priv-value(s)
     of "header" or "history." A UAC that wants to ensure that privacy
     not be applied to its identity MUST include a Privacy header with
     a priv- value of "none."

 should have the punctuation moved for clarity:

     A UAC that does not want an hi-entry added due to privacy
     considerations MUST include a Privacy header with a priv-value(s)
     of "header" or "history". A UAC that wants to ensure that privacy
     not be applied to its identity MUST include a Privacy header with
     a priv-value of "none".

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