Subject: [sipcore] draft-ietf-sipcore-info-events-02: WGLC comment and questions

From: Brett Tate <[email-masked]>
Date: Mon, 26 Oct 2009 07:12:43 -0700

Hi Christer,

The following are a few comments and questions concerning draft-ietf-sipcore-info-events-02.

Thanks,
Brett

------------

Section 3.2 paragraph 2: Concerning "during the dialog establishment, and during a target refresh", how should it be interpreted in relation to PRACK and ACK discussed within the next sentence?  More specifically, is indication of Recv-Info limited to call setup or can it be performed during the re-INVITE process?

Section 3.2 paragraph 3: "to INFO" should likely be "to receive INFO".  The last sentence potentially could be reworded to avoid "This" ambiguity.

Section 3.5: It is unclear if OPTIONS within dialog can be used to communicate a Recv-Info change similar to target refresh requests like UPDATE.

Section 3.5 paragraph 1: The strength of "SHALL" is likely too strong and potentially conflicts with the drafts table 2.  In case it matters, RFC 3261 tables 2 and 3 indicated "m*" for various OPTIONS headers.  For compliance, is this "SHALL" going to cause devices that use OPTIONS as a device ping (outside of dialog) to be required to add Recv-Info if they support this draft?

Section 4.4 and table 2: Concerning the 469, should it be optional (or mandatory) to return Recv-Info?

Section 5.1 figure 1: Retry-After needs a 500 next to the 503.

Section 6.1 table 2: ACK responses should have "-" instead of "o".

Section 6.1 table 2: Because of rfc4320, the "Recv-Info 1xx" row should likely only have "-" everywhere except INV.

Section 6.1 table 2: Is there really a current reason for "Recv-Info r" row?  If so or not, why would UPD have an "o" when INV has a "-"?

Section 11.4 bullet 2: Since it doesn't follow the related rfc4485 section 4.4 "SHOULD", why are the parameter names and values case-sensitive?

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 26 Oct 2009 23:37:46 +0100

Hi Brett,
 
------------------

>Section 3.2 paragraph 2: Concerning "during the dialog establishment,
and during a target refresh", how should it be interpreted in relation
to PRACK and ACK discussed within the next sentence?  More 
>specifically, is indication of Recv-Info limited to call setup or can
it be performed during the re-INVITE process?
 
It can be performed during a re-INVITE process. That should be covered
with "during a target refresh", which can occur at any time.
 
------------------

>Section 3.2 paragraph 3: "to INFO" should likely be "to receive INFO".
The last sentence potentially could be reworded to avoid "This"
ambiguity.
 
Yes.
 
------------------

>Section 3.5: It is unclear if OPTIONS within dialog can be used to
communicate a Recv-Info change similar to target refresh requests like
UPDATE.
 
OPTIONS is only used for general queries - not for specific dialog
queries, and not to update dialog information.
 
So, if you send OPTIONS inside a dialog, the packages in the response
may not be the same packages that you have indicated support of for that
particular dialog.
 
------------------

>Section 3.5 paragraph 1: The strength of "SHALL" is likely too strong
and potentially conflicts with the drafts table 2.  In case it matters,
RFC 3261 tables 2 and 3 indicated "m*" for various OPTIONS 
>headers.  For compliance, is this "SHALL" going to cause devices that
use OPTIONS as a device ping (outside of dialog) to be required to add
Recv-Info if they support this draft?
 
In my opinion, if we put a "SHOULD" we should indicate when something
does NOT apply. Otherwise the text is useless when it comes to things
like conformance testing etc...
 
------------------

>Section 4.4 and table 2: Concerning the 469, should it be optional (or
mandatory) to return Recv-Info?
 
Good point. I think that the 469 shall contain Recv-Info (in the same
way as 420 contains Supported).
 
------------------

>Section 5.1 figure 1: Retry-After needs a 500 next to the 503.
 
Ok.
 
------------------

>Section 6.1 table 2: ACK responses should have "-" instead of "o".
 
Yes.
 
------------------

>Section 6.1 table 2: Because of rfc4320, the "Recv-Info 1xx" row should
likely only have "-" everywhere except INV.
 
Yes.
 
------------------

>Section 6.1 table 2: Is there really a current reason for "Recv-Info r"
row?  If so or not, why would UPD have an "o" when INV has a "-"?
 
I think INV should also have it. I can't think of any specific reason
why we would need the "r" row at this point. But, does it harm? Maybe
there will be a future use-case at some point...
 
In addition, if we agree on the MUST for 469, I guess we should add a
row for 469 with "m".
 
------------------

>Section 11.4 bullet 2: Since it doesn't follow the related rfc4485
section 4.4 "SHOULD", why are the parameter names and values
case-sensitive?
 
You are right. 4485 says "Header field parameter names MUST be case
insensitive".
 
------------------
 
A big thank you for your comments I give! :)
 
Regards,
 
Christer