Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02

["Elwell, John" <[e-mail]>]

> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: 02 November 2010 19:25
> To: Elwell, John
> Cc: [e-mail]
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
>
> Hi John,
>
> Responses inline below [MB].  I will skip the ones that I replied to
> in the other response [MB].
>
> Thanks,
> Mary.
>
> On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John
> <[e-mail]> wrote:
> > Despite the effort that has gone into addressing comments
> raised by people on -01, I still find -02 hard to understand
> in places. I have not had time to review the whole document,
> but here are some comments up to section 7. Just as I
> finished writing this I saw Mary's response to my comments on
> -01, which I will respond to tomorrow. Apologies for any
> overlap between the two.
> >
> >
> > 1. As a general comment that I have made before, the
> document still talks about 'header' in many places where it
> is not referring to the entire header for a SIP message, but
> only to a particular header field such as History-Info.
> History-Info is only one field within the entire SIP header.
> See RFC 3261 section 6 - definitions of header and header
> field. Although RFC 3261 is not 100% consistent, in general
> things like Contact, To, From etc. are referred to as header
> fields, and hence History-Info should be too. Section 4.3 of
> RFC 4485 also calls for attention to be given to the correct
> use of terms header, header field and header field parameter,
> although it fails to say what the correct use is and one has
> to rely on RFC 3261.
> [MB] I replied to this in the other email. But, yes, this doc does use
> Header to mean Header field, but that's done in many other documents.
> However, I can change all of those to say "header field" if it makes a
> difference in understanding the document. [This might be something to
> put on the RFC editor list if folks are insisting that we always use
> "Header field"]  The term header field parameter AFAIK is only used to
> refer to the two new header field parameters defined in this document.
> [/MB].
[JRE] Yes, I know some other documents have got it wrong. As editor, I guess the decision can rest with you (or defer to RFC-Editor) - I was just pointing out the discrepancy.

> >
> > Also there are some instances of "header parameter field",
> which is not a normal term - it should be "header field parameter".
> [MB] That's a typo. [/MB]
> >
> > 2. There is some confusion concerning Reason - sometimes it
> is referred to as a parameter (e.g., 7.1 3rd bullet, 7.1 last
> paragraph), sometimes as reason header, sometimes as reason,
> sometimes as Reason header, sometimes as Reason...
> [MB] Logically, Reason is a "parameter" for the hi-entries. However,
> rather than redefine the "parameter", we reuse the Reason header by
> escaping it in the URI - the term Reason header was used for brevity.
> I did add text in the -02 to clarify that in cases where it is
> confusing. I can change all instances to refer to "escape a Reason
> header in the hi-targeted-uri" rather than just "add a Reason header".
> [/MB]
[JRE] I find it odd referring to it as a parameter of an hi-entry, yet it is not to be found in hi-param. I would suggest we change section 7.1 3rd bullet to say "Reason: Optional information in History-Info, capturing the reason for retargeting to a Targeted-to URI. It is reflected in the ....". Furthermore, since we have this definition, in the rest of the document we should use "Reason", and not all the other variants.

> >
> > 3. The word "entry" is used inconsistently. Mostly it
> occurs in "hi-entry", which is fine. But we also have
> "targeted-to-URI entry", "entry" (alone), History-Info entry
> (which is probably fine, as long as we say what it is),
> "header entry". Also "hi-entries".
> [MB] Which term do you prefer?  I will change all the entry(s) to
> hi-entry. The targeted-to-URI entry possibly should be
> hi-targeted-to-uri. [/MB]
[JRE] Sounds reasonable.

>
> >
> > 4. As another general comment, there are too many normative
> statements using the passive voice, and therefore hard to
> understand. To quote one example of the sort of ambiguity
> that can arise from using passive, in 7.3.2:
> > "For retargets that are the result of an explicit SIP response, a
> >   Reason MUST be associated with the hi-targeted-to-uri."
> > Is this saying that an entity that inserts History-Info
> MUST include in hi-targeted-uri an escaped Reason header
> field? Or is this saying that a recipient of Reason MUST
> associate it with an hi-targeted-to-uri. I guess the first
> interpretation is more plausible, but why not say what is
> meant, rather than fudging it?
> [MB] The Reason header is added to the hi-entry whose
> hi-targeted-to-URI is being retargeted due to the response.  It is
> added by the entity receiving the response.  Note that it is added to
> the entry prior to the entry that is being added as a result of the
> retargeting due to the response - i.e., it's not added to the
> "current" hi-entry.  It's added to the previous.  The sentences
> following the one that you highlight are intended to say just that.
> That's why the term "associated" is loosely used because the next
> sentences are the normative part. So, really, that first sentence
> shouldn't be "MUST be" and would be more accurate to say "is". [/MB]
[JRE] Right, so that fixes this particular instance of passive voice, since it is no longer a normative statement. Use of the passive voice had concealed the fact that we were incorrectly using normative language, which just goes to prove my point that passive voice, at least in normative statements, is bad.

</snip>
> >
> > 7. Section 3:
> > "Capturing aliases and Globally Routable User Agent URIs (GRUUs)
> >      [RFC5627], which can be overwritten by a home proxy
> upon receipt"
> > The term "home proxy" is not used in RFC 3261.
> [MB] I will change to "proxy in the home domain" which is a term used
> in RFC 5627 (earlier versions of GRUU did use the term "home
> proxy")[/MB]
[JRE] Good.

<snip/>
> >
> > 9. Section 4;
> > "Target : A parameter indicating ..."
> > This overloads the word target. Perhaps a better generic
> term for these parameters would be "Derivation".
> [MB] I will just change to "Indicates.." which matches the form of the
> other bullets in that list. [/MB]
[JRE] Sorry, I didn't express my concern very clearly. I was concerned that "Target" is a confusing name for the collective term for rc and mp parameters, since it overloads the word "target". I was suggesting we use "Derivation" instead of "Target" (and hence hi-derivation instead of hi-target). But perhaps this is too much of a change at this stage.

<snip/>
> >
> > 16. Section 5.1:
> > "If the Contact header contained any of
> >   the header parameter fields defined in this specification"
> > Don't understand. The parameters defined in this
> specification are parameters of the History-Info header
> field, so would not appear in a Contact header field.
> Admittedly there is some mention in 7.3.4 of using the
> parameters in a Contact header field, but there is nothing
> that specifies the extended syntax of the Contact header field.
> [MB] The header field parameters are defined for the Contact header
> (and History-Info) in the IANA section.  It is introduced in 7.1 and
> the usage thereof described in 7.3.4.  [/MB]
[JRE] Sorry, that is what comes of submitting comments before I have reviewed the whole document. However, the way things are scattered around in this document makes it quite hard to find things, but it is probably too late to do much about that.

> >
> > 17. Section 5.1:
> > "MUST include the header parameter field  as a header
> parameter field
> >   associated with the current hi-entry as described in
> Section 7.3.4."
> > Is "current hi-entry" the "new hi-entry" from a couple of
> sentences earlier?
> [MB] Yes. Do you have a terminology preference? [/MB]
[JRE] I would use "new hi-entry".

<snip/>
> >
> > 22. Section 5.2.1:
> > "Prior to any application usage of the information, the
> validity MUST
> >   be ascertained"
> > What MUST ascertain the validity - the UAS or the
> application? Use active voice. How does it do this? Is this
> testable? I don't believe we can use RFC2119 language here.
> [MB] That is saying that the UAS MUST check that the entries that it
> is aware of contain the information that might be needed by an
> application (i.e., the last entry, target header field parameters,
> etc.). It's testable from a software implementation perspective - not
> a protocol perspective.  I can change the MUST to a lower case
> recommended .. ie., it is recommended that the UAS...Note, that this
> was one of the SHOULDS (from RFC 4244) that folks wanted to change to
> MUST.  [/MB]
[JRE] OK, I can live with MUST, but please use active voice.

<snip/>
> >
> > 25. Section 5.3:
> > "the redirect server MUST add the appropriate target header
> >   field parameter to each Contact header as described in
> Section 7.3.4."
> > I don't think 7.3.4 tells me how to do this. Section 7.3.4
> does mention the Contact header field, but only in the
> context of adding these parameters to the History-Info header
> field (if I understand correctly).
> [MB] 7.3.4 tells you which one to add based upon the mechanism by
> which the targets are determined.  The header field parameter is added
> based upon the same criteria. [/MB]
[JRE] So it should say "as described in Section 7.3.4 for adding to a History-Info entry" or something similar.

<snip/>
> >
> > 27. Section 6.1.1:
> > "The proxy MUST include an hi-index attribute
> >      with a value of "1""
> > It says we are inserting an entry, not replacing any
> existing entries. Value "1" will not apply if there is an
> existing entry.
> [MB] Correct. If the prior hop did not include an hi-entry, then one
> is added. Even if there are already other hi-entries, there is no way
> to know how many hops might have been missed and thus, the indexing
> needs to be reset to 1 to reflect such. [/MB]
[JRE] So this means a downstream entity can receive two entries with index "1" (possibly with intervening entries 1.1 etc.), not because of any incorrect behaviour of any of the nodes concerned, but merely because some intervening nodes don't support H-I. This was the first time I was aware of this. We should add some explanation. Personally I would prefer to continue the indexing rather than reset to "1".

<snip/>
> > 36. "MUST forward captured History-Info in subsequent,
> >   provisional, and final responses to the request sent by
> the ultimate
> >   UAS (see Section 5.2)"
> > If a response does not contain any captured H-I (because
> the UAS doesn't support it), is there any requirement on the
> proxy to generate it from its own information?
> [MB] A proxy would have added an hi-entry for the UAS if it follows
> the normative procedures in this document. But, there is no way for
> the proxy to generate any additional hi-entries (in cases where the
> UAS internally retargets or B2BUA case).   [/MB]
[JRE] Understood. However, let me give you an example. A proxy receives a request with entries 1 and 1.1, and forwards it thereby adding 1.1.1. Suppose the next entity is the UAS and the UAS supports H-I. The UAS will capture 1, 1.1 and 1.1.1 in the returned response, so therefore the proxy forwards 1, 1.1 and 1.1.1 when it forwards the response. That's fine. However, if the UAS does not support H-I, the response will contain no entries. In this case, the proxy will be aware of entries 1, 1.1 and 1.2 and could add them when forwarding the response. This assumes a certain amount of state be held at the proxy, but no more than is required for forking, for example.
Perhaps I have misinterpreted the word "captured" in the cited text - I had assumed you meant captured in the received response, but of course it might mean captured by the proxy from the time it forwarded the request. It certainly needs some clarification.

> >
> > 37. Section 7.1:
> > "Reason: An optional parameter for History-Info,"
> > It is not in the ABNF as a parameter of History-Info - in
> fact it is an escaped header field.
> [MB] Correct - this is a summary of information associated with each
> hi-entry and it is described in   as being escaped. Logically, the
> information is there. Certainly, it's clear that it's not defined
> specifically in the ABNF for the header. [/MB]
[JRE] See my proposal above for rewording this.

<snip/>
> >
> > 39. Section 7.3.2:
> > "If the response contains a Reason header for a protocol
> >   that is not SIP (e.g., Q.850), it MUST be captured as an
> additional
> >   Reason associated with the hi-targeted-to-uri that has been
> >   retargeted, along with the SIP Response Code"
> > I think this is saying that the entity MUST include two
> Reason parameters in the hi-entry. Perhaps we should state
> that more explicitly. Also, does order matter?
> [MB] I can add (i.e., there will be two reason headers), but I figured
> when you add "an additional" to one, that it's obvious that there are
> two headers. Per RFC  , order does not matter. [/MB]
[JRE] I did interpret the wording correctly then, so perhaps the existing wording is OK. It just seemed a bit convoluted, somehow saying that the Reason conveying the SIP response code is somehow the main reason and the other one is an additional Reason, when really they are just two Reasons.

<snip/>
> >
> > 41. Section 7.1.3, item 6:
> > "For example, if
> >       a procesing entity received failure responses for
> forks 1.1.1 and
> >       1.1.2, it would return both the 1.1.1 and 1.1.2 entries to the
> >       entity that generated the hi-entry with index of 1."
> > I can't figure this out - shouldn't "index of 1" be "index of 1.1"?
> [MB] No.  The processing entity in that sentence has the index of 1.1.
> The processing entity is the subject of that sentence and "it" returns
> the response to the entity that would have added the hi-entry with
> index of 1.[/MB]
[JRE] I still can't figure this out. A proxy receives a request with entries 1 and 1.1. It creates two branches, 1.1.1 and 1.1.2. Both fail, so when the proxy sends a response back, it will include entries 1.1.1 and 1.1.2. That response is sent to the entity that generated 1.1.

<snip/>
> >
> > Although I didn't review beyond section 7, I happened to
> notice the following in Appendix B:
> > "B.  An entity (UA or proxy) retargeting in response to a redirect
> >           or REFER MUST include any Request History information from
> >           the redirect/REFER in the new request."
> > It is unclear how you can retarget in response to a REFER.
> A REFER requests leads to the generation of a new request -
> there is no retargeting.
> [MB] I'll reword that to reflect that the REFER includes the
> History-Information from previous retargets. [/MB]
[JRE] Well, clearly the REFER can contain H-I from previous retargets of the REFER request, but that has no bearing on the request generated as a result of the REFER.

John