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

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Oct 2010 17:44:31 -0500

Responses inline below.

On Tue, Aug 31, 2010 at 12:34 PM, sipcore issue tracker
<[email-masked]> wrote:
> #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.
[MB] This doesn't apply only to UACs - similar text is in the UAS
section. Per your suggestion below, we can remove the text in both the
UAS can UAC sections and add that statement to section 7.   [/MB]

 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.
[MB] Dividing the text to normatively describe UAC, UAS and Proxy
behavior is standard - it facilitates implementation. And, I do not
see alot of redundancy other than what you note above.  I can agree
that once we fix the redirect server behavior per issue #24 that there
might be more common behavior that applies to both. The best way to
handle that IMHO is to refer to the appropriate places in the Proxy
section.   [/MB]
>
>  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.
[MB] The behavior for the UAC upon receipt of a 3xx is slightly
different than a proxy, so I do not think we can generalize the
behavior here - i.e., a UAC may not want to include all the
information previously received in the new INVITE. Although, I guess
we can debate that. [/MB]

>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/23>
> sipcore <http://tools.ietf.org/sipcore/>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>