Re: [dispatch] URI schemes in P-Asserted-Identity

3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" <fluffy@cisco.com>:

> 
> If you don't want to do the vcard but just want the xmpp address directly, I'd probably suggest something like 
> 
> Call-Info: <xmpp:aice@example.com> ;purpose=impp
> 
> To just indicate that the URL provided the IM and Presence service for that user
> 
> RFC 3261 section 20.9 says that the IANA section of 3261 will define how to add a new purpose but as far as I can tell it does not. However, the IANA SIP registry for the URI purpose at
> 
> http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-13
> 
> is just spec required so I think think you might be able to trivial add a "impp" purpose. 
Shouldn't the purposes in RFC 3261 be added to that registry too?

/O
> 
> As a side note, I'm very much in favor of the SIP messages being able to provide the XMPP address related to the user so glad to see this work getting done.
> 
> Cullen
> 
> PS -  Seriously,  PAI is not the header your are looking for. 
> 
> 
> 
> On Mar 3, 2013, at 6:31 AM, Emil Ivov <emcho@jitsi.org>
> wrote:
> 
>> Hey Cullen,
>> 
>> On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy)
>> <fluffy@cisco.com> wrote:
>>> 
>>> 
>>> I'd be fascinated to hear the need for this
>> 
>> As Peter already mentioned: we need to be able to match an incoming
>> INVITE to a JID so we are looking for the most convenient way to do
>> this without defining a new header. Partially because we'd like to
>> keep all this as an informational effort and in part because, as you
>> said it your self in Vancouver: there has to be an existing header
>> that we could use for this.
>> 
>>> - PAI is such a disaster zone that I'd want to make sure the envisioned
>>> usage did not run into the many land mines around PAI. It might be that
>>> some other header might meet the needs better than PAI.
>> 
>> Well right now we basically say that if you are operating in a trusted
>> domain, then you use PAI, if not you can still use
>> P-Preferred-Identity as an indication but then you still have to
>> validate that the JID from PPI has a vCard that matches the caller. In
>> other words, you still have to get the vCard but at least you can do
>> so for a single contact and not your entire roster.
>> 
>>> Cullen - co-authors of the ill fated RFC 3325
>>> 
>>> PS - you might want consider the "Call-Info" header -
>> 
>> OK, this does look like it could also do the job and we even have the
>> "card" info-param. Thanks for the tip!
>> 
>>> it would be very cool to the have HTTP URL in that pointed at the
>>> JSON vCard for the user.
>> 
>> Does it have to be HTTP? Would it make sense to use it with an xmpp:
>> URI? The grammar seems to allow for a generic URI and I don't think
>> there would be much ambiguity in a header that looks like this:
>> 
>> Call-Info: <xmpp:aice@example.com> ;purpose=card
>> 
>> It seems like this could only mean that Alice's vCard can be retrieved
>> through XMPP and it would probably be safe to infer that the XMPP URI
>> mentioned there is her own JID (and "safe to infer" is really what
>> this draft is all about). WDYT?
>> 
>> I am also wondering if we should repeat the URI with purpose=icon in
>> order to get the XMPP avatar or if having "card" one would suffice.
>> 
>> Finally, we'd still need to keep the requirement for a cross check:
>> whatever Call-Info says, one needs to download that vCard and make
>> sure that a number in there matches the source of the current call.
>> Otherwise this can be an attack.
>> 
>> Cheers,
>> Emil
>> 
>> 
>>> 
>>> On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>>> 
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> 
>>>> Dear DISPATCHers,
>>>> 
>>>> At the XMPP Summit last week, for various reasons that aren't
>>>> particularly relevant here, we talked a bit about how to include an
>>>> XMPP address in the header of a SIP message. Folks at the meeting
>>>> concluded that the P-Asserted-Identity header would work quite well
>>>> (certainly better than a second Contact header). Unfortunately, RFC
>>>> 3225 defines the P-Asserted-Identity as follows:
>>>> 
>>>> A P-Asserted-Identity header field value MUST consist of exactly one
>>>> name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>>>> values.  If there is one value, it MUST be a sip, sips, or tel URI.
>>>> If there are two values, one value MUST be a sip or sips URI and the
>>>> other MUST be a tel URI.
>>>> 
>>>> It's not clear to me why the definition restricts the scheme to sip,
>>>> sips, or tel. Could someone provide some insight about that? Would
>>>> things break if we allowed more URI schemes there, in particular the
>>>> xmpp scheme?
>>>> 
>>>> Thanks!
>>>> 
>>>> Peter
>>>> 
>>>> - --
>>>> Peter Saint-Andre
>>>> https://stpeter.im/
>>>> 
>>>> 
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>> 
>>>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
>>>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
>>>> =lu3v
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>> 
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
>> 
>> 
>> 
>> --
>> Emil Ivov, Ph.D.                       67000 Strasbourg,
>> Project Lead                           France
>> Jitsi
>> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
>> http://jitsi.org                       FAX:   +33.1.77.62.47.31
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch