Subject: Re: [dispatch] New Draft - draft-elz-dispatch-req-sip-3rdpartyprivacy-00

From: Ian Elz <[email-masked]>
Date: Wed, 9 Mar 2011 00:21:16 +0000 (GMT)

Paul,

I don't believe that a generalized mechanism is difficult. It just needs a little thought.

History-info has defined a mechanism for adding privacy to an individual uri. It just need extending so that any uri can use a similar mechanism.

The second issue regarding the precedence is the one which people may have opinions about.

Ian

----- Original Message -----
From: "Paul Kyzivat" <[email-masked]>
To: [email-masked]
Sent: Tuesday, 8 March, 2011 2:12:39 PM
Subject: Re: [dispatch] New Draft -	draft-elz-dispatch-req-sip-3rdpartyprivacy-00

Ian,

I'd like to thank you for submitting a clear requirements draft that is 
unburdened by mechanism proposals.

IMO the hard part of this issue is sorting out whether there is a need 
for a "generalized" mechanism dealing with arbitrary 3rd party 
identities, or just for a mechanism to deal with a specific enumerated 
set of 3rd party identities.

While its easy to wish for a generalized mechanism, I think it will be 
very difficult to adequately specify. If constrained to a specific set 
than it is a solvable problem.

	Thanks,
	Paul

On 3/8/2011 3:15 AM, Ian Elz wrote:
> All,
>
> I have submitted a new draft relating to third party privacy in SIP
> messages.
>
> http://www.ietf.org/id/draft-elz-dispatch-req-sip-3rdpartyprivacy-00.txt
> (Link that I forgot in the previous posting.)
>
> There are two specific issues included, how to specify third party
> privacy in a SIP message; the precedence of privacy settings between
> Privacy header values and Privacy URI parameters.
>
> The things to consider are:
>
> Should this work be pursued and if so in which forum.
>
> A suitable solution to meet the requirements.
>
> How any changes should be implemented: a new draft which modifies
> RFC3323 or an update to RFC3323 which includes the additional work.
>
> All comments welcome.
>
> Sorry I forgot to write the Abstract in version -00. I will include this
> in the next version. ( I leave abstracts to last and overlooked this
> before submission.)
>
> Ian Elz
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Mar 2011 19:59:39 -0500

> History-info has defined a mechanism for adding privacy to an individual uri. It just need extending so that any uri can use a similar mechanism.

The problem with generalizing is that boxes implementing privacy need to 
be updated every time there is a new place header, etc. defined that can 
contain something requiring privacy. At the moment that happens the 
world is filled with boxes that don't support privacy for that thing. 
How do you determine if you have the privacy you need?

	Thanks,
	Paul

> From: "Paul Kyzivat"<[email-masked]>
> To: [email-masked]

---

From: Ian Elz <[email-masked]>
Date: Wed, 9 Mar 2011 08:19:48 +0000 (GMT)

Paul,

I would have thought that using the present system that any new header added 
that requires privacy would require that the box providing the privacy service 
would need to be updated. E.g. If a new header "Xxxx" is defined which requires 
privacy and can be classified as "user" privacy in the existing mechanism then 
the privacy box would need to be updated to ensure that Header "Xxxx" was 
removed when "user" privacy was indicated but not if "header" privacy is 
indicated.

If we can defined a generic mechanism that allows the privacy box to identify 
whether privacy is required irrespective of the header then there may be less 
changes required at the privacy box. E.g. If it was possible to mark a header 
containing a uri with a privacy header indicating that privacy is required then 
the privacy box would know to remove the header even if it did not understand 
the specific header. This could be as follows: 

Xxxx: <[email-masked];'private'    (not suggesting that this is the mechanism 
for marking privacy)

The privacy box could identify the privacy setting and either remove the header 
if it is optional or anonymise the header if it is required in SIP.

At present I am more interested in whether there is agreement with pursuing the 
work than in agreeing a solution.

Thanks

Ian

________________________________
From: Paul Kyzivat <[email-masked]>
To: Ian Elz <[email-masked]>
Cc: [email-masked]
Sent: Wed, 9 March, 2011 0:59:39
Subject: Re: [dispatch] New Draft - 
draft-elz-dispatch-req-sip-3rdpartyprivacy-00

On 3/8/2011 7:21 PM, Ian Elz wrote:
> History-info has defined a mechanism for adding privacy to an individual uri. 
>It just need extending so that any uri can use a similar mechanism.

    Thanks,
    Paul

> Subject: Re: [dispatch] New Draft -    
>draft-elz-dispatch-req-sip-3rdpartyprivacy-00
>
> Ian,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Mar 2011 09:02:47 -0500

> Paul,
...
> At present I am more interested in whether there is agreement with
> pursuing the work than in agreeing a solution.

I think that is the right focus. So lets keep it at that for now, and 
worry about the details later.

	Thanks,
	Paul