Subject: [Sip] Comments on draft-garcia-sip-called-party-id-01

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Fri, 24 May 2002 16:09:23 +0200

Hi,

- Reading the draft for the first time, I must say that I was confused by
the 4th 
  paragraph of the Section 2 which starts with "Another possible solution to
the 
  problem is...". Up to this point the draft talks about the problem, with
no
  solution mentioned yet. With the "Another possible solution", I thought I
had
  a corrupted version of the draft with some paragraphs missing.

- The next paragraph which starts with "The solution described above...",
the
  sentence "that some URIs may be automatically registered when the UA
  registers some of its URIs" confused me further.

- Is the term "terminating ID" (of the current INVITE) defined somewhere ? I
think
  you mean "the destination (request-URI) of the request before it was
replaced
  by the contact address".

- In the example, the sentence above the mesage F2 starts with
  "A user also...", do you actually mean "The user also..." ?

- The last paragraph of Section 2 :
  "... the proxy that is serving the user..." should be made clearer,
perhaps with
  "the proxy that is responsible for the home domain (as defined in RFC
3261) of
  the user" ? Also, please add a "header" after the P-Called-Party-ID in the
same
  sentence.

- Section 3
  "1. The UA registers to his proxy with one or more SIP URIs". Does it have
to be
   SIP URIs or can it be "SIP or SIPS URIs" ? I assume you mean here that
the
   UA registers one or more address-of-record.
  "2. The proxy receives an INVITE destined to a user's ID" means :
  "2. An INVITE arrives at a proxy which is responsible for the domain of
the
       Request-URI".
  
  Come to think of it, these applicability statements apply to all SIP
requests in
  general. It is normal for a UA to register to his proxy with at least one
address-
  of-record, and some proxy always receives an INVITE destined to a user'
ID.
  I do not see how these statements meet the requirement of [3], which
states :

  "An applicability statement in the Informational RFC MUST
   clearly document the useful scope of the proposal, and explain
   its limitations and why it is not suitable for the general use
   of SIP in the Internet."

- Section 4 2nd paragraph
  o This paragraph seems to imply that any SIP proxy can insert the
     P-Call-Party-ID header field.
  o The term "standalone method" is not defined in SIP RFC.
  o INVITE is a method that initiates a dialog so it cannot be "INVITE or
    method that intiates a dialog".

- Section 5
  The sentence "The allowable usage of headers..." is repeated. The 3rd
  paragraph should be completely deleted.

- Section 6.2
  First paragraph
  o The term "standalone method" is not defined in SIP RFC.
  o INVITE is a method that initiates a dialog so it cannot be "INVITE or
    method that intiates a dialog".
  o "...contents Request-URI" => "...contents of the Request-URI..."

  Second paragraph
  o "...the proxy who..." => "...the proxy which..."

- Ya-Ching Tan

_______________________________________________
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: Sat, 25 May 2002 16:13:29 +0300

Hi Ya-Ching:

Thanks a lot for your comments. See my answers inline.

/Miguel

>   a corrupted version of the draft with some paragraphs missing.

<miguel>
Section 2 starts with a description of the problem in the first
paragraph. Paragraphs 2 and 3 in this section describe a possible solution
that does not work. Paragraphs 4 and 5 describe another possible solution
that does not work as well. That is why the 4th paragraph begins with 
"Another possible solution ...".
</miguel>

>   registers some of its URIs" confused me further.

<miguel>
Maybe the following text is clearer:
"some URIs may be automatically registered when the UA registers a 
particular URI".
</miguel> 

>   you mean "the destination (request-URI) of the request before it was

<miguel>
Yes, you are right. I think if I replace "terminating ID" by "intended 
destination URI" the sentence is clearer. It will read:

"... so that the UAC is not aware of the intended destination URI in 
the current INVITE."
</miguel>

>   "A user also...", do you actually mean "The user also..." ?

<miguel>
Certainly is "The user also ..."
</miguel> 

>   the user" ? Also, please add a "header" after the P-Called-Party-ID in the

<miguel>
ok. Done!!!
</miguel>

>    UA registers one or more address-of-record.

<miguel>
The important thing here is that the UAC registers at least one SIP or SIPS
URI to his proxy. It is not relevant whether there are one or more address-of-
record registered. What I want to say is that the user may register more
than one SIP or SIPS URI.
</miguel>

>   "2. An INVITE arrives at a proxy which is responsible for the domain of

<miguel>
better... However we are missing the connection between the proxy and the
registrar. Perhaps the sentence should read "an INVITE destined for the user
arrives at a proxy in the domain where the user is registered. The proxy 
contacts the registrar to find the location of the user."
</miguel>

>   of-record, and some proxy always receives an INVITE destined to a user'

<miguel>
Not necessarily. Registration is an optional procedure in SIP, although 
quite common. Without registration this P- header has no sense at all.
</miguel>

>    its limitations and why it is not suitable for the general use

<miguel>
My effort was to scope as much as possible this header. It is suitable
for the general use of SIP in the Internet, so I have nothing else to
say.
</miguel>

>      P-Call-Party-ID header field.

<miguel>
fixed.
</miguel>

>   o The term "standalone method" is not defined in SIP RFC.

<miguel>
I meant requests that do not create a dialog, such a MESSAGE.
But I need to differentiate from requests that are sent within
a dialog (e.g. INFO).
I'll fix it somehow, but I think that the term standalone, 
although not define in RFC 3261, is understandable by the
reader familiar with SIP.
</miguel>

>     method that intiates a dialog".

<miguel>
fixed
</miguel>

>   paragraph should be completely deleted.

<miguel>
Ooops, I forgot to delete this paragraph when I replaced it by the next 
paragra. Thanks a lot. Fixed
</miguel>

>   o "...the proxy who..." => "...the proxy which..."

<miguel>
All fixed. You will see the changes in the next version.
</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