Subject: [Sipping] draft-ietf-sipping-update-pai-03

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jun 2008 16:36:23 +0100

This is now available.
http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-pai-03.txt

The various changes are all to do with allowing PAI/PPI in any request,
as discussed on the list in recent weeks.

>From my point of view it is ready for WGLC.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jun 2008 12:19:19 -0400

Looking good.

I think there is a problem in 4.1.1. The two paragraphs appear 
redundant, as if a new one was added and the old one not removed.

Section 4.2.2 says:

    If a proxy receives a response
    from a UAS within the Trust Domain it MUST behave as for a response
    from any other node within the Trust Domain, in accordance with the
    rules of RFC 3325 for a proxy.

In general the recipient of the request cannot know if the source was a 
UAS or a proxy. So I can't figure out what this means. I guess it could 
be reworded as:

    If a proxy receives a response
    from a node within the Trust Domain it MUST behave as for a response
    from any other node within the Trust Domain, in accordance with the
    rules of RFC 3325 for a proxy.

But that is a tautology, so there is no point in saying it at all. What 
am I missing here?

Section 4.3 says:

    If a registrar receives a REGISTER request containing a P-Asserted-
    Identity header field, it MUST disregard the asserted identity unless
    received over a secure transport from a proxy within the Trust
    Domain.  Otherwise it MAY use this as evidence that the registering
    UA has been authenticated as representing the identity asserted in
    the header field.

Similar to above, the registrar can't tell if it is receiving this from 
a UAC or a proxy, and shouldn't need to care. So this could be worded as:

    If a registrar receives a REGISTER request containing a P-Asserted-
    Identity header field, it MUST disregard the asserted identity unless
    received over a secure transport from a *node* within the Trust
    Domain.  Otherwise it MAY use this as evidence that the registering
    UA has been authenticated as representing the identity asserted in
    the header field.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jun 2008 20:50:54 +0100

Paul,

Thanks for your swift read and comments. See below. 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 26 June 2008 17:19
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] draft-ietf-sipping-update-pai-03
> 
> Looking good.
> 
[JRE] In fact the first paragraph and the first sentence of the second
paragraph should stand - they say different things. The final sentence
is duplication and can be deleted.

> UAS or a proxy. So I can't figure out what this means. 
[JRE] True

> I 
> guess it could 
[JRE] I guess the offending sentence can just be deleted. It might also
be worth adding instead (after the note): "<t>The proxy behaviour
specified in RFC 3325 applies for handling a P-Asserted-Identity header
field in a response from a node within the Trust Domain.</t>"

>     UA has been authenticated as representing the identity asserted in
[JRE] Agreed.
I will hold back for a few days in anticipation of further comments
before submitting 04.

John