Subject: [Sip] (no subject)

From: Rohan Mahy <[email-masked]>
Date: Thu, 28 Feb 2002 10:33:53 -0800 (Pacific Standard Time)

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

_______________________________________________
Sip mailing list  https://www1.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