The example with vovida.org may be a typo :-)

The idea is pretty simple. Let's say that I can take on the identity
[EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED] The system
may be able to verify that I can be any one of those but it does not know
wish one I want to use for this particular call. The hint can indicate which
one I want to use. 

If I give a hint that I want to be [EMAIL PROTECTED], the system will no allow
this because it is not valid for me.

Sorry for the sloppy details in this response but hope it helps,

Cullen


On 5/15/04 3:53 AM, "Goud, Venkat Ramana (Venkat) ** CTR **"
<[EMAIL PROTECTED]> wrote:

> Hi Subhash,
> The criteria itself is open to implementations but I assume based on the
> authentication information proxy need to somehow identify a list of
> identities that could be validly associated with that user. For ex, this
> could either be a database of its own or a database provided by other
> component on which it relies. Otherwise malicious UACs might indicated
> false identities in PPI.
> In the example if PPI is something like P-Preferred-Identity: "John Doe"
> <[EMAIL PROTECTED]>, proxy need to verify that this is not a valid
> identity for user fluffy and either it rejects this requests or inserts
> [EMAIL PROTECTED] or [EMAIL PROTECTED] The reason the example includes
> [EMAIL PROTECTED] might be that the domain being forwarded to is
> vovida.org and there might be an implicit trust relationship between
> those two.
> 
> There are some valid reasons where proxy might need to ignore PPI and
> insert a totally different PAI which has no semblance to PPI at all.
> When forwarding requests across domains, proxy might need to insert a
> PAI which a user is not aware of or might need to provide a different
> PAI to the forwarding domain to provide certain features.
> 
> 
> -Venkat 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 14, 2004 10:21 AM
> To: Goud, Venkat Ramana (Venkat) ** CTR **
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] Interpretation of 'hint' in
> thePreferred-Identity
> 
> 
> 
> 
> 
> 
> Hi Venkat,
>     My question is how does the proxy recognize if
> the PPI is a valid identity for the user ? From the
> example, it seems like
> P-Preferred-Identity: "Cullen Jennings" <sip:[EMAIL PROTECTED]> results
> in the proxy inserting:
> P-Asserted-Identity: "Cullen Jennings" <sip:[EMAIL PROTECTED]>
> 
> In this case, how did the proxy decide that the PPI was a valid or
> invalid identity ? Ideally it should have inserted [EMAIL PROTECTED]
> but it seems to have inserted [EMAIL PROTECTED] Is it correct to assume
> that it did a _full_URL_comparision_; did not find a match; and hence
> inserted the closest identity it could find to the one suggested in the
> PPI ? Again, in deciding "closest identity" what was the criteria - the
> PPI header does not allow the client to suggest which part of the header
> is to be used as the hint (display-name or userinfo part or
> whatever)...is that left open to implementations ?
> 
> Thanks,
> Subhash.
> 
> 
> 
> 
> 
>            "Goud, Venkat
> 
>            Ramana (Venkat)
> 
>            ** CTR **"
> To 
>            <[EMAIL PROTECTED]>          <[EMAIL PROTECTED]>,
> 
> 
> <[EMAIL PROTECTED]>
>            05/13/04 06:28 PM
> cc 
>                                      <[EMAIL PROTECTED]>,
> 
>                                      <[EMAIL PROTECTED]>,
> 
>                                      <[EMAIL PROTECTED]>
> 
> 
> Subject 
>                                      RE: [Sip-implementors]
> 
>                                      Interpretation of 'hint' in
> 
>                                      thePreferred-Identity
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I think section 6 is pretty clear on this. PPI is only a
> suggestion/request so I guess its up to the proxy as to whether to use
> the hint or not.
> 
> If there is a P-Prefferred-Identity header:
> 
> 1) If the proxy recognizes it as a valid identity for that user and if
> there is no local policy for the proxy suggesting some other PAI, then
> it can use the one in the PPI header.
> 
> 2) If the proxy does not accept the PPI as valid identity for the user
> then it may either reject that request or use a PAI constructed based on
> its local policies.
> 
> -Venkat
> 
> 
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, May 13, 2004 8:33 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: [Sip-implementors] Interpretation of 'hint' in
> thePreferred-Identity
> 
> 
> 
> 
> 
> 
> Hi,
>     RFC 3325 states that a proxy may use the P-Preferred-Identity in
> an incoming request as a hint to choose among multiple identities that
> are configured for a user. The example section shows an example where
> the user suggets that he prefers to use the identity [EMAIL PROTECTED]
> But the proxy inserts [EMAIL PROTECTED] in the forwarded request.
>     The RFC does not clearly specify how the proxy should interpret
> the 'hint' that is provided. From the syntax of the P-Preferred-Identity
> and the P-Asserted-Identity it seems that one should do a URL comparison
> to choose the correct PAI header. But from the example, it seems like
> either the display-name or the userinfo part is being used to choose the
> correct PAI header.
>     Can someone provide some clarity or point to discussions which
> indicate how the 'hint' should be interpreted. Is it that no rules have
> been laid down so that it is left to individual implementations ? In
> that case, could implementors/authors suggest as to how one would
> normally interpret the hint i.e. by comparing which part of the
> P-Preferred-Identity header.
> 
> Thanks in advance,
> Subhash Nayak
> Hughes Software Systems
> http://www.hssworld.com
> 
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 
> 
> 
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to