Subject: [Sip] Comments on Path-07

From: [email-masked]
Date: Thu, 23 May 2002 16:05:41 +0300

In section 4.2, it is mentioned that if a Proxy requires that the registrar supports the path extension, it inserts a Require header, should the proxy remove the supported header in that case? it is kinda redundant.

Section 4.4 assumes that the home proxy and registrar are always co-located. What about when they are not (not talking about 3GPP for now).

So in your diagram, P3 is actually the home proxy for UA2. Should there be some text talking about how P3 should behave when it receives a request? It contact the registrar, gets the path headers converts them to route and finds itself in the top-most route-header.

The same issue was brought up about record-route and route headers. A proxy should remove the first route header or (if its not smart enough to recognise its own route, should just send it to itself).

Also in this section, it does not mention anything about the first route being a strict-route and that the R-URI needs to be re-written yet again.

In section 5, (this is a little too picky) in your examples, the display names in the to-header and from-header have '@'. This is not allowed. You need to place quotes around them,  or better still, change them to something meaningful.

There are also few spelling mistakes and nits, do you want those?

Regards,
Hisham

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Thu, 23 May 2002 10:21:08 -0500

Hisham wrote:
> In section 4.2, it is mentioned that if a Proxy requires that the
registrar supports the path extension, it inserts a Require header,
should the proxy remove the supported header in that case? it is kinda
redundant.

No, because the registrar has to decide with to do if the extension is
required by a proxy but not supported by the UA. The two obvious options
are "reject" and "accept", although there might also be an "accept and
notify somebody externally".

This is addressed in 4.3, Procedures at the Registrar:

"If a registrar receives a REGISTER request containing a Path header
field and there is no indication of support for the extension in the UA
(via A Supported header field), the registrar must rely on local policy
in determining how to treat this request. The recommended policy is for
the registrar to reject the request with a 420 "Bad Extension" response
indicating the Path extension. This approach allows the UA to detect
that an intermediate proxy has innapropriatelty added a Path header
field. However, the Path mechanism should technically work in the
absence of UA support (at some compromise to security), so some
registrars may choose to support the extension in the absence of a
Supported header field value in the request."

> Section 4.4 assumes that the home proxy and registrar are always
co-located. What about when they are not (not talking about 3GPP for
now).

> So in your diagram, P3 is actually the home proxy for UA2. Should
there be some text talking about how P3 should behave when it receives a
request? It contact the registrar, gets the path headers converts them
to route and finds itself in the top-most route-header.

>
> The same issue was brought up about record-route and route headers. A
proxy should remove the first route header or (if its not smart enough
to recognise its own route, should just send it to itself).

I could put in a clarification that, if not co-located with the
registrar, the home proxy apply local topology knowledge to construct a
return route from the stored Path vector.

>
> Also in this section, it does not mention anything about the first
route being a strict-route and that the R-URI needs to be re-written yet
again.

Huh?

>
> In section 5, (this is a little too picky) in your examples, the
display names in the to-header and from-header have '@'. This is not
allowed. You need to place quotes around them,  or better still, change
them to something meaningful.

I assume you mean section 4? Good catch.

> There are also few spelling mistakes and nits, do you want those?

Yes. That's why I asked for feedback and proofreading on the list.
That's why we went through six versions during list discussion and
working group last call. That's why we have a seperate IETF Last Call,
which has now been going on for over a week.

So please post any corrections you think are needed. Be explicit! The
same applies to any document under working group review -- the authors
will be appreciative, and our work will be of better quality, if all of
you folks in the working group take the initiative to provide feedback.
Of course, the authors are free to disagree with suggestions and discuss
further.

Thanks!

--
Dean