Subject: [Sip] WGLC for draft-willis-sip-path-05

From: "Dean Willis" <[email-masked]>
Date: Sun, 5 May 2002 16:06:18 -0500

I'd like to request Working Group Last Call for draft-willis-sip-path.
This will need to close by about 11May.

Version -05 draft has been submitted to internet-drafts and shoudl be
available.

in the meantime use:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt

or

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html

--
Dean

_______________________________________________
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: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 06 May 2002 09:35:31 +0300

Dean, Bernie:

Some comments to the Path header, mostly NITS.

1) Regarding the tag option "Path" for the Supported header, as far as 
   I have seen before, most of the other option tags are defined in 
   lowercase. I would suggest to follow the same approach for consistency,
   that is, define "path".

2) The syntax defined at the end of section 3 does not allow the Path 
   header to be part of the request, only to the response. I suspect 
   this is an error. Suggestion:

         Header field          where   proxy ACK BYE CAN INV OPT REG PRA
         _______________________________________________________________
         Path                    R       ar   -   -   -   -   -   o   -
         Path                   2xx       -   -   -   -   -   -   o   -

3) The last sentence in section 4.1 reads: "The UA should include the
   option tag 'Path' in any Supported headers". I suspect this inclusion
   affects all the instances of Supported, including those in an INVITE.
   Can you confirm this?

4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be
   replaced by reference [2] (bis-09).

5) In section 4.7, the Via in the examples do not begin with "z9hG4bK"
   as required by bis-09.

Thanks a lot,

       Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: [email-masked]
Date: Mon, 6 May 2002 11:06:11 +0300

below are my comments:

- i thought that it was agreed to use name rrr instead of path for this
  header.  the reason is that this header is both semantically and
  syntactically very close to record-route.  also, name path is not at
  all descriptive, what path?

- this paragraph should be moved, since somebody's suggestions regarding
  things that are outside the scope of the i-d should not be part of
  the normative text:

  It has been suggested that the UA MAY choose to store the contents of
  the Path header for future use as a preloaded Route for use when the
  UA wishes to send a SIP message that, for reasons of acquiring
  services in the home network, need to transit the service proxies in
  the home network.  Such usage is explicitly outside the scope of this
  document.

-- juha

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 06 May 2002 18:21:19 +0300

Juha:

I believe the name of the header should be related as much as possible to 
the semantics, not to the relation with other headers and how to build it.

Therefore, having a name of a header "rrr" sounds to me like coding ISUP.
I would prefer to keep the name Path as it is suggested in the draft.

/Miguel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 06 May 2002 10:45:35 -0500

> Version -05 draft has been submitted to internet-drafts and shoudl be
[...]

Dean:

New comments based on -05 I-D:
Section 4.2, first paragraph: s/future transmissions/future transactions

Old comments, persisting from -04 I-D:

Section 1, "UA" still remains in the figure, although the succeeding
text refers to "UA1".  To remain consistent with later figures, change
"UA" in Section 1 figure to "UA1".

I also made a general comment in the last review round, which may have
escaped your attention; I reproduce the comment here (full context can
be found at
http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04979.html)

vkg> Generally speaking, in many places where you use "message", I
vkg> believe you mean "requests".  If so, can we substitute the
vkg> term request, since a "message" may be a response, for
vkg> instance, which will follow the Via paths.

dean>Reasonable.

vkg> In Section 4.6, the requests from P1->P2 show P1 adding
vkg> itself to the Path list (initially set to null).  The branch
vkg> of P1 does NOT contain the "magic cookie" (z9hG4bK).
vkg> Likewise for P3->REGISTRAR. Since P1 and P3 supports "lr", it
vkg> is a good bet that they also support the Via "magic cookie".
vkg> Of course, this is an obscure nit, but all the same...

dean> Good point.

It appears that you have added the magic cookie to in the UA1->P1
INVITE request, which is okay, since UA1 supports lr, so there-
fore it also supports the new Via "magic cookie".  But so do proxies P1
and P3; however, the Vias for P1 and P3 do not contain the magic cookie.
Again, this is a pedantic nit, so I will leave it at your discretion
on what to do.  I resurrect this here based solely on your modification
of the UA1->P1 INVITE request to add the magic cookie.

That's all!

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 7 May 2002 13:03:05 -0400

Hi Dean,

Maybe I am missing something, but how do we make sure the registrar can
support the Path header? The UA probably does not care, but the intervening
proxies probably need to know that the "Path" cannot honored by the
registrar. I suppose the proxy could insert Require:path if it saw the
Supported:path in the request.

I think the spec should say that UAs that want to allow a Path to be
inserted MUST add Supported:path to the REGISTER request and that a proxy
MUST NOT add a Path header if Supported:path is not present. The proxy
inserting a Path header SHOULD add Require:path to guarantee that the
registrar supports Path. If the request is rejected with 420, the UA SHOULD
resubmit without Supported:path.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 7 May 2002 13:15:06 -0400

see below

----- Original Message -----
From: "Miguel A. Garcia" <[email-masked]>

>    lowercase. I would suggest to follow the same approach for consistency,

I also think it should be "path".

>          Header field          where   proxy ACK BYE CAN INV OPT REG PRA

A prior e-mail said that a UA was not allowed include a Path header. Is
there a particular reason we want to prohibit the UA from contributing to
the path? I can't think of a particular example, but a UA could know that a
specific element needs to be on the inbound path, and that element may not
be in the register path (just like a proxy adding "a Path element
referencing another node" as described in section 4.2).

>    affects all the instances of Supported, including those in an INVITE.

The Supported:path is only needed in the REGISTER request. Why would the UA
need to include it in INVITEs it sends? And how would a Calling UA know to
include it? I don't think the Calling party needs to consent to the Called
party's registered Path.

cheers,
(-:bob

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 7 May 2002 12:39:20 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, May 06, 2002 3:06 AM
> To: Dean Willis
> Cc: [email-masked]; 3GPP_TSG_CN_WG1; 
> [email-masked]; Rohan Mahy; 
> [email-masked]; [email-masked]
> Subject: [Sip] WGLC for draft-willis-sip-path-05
> 
> 
> below are my comments:
> 

I polled the list on April 1, and received about a dozen responses
indicating a preference for Path. Nobody responded in favor of RRR.

>   the home network.  Such usage is explicitly outside the 

This seems reasonable, and unless there are objections I intend to
delete in next revision.

--
Dean

---

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

Bob said:
> Maybe I am missing something, but how do we make sure the 
> registrar can support the Path header? The UA probably does 
> not care, but the intervening proxies probably need to know 
> that the "Path" cannot honored by the registrar. I suppose 
> the proxy could insert Require:path if it saw the 
> I think the spec should say that UAs that want to allow a 
> Path to be inserted MUST add Supported:path to the REGISTER 
> request and that a proxy MUST NOT add a Path header if 
> Supported:path is not present. The proxy inserting a Path 
> header SHOULD add Require:path to guarantee that the 
> registrar supports Path. If the request is rejected with 420, 
> the UA SHOULD resubmit without Supported:path.

I think this works. It does have the side effect that a UA that doesn't
know about Path can't be served by a proxy network that requires it even
though there are no functional changes needed in the UA.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 7 May 2002 13:07:21 -0500

Bob asked:
> A prior e-mail said that a UA was not allowed include a Path 
> header. Is there a particular reason we want to prohibit the 
> UA from contributing to the path? I can't think of a 
> particular example, but a UA could know that a specific 
> element needs to be on the inbound path, and that element may 
> not be in the register path (just like a proxy adding "a Path 
> element referencing another node" as described in section 4.2).

That's a reasonable question. It's not consistent with the original
intent, but on first analysis, I can't think of a real reason that this
COULDN'T be done. Anybody else out there have an opinion?

> The Supported:path is only needed in the REGISTER request. 
> Why would the UA need to include it in INVITEs it sends? And 
> how would a Calling UA know to include it? I don't think the 
> Calling party needs to consent to the Called party's registered Path.

The Supported mechanism is not method specific. This is part of why
option tags may not be such a good idea. The UA is supposed to include
an option tag for EVERY extension it supports in EVERY case in which it
sends a Supported header.

>From bis:

20.37 Supported 
4429 The Supported header field enumerates all the extensions supported
by the UAC or UAS. 
4430 The Supported header field contains a list of option tags,
described in Section 19.2, that are understood 
4431 by the UAC or UAS. A UA compliant to this specification MUST only
include option tags corresponding to 
4432 standards-track RFCs. If empty, it means that no extensions are
supported. 

It doesn't really matter whether the calling UA understands Path or not
-- it is applied by the called party's proxy.

Conversely, I'm not sure that it matters all that much whether the
registering UA understands Path. If it doesn't, it can't sanity-check
the response in 200Ok, but that doesn't keep the path mechanism from
working.

One possibility (and I believe this is the justification for Supported
in this case) is that the UA knows whether its registrar supports Path,
and that intermediate proxies can use the presence of a Supported header
for path as hint to decide whether they may safely include Path headers.
One could for example use this mechanism to allow a proxy to reject a
registration when the proxy knows that it requires Path functionality,
and the UA doesn't indicate support for the header. This seems like a
slight stretching of the Supported functionality, but should work.

What we don't have is a way to have perfect forward knowledge in the
proxy which inserts Path that the registrar processing the registration
understands Path. Perhaps there's a way to get this using Require?

For example, the UA could do a Require: path if it thinks that there's
any chance that intermediate proxies will need it.

--
Dean

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 7 May 2002 14:24:33 -0400

----- Original Message -----
From: "Dean Willis" <[email-masked]>
<snip>
> sends a Supported header.
OK. But surely the UA is allowed to exclude features (option tags) it does
not want used for a given request.

<snip>
> the response in 200Ok, but that doesn't keep the path mechanism from

I almost see the UA's inclusion of "Supported:path" as 'permission' for the
intervening elements to insert Path headers (you know all that stuff about
the knowledge and consent of the user). That's why I think proxies should be
forbidden from adding Path headers if Supported:path is not present.

> any chance that intermediate proxies will need it.

By having the proxy that is inserting a Path header add the Require:path,
you eliminate the rejection of the request by a registrar that does not
support 'path' when no Path headers have been added.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 7 May 2002 12:39:20 -0500

>    lowercase. I would suggest to follow the same approach for 

Works for me.
 
>          Path                    R       ar   -   -   -   -   
> -   o   -
>          Path                   2xx       -   -   -   -   -   
> -   o   -

I'm busy arguing with Jonathan about the meaning of stuff in table 2. As
I read it, the formulation I've given says that the UA (see bis line
4036) MUST NOT insert a Path header in a request, but that a proxy MAY
add a Path header, or add to an existing Path header inserted by another
proxy. The registrar, which is a UA, MAY (support for Path is optional)
insert a Path header in the 2xx response to the request, and proxies
MUST NOT modify or delete that header from the response.

However, Jonathan has now decided that the text around 4036 is an error,
and there's no way to actually describe the logic above in table 2/3.
This furthers the arguments that tables 2/3 need to be either deleted or
replaced. Jonathan suggests we follow the example of Record-Route and
Proxy-Authenticate, which according to Table 2/3 is allowed in a message
from a UA even though it makes no sense at all.

In short, anybody who's relying on Table 2/3 to provide a truth table
for their implementation is likely to be sorely disappointed.

>    affects all the instances of Supported, including those in 

Yes, "path" should be included in any Supported headers sent by the UA.
At least that's my understanding of the Supported mechanism. It seems to
make sense only in REGISTER, but (and I just verified with Jonathan) the
Supported mechanism is not method specific, so it goes in any Supported
header.

--
Dean