Subject: [Sipping] Fwd: Re: Reminder: WGLC: draft-ietf-sipping-update-pai-04 --- EndsFriday!

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Jul 2008 14:57:12 -0700

At 2:18 PM -0700 7/17/08, Jonathan Rosenberg wrote:
>We didn't have any restriction in URI types for the Contact header field
>in SIP itself:
>
>    The Contact header field values of the request typically consist of
>    SIP or SIPS URIs that identify particular SIP endpoints (for example,
>    "sip:[email-masked]"), but they MAY use any URI scheme.
>    A SIP UA can choose to register telephone numbers (with the tel URL,
>    RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
>    as Contacts for an address-of-record, for example.
>
>If its not a problem in RFC3261, I don't see why its a problem here.

>I really don't see the problem. If someone sends me a P-A-I header field
>with a URI scheme I don't understand, I discard it. If I do understand
>it, its meaning is well defined by the URI scheme itself. Where is the
>interop issue?
>
>-Jonathan R.

Because URI matching is rarely as simple as people believe.   At one
end of the spectrum is simple string matching; at the other end is
"equivalence" of what you get when you dereference the URI.   To
take some examples from RFC 4516, you really need to know
whether someone  asserting an identity  for

 ldap:///o=University%20of%20Michigan,c=US

and
 
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US

are asserting the same thing or something different and
on what it depends.  That will vary per URI scheme (and
what it can vary on in LDAP might surprise you, since
LDAP is a common source of enterprise "identity").  There
are some schemes for which it will be easy to make the judgement
call; for others it will not. For other examples, think of split DNS answers
for the dns URI scheme and the RRs I gave earlier, or even the
overlay-node scheme I propose in draft-hardie-p2psip-p2p-pointers-00.txt ;
in a specific context, what you get may vary from what you'd
get in a different or named context (and that's why
the overlay-node scheme has a way to name the context).  What does
your assertion mean, there?

Do you want the [email-masked] problem
all over again, one per scheme?   Without real definitions,
you will get that level of ambiguity or worse for some of the
schemes that may look "obvious".

			regards,
				Ted

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jul 2008 23:39:23 -0400

Wow! I wasn't paying attention for a few hours, and this explosion happens!

I think we *at least* need to permit more instances of the existing 
schemes. And that seems to be non-controversial.

I see good arguments on both sides for expanding the number of schemes. 
I don't have strong feelings about it, since I don't currently know of 
any others that are needed, though that could change. I think we just 
need to decide how and when use of additional schemes should be decided. 
Do we see a need for that to happen without another RFC of some sort?

It seems the range of options are:
- adding another scheme requires another revision to the PAI RFC
- Adding another requires an RFC, but not a revision to PAI
   (I guess this would be via an IANA registry)
- Adding another requires recording somewhere public
   (Iana registry without RFC requirement)
- We allow use of any scheme

I agree with Ted that saying not all are allowed, but not giving any 
objective criterion for which ones are is problematic.

I'm inclined to think that a registry with an RFC requirement would be 
sufficient. But for that to be useful I think we would need a template 
set of information that would need to be specified. While that isn't 
rocket science, it may be more than we want to work on now. If not, then 
I guess I would leave it that another revision to PAI is required.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jul 2008 09:39:47 +0100

Thanks for all who expressed an opinion yesterday evening. My proposal
would be to say you MUST send at least one sip, sips or tel URI and MAY
send other schemes that might be useful to the recipient as a means of
identifying the originator of a request or response. Then on receipt at
a UA (from a trusted entity), one should be able to accept any number of
URIs and discard any schemes not supported. Since we don't mandate any
particular handling at a UA on receipt, I don't think we can mandate
support even for TEL/SIP/SIPS.

Although not discussed, I don't think we need to allow more than one URI
of the same scheme.

This leaves a difficulty with a proxy, which normally would pass on a
PAI from one trusted entity to another. Do we say it MUST pass on
unsupported/unrecognised schemes? Or should we allow it to discard them?
My inclination is to allow them to be dropped, because I don't see
service providers wanting to carry excess baggage.

So my proposed words would be:

1. A new subsection in the Discussion section:
    <section title="URIs that can be included in a P-Asserted-Identity
or P-Preferred-Identity header field">
      <t>RFC 3325 allows a proxy to include "at most one SIP or SIPS URI
and at most one TEL URL" in the P-Asserted-Identity header field. In
practice, this unnecessarily restrictive and prevents the assertion of
multiple URIs known to be associated with the authenticated user. For
example, there may be occasions where both a SIP and a SIPS URI can
advantageously be asserted. Other URI schemes like MAILTO might also be
asserted where they provide meaningful identification of the
authenticated user.</t>
    <t>This update to RFC 3325 removes the restriction of two URIs and
its limitation to TEL, SIP and SIPS URIs.</t>
    </section>

2. New text in UAC behaviour sub-section:
        <t>When including a P-Asserted-Identity or P-Preferred-Identity
header field in a request, a UAC MUST include one or more URIs, each
with a different scheme. At least one of these URIs MUST be a TEL, SIP
or SIPS URI. A UAC MAY include URIs with schemes other than SIP, SIPS
and TEL where they provide meaningful identification of the user.</t>

3. New text in proxy behaviour sub-section:
"A proxy MUST silently discard any URIs with schemes it is not prepared
to accept."
and
"<t>When adding a P-Asserted-Identity header field to a forwarded
request, a proxy MUST include one or more URIs, each with a different
scheme. At least one of these URIs MUST be a TEL, SIP or SIPS URI. A UAC
MAY include URIs with schemes other than SIP, SIPS and TEL where they
provide meaningful identification of the user.</t>"

4. New text in the UAS sub-section
"<t>This document does not mandate any UA handling for any particular
URI scheme (although SIP, SIPS or TEL URIs are most likely to be
received) or for multiple URIs that happen to appear in a request,
except that a UAS MUST silently discard any URIs that it is unable to
handle.</t>"

5. Corresponding changes for response handling at UAC, proxy and UAS.

6. New section on syntax:
"  <section title="Syntax">
    <t>The formal syntax of P-Asserted-Identity and P-Preferred-Identity
header fields is modified as follows. The limit of two instances of
PAssertedID-value is removed, thereby allowing more than one instance of
name-addr or addr-spec. At least one instances MUST be either a SIP URI,
a SIPS URI or a TEL URI. Multiple URIs with the same scheme are not
allowed.</t>
  </section>"

I think this should be workable, but if people think this is too
relaxed, and we need to allow schemes on a case by case basis, then as
Paul says, we would need a process for doing that and it would appear to
be beyond the scope of the present work. So if we can gain consensus on
the solution above, fine, but otherwise I think we need to fall back to
just the three existing schemes.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 18 July 2008 04:39
> To: Ted Hardie
> Cc: [email-masked]
> Subject: Re: [Sipping] Fwd: Re: Reminder: WGLC: 
> draft-ietf-sipping-update-pai-04 --- EndsFriday!
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Fri, 18 Jul 2008 07:38:40 -0400

Hi John,

Thanks for putting this together.  Pl. see inline ..

>[mailto:[email-masked]] On Behalf Of Elwell, John
>Sent: Friday, July 18, 2008 4:40 AM
>To: [email-masked]
>Thanks for all who expressed an opinion yesterday evening. My 
>proposal would be to say you MUST send at least one sip, sips 
>or tel URI and MAY send other schemes that might be useful to 
>the recipient as a means of identifying the originator of a 
>request or response. Then on receipt at a UA (from a trusted 
>entity), one should be able to accept any number of URIs and 
>discard any schemes not supported. Since we don't mandate any 
>particular handling at a UA on receipt, I don't think we can 
>mandate support even for TEL/SIP/SIPS.
>
>Although not discussed, I don't think we need to allow more 
>than one URI of the same scheme.

IMO, this restriction should be removed too, that is a UA is allowed to
add more than one uri of the same scheme. This was one of the items in
Jonathan's email. 
Is there any particular reason for not allowing this?

>
>This leaves a difficulty with a proxy, which normally would 
>pass on a PAI from one trusted entity to another. Do we say it 
>MUST pass on unsupported/unrecognised schemes? Or should we 
>allow it to discard them?
>My inclination is to allow them to be dropped, because I don't 
>see service providers wanting to carry excess baggage.

I do not have a strong opinion, but I think this may cause some
heartburn if proxies are allowed to drop unrecognised schema, esp. with
the MUST recommenedation below in the Proxy section.

>    <section title="URIs that can be included in a 
>P-Asserted-Identity or P-Preferred-Identity header field">
>      <t>RFC 3325 allows a proxy to include "at most one SIP 
>or SIPS URI and at most one TEL URL" in the 
>P-Asserted-Identity header field. In practice, this 
>unnecessarily restrictive and prevents the assertion of 
>multiple URIs known to be associated with the authenticated 
>user. For example, there may be occasions where both a SIP and 
>a SIPS URI can advantageously be asserted. Other URI schemes 
>like MAILTO might also be asserted where they provide 
>meaningful identification of the authenticated user.</t>
>    <t>This update to RFC 3325 removes the restriction of two 
>URIs and its limitation to TEL, SIP and SIPS URIs.</t>
>    </section>
>
>        <t>When including a P-Asserted-Identity or 
>P-Preferred-Identity header field in a request, a UAC MUST 
>include one or more URIs, each with a different scheme. At 
>least one of these URIs MUST be a TEL, SIP or SIPS URI. A UAC 
>MAY include URIs with schemes other than SIP, SIPS and TEL 
>where they provide meaningful identification of the user.</t>

As above, I do not like the each with a different scheme limitation.

Sanjay

>"A proxy MUST silently discard any URIs with schemes it is not 
>prepared to accept."
>and
>"<t>When adding a P-Asserted-Identity header field to a 
>forwarded request, a proxy MUST include one or more URIs, each 
>with a different scheme. At least one of these URIs MUST be a 
>TEL, SIP or SIPS URI. A UAC MAY include URIs with schemes 
>other than SIP, SIPS and TEL where they provide meaningful 
>identification of the user.</t>"
>
>"<t>This document does not mandate any UA handling for any 
>particular URI scheme (although SIP, SIPS or TEL URIs are most 
>likely to be
>received) or for multiple URIs that happen to appear in a 
>request, except that a UAS MUST silently discard any URIs that 
>it is unable to handle.</t>"
>
>    <t>The formal syntax of P-Asserted-Identity and 
>P-Preferred-Identity header fields is modified as follows. The 
>limit of two instances of PAssertedID-value is removed, 
>thereby allowing more than one instance of name-addr or 
>addr-spec. At least one instances MUST be either a SIP URI, a 
>SIPS URI or a TEL URI. Multiple URIs with the same scheme are 
>not allowed.</t>
>  </section>"
>
>I think this should be workable, but if people think this is 
>too relaxed, and we need to allow schemes on a case by case 
>basis, then as Paul says, we would need a process for doing 
>that and it would appear to be beyond the scope of the present 
>work. So if we can gain consensus on the solution above, fine, 
>but otherwise I think we need to fall back to just the three 
>existing schemes.
>
>John
>
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jul 2008 13:41:37 +0100

Sanjay,

> From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
> Sent: 18 July 2008 12:39
> To: Elwell, John; [email-masked]
> Subject: RE: [Sipping] Fwd: Re: Reminder: WGLC: 
[JRE] I wasn't sure of use cases, and how would a recipient interpret
two URIs of the same scheme? I don't feel strongly about this, so let's
see what others think.

> the MUST recommenedation below in the Proxy section.
[JRE] Proxies will drop ANY PAI from an untrusted node. From a trusted
node, that trust will depend on Spec(T) between the domains concerned,
and that Spec(T) may well stipulate the URI schemes that are acceptable.
So I think it is reasonble to allow the dropping of unsupported schemes,
or schemes not part of the trust agreement.

> As above, I do not like the each with a different scheme limitation.
[JRE] See above.

John

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jul 2008 11:30:23 -0400

John,

Two URIs of the same scheme is frankly the use case I worry most about - 
that is the one I raised in my original mail on this.

The use case is an enterprise where it is very common for a user to be 
known by several identifiers:

sip:[email-masked]    -> internal-only number
sip:[email-masked] -> my external number
sip:[email-masked]      -> my uri

in this case it would be THREE sip URI; now I could convert the first 
two to tel - though tel URI is spotty as you know - but anyway thats 
still TWO TEL URI. So either way, we're talking about multiple URI of 
the same scheme.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jul 2008 16:50:58 +0100

Jonathan,

Of course, this issue came up in the context of From and Identity. Yes,
we could apply it to PAI too. I was thinking use TEL for E.164 and SIP
for the email-style (and any private number can generally be converted
to an E.164). But there are cases where there is no direct E.164
equivalent, so the private number would be the number of the user and
the E.164 would be the default for the enterprise (e.g., attendant). I
guess there are use cases where conveyance of all three would be
advantageous. So I don't mind adding this, but I think Keith at least
needs to be convinced.

John 

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 18 July 2008 16:30
> To: Elwell, John
> Cc: Sanjay Sinha (sanjsinh); [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jul 2008 12:50:22 -0400

Jonathan,

Actually, you can't convert sip:[email-masked] to tel, at least not 
without providing a phone-context.

Personally, I don't agree with using URIs of that form when there is an 
E.164, but that is an argument for another day.

	Paul

Jonathan Rosenberg wrote:
>>> From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] Sent: 18 
>>> July 2008 12:39
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Elwell, John
>>>> proposal would be to say you MUST send at least one sip, sips or tel 
>>>> URI and MAY send other schemes that might be useful to the recipient 
>>>> as a means of identifying the originator of a request or response. 
>>>> Then on receipt at a UA (from a trusted entity), one should be able 
>>>> to accept any number of URIs and discard any schemes not supported. 
>>>> Since we don't mandate any particular handling at a UA on receipt, I 
>>>> don't think we can mandate support even for TEL/SIP/SIPS.
>>>>
>>>> Although not discussed, I don't think we need to allow more than one 
>>>> URI of the same scheme.
>>> Jonathan's email. Is there any particular reason for not allowing this?
>>>> This leaves a difficulty with a proxy, which normally would pass on 
>>>> a PAI from one trusted entity to another. Do we say it MUST pass on 
>>>>      <t>RFC 3325 allows a proxy to include "at most one SIP or SIPS 
>>>> URI and at most one TEL URL" in the P-Asserted-Identity header 
>>>> field. In practice, this unnecessarily restrictive and prevents the 
>>>> assertion of multiple URIs known to be associated with the 
>>>> authenticated user. For example, there may be occasions where both a 
>>>> SIP and a SIPS URI can advantageously be asserted. Other URI schemes 
>>>> like MAILTO might also be asserted where they provide meaningful 
>>>> identification of the authenticated user.</t>
>>>>    <t>This update to RFC 3325 removes the restriction of two URIs 
>>>> and its limitation to TEL, SIP and SIPS URIs.</t>
>>>>    </section>
>>>>
>>>> P-Preferred-Identity header field in a request, a UAC MUST include 
>>>> one or more URIs, each with a different scheme. At least one of 
>>>> these URIs MUST be a TEL, SIP or SIPS URI. A UAC MAY include URIs 
>>>> with schemes other than SIP, SIPS and TEL where they provide 
>>>> meaningful identification of the user.</t>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jul 2008 15:07:49 -0400

Sorry - I left off the phone-context. It would in principle be there for 
either the SIP or tel URI form though:

sip:5001;phone-context=[email-masked]
tel:4001;phone-context=example.com

Of course, as you well know, people often leave off the phone context 
and in reality, you typically see:

sip:[email-masked]

But, thats all orthogonal and remains another big mess that needs to be 
cleaned up.

-Jonathan R.

Paul Kyzivat wrote:
>> Two URIs of the same scheme is frankly the use case I worry most about 
>> - that is the one I raised in my original mail on this.
>>
>>>>> proposal would be to say you MUST send at least one sip, sips or 
>>>>> tel URI and MAY send other schemes that might be useful to the 
>>>>> recipient as a means of identifying the originator of a request or 
>>>>> response. Then on receipt at a UA (from a trusted entity), one 
>>>>> should be able to accept any number of URIs and discard any schemes 
>>>>> not supported. Since we don't mandate any particular handling at a 
>>>>> UA on receipt, I don't think we can mandate support even for 
>>>>> TEL/SIP/SIPS.
>>>>>
>>>>> Although not discussed, I don't think we need to allow more than 
>>>>> one URI of the same scheme.
>>>>> authenticated user. For example, there may be occasions where both 
>>>>> a SIP and a SIPS URI can advantageously be asserted. Other URI 
>>>>> schemes like MAILTO might also be asserted where they provide