Subject: Re: [Sipping] WGLC: draft-ietf-sipping-update-pai-04

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 16 Jul 2008 11:05:51 +0200

Hello all,

I went through the document and could not find anything to complain
about.

I think the document is "Ready".

Regards
Thomas

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: Friday, June 27, 2008 4:36 PM
> To: [email-masked]
> Cc: Elwell, John; Gonzalo Camarillo
> Subject: [Sipping] WGLC: draft-ietf-sipping-update-pai-04
> 
> Hi Folks,
> 
> This email is to announce the WGLC for this document.
> 
> The past reviewers (Vijay Gurbani, Francois Audet, Paul Kyzivat and
> Thomas Stach) are especially requested to review the document 
> to ensure
> that previous comments have been addressed.  
> 
> The WGLC ends on Friday, July 18th, 2008 (three weeks time in
> consideration of IETF-72 draft deadlines). 
> 
> If you think the doc is "Ready", please post a comment to the list as
> well.  
> 
> Thanks,
> Mary.
> SIPPING WG co-chair
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Friday, June 27, 2008 9:20 AM
> To: [email-masked]
> Subject: [Sipping] draft-ietf-sipping-update-pai-04
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-
> pai-04.txt
> 
> The only changes are to fix the comments Paul made yesterday, in
> accordance with my response to Paul. This will be the WGLC version.
> 
> John
> 
> _______________________________________________
> 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
> _______________________________________________
> 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
> 
_______________________________________________
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: "Mary Barnes" <[email-masked]>
Date: Thu, 17 Jul 2008 08:30:24 -0500

This is a reminder that this WGLC ends this Friday, July 18th.  

We've had one response from Thomas Stach (AFAIK - if I've missed
something, let me know) that he believes the document is "Ready".  If
the other reviewers could please check the delta and provide their
feedback that would be great?

And, as always, others in the WG should also provide any final feedback
on this document.

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Barnes, Mary (RICH2:AR00)
Sent: Friday, June 27, 2008 9:36 AM
To: [email-masked]
Cc: Elwell, John; Gonzalo Camarillo
Subject: [Sipping] WGLC: draft-ietf-sipping-update-pai-04

Hi Folks,

The past reviewers (Vijay Gurbani, Francois Audet, Paul Kyzivat and
Thomas Stach) are especially requested to review the document to ensure
that previous comments have been addressed.  

Thanks,
Mary.
SIPPING WG co-chair

-----Original Message-----

http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-pai-04.txt

John

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Jul 2008 14:22:57 -0400

There has been some discussion about relaxing the schema restriction
from RFC 3325 about one sip/sips schema url and a tel: url. I did not
see any mention of that in this version. Does it mean that it was
decided not to relax that restriction?

Sanjay

>Sent: Thursday, July 17, 2008 9:30 AM
>To: [email-masked]
>Cc: Paul Kyzivat (pkyzivat); Francois Audet; Elwell, John; 
>Gonzalo Camarillo
>Subject: [Sipping] Reminder: WGLC: 
>draft-ietf-sipping-update-pai-04 --- EndsFriday!
>
>We've had one response from Thomas Stach (AFAIK - if I've 
>missed something, let me know) that he believes the document 
>is "Ready".  If the other reviewers could please check the 
>delta and provide their feedback that would be great?
>
>And, as always, others in the WG should also provide any final 
>feedback on this document.
>
>Thanks,
>Mary. 
>
>[mailto:[email-masked]] On Behalf Of Barnes, Mary 
>(RICH2:AR00)
>The past reviewers (Vijay Gurbani, Francois Audet, Paul 
>Kyzivat and Thomas Stach) are especially requested to review 
>the document to ensure that previous comments have been addressed.  
>
>If you think the doc is "Ready", please post a comment to the 
>list as well.  
>
>Thanks,
>Mary.
>SIPPING WG co-chair
>
>[mailto:[email-masked]] On Behalf Of Elwell, John
>The only changes are to fix the comments Paul made yesterday, 
>in accordance with my response to Paul. This will be the WGLC version.
>
>John
>
>[email-masked] for questions on current sip 
>[email-masked] for questions on current sip 
>[email-masked] for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jul 2008 20:01:17 +0100

Sanjay,

I tried to gain closure on this with the following message on 12th May:
http://www.ietf.org/mail-archive/web/sipping/current/msg15573.html

There were a few replies to that thread, but I am not sure we reached
any conclusion. I didn't sense any consensus to increase the range of
URI schemes beyond sip/sips/tel. Also I was not sure about the
conclusion on the issue of whether to lift the restriction of 2 URIs.

Then on 16th May when I posted draft-02 I also posted the following:
http://www.ietf.org/mail-archive/web/sipping/current/msg15633.html

I stated that I had not gained consensus on these points and requested
more list discussion. There were no more list comments and I indicated
privately to the chairs that I considered the issue closed, with no
further changes.

So if people want relaxation of the choice of schemes or of the number
of URIs, then please say now.

John

> From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
> Sent: 17 July 2008 19:23
> To: Mary Barnes; [email-masked]
> Subject: RE: [Sipping] Reminder: WGLC:

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 17 Jul 2008 14:05:32 -0500

I agree with your proposal, 3 and A. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2008 12:01
> To: Sanjay Sinha (sanjsinh); Barnes, Mary (RICH2:AR00); 
> [email-masked]
> Cc: Paul Kyzivat (pkyzivat); Audet, Francois (SC100:3055); 
> Gonzalo Camarillo
> There were a few replies to that thread, but I am not sure we 
> reached any conclusion. I didn't sense any consensus to 
> increase the range of URI schemes beyond sip/sips/tel. Also I 
> was not sure about the conclusion on the issue of whether to 
> lift the restriction of 2 URIs.
> 
> I stated that I had not gained consensus on these points and 
> requested more list discussion. There were no more list 
> comments and I indicated privately to the chairs that I 
> considered the issue closed, with no further changes.
> 
> So if people want relaxation of the choice of schemes or of 
> the number of URIs, then please say now.
> 
> John
>  
> 
> > Cc: Paul Kyzivat (pkyzivat); Francois Audet; Elwell, John; Gonzalo 
> > Camarillo
> > >Cc: Paul Kyzivat (pkyzivat); Francois Audet; Elwell, John; Gonzalo 
> > >Camarillo
> Kyzivat and 
> > >Thomas Stach) are especially requested to review the document to 
> > >ensure that previous comments have been addressed.
> > >

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 17 Jul 2008 12:08:56 -0700

> of URIs, then please say now.

I vote in favor of relaxing both.

Thanks,
Anders

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Jul 2008 15:34:22 -0400

I am also in favor of relaxing it.

>From: Anders Kristensen [mailto:[email-masked]] 
>Sent: Thursday, July 17, 2008 3:09 PM
>To: Elwell, John
>Cc: Sanjay Sinha (sanjsinh); Mary Barnes; [email-masked]; 
>Paul Kyzivat (pkyzivat); Francois Audet; Gonzalo Camarillo
>Subject: Re: [Sipping] Reminder: WGLC: 
>requested 
>>>> something, let me know) that he believes the document is "Ready".  
>>>> If the other reviewers could please check the delta and provide 
>>>> their feedback that would be great?
>>>>
>>>> If you think the doc is "Ready", please post a comment to the list 
>>>> as well.
>>>>
>>>> Thanks,
>>>> Mary.
>>>> SIPPING WG co-chair
>>>>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jul 2008 20:52:31 +0100

> Sent: 17 July 2008 20:34
> To: Anders Kristensen; Elwell, John
> Cc: Mary Barnes; [email-masked]; Paul Kyzivat (pkyzivat); 
> Francois Audet; Gonzalo Camarillo
[JRE] Which, the number of schemes or the number of URIs or both? I
think there was a strong concern about allowing any URI scheme, because
it simply wouldn't make sense for some schemes. See message from Ted
Hardie:
http://www.ietf.org/mail-archive/web/sipping/current/msg15497.html
I think there is more consensus to increase the number of URIs (i.e.,
the number of instances of sip/sips/tel URIs). Or possibly we could add
some named schemes, but I don't recall any specific proposals. So (as an
individual rather than author) I think we should increase the number of
URIs, but not the number of schemes.

John

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Jul 2008 16:10:52 -0400

Proposal 3 & A from this email:
http://www.ietf.org/mail-archive/web/sipping/current/msg15573.html

Thanks

>Sent: Thursday, July 17, 2008 3:53 PM
>To: Sanjay Sinha (sanjsinh); Anders Kristensen
>Cc: Paul Kyzivat (pkyzivat); Gonzalo Camarillo; 
>[email-masked]; Mary Barnes; Francois Audet
>> Cc: Mary Barnes; [email-masked]; Paul Kyzivat (pkyzivat); Francois 
>> Audet; Gonzalo Camarillo
>[JRE] Which, the number of schemes or the number of URIs or 
>both? I think there was a strong concern about allowing any 
>URI scheme, because it simply wouldn't make sense for some 
>schemes. See message from Ted
>Hardie:
>I think there is more consensus to increase the number of URIs 
>(i.e., the number of instances of sip/sips/tel URIs). Or 
>possibly we could add some named schemes, but I don't recall 
>any specific proposals. So (as an individual rather than 
>author) I think we should increase the number of URIs, but not 
>the number of schemes.
>
>John

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2008 16:12:30 -0400

My concrete proposal is:

1. to remove the limit on the number of URIs,
2. to allow any number of sip, sips, or tel URI
3. to allow other URI schemes as long as they are sensible as user 
identities. and give examples of things that make sense (mailto) and 
ones which dont (mid, opaquelocktoken, etc.)

-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: Ted Hardie <[email-masked]>
Date: Thu, 17 Jul 2008 13:17:29 -0700

>URIs, but not the number of schemes.

I continue to believe that an enumerated list of permitted URI
schems is the right way to go on this. It may well be that there
are benefits to URI schemes beyond sip/sip/tel, and list discussion
on specific schemes and why they should be included might
appropriately result in some new schemes being added.

But before anyone goes for "Let's leave it wide open, the
market will sort it out", please review the current set of
schemes:

http://www.iana.org/assignments/uri-schemes.html

It's a long list, with quite a few entries that would
make no sense at all and few that look plausible
but might well turn out to be painful.  Saying something
supports *every* scheme in that list is going to end
up being not true, with different implementations supporting
different subsets.  That way interoperability failure, if not
actual madness, lies.
			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Jul 2008 13:25:05 -0700

>ones which dont (mid, opaquelocktoken, etc.)

If  you don't make this an enumerated list, different folks will have
different ideas of what makes sense.  Does ldap make sense, and
are you sure someone else will come to the same conclusion as you?
How about tag?   If mailto works, is dns with a pointer to the
the MINFO (mailbox or mail list info) in or out?  How about a
dns uri pointinto an RP (responsible person) RR? How about whois or iris?

Making this dependent on someone's interpretation of this list is
not a way forward, at least in my opinion. 

			regards,
				Ted Hardie

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 17 Jul 2008 13:30:21 -0700

Certainly not all URI schemes make sense but what would anyone gain from 
using them and what harm can come of it? AFAIK there is also no 
restrictions on URI schemes that can be used in From and To...

IMHO some general text limiting PAI to identity related URI schemes is 
appropriate but a new registry is probably overkill.

Anders

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 17 Jul 2008 15:30:33 -0500

Really, what we should do is point out the ones that we know 
make sense, and leave everything else undefined for now (as opposed
to prohibited). Maybe saying that applicability of the schemes that
are not specifically listed in this draft is for further study.

What we don't want to do is wrongly rule some out hastily before we
can decide or not if they make sense.

Maybe there are a few that we could explicitly rule out, but I'm not
sure we need to do that now.

> From: Ted Hardie [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2008 13:25
> To: Jonathan Rosenberg; Elwell, John
> Gonzalo Camarillo; Sanjay Sinha (sanjsinh); Barnes, Mary 
> (RICH2:AR00); [email-masked]
> >1. to remove the limit on the number of URIs, 2. to allow 
> any number of 
> >sip, sips, or tel URI 3. to allow other URI schemes as long 
> as they are 
> >sensible as user identities. and give examples of things that make 
> >sense (mailto) and ones which dont (mid, opaquelocktoken, etc.)
> 
> If  you don't make this an enumerated list, different folks 
> will have different ideas of what makes sense.  Does ldap 
> make sense, and are you sure someone else will come to the 
> same conclusion as you?
> Making this dependent on someone's interpretation of this 
> list is not a way forward, at least in my opinion. 
> 
> 			regards,
> 				Ted Hardie
> 
> 
> 
> 
> >-Jonathan R.
> >
> >Elwell, John wrote:
> >>
> >>
> >> think there was a strong concern about allowing any URI scheme, 
> >> because it simply wouldn't make sense for some schemes. 
> See message 
> >> from Ted
> >> Hardie:
> >> the number of instances of sip/sips/tel URIs). Or possibly 
> we could 
> >> add some named schemes, but I don't recall any specific 
> proposals. So 
> >> (as an individual rather than author) I think we should 
> increase the 
> >> number of URIs, but not the number of schemes.
> >>
> >> John

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Jul 2008 13:44:00 -0700

>sure we need to do that now.

How do you get interoperability, then, when new ones are introduced?

				regards,
					Ted

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Jul 2008 16:46:05 -0400

Probably an overkill, but to improve inter-op and to guard against
personal interpretations, I think it should be good to list out uri
schemes that make sense as conveying user identities and others are
unsupported (use it within your walled garden)

Sanjay

>Sent: Thursday, July 17, 2008 4:30 PM
>To: Ted Hardie
>Cc: Elwell, John; Sanjay Sinha (sanjsinh); Paul Kyzivat 
>(pkyzivat); Gonzalo Camarillo; [email-masked]; Mary Barnes; 
>Francois Audet
>Certainly not all URI schemes make sense but what would anyone 
>gain from using them and what harm can come of it? AFAIK there 
>is also no restrictions on URI schemes that can be used in 
>From and To...
>
>IMHO some general text limiting PAI to identity related URI 
>schemes is appropriate but a new registry is probably overkill.

>>> because it simply wouldn't make sense for some schemes. See message 
>>> from Ted
>>> Hardie:
>>> the number of instances of sip/sips/tel URIs). Or possibly we could 
>> I continue to believe that an enumerated list of permitted 
>URI schems 
>> is the right way to go on this. It may well be that there 
>are benefits 
>> to URI schemes beyond sip/sip/tel, and list discussion on specific 
>> schemes and why they should be included might appropriately 
>result in 
>> some new schemes being added.
>> 
>market will 
>> sort it out", please review the current set of
>> schemes:
>> 
>> It's a long list, with quite a few entries that would make 
>no sense at 
>> all and few that look plausible but might well turn out to 
>be painful.  
>> Saying something supports *every* scheme in that list is 
>going to end 
>different 
>> subsets.  That way interoperability failure, if not actual madness, 
>> lies.
>> 			regards,
>> 				Ted Hardie
>> 
>> 
>> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 17 Jul 2008 15:46:55 -0500

Basically, you don't use them until their usage is defined (in an RFC).

We would probably be ready to describe sip and sips for now (maybe a few
others).

The others would follow-up later in new RFCs, when people bring use cases
for them.

> Sent: Thursday, July 17, 2008 13:44
> To: Audet, Francois (SC100:3055); Jonathan Rosenberg; Elwell, John
> Cc: Paul Kyzivat (pkyzivat); Gonzalo Camarillo; Sanjay Sinha 
> (sanjsinh); Barnes, Mary (RICH2:AR00); [email-masked]
> >Really, what we should do is point out the ones that we know make 
> >sense, and leave everything else undefined for now (as opposed to 
> >prohibited). Maybe saying that applicability of the schemes that are 
> >not specifically listed in this draft is for further study.
> >
> >What we don't want to do is wrongly rule some out hastily 
> before we can 
> >decide or not if they make sense.
> >
> >> Cc: Paul Kyzivat (pkyzivat); Audet, Francois (SC100:3055); Gonzalo 
> >> Camarillo; Sanjay Sinha (sanjsinh); Barnes, Mary (RICH2:AR00); 
> >> [email-masked]
> >> different ideas of what makes sense.  Does ldap make 
> sense, and are 
> >> you sure someone else will come to the same conclusion as you?
> >> the MINFO (mailbox or mail list info) in or out?  How 
> about a dns uri 
> >> pointinto an RP (responsible person) RR? How about whois or iris?
> >>
> >> >> Sipping mailing list  
> >> >> https://www.ietf.org/mailman/listinfo/sipping
> >> >Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2008 17:18:24 -0400

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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Jul 2008 17:34:14 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jonathan Rosenberg
>
> My concrete proposal is:
>

+1 for the above.

(I don't care either way about allowing other schemes, because I doubt anyone will use others for PAI; and the interop issues can be argued either way)

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 18 Jul 2008 15:17:03 +0200

Interoperability is the whole thing that concerns me about this
discussion.

The one I am interested in is with existing RFC 3325 implementations,
and there are an awful lot out there. 

I am reluctant (even object) to accept a change to the existing limits
without thoroughly exploring the compatibility issues. Generally I guess
on current proposals this will an update-pai implementation sending the
headers to an RFC 3325 implementation. Remember this can have an impact
on both UAs and proxies, as the edge proxy needs to convert P-Preferred
to P-Asserted. I have a number of questions:

1)	RFC 3325 specifies a limit on the number of headers. If an RFC
3325 implementation receives more than two, we don't define what
happens. Does it take the first two, throw them all away, or work its
way through them until it finds two it understands. What should we
specify for the updated-pai implementation to make it choose the most
sensible option.

2)	RFC 3325 specifies only SIP, SIPS and tel. If it see a URI
scheme it does not understand sufficiently to perform its normal
function on, what does it do with this (and what do current
implementations do with it). If current implementations just miss off
the URI scheme and render the remainder, I suspect we are in trouble. Do
they work through all headers until they find one they can work with. Do
they fail to understand the first and then ignore the remainder.

Answers to both these questions may mean it inappropriate to change the
current rules, that new headers are invented for other URI schemes, or
that we may need to specify ordering rules on what we specify to appear
first of any set of URI schemes. At the moment I do not know what the
answer will be.

Regards

Keith 

> [mailto:[email-masked]] On Behalf Of Ted Hardie
> Sent: Thursday, July 17, 2008 9:44 PM
> To: Francois Audet; Jonathan Rosenberg; Elwell, John
> Cc: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat); 
> [email-masked]; Gonzalo Camarillo; Mary Barnes
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 Jul 2008 11:33:17 -0500

What I would like to avoid is a situation where seeing a P-AI 
of an unrecognized scheme (unrecognized scheme in the context of P-AI of course)
causes an ERROR. This typically happens when we say YOU MUST NOT do this.
Rather, UAs should ignore P-AI of an unrecognized type.

What invariably happens when we are too restrictive is that we later 
find A use for it, and we have to invent insane procedures because
we can't break backward compatibility (PRACK, UPDATE come to mind).

So what I'm proposing is that UAs IGNORE P-AIs of schemes that are
unrecognized, i.e., that are not specifically spelled out in 
this draft.

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Friday, July 18, 2008 06:17
> To: Ted Hardie; Audet, Francois (SC100:3055); Jonathan 
> Rosenberg; Elwell, John
> [email-masked]; Gonzalo Camarillo; Barnes, Mary (RICH2:AR00)
> Interoperability is the whole thing that concerns me about 
> this discussion.
> 
> The one I am interested in is with existing RFC 3325 
> implementations, and there are an awful lot out there. 
> 
> I am reluctant (even object) to accept a change to the 
> existing limits without thoroughly exploring the 
> compatibility issues. Generally I guess on current proposals 
> this will an update-pai implementation sending the headers to 
> an RFC 3325 implementation. Remember this can have an impact 
> on both UAs and proxies, as the edge proxy needs to convert 
> P-Preferred to P-Asserted. I have a number of questions:
> 
> 3325 implementation receives more than two, we don't define 
> what happens. Does it take the first two, throw them all 
> away, or work its way through them until it finds two it 
> understands. What should we specify for the updated-pai 
> implementation to make it choose the most sensible option.
> 
> scheme it does not understand sufficiently to perform its 
> normal function on, what does it do with this (and what do 
> current implementations do with it). If current 
> implementations just miss off the URI scheme and render the 
> remainder, I suspect we are in trouble. Do they work through 
> all headers until they find one they can work with. Do they 
> fail to understand the first and then ignore the remainder.
> 
> Answers to both these questions may mean it inappropriate to 
> change the current rules, that new headers are invented for 
> other URI schemes, or that we may need to specify ordering 
> rules on what we specify to appear first of any set of URI 
> schemes. At the moment I do not know what the answer will be.
> 
> Regards
> 
> Keith 
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 18 Jul 2008 18:46:47 +0200

At least as far as my comments go you are missing the point.

We MUST cater for existing RFC 3325 implementations, and what they currently do on receipt, in any enhancement we make to this header. We cannot write new requirements in update-pai for those implementations, and yet they must still be able to do something sensible with what they receive.

We can only avoid that if we define a new header (or some other protocol mechanism). 

Regards

Keith

> From: Francois Audet [mailto:[email-masked]] 
> Sent: Friday, July 18, 2008 5:33 PM
> To: DRAGE, Keith (Keith); Ted Hardie; Jonathan Rosenberg; Elwell, John
> of an unrecognized scheme (unrecognized scheme in the context 
> of P-AI of course) causes an ERROR. This typically happens 
> when we say YOU MUST NOT do this.
> What invariably happens when we are too restrictive is that 
> we later find A use for it, and we have to invent insane 
> procedures because we can't break backward compatibility 
> (PRACK, UPDATE come to mind).
> 
> So what I'm proposing is that UAs IGNORE P-AIs of schemes 
> that are unrecognized, i.e., that are not specifically 
> spelled out in this draft.
> 
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 Jul 2008 12:55:17 -0500

Yeah, I see what you mean.

So RFC 3325 is another example of why being overly restrictive is
a bad idea then.

I'd really like to avoid a new header... I mean, we are already 
at a point of mind-bogling complexity.

My suspicion (hope?) is that we can build on top of 3325 without
breaking existing real implementations.

For example, by mandating that the first P-AI be of the types
that were allowed in 3325. (Hopefully that will work).

> Sent: Friday, July 18, 2008 09:47
> To: Audet, Francois (SC100:3055); Ted Hardie; Jonathan 
> Rosenberg; Elwell, John
> We MUST cater for existing RFC 3325 implementations, and what 
> they currently do on receipt, in any enhancement we make to 
> this header. We cannot write new requirements in update-pai 
> for those implementations, and yet they must still be able to 
> do something sensible with what they receive.
> 
> > What I would like to avoid is a situation where seeing a P-AI of an 
> > unrecognized scheme (unrecognized scheme in the context of P-AI of 
> > course) causes an ERROR. This typically happens when we say 
> YOU MUST 
> > NOT do this.
> we later 
> > find A use for it, and we have to invent insane procedures 
> because we 
> > can't break backward compatibility (PRACK, UPDATE come to mind).
> > 
> > unrecognized, i.e., that are not specifically spelled out in this 
> > draft.
> > 
> > 
> > 
> > > To: Ted Hardie; Audet, Francois (SC100:3055); Jonathan Rosenberg; 
> > > Elwell, John
> > > I am reluctant (even object) to accept a change to the existing 
> > > limits without thoroughly exploring the compatibility issues. 
> > > Generally I guess on current proposals this will an update-pai 
> > > implementation sending the headers to an RFC 3325 implementation. 
> > > Remember this can have an impact on both UAs and proxies, as the 
> > > edge proxy needs to convert P-Preferred to P-Asserted. I have a 
> > > number of questions:
> > > 
> > > happens. Does it take the first two, throw them all away, or work 
> > > its way through them until it finds two it understands. 
> What should 
> > > we specify for the updated-pai implementation to make it 
> choose the 
> > > most sensible option.
> > > 
> > > implementations do with it). If current implementations just miss 
> > > off the URI scheme and render the remainder, I suspect we are in 
> > > trouble. Do they work through all headers until they find 
> one they 
> > > can work with. Do they fail to understand the first and 
> then ignore 
> > > the remainder.
> > > 
> > > Answers to both these questions may mean it inappropriate 
> to change 
> > > the current rules, that new headers are invented for other URI 
> > > schemes, or that we may need to specify ordering rules on what we 
> > > specify to appear first of any set of URI schemes. At the 
> moment I 
> > > do not know what the answer will be.
> > > 
> > > Regards
> > > 
> > > Keith
> > >

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 18 Jul 2008 14:31:13 -0400

Oh, I don't know, I think maybe a new header is in order.

'Asserted-Identity' perhaps?

Brian

> Of Francois Audet
> Sent: Friday, July 18, 2008 1:55 PM
> Cc: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat); [email-masked];
> Gonzalo Camarillo; Mary Barnes
> Subject: Re: [Sipping] Reminder: WGLC: draft-ietf-sipping-update-pai-04 --
> -EndsFriday!
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Fri, 18 Jul 2008 14:51:02 -0400

I do not know if a new header is the solution. To interop with RFC 3325
implementations and new implementation, a UA will have to add
P-Asserted-Identity header as well as new one for the same information.

Sanjay

>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Friday, July 18, 2008 2:31 PM
>To: 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Ted Hardie'; 
>Jonathan Rosenberg (jdrosen); 'Elwell, John'
>[email-masked]; 'Gonzalo Camarillo'; 'Mary Barnes'
>draft-ietf-sipping-update-pai-04 ---EndsFriday!
>
>> Behalf Of Francois Audet
>> draft-ietf-sipping-update-pai-04 -- -EndsFriday!
>> 
>> So RFC 3325 is another example of why being overly restrictive is a 
>> bad idea then.
>> 
>> I'd really like to avoid a new header... I mean, we are already at a 
>> point of mind-bogling complexity.
>> 
>> For example, by mandating that the first P-AI be of the types that 
>> were allowed in 3325. (Hopefully that will work).
>> 
>> > To: Audet, Francois (SC100:3055); Ted Hardie; Jonathan Rosenberg; 
>> > Elwell, John
>> > We MUST cater for existing RFC 3325 implementations, and what they 
>> > currently do on receipt, in any enhancement we make to 
>this header. 
>> > We cannot write new requirements in update-pai for those 
>> > implementations, and yet they must still be able to do something 
>> > sensible with what they receive.
>> >
>> > > What I would like to avoid is a situation where seeing a P-AI of 
>> > > an unrecognized scheme (unrecognized scheme in the 
>context of P-AI 
>> > > of
>existing 
>> > > > happens. Does it take the first two, throw them all away, or 
>> > > > work its way through them until it finds two it understands.
>> > What should
>> > > > implementations do with it). If current implementations just 
>> > > > miss off the URI scheme and render the remainder, I suspect we 
>> > > > are in trouble. Do they work through all headers until 
>they find
>> > one they
>> > > > schemes, or that we may need to specify ordering rules on what 
>> > > > we specify to appear first of any set of URI schemes. At the
>> > moment I
>> > > > > >> >> [JRE] Which, the number of schemes or the 
>number of URIs
>> > > > > >> or both? I
>> > > > > >> >> I think there is more consensus to increase the number 
>> > > > > >> >> of
>> > > > > >> URIs (i.e.,

---

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

Right! And then we can deprecate RFC3325 and progress update-pai on 
standards track as its replacement ;)

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 Jul 2008 14:03:26 -0500

Exactly. 

> Sent: Friday, July 18, 2008 11:51
> To: Brian Rosen; Audet, Francois (SC100:3055); DRAGE, Keith 
> (Keith); Ted Hardie; Jonathan Rosenberg (jdrosen); Elwell, John
> Cc: Paul Kyzivat (pkyzivat); [email-masked]; Gonzalo 
> Camarillo; Barnes, Mary (RICH2:AR00)
> I do not know if a new header is the solution. To interop 
> with RFC 3325 implementations and new implementation, a UA 
> will have to add P-Asserted-Identity header as well as new 
> one for the same information.
> 
> Sanjay
> 
> >To: 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Ted Hardie'; Jonathan 
> >Rosenberg (jdrosen); 'Elwell, John'
> [mailto:[email-masked]] On 
> >> Behalf Of Francois Audet
> Rosenberg; 
> 2. to allow
> >> > > > > >> >sensible as user identities. and give examples 
> of things
> >> > > > > that make

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jul 2008 16:47:19 -0400

This is a good point, Keith. I agree with Francois its arguably a 
(major) design flaw in rfc3325.

Now, this is one of those things that is a real issue in theory, but in 
practice could be a total non-issue, or could be a big issue.

I think we'd need to understand what happens when:

a. an RFC3325 implementation receives a PAI with more than two URI
b. what happens when one of those URI is not SIP or tel
c. what happens when there are more than one SIP, or more than one tel

so - I'd like to hear from folks who have implementations, what happens 
in the above cases.

-Jonathan R

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 Jul 2008 16:56:56 -0500

> Now, this is one of those things that is a real issue in 
> theory, but in practice could be a total non-issue, or could 
> be a big issue.

Exactly what I was thinking.

> a. an RFC3325 implementation receives a PAI with more than 
> two URI b. what happens when one of those URI is not SIP or 
> tel c. what happens when there are more than one SIP, or more 
> than one tel
> 
> so - I'd like to hear from folks who have implementations, 
> what happens in the above cases.

You are going exactly where I wanted us to go.

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 20 Jul 2008 12:16:12 +0100

Right, so I would really welcome input on points a, b and c.

John 

> Sent: 18 July 2008 22:57
> To: Jonathan Rosenberg; DRAGE, Keith (Keith)
> Cc: Ted Hardie; Elwell, John; Sanjay Sinha (sanjsinh); Paul 
> Kyzivat (pkyzivat); [email-masked]; Gonzalo Camarillo; Mary Barnes

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 20 Jul 2008 17:39:31 +0300

> decided not to relax that restriction?

i don't know what has been decided, but i would like to allow more than
one sip uri in pai header.  even if user has an userid style uri and
an e.164 uri, i would prefer to use sip uri scheme for both.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 20 Jul 2008 21:03:05 -0700

I don't think this draft is at all close to ready for publication. We  
still talking about what we are trying to do much less if this does it  
or not.

This also seems very intertwined with the overall Identity problem - I  
have a hard time understanding how this draft is not about SIP  
security, which may explain why I can't find a milestone for it.

Cullen

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 21 Jul 2008 14:11:08 -0500

I agree.

I think we are still struggling with the comments that were made about 
allowing more than 2 P-AIs, and also allowing schemes that are not sip:, sips:
or tel:.

I believe the group needs to take a step back and look at the likely 
consequences of those two proposals on interoperability. 

So I don't think we are ready, and since the investigation is non-trivial, it
may take some time. 

> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Sunday, July 20, 2008 21:03
> To: sipping
> I don't think this draft is at all close to ready for 
> publication. We still talking about what we are trying to do 
> much less if this does it or not.
> 
> This also seems very intertwined with the overall Identity 
> problem - I have a hard time understanding how this draft is 
> not about SIP security, which may explain why I can't find a 
> milestone for it.
> 
> Cullen
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Jul 2008 14:25:33 -0500

Mary Barnes wrote:
> [...]  If

Mary: I went through the deltas from -01 (which I had reviewed)
with -02 and upto -04.  All the comments I had in the -01
review have been adequately addressed (there has been some change
since -02 and -04; certain comments made in older sections of -02
no longer apply in -04 since those sections appear to have
been deleted as the draft progressed.)

I don't have any further comments on this draft.

Sorry for the delay in getting this out.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
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