Subject: [Sip] Comments on 100rel pre-release

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 19 Feb 2002 03:17:25 -0000

Sorry.  Again with the disclaimer about my poor
ability to notice re-reports.

 * Section 1; Paragraph 3:
   First use of "TU".

 * Section 1; Paragraph 4:
   First use of "UAC".

 * Section 3:
   First use of "UAS".

 * Section 3; Paragraph 10:
   Missing closing parenthesis after "RFC BBBB".
   [Dunno how generous the RFC Editor will be,
   eh? (:&]

 * Section 3; Paragraph 13; Sentence 1:
   It might be helpful to
   s/If a PRACK request/If a new PRACK request/
   to emphasise that this doesn't apply to
   retransmissions of a PRACK?

 * Section 4; Paragraph 2:
   "100rel" is quoted here.  Not sure what the
   preferred apprach should be, but I guess it
   should be consistent.

 * Section 4; Paragraph 8:
   s/TU/UAC ?

 * Section 5; Paragraph 3:
   For consistency, I would have thought
   s/a session description/an offer/ ?
   But this might make the sentence a little
   hard to parse.

 * Section 5; Paragraph 4:
   s/a session description/an offer or an answer/
   Perhaps?

 * Table 1:
    - Accept/415: I suspect should be "m"?

 * Table 2:
    - Record-Route: s/,401,484//
    - To: c(1) -- I don't see how it's possible
      that there could be no tag.
    - Unsupported/420: Shouldn't this read "m"?

 * Table 3:
    - RSeq: Only INV should be "o", right?  The
      rest "-"?

 * Section 9:
   I'm not sure how valid a concern this is, but
   I might perceive a vague DoS attack based on
   a MitM adding the option tag "100rel" to the
   Require: in a request.  Seems like the UAS
   might have to transmit a lot more responses
   that it would usually in this case?

Cheers,

 - Jo.

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Feb 2002 15:20:24 -0500

>  * Section 1; Paragraph 4:

These are all terms defined in bis. There is a dependency on bis, IMHO,
for both semantics and acronym expansion. I am not really inclined to
re-expand acronyms which you can get out of the definitions section of
bis.

>    [Dunno how generous the RFC Editor will be,

Fixed.

>    retransmissions of a PRACK?

Yeah, good point. That aspect is better handled by 
saying "If a PRACK request is received by the UA core",
since the transaction layer will handle the retransmit
issues.

>    preferred apprach should be, but I guess it

Right. Removed all quotes.

>  * Section 4; Paragraph 8:

Hmm. UAC is probably better.

>    But this might make the sentence a little

I think offer is better. Fixed.

>    s/a session description/an offer or an answer/

I think you mean paragraph 5 here. I think "session description" is OK.

>     - Accept/415: I suspect should be "m"?

I looked in bis, and its "o" there for Accept, Accept-Encoding, and
Accept-Language. The text in the spec is inconsistent. The UA section
says that a UAS MUST insert Accept when it rejects a request because the
body wasn't understood. The Accept header section says its a SHOULD. 

I think its a MUST.

However, table 2 cannot just say "m"; thats not sufficient. The reason
is that the 415 could have been sent because of an invalid encoding, so
that the 415 would need to have an Accept-Encoding, but not Accept. 

The basic problem is that the constraints that dictate whether or not a
header needs to be included in a message, can be more complicated than
just the method or response code. Here, its response code along with
some other condition.

My proposal to fix this, is to take the "c" value from table 2, and
generalize it. A value of "c" means that there are conditions which will
make this header have different strengths for inclusion in this message,
and that you need to read the text to figure it out. Then, the rows for
Accept, Accept-Encoding, Accept-Language for the 415 code would all be
"c".

Existing "c" values in the table would remain "c".

>     - Record-Route: s/,401,484//

Egads... good point. I copied table 2/3 from bis before the editors did
a serious sweep through the table, cleaning it up. I'll have to
back-propagate those changes, inclduing this one.

>       that there could be no tag.

Forgot to change that in the copy-paste.

>     - Unsupported/420: Shouldn't this read "m"?

Yup. Its still wrong in bis too. Grrr, I thought we fixed it...

>     - RSeq: Only INV should be "o", right?  The

Right, thanks. 

>    that it would usually in this case?

Only if the uas would otherwise send a provisional response (not 100, of
course). Having Require:100rel doesn't force sending of provisional
resposnes, on sending provisional responses that are sent, to be sent
reliably. No worse than if you just used TCP w/o this extension.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com