Subject: Re: [Sipping] Post-WGLC^3: draft-ietf-sipping-update-pai-07 (allowable URN schemes)

From: "John-Luc Bakker" <[email-masked]>
Date: Thu, 4 Dec 2008 13:16:53 -0600

Folks,

Reacting to point 2:

> 2. We should not specify the sending of service URNs. The syntax already
> allows for them and the draft already says that you have to be tolerant
> of any scheme on receipt. No text change is required for this.

Being tolerant of URN schemes upon receipt suggests to me that within a
particular Spec(T) more or less URN schemes can be allowed. For example, urn
scheme SIPS appears not used in the spec(T) instanciated by 3GPP.

Is it true that it is up to the Spec(T) to determine which URN schemes are
allowed for identification of the authenticated UA? If "yes" then I question
the text in section 4.5 where the RFC 3325 restriction is repeated, only
allowing 3 URI schemes, basta:

>   This document does not change the RFC 3325 requirement that allows
>   each of these header fields to contain at most two URIs, where one is
>   a SIP or SIPS URI and the other is a TEL URI, but future updates to
>   this document may relax that requirement.  In the absence of such a
>   relaxation, the requirement above means that an entity receiving a
>   request containing a P-Asserted-Identity or P-Preferred-Identity
>   header field must act as follows:
>
>   o  ignore any URI with a scheme other than SIP, SIPS or TEL;
>
>   o  ignore a second or subsequent SIP URI, a second or subsequent SIPS
>      URI or a second or subsequent TEL URI; and
>
>   o  ignore a SIP URI if a SIPS URI occurred earlier in the header
>      field and vice versa.

To take account of the case where allowable URN schemes can be determined by
the Spec(T) instance, maybe we can reword the above too:

>   In the absence of a Spec(T) determining otherwise, this document does
not change the RFC 3325 requirement that allows
>   each of these header fields to contain at most two URIs, where one is
>   a SIP or SIPS URI and the other is a TEL URI, but future updates to
>   this document may relax that requirement.  The requirement in RFC
3325 means that an entity receiving a
>   request containing a P-Asserted-Identity or P-Preferred-Identity
>   header field must act as follows:
>
>   o  ignore any URI with a scheme other than SIP, SIPS or TEL;
>
>   o  ignore a second or subsequent SIP URI, a second or subsequent SIPS
>      URI or a second or subsequent TEL URI; and
>
>   o  ignore a SIP URI if a SIPS URI occurred earlier in the header
>      field and vice versa.

Comments? Suggestions?

Regards,

John-Luc

On Wed, Nov 26, 2008 at 1:23 AM, Elwell, John <[email-masked]>
wrote:
> There are a couple of points from the meeting that need confirmation on
> the list.
>
> 1. We should specify that PAI can be inserted in requests for all
> methods except ACK and CANCEL. This is because ACK and CANCEL cannot be
> challenged (similar reasoning for why PAI in responses will not be
> specified in this draft).
>
> My proposed new text in section 2 would be:
> "This document extends RFC 3325 by allowing inclusion of the
> P-Asserted-Identity header field by a UAC in the same Trust Domain as
> the first proxy and allowing use of P-Asserted-Identity and
> P-Preferred-Identity header fields in any request except ACK and CANCEL.
> The reason for these two exceptions is that ACK and CANCEL requests
> cannot be challenged for digest authentication."
>
> Then in 4.1:
> "A UAC MAY include a P-Asserted-Identity header field in a request
> except ACK and CANCEL to report the identity of the user ...."
> And similar changes in 4.2 and 4.4 for proxy and UAS.
>
> 2. We should not specify the sending of service URNs. The syntax already
> allows for them and the draft already says that you have to be tolerant
> of any scheme on receipt. No text change is required for this.
>
> If you have any objections to these conclusions, please shout before the
> deadline given by Mary below (2008-12-15).
>
> John
>
>
>> -----Original Message-----
>> From: Mary Barnes [mailto:[email-masked]]
>> Sent: 25 November 2008 19:30
>> To: sipping
>> Cc: Gonzalo Camarillo; Elwell, John
>> Subject: Post-WGLC^3: draft-ietf-sipping-update-pai-07
>>
>> Hi folks,
>>
>> Based on discussions in SIPPING WG last Friday, it was
>> decided to do a FINAL review of this document before
>> progressing as it seems there are remaining concerns and some
>> folks felt they had not had enough time to review.
>>
>> There are already some good discussions and proposals for
>> modifying the text underway:
>> http://www.ietf.org/mail-archive/web/sipping/current/msg16466.
>> html
>> <http://www.ietf.org/mail-archive/web/sipping/current/msg16466.html>
>>
>> ANYONE that has final comments PLEASE provide them no later
>> than December 15th, 2008.
>>
>> That gives folks two working weeks after Thanksgiving (US Holiday).
>>
>> Depending upon the amount of changed text, we may do a very
>> short (one week) review prior to progressing.
>>
>> Regards,
>> Mary.
>> SIPPING WG co-chair
>>
>>
> _______________________________________________
> 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: "Elwell, John" <[email-masked]>
Date: Fri, 12 Dec 2008 09:30:13 +0000

I have heard no objections to this proposal from John-Luc.
 
John

________________________________

	From: John-Luc Bakker [mailto:[email-masked]] 
	Sent: 04 December 2008 19:17
	To: sipping
	Cc: Gonzalo Camarillo; Mary Barnes; Elwell, John
	Subject: Re: [Sipping] Post-WGLC^3:
draft-ietf-sipping-update-pai-07 (allowable URN schemes)

	Folks,

	> of any scheme on receipt. No text change is required for this.
	 
	Being tolerant of URN schemes upon receipt suggests to me that
within a particular Spec(T) more or less URN schemes can be allowed. For
example, urn scheme SIPS appears not used in the spec(T) instanciated by
3GPP.
	 
	Is it true that it is up to the Spec(T) to determine which URN
schemes are allowed for identification of the authenticated UA? If "yes"
then I question the text in section 4.5 where the RFC 3325 restriction
	 
	>   o  ignore a SIP URI if a SIPS URI occurred earlier in the
header
	 
	To take account of the case where allowable URN schemes can be
determined by the Spec(T) instance, maybe we can reword the above too:
	 
	>   In the absence of a Spec(T) determining otherwise, this
document does not change the RFC 3325 requirement that allows
	>   this document may relax that requirement.  The requirement
in RFC 3325 means that an entity receiving a
	 
	Comments? Suggestions?
	 
	Regards,
	 
	John-Luc
	 
	> Sipping mailing list
https://www.ietf.org/mailman/listinfo/sipping