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

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

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:bob@192.0.2.7 "
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