Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 17 Apr 2012 12:56:30 -0400

Here are some things that I think could be improved in sections 1 to 5
of the 07 draft.  They are listed in textual order.

Abstract

    In addition, this specification defines a value for the Privacy
    header field specific to the History-Info header field.

As in other places in the draft, mention is made that there *exists* a
related Privacy value without giving any hint of the *purpose* of the
value.  This seems to me to be needlessly obscure.  A better
description would be "This specification defines a value for the
Privacy header field that directs the anonymization of values in the
History-Info header field."

1. Introduction

    the receiving application to determine hints about how and why the

should be

    the receiving application to obtain information about how and why the

2. Conventions and Terminology

   process of a SIP entity changing a Uniform Resource Identifier (URI)
   in a request based on the rules for determining request targets as

This sentence does not specify *which* URI in the request is being
changed.  A better wording would be

   process of a SIP entity changing the request-URI [RFC3261, section 7.1]
   in a request based on the rules for determining request targets as

   The terms "target user" is used in this specification as the human
   user associated with particular AoR or AoRs (in case the human user
   has multiple alias).

The use of "alias" here is not particularly good.  A better phrase
would be "in case the human user has multiple AoRs".

3. Background

   Current network applications provide the ability for elements

should have added "Current network applications >>>for other
protocols<<< provide".

   2.  Email forwarding whereby the forwarded-to user obtains a
       "history" of who sent the email to whom and at what time

More apropos is the fact that most e-mail systems add "Received"
lines, giving a detailed trace of the path of the message from sender
to receiver, and if the Received headers include the "for" clause, the
translation of the original destination address to the ultimate
recipient's address can be tracked.  E.g.,

     Received: from eye.ariadne.com (eye.ariadne.com [127.0.0.1])
	     by eye.ariadne.com (8.14.4/8.14.4) with ESMTP id q3H8e3vI026332
	     for <worley@localhost>; Tue, 17 Apr 2012 04:40:03 -0400
     Received: from mail.comcast.net [76.96.58.11]
	     by eye.ariadne.com with POP3 (fetchmail-6.3.20)
	     for <worley@localhost> (single-drop); Tue, 17 Apr 2012 04:40:03 -0400 (EDT)
     Received: from imta34.emeryville.ca.mail.comcast.net (LHLO
      imta34.emeryville.ca.mail.comcast.net) (76.96.28.168) by
      sz0045.wc.mail.comcast.net with LMTP; Tue, 17 Apr 2012 08:26:05 +0000 (UTC)
     Received: from VIMPORTPART.COM ([78.46.253.246])
	     by imta34.emeryville.ca.mail.comcast.net with comcast
	     id ywS21i00o5KkC6e0awS2oh; Tue, 17 Apr 2012 08:26:03 +0000
     Received: by VIMPORTPART.COM (Postfix, from userid 0)
	     id 21D99831D7; Tue, 17 Apr 2012 10:26:02 +0200 (CEST)

   o  Capturing aliases and Globally Routable User Agent URIs (GRUUs)
      [RFC5627], which can be overwritten by a REGISTRAR or a "home

should be "registrar".

4.  Overview

   request to be changed by the same proxy/SIP Intermediary multiple

should be "intermediary".

   header field parameters, along with examples is provided in

reads better with a comma after "examples".

   In addition, this specification defines a priv-value for the Privacy
   header, "history", that applies to all the History-info header field
   entries in a Request or to a specific History-info header field hi-
   entry as described above.  Further detail is provided in
   Section 10.1.

Again, this description does not state that the priv-value requires
that History-Info values be anonymized.  Better would be

   In addition, this specification defines a priv-value for the
   Privacy header, "history", that >>>requires anonymization of<<< all
   the >>>History-Info<<< header field entries in a Request or to a
   specific History-info header field hi-entry as described above.
   Further detail is provided in Section 10.1.

And "History-info" needs to be capitalized as "History-Info".

5.  History-Info Header Field Protocol Structure

   these requests (ISSUER-req, see Appendix A).

It looks like this phrase is intended to be a reference to the
requirements listed in Appendix A.  In that case, it should use
brackets [...] rather than parentheses (...).  But since there are
only two such references (the other one is in section 13), it appears
that the references were incompletely removed.  Otherwise there would
be many more of them.

      parameter is a string of digits, separated by dots to indicate the

There is a long history of using the term "string of digits" in these
drafts, despite that it's not a correct way to look at the syntax.
The syntax is a sequence of positive integers separated by dots and
the text should say that:

      parameter is a sequence of positive integers, separated by dots
      to indicate the

      This results in a tree
      representation of the history of the request, with the lowest-
      level index reflecting a branch of the tree.

I'm not sure what is meant here.  It is true that the lowest-level
index reflects a branch of the tree, but so do all the higher-level
indexes.  I believe that what is intended is "leaf".

      This
      parameter contains either an "rc", "mp" or "np" header field
      parameter, which is interpreted as follows:

"contains" should be "is".

         "np": The hi-targeted-to-URI represents that there was no
         change in Request-URI.  This would apply for example when a
         proxy merely forwards a request to a next hop proxy and loose
         routing is used.

Unlike the previous two cases, this case does not describe the
function of the value of the np parameter.

   o  Privacy: An optional parameter for History-Info, reflected in the
      History-Info header field values by including the Privacy Header
      [RFC3323] included in the hi- targeted-to-uri or by adding the
      Privacy header field to the request.  The latter case indicates
      that the History-Info entries for the domain MUST be anonymized
      prior to forwarding, whereas the use of the Privacy header field
      included in the hi-targeted-to-uri means that a specific hi-entry
      MUST be anonymized.

The phrase "the domain" is completely undefined here.  I suspect you
mean something like "all History-Info entries whose hi-targeted-to-uri
has the same domain as the domain for which the SIP entity processing
the message is responsible".

   Note that the backslash and CRLF between the fields in
   the examples below are for readability purposes only.

Was "lines" meant instead of "fields"?

   Note that the backslash, CRLF and whitespace between the lines in
   the examples below are inserted for readability purposes only.
   (But History-Info can be broken into multiple lines due to the SWS
   that is part of HCOLON, COMMA and SEMI, and there can be multiple
   History-Info header fields due to the rule of section 7.3
   [RFC3261].)

   History-Info: <sip:[email-masked]>;index=1;foo=bar

   History-Info: <sip:[email-masked]?Reason=SIP%3B\
                 cause%3D302>;index=1.1,\
                 <sip:[email-masked]?Privacy=history&Reason=SIP%3B\
                 cause%3D486>;index=1.2;mp=1.1,\
                 <sip:[email-masked]>;index=1.3;rc=1.2

5.1.  History-Info Header Field Example Scenario

   One important thing illustrated by this call flow is that without
   History-Info, Bob would "lose" the target information, including any
   parameters in the request URI.

It seems to me that "the target information" is ambiguous -- the
target information of which request would be lost when?  You want to
say something like "the initial request-URI" or "the original target
information".

   Note that an hi-
   entry is not included for the fork to sip:[email-masked] since there
   was no response at the time the 200 OK is sent to Alice.

This would be a lot clearer if it was more detailed:

   Note that in the 200 response to Alice, an hi-entry is not included
   for the fork to sip:[email-masked] (index 1.1.1) since
   biloxi.example.com had not received a response from that fork at
   the time it sent the 200 OK that ultimately reached Alice.

   The formatting in this scenario is for visual purposes; thus,
   backslash and CRLF are used between the fields for readability.

Although in fact there are no backslash-line breaks in the example.
If there were, it might be needed to mention the included whitespace
as in section 5.

   |                |                | Proxy Cancels INVITE      |
   |                |                |<=========================>|

Might be better illustrated by showing it as a CANCEL request:

   |                |                | CANCEL         |          |
   |                |                |-------------------------->|

Dale

---

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Apr 2012 09:07:58 +0900

Dale;

 Many thanks for your comments, my response inline.

> History-Info header field."

 Ok

>    the receiving application to obtain information about how and why the

DONE

> would be "in case the human user has multiple AoRs".

DONE

> should have added "Current network applications >>>for other

 DONE

> 	     id 21D99831D7; Tue, 17 Apr 2012 10:26:02 +0200 (CEST)

 Tried to incorporate it. 

>      [RFC5627], which can be overwritten by a REGISTRAR or a "home

DONE

> should be "intermediary".

DONE

> reads better with a comma after "examples".

 DONE

>   Further detail is provided in Section 10.1.

DONE

> And "History-info" needs to be capitalized as "History-Info".

DONE

> that the references were incompletely removed.  Otherwise there would

REMOVED.

> indexes.  I believe that what is intended is "leaf".

 FIXED

> "contains" should be "is".

 FIXED

> function of the value of the np parameter.

 Any suggestion for rewording?

> the message is responsible".

 Sounds good. 

>                 <sip:[email-masked]>;index=1.3;rc=1.2

 Will use this instead.

> If there were, it might be needed to mention the included whitespace

 Removed.

 Many Thanks & Regards
  Shida

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 18 Apr 2012 11:48:28 -0400

> From: Shida Schubert [[email-masked]]
> 

Assuming that the values of the three parameters are intended to carry
the same information (that is, the index of the hi-entry from which
this request-URI was derived), the value of "np" would be the index of
the parent hi-entry of this hi-entry.  As in the example in 5.1:

   | History-Info: <sip:[email-masked];p=x>;index=1
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1

Largely copying the wording of the entry for "rc", we can add:

         >>>The "np"
         header field parameter contains the value of the hi-index in
         the hi-entry with an hi-targeted-to-uri that reflects the
         Request-URI that was copied unchanged into the request
         represented by this hi-entry.  That value will usually be the
         hi-index of the parent hi-entry of this hi-entry.<<<

While I was lookng at this, the entry for "mp" has some awkward
wording that could be improved by copying the wording from "rc".
Instead of

         The "mp" header field parameter contains the
         >>>value which represents the value<<< of the hi-index in the
         hi-entry ...

perhaps

         The "mp"
         header field parameter contains the >>>value<<< of the hi-index in
         the hi-entry ...

Dale

---

From: Shida Schubert <[email-masked]>
Date: Thu, 19 Apr 2012 15:28:13 +0900

Dale;

 Thanks for the suggestion and the catch. 

 Regards
  Shida