Subject: [Sip] RE:

From: "Mark Watson"<[email-masked]>
Date: Thu, 28 Feb 2002 18:55:42 -0000

Rohan,

I guess I worded my statement a little strongly, I meant that *within the
applicable environment* it would provide a general-purpose capability.

I am hopeful that future work will extend the 'applicable environment', but
I wasn't suggesting that this draft be delayed for that work to be
completed.

If that work were never completed, then RPID would remain applicable only
within the environment stated. Or if future work decides that different
header(s) be used in other environments.

But re-use is good, so we should not rule it out until we find out whether
it is appropriate.

To answer your question about why extensibility of RPID is better than new
headers: imagine I am an Internet Telephony Service Provider and I have
parnerships with a number of other Service Providers who will route SIP
calls to the PSTN for me.

Part of my agreements with these Service Providers is that they will support
the privacy draft. So I can send them information which my subscribers want
kept private (see previous discussions for why I might want to do this).

If someone comes up with a great idea for a new identity type, we can either
define a new rpi-id-type or a new header:
a) New rpi-id-type: I can just send this new identity to all my partner
Service Providers - I know that even if they do not support the new
rpi-id-type value, they will respect the rpi-privacy values.
b) New header: I cannot send this to my partners until I have agreed with
each of them that they will respect the privacy information within the
header. I will need a capability to selectively remove this header based on
who I am sending it to & I need to maintain data about who supports it and
who does not etc. - this becomes a massive pain and introduces even more
scope for error.

The point is that the privacy problem, in this environment, whatever you
think of it, is independent of the identity type. So there should be a
single solution into which we can plug future identity types, rather then
re-inventing it again and again.

...Mark

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: 28 February 2002 18:34
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: 
> 
> 
> Mark,
> 
> We've already discussed to some extent the applicability statement
> proposed for privacy-04.  This draft obviously doesn't address pure
> user-to-user privacy (it never intended to, and there is nothing wrong
> with that).  However, I'm sure the IESG will have a problem 
> approving a
> document that defines the "general purpose platform" for privacy
> that you propose, but that only addresses the requirements in a
> specific environment.  How do you intend to make a general purpose
> platform acceptable for publication by the IESG?
> 
> Are you proposing that we delay last call to incorporate a 
> full privacy
> scheme?
> 
> Please see a few additional comments inline with ##.
> 
> Please feel free to call me if you want to talk about this.
> +1 408 307 1866
> 
> thanks,
> -rohan
> 
> 
> To: "'Flemming Andreasen'" <[email-masked]>, "[email-masked]'"
> <[email-masked]>
> Subject: [Sip] RE: Remote-Party-Id extensibility
> From: "Mark Watson"<[email-masked]>
> Date: Thu, 28 Feb 2002 13:11:20 -0000
> List-Id: Session Initiation Protocol <sip.ietf.org>
> Sender: [email-masked]
> 
> --------------------------------------------------------------
> ------------------
> 
> Title: RE: Remote-Party-Id extensibility
> Flemming, all,
> 
> My opinion is that 95% of the value of the Remote-Party-ID 
> header is in
> this extensibility.
> 
> The extensibility provides a general purpose platform
> ##                           ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> for handling of
> identity information which is subject to privacy restrictions (in the
> applicable environment), because we can add new types of 
> identity and be
> sure that the privacy handling will be applied to these even 
> if the actual
> identity type is not recognised by downstream systems.
> 
> If you remove this extensibility, you might as well define separate
> headers for each identity ('Private-Calling-Party:' etc.), 
> with separate
> Require: tags, and then any SLAs between Service Providers 
> with respect to
> privacy would have to list the headers that were guaranteed to be
> respected. Such SLAs would need extension every time new 
> identities were
> added.
> 
> ## why is this a problem (additional headers) if it meets the
> ## requirements?
> 
> As it stands, we need only include support of the 'privacy' tag in the
> SLAs.
> 
> I can promise you that the lack of such extensibility in the 
> PSTN has be a
> nightmare. It was predicated on the assumption that we know a 
> priori that
> a given set of identity parameters are sufficient for present 
> and future
> purposes - an assumption which has proved wrong time and time again.
> 
> I would also hope that the envisioned future privacy support 
> for the pure
> Internet environment could be as backwards-compatible with 
> Remote-Party-ID
> as possible cf Dean's ideas about signing the RPID etc. If we rule out
> extensibility now, we tie our hands somewhat with regards to 
> this future
> solution.
> 
> ## syntax is always the least important aspect of a protocol. 
>  i don't see
> ## any compelling reason why future privacy work would have to use the
> ## same header name.  In fact this may hamper our ability to add new
> ## features.  Of course, a new RFC could always update or obsolete the
> ## current draft if we decided that the syntax of the more 
> general privacy
> ## document should use the Remote-Party-ID header
> 
> I would prefer to have the extensibiity left as in privacy-02.
> 
> Regards,
> 
> Mark
> 
> 
> 
>