Subject: [Sipping] draft-ietf-update-pai-01 available

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 16:29:04 +0100

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
_______________________________________________
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: Tue, 22 Apr 2008 16:12:42 -0500

Hi all, 

This is to announce an initial WG review for:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-pai-01.txt

The Initial WG Review ends on May 7th, 2008 (Two weeks timeframe).   

We already have two reviewers (Vijay Gurbani and Francois Audet), but
would like at least one more person, so please let us know if you have
an interest in reviewing this document. 

Regards,
Mary
SIPPING WG co-chair

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 23 Apr 2008 07:42:08 +0300

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

why is the header a P header?

if uri in pai header would be the same as uri in from header, why does
the uri need to be written twice?

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 23 Apr 2008 11:14:32 +0100

Juha, 

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: 23 April 2008 05:42
> To: Mary Barnes
> Cc: [email-masked]; Francois Audet; Elwell, John; Gonzalo Camarillo
> Subject: [Sipping] Initial WG review: draft-ietf-update-pai-01
> 
> Mary Barnes writes:
> 
[JRE] For historic reasons. It doesn't seem feasible to change now.

> the uri need to be written twice?
[JRE] The PAI value is asserted by the sender (i.e., the upstream SIP
entity), so within a trust domain the value can presumably be trusted.
Just the From URI would say nothing about whether the sender asserts
correctness.

John

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 23 Apr 2008 18:14:12 +0300

> Just the From URI would say nothing about whether the sender asserts

my point was why to repeat from uri rather than saying that uri in from
header is asserted.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Apr 2008 11:26:06 -0400

It isn't always the URL in the From header that is asserted. It can be 
something else.

(Don't ask why - its IMS.)

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 23 Apr 2008 18:33:17 +0300

> It isn't always the URL in the From header that is asserted. It can be 

sure it can be something else, for example uri in ppi header.  my point
is why to repeat the uri if it exists somewhere in the request rather
than just tell that this or that uri is asserted.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 23 Apr 2008 16:39:00 +0100

Juha,

That is the way it is done in RFC 3325. The present draft just extends
RFC 3325 and does not try to change its basic operation.

John

> Sent: 23 April 2008 16:33
> To: Paul Kyzivat
> Cc: Elwell, John; Francois Audet; [email-masked]; Mary 
> Barnes; Gonzalo Camarillo
> Subject: Re: [Sipping] Initial WG review: draft-ietf-update-pai-01
> 
> Paul Kyzivat writes:
>

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Wed, 23 Apr 2008 17:46:20 +0200

Because the From header is e2e for some reason. It may contain crap or
"alias" information.
A network node might want to assert the real identity of the caller,
therefore it adds the PAI. Of course there are other ways to solve this,
but that is how 3324, 3325 have solved this.

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juha Heinanen
Sent: Wednesday, April 23, 2008 5:33 PM
To: Paul Kyzivat
Cc: [email-masked]; Francois Audet; Elwell,John; Mary Barnes; Gonzalo
Camarillo
Subject: Re: [Sipping] Initial WG review: draft-ietf-update-pai-01

Paul Kyzivat writes:

 > It isn't always the URL in the From header that is asserted. It can
be  > something else.

-- juha
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Wed, 23 Apr 2008 16:12:55 -0500

And I might add that this RFC is widely used. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, April 23, 2008 08:39
> To: Juha Heinanen; Paul Kyzivat
> Cc: Audet, Francois (SC100:3055); [email-masked]; Barnes, 
> Mary (RICH2:AR00); Gonzalo Camarillo
> Subject: RE: [Sipping] Initial WG review: draft-ietf-update-pai-01
> 
> Juha,
> 
> That is the way it is done in RFC 3325. The present draft 
> just extends RFC 3325 and does not try to change its basic operation.
> 
> John
> 
> > Cc: Elwell, John; Francois Audet; [email-masked]; Mary Barnes; 
> > Gonzalo Camarillo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Apr 2008 19:30:17 -0400

I took a look, and have a few comments:

Section 3.1 says:

    This can be
    meaningful if the UAC is in the same Trust Domain as the first proxy.

What is so special about the *first* proxy? And this statement doesn't 
really say whether the UAC is before or after the first proxy. And there 
may be *no* proxy. (Just a bunch of B2BUAs. :-( )

Similarly, section 3.6 says:

    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).

Why shouldn't *any* element on the signaling path within a trust domain 
be allowed to assert the identity if it has some way of determining it?

In any case, its less important to document who is allowed to insert it 
than it is to specify when a recipient should trust the value that was 
inserted. It is presumably adjacency over a trusted connection that 
allows the value to be trusted. Perhaps that is what "first" and "last" 
are trying to get at. IIUC its an unbroken sequence of such trusted 
adjacencies that defines the trust domain.

I will now try to manifest the above comments in the normative text that 
  follows:

Section 4.1.1:

s/first proxy/sip server to which it sends the request,/

(three places).

Section 4.1.2 says:

    However, if a UAC receives a response from a previous element outside
    the Trust Domain, it MUST NOT use the P-Asserted-Identity header
    field in any way.

I think this fails to reflect asymmetry in the trust relationships. In 
particular, a UAC may trust its provider to provide useful assertions of 
identity even though the provider doesn't trust the UAC to provide 
assertions of its own identity. I think that means that the UAC is not 
part of the trust domain, yet the above requirement is seemingly 
inappropriate. I would suggest somthing more like:

    However, if a UAC receives a response from a previous element it
    does not trust, it MUST NOT use the P-Asserted-Identity header
    field in any way.

I realize that may be insufficient because it doesn't specify how this 
form of trust is determined. So it needs more work.

Section 4.4.2:

s/last proxy/sip server from which it received the response,/

Section 6 says:

    When receiving a request or response containing a P-Asserted-Identity
    header field directly from a UA (rather than from another proxy), a
    proxy will trust the UA only if it is known to be within the Trust
    Domain and is connected by means of TLS as specified in RFC 3325.

A proxy (or any sip server) in general has no way to know whether the 
message was received from a UA or a proxy, and so can't base any 
decisions on knowing. I'm uncertain how to fix the above to reflect this.

It goes on to say:

    Domain and is connected by means of TLS as specified in RFC 3325.
    One example where this might be true is a UA that is a PSTN gateway.
    In this case the UA can assert an identity received from the PSTN,
    the proxy itself having no means to authenticate such an identity.  A
    proxy must not trust an identity asserted by a UA outside the Trust
    Domain.

Same issue. I would propose to change the last sentence to:

    A sip server must not trust an identity asserted by a source outside
    the trust domain.

That's all I have.

	Thanks,
	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 24 Apr 2008 08:41:48 +0300

> And I might add that this RFC is widely used. 

yes, i use it too.  it is just plain stupid that a widely used, general
purpose header is a P header and that an RFC specifying it "does not
specify an Internet standard of any kind".  at the same time this gw has
produced countless RFCs that specify standards that no-one has
implemented.  the message that this gw gives to implementers is thus
VERY confusing.

regarding the extension at hand, if proxy adds a PAI header or receives
one from a trusted element upstream and uri in that pai header does not
correspond to a uri in any other header in the request, how can the
proxy indicate to the callee about the asserted identity of a caller if
it needs to remove the pai header.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Apr 2008 12:14:45 +0100

Paul,

Thanks for these comments, which I will try to investigate in more
detail in a few days time. One point, however. RFC 3325 is written only
in terms of procedures for UAs and proxies, not B2BUAs, and I had not
attempted to change that. I would like to hear other opinions about
whether to continue talking about proxies or to change to more general
terminology such as SIP servers.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 24 April 2008 00:30
> To: Mary Barnes

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 24 Apr 2008 14:27:22 +0300

Elwell, John writes:

 > I would like to hear other opinions about

rfc3261 only knows about proxies and user agents.  this draft should not
talk about anything else.  a b2bua or pstn gw is an ua like any other ua.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Apr 2008 07:46:04 -0400

For normative behavior I think it is sufficient to discuss UAs and 
Proxies. B2BUAs are just UAs from this perspective. But for purposes of 
examples, it may be worthwhile to consider B2BUAs.

As I noted in my comments, a recipient of a message cant tell if it came 
from a UA or a Proxy, and must deal with it without knowing.

	Paul

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Thu, 24 Apr 2008 17:53:00 +0200

John,

NOt sure if this was already brought up, but the mandate of TLS seems to
be a step to far:
  In accordance with RFC 3325, nodes within a Trust Domain must be
   connected using TLS with a certain cipher suite, and this principle
   needs to apply to the connection between a UAC and its proxy as part
   of the condition for considering the UAC to be within the same Trust
   Domain.  Normal proxy procedures of RFC 3325 ensure that the header
   field is removed or replaced if the first proxy considers the UAC to
   be outside the Trust Domain.

How the connection is secured should not be a concern of this draft.

RFC3325 does not mandate TLS at all, there is only a sentence in an
example Spect(T).

/Hans Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Thursday, April 24, 2008 1:30 AM
To: Mary Barnes
Cc: Elwell, John; Francois Audet; [email-masked]; Gonzalo Camarillo
Subject: Re: [Sipping] Initial WG review: draft-ietf-update-pai-01

Section 3.1 says:

    This can be
    meaningful if the UAC is in the same Trust Domain as the first
proxy.

Section 4.1.1:

(three places).

Section 4.1.2 says:

    However, if a UAC receives a response from a previous element
outside
    the Trust Domain, it MUST NOT use the P-Asserted-Identity header
    field in any way.

Section 4.4.2:

Section 6 says:

    When receiving a request or response containing a
P-Asserted-Identity
    header field directly from a UA (rather than from another proxy), a
    proxy will trust the UA only if it is known to be within the Trust
    Domain and is connected by means of TLS as specified in RFC 3325.

A proxy (or any sip server) in general has no way to know whether the
message was received from a UA or a proxy, and so can't base any
decisions on knowing. I'm uncertain how to fix the above to reflect
this.

It goes on to say:

    the proxy itself having no means to authenticate such an identity.
A

That's all I have.

	Thanks,
	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Apr 2008 12:16:21 -0400

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.

-- 
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: "Elwell, John" <[email-masked]>
Date: Thu, 24 Apr 2008 18:06:45 +0100

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 

> From: [email-masked] 
> [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
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 24 Apr 2008 19:41:58 +0200

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]
> 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 
> 
> >  >  If there is no P-Asserted-Identity header field 
> present, a proxy 
> > MAY
> > 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.
> > 
> > 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:
> > > 
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Apr 2008 14:15:51 -0400

> limitation to SIP:, SIPS: and tel: (we do not want to start adding im:,

Why? Frankly I've never understood this limitation in the first place. 
Indeed I'd find it quite useful to have:

P-Asserted-Identity: mailto:[email-masked]

no?

> only SIP URI. The alias is there to interwork with the PSTN.

Again I disagree. I don't see the purpose overall of the limitations 
here. Indeed I'd argue that in reality, the sip URI version of phone 
numbers is far more commonplace than the tel URI version.

> used. I assume here we should continue to have one or the other, but not

For the same user@domain, I don't see much use in including both since 
one implies the other. But I don't see a reason to forbid it.

> maps from one to the other.

That I agree with.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Apr 2008 14:17:07 -0400

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 24 Apr 2008 20:37:19 +0200

First and foremost, my prime requirement is that we all understand what
can be included, and what cannot, and that the specification is rigorous
in this respect.

I understand that the current specification implies (I could not find
words that say this in RFC 3325) that the P-Asserted-Identity conveys
the identity by which I can be reached using the current protocol, i.e.
SIP. Certainly anything in the P-Asserted-Identity header would imply a
need to authenticate that this user is entitled to use that value, and
it is more likely that the outgoing proxy can validate sip:.... or
tel:... on a particular request than mailto:... 

But I think the main thing is where does P-Asserted-Identity leave off
as a mechanism, and a mechanism for transmitting a vcard take over, and
at least we need to make this clear. Vcard is surely "If you want to
reach this user for any reason then use the appropriate one of the
addresses on this card", whereas P-Asserted-Identity is "If you wish to
return this communication, then go to this address". 

I would note that multiple addresses in P-Asserted-Identity are meant to
be aliases, but could not find a rigorous definition of that.

Regards

Keith

> Sent: Thursday, April 24, 2008 7:16 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; Elwell, John
> > 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. 
> 
> > 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.
> 
> Again I disagree. I don't see the purpose overall of the 
> limitations here. Indeed I'd argue that in reality, the sip 
> URI version of phone numbers is far more commonplace than the 
> tel URI version.
> 
> > 
> > used. I assume here we should continue to have one or the 
> other, but 
> > not both.
> 
> For the same user@domain, I don't see much use in including 
> both since one implies the other. But I don't see a reason to 
> forbid it.
> 
> > 
> > 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.
> 
> That I agree with.
> 
> -Jonathan R.
> 
> 
> --

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 24 Apr 2008 20:42:16 +0200

Well, it is a restriction that is there at the moment. I didn't invent it.

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.

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.

Keith 

> Sent: Thursday, April 24, 2008 7:17 PM
> To: DRAGE, Keith (Keith)
> Cc: Elwell, John; Jonathan Rosenberg; [email-masked]
> 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: "Hans Erik van Elburg" <[email-masked]>
Date: Thu, 24 Apr 2008 20:50:33 +0200

Why can't they be aliases, if they represent the same user?
/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, April 24, 2008 8:42 PM
To: Paul Kyzivat
Cc: [email-masked]; Elwell, John
Subject: Re: [Sipping] draft-ietf-update-pai-01 available

Well, it is a restriction that is there at the moment. I didn't invent
it.

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.

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.

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: Ted Hardie <[email-masked]>
Date: Thu, 24 Apr 2008 11:51:24 -0700

>P-Asserted-Identity: mailto:[email-masked]

You can argue for the addition of specific URI schemes, but you
need some restrictions, as there are too many schemes which
do not relate to identity.  P-Asserted-Identity: opaquelocktoken, mid,
tag and friends aren't going to be well suited to this.

				regards,
					Ted

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Apr 2008 15:10:55 -0400

> 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

---

From: Dean Willis <[email-masked]>
Date: Thu, 24 Apr 2008 14:47:59 -0500

> my point was why to repeat from uri rather than saying that uri in  

Proxies can change PAI, and they can't change the From.

In the IMS world, the request originates with a P-Preferred-Identity  
header, which (after authorization) is replaced by a P-Asserted- 
Identity (PAI) header. The PAI value may or may not match either From  
or P-Preferred-Identity, depending on whose interpretation of the  
specs you believe.

IMS UAS therefore generally ignore From and use PAI as their source of  
"caller ID".

Could this have been done better with RFC 4474 style functions? Yes.  
That's why it's a P-header.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 24 Apr 2008 14:51:29 -0500

On Apr 24, 2008, at 11:16 AM, Jonathan Rosenberg wrote:

> reasonable

I've been leaning towards a similar mod in RFC 4474 to allow multiple  
identities to be asserted, each with its own signature.

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 25 Apr 2008 14:32:07 +0200

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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 25 Apr 2008 15:11:54 +0200

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,
> 
> However, as your update goes to allow PAI in responses, it 
> would be worthwhile to allow PAI in the ACK as well.
> 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: "Stach, Thomas" <[email-masked]>
Date: Fri, 25 Apr 2008 15:22:43 +0200

Keith,

the draft says in 3.6

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

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> 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
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 25 Apr 2008 17:46:22 +0100

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
> 
> If we allowed the PAI in responses under this circumstances, 
> I think it should be allowed in ACK under the same restrictions.

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 25 Apr 2008 20:27:14 +0200

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]'
> 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: "Francois Audet" <[email-masked]>
Date: Fri, 25 Apr 2008 18:16:26 -0500

Here is my review of draft-ietf-update-pai-01

I have no major issues with draft. Well written, and understandable.

Nits:

- Sections 3.1-3.6. Each one of those sections should conclude with a statement
  that "This draft allows for P-Asserted-ID to be included in....", as appropriate.
  That will make it easier to understand what is proposed, without having to jump
  ahead to section 4.

- Section 3.1 should clarify that RFC 3265 doesn't preclude a UAC inserting P-Asserted-ID
  either: it just doesn't describe it. Furthermore, the section should point out that
  UAC inserting P-Asserted-ID is widely used.

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.
_______________________________________________
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: Mon, 28 Apr 2008 10:50:29 +0100

Francois,

Thanks for your comments. See below.

John 

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 26 April 2008 00:16
> To: Elwell, John; Mary Barnes; Gonzalo Camarillo
> Cc: [email-masked]
[JRE] Agreed.

>   UAC inserting P-Asserted-ID is widely used.
[JRE] Agreed, but the existing text in the draft says "RFC 3325 does not
include procedures for a UAC to include the P-Asserted-Identity header
field in a request", which I think is correct. The addition resulting
from your first comment will say "This update to RFC 3325 clarifies that
a UAC may include a P-Asserted-Identity header field in a request in
certain circumstances." Is this sufficient?

>   that has everything self-contained (i.e., rfc3325-bis)? I 
[JRE] I agree, but that is a decision for the WG to make. It would also
involve a lot more drafting work. Any other opinions?

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Apr 2008 11:29:46 +0100

Paul, 

> may be *no* proxy. (Just a bunch of B2BUAs. :-( )
[JRE] How about "in the same Trust Domain as the first downstream SIP
entity"?

> be allowed to assert the identity if it has some way of 
[JRE] The preceding paragraph talks about a proxy inserting PAI, and the
paragraph you comment on simply extends that to a UAS.

> s/first proxy/sip server to which it sends the request,/
[JRE] OK

> form of trust is determined. So it needs more work.
[JRE] I can make this change. As to whether it is sufficient, I am not
sure. Do we need to start redefining Trust Domain in a way that is not
necessarily symmetrical?

> s/last proxy/sip server from which it received the response,/
[JRE] OK, but the last word should be "request".

> decisions on knowing. I'm uncertain how to fix the above to 
[JRE]I propose:
"<t>When receiving a request or response containing a
P-Asserted-Identity header field, a proxy will trust the assertion only
if the source is known to be within the Trust Domain and is connected by
means of TLS as specified in RFC 3325. This applies regardless of the
nature of the resource (UA or proxy). One example where a trusted source
might be a UA is a PSTN gateway. In this case the UA can assert an
identity received from the PSTN, the proxy itself having no means to
authenticate such an identity. A SIP server must not trust an identity
asserted by a source outside the Trust Domain.</t>"

>     A sip server must not trust an identity asserted by a 
[JRE] Although I tentatively accept the proposals you make, I have a
concern that "SIP server" is not a defined term and that we now have a
mixture of "SIP server" and "proxy" in the document.

John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 28 Apr 2008 06:49:59 -0400

Hi, John,

> [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

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Apr 2008 13:51:35 +0100

Spencer,

> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: 28 April 2008 11:50
> To: [email-masked]
[JRE] As editor of the current draft, I have not yet attempted the
exercise of producing a complete replacement, but I would guess
somewhere between the two extremes you mention. We would need to ensure
a coherent structure for the whole, align with latest drafting
practices, terminology, RFC 4485, etc..

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Apr 2008 10:36:35 -0400

> [JRE] How about "in the same Trust Domain as the first downstream SIP

sounds ok to me.

Here you are using "sip entity", where at places I used "sip server" 
which you said was not defined. Either is fine with me.

> paragraph you comment on simply extends that to a UAS.

I realize that it is standard practice in documents to split up the 
specification behavior into separate sections for proxies and UAs 
(usually separately for UAC and UAS as well.) IMO that is getting in the 
way of clarity here. That convention assumes that there is a UAC and one 
end, some number of proxies in the middle, and a UAS at the other end.

Here, IIUC, the goal is to describe behavior in an environment where the 
hops between the originating UAC and terminating UAS may be either 
proxies or B2BUAs, and where a trust chain may include the entire path, 
including the UAC and UAS, or the entire chain with the exception of the 
UAC and/or UAS, or there may be breaks along the way in the trust chain. 
(An untrusted peer.) Within that more complex picture I don't know what 
you mean by "first" or "last".

Perhaps this could be clarified by actually describing the potential 
topologies that are being addressed.

If you only intend to extend this to include the originating UAC and/or 
terminating UAS in the trust chain, then I have less concern with the 
wording.

>> s/first proxy/sip server to which it sends the request,/

I know later you questioned the term "sip server". I thought that was a 
generic 3261 term, but maybe I imagined it. I'm just looking for a term 
that means "UA or proxy", and don't much care what it is. I'd be happy 
with sip entity if you like that better.

> sure. Do we need to start redefining Trust Domain in a way that is not

I always found this confusing. I seem to recall having some discussions 
with Jon about this. IIRC he had some very specific ideas about this. 
Perhaps we can get his input.

> asserted by a source outside the Trust Domain.</t>"

Sounds good to me.

> mixture of "SIP server" and "proxy" in the document.

Yeah. I've already commented on this above. I'm not certain what the 
best term to use is. But in general it seems there is frequent need 
within this document to refer to something that sends sip messages 
without specifying what role it plays.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Apr 2008 15:56:34 +0100

Paul,

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.

I was inconsistent between "SIP server" and "SIP entity". I prefer "SIP
entity", so I will use that consistently.

John

> Sent: 28 April 2008 15:37
> To: Elwell, John
> Cc: Mary Barnes; Francois Audet; [email-masked]; Gonzalo Camarillo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Apr 2008 13:14:32 -0400

John,

I guess what you are saying is that my point about the half-trusted was 
true in the original as well, an you have just extended it to another 
case. Is that right?

I can sympathize with that. If you want to declare fixing that out of 
scope for your document I won't object. Same for the other things.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 28 Apr 2008 15:22:41 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elwell, John
>

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: Tue, 29 Apr 2008 07:35:22 +0100

Paul,

Yes. I think there are practical limits to what we can do as an update,
as opposed to a replacement. If we try to do too much in an update, we
end up not keeping much of the original, and then the documentation
structure would not make much sense.

John 

> Sent: 28 April 2008 18:15
> To: Elwell, John
> Cc: Francois Audet; [email-masked]; Mary Barnes; Gonzalo Camarillo

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Apr 2008 07:46:47 +0100

Hadriel,

We have waited several years to fix some of the things in in RFC 3325
that people do in practice, so waiting a few more months to have a clean
replacement, rather than a messy update, would be worthwhile, in my
opinion. Of course, I would not want it to drag on for a couple more
years!

If we can get WG support, I would be prepared to edit a 00 draft
replacement for 3325 in time for Dublin. I think at Dublin we would need
to confirm the direction of that, and doubtless there will be a lot more
technical discussion concerning Jonathan's proposed additions, asymmetry
in Trust Domains, etc.. Therefore the BEST we could hope for would be
closing the open issues in Minneapolis and WGLC early 2009. But as you
know, timescales have a habit of slipping.

Also there may need to be some synchronisation with the work SIP is
doing on 4474.

John

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 28 April 2008 20:23
> To: Elwell, John
> Cc: [email-masked]; Mary Barnes; Gonzalo Camarillo
> Subject: draft-ietf-update-pai-01 vs. draft-ietf-sip-3325bis
> 
> 
> 
> 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: Tue, 29 Apr 2008 08:21:33 +0100

Hans Erik,

Sorry for the delay in responding. See below.

John

> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 24 April 2008 16:53
> To: Paul Kyzivat; Mary Barnes
[JRE] Thanks. This was pointed out before, but I see I have residual
text in there that assumes TLS. The paragraph will be changed to say:
"<t>In accordance with RFC 3325, nodes within a Trust Domain must behave
in accordance with a Spec(T), and this principle needs to apply between
a UAC and its proxy as part of the condition for considering the UAC to
be within the same Trust Domain. Normal proxy procedures of RFC 3325
ensure that the header field is removed or replaced if the first proxy
considers the UAC to be outside the Trust Domain.</t>"

John