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

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Nov 2010 23:13:20 +0100

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.

Also there are some instances of "header parameter field", which is not a normal term - it should be "header field parameter".

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...

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".

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?

5. Section 1:
"there is a need for a standard mechanism within
   SIP for communicating the retargeting history of such a request"
What is meant by "such a request"? We have not previously mentioned "request". The preceding text has talked about calls, not requests, but perhaps it should talk about requests.

6. Section 3:
"Current network applications provide the ability for elements
   involved with the call to exchange  additional information relating to
   how and why the call was routed to a particular destination"
Change "exchange" to "obtain". I think that would fit better with the examples that follow.

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.

8. Section 4:
"The  following information is carried in the History-Info header as
   detailed in Section 7.1:"
I think it would be better to say "For each target used for forwarding a request, the  following information is carried in the History-Info header as detailed in Section 7.1:"
This would make it clear that there can be more than one instance of this information.

9. Section 4;
"Target : A parameter indicating ..."
This overloads the word target. Perhaps a better generic term for these parameters would be "Derivation".

10. Section 4:
"A SIP entity changing the target of a
   request in response to a redirect or REFER"
A REFER does not cause an entity to change the target of a request - it causes an entity to generate a new request. H-I will indeed be added, but that is covered by the statement above about creating a new request.

11. "propagates any
   History-Info header from the initial Request in the new request":
Contrary to what it says in the first half of the sentence, this does indeed acknowledge that we have a new request as a result of REFER. However, the statement is incorrect because there is no normative statement (e.g., in section 5) concerning this special behaviour for REFER. There is merely a requirement in Appendix A.

12. Section 4:
"Note that an hi-entry is not included for the fork to
   sip:[email-masked] "
This is misleading, because there is indeed H-I sent to 192.0.2.7. I think what it should say is that the H-I sent to 192.0.2.3 and subsequently sent back to Alice does not contain an entry for target 192.0.2.7.

12bis. Section 5.1:
"In addition, the UAC
   SHOULD add  a History-Info header"
Why is this only a SHOULD, not a MUST? What would be the exceptions?

13. Section 5.1:
"As a result, intermediaries and
   the UAS at least know the original Request-URI, and if the Request-
   URI was modified by a previous hop. "
This is inaccurate, since intermediaries may have removed H-I for privacy or other reasons. Best to delete the sentence.

14. Section 5.1:
"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"."
I am not sure that 'none' ensures anything - it is only a request according to RFC 3323.

15. Section 5.1:
"A new hi-entry  MUST then be added for the URI from
   the Contact header (which becomes the new Request-URI) "
The Contact header field could contain >1 URIs. I think what we want to say is that the UAC MUST populate the new-hi-entry with the URI chosen as the Request-URI for the new request.

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.

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?

18. Section 5.2.1:
"The last hi-entry reflects the most recent
   target and MUST contain the Request-URI for the received request,"
If I interpret this correctly, this is talking about what the UAS receives. What the UAS receives is outside the control of the UAS, so we can't use RFC 2119 language. Should be "will".

19. Section 5.2.1:
"e.g., the last proxy does
   not support History-Info"
In the previous sentence we used the term "previous entity", so it would be better to stick to that term rather than "last proxy".

20. Section 5.2.1:
"hi-index attribute"
and
"hi-target attribute"
Up till now we have called these parameters rather than attributes.

21. Section 5.2.1:
"The
   addition of the missing hi-entry ensures that the most complete
   information can be provided in the response ..."
Not sure that it is "most complete" - "more complete" would be better, since there could still be some missing entries from upstream.

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.

23. Section 5.2.2:
"If the "histinfo" option tag is received in a request, the UAS MUST
   include any History-Info received in the request in the subsequent
   response"
This is incorrect for a B2BUA - a B2BUA should be allowed to use information received from its other interface. Also it is not necessarily correct for a regular UAS, since I would have thought a UAS should be required to include the hi-entry inserted in accordance with 5.2.1, rather than using just the H-I received.

24. Section 5.2.2:
"The processing of History-Info in responses follows the methodology
   described in Section 16.7 of [RFC3261], "
We can't refer to 16.7 of RFC 3261, because that is for proxies, not UASs.

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).

26. Section 6:
"A Reason MAY be associated with the hi-targeted-to-uri that has been
   retargeted as shown in the example in Appendix B.1."
It would be good to be more precise, since B.1 is long - refer to A6, perhaps.

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.

28. Section 6.1.1:
"The proxy MUST add a separate hi-entry in each
      separate outgoing request for each of the current (outgoing)
      targets in the target set."
Ambiguous - there should be only one entry per request - not one per target in each request.
Perhaps it should say "For each outgoing request relating to a target in the target set, the proxy MUST add a single hi-entry identifying that target. For this new hi-entry, the proxy MUST..."

29. Section 6.1.2:
"When re-sending a request as "
I don't think this is really resending - we are retargeting, and therefore changing some aspects of the original request.

30. Section 6.1.2:
"in the order indicated by the indexing (see
      Section 7.3.3)"
We really need a more precise reference - where in 7.3.3 does it tell me how to use the aggregated information?

31. Section 6.1.2:
"If the received error response did not include
      any History-Info header fields, the proxy MUST use the same
      History-Info header fields that were sent in the outgoing request
      that failed to build the outgoing request."
First, the two instances of "outgoing request" are confusing - I think the second should be "new outgoing request" or "retargeted request".
Second, what if some responses include aggregated information and others don't?

32. Section 6.1.2:
"Same as per Step 2 above for the normal forwarding case
      Section 6.1.1."
This is confusing, because 6.1.1 is not on "normal forwarding case" but on "initial requests".

33. Section 6.1.3:
"When re-sending a request as "
Again I don't think "re-sending" is the correct term.

34. Section 6.1.3:
"   Step 1:  Including Previous Entries
      The proxy MUST include the History-Info header fields that were
      sent in the outgoing request that is being redirected."
This seems to be a significant difference from the 4xx/5xx/6xx case. In that case we include any hi-entries from downstream entities that have sent back the 4xx/5xx/6xx - why not in the 3xx case too?

35. Section 6.1.3:
"add a Reason header this
      entry"
Change "this" to "to this".

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?

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.

38. Section 7.1:
"he hi-target is added for a hi-entry when it is
      first added in a History-Info header field, and only one value is
      permitted"
I believe it should say "only one parameter is permitted". True that parameter ('rc' or 'mp') can have only one value, but I don't think that is the point we are trying to make.

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?

40. Section 7.3.3 item 6:
"When a response is built and it represents the aggregate of
       responses to multiple forks "
Suddenly we are talking about forks when previously we were talking about branches.

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"?

42. Section 7.1.3, item 6:
"See
       Appendix B.1 for an example"
It is unclear where exactly in B.1 I am supposed to look - searching for '1.1.1' or '1.1.2' produces no results. Please cite the specific messages.

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.

John

---

From: Mary Barnes <[email-masked]>
Date: Tue, 2 Nov 2010 14:25:05 -0500

Hi John,

Responses inline below [MB].  I will skip the ones that I replied to
in the other response [MB].

Thanks,
Mary.

> 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 he…
[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].
> 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 R…
[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]
> 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…
[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]

> 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-tar…
[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]
> What is meant by "such a request"? We have not previously mentioned "request". The preceding text has talked about calls, not requests, but perhaps it should talk about requests.
[MB] I will change "such a request" to "call requests". [/MB]
> Change "exchange" to "obtain". I think that would fit better with the examples that follow.
[MB] Okay. [/MB]
> 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]
> This would make it clear that there can be more than one instance of this information.
[MB] Okay. [/MB]
> 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]
> A REFER does not cause an entity to change the target of a request - it causes an entity to generate a new request. H-I will indeed be added, but that is covered by the statement above about creati…
[MB] Yep. [/MB]
> Contrary to what it says in the first half of the sentence, this does indeed acknowledge that we have a new request as a result of REFER. However, the statement is incorrect because there is no nor…
[MB] I'll add text. [/MB]
> This is misleading, because there is indeed H-I sent to 192.0.2.7. I think what it should say is that the H-I sent to 192.0.2.3 and subsequently sent back to Alice does not contain an entry for tar…
[MB] yep. [/MB]
> Why is this only a SHOULD, not a MUST? What would be the exceptions?
[MB] This was issue  #28  where Dale suggested it be change from a
"MAY" to a "SHOULD" (with which you agreed in the email thread).  But,
I don't have a problem to change this to a MUST. [/MB]
> This is inaccurate, since intermediaries may have removed H-I for privacy or other reasons. Best to delete the sentence.
[MB] Okay. HOwever, entries should not be removed for privacy - that
was a change from RFC 4244 - they MUST be anonymized.  [/MB]
> I am not sure that 'none' ensures anything - it is only a request according to RFC 3323.
[MB] Then I'll change it from "ensure" to "request". [/MB]
> The Contact header field could contain >1 URIs. I think what we want to say is that the UAC MUST populate the new-hi-entry with the URI chosen as the Request-URI for the new request.
[MB] Yes. [/MB]
> 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.…
[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]
> Is "current hi-entry" the "new hi-entry" from a couple of sentences earlier?
[MB] Yes. Do you have a terminology preference? [/MB]
> If I interpret this correctly, this is talking about what the UAS receives. What the UAS receives is outside the control of the UAS, so we can't use RFC 2119 language. Should be "will".
[MB] Yep. [/MB]
> In the previous sentence we used the term "previous entity", so it would be better to stick to that term rather than "last proxy".
[MB] Okay. [/MB]
>
> 20. Section 5.2.1:
> "hi-index attribute"
> and
> "hi-target attribute"
> Up till now we have called these parameters rather than attributes
[MB] I'll change to parameter [/MB].
> Not sure that it is "most complete" - "more complete" would be better, since there could still be some missing entries from upstream.
[MB] Most complete as "possible" - but I can change to "more". [/MB]
> 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]
> This is incorrect for a B2BUA - a B2BUA should be allowed to use information received from its other interface. Also it is not necessarily correct for a regular UAS, since I would have thought a UA…
[MB] We can reword something like the following to capture your concern:

   If the "histinfo" option tag is received in a request, the UAS MUST
   include any History-Info received in the request and any hi-entries
   added by the UAS in the subsequent response.  In addition, in
   the case of a B2BUA, the UAS MAY include any hi-entries
   received by the UAC in a response in the subsequent response
   sent by the UAS.

[/MB]

> We can't refer to 16.7 of RFC 3261, because that is for proxies, not UASs.
[MB] See reply in other email response [/MB]
> 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 understan…
[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]
> It would be good to be more precise, since B.1 is long - refer to A6, perhaps.
[MB] Okay. [/MB]
> 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]
> Perhaps it should say "For each outgoing request relating to a target in the target set, the proxy MUST add a single hi-entry identifying that target. For this new hi-entry, the proxy MUST..."
[MB] Yes - your suggestion is more clear. [/MB]
> I don't think this is really resending - we are retargeting, and therefore changing some aspects of the original request.
[MB] I'll change to "sending the retargeted request" [/MB]
> We really need a more precise reference - where in 7.3.3 does it tell me how to use the aggregated information?
[MB] 7.3.3. refers to RFC 3261 Step 7
       "Aggregate Authentication Header Field Values", which states:
         "the proxy MUST collect any WWW-
         Authenticate and Proxy-Authenticate header field values from
         all other 401 (Unauthorized) and 407 (Proxy Authentication
         Required) responses received so far in this response context
         and add them to this response without modification before
         forwarding.  "

It's actually easier to just reword that to match what is done for
History-Info header field something like the following:
         The SIP entity MUST collect any History-Info header
         field values from
         all other responses received so far in this response context
         and add them to this response without modification before
         forwarding.
[/MB]

> First, the two instances of "outgoing request" are confusing - I think the second should be "new outgoing request" or "retargeted request".
[MB] I'll change to "new outgoing request" since the other request
could also have been retargeted.
> Second, what if some responses include aggregated information and others don't?
[MB]  That shouldn't matter.  The receiving entity will use what it
can. If the normative procedures are followed, it's fairly
deterministic as to when the aggregated information should be used.
[/MB]
> This is confusing, because 6.1.1 is not on "normal forwarding case" but on "initial requests".
[MB]  Section 6.1.2. use of "initial" is referring to both the case of
the "initial" hi-entry to be added (bullet 1) AND the case whereby a
Proxy received a request and it is adding the "initial" hi-entry for
the first ("initial") retargeting.  The "normal" forwarding is
specifically bullet #3.  I think it would be clearer if we just
removed the word "initial" from the title and first paragraph and add
an explicit reference to bullet 3. [/MB]
> Again I don't think "re-sending" is the correct term.
[MB] I'll change to the "generating new requests"  [/MB]
> This seems to be a significant difference from the 4xx/5xx/6xx case. In that case we include any hi-entries from downstream entities that have sent back the 4xx/5xx/6xx - why not in the 3xx case to…
[MB] See response to issue 25 in your previous set of comments. [/MB]
> 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]
> 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]
> I believe it should say "only one parameter is permitted". True that parameter ('rc' or 'mp') can have only one value, but I don't think that is the point we are trying to make.
[MB] Correct. [/MB]
> 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]
> Suddenly we are talking about forks when previously we were talking about branches.
[MB] A branch reflects a fork.  I'll clarify the text  in item 6, such
that it reads:
"the index MUST be captured
       for each forked request, creating a new branch,  per the rules above..."
and change the use of forks to branch in the body of item 6.
[/MB]
> 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]
> It is unclear where exactly in B.1 I am supposed to look - searching for '1.1.1' or '1.1.2' produces no results. Please cite the specific messages.
[MB] Okay. [/MB]
> 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]
>
> John
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Nov 2010 10:15:34 +0100

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]]
> Sent: 02 November 2010 19:25
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
>
> Hi John,
>
> > 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.
[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".
> > 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...
[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".
[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:
> > 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?
[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>
> in RFC 5627 (earlier versions of GRUU did use the term "home
[JRE] Good.

<snip/>
> > This overloads the word target. Perhaps a better generic
> term for these parameters would be "Derivation".
[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/>
> > 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.
[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.

> [MB] Yes. Do you have a terminology preference? [/MB]
[JRE] I would use "new hi-entry".

<snip/>
> > 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.
[JRE] OK, I can live with MUST, but please use active voice.

<snip/>
> > 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).
[JRE] So it should say "as described in Section 7.3.4 for adding to a History-Info entry" or something similar.

<snip/>
> > It says we are inserting an entry, not replacing any
> existing entries. Value "1" will not apply if there is an
> existing entry.
[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/>
> > 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?
[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.

> specifically in the ABNF for the header. [/MB]
[JRE] See my proposal above for rewording this.

<snip/>
> > 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?
[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/>
> the response to the entity that would have added the hi-entry with
[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/>
> > 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.
[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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Nov 2010 11:41:41 +0100

> [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].

If you look at the definitions in RFC 3261 you will find that "header" and "header field" are terms with two very different meanings, so I would support the change to "header field".

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: Tuesday, November 02, 2010 7:25 PM
> To: Elwell, John
> Cc: [email-masked]
> Responses inline below [MB].  I will skip the ones that I
> replied to in the other response [MB].
>
> Thanks,
> Mary.
>
> [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].
> >
> [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]
> >
> [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]
>
> >
> 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]
> >
> > 5. Section 1:
> > What is meant by "such a request"? We have not previously
> mentioned "request". The preceding text has talked about
> calls, not requests, but perhaps it should talk about requests.
> >   involved with the call to exchange  additional
> information relating
> > to
> [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]
> >
> > 8. Section 4:
> > I think it would be better to say "For each target used for
> forwarding a request, the  following information is carried
> in the History-Info header as detailed in Section 7.1:"
> [MB] I will just change to "Indicates.." which matches the
> form of the other bullets in that list. [/MB]
> >
> > 10. Section 4:
> > A REFER does not cause an entity to change the target of a
> request - it causes an entity to generate a new request. H-I
> will indeed be added, but that is covered by the statement
> above about creating a new request.
> [MB] Yep. [/MB]
> >
> > 11. "propagates any
> > Contrary to what it says in the first half of the sentence,
> this does indeed acknowledge that we have a new request as a
> result of REFER. However, the statement is incorrect because
> there is no normative statement (e.g., in section 5)
> concerning this special behaviour for REFER. There is merely
> a requirement in Appendix A.
> > This is misleading, because there is indeed H-I sent to
> 192.0.2.7. I think what it should say is that the H-I sent to
> 192.0.2.3 and subsequently sent back to Alice does not
> contain an entry for target 192.0.2.7.
> [MB] yep. [/MB]
> >
> > 12bis. Section 5.1:
> > "In addition, the UAC
> [MB] This was issue  #28  where Dale suggested it be change
> from a "MAY" to a "SHOULD" (with which you agreed in the
> email thread).  But, I don't have a problem to change this to
> a MUST. [/MB]
> >
> > 13. Section 5.1:
> > This is inaccurate, since intermediaries may have removed
> H-I for privacy or other reasons. Best to delete the sentence.
> [MB] Okay. HOwever, entries should not be removed for privacy
> - that was a change from RFC 4244 - they MUST be anonymized.  [/MB]
> >
> > 14. Section 5.1:
> > The Contact header field could contain >1 URIs. I think
> what we want to say is that the UAC MUST populate the
> new-hi-entry with the URI chosen as the Request-URI for the
> new request.
> [MB] Yes. [/MB]
> >
> > 16. Section 5.1:
> [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]
> >
> > 17. Section 5.1:
> > If I interpret this correctly, this is talking about what
> the UAS receives. What the UAS receives is outside the
> control of the UAS, so we can't use RFC 2119 language. Should
> be "will".
> [MB] Yep. [/MB]
> >
> > 19. Section 5.2.1:
> > In the previous sentence we used the term "previous
> entity", so it would be better to stick to that term rather
> than "last proxy".
> [MB] Okay. [/MB]
> >
> > 20. Section 5.2.1:
> > "hi-index attribute"
> > and
> > "hi-target attribute"
> > Not sure that it is "most complete" - "more complete" would
> be better, since there could still be some missing entries
> from upstream.
> [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]
> >
> > 23. Section 5.2.2:
> > This is incorrect for a B2BUA - a B2BUA should be allowed
> to use information received from its other interface. Also it
> is not necessarily correct for a regular UAS, since I would
> have thought a UAS should be required to include the hi-entry
> inserted in accordance with 5.2.1, rather than using just the
> H-I received.
> [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]
> >
> > 26. Section 6:
> [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]
> >
> > 28. Section 6.1.1:
> > Perhaps it should say "For each outgoing request relating
> to a target in the target set, the proxy MUST add a single
> hi-entry identifying that target. For this new hi-entry, the
> proxy MUST..."
> > I don't think this is really resending - we are
> retargeting, and therefore changing some aspects of the
> original request.
> > We really need a more precise reference - where in 7.3.3
> does it tell me how to use the aggregated information?
> It's actually easier to just reword that to match what is
> done for History-Info header field something like the following:
> > First, the two instances of "outgoing request" are
> confusing - I think the second should be "new outgoing
> request" or "retargeted request".
> [MB] I'll change to "new outgoing request" since the other
> request could also have been retargeted.
> [MB]  That shouldn't matter.  The receiving entity will use
> what it can. If the normative procedures are followed, it's
> fairly deterministic as to when the aggregated information
> should be used.
> [/MB]
> >
> > 32. Section 6.1.2:
> > This is confusing, because 6.1.1 is not on "normal
> forwarding case" but on "initial requests".
> [MB]  Section 6.1.2. use of "initial" is referring to both
> the case of the "initial" hi-entry to be added (bullet 1) AND
> the case whereby a Proxy received a request and it is adding
> the "initial" hi-entry for the first ("initial") retargeting.
>  The "normal" forwarding is specifically bullet #3.  I think
> it would be clearer if we just removed the word "initial"
> from the title and first paragraph and add an explicit
> reference to bullet 3. [/MB]
> >
> > 33. Section 6.1.3:
> > This seems to be a significant difference from the
> 4xx/5xx/6xx case. In that case we include any hi-entries from
> downstream entities that have sent back the 4xx/5xx/6xx - why
> not in the 3xx case too?
> [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
> information is there. Certainly, it's clear that it's not
> defined specifically in the ABNF for the header. [/MB]
> >
> > 38. Section 7.1:
> > I believe it should say "only one parameter is permitted".
> True that parameter ('rc' or 'mp') can have only one value,
> but I don't think that is the point we are trying to make.
> [MB] Correct. [/MB]
> >
> > 39. Section 7.3.2:
> [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]
> >
> [MB] A branch reflects a fork.  I'll clarify the text  in
> item 6, such that it reads:
> 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]
> >
> > It is unclear where exactly in B.1 I am supposed to look -
> searching for '1.1.1' or '1.1.2' produces no results. Please
> cite the specific messages.
> [MB] Okay. [/MB]
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 10:05:04 -0500

The following is giving me heartburn:

> shouldn't be "MUST be" and would be more accurate to say "is". [/MB]

I guess this isn't a new concern - its been there all along, but it 
seems very wrong to me. (Warning - this is long.) Specifically,

There is a real difference between Reason as a parameter of an H-I entry 
and an H-I entry containing a URI that contains a Reason header as a URI 
parameter. A URI parameter has a specific meaning - it specifies a 
Header that is to be incorporated into a request that uses that URI as 
an R-URI.

Depending on details of how H-I entries are constructed during 
retargeting, it may be that a retarget URI would contain URI parameters, 
and those would end up in an H-I entry. There could be a Reason header 
included in the retarget URI. I *think* the procedures for UAC and proxy 
imply that the retargeted request would be constructed first - thus 
removing embedded parameters and making them headers in the request - 
*before* capturing the R-URI for H-I, but I'm not certain of that. If 
not, then there could be ambiguity about the origin and meaning of a 
Reason header in an H-I URI.

Even if that is not a problem, there are potential problems if an H-I 
entry is ever used to construct a new request. For instance, if someone 
were to analyze H-I to identify the URI of some entity (say the caller) 
in order to send a new request there, it would lift the URI from H-I and 
put it into a new request. Then the Reason URI parameter would, 
according to 3261, be removed and be added as a header to that new 
request. That isn't catastrophic, but I think its at least misleading, 
because:

The reason is on the wrong URI. The Reason explains why the retargeted 
URI is being used, so it belongs in the message addressed to that URI. 
It makes no sense that it be in a request to the R-URI that, in some 
prior usage, was eventually retargeted.

Bottom line: the H-I use of Reason as a URI header parameter is a hack 
and an abuse of that mechanism. It might be benign and forgivable if it 
were consistent with the intended use of that mechanism. But it seems it 
is not - that it is at best the re-purposing of that mechanism in a case 
where it, arguably, might be thought not to conflict with legitimate use 
of the URI header parameter mechanism. I'll argue it isn't that benign - 
that there are overlaps where the uses overlap.

H-I should have had its own header field parameter for this purpose - 
not use the Reason header.

This has ripple effects. Now we have 
draft-mohali-sipcore-reason-call-forwarding which is defining new reason 
codes which are intended specifically for use with H-I, without any 
contemplation of their use in a real Reason header in a request. This is 
insanity - but not for the author who is just trying to work within the 
existing system. Its just an example of the mess created by the abuse of 
repurposing Reason within H-I.

I commented to the author of draft-mohali-sipcore-reason-call-forwarding 
that I felt any extensions to Reason needed to be justified in their own 
right, without reference to H-I. In fact what is proposed there *does* 
make sense in its own right, without regard to H-I *if* it is used in 
the retargeted request, rather than the request that is about to be 
retargeted.

This could be fitted into H-I. When retargeting, it could be specified 
that a Reason header should be added to the new request, explaining why 
it was retargeted. Then whoever makes the H-I entry for that could 
include in the H-I entry for that request the R-URI of the request with 
any Reason headers in that request added to the entry as URI parameters. 
However this would be incompatible with 4244 because it would change 
which entry contains the reason.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Sun, 7 Nov 2010 17:39:15 -0600

I think there is still some confusion here - the Reason is NOT a URI
parameter. It is a SIP header field that is escaped in the URI for
compactness.  In earlier versions, we had a separate parameter in the
SIP History-Info header for Reason, but Rohan suggested to just escape
the existing Reason header in the URI so as not to redefine Reason
parameters.

The Reason header is intended to tag the Reason why the hi-targeted-to
URI was retargeted and thus it goes with the "old" hi-entry versus the
"new" one.  We originally had two URIs for each hi-entry (the old and
the new) . The idea of capturing the "new" is so that you already have
the old entry when you do the retarget, noting that when an entity
goes to process History-Info, the last entry isn't typically useful,
since it should always be the URI in the received request.  So,
logically, for each request that is retargeted, you have the "old" and
"new", so they really are related and .

Also, note that we cannot change this now even if it were the right
thing to do due to backwards compatibility.

Mary.

On Sun, Nov 7, 2010 at 9:05 AM, Paul Kyzivat <[email-masked]> wrote:
>>> 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...
>>
>>> 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:
>>> 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?
>>
> I guess this isn't a new concern - its been there all along, but it seems
> very wrong to me. (Warning - this is long.) Specifically,
>
> There is a real difference between Reason as a parameter of an H-I entry and
> an H-I entry containing a URI that contains a Reason header as a URI
> parameter. A URI parameter has a specific meaning - it specifies a Header
> that is to be incorporated into a request that uses that URI as an R-URI.
>
> Depending on details of how H-I entries are constructed during retargeting,
> it may be that a retarget URI would contain URI parameters, and those would
> end up in an H-I entry. There could be a Reason header included in the
> retarget URI. I *think* the procedures for UAC and proxy imply that the
> retargeted request would be constructed first - thus removing embedded
> parameters and making them headers in the request - *before* capturing the
> R-URI for H-I, but I'm not certain of that. If not, then there could be
> ambiguity about the origin and meaning of a Reason header in an H-I URI.
>
> Even if that is not a problem, there are potential problems if an H-I entry
> is ever used to construct a new request. For instance, if someone were to
> analyze H-I to identify the URI of some entity (say the caller) in order to
> send a new request there, it would lift the URI from H-I and put it into a
> new request. Then the Reason URI parameter would, according to 3261, be
> removed and be added as a header to that new request. That isn't
> catastrophic, but I think its at least misleading, because:
>
> The reason is on the wrong URI. The Reason explains why the retargeted URI
> is being used, so it belongs in the message addressed to that URI. It makes
> no sense that it be in a request to the R-URI that, in some prior usage, was
> eventually retargeted.
>
> Bottom line: the H-I use of Reason as a URI header parameter is a hack and
> an abuse of that mechanism. It might be benign and forgivable if it were
> consistent with the intended use of that mechanism. But it seems it is not -
> that it is at best the re-purposing of that mechanism in a case where it,
> arguably, might be thought not to conflict with legitimate use of the URI
> header parameter mechanism. I'll argue it isn't that benign - that there are
> overlaps where the uses overlap.
>
> H-I should have had its own header field parameter for this purpose - not
> use the Reason header.
>
> right, without reference to H-I. In fact what is proposed there *does* make
> sense in its own right, without regard to H-I *if* it is used in the
> retargeted request, rather than the request that is about to be retargeted.
>
> This could be fitted into H-I. When retargeting, it could be specified that
> a Reason header should be added to the new request, explaining why it was
> retargeted. Then whoever makes the H-I entry for that could include in the
> H-I entry for that request the R-URI of the request with any Reason headers
> in that request added to the entry as URI parameters. However this would be
> incompatible with 4244 because it would change which entry contains the
> reason.
>
>        Thanks,
>        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Nov 2010 20:05:10 -0500

Yes, it sucks.  And it's wrong.  I raised it last year here:
http://www.ietf.org/mail-archive/web/sipcore/current/msg00612.html

But we're stuck with it for backwards compatibility.

And it's even worse than you think.  Apparently 3gpp uses H-I with a "cause" URI param a la RFC 4458, rather than an embedded Reason header's cause param.

On the other hand all of this will help me sell more boxes, so I think I'll shut up now...

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 20:22:26 -0500

Hadriel,

OK, I guess I'm way late on this.

This bis is a chance to fix problems isn't it?
We should at least talk about the problems and see if we can figure some 
way around them. We may have to grandfather some behavior, but couldn't 
we define a better alternative and deprecate the broken stuff?

And if 3gpp is doing something that isn't even consistent with 4244, 
that is *their* problem, and Acme's opportunity.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 20:41:51 -0500

On 11/7/2010 6:39 PM, Mary Barnes wrote:
> compactness.

I don't think there is any real confusion. Its just that the terminology 
is awkward. We have parameters to headers, and we have headers that are 
parameters to URIs.

> In earlier versions, we had a separate parameter in the

I even remember him making that suggestion. Too bad he isn't around so 
we can wring his neck. I thought it was a hack at the time, but didn't 
then realize how much trouble it would cause.

> "new" one.

Just stating it that was exposes the problem.
The intent of the Reason header is specified in RFC3326.
Any use that isn't consistent with that is an abuse.
Its intended to indicate why a *request* is being sent.

> We originally had two URIs for each hi-entry (the old and

So then we allow it continue to metastasize, e.g. by defining new Reason 
values that aren't ever expected to be used in requests, and that 
wouldn't make any sense if they were?

	Thanks,
	Paul

> Mary.
>
> On Sun, Nov 7, 2010 at 9:05 AM, Paul Kyzivat<[email-masked]>  wrote:

---

From: Mary Barnes <[email-masked]>
Date: Sun, 7 Nov 2010 21:14:09 -0600

I totally agree that escaping the Reason header is a hack, but that
was a hack that was agreed way long ago.  While it does warp the
definition of the Reason header, I do not think it breaks anything and
this document does NOT define any new values for the Reason header.
The definition of new values is entirely out of scope and orthogonal
to the History-Info header.  The WG does have control over whether new
values are defined.  And, there has still been no conclusion to the
long time discussion as to whether the use of Reason headers is
appropriate in Responses.

I personally feel that this is a rathole and that we will never finish
4244bis if we continue debating this issue.

Regards,
Mary.

On Sun, Nov 7, 2010 at 7:41 PM, Paul Kyzivat <[email-masked]> wrote:
> I don't think there is any real confusion. Its just that the terminology is
> awkward. We have parameters to headers, and we have headers that are
> parameters to URIs.
>
> I even remember him making that suggestion. Too bad he isn't around so we
> can wring his neck. I thought it was a hack at the time, but didn't then
> realize how much trouble it would cause.
>
> values that aren't ever expected to be used in requests, and that wouldn't
> make any sense if they were?
>
>        Thanks,
>        Paul
>
>> Mary.
>>
>>> retargeting,
>>> entry
>>> URI
>>> make
>>> that

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Nov 2010 05:55:13 +0100

I agree with Paul's concerns, and I think we should use bis as an opportunity to get this right, even if we have to grandfather some existing mechanism. The Mohali draft is evidence that the present mechanism causes further problems down the line.

John

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 08 November 2010 01:42
> To: Mary Barnes
> Cc: [email-masked]
> MUST include in
> >> I commented to the author of 
> draft-mohali-sipcore-reason-call-forwarding

---

From: Shida Schubert <[email-masked]>
Date: Mon, 8 Nov 2010 14:48:26 +0900

I don't agree. This is going to completely break backward 
compatibility. 

 Regards
  Shida

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 07:27:39 +0100

I have the same problem as Shida has.
We have already deployed RFC4244 and RFC4458 for Call forwarding. And a new mechanism will violate our network.
So from my point of view we have to life with that what is existing.

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Shida Schubert
Gesendet: Montag, 8. November 2010 06:48
An: Elwell, John
Cc: [email-masked]
Betreff: Re: [sipcore] Reason as a parameter rather than an escaped header(was Comments on draft-ietf-sipcore-rfc4244bis-02)

 Regards
  Shida

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Nov 2010 01:31:47 -0500

I know this is beating a dead horse, but breaking backwards compatibility for Hist-Ifno may be a GOOD thing.
Seriously.  Afaict, "legacy" H-I is broken.  It didn't solve people's problems, in an interoperable fashion.  That's why we needed 4244bis to begin with, ain't it?

In fact, start with a new header name, if need be.
To be transparent, we can name the new header "Possible-Targets-Lottery:" and if you guess the right "real" target from the list, you win some award.  :)

-hadriel

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 08:53:02 +0100

Hi,
we have already a mechanism putting a "cause" into the URI which is the target.
RFC4458 describes this for diverting reasons. 
So it is a own header used for History Info no new definition is needed.
And so this mechanism could be extended by the proposed values in http://tools.ietf.org/html/draft-mohali-sipcore-reason-extension-application-00 and other needed. 

So in final the Reason is included within the "retargeting" URI based on the received response.
And the cause as defined in RFC4458 is in the target URI.

Comments? 

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
Gesendet: Montag, 8. November 2010 07:32
An: Shida Schubert
Cc: [email-masked]
Betreff: Re: [sipcore] Reason as a parameter rather than an escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

-hadriel

---

From: <[email-masked]>
Date: Tue, 9 Nov 2010 01:42:46 +0100

Hi,

Trying to show how RFC4244 was useless as it was designed (not for what it was imagined), I failed. So, I decided to do with the existing abilities with H-I and escaped Reason header...
Being involved in 3GPP debates on this topic (usage for CDIV service), I just want to say that, 3GPP is not using an other solution. 3GPP, exactly uses what is possible with RFC4244 and RFC 4458: a combination of both Reason header field parameter escaped a URI (associated to redirecting hi-entry) and cause URI parameter (associated to the retargeted-to hi-entry) ; both with a parameter named "cause=xxx" but not with the same values significations and not located in the same hi-entry (childlishly simple!). You can imagine misinterpretation...
If it is complicated only for CDIV service (Keith and Roland can confirm) what will be the future for enriched services??

Having a history header could be usefull ONLY if simple solutions are offered to identify services's needs, select entries by types... For that, a parmeter, a header parameter, a URI parameter... Whatever, if it's clearly defined.

As I've often been told that H-I was already implemented, I choose to propose extensions based on the current header to show where the reasoning can leads. If H-I has to be re-designed, ok, I can re-design the extensions accordingly. But if there is not possibility to have application/services information, IMHO, H-I will stay at IETF.    
If we have the opportinity to fix inconsistencies, lack of clearness, even with no backward compatibility ; I'm in !

About the Reason escaped in the hi-targeted-to-uri parameter of the H-I header field, I'm not sure it has no sense to associate the Reason to the address applying the retargeting.
Beyond the break of backward compatibility, in ISUP, the redirecting reason is associated to the redirecting user (for Call Forwarding).

I see 2 possible interpretations:
1- It is the Reason why a new R-URI has been contacted unsuccessfully. What is the cause of this Retargeted-to destination failure.
2- The reason why the Retageting entity decides to modified the R-URI. eg. After receiving a SIP response, after an internal processing (see my drafts)...

Case 1: It could make sense for a 3xx response where the retargeting is invloved in the response (explicitly request a redirection). In an other situation, it is not the target destination answering with a 486 Busy Here that can determines that call has to be retargeted (it is the entity receiving that response = the Retargeting). In general, we need to know which entity do what. 

Whatever the one chosen, it has to be clearly mentionned, not only with "associated to the hi-retargeted-to-uri" not saying which one. 

Marianne

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de [email-masked]
> Envoyé : lundi 8 novembre 2010 15:53
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [sipcore] Reason as a parameter rather than 
> anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
> 
> Hi,
> And so this mechanism could be extended by the proposed 
> values in 
> http://tools.ietf.org/html/draft-mohali-sipcore-reason-extensi
> on-application-00 and other needed. 
> 
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
> Betreff: Re: [sipcore] Reason as a parameter rather than an 
> escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
> 
> 
> I know this is beating a dead horse, but breaking backwards 
> compatibility for Hist-Ifno may be a GOOD thing.
> Seriously.  Afaict, "legacy" H-I is broken.  It didn't solve 
> people's problems, in an interoperable fashion.  That's why 
> we needed 4244bis to begin with, ain't it?
> 
> To be transparent, we can name the new header 
> "Possible-Targets-Lottery:" and if you guess the right "real" 
> target from the list, you win some award.  :)
> 
> -hadriel
> 
> >> I agree with Paul's concerns, and I think we should use 
> bis as an opportunity to get this right, even if we have to 
> grandfather some existing mechanism. The Mohali draft is 
> evidence that the present mechanism causes further problems 
> down the line.
> >> 
> >> John
> >> 
> >>>> I think there is still some confusion here - the Reason is NOT a 
> >>>> URI parameter. It is a SIP header field that is escaped 
> in the URI 
> >>>> for compactness.
> >>> 
> >>> I don't think there is any real confusion. Its just that the 
> >>> terminology is awkward. We have parameters to headers, 
> and we have 
> >>> headers that are parameters to URIs.
> >>> 
> >>>> In earlier versions, we had a separate parameter in the SIP 
> >>>> History-Info header for Reason, but Rohan suggested to
> >>> just escape
> >>> I even remember him making that suggestion. Too bad he 
> isn't around 
> >>> so we can wring his neck. I thought it was a hack at the 
> time, but 
> >>> didn't then realize how much trouble it would cause.
> >>> 
> >>>> We originally had two URIs for each hi-entry (the old 
> and the new) 
> >>>> . The idea of capturing the "new" is so that you
> >>> already have
> >>>> goes to process History-Info, the last entry isn't typically 
> >>>> useful, since it should always be the URI in the 
> received request.  
> >>>> So, logically, for each request that is retargeted, you have
> >>> the "old" and
> >>> So then we allow it continue to metastasize, e.g. by defining new 
> >>> Reason values that aren't ever expected to be used in 
> requests, and 
> >>> that wouldn't make any sense if they were?
> >>> 
> >>>     Thanks,
> >>>     Paul
> >>> 
> >>>> Mary.
> >>>> 
> >>>>>> 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]
> >>>>> 
> >>>>>>> "For retargets that are the result of an explicit SIP 
> response, 
> >>>>>>> a  Reason MUST be associated with the hi-targeted-to-uri."
> >>>>>> 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
> >>>>> codes which are intended specifically for use with H-I, without 
> >>>>> any contemplation of their use in a real Reason header in a
> >>> request. This is

---

From: <[email-masked]>
Date: Tue, 9 Nov 2010 03:16:53 +0100

Hi,
I see the problems also with the future use of the H-I. But how we could solve it?

Question is if we could make the Reason optional instead mandatory for cases where the retargeting was based on a SIP Response?

I cannot see what will break if we do it as a option. (For Call forwarding it is important that we can count the real forwarding's. It is not really important on which the forwarding's are based.)

Next Question is if we could use instead the RFC4458 causes with further values. I know I asked already this question but I didn't get a clear answer why not to use. RFC4458 does define this causes not only for the cases Voicemail and IVR, it says: "such as".

What are the opinions on that.

The only what I also want to have is a future proof solution as Marianne would like.

Within ISUP the Redirecting reason is within the Redirection Information Parameter included which is not bind to any of the Numbers. It is a own Parameter. So  
there are not the problems where and how to place the "cause"

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 9. November 2010 01:43
An: Jesske, Roland; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: RE: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

Hi,

Having a history header could m be usefull ONLY if simple solutions are offered to identify services's needs, select entries by types... For that, a parmeter, a header parameter, a URI parameter... Whatever, if it's clearly defined.

Marianne

---

From: Shida Schubert <[email-masked]>
Date: Tue, 9 Nov 2010 15:28:21 +0900

Hi Marianne;

 First of all, I have to disagree that RFC4244 is useless. AFAIK 
we are using it in our network and it is providing us with most of 
the functionality that we want, and with revised RFC4244bis 
according to guys actually implementing the stuff, it satisfies 
all the requirements we have so far.

 I agree that RFC4244 is not very simple, I think anybody that had 
to implement RFC4244 had a very difficult time trying to get the 
outcome they wanted. But I know at some country including Japan, 
it is the country wide standard used, and revising the spec in 
non-backword compatible way is going to be a nightmare. 

 I believe that RFC4244bis does clarify a lot of things that required 
guess work and it is a huge improvement over the original.

 Regards
  Shida

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 11 Nov 2010 05:08:15 -0500

From: [email-masked]
> Question is if we could make the Reason optional instead mandatory
> for cases where the retargeting was based on a SIP Response?
> 
> I cannot see what will break if we do it as a option. (For Call
> forwarding it is important that we can count the real
> forwarding's. It is not really important on which the forwarding's
> are based.)

Since 4244 does not require Reason headers, any implementation should
be able to cope with with the absence of Reason.

However, there is a subtle aspect:  In the current 4244bis, it seems
that the presence of a Reason header on a history-entry documents that
the request carrying that URI has completed (and returned the
specified response).  If I'm correct in this, omitting a Reason header
has an additional meaning and so can't be made optional.

> Next Question is if we could use instead the RFC4458 causes with
> further values. I know I asked already this question but I didn't
> get a clear answer why not to use. RFC4458 does define this causes
> not only for the cases Voicemail and IVR, it says: "such as".
> 

If I understand RFC 4458 correctly, the 'cause' URI-parameter is added
to the "new" URI to indicate the reason it was generated or used.
Assuming History-Info shows how and why each request-URI was
generated, the 'cause' URI-parameter is redundant.

However, if we define further 'cause' values, it might provide
additional information.

> Within ISUP the Redirecting reason is within the Redirection
> Information Parameter included which is not bind to any of the
> Numbers. It is a own Parameter. So there are not the problems where
> and how to place the "cause"

It does seem to me that this causes a problem in interworking, but I
might be wrong.

Dale