Subject: AW: [Sip] History-Info Privacy Issue

From: "Jesske, R" <[email-masked]>
Date: Thu, 22 Apr 2004 15:19:52 +0200

I favour 1, because I think this should be kept together.
 
Best Regards
 
Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]Im Auftrag von Cullen Jennings
Gesendet: Donnerstag, 22. April 2004 00:04
An: Mary Barnes; [email-masked]
Betreff: Re: [Sip] History-Info Privacy Issue

I don't care a huge amount but I think I slightly favor 2. 

On 4/16/04 9:05 AM, "Mary Barnes" <[email-masked]> wrote:

Per my posting on the status of History-Info, Privacy is one of the remaining open issues.  The proposal currently in the draft is quite simple: 

If the Privacy header has a priv-value of "Session" or "Header" privacy, the History-Info  SHOULD not be included in the Request (or subsequent responses).  

This is effectively applying the fundamental recommendation in RFC3323 that any optional information that can divulge information about the user(s) should not be included in the requests.  

A proposal was made that there are scenarios (e.g. where local policy limits the applicability of History-Info within a specific domain) where you would want to capture the History-Info but not send it beyond certain intermediaries or domains.  To support this, it was proposed that we could extend the Privacy header defined in RFC 3323 with tags for History-Info something like the following:

priv-value = "history" / "history-index"  

The "history" priv-value would mean that all the History-Info entries should be removed.  The "history-index" would be used to indicate that the specific entry is to be removed and would need to have the Privacy header escaped in the URI so that it can be associated with a specific History-Info entry (or we need to add another field to History-Info for this).    

So, I think we have two options here: 
1) Extend History-Info to have an optional privacy field along the lines of what's detailed above.  

2) Defer the definition of the privacy field to a separate draft, since it appears to be primarily limited to scenarios with certain trust models.  

So, if folks could just take a bit of time and consider their preference, I would like to get the draft updated soon and closed off prior to the Interim meeting.

Regards, 
Mary H. Barnes 
[email-masked]