Subject: Re: [Sipping] Initial WG review: draft-ietf-update-pai-01

From: Dan York <[email-masked]>
Date: Fri, 2 May 2008 06:03:46 -0400

+1

The many folks out there *implementing* SIP don't understand the inner  
workings of the IETF and our various processes and so if a developer  
has a requirement given to him/her from product management to  
implement PAI, he/she is going to go out, find RFC 3325 and go ahead.  
In most cases I will bet the developer will NOT look to see if we have  
issued "update" documents.

So IMHO we need to keep it as *simple* as possible and I agree with  
folks that we should come out with a single new document that  
obsoletes the old one. This *should* make it more likely to actually  
get these updates out in actual usage. (Although a certain % of  
developers will still pull up RFC 3325 and ignore the fact that its  
marked "obsoleted" and implement it anyway.)

My 2 cents,
Dan

On Apr 28, 2008, at 6:49 AM, Spencer Dawkins wrote:

> Hi, John,
>
>
>>> Procedural issue:
>>>
>>> - This document does an excellent job at explaining how to
>>> clarify and expand RFC 3325.
>>>  However, why don't we just obsolete RFC 3325 entirely and
>>> replace it with a document
>>>  that has everything self-contained (i.e., rfc3325-bis)? I
>>> think it would be much
>>>  easier for developppers.
>
>> [JRE] I agree, but that is a decision for the WG to make.
>
> Yes, that's appropriate to punt to the working group.
>
>> It would also
>> involve a lot more drafting work. Any other opinions?
>
> I can rant in Dublin about the reasons why I think we often update  
> documents
> by writing other documents, instead of reissuing the base document  
> plus
> updates/clarifications as a single new document, but the high-order  
> bit is
> that I think it's a mistake to increase our document count when we  
> have an
> opportunity to obsolete a previous version and issue a new version.
>
> We may end up with a hitchhiker's guide that has 500 references, but  
> that's
> not a goal.
>
> ;-)
>
> I would like to see a new self-contained document, as Francois  
> suggested.
> I'm not the editor, so I should ask for more detail about "a lot more
> drafting work" - is this just editorial work, folding current text  
> into the
> previous document, or are you thinking that most of the text in the  
> previous
> document would be touched?
>
> Thanks,
>
> Spencer
>
>
> _______________________________________________
> 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

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

_______________________________________________
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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 2 May 2008 12:45:56 +0200

My concern here is that if we are not careful, this turns into a rewrite
and reissue of RFC 3325, which:

-	will take months if not years to complete.
-	will lose the key changes from RFC 3325 so the majority of the
world that has already implemented RFC 3325 will not know what the
updates are.

Therefore, while I don't object to a single complete text that replaces
the existing RFC, I would prefer that:

-	we do not modify the existing text except to add the new
"features" or to correct known errors. Additionally we keep the existing
structure of the document intact so people are able to do a compare
using standard tools of the two texts. This should not be a wordsmithing
exercise.

-	we clearly list the scope of the enhancements in an annex (and
therefore informative), possibly with reference back to the main text to
identify the changes to support that enhancement.

-	that we don't treat this as an improvement exercise to add all
the new features that might be possible. We should concentrate on known
shortcomings, and given the amount of deployment experience in the field
on RFC 3325, people should be able to point to those shortcomings with
real experience! 

-	we remember that we are working within the scope of a trust
domain and accept its limitations on the field of applicability, and do
not try and develop new capabilities merely to mimic RFC 4474. New
capabilities should show a benefit of network authentication of the
identity, and not just assume that it is another identity header that
needs all the capabilities of the other ones (e.g. From), which after
all can coexist.

-	we freeze the list of new capabilities before we write them into
the existing RFC 3325 text to prevent people inventing new capabilities
on the fly in WGLC last call (assuming we have one - given that this is
a P-header!)

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan York
> Sent: Friday, May 02, 2008 11:04 AM
> To: Spencer Dawkins
> Cc: [email-masked]
> Subject: Re: [Sipping] Initial WG review: draft-ietf-update-pai-01
> 
> +1
> 
> The many folks out there *implementing* SIP don't understand 
> the inner workings of the IETF and our various processes and 
> so if a developer has a requirement given to him/her from 
> product management to implement PAI, he/she is going to go 
> out, find RFC 3325 and go ahead.  
> In most cases I will bet the developer will NOT look to see 
> if we have issued "update" documents.
> 
> So IMHO we need to keep it as *simple* as possible and I 
> agree with folks that we should come out with a single new 
> document that obsoletes the old one. This *should* make it 
> more likely to actually get these updates out in actual 
> usage. (Although a certain % of developers will still pull up 
> RFC 3325 and ignore the fact that its marked "obsoleted" and 
> implement it anyway.)
> 
> My 2 cents,
> Dan
> 
> >>> - This document does an excellent job at explaining how 
> to clarify 
> >>> and expand RFC 3325.
> >>>  However, why don't we just obsolete RFC 3325 entirely 
> and replace 
> >>> it with a document  that has everything self-contained (i.e., 
> >>> rfc3325-bis)? I think it would be much  easier for developppers.
> >
> > documents by writing other documents, instead of reissuing the base 
> > document plus updates/clarifications as a single new 
> document, but the 
> > high-order bit is that I think it's a mistake to increase 
> our document 
> > count when we have an opportunity to obsolete a previous 
> version and 
> > issue a new version.
> >
> > that's not a goal.
> > into the previous document, or are you thinking that most 
> of the text 
> > in the previous document would be touched?
> >
> > Thanks,
> >
> > Spencer
> >
> >
> > 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
> 
> --
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 02 May 2008 13:26:32 +0100

On that basis, we would need to start by getting the requirements
agreed. Here is the list of known requirements from my perspective:

1. Allow PAI/PPI with certain additional methods (namely UPDATE,
REGISTER, MESSAGE and PUBLISH)
2. Allow PAI to be inserted by a trusted UA
3. Allow PAI in responses, subject to some form of authentication
4. Allow PPI in corresponding situations, where appropriate
5. Allow PAI in ACK requests
6. Allow more than 2 identities to be asserted in a single message
7. Allow additional URI schemes

Items 1 to 4 should not require discussion, as they are already in the
present update draft. Items 5 to 7 have been discussed on the list
recently, but I am not sure we have reached consensus. There certainly
seems to be interest in 6.

John

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 02 May 2008 11:46
> To: Dan York; Spencer Dawkins
> Cc: [email-masked]
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 06 May 2008 20:08:29 +0300

Hi,

per our charter, the WG has committed itself to work on the reduced 
scope of updating RFC 3325. I believe we have enough interest and energy 
to finish this in a reasonable time frame. If we increase the scope of 
this effort at this point, it may end up taking much longer. My 
preference would be to finish the document with the reduced scope as 
agreed and if when we are done we have interest and energy left, think 
of tackling the larger problem.

Cheers,

Gonzalo

Hadriel Kaplan wrote:
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Elwell, John
>>
>> There is a separate thread going on about whether to replace rather than
>> update RFC 3325, and in so doing we could also try to fix the definition
>> of Trust Domain, write procedure in terms of source and consumer of an
>> assertion (rather than a UA or proxy), etc.. While we are just updating
>> RFC 3325 to add a few more methods, allow assertions in responses, etc.,
>> I would prefer not to do more than is necessary.
> 
> Besides the obvious extra work for you or another editor - how long would doing a full 3325bis delay the timeline for getting this done, in terms of process?
> 
> I think a 3325bis is reasonable, especially if you incorporate Jonathan's suggestion for no limit on SIP/SIPS/TEL URI numbers. (which I like the idea of, but seems a more general "let's fix 3325" to me than just this "update the methods" draft)
> 
> But I wouldn't personally want your update draft to be held up much, to really do a 3325bis; and I don't think it's fair to ask it if all you scoped to change was the method list.
> 
> -hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 10:41:47 +0100

I didn't really sense any consensus on this thread. I think there are
two sub-issues: allowing additional instances of tel/sip/sips URIs and
allowing additional URI schemes.

Concerning additional instances of tel/sip/sips URIs, it seems we have
three basic options:
1. Do nothing (i.e., the existing limitation of one tel URI and/or one
sip or sips URI remains).
2. Allow multiple tel/sip/sips URIs and be specific about what
particular combinations are allowed and how they inter-relate.
3. Allow multiple tel/sip/sips URIs but not state any restrictions.

IMO, the problem with option 2 is that it gets into another discussion
(discussed at length on the SIP list recently in the context of RFC
4474) about schemes and formats for number-based URIs. Whilst I think
there is work to be done there (independently of the RFC 4474 issue), I
don't think it is something we should tackle as part of the update-pai
draft.

I tend to prefer option 3, since that would open it up so that any
future work in SIP or SIPPING on schemes and formats for number-based
URIs could exploit PAI without requiring a further update to RFC 3325.

Concerning additional URI schemes, again we have three basic options:
A. Do nothing (i.e., the existing limitation to tel/sip/sips remains).
B. Allow particular additional schemes.
C. Allow any scheme.

I don't like option C. As Ted said, some schemes might be totally
unsuitable. Even with option B, there is the issue of how an asserting
entity can perform the necessary authentication, and where we draw the
line between PAI and vcard. Perhaps on a case-by-case basis we could
justify this. However, I lean towards option A.

So my preference would be options 3 and A. Comments?

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 24 April 2008 20:11
> To: DRAGE, Keith (Keith)
> Cc: Elwell, John; Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sipping] draft-ietf-update-pai-01 available
> 
> 
> 
> DRAGE, Keith (Keith) wrote:
> > Well, it is a restriction that is there at the moment. I 
> didn't invent it.
> 
> Well, at the moment it is (one-of-sip/sips)(and/or)(tel)
> 
> There are a variety of ways to relax that. Singling out sip/sips as 
> inviolable seems unjustified to me.
> 
> > But surely if the meaning is that this is where I want this 
> communication to be returned, I should also specify whether I 
> want it secure or unsecure, and not imply that I don't care.
> 
> I may not care *much*. I may be more concerned that the recipient get 
> something it can use.
> 
> Also, this is at least as much about identity as about return 
> routability. Does it matter for identity?
> 
> > Further multiple values are alias. Are you implying that a 
> SIP: URI can be an alias for a SIPS: URI? (whatever alias 
> means I don't think it encompasses that.
> 
> AFAIK we don't have a definition for Alias.
> For purposes of identity it doesn't matter (IMO).
> Even for purposes of return routability I think these could in some 
> cases be acceptable aliases.
> 
> 	Paul
> 
> > Keith 
> > 
> >> From: Paul Kyzivat [mailto:[email-masked]] 
> >> Sent: Thursday, April 24, 2008 7:17 PM
> >> To: DRAGE, Keith (Keith)
> >> Cc: Elwell, John; Jonathan Rosenberg; [email-masked]
> >> Subject: Re: [Sipping] draft-ietf-update-pai-01 available
> >>
> >> I don't understand why you want to forbid including both 
> sip and sips.
> >>
> >> It might not make sense if they were otherwise identical, but 
> >> when they aren't it certainly makes sense to allow either or 
> >> both. E.g.
> >>
> >> 	PAI: sips:[email-masked],
> >>            sip:[email-masked];user=phone
> >>
> >> Paul
> >>
> >> DRAGE, Keith (Keith) wrote:
> >>> I don't have a problem with this, but suggest that we keep the 
> >>> existing limitation to SIP:, SIPS: and tel: (we do not want 
> >> to start 
> >>> adding im:,
> >>> pres: etc. 
> >>>
> >>> Not sure whether John is suggesting including or 
> excluding the SIP:
> >>> representation of a tel: URI. My view would be to exclude, 
> >> except as 
> >>> the only SIP URI. The alias is there to interwork with the PSTN.
> >>>
> >>> The current restriction also prevents a SIP: and a SIPS: 
> both being 
> >>> used. I assume here we should continue to have one or the 
> >> other, but 
> >>> not both.
> >>>
> >>> In other words we could validly have the following combinations:
> >>>
> >>> SIP:...
> >>> Tel:...
> >>> Tel:... Tel:...
> >>> SIP:... Tel:...
> >>> SIP:... Tel:... Tel:....
> >>> SIP:...;user=phone Tel:...
> >>> SIP:...;user=phone Tel:... Tel:...
> >>> SIPS:... Tel:...
> >>> SIPS:... Tel:... Tel:....
> >>>
> >>> Further I would suggest something informative stating that 
> >> there is no 
> >>> requirement for one entity to include all the alias, i.e. a first 
> >>> proxy could add alias1 and a second proxy could add alias2. This 
> >>> depends on how the enterprise has configured its numbering 
> >> plans, and 
> >>> which entity maps from one to the other.
> >>>
> >>> Regards
> >>>
> >>> Keith
> >>>
> >>>> [mailto:[email-masked]] On Behalf Of Elwell, John
> >>>> Sent: Thursday, April 24, 2008 6:07 PM
> >>>> To: Jonathan Rosenberg
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [Sipping] draft-ietf-update-pai-01 available
> >>>>
> >>>> Jonathan,
> >>>>
> >>>> I think this is a good proposal. I don't think we should 
> >> be specific 
> >>>> about how these different forms are represented, e.g., 2 
> >> TEL URIs for 
> >>>> the 2 number formats, plus 1 SIP URI for the email-style.
> >>>>
> >>>> John
> >>>>
> >>>>> [mailto:[email-masked]] On Behalf Of Jonathan 
> Rosenberg
> >>>>> Sent: 24 April 2008 17:16
> >>>>> To: Elwell, John
> >>>>> Cc: [email-masked]
> >>>>> Subject: Re: [Sipping] draft-ietf-update-pai-01 available
> >>>>>
> >>>>> Here is another big limitation in RFC 3325 I think we
> >>>> should address.
> >>>>> RFC3325 says:
> >>>>>
> >>>>>  >  If there is no P-Asserted-Identity header field
> >>>> present, a proxy
> >>>>> MAY
> >>>>>  >    add one containing at most one SIP or SIPS URI, and at 
> >>>>> most one tel
> >>>>>  >    URL.
> >>>>>
> >>>>> For the initial IMS deployments envisioned for this, it was a 
> >>>>> reasonable limitation. You had a phone number and an 
> email-style 
> >>>>> identifier, and thats it.
> >>>>>
> >>>>> We are now seeing much broader deployment of 3325, and this
> >>>> limitation
> >>>>> is a problem. In enterprise, for example, there are often three 
> >>>>> identifiers for a user and sometimes more than that. The 
> >> three are:
> >>>>> 1. their 8 digit (or whatever it is) extension, 2. their
> >>>> DID 3. their
> >>>>> user@domain identifier
> >>>>>
> >>>>> and it would sure be nice to be able to assert all three. 
> >> But now I 
> >>>>> can only assert two of them.
> >>>>>
> >>>>> I'd suggest relaxing this limitation, and allowing any
> >>>> number of URI
> >>>>> of any format for a user. For backwards compatibility, we can 
> >>>>> recommend that if a user has only an e164 and a user@domain
> >>>> identifier
> >>>>> they use one tel and one sip URI respectively.
> >>>>>
> >>>>> Thanks,
> >>>>> Jonathan R.
> >>>>>
> >>>>> Elwell, John wrote:
> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-
> >>>>> pai-01.txt
> >>>>>> The only changes are to delete the open issues and add
> >>>>> support for PAI
> >>>>>> in a REGISTER request. This is in accordance with consensus
> >>>>> on the open
> >>>>>> issues in Philadelphia and subsequent verification on 
> >> the list (I 
> >>>>>> received no objections).
> >>>>>>
> >>>>>> All open issues are now closed, and as far as I am
> >>>>> concerned it is ready
> >>>>>> for review.
> >>>>>>
> >>>>>> John
> >>>>> 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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 11:16:21 +0100

I did not receive any further input on this topic. Since I didn't hear
any objections I will include this in the next draft.

John 

> [mailto:[email-masked]] On Behalf Of Stach, Thomas
> Sent: 25 April 2008 19:27
> To: Elwell, John; DRAGE, Keith (Keith); [email-masked]
> Subject: Re: [Sipping] draft-ietf-update-pai-01 available - PAI in ACK
> 
> John,
> 
> yes, that my motivation.
> I think this is the flow that is used by a vast majority.
> Basically, the 3PCC controller could relay a PAI received in 
> the 200 OK
> of the 2nd SIP leg in the ACK of the 1st SIP leg.
> 
> Regards
> Thomas
> 
> > From: Elwell, John 
> > Sent: Friday, April 25, 2008 12:46 PM
> > To: Stach, Thomas; 'DRAGE, Keith (Keith)'; [email-masked]'
> > Subject: RE: [Sipping] draft-ietf-update-pai-01 available - 
> PAI in ACK
> > 
> > Thomas,
> > 
> > I would guess what you have in mind is Flow I in RFC 3725. 
> > The PAI in the 200 OK from B would be put into the ACK sent 
> > to A. This would save an additional UPDATE transaction.
> > 
> > John
> > 
> > > From: Stach, Thomas 
> > > Sent: 25 April 2008 14:23
> > > To: DRAGE, Keith (Keith); [email-masked]; Elwell, John
> > > Subject: RE: [Sipping] draft-ietf-update-pai-01 available - 
> > PAI in ACK
> > > 
> > > Keith,
> > > 
> > > the draft says in 3.6
> > > 
> > >    It should also be permissible for a UAS to insert a P-Asserted-
> > >    Identity header field into a response if it is within the 
> > > same Trust
> > >    Domain as the proxy from which the request was 
> received (the last
> > >    proxy).
> > > 
> > > If we allowed the PAI in responses under this circumstances, 
> > > I think it should be allowed in ACK under the same restrictions.
> > > We could just save the additional UPDATE cycle under this 
> > > circumstances.
> > > 
> > > Regards
> > > Thomas
> > > 
> > > 
> > > > Sent: Friday, April 25, 2008 9:12 AM
> > > > To: Stach, Thomas; [email-masked]; Elwell, John
> > > > Subject: Re: [Sipping] draft-ietf-update-pai-01 available - 
> > > PAI in ACK
> > > > 
> > > > Can you clarify why the problems identified in your mail are 
> > > > not met by
> > > > a subsequent exchange of the UPDATE method (or reINVITE if 
> > > > appropriate).
> > > > Extension to UPDATE was one of the main reasons for 
> > > updating RFC 3325
> > > > with this draft.
> > > > 
> > > > Regards
> > > > 
> > > > Keith
> > > > 
> > > > > [mailto:[email-masked]] On Behalf Of Stach, Thomas
> > > > > Sent: Friday, April 25, 2008 1:32 PM
> > > > > To: [email-masked]; Elwell, John
> > > > > Subject: [Sipping] draft-ietf-update-pai-01 available - 
> > PAI in ACK
> > > > > 
> > > > > John,
> > > > > 
> > > > > RFC 3325 does not allow PAI in ACK. 
> > > > > However, as your update goes to allow PAI in responses, it 
> > > > > would be worthwhile to allow PAI in the ACK as well.
> > > > > This would be particularly useful for 3PCC scenarios.
> > > > > Here, the PAI might not be known when the INVITE is sent or 
> > > > > it may change e.g. due to call forwarding during 3PCC call 
> > > > > establishment
> > > > > 
> > > > > Regards
> > > > > Thomas

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 12 May 2008 13:11:41 +0200

John,

Wouldn't the same reasoning apply to PRACK? (i.e. potentially useful in 
3PCC cases when combined with 100rel)

And what about INFO, given recent discussions (e.g. 
http://tools.ietf.org/id/draft-rosenberg-sip-info-litmus-00.txt)

Regards,
Jeroen

Elwell, John wrote:
>>>>> [mailto:[email-masked]] On Behalf Of DRAGE, 
>>>>>           
>>> Keith (Keith)
>>>       
>>>>> Use [email-masked] for questions on 
>>>>>           
>> current sip
>>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 12 May 2008 12:55:06 +0200

John,

We have already encountered situations where the ambiguity of RFC3325 
w.r.t. multiple PAI headers lead to interop issues. Specifically, a 
particular implementation inserted 2 PAI headers: a sip: URI for the 
user (in the form of a telephone number), and a tel: URI containing a 
group number (i.e. there is a notion of a "group" to which the user 
belongs). Consequently, the PSTN gateway would assert the wrong A number

RFC3325 is not explicit about this, but my interpretation is that it 
defines the use of 2 PAI headers with sip: and tel: URIs specifically 
for interworking with the PSTN:
- for calls originating from a SIP network, PAI would contain a sip: 
URI, and the network would add an associated telephone number (tel: URI) 
in case the calls goes through a PSTN gateway (which would use the tel: 
URI as the calling party number)
- for calls originating from the PSTN network, the PSTN gateway would 
insert a PAI with a tel: URI, and the SIP network would add an 
associated sip: identity (if possible/necessary)

If my interpretation is correct, I don't see a use case for allowing 
even more identities in PAI headers. I can imagine a case where an im: 
scheme would be used for a MESSAGE request, but I don't see the value of 
using "im:" instead of "sip:" in that case. This would only lead to 
further confusion and more interop issues. Instead, I would argue that 
we should clarify the intention/reason behind RFC3325's 2 PAI headers 
with sip:/tel: URIs  in your draft (e.g. describe the use cases / call 
flows the authors had in mind).

As it currently stands, people don't understand the reasoning behind the 
restrictions, and hence don't consider it necessary to adhere to them

Regards,
Jeroen

Elwell, John wrote:
>>>>>>>> [email-masked] for questions on 
>>>>>>>>                 
>>>> current sip Use 
>>>>         
>>>>>>> [email-masked] for questions on 
>>>>>>>               
>> current sip Use 
>>     
>>>>>> [email-masked] for questions on 
>>>>>>             
>> current sip Use 
>>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 13:19:38 +0100

Jeroen, 

> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: 12 May 2008 12:12
> To: Elwell, John
> Cc: Stach, Thomas; DRAGE, Keith (Keith); [email-masked]
[JRE] Yes, there is probably an equal argument for PRACK as for ACK.

> http://tools.ietf.org/id/draft-rosenberg-sip-info-litmus-00.txt)
[JRE] I am not aware of a use case for PAI in INFO. For all the other
methods we have included in the draft we described particular use cases
that lend justification.

> - PAI in ACK

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 May 2008 09:36:31 -0400

John,

Good summary of the issues. I agree with your analysis, and am ok with 3 
and any of A/B/C.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 May 2008 09:42:31 -0400

Jeroen,

What you describe is consistent with the URIs being aliases, where each 
element is allowed to use whichever one it wishes. The only problem, if 
it is a problem, is your use case where one is a private number and one 
is a group number. It is only a problem if the entity inserting those 
didn't intend them to be used as aliases.

	Paul

Jeroen van Bemmel wrote:
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: 24 April 2008 20:11
>>> To: DRAGE, Keith (Keith)
>>> communication to be returned, I should also specify whether I want it 
>>> secure or unsecure, and not imply that I don't care.
>>>
>>> SIP: URI can be an alias for a SIPS: URI? (whatever alias means I 
>>> don't think it encompasses that.
>>>
>>>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Thursday, 
>>>>> April 24, 2008 7:17 PM
>>>>> To: DRAGE, Keith (Keith)
>>>>> It might not make sense if they were otherwise identical, but when 
>>>>> they aren't it certainly makes sense to allow either or both. E.g.
>>>>>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 12 May 2008 17:00:47 +0200

Paul,

My description of the use case is inaccurate and incomplete ( if I 
recall correctly there was something with CLIP restriction, the 
intention was that the PSTN gateway would use the group number as A 
number) but that is besides the point. My point is that the way things 
are currently defined, there is already too much room for different 
interpretations, leading to interop issues.

It is nowhere defined that the 2 PAI URIs need to be aliases, I'm 
arguing that we should add something along these lines to the update-pai 
draft (e.g. that they MUST be (or at least are assumed to be) aliases)

Regards,
Jeroen

Paul Kyzivat wrote:
> Jeroen,
>
> What you describe is consistent with the URIs being aliases, where 
> each element is allowed to use whichever one it wishes. The only 
> problem, if it is a problem, is your use case where one is a private 
> number and one is a group number. It is only a problem if the entity 
> inserting those didn't intend them to be used as aliases.
>
>     Paul
>
> Jeroen van Bemmel wrote:
>> John,
>>
>> URI, and the network would add an associated telephone number (tel: 
>> URI) in case the calls goes through a PSTN gateway (which would use 
>> the tel: URI as the calling party number)
>> even more identities in PAI headers. I can imagine a case where an 
>> im: scheme would be used for a MESSAGE request, but I don't see the 
>> value of using "im:" instead of "sip:" in that case. This would only 
>> lead to further confusion and more interop issues. Instead, I would 
>> argue that we should clarify the intention/reason behind RFC3325's 2 
>> PAI headers with sip:/tel: URIs  in your draft (e.g. describe the use 
>> cases / call flows the authors had in mind).
>>
>> As it currently stands, people don't understand the reasoning behind 
>> the restrictions, and hence don't consider it necessary to adhere to 
>> them
>>
>> Regards,
>> Jeroen
>>
>> Elwell, John wrote:
>>>> communication to be returned, I should also specify whether I want 
>>>> it secure or unsecure, and not imply that I don't care.
>>>>
>>>> I may not care *much*. I may be more concerned that the recipient 
>>>> get something it can use.
>>>>
>>>>>>> requirement for one entity to include all the alias, i.e. a 
>>>>>>> first proxy could add alias1 and a second proxy could add 
>>>>>>> alias2. This depends on how the enterprise has configured its 
>>>>>>> numbering           
>>>>>> plans, and       
>>>>>>>>> is a problem. In enterprise, for example, there are often 
>>>>>>>>> three identifiers for a user and sometimes more than that. The 
>>>>>>>>>               
>>>>>> three are:
>>>>>>       
>>>>>>> [email-masked] for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 May 2008 16:55:30 +0100

Jeroen,

On further consideration, I don't think there is an equal argument for
PAI in PRACK. The rationale for PAI in ACK was that it would be useful
in Flow I of RFC 3725. PRACK does not feature in that flow, and even if
PRACK were used, I doubt there would be a possibility to include PAI in
the same way that ACK could include it.

John 

> Sent: 12 May 2008 13:20
> To: 'Jeroen van Bemmel'
> Subject: RE: [Sipping] draft-ietf-update-pai-01 available - PAI in ACK
> 
> Jeroen, 
> 
> [JRE] I am not aware of a use case for PAI in INFO. For all 
> the other methods we have included in the draft we described 
> particular use cases that lend justification.
> 
> > 
> > Regards,
> > Jeroen
> > 
> > Elwell, John wrote:

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 16 May 2008 12:28:47 -0700

John,

I don't see any point in restricting which requests can carry PAI. RFC 
3325 had restrictions and it turned out to be a bad idea. What's the 
downside to basically just allowing it everywhere?

Thanks,
Anders

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 May 2008 16:01:14 -0400

> Of Anders Kristensen

+1 - just because we can't think of a use-case now doesn't mean someone won't someday.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 May 2008 17:39:34 -0400

I had also suggested this earlier, and was shot down for some reason I 
can't recall.

There seems to be a long history of this sort of thing with P-headers. 
(Not including extensibility mechanisms such as generic-param in headers 
comes to mind.)

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 May 2008 08:02:56 +0100

Paul,

Yes, I found you suggested this back in October 2006, and my response at
the time was that I thought we ought to have use cases to justify any
additions. That was not so much a strong opinion on my part, but rather
my assessment of how we do things in SIP/SIPPING. I would be quite happy
to relax it to cover any request (and any response), if this is what the
WG desires. Other opinions?

John

> Sent: 16 May 2008 22:40
> To: Hadriel Kaplan
> Cc: Anders Kristensen; Elwell, John; [email-masked]; Stach, 
> Thomas; DRAGE, Keith (Keith)
> [mailto:[email-masked]] On Behalf
> >> Of Anders Kristensen
> >>

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 19 May 2008 13:56:03 -0400

> I would be quite happy to relax it to cover any 
> request (and any response), if this is what 
> the WG desires. Other opinions?

In general the more locations that content updates are allowed, the
higher potential for race conditions, ambiguities, and interoperability
problems.  However since PAI is hopefully a header which doesn't change
much within a dialog, I don't have a strong opinion concerning the
topic.  

Unfortunately one of the problems with UPDATE, re-INVITE, etcetera is
that it is not always clear what is trying to be updated and what was
successfully updated.  Allowing things to be updated by responses and
additional requests just adds to the problem and race conditions.

Hopefully nobody is wanting to update a dialog's PAI by 100 and 300-699
responses.  Hopefully nobody is wanting to update PAI by CANCEL, CANCEL
responses, and ACK-for-non-2xx.

For race condition reasons, I prefer PAI processing not be assumed
successful if PAI included within PRACK, PRACK 2xx, or ACK.

-brett