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

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Mon, 27 May 2002 10:12:50 +0200

Hi Miguel,

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

A REGISTER is used to create a binding between an address-of-record AOR (or
public address) and a contact address. One may use a new registration to
bind more contact addresses to an AOR. It is also possible or have more than
one AOR bound to the same contact address (more than one user can be
registered on a single device). So it is not clear to me in your sentence
above what URIs you are talking about - public addresses or contact
addresses ?
| 
| 
| <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>

Same comment as above. You cannot just say that a user register more than
one SIP or SIPS URI. I think the point of the whole draft is that a user can
have more than one address-of-record (public address) -
sip:[email-masked] and sip:[email-masked]. These
address-of-record's are bound to the same device. When he gets a call, the
Request-URI is always replaced by his contact/device address and so he
cannot tell which address-of-record the caller has used to call him.

| >   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."
| 
| <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>

If it is suitable for the general use, why a P-header ?

| >   o The term "standalone method" is not defined in SIP RFC.
| 
| <miguel>
| 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>

RFC 3261 even defines terms such as "Message", "Parallel Search". One simply
can't start using a new term like "standalone request" or "standalone
transaction request" and assume that it is 'understandable by the reader
familiar with SIP'.

Regards,
Ya-Ching

_______________________________________________
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, 27 May 2002 12:28:00 +0300

Hi Ya-Ching:

Comments below

> above what URIs you are talking about - public addresses or contact

<miguel>
Reading again the text, I agree with you, it is not clear at all. The case I
refer is when an application server registers other address-of-record URIs
pointing to the same contact address. I will clarify the terminology in the
draft.
</miguel>

> cannot tell which address-of-record the caller has used to call him.

<miguel> 
yes, I agree with you
</miguel>

> If it is suitable for the general use, why a P-header ?

<miguel>
Because so far nobody else has the requirement as we expressed.
That's why we are going for a P- header. But the extension itself
is not restricted to 3GPP. It is generally applicable to the Internet.
</miguel>

> transaction request" and assume that it is 'understandable by the reader

<miguel>Yes, I understand your comment. I will do my best to make it
clear what it means in the next version.
</miguel>

Thanks for your comments.

/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: "Bob Penfield" <[email-masked]>
Date: Tue, 28 May 2002 14:02:39 -0400

A couple follow-ups and one new comment below

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

Does the fact that one would want to use P-Called-Party-ID when they cannot
(or will not) rely on the To field, need be included in the applicability
statement?

><snip>

I think what you are trying to say is that the P-Called-Party-ID can be
inserted in any request that initiates a dialog, or any request that is
completely outside of a dialog. These should be the only requests that would
have been issued with an AOR type Request-URI that a proxy would replace.
All other requests (those within an existing dialog) would have a
Request-URI equal to a URI that the UA learned from a Contact header in the
request/response that created the dialog. Is this correct?

New issue:

In the header field table in Section 5, shouldn't the header be optional for
a SUBSCRIBE and not allowed for a NOTIFY? SUBSCRIBE initiates a dialog, and
NOTIFY should use the value from the Contact of the SUBSCRIBE for the R-URI
(thus R-URI would not be changed by a proxy).

cheers,
(-:bob

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 29 May 2002 15:45:12 +0300

Bob:

Thanks for your comments. Answers inline.

/Miguel

> A couple follow-ups and one new comment below
[snip]
> (or will not) rely on the To field, need be included in the applicability

IMHO any decent implementation should not rely on the To header for any other
thing that maintaining the dialogs (and for that you need only the tag).
This should be evident for the SIP ilustrated reader. Therefore, I don't 
think it is necessary to add anything else in the applicability statement.

> request/response that created the dialog. Is this correct?

Precisely.

> (thus R-URI would not be changed by a proxy).

Definitely. Thanks for catching the bug.