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

["Cullen Jennings (fluffy)" <[e-mail]>]

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:[e-mail]> ;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. 

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 <[e-mail]>
wrote:

> Hey Cullen,
> 
> On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy)
> <[e-mail]> 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:[e-mail]> ;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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> 
> 
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> [e-mail]                        PHONE: [phone]
> http://jitsi.org                       FAX:   [phone]