Subject: [Sip] Revision of draft-willis-sip-path to version -07

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 May 2002 13:43:37 -0500

We have previously requested IETF last call on draft-willis-sip-path.

Sharp-eyed Vijay found a couple of minor typos that, though previously
thought  fixed, didn't stay fixed. This annoyed me enough that I fixed
them and revved the draft, although there are no technical changes.

The version-07 draft can be retrieved from:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.html
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.xml

Internet-Drafts -- please post this draft and announce to SIP WG list
IESG-Secretary -- please repalce the reference to -06 on the calendar
with a reference to -07.

Thank you all.

--
Dean Willis

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 14 May 2002 17:19:52 -0400

Hi Dean,

You're still missing a couple:

Line 190 (txt version): "reuqest"
Line 253: "vfield"

Other nits...

Line 46: Does not compute: "The problem is that network topology may be 
that..."

Line 139: is "service proxy" an established term? Why not just "proxy".

Line 141: is "transited" really a real word?

Line 147: "The proposed Path extension header field...". When becoming 
RFC it's no longer a proposal.

Line 172:

    2.  The same set of intervening proxies MUST be visited by requests
        between a home service proxy and the UA.  That is, the proxy
        route between the home service proxy and the UA is the exact
        reverse of the proxy route between the UA and its registrar.

As the draft points out later, this is not, strictly speaking, a 
condition for applicability.  One might end up with a subset of teh path 
travelled by the REGISTER and also, a proxy might insert addresses other 
than its own on the Path.

Line 198:

    The primary difference between Path and Record-Route is that Path
    applies to REGISTER and 200 OK responses to REGISTER.  Record-Route
    doesn't, and can't be defined in REGISTER for reasons of backward
    compatibility.

I'd say the more important difference is that Record-Route applies to 
the dialog being set by the request it's used in whereas Path is used to 
establish a route for subsequent requests.

Line 153:

    The UA should include the option tag "path" as a header vfield value
    in all Supported header fields, and should include a Supported header
    field in all requests.

This make it sound like the path token is optional if the UA inserts a 
Supported header. I believe it's the case that a Supported header must 
always include the tokens for all supported extensions.

Line 331:

    However, the Path
    mechanism should technically work in the absence of UA support (at
    some compromise to security)

I'm not sure I see how a Supported: path header contributes to making 
this more secure. That is, unless you also assume S/MIME and what have you.

BTW, it seems a little schizofrenic to me to say that a registrar may 
ignore absence of "Supported: path" but a proxy can't. In fact, since 
the functioning of the Path header doesn't depend on UA cooperation I'm 
not sure wht it's required at all. Is it so that you get a measure of 
assurance that the UA/human sending the REGISTER knows that things have 
inserted themselves on the path of subsequent requests?

Line 347: "home service proxy" - again, I'd prefer just proxy or home proxy.

Sorry for the late comments.

Anders

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 15 May 2002 11:58:12 -0500

Many good comments elided. They will be incorporated in next rev.
Thanks, Anders.

> always include the tokens for all supported extensions.

Yes, this is definitely a slightly different usage of Supported. It's
the closest thing we could come up with to a hinting mechanism, and
probably deserves discussion in its own right. It made Robert Sparks
hair stand on end until he thought about it for a while. But it's
actually pretty cool.

Think about it -- someday we're going to have 1,000 extensions, so every
Supported header is going to be like 20kB long. So the suggested
semantic is that the UA include only those options it is willing to use
for this transaction or any dialog resulting from it, rather than every
possibe supported extension.
 
> this more secure. That is, unless you also assume S/MIME and 

The Security aspect is that a UA that is aware of Path can look at the
Path header field in the REGISTER response and see what proxies have
attached themselves. This may allow users to detect unwanted proxies
that have "latched on" to registrations. If the UA doesn't support Path,
it is unlikely to able to do this inspection. So it isn't the Supported
header that makes the difference, it's the actual functional support
that matters.

> inserted themselves on the path of subsequent requests?

Yes.

> Sorry for the late comments.

The critical piece is that the proxy in question is the proxy
responsible for the address-of-record. It can be expected to do a
retargeting of requests to that AOR by changing the Requist-URI. This
distinguishes it from a proxy that simply forwards using forwarding
rules.  We probably need a distinctive term for such a beast. Please
make suggestions.

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 15 May 2002 18:35:02 -0400

> possibe supported extension.

I think the reason the requirement is there is that if a proxy/UAS 
cannot tell from a Supported header whether the UAC supports a 
particular extension it cannot intelligently downgrade the service it 
provides - does it send a 420 in the hope that the UAC will resend with 
the extension token or does it proceed without the extension.

One idea that was floated at the time was to allow a special Supported 
token signaling that all supported extensions have been listed. But 
given that this is not what's in the current or previous specs, servers 
wouldn't be able to interpret absence of such a special token as 
guarantee that the UAC didn't send a complete Supported list anyway, so 
it wouldn't really help now.

Anders

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 16 May 2002 12:49:06 -0500

Anders wrote:
> > Think about it -- someday we're going to have 1,000 extensions, so 
> > every Supported header is going to be like 20kB long. So 
> the suggested 
> > semantic is that the UA include only those options it is willing to 
> > use for this transaction or any dialog resulting from it, 
> rather than 
> > every possibe supported extension.
> 

The assumption has to be that the UA is unwilling to (read WILL NOT) use
extensions other than those listed, so the proxy simply proceeds as if
the extension is not supported by the UA -- if it's REQUIRED, reject the
request.
 
> it wouldn't really help now.

I believe  my proposal requires no changes whatsoever to proxy logic. If
the proxy requires that a UA support a particular extension not listed,
it 420s. If it doesn't, it forwards (optionally adding a Requires). If
the UA just happens to offer a different set of options on another
transaction, the proxy doesn't really care -- the decisions always
happen on a per-transaction basis anyhow.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 May 2002 17:55:35 -0500

> Line 190 (txt version): "reuqest"

fixed 

> Line 253: "vfield"

fixed 

> Other nits...
>
> Line 46: Does not compute: "The problem is that network topology may
> be that..."

restructured to: 

"The problem is that network topology may have one  or more SIP proxies 
between the UA and the registrar, such that any request travelling 
fromt he user's home network to the registered UA must traverse these 
proxies."

"
> Line 139: is "service proxy" an established term? Why not just

Switched to "home proxy" and added the definition:
"a proxy serving as the terminal point for routing an 
address-of-record".

> Line 141: is "transited" really a real word?

yes.

>
> Line 147: "The proposed Path extension header field...". When
> becoming RFC it's no longer a proposal.

deleted.

> Line 172:
>
>     2.  The same set of intervening proxies MUST be visited by
> requests between a home service proxy and the UA.  That is, the proxy
> route between the home service proxy and the UA is the exact reverse
> of the proxy route between the UA and its registrar.
>
> condition for applicability.  One might end up with a subset of teh
> path travelled by the REGISTER and also, a proxy might insert
> addresses other than its own on the Path.

rephrased as:

"The same intermediate proxies or a set of proxies known to the 
intermediate proxies must be traversed, in reverse order, by requests 
sent through a home service proxy to the UA. In the simplest form, the 
route between the home service proxy and the UA is the exact inverse of 
the route between the UA and the route between the UA and the registrar"

>     applies to REGISTER and 200 OK responses to REGISTER. 
> Record-Route doesn't, and can't be defined in REGISTER for reasons of
> backward compatibility.
>
> the dialog being set by the request it's used in whereas Path is used
> to establish a route for subsequent requests.

rephrased to:
"The difference between Path and Record-Route is that Path applies toR 
EGISTER and 200 OK responses to REGISTER. Record-Route doesn't, and 
can't be defined in REGISTER for reasons of backward compatibility. 
Furthermore, the vector established by Record-Route applies only to 
requests within the dialog that established that Record-Route, whereas 
the vector established by Path applies to future dialogs."

--
dean