Subject: [sipcore] #23: Which elements a particular normative passage applies to

From: "sipcore issue tracker" <[email-masked]>
Date: Tue, 31 Aug 2010 17:34:53 -0000

#23: Which elements a particular normative passage applies to
---------------------------------+------------------------------------------
 Reporter:  worley@…             |       Owner:     
     Type:  enhancement          |      Status:  new
 Priority:  major                |   Milestone:     
Component:  rfc4244bis           |     Version:     
 Severity:  In WG Last Call      |    Keywords:     
---------------------------------+------------------------------------------
 In regard to the general notes in section 4.1:

    Prior to any application usage of the information by the UAC (e.g.,
 debug), the validity SHOULD be ascertained.  The entries SHOULD be
 evaluated to determine gaps in indices, which could indicate that an entry
 has been maliciously removed.  Either way, an application SHOULD be aware
 of potentially missing information.  The interpretation of the information
 in the History-Info header by a UAC in a request depends upon the specific
 applications supported by the UAC.  Application considerations and
 guidelines are provided in section 7.

 It's not clear why this is phrased to refer only to UACs, as UASs seem to
 be the most likely application, and in any case, there is no particular
 limitation the what SIP elements might want to examine History-Info.  A
 better phrasing would be:

    Prior to any application usage of the information by a SIP element
 (e.g., debugging of request routing), the validity of the History-Info
 values SHOULD be ascertained.  An application SHOULD be aware of the
 possibility of missing or incorrect values.  The interpretation of the
 information in the History-Info header by a UAS in a request depends upon
 the specific applications supported by the UAS.  Application
 considerations and guidelines are provided in section 7.

 This is an instance of a more general exposition problem:  Many normative
 parts of the exposition specifically identify their target as UAS, UAC,
 proxy, etc. even though the processing described applies to a larger class
 of elements.

 For instance, there are behaviors that are specific to "any element that
 receives a request containing History-Info", but (IIRC), the same rules
 are stated separately for UASs and proxies.

 Similarly, since both proxies and UACs can act on 3xx responses, the rules
 for handling redirection should be labeled as such.

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