Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

From: "Ian Elz" <[email-masked]>
Date: Wed, 11 Mar 2009 10:53:59 +0100

Mary, Francois,

Section 4.1 of the draft allows for the addition of the Privacy header
parameter with a value of "history" to be included with the
hi-targeted-to-uri.

Can this be extended to also allow the value "none".

A node adding a H-I entry is allowed to specify the privacy value
"history" either in the Privacy header or as a header parameter
associated with the hi-targeted-to-uri. If the former action is taken by
one node this results in privacy for all history info header entries
even if this is not required. There is no way for privacy of an
individual H-I entry to be set to none if no Privacy is required for the
uri.

This creates a specific problem when interworking with the PSTN where
the privacy is associated with each E.164 number included in the
protocol. If an INVITE is being mapped to ISUP and the H-I entries are
being used to map to redirection numbers then a single Privacy header
with the value "history" will result in all numbers being restricted.

If the Privacy header parameter could include the value "none" then this
would explicitly indicate that the associated uri was allowed to be
presented.

The ability to explicitly allow presentation of specific H-I entries may
also be useful in pure sip implementations.

I don't believe that this change would create any backward compatibility
issues. The existing implementations will continue as deployed but new
implementations could explicitly set no privacy for a specific uri.

There are no security issues other than those already defined in the
draft that an intervening node could modify an existing H-I entry. The
Privacy header value of "none" should only be included by the node in
the same manner as the existing inclusion of the "history" value.

Ian Elz

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 04 March 2009 15:15
To: [email-masked]
Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : An Extension to the Session Initiation
Protocol (SIP) for Request History Information
	Author(s)       : M. Barnes, F. Audet
	Filename        : draft-barnes-sip-rfc4244bis-00.txt
	Pages           : 49
	Date            : 2009-03-04

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request.  This capability enables many enhanced services by providing
the information as to how and why a call arrives at a specific
application or user.  This document defines a new optional SIP
header, History-Info, for capturing the history information in
requests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Mar 2009 13:55:07 +0100

Hi,

My first comment/question on the draft: eventhough there are lots of
examples, do we really need 46 pages? Are we really making History-Info
more clear if we still need that many pages?

I know my comment is not that useful, since I don't propose what to
change/remove, but just as a general comment.

Regards,

Christer

> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> This document defines a standard mechanism for capturing the 
> history information associated with a Session Initiation 
> Protocol (SIP) request.  This capability enables many 
> enhanced services by providing the information as to how and 
> why a call arrives at a specific application or user.  This 
> document defines a new optional SIP header, History-Info, for 
> capturing the history information in requests.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> _______________________________________________
> Sip mailing list  https://www.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: Wed, 11 Mar 2009 08:24:00 -0500

Hi Christer, 

Yes, we can remove a lot of the extra examples in the appendix - that
was what we had in mind for the next revision, since they all need to be
updated (all of them are dated in that they use strict routing). Also,
since there is now a document like target-uri that has better use cases,
we really don't need so many in the protocol spec. So, perhaps, you can
consider adding some detailed flows to target-uri?  

And, you have to keep in mind that the normative text in 4244 is
comprised of about 12 pages (7-18), so yes the size of the document is
misleading in terms of what really has to be implemented

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 7:55 AM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

Hi,

Regards,

Christer

> application or user.  This document defines a new optional SIP header,

> History-Info, for capturing the history information in requests.
> 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 11:52:56 -0500

Ian,

This is an interesting question. I need to think about it some more, but
I don't like the "none" idea as it really must be up to the entity that
added the Privacy header to the request, as to whether it wants the HI
entries that it adds to go outside a domain. My initial thought is that
we can't overrule the overall Privacy header. The thing is that the
Privacy header doesn't preclude gathering the information and using
within a domain AND if it were to not include an hi-entry when the
request leaves the domain for which the proxy is responsible, the
recipient can add the hi-entry for the current request-uri before it
adds the new hi-entry.  

Your PSTN example doesn't strictly map obviously to a SIP model and I
would think you might consider the PSTN hop to be within the same domain
for which the proxy (or gw, I guess) is responsible OR consider this a
walled garden whereby the Privacy header doesn't apply. Which brings me
to a more general question as to how you all deal with other headers
when you do your mapping to the PSTN when there is a Privacy header?  It
would seem this problem isn't unique to History-Info, although I know
little about the details of PSTN I/W.

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 4:54 AM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Mary, Francois,

Ian Elz

-----Original Message-----

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) request.
This capability enables many enhanced services by providing the
information as to how and why a call arrives at a specific application
or user.  This document defines a new optional SIP header, History-Info,
for capturing the history information in requests.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 11 Mar 2009 23:04:46 +0100

I believe in this case the History-Info application-agnosticness 
principle applies.

Why should History-Info enforce something, that goes against the whishes 
of a domain that is adding a hi-entry and should be considered best 
equiped in judging what privacy rules apply for this specific entry.

/Hans Erik

Mary Barnes wrote:
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 17:43:46 -0500

I'm not sure if I'm clear on your concern here - what is the "something"
in the "Why should History-Info enforce..."? 

If by the "something" you mean removing the history-info header (if it's
session or header level privacy), we have to go back to the fundamental
History-Info solution requirements and consider the functionality
provided by the Privacy header in RFC 3324. This isn't about
application-agnostic or not.  The information in the hi-entries can be
considered of the same ilk as the other information that is intended to
be kept private by the use of the Privacy header, thus if the request
indicates session or header levels of privacy, the proxy SHOULD NOT
forward the hi-entries. Note, it's a SHOULD NOT. If your network
configuration is such that there is no privacy issue with sharing that
information, then you can document as such and explain why it's
perfectly okay to forward the hi-entries. 

However, per my note below, even if the prior hop strips out information
that is appropriate to the next domain, the last hi-entry can be added
by that next hop proxy to preserve the information before that proxy
might change the request-uri. 

Mary. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 5:05 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Ian Elz; Audet, Francois (SC100:3055); [email-masked]
Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

/Hans Erik

Mary Barnes wrote:
> Ian,
>
> This is an interesting question. I need to think about it some more, 
> but I don't like the "none" idea as it really must be up to the entity

> that added the Privacy header to the request, as to whether it wants 
> the HI entries that it adds to go outside a domain. My initial thought

> is that we can't overrule the overall Privacy header. The thing is 
> that the Privacy header doesn't preclude gathering the information and

> using within a domain AND if it were to not include an hi-entry when 
> the request leaves the domain for which the proxy is responsible, the 
> would think you might consider the PSTN hop to be within the same 
> domain for which the proxy (or gw, I guess) is responsible OR consider

> this a walled garden whereby the Privacy header doesn't apply. Which 
> brings me to a more general question as to how you all deal with other

> headers when you do your mapping to the PSTN when there is a Privacy 
> header?  It would seem this problem isn't unique to History-Info, 
> although I know little about the details of PSTN I/W.
>
> Regards,
> Mary. 
>

> associated with the hi-targeted-to-uri. If the former action is taken 
> by one node this results in privacy for all history info header 
> entries even if this is not required. There is no way for privacy of 
> an individual H-I entry to be set to none if no Privacy is required 
> for the uri.
>

> If the Privacy header parameter could include the value "none" then 
> this would explicitly indicate that the associated uri was allowed to 
> be presented.
>
> The ability to explicitly allow presentation of specific H-I entries 
> may also be useful in pure sip implementations.
>
> I don't believe that this change would create any backward 
> compatibility issues. The existing implementations will continue as 
> deployed but new implementations could explicitly set no privacy for a
specific uri.

> information associated with a Session Initiation Protocol (SIP)
request.

> or user.  This document defines a new optional SIP header,

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 00:01:38 +0100

When a proxy1 adds a Privacy header with the value history, then why 
should a proxy 2 not be able to say: fine but I override the general 
privacy rule for the specific hi-entry that I add or am responsible for?

I was reacting to  "I don't like the "none" idea as it really must be up 
to the entity that  added the Privacy header to the request, as to 
whether it wants the HI entries that it adds to go outside a domain."

/Hans Erik

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 18:31:46 -0500

And, if you have a network whereby you believe that none of the
information that Proxy 2 will put in hi-entries reveals any information
that is considered private, then you can set your flag, or whatever and
not drop the hi-entries when they leave that domain - that's why it's a
SHOULD NOT - i.e., don't do it unless you've evaluated why it's okay to
do it in that case.  It is clearly documented in 4244 that there is
indeed a loss of information when you use the Privacy header versus
tagging individual hi-entries with the privacy header. Now, we could add
a Recommendation that the Privacy header be used only to tag individual
entries. 

Yes, I agree the "none" is not a good idea (and conflicts with the
Privacy header) as it kindof overrides it, so to speak. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hans Erik van Elburg
Sent: Wednesday, March 11, 2009 6:02 PM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]; Ian Elz; Audet, Francois (SC100:3055)
Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

/Hans Erik

Mary Barnes wrote:
> If by the "something" you mean removing the history-info header (if 
> it's session or header level privacy), we have to go back to the 
> fundamental History-Info solution requirements and consider the 
> functionality provided by the Privacy header in RFC 3324. This isn't 
> about application-agnostic or not.  The information in the hi-entries 
> can be considered of the same ilk as the other information that is 
> intended to be kept private by the use of the Privacy header, thus if 
> the request indicates session or header levels of privacy, the proxy 
> SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your 
> network configuration is such that there is no privacy issue with 
> sharing that information, then you can document as such and explain 
> why it's perfectly okay to forward the hi-entries.
>
> However, per my note below, even if the prior hop strips out 
> information that is appropriate to the next domain, the last hi-entry 
> can be added by that next hop proxy to preserve the information before

> that proxy might change the request-uri.
>
> Mary. 
>
> Why should History-Info enforce something, that goes against the 
> whishes of a domain that is adding a hi-entry and should be considered

> best equiped in judging what privacy rules apply for this specific
entry.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 00:55:39 +0100

But you do not have control over a previously visited proxy using the 
header. Why should that one dictate the privacy needs of the next hop 
proxy in the same domain?

I dont think there is a conflict it is just adding some higher level of 
granularity in controlling the privacy of specific entries.

/Hans Erik

Mary Barnes wrote:
>> I'm not sure if I'm clear on your concern here - what is the
>>     
> "something"
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 19:44:03 -0500

Responses below [MB].

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 6:56 PM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]; Ian Elz; Audet, Francois (SC100:3055)
Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

But you do not have control over a previously visited proxy using the
header. Why should that one dictate the privacy needs of the next hop
proxy in the same domain?
[MB] If the Privacy header is for the request as a whole (i.e., it's not
tagged against a specific hi-entry), then by the definition of the
header in RFC 3323 (with the addition of the priv-value="history"), it
does apply to how the handled is request at every node.  And, again, it
is a SHOULD NOT, so it is possible that there might be conditions under
which you don't want to "dictate the privacy needs..." - you just need
to specify the conditions.  Also, within the same domain, the hi-entries
are NOT removed even if the Privacy header is used. If Proxy 1 and Proxy
2 are responsible for the same domain, then you don't remove the
hi-entries until you leave that domain.  [/MB]

I dont think there is a conflict it is just adding some higher level of
granularity in controlling the privacy of specific entries.
[MB] I had interpreted the "none" to be used with the Privacy header
(for the whole request, not just specific hi-entries), so that the
specific entry can be forwarded outside a domain.  [/MB]

/Hans Erik

Mary Barnes wrote:
> information that Proxy 2 will put in hi-entries reveals any 
> information that is considered private, then you can set your flag, or

> whatever and not drop the hi-entries when they leave that domain - 
> that's why it's a SHOULD NOT - i.e., don't do it unless you've 
> evaluated why it's okay to do it in that case.  It is clearly 
> documented in 4244 that there is indeed a loss of information when you

> use the Privacy header versus tagging individual hi-entries with the 
> privacy header. Now, we could add a Recommendation that the Privacy 
> header be used only to tag individual entries.
>
> I was reacting to  "I don't like the "none" idea as it really must be 
> up to the entity that  added the Privacy header to the request, as to 

>>> deployed but new implementations could explicitly set no privacy for

>>> a

>>> http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.t
>>> x
>>> t
>>>

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 12 Mar 2009 14:42:37 +0100

Mary,

(Written after reading your discussion with Hans Erik.)

First an apology for not making it clear in my original email that a
value of "none" in a Privacy header parameter in a History-Info entry
was only applicable to the uri contained in the hi-targeted-to-uri.

I only suggested using the value "none" as this is a value defined for
the Privacy header which explicitly indicates that privacy is not
required. Any other value with the meaning of explicitly indicating that
there is no privacy required for the specific uri could be used.

With regard to your second paragraph below I understand that the SIP and
PSTN models do not align. You are correct in your assumption that this
problem is not unique for History-Info. The problem also arises with the
Referred-By header. 

I have raised this for History-Info at this time as your new draft
presents an opportunity to correct this problem for the H-I case.

The general SIP privacy issue arises as when the Privacy header was
defined the concept of carrying third party identities in the SIP
messages was not defined. This came later with the REFER Request and the
associated Referred-By header and the History-Info header. 

We should take what opportunities arise to discuss and correct this if
there is a will to make these changes.

Ian Elz

Office: + 44 24 764 35256
[email-masked]

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 11 March 2009 16:53
To: Ian Elz; Francois Audet
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 4:54 AM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Mary, Francois,

Ian Elz

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 08:54:31 -0500

Ian,

Okay, so I think I might understand now - you want to use the "none" to
override the Privacy header that would be (in current 4244/4244bis)
applied to the whole message as it traverses across the n/w from the UAC
to the UAS. Is that correct? That then though changes the meaning of the
Privacy header, as I understand it - i.e., the "none" I thought had to
do with specifying that an intermediary MUST NOT change the value of the
Privacy header. But, I guess you are saying we specify a slightly
different usage in 4244bis such that when we add it to an hi-entry, it
specifies that that hi-entry MUST NOT be dropped by an intermediary.
That might work, although, we would need verbage about the "risks" of
doing so.

Thanks,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 8:43 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]; Audet, Francois (SC100:3055)
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Mary,

Ian Elz

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 11 March 2009 16:53
To: Ian Elz; Francois Audet
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, March 11, 2009 4:54 AM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Mary, Francois,

Ian Elz

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 12 Mar 2009 16:12:20 +0100

Mary,

I was only considering the specific domain case as included in paragraph
2 of section 3.3 in the draft:

                                                  Thus, local policy
   MAY also be used to determine whether to include the History-Info
   header at all, whether to capture a specific Request-URI in the
   header, or whether it be included only in the Request as it is
   retargeted within a specific domain (PRIV-req-3).  In the latter
   case, this is accomplished by adding a new priv-value, history, to
   the Privacy header [RFC3323] indicating whether any or a specific
   History-Info header(s) SHOULD be forwarded.

And from Section 4.1 

   o  Privacy: An optional parameter for History-Info, reflected in the
      History-Info header field values by including the Privacy Header
      [RFC3323] with a priv-value of "history" escaped in the hi-
      targeted-to-uri or by adding the Privacy header with a priv-value
      of "history" to the Request.  The use of the Privacy Header with a
      priv-value of "history" indicates whether a specific or all
      History-Info headers should not be forwarded.

(There appears to be an inconsistency here as sections 3.3 and 4.1
appear to contradict. [Perhaps it just needs clarification that section
3.3 allows forwarding within the domain and 4.1 prohibits forwarding
outside the domain?])

Assuming that the value 'history' means that presentation and forwarding
should not occur.

In this case the inclusion of the value 'history' in the Privacy header
impacts all H-I entries. If one node includes the value 'history' in the
Privacy header then there is no way for another node to specifically
allow the uri included in the hi-targeted-to-uri to not be restricted.
To allow forwarding of a specific H-I entry there needs to be another
value which can be included in the Privacy header parameter of for the
hi-targeted-to-uri.

If the value "none" has specific meanings which will cause confusion
then another value should be used.  

More comments in-line

Nit in A.3

In both the sequence and the text you indicate that the INVITE to UA-B
will retransmit. This should not occur if a 100 Trying has been received
from UA-B. This means that the retransmit timer cannot be used to
determine if UA-B does not respond. There will be a separate timer
specified for determining no answer after the 180 has been received.

Ian Elz

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 12 March 2009 13:55
To: Ian Elz
Cc: [email-masked]; Francois Audet
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

Okay, so I think I might understand now - you want to use the "none" to
override the Privacy header that would be (in current 4244/4244bis)
applied to the whole message as it traverses across the n/w from the UAC
to the UAS. Is that correct? 
 
[ige] Yes - currently a Privacy header with value 'history' will prevent
any H-I entries from being passed. If the Privacy header does not
contain the value 'history' then individual H-I entries may have privacy
associated. Those which do will not be forwarded but those with no
privacy will be forwarded.

That then though changes the meaning of the
 
[ige] I would not be as strong as MUST NOT. There may be local policy
which will override what is included. I would prefer the words NEED NOT
be removed {Scott B will hate me for that.} or perhaps MAY be forwarded
based upon local policy. 

Thanks,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 8:43 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]; Audet, Francois (SC100:3055)
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Mary,

Ian Elz

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 11 March 2009 16:53
To: Ian Elz; Francois Audet
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, March 11, 2009 4:54 AM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
Cc: [email-masked]
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Mary, Francois,

Ian Elz

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 10:53:00 -0500

Ian,
 
I do see your point now - the text does need clarification.  Detailed
comments are below [MB].
 
Thanks,
Mary. 

________________________________

Sent: Thursday, March 12, 2009 10:12 AM

Mary,

                                                  Thus, local policy

[MB] Yes, this is a little fuzzy. It is trying to make a very general
statement that we are adding this new "priv-value" to the  Privacy
header so that we can control whether the entries are sent outside the
proxy.  I think that sentence is okay if we remove the normative
(SHOULD) and just add a note that the details of the use of the privacy
header are provided in section 4.1., something like the following: 
   In the latter

   the Privacy header [RFC3323] indicating whether or not any or a
specific

   History-Info header(s) are forwarded outside a specific domain for
which the proxy is responsible. 
 
   The details as to the use of the new priv-value with the Privacy
header are provided in section 4.1.

 [/MB]

[MB] Yes, this is also fuzzy. It should really read (and the SHOULD NOT
ought to be caps):

 Privacy: An optional parameter for History-Info, reflected in the

      of "history" to the Request.   The latter case indicates that  

      none of the History-Info headers should be forwarded , whereas the
use of

      the Privacy header escaped in the hi-targeted-to-uri means that a
specific hi-entry SHOULD NOT be forwarded. 
[/MB]

[MB] Exactly - that's why I had suggested earlier that we perhaps
RECOMMEND that the Privacy header only be used in the escaped form
associated with a specific hi-entry. There is text elsewhere explaining
that you do have potential loss of functionality when you use the
Privacy header. Perhaps, we need a stronger warning. [/MB]

More comments in-line

Nit in A.3

[MB] You are correct - that flow is buggy and there are bugs in the
flows and we will rework these and/or remove some of them.[/MB]

Ian Elz

[email-masked]

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 12 March 2009 13:55
To: Ian Elz
Cc: [email-masked]; Francois Audet
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

doing so.

Thanks,

Mary. 

-----Original Message-----

Mary,

Referred-By header. 

Ian Elz

[email-masked]

-----Original Message-----

Cc: [email-masked]

Ian,

adds the new hi-entry.  

Regards,

Mary. 

-----Original Message-----

Cc: [email-masked]

Mary, Francois,

hi-targeted-to-uri.

uri.

presented.

Ian Elz

-----Original Message-----

[email-masked]

directories.

        Pages           : 49

        Date            : 2009-03-04

Internet-Draft.

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 12 Mar 2009 17:52:45 +0100

Mary,

Thanks.

RFC4244 was always considered a little fuzzy in some areas but the
intent was generally understood.

We may be able to use this opportunity to clarify some additional parts.

I will read through the full draft with this purpose to see what may
need clarification.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 12 March 2009 15:53
To: Ian Elz
Cc: [email-masked]; Francois Audet
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

Thanks,
Mary. 

Mary,

                                                  Thus, local policy

 

 [/MB]

More comments in-line

Nit in A.3

Ian Elz

[email-masked]

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 12 March 2009 13:55
To: Ian Elz
Cc: [email-masked]; Francois Audet
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 

Ian,

doing so.

Thanks,

Mary. 

-----Original Message-----

Mary,

Referred-By header. 

Ian Elz

[email-masked]

-----Original Message-----

Cc: [email-masked]

Ian,

adds the new hi-entry.  

Regards,

Mary. 

-----Original Message-----

Cc: [email-masked]

Mary, Francois,

hi-targeted-to-uri.

uri.

presented.

Ian Elz

-----Original Message-----

[email-masked]

directories.

        Pages           : 49

        Date            : 2009-03-04

Internet-Draft.

---

From: <[email-masked]>
Date: Mon, 16 Mar 2009 23:11:14 +0100

Hi Mary and François,

I have a suggestion and few comments on the document.

** To make the History-Info header usefull for applications and services interactions, it could be interesting to be able to include in the hi-target-to-uri IARI and ICSC values as described in TS 24.229 (3GPP) wich ar coded as URN. An example of an ICSI for a 3GPP defined IMS communication service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
Do you think, this kind of enhancement for Histroy-Info header could be added in the document ?

** Section 4.1: About Retarget (hi-target), it is indicated "A retarget parameter is not added for a hi-entry when it is first added in a History-
Info header, but rather is added when the retargeting actually occurs". It is indicated when the Retarget indication should be added but it could be 	good to add an information on where the parameter should be added (associated to the retargeting hi-targeted-to-uri). This is just to be clear on 	the History-Info header structure. 
I have the same comment for the Reason header escaped in the History-Info. About that, there is an inconsistency between Reason header associated to 	the retargeting URI and cause-param parameter (RFC4458) associated to the retargeted-to URI. This should be corrected in RFC4458 but I don't know if 	it is possible.

** Section 4.5.1 and following: in the call flows there is a "retarget" parmeter inserted in the second INVITE by Proxy1 when sending the request to Proxy2. In my understanding, it should only be added (in the same place) by Proxy2 when retargeting the request to Bob. Did I miss something ?

** Privacy: I also think that it should be recommended in the document to use the Privacy header with the value "history" escaped in the hi-entries rather than directly in the INVITE request.  

Best Regards,
Marianne

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 17 Mar 2009 00:54:55 +0100

You wrote:

> ** To make the History-Info header usefull for applications 
> and services interactions, it could be interesting to be able 
> to include in the hi-target-to-uri IARI and ICSC values as 
> described in TS 24.229 (3GPP) wich ar coded as URN. An 
> example of an ICSI for a 3GPP defined IMS communication 
> service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel

Question: What have these values to do with the history of a retargetting?

Keith 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, March 16, 2009 10:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> ** To make the History-Info header usefull for applications 
> and services interactions, it could be interesting to be able 
> to include in the hi-target-to-uri IARI and ICSC values as 
> described in TS 24.229 (3GPP) wich ar coded as URN. An 
> example of an ICSI for a 3GPP defined IMS communication 
> service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
> ** Section 4.1: About Retarget (hi-target), it is indicated 
> "A retarget parameter is not added for a hi-entry when it is 
> first added in a History-
> Info header, but rather is added when the retargeting 
> actually occurs". It is indicated when the Retarget 
> indication should be added but it could be 	good to add an 
> information on where the parameter should be added 
> (associated to the retargeting hi-targeted-to-uri). This is 
> just to be clear on 	the History-Info header structure. 
> I have the same comment for the Reason header escaped in the 
> History-Info. About that, there is an inconsistency between 
> Reason header associated to 	the retargeting URI and 
> cause-param parameter (RFC4458) associated to the 
> retargeted-to URI. This should be corrected in RFC4458 but I 
> don't know if 	it is possible.
> 
> ** Section 4.5.1 and following: in the call flows there is a 
> "retarget" parmeter inserted in the second INVITE by Proxy1 
> when sending the request to Proxy2. In my understanding, it 
> should only be added (in the same place) by Proxy2 when 
> retargeting the request to Bob. Did I miss something ?
> 
> ** Privacy: I also think that it should be recommended in the 
> document to use the Privacy header with the value "history" 
> escaped in the hi-entries rather than directly in the INVITE 
> request.  
> 
> 
> Best Regards,
> Marianne

---

From: <[email-masked]>
Date: Thu, 19 Mar 2009 10:53:31 +0100

Hi Keith,

Let's just talk about IARI. My idea was just to suggest a trail to improve History-Info. Before to create new things (headers or parameters), we should look what is available and reusable. If it is not conceivable to use IARI values in a History-Info header allowing a proxy server to indicate what has been done in term of service, could you please give a reason. 

Best Regards,
Marianne 

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:[email-masked]] 
Envoyé : mardi 17 mars 2009 00:55
À : MOHALI Marianne RD-CORE-ISS; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

You wrote:

> ** To make the History-Info header usefull for applications and 
> services interactions, it could be interesting to be able to include 
> in the hi-target-to-uri IARI and ICSC values as described in TS 24.229 
> (3GPP) wich ar coded as URN. An example of an ICSI for a 3GPP defined 
> IMS communication service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel

Keith 

> [email-masked]
> ** To make the History-Info header usefull for applications and 
> services interactions, it could be interesting to be able to include 
> in the hi-target-to-uri IARI and ICSC values as described in TS 24.229 
> (3GPP) wich ar coded as URN. An example of an ICSI for a 3GPP defined 
> IMS communication service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
> ** Section 4.1: About Retarget (hi-target), it is indicated "A 
> retarget parameter is not added for a hi-entry when it is first added 
> in a History- Info header, but rather is added when the retargeting 
> information on where the parameter should be added (associated to the 
> retargeting hi-targeted-to-uri). This is
> cause-param parameter (RFC4458) associated to the retargeted-to URI. 
> This should be corrected in RFC4458 but I
> "retarget" parmeter inserted in the second INVITE by Proxy1 when 
> sending the request to Proxy2. In my understanding, it should only be 
> added (in the same place) by Proxy2 when retargeting the request to 
> Bob. Did I miss something ?
> 
> ** Privacy: I also think that it should be recommended in the document 
> to use the Privacy header with the value "history"
> escaped in the hi-entries rather than directly in the INVITE request.
> 
> 
> Best Regards,
> Marianne

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 19 Mar 2009 11:51:11 +0100

Hi Mary,

Other discussion on the list triggered the following question when looking
at how Request-URI's are recorded in 4244.

Assume: A UAS that receiving the History-Info in a request. The UAS needs
the original parameters that where present on a particular recorded
Request-URI.

Q1: Does the current 4244 text ensure that the Request-URI parameters are
recorded?
Q2: Assuming they are recorded, how to distinguish parameters that where
originally present and those that where added in the History-Info recording
process?
Q3: What was the design objective for not having reason headers etc be
recorded as hi-param? I.e. why is the recorded URI modified?

Best Regards,
/Hans Erik van Elburg

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 19 Mar 2009 23:47:40 +0100

IARI is end to end (either user terminal or application) and is not changed by intermediate call functionality. 

Therefore any intermediate application that changes this is essentially making a new call that is not the original call. Think of something like a conference bridge.

If you start recording IARI in History-Info, then that would suggest you record all the other headers and bodies that are end to end information.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, March 19, 2009 9:54 AM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Let's just talk about IARI. My idea was just to suggest a 
> trail to improve History-Info. Before to create new things 
> (headers or parameters), we should look what is available and 
> reusable. If it is not conceivable to use IARI values in a 
> History-Info header allowing a proxy server to indicate what 
> has been done in term of service, could you please give a reason. 
> 
> Best Regards,
> Marianne 
> 
> Envoyé : mardi 17 mars 2009 00:55 À : MOHALI Marianne 
> RD-CORE-ISS; [email-masked]; [email-masked] Cc : 
> [email-masked] Objet : RE: [Sip] I-D 
> Action:draft-barnes-sip-rfc4244bis-00.txt
> 
> You wrote:
> 
> > Do you think, this kind of enhancement for Histroy-Info 
> header could 
> > be added in the document ?
> 
> > Do you think, this kind of enhancement for Histroy-Info 
> header could 
> > be added in the document ?
> > 
> retargeted-to URI.

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 20 Mar 2009 00:33:30 -0500

Resending to include SIP WG mailing list.

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Fri 3/20/2009 12:32 AM
To: Hans Erik van Elburg
Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
 
Hi Hans Erick,

Responses below [MB].

Thanks,
Mary.

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: Thu 3/19/2009 5:51 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
 
Hi Mary,

Q1: Does the current 4244 text ensure that the Request-URI parameters are
recorded?
[MB] The current text doesn't specifically discuss Request-URI parameters, but per the general rule that information is not removed from messages, the parameters should be left intact. I can add something to that affect to the next version to clarify that point. [/MB]
Q2: Assuming they are recorded, how to distinguish parameters that where
originally present and those that where added in the History-Info recording
process?
[MB] History-Info doesn't add any new Request-URI parameters.  The Reason header is escaped in the Request-URI, but it's not something that would be part of any SIP Request and would only appear in a Request-URI that has been captured in the History-Info header. We could also add a statement clarifying that to RFC 4244. 
Q3: What was the design objective for not having reason headers etc be
recorded as hi-param? I.e. why is the recorded URI modified?
[MB] That was just a matter of reusing an existing header versus defining a parameter that had the exact same information. This was an issue discussed at IETF-55 in Nov 22 (Issue 2, chart 5):
http://www.ietf.org/proceedings/02nov/slides/sipping-2/index.html
You can see in those charts (and older versions of the drafts that you may or may not be able to dig up) that the Reason was originally an hi-param. The escaping also saves a few bytes per hi-entry.   The recorded URI is modified because the intent was to capture "why" that URI was retargeted. You can also look at those charts above (specifically chart 4 that has the ABNF) and see that we were originally capturing two entries at each node - old and new. But, again, to make the header more compact we simplified to just record the new and thus have the "old" already captured by the time the request is received by the next node. The Reason header is only added (to the "old" hi-entry) in the case that the retargeted URI is in the domain for which the entity doing the retargeting is responsible. [/MB]

Best Regards,
/Hans Erik van Elburg