Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 29 May 2002 05:44:34 -0500

I don't think anything that is expressed in this draft is incompatible with
what you're attempting to accomplish with the normative statements below -
except in so far as you levy restrictions that are not meaningful for all
networks.

"Hint", for whatever reason, is the term that has stuck throughout this
discussion. There are meaningful cases in which a network would elect to use
some identity other than that hinted by the user, so I don't feel this term
is entirely inappropriate.

There is a concept, though one that is not discussed extensively in the
draft, that a user authenticates themselves in some fashion to the network.
The Spec(T) example in the draft suggests SIP Digest authentication, if I
recall. The P-Asserted-Identity could be populated based on an identity
expressed in that authentication process, rather than a From header, in the
absence of a hint (although admittedly in some networks the authentication
will not supply a usable identity as such). This applies equally to cases in
which the user has supplied an anonymous From header. This would seem to
provide a credible alternative to the MUST that you suggest below, one that
I see no reason to rule out.

The short-term identity work puts the network, not the user, firmly in the
driver's seat. There are other forms of identity (like the contents of the
>From header field) that are more directly under the user's control. You are
welcome to apply whatever policies you like for proxy servers in your own
network, including the ones you enumerate below. I don't think this requires
any support in the protocol, though. We mention, but do not mandate, that a
proxy server can reject requests that have an inappropriate hint. I'm not
sure I see any value in strengthening this.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 12:23 AM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: [Sip] draft-ietf-sip-asserted-identity-00
> 
> 
> once again:
> 
> the term "hint" is not a good one.  if user adds the a-i, then the
> network MUST respect it or reject the request.  the network MUST not
> override the a-i and pick one of the identities on its own.  for
> example, the user may have misspelled the its uri in the a-i.
> 
> also, the text should say that in case from is anonymous the user MUST
> insert the a-i header if it has multiple identities, because otherwise
> the network cannot know which identity the user wants to use.
> 
> finally, for backwards compatibility, if from is not anonymous and the
> user has multiple identities, then from uri can serve as the 
> purpose of
> a-i.
> 
> -- juha
> 
> _______________________________________________
> 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
> 

_______________________________________________
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

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 30 May 2002 00:46:04 +0300

> is entirely inappropriate.

looks like my values differ from yours.  i as a service provider have to
respects the user's wish.  if there is many, i simply can't pick an
identity for a user on my own.  also, if the users wish conflicts with
his subscription, i must clear the call.

 > I see no reason to rule out.

that doesn't work if the user has multiple sip identities.

 > driver's seat. 

sounds a very bellhead approach to me.  if the user claims to be someone
that conflicts with the idea of the network regarding who the user
should be, then the network should not make things up, but deny the
request.

-- juha

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 30 May 2002 07:02:08 -0700

Would you feel better about this hint stuff if we put in that Spec(T) must
specify how the situation is handled when a node receiving a hint which is
not going to be honored. So Spec(T) would need to say that if you got a hint
and you were actually going to use a different AI in the trust domain, then
you must do one of a) just do it and not tell the user b) return an error to
the user c) unspecified.

I see difficulties in really deploying and this - at the UAC, it might be
hard to know AI the trust domain will use for UA - presumably I would need
to get it exactly right on the UA - if it is using both a sip and tel url do
I have to include both of them?

I feel there is a header where the UA gets to assert who it wants to be
known as - it's the From header. There is another header where the network
gets to assert information about who it thinks the user is - this is the
Asserted-Identity header. There is a header where the user gets to control
the scope of how widely this network information is distributed - that is
the Privacy header.

Cullen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Juha
Heinanen
Sent: Wednesday, May 29, 2002 2:46 PM
To: Peterson, Jon
Cc: Cullen Jennings; [email-masked]
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00

-- juha

---

From: [email-masked]
Date: Fri, 31 May 2002 09:55:29 +0300

Cullen Jennings writes:

 > known as - it's the From header. 

yes, but if the user uses anonymous from header, the it MUST use nai
header for that purpose.

i don't know about Tspec(T).  nao should be part of basic sip and it
doesn't sound like a good idea to start to parameterize the basic
semantics of the protocol.  so my suggestion is that if the user
inserted nai doesn't match with networks opinion, the network MUST
reject the request with an error code.  the user then will know to
change the contents of the nai header, which is a very reasonable thing
to do.

-- juha