Re: I-D Action:draft-barnes-sip-rfc4244bis-00.txt

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:
> 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 protected]] 
> Sent: Wednesday, March 11, 2009 4:54 AM
> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
> Cc: [email protected]
> Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt 
>
> 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 protected]
> [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: 04 March 2009 15:15
> To: [email protected]
> 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.
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
>   
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip