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 <john.elwell@xxxxxxxxxxx> 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:mary.barnes@xxxxxxxxxx]
>> 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:
>> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
