Subject: RE: [SIP] SIP Privacy Draft

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Feb 2001 11:25:22 -0000

In addition to the current discussion on location, I wanted to add some
words on the following part of Marks comment.

I do believe within any individual session, and for any endpoint, there are
multiple identities that need to be exchanged. 

We either have the option of specifying these in the RFC, or allowing to be
added as IANA registered enhancements, or a combination of both. Before we
decide this, we possibly need to get some idea of the number of different
identities people may want. I think this involves adding definitions to the
terms that Mark has identified.

We should also note that we already have a number of identities already
existing in the draft, depending on the endpoint we are talking about. For
the calling endpoint we have the From header and the Contact header. These
may fulfil some of the functions of i) and ii) in Mark's list.

I would like to propose two definitions which I believe should be covered by
an extended privacy draft (note that these are currently phrased from the
viewpoint of the calling endpoint, and would need to be modified to cover
other endpoints:

	Logical Calling Subscriber ID
	A URL that identifies the owner of the telecommunications
subscription of the user originating the session.

	Logical Calling User ID
	A URL that identifies the calling user, and that shall at least be
suitable for making a return session establishment.

It is the second of these that I would expect to be used in a Calling Line
Identification Presentation Service. The first would need to accompany any
emergency call, or be used for any malicious call identification.

Keith Drage

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Mark Watson[SMTP:[email-masked]]
> Sent: 	01 February 2001 15:49
> To: 	[email-masked]'
> Subject: 	[SIP] SIP Privacy Draft
> 
> All, 
> 
> I sent some comments on this draft to the list in December. Below is an
> update to these comments based on some off-line discussions. (The draft
> itself is at
> http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt)
> 
> Five enhancements to the draft are proposed: 
> 
<cut>
> 3) Types of identity 
> 
> A party involved in a session may have several kinds of identity. Support
> should be provided for signalling any/all of them:
> 
> i) Subscriber identity - who owns the network subscription under which the
> session is being established 
> ii) User identity - a human being 
> iii) Display/Alias identity - the identity that the party wishes to be
> known as 
> iv) Return identity - the identity to be used to contact the party (e.g.
> to establish a return call/session) 
> v) Terminal identity 
> 
> In many practical scenarios one or all of these identities are in fact the
> same and the same as the User identity, and so all do not need to be
> signalled separately. In any given application scenario it should be
> specified what these identities refer to.
> 
,cut>

> Regards, 
> 
> Mark Watson 
> Nortel Networks 
> [email-masked] 
> 
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Feb 2001 17:16:27 -0500

> may fulfil some of the functions of i) and ii) in Mark's list.

Your point is well taken, but I don't think the specific examples apply.

Note that there is an inherent conflict between anonymity and providing identity
information in the From header, which was part of the motivation for the
Remote-Party-ID originally.

As far as the Contact header is concerned, I also don't think it covers (or
should cover) subscriber/user identity. We had discussed if it perhaps covered
the terminal identity, and while you conceivably could construct an argument for
that, it would inherently place restrictions on the format and information you
can provide in a Contact header. I think that would be an unfortunate
overloading of semantics, especially if we have a general Remote-Party-ID
mechanism that could be used instead, so I would argue against that.

> suitable for making a return session establishment.

I'll let Mark speak to these as they are his definitions, but I believe your
Logical Calling User ID combines a couple of Mark's identities in one, and I
don't that was his intention.

-- Flemming

--
Flemming Andreasen
Cisco Systems