Subject: [Sip] Comments to the Path header draft

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 15 Feb 2002 10:44:46 +0200

Hi:

Some comments to the Path header draft, draft-willis-sip-path-01.txt

1) Section 3. "UA1 discovers P1 as a
   result of a DHCP assignment."

   Although most of the UAs will discover P1 as a result of a DHCP assignment,
   I foresee other mechanisms, like local configuration (a la http browser) or
   external means (e.g., 3GPP PDP context activation). I will propose to replace
   the above text by this one:

   "UA1 typically discovers P1 as a result of a DHCP assignment, although
    other mechanisms, such s manually provisioning may be also possible".

2) Section 4, 2nd paragraph: "A Path header may inserted ..." should read
   "A Path header may be inserted ..."

3) Section 4, bullet point 1: "Path applies to REGISTER and responses to 
   REGISTER. Record-Route doesn't." It should read:
   "Path applies to REGISTER and the 200 OK response to REGISTER. Record-Route
   doesn't."

4) Section 4, bullet point 3. Typo: "Regsiter" should be "REGISTER". 
   Same section: "rflected" should read "reflected".

5) Section 4: I would add a new bullet point 5 to emphasize that the URI
   inserted in a Path header does not have any requirement to be the own
   URI of the node which inserts it. I know it is already written in 
   section 5.2, but I guess the text will enlighten the reader.

   "Unlike Record-Route headers, there is no restriction on the URI that
    a node inserts in a Path header field value, other than it MUST be
    a SIP URI. Particularly, a node MAY insert a Path header field value
    with SIP URI that resolves to another node. This requires the inserting
    node to have some knowledge of the network topology".

6) Section 5.1: clarify that the Path header field is only allowed in
   200 OK response for a Register, so replace: "When a UA receives a 
   response to REGISTER containing the Path header ..." with "When a UA 
   receives a 200 OK response to a REGISTER containing one or more Path 
   header field values ..."

7) Section 5.1, 1st paragraph: "This list SHOULD be stored during the 
   entire registration period of the associated public user identity." 
   should read:
   "This list SHOULD be stored during the entire registration period of 
   registered URI".

8) Section 5.1. The first sentence assumes that the Path header field
   values in the 200 OK will contain the SIP URL of the own UAC. However,
   this is not true. By no means the UAC SIP URL will be present in the
   Path in the 200 OK. See the examples, flow "F4 Registrar Response 
   P1->UA1" for a correct example.

   Therefore, the text "When a UA receives a response to REGISTER 
   containing the Path header, the UA removes its SIP URL from the list 
   of Path headers, reverse the order of the list and save the resulting 
   list of Path headers." should be rephrased to:

   "When a UA receives a response to REGISTER containing the Path header,
   the UA reverse the order of the list and save the list of Path header
   field values as a list of preloaded routes that will be used in 
   subsequent requests.

9) Section 5.2. "... the topmost entry in the Path header before processing
   the request" should read "... the topmost entry in the Path header field
   value before processing the request".

10) Section 5.2, last paragraph: "It is also possible for a proxy
   with specific knowledge of network topology to add a Path header
   referencing another node, ..." should read "It is also possible for 
   a proxy with specific knowledge of network topology to add a Path header
   field value referencing another node, ..."

11) Section 5.3, 1st paragraph: First, there is a condition on the existence
    of a Path header in the response, based on the existence of the Path 
    header in the REGISTER. I believe there should not be such a restriction,
    because a registrar should be able to insert a Path header even when the
    REGISTER didn't include it.

    I propose to replace the first paragraph in section 5.3 by these others:
    "A registrar that receives a REGISTER message that includes one or more
    Path header fields MUST copy the list of Path header field values into a 
    list of preloaded Route header field values. The order in the lists MUST 
    be preserved.

    The registrar MUST bind the registered URL with the Contact header field
    values and the list of preloaded Route header field values.

    The registrar MAY add a URL as a Path header field value to the 200 OK
    response to the REGISTER."

12) Section 5.3:  "The registrar can also act as a proxy as described above 
    (in which case it inserts a resolvable identifier identifying itself in 
     the Path header) before storing the list of preloaded Route headers."
 
    I don't clearly understand what this paragraph is trying to say. Maybe
    is trying to say:

    "Upon the reception of a user location query, the registrar MUST return 
     the binding information associated to the particular user. This binding
     information is built upon the Contact header field values along with 
     the list of preloaded Route header field values as described previously 
     in this section".

    Therefore, I propose to replace the existing text with the proposed one.

13) Section 5.4, first paragraph, several comments already discussed above.
    I propose to replace the first paragraph with this one:

   "Any node generating or receiving a REGISTER request or 200 OK response
   (to the REGISTER request) that wishes to be included in the service route 
   for future messages flowing in the direction of the received message may 
   add a SIP URL as a Path header field value at the end of any Path header 
   field in that message, or may add Path header field with a SIP URL as a 
   Path header field value as the final value in the Path header field in 
   that message."

14) Section 5.4: "So, P1 and will add itself ..." should read "So, P1 will
    add itself".

15) Section 5.4, flows. There are two flows F4.

16) Section 8: Typo, "Migual" should read "Miguel" ;-)

17) Somewhere in the draft we should add the following:

    The following table extends table 2 in [bis]:

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

18) Section 6, security considerations: If we allow a proxy to insert a
    path header field value that does not point to its own resolvable
    SIP URL, I guess we are introducing a security risk, but I am not 
    sure how to cover this in the text. Perhaps something like this:

    "Care must be taken when a SIP entity introduces a Path header field
     value that points to a different entity. Such a mechanism SHOULD be
     used by entities that have administratively knowledge of each other,
     typically because they are part of the same administrative network".

/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

_______________________________________________
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