Subject: [Sip] comments on history-info-00

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 20:58:30 -0400

Mary,

Here are some comments on history-info. I suspect many apply to prior 
versions as well. My apologies if they have been discussed, I have not 
really followed the work closely. Many of my comments are asking for 
much more precision in the document. Generally, I found it to be very 
imprecise, with lots of undefined terminology and vague procedures.

That aside, I have some major issues with the privacy mechanisms, with 
the usage of history-info by redirect servers, with sending a 183 with 
history information, and with the backwards compatibility 
implications. So, here we go:

Firstly, the draft says in many places that applications need to 
document the impact of things. For example, Section 1.1 says:

    Thus, it is highly
    recommended that all applications making use of the request history
    information clearly define the impact of the information not being
    available and specify the processing of such a request.

Does this mean there is some kind of application registry where such 
documentation will exist? Does it mean that applications won't be 
interoperable because they will depend on the presence of these 
headers? The text in 1.1 makes it sound like the information would 
only be present if some local policy prevented its insertion. What 
about cases where the proxy doesn't support it? Even if it does, your 
draft reads very much like it is now going to require every proxy to 
insert this header. Is that so?

Second, section 1.3 talks about the use of the Privacy header. There 
are a few problems here. First, the privacy header gets stripped once 
the privacy service finishes execution. Thus, a downstream proxy would 
not be able to know privacy was requested. To a large degree, this is 
because the privacy header in a request is about privacy of the 
caller. Request history is about the current target (i.e., called 
party). So, in fact, the issue is that if the *called* party requests 
privacy (using a privacy header in a response), the history info 
headers should not be propagated backwards in a response. I dont think 
your draft does that.

Local policy might also play a role, when it is representing the 
privacy interests of a user that is retargeting. In that case, it was 
unclear to me how the proxy prevents downstream elements from 
inserting history-info? Your draft makes it sound like the privacy 
requirements are met if just this one hop avoids insertion. But seeing 
the contact from downstream retargets will often reveal sensitive 
information about a target further upstream.

Section 2.1:

> Targeted-to-URI: the Request URI captured as the Request is 
>         targeted. By capturing a copy of the Request URI in the initial 
>         request, the Retargeted-from-URI is already captured when a 
>         request is retargeted and the Retargeted-to-URI is being 
>         captured.   
>  

I read this many times and could not make sense of it. What does it mean?

Section 2.3.1:

> The UAC SHOULD include the HistInfo option tag in the Supported 
>    header in any request not associated with an established dialog for 
>    which the UAC would like the History-Info in the Response.  In 
>    addition, the UAC should initiate the capturing of the History 
>    Information by capturing the Request-URI as the hi-targeted-to-uri 
>    and initializing the index to 1.  

What if the UAC doesn't support this extension? Can the UAS get 
history info? My understanding is that most, if not all, evnisioned 
applications were for the UAS. This means the UAS can't get 
information unless the caller and many, if not all, proxies along the 
path support it.

Section 2.3.2:

> The processing of History-Info by a UAS in a Request depends upon 
>    local policy and specific applications at the UAS which might make 
>    use of the information.  If the HistInfo option tag is received in a 
>    request, the UAS should include any History-Info received in the 
>    request in the subsequent response.     

I think you mean SHOULD in the last sentence. Also, I think you mean 
that "If the request contained the histinfo option tag in the 
Supported header field of the request, the UAS....".

Also, you've capitalized the H and I in HistInfo. Please don't. Option 
tags are not case sensitive.

Section 2.3.3:

The wording about when to capture is really vague. You need to be much 
more precise in your wording of when the proxy is and isnt going to 
capture history information.

Section 2.3.3.1:

>  If the proxy supports History-Info, the proxy SHOULD add any History-
>    Info collected as it retargets a Request. For retargets that are the 
>    result of an explicit SIP response, the SIP Response Code that 
>    triggered the retargeting MUST be included in the Reason header of 
>    the Targeted-to-URI.

This needs to be more precise. What does it mean "..collected as it 
retargets a request"? How is this information collected? Also, when 
you say "explicit SIP response" - all responses are explicit as far as 
I know. Perhaps you mean when a 3xx response is received? Also, you 
say "Reason header of the Targeted-to-URI". I believe reason is a 
parameter, not a header, in this instance.

and then:
> For retargets as a result of timeouts or 
>    internal events, a Reason header MAY be included in the Reason header 
>    of the Targeted-to-URI. 

what are internal events?

What value does the reason parameter have in the case of timeout? In 
the case of internal events?

and then:
>  Additionally, if a request is received that doesn't include a 
>    captured Request URI from the previous entity, the proxy MAY add an 
>    additional entry, effectively capturing the retargeted-from-URI in 
>    the Request.   

What does it mean for a request to "not include a captured 
Request-URI"? You need to define that. What is contained in the 
additional entry?

I may sound like I am being nit-picky, but in my experience 
specifications need to be very precise in what you want people to do. 
I am confused about what is implied here, and I would imagine many 
others would be confused too.

and then:

> In order to maintain ordering and accurately reflect the nesting and 
>    retargeting of the request, an index MUST be included along with the 
>    Targeted-to-URI being captured. The basic rule for adding the index 
>    are to read the value from the previous History-Info, if available, 
>    and capture the index.n as the index for the History-Info being 
>    captured, where n would typically be 1 for a forwarded request. Thus, 
>    the level of nesting of the index reflects the number of hops.

define previous.

what does it mean to "capture the index.n"? what is index? what is .n? 
  You say its "typically 1". When is it 1, and when is it not one?

and then:
> For 
>    retargets within a proxy, the proxy MUST maintain the current level 
>    of nesting by incrementing the lowest/last digit of the index for 
>    each instance of retargeting, thus reflecting the number of retargets 
>    within the proxy.

I cannot understand this at all.

and then:
> n index MUST NOT be added 
>    in the scenario whereby the received request had no History-Info 
>    header and the retargeted-from-URI is being captured for 
>    completeness.

what does "for completeness" mean? You need to be precise.

> The lack of Reason headers in the captured Request-URIs should be 
>    indicative of the parallel nature of forking (i.e the Request-URIs 
>    are not the result of retargets, but are rather all simultaneous 
>    Targeted-To URIs.)  

should be indicative? Is it, or isnt it?

> A proxy that receives a Request with the HistInfo option tag in the 
>    Supported header, and depending upon a local policy supporting the 
>    capture of History-Info, SHOULD return captured History-Info in 
>    subsequent, provisional and final responses to the Request.  A 183 
>    response MAY be sent explicitly for the purposes of conveying 
>    History-Info prior to the final response. 

I think the first sentence means that the proxy does nothing to 
responses - any history-info in those responses is just passed on. But 
I'm not sure. The sentence says "should return", and return seems like 
an active operation to me. The next sentence actually implies that the 
proxy generate a 183 provisional responses. This means that a UA 
making a call with N proxies will get N extra provisional responses, 
where the first has one history-info value, the next 2, the next 3, 
and so on. The first history info is transmitted to the UAC N times. 
Is that really what we want? It seems very expensive for the UAC.

> It MAY be advantageous for redirect servers to support the receipt of 
>    History-Info in requests.

You can you assign a protocol strength to being advantageous?

I think you mean "A redirect server MAY use information in the 
History-Info header field in a request to determine the URIs that it 
will retarget to.".

> By receiving it in the request, the 
>    Redirect Server MAY be able to optimize the information it sends in 
>    responses by looking at the already targeted-to-URIs.

and what optimization is that? I think you mean that the redirect 
server shouldnt redirect to somewhere that the request has already 
visited. If so, please say that. However, are we sure about that? 
Redirection to a URI already visited can be appropriate in cases where 
there is a spiral, and not a loop. Unless a redirect server is 
maintaining state, how can it make this determiantionabout whether 
this is a spiral or a loop?

> HistInfo      When used with the Supported header, [RFCXXXX] 
>                  this option tag indicates support 
>                  for the History Information to be  
>                  captured for requests and returned in 
>                  subsequent responses. This tag is not 
>                  used in a Proxy-Require or Requires  
>                  header field since support of  
>                  History-Info is optional.       

Require header field, not Requires.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 22 Jul 2003 14:35:57 -0500

This email appears to have gotten lost somewhere, so I'm resending (I
apologize if it ends up being a duplicate).

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH] 
Sent: Monday, July 21, 2003 1:42 PM
To: 'Jonathan Rosenberg'
Cc: [email-masked]
Subject: RE: [Sip] comments on history-info-00

Jonathan,

Some initial responses are embedded below [MB].  I do, however, have some
more general comments that might also address your concerns as follows:

- In general, it seems that alot of your confusion around the fundamental
processing of History-Info is around the fact that we've optimized to only
capturing a single URI, which adds to some of the terminology concerns that
you have. I'm beginning to wonder if it wouldn't be better to go back to
capturing both the retargeted-from and retargeted-to URIs?  The advantage of
this is that it doesn't introduce this "seeding" or "kickstarting" of HI
when a proxy receives a request with no HI, which introduces these special
cases in the fundamental processing. What this also might be highlighting is
the need to bring some of the background text on the solution options from
appendix D into a background section that precedes the normative text for
HI. 

- As I mentioned during the discussion, I fully agree that there is a
general lack of clarity (and as you suggest a need for more precision)
around the fundmental normative processing after discussions with folks that
are planning on implementing this draft. In particular, the processing
around the Index is quite unclear; I think adding the index to all the
examples and adding additional example flows will also help with the concern
here. 

Regards,
Mary H. Barnes
[email-masked]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, July 15, 2003 7:58 PM
To: [email-masked]
Subject: [Sip] comments on history-info-00

Mary,

    Thus, it is highly

Does this mean there is some kind of application registry where such 
documentation will exist? 
[MB]: No, I think the use of History-Info is no different than any other
optional SIP header and that application scenarios in the form of call flows
will be needed in Informational (or as has become the trend BCPs) to
effectively document the use of the header. 

Does it mean that applications won't be 
interoperable because they will depend on the presence of these 
headers? 
[MB]: Ditto my previous comment.

The text in 1.1 makes it sound like the information would 
only be present if some local policy prevented its insertion.
[MB] I think you mean "didn't prevent" rather than "prevented" in this
preceeding sentence.  And, yes,local policy is one factor that determines
whether the History-Info is inserted.

What about cases where the proxy doesn't support it? 
[MB]: Then, the information isn't captured for any retargeting by that
proxy, but any previous HI entries should remain, since proxies should not
remove headers. 

Even if it does, your 
draft reads very much like it is now going to require every proxy to 
insert this header. Is that so?
[MB]: No, it's an optional header. However, for systems where this isn't
supported, the functionality of an end application might be limited. 

[MB]: This is similar to several threads of discussion we had around the
requirements about 6 months ago:
http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg03695.ht
ml
which I believe was addressed in a subsequent revision to the requirements
(although, I'll have to dig for the details on that as I don't see that
readily visible in the archives or cached in my email archives at this
time).        

[MB]: I agree, I think local policy is this primary mechanism for the
privacy solution for HI and per the email discussion.  As I highlighted in
the meeting, the privacy aspects of the solution are indeed incomplete and
hopefully will be addressed adequately in the next version. 

[MB] This has to be read in context of the definitions for
Retargeted-from-URI and Retargeted-to-URI in the Definitions section.
Because we're optimizing by capturing only a single URI (the "new" URI in
the request being retargeted) rather than capturing both the "old" and "new"
URIs for each retargeting (and thus duplicating information since the "new"
of the previous HI entry would become the "old" for the next entry). 

[MB] If the UAC doesn't include the option tag, then that means that it
won't get the History-Info in any responses.  Whether the proxy captures
History-Info is local policy; the text is attempting to state that if the
proxy is planning on capturing History-Info then it goes ahead and creates
the "zero-th" entry.  We originally were capturing 2 URIs, the original
request URI and the retargeted-to URI. However, to minimize the overhead and
duplicate data, we made the change in the -01 individual draft to only
capture one URI, so that you basically need to "seed" the chain of URIs to
capture the History, by capturing the original URI at the time of the first
re-targeting that you're intending to capture.  So, the UAS can get the
information even if the caller doesn't want it in responses.  You are
correct that for many applications, it would be necessary for many of the
proxies along the path to support it.  

[MB] Correct.

[MB] Noted.

Section 2.3.3:

[MB]: As I mentioned during my presentation of issues during the WG meeting,
this was the same feedback I had received from some folks that in the
process of implementing this and I do improve this in the next version.
However, this section was intended to be a higher level overview of the
processing with the subsequent sub-sections intended to provide the details
of the normative processing. 

[MB]: This was also something I mentioned at the meeting and has to do with
"internal retargeting" which can be the result of things like selecting the
route in a route list, etc. ******************************************

[MB]: It lets an application or end user know why the retargeting occurred.

[MB]: Per my general comment at the beginning of my email response, this has
to do with the current mechanism of only capturing a single URI. 

[MB]: Again, as I mentioned during the meeting, this is an open issue with
the draft that I plan to correct on the next version.

define previous.

[MB]: Another issue related to the general mechanism of capturing a single
URI that I mentioned at the beginning of my email response. 

[MB] Correct. I'll change this from "should be" to "is"

I think the first sentence means that the proxy does nothing to 
responses - any history-info in those responses is just passed on. But 
I'm not sure. The sentence says "should return", and return seems like 
an active operation to me. 
[MB]: The use of HI does not at all change the messaging, but rather just
adds the captured information to the response in the scenarios where it has
been captured. It is not intended to be an "active" operation.  

The next sentence actually implies that the 
proxy generate a 183 provisional responses. 
[MB]: No, that's not what was intended.  This sentence was added in response
to a concern raised that HI didn't appear to be allowed to be sent in
provisional responses.  

This means that a UA 
making a call with N proxies will get N extra provisional responses, 
where the first has one history-info value, the next 2, the next 3, 
and so on. The first history info is transmitted to the UAC N times. 
Is that really what we want? It seems very expensive for the UAC.
[MB]: Per my response to a previous comment above, HI does not at all change
the fundamental messaging, but rather just adds the captured information to
the response in the scenarios where it has been captured.

[MB] Agreed; your suggested wording is a more accurate representation of the
intent of the original statement. 

[MB]: You bring up a valid point that should be clarified.  It might be
better to just remove that statement since it really is an implementation
decision and as you suggest such "optimizations" could be problematic in
some scenarios.  (Although, it might be better to highlight the cautions
should someone want to make such an optimization or highlight perhaps that
it's better not to do such an optimization). 

[MB]: Noted. 

Thanks,
Jonathan R.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 21 Jul 2003 13:42:19 -0500

Jonathan,

Regards,
Mary H. Barnes

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, July 15, 2003 7:58 PM
To: [email-masked]
Subject: [Sip] comments on history-info-00

Mary,

    Thus, it is highly

Even if it does, your 

[MB] Correct.

[MB] Noted.

Section 2.3.3:

define previous.

This means that a UA 

[MB]: Noted. 

Thanks,
Jonathan R.