Subject: RE: [Sip] Asserted-Identity: How to 'hint'?

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Jun 2002 02:58:46 -0500

I have not been persuaded by the argument that the 'hint' has applicability
outside of the short-term asserted identity mechanism. Agreed that the hint
only seems to be necessary because a user could potentially select an
anonymous From field, but with whom would a user share such a suggested
identity when they are anonymous, and why would they share it? 

Even when the From field is anonymous, the hint is only necessary when the
normal authentication process in SIP (which provides a secure way for a user
to share their identity with a specific intermediary) does not allow the
user to express a usable identity to the network. I think the normal SIP
authentication method constitutes a standard way of expressing an identity
to the network when the From field is anonymous - if a user has multiple
identities, they can express any one of several identities in the username
portion of an Authorization header. 

Thus, I don't see this as any particular reason why the 'hint', with it's
more modest applicability, cannot be represented by a P- header.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 2:45 PM
> To: Peterson, Jon
> Cc: 'David R. Oran'; Jonathan Rosenberg; 'Mark Watson'; 
> 'Andrew Allen';
> 'Rohan Mahy'; [email-masked]
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> Peterson, Jon writes:
> 
>  > - What do we call the new header? (I think it should be a 
> P- header; I don't
>  > think we should change the name of the existing 
> P-Asserted-Identity header
>  > if we can help it - maybe P-Suggested-Identity for the hint?)
> 
> since the hint is needed for the general case where from is anonymous
> and since there is no other standardized sip mechanism for 
> that purpose,
> i'm strongly against defining a p-header for it.  it must be a normal,
> standards track header with possibly a new error code to tell the UA
> that the proxy didn't like the identity the ua was claiming.
> 
> -- 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

---

From: [email-masked]
Date: Tue, 4 Jun 2002 11:10:26 +0300

> identity when they are anonymous, and why would they share it? 

this has been discussed many times before:  when the call is routed to
pstn, the calling party number is still carried in the isup message even
if the caller wants to remain anonymous to the called party.

 > portion of an Authorization header. 

are you suggesting that if my customer has a phone number in each of the
15 area codes in finland, he/she should have 15 different sip
usernames/passwords?  if i would propose such a thing to my customer,
he/she would think i must be joking.

 > more modest applicability, cannot be represented by a P- header.

there is real demonstrated need to include "Really From" style header in
basic sip.  ietf must do its job properly and, in order to do so, must
not be constrained by 3gpp or any other external deadlines.  if that is
not acceptable to 3gpp, then i suggest that you go invent your own
3GPP-headers and be done with it.

-- juha

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 04 Jun 2002 12:52:47 +0300

"Peterson, Jon" wrote:
[snip] 
> portion of an Authorization header.

I don't agree with this usage of the username part of the Authorization header.
The username part indicates the username who is authenticating, as opposed to
the hint of the identity. You may also consider that the authorization data is
typically locally stored data, as opposed to the asserted identity, that can
cross domains is transitive trust exists between networks. Therefore, the
username part of the Authorization header does not offer, in the general case,
a hint for the asserted identity.

Jonathan already commented about the problems of overloading the semantics
of one header with other semantics, and I consider the same hack to the
username part of the Authorization header.

Let's move forward and go for a new header for the hint.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002