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

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Feb 2013 14:50:25 -0700

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/

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 4 Feb 2013 22:59:10 -0500

RFC 5876 extends the P-Asserted-Identity header to cover unexpected URI schemes (i.e., other than SIP/SIPS/TEL):

   RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity
   header fields each to contain at most two URIs, where one is a SIP or
   SIPS URI [RFC3261] and the other is a TEL URI [RFC3966].  This may be
   unduly restrictive in the future, for example, if there is a need to
   allow other URI schemes, if there is a need to allow both a SIP and a
   SIPS URI, or if there is a need to allow more than one URI with the
   same scheme (e.g., a SIP URI based on a telephone number and a SIP
   URI that is not based on a telephone number).  This document
   therefore provides forwards compatibility by mandating tolerance to
   the receipt of unexpected URIs.

See Section 4.5 for general handling of unexpected URI schemes.

Regards,

Gonzalo

On Feb 4, 2013, at 4:50 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear DISPATCHers,
> 
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Feb 2013 00:19:16 -0500

Not responsive to your specific query, but what places did you consider?

Reply-To is a possibility.

And while Contact isn't viable for this in most messages, in REGISTER it 
can work.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Tue, 05 Feb 2013 09:27:58 -0500

Hey Paul,

> And while Contact isn't viable for this in most messages, in REGISTER it 

Right, but we really need something in the INVITE in order to avoid
having to look through a roster for an entry or an entry's vCard
matching the "From" header (which also has security issues).

Emil

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Feb 2013 08:56:03 -0700

On 2/4/13 8:59 PM, Gonzalo Salgueiro wrote:
> RFC 5876 extends the P-Asserted-Identity header to cover
> unexpected URI schemes (i.e., other than SIP/SIPS/TEL):

Hi Gonzalo,

Thanks for the pointer. I'll read RFC 3325 and RFC 5876 more
thoroughly before replying again, and ponder whether
draft-ivov-xmpp-cusax is a Spec(T) in the sense defined within RFC 3324...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Feb 2013 11:08:27 -0500

> matching the "From" header (which also has security issues).

I wasn't aware of the context of your discussion, but I was assuming 
that REGISTER wasn't what you were looking for.

Reply-To can work here. Neither it nor P-Asserted-Identity are ideal - 
neither have precisely the right semantics. AFAIK Reply-To is present 
only as a carry over from HTTP - I've never heard of it being used. That 
could be viewed as a good thing or a bad thing. P-Asserted-Identity is 
really about identity and authorization, not about addressability. On 
margin I think I like Reply-To better among the two.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Wed, 06 Feb 2013 11:24:30 -0500

On 05.02.13, 11:08, Paul Kyzivat wrote:
> only as a carry over from HTTP - I've never heard of it being used.

It definitely sounds like a good backup option so thanks for sending it!

> That 
> really about identity and authorization, not about addressability.

Well, it could be argued that in CUSAX your XMPP JID _is_ your identity.
That's how people learn about you (in their roster) and that's the
address you would put on a business card. Your SIP AOR is just a thing
you use for making calls.

So in other words P-Asserted-Identity would be telling the other side:
hey this is who I really am.

Emil

> On 

-- 
https://jitsi.org

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Feb 2013 17:47:14 +0100

> hey this is who I really am.
No it would be whoever you have established a secure connection with telling you who they believe the other side is. It is a hop by hop trust model.

P-Preferred-Identity is telling the first entity who you really are, and you may not be believed.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Emil Ivov
> Sent: 06 February 2013 16:25
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 6 Feb 2013 12:12:54 -0500 (EST)

> From: Peter Saint-Andre <[email-masked]>
> 
> (certainly better than a second Contact header).

What is the semantics of the usage?  That determines where to put the
XMPP URI.  I can't imagine a single meaning which could justify use in
either Contact and P-Asserted-Identity.

Dale

---

From: Emil Ivov <[email-masked]>
Date: Thu, 07 Feb 2013 13:35:10 -0500

Hey,

> either Contact and P-Asserted-Identity.

We discussed this offline but for the sake of completeness:

The semantics come from draft-ivov-xmpp-cusax. The point is to be able
to discover the XMPP identity (JID) of an incoming SIP request and
potentially match it to an entry in a locally available XMPP roster.

A simple use case is: Bob gets an INVITE from sip:[email-masked]. The
INVITE says that Alice's XMPP identity is xmpp:[email-masked], so
Bob's agent can now use this to lookup Alice's entry in his XMPP roster
and then show her picture on the call alert window/dialog.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Dean Willis <[email-masked]>
Date: Mon, 11 Feb 2013 12:47:16 -0600

On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre <[email-masked]> wrote:

> XMPP address in the header of a SIP message. 

IIRC, we meant to use Contact: for alt-protocol references.

RFC 3261 11.2 shows the use of a Contact: field in a response to an Options request to indicate an alternate protocol contact:

"Contact header fields MAY be present in a 200 (OK)  response and have the same semantics as in a 3xx response.  That is,  they may list a set of alternative names and methods of reaching the user."

Example:
      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
       ;received=192.0.2.4
      To: <sip:[email-masked]>;tag=93810874
      From: Alice <sip:[email-masked]>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:[email-masked]>
      Contact: <mailto:[email-masked]>
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
      Accept: application/sdp
      Accept-Encoding: gzip
      Accept-Language: en
      Supported: foo
      Content-Type: application/sdp
      Content-Length: 274

      (SDP not shown)
I suspect that RFC 3261 12.1.2 is overstrict in its restriction of Contact in an dialog-initiating request to encode exactly one URI which must be SIP or SIPS.  I'm thinking it should say "Exactly one SIP or SIPS URI" without restricting additional URIs that might be present.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Feb 2013 16:27:14 -0500

On 2/11/13 1:47 PM, Dean Willis wrote:

> I suspect that RFC 3261 12.1.2 is overstrict in its restriction of
> Contact in an dialog-initiating request to encode exactly one URI which
> must be SIP or SIPS.  I'm thinking it should say "Exactly one SIP or
> SIPS URI" without restricting additional URIs that might be present.

Hmm. Interesting idea.

Regardless of how interesting it is, I think it won't fly well as an 
extension now. I'm pretty certain that many (most/all) implementations 
would barf on this usage in an INVITE or other dialog establishing request.

IMO there needs to be a clear separation between what is to be used to 
establish the dialog, and what could be used to communicate *outside* of 
this dialog.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Feb 2013 08:45:58 -0500 (EST)

> From: Dean Willis <[email-masked]>
> 
> RFC 3261 11.2 shows the use of a Contact: field in a response to an
> Options request to indicate an alternate protocol contact:
> 
> "Contact header fields MAY be present in a 200 (OK)  response and
> have the same semantics as in a 3xx response.  That is,  they may
> list a set of alternative names and methods of reaching the user."

> Contact in an dialog-initiating request to encode exactly one URI
> which must be SIP or SIPS.  I'm thinking it should say "Exactly one
> SIP or SIPS URI" without restricting additional URIs that might be
> present.

I agree with Paul here.

The difficulty with Contact is that it has two distinctly different
uses.  One use is to indicate "You can contact this AOR here."  That's
its purpose in 3xx responses and 2xx responses to OPTIONS.  The other
use is, "This is the routing address for this endpoint, for this
dialog."  That's its purpose in INVITE and 2xx responses to INVITEs.

As far as I can tell, this unspoken distinction was well-established
by the time RFC 3261 was approved.

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Feb 2013 19:27:47 -0700

On 2/13/13 6:45 AM, Dale R. Worley wrote:
>> RFC 3261 11.2 shows the use of a Contact: field in a response to
>> an Options request to indicate an alternate protocol contact:
>> 
>> "Contact header fields MAY be present in a 200 (OK)  response
>> and have the same semantics as in a 3xx response.  That is,  they
>> may list a set of alternative names and methods of reaching the
>> user."
> 
>> I suspect that RFC 3261 12.1.2 is overstrict in its restriction
>> of Contact in an dialog-initiating request to encode exactly one
>> URI which must be SIP or SIPS.  I'm thinking it should say
>> "Exactly one SIP or SIPS URI" without restricting additional URIs
>> that might be present.
> 
> I agree with Paul here.
> 
> The difficulty with Contact is that it has two distinctly
> different uses.  One use is to indicate "You can contact this AOR
> here."  That's its purpose in 3xx responses and 2xx responses to
> OPTIONS.  The other use is, "This is the routing address for this
> endpoint, for this dialog."  That's its purpose in INVITE and 2xx
> responses to INVITEs.
> 
> As far as I can tell, this unspoken distinction was
> well-established by the time RFC 3261 was approved.

Revisiting this topic, I understand the distinction here, but that
leaves me wondering how to include an XMPP address in a SIP INVITE.
Apparently both P-Asserted-Identity (or P-Preferred-Identity) and
Contact are inappropriate. And defining a new SIP header seems to be a
non-starter. However, I suppose the Contact header could be included
in non-INVITE messages, such as OPTIONS.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2013 00:10:05 -0500

> in non-INVITE messages, such as OPTIONS.

I still offer Reply-To as a possibility.

	Thanks,
	Paul

> iQIcBAEBAgAGBQJRJYYjAAoJEOoGpJErxa2pcH8P/ArcB3Kwki7ZDf+fB4jNQoY+
> X6rK/1UqGzBsn5usraenL/zwr5Q7asOTGZOpEt6KPfszyKa7+AhQGfFWNji9ifj5
> KTZqfeDO2VXXVDr2nTQJffxMXHt6q6Ate1KhrYfctyjYW0wZMF08el9kZtLMKFwc
> qiRASCcrA0nv6oqOFO6vRQ99BfP94TGII4TqNU41pBphDwyX/61Ln9yMzfpEuh/2
> VlO5+kZoV1auyawBYb5wHakioFc2bqGR3wwAVPrpqhs6DZtRY/jArMaa/MUHdBhL
> k8Aw799RN55MaIePtdq4AjlgpCYmpKy4kYkfl8TBQ1hQSjoAtU5dZwhcpgEt27YY
> mqe23aXegT/O0hhEcl2L/rmgm7CDYTKgjZ+t/0N6yg/FzE8PnUJl8JOPXs4+J3NC
> 2kpOnpnTUKhC7nD6IzRTrud2uHU5UFJWodsubzVDF1nUD/F/m/b2Sg/8twZW+P/Z
> W3fY3gi374+ZiEzZqh9+Eumvda/12UGKjYcSGDuYDD403ONvW24aURAMD9N3WtWY
> HXzio+foM5YKB1Zu3FImDbAmu7EIogGpAyhF6fazGOk0Ytyr000URfI/pj8gPYQi
> BYJV5klSdq6U7QVXAry+5cMJjfCAD24V4ia7H6C3chRQXMRZDCY6yCrBtbfXsYAm
> MF+//A+qeyD4x/i5Q96c
> =z5X3

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Feb 2013 22:15:29 -0700

On 2/20/13 10:10 PM, Paul Kyzivat wrote:
> On 2/20/13 9:27 PM, Peter Saint-Andre wrote: On 2/13/13 6:45 AM,
> Dale R. Worley wrote:
>>>>> RFC 3261 11.2 shows the use of a Contact: field in a
>>>>> response to an Options request to indicate an alternate
>>>>> protocol contact:
>>>>> 
>>>>> "Contact header fields MAY be present in a 200 (OK)
>>>>> response and have the same semantics as in a 3xx response.
>>>>> That is,  they may list a set of alternative names and
>>>>> methods of reaching the user."
>>>> 
>>>>> I suspect that RFC 3261 12.1.2 is overstrict in its
>>>>> restriction of Contact in an dialog-initiating request to
>>>>> encode exactly one URI which must be SIP or SIPS.  I'm
>>>>> thinking it should say "Exactly one SIP or SIPS URI"
>>>>> without restricting additional URIs that might be present.
>>>> 
>>>> I agree with Paul here.
>>>> 
>>>> different uses.  One use is to indicate "You can contact this
>>>> AOR here."  That's its purpose in 3xx responses and 2xx
>>>> responses to OPTIONS.  The other use is, "This is the routing
>>>> address for this endpoint, for this dialog."  That's its
>>>> purpose in INVITE and 2xx responses to INVITEs.
>>>> 
> leaves me wondering how to include an XMPP address in a SIP
> INVITE. Apparently both P-Asserted-Identity (or
> P-Preferred-Identity) and Contact are inappropriate. And defining a
> new SIP header seems to be a non-starter. However, I suppose the
> Contact header could be included in non-INVITE messages, such as
> OPTIONS.
> 

Does Reply-To imply that all replies in the session ought to be
directed to that address? We don't want to "hijack" the session so
that traffic is redirected to the XMPP address, only to advertise the
fact that a dual-stack client can be contacted via the XMPP path in
addition to the SIP path.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 21 Feb 2013 09:30:36 -0500 (EST)

> in non-INVITE messages, such as OPTIONS.

It seems that the semantic you want is "The UAC asserts this is an
alternative identity for the caller identified by the From: header."
I would think one of the many "identity" headers would supply that,
but after looking a bit, it seems that there is none such defined.

In practice, Remote-Party-Id seems to have that sort of intention, but
there is a general attitude that people are only interested in
"identities" if some trusted network can vouch for them.  You might
want to look into draft-dcsgroup-sip-privacy and
draft-ietf-sip-privacy and the discussions surrounding them to see why
Remote-Party-Id didn't get standardized.

In any case, please don't bastardize some header that has an
incompatible definition.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2013 09:51:00 -0500

> addition to the SIP path.

AFAIK there is *no* history of Reply-To being used with SIP, though it 
has been present in the syntax forever.

I *guess* that it is present based on analogy to email. In email I guess 
Reply-To typically takes precedence over From as a destination for 
future messages.

So using Reply-To here would be breaking new ground, almost as much as 
introducing a new header would.

To avoid hyjacking, I suppose one could put *both* a sip URI and an xmpp 
URI in the Reply-To. In email that would presumably mean to reply to 
*both*, but in sip it couldn't very well mean that, so someone wanting 
to follow it would be forced to choose.

If we expect anyone to implement this behavior there will need to be 
some document that specifies precisely what behavior is expected. So it 
probably doesn't matter much whether Reply-To is adopted for this 
behavior or a new header is defined.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Feb 2013 08:10:07 -0700

On 2/21/13 7:30 AM, Dale R. Worley wrote:
>> Revisiting this topic, I understand the distinction here, but
>> that leaves me wondering how to include an XMPP address in a SIP
>> P-Preferred-Identity) and Contact are inappropriate. And defining
>> a new SIP header seems to be a non-starter. However, I suppose
>> the Contact header could be included in non-INVITE messages, such
>> as OPTIONS.
> 
> alternative identity for the caller identified by the From:
> header." I would think one of the many "identity" headers would
> supply that, but after looking a bit, it seems that there is none
> such defined.
> 
> In practice, Remote-Party-Id seems to have that sort of intention,
> but there is a general attitude that people are only interested in 
> "identities" if some trusted network can vouch for them.  You
> might want to look into draft-dcsgroup-sip-privacy and 
> draft-ietf-sip-privacy and the discussions surrounding them to see
> why Remote-Party-Id didn't get standardized.
> 

Certainly not. That's why we're trying to find out what these headers
really mean in practice so that we don't use the wrong one. Although
I'm starting to get the sense that there is no right one, and this use
case might not warrant a new one (which probably would be stripped out
by b2bua's and such anyway).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 21 Feb 2013 16:19:29 +0100

Hi,

> by b2bua's and such anyway).

What about using a Contact header parameter instead of a header? Something like this:

Contact: <sip:[email-masked]:54819>;+sip.instance="urn:uuid:2af16065-6f4c-40a5-8bee-c38678776dec";+xmpp.jid="[email-masked]"

Regards,

--
Saúl Ibarra Corretgé
AG Projects