Subject: comments on SIP INFO last call

From: "Schroeder, Tim" <[email-masked]>
Date: Tue, 25 Jan 2000 16:49:49 -0600

A few comments on the draft-ietf-sip-info-method-01.txt:

[1. Introduction]  The introduction says the INFO method merely sends
"optional application layer information".  But some of the uses of the INFO
method (carrying PSTN signaling messages, e.g.) are not really optional.
Maybe optional in the sense of the session state, but not optional in the
sense of getting things to work.

[2.2 Responses to the INFO Request Method]  A 200 OK message must be sent
for an INFO request with no body.  A 200 OK message must be sent if the body
is understood, but there are no rules for processing it.  I guess if the
body is not understood at all (I'm not sure how that differs from the
previous case), the action falls "outside the scope of this document".  (1)
I would like clarified what an "understood" body is, as opposed to a
non-understood body, and how the presence/absence of rules for handling the
body affects this.  Wouldn't a body with no rules defined be "not
understood"?  (2) Would it be correct to at least demand that the server
return some sort of final response on receipt of an INFO message, even if
the determination of the particular response sent is outside the scope of
the document?  The sender ought, I think, to be entitled to receive a final
response of some sort on any INFO method.  (3) Section 2 says the
mid-session information can be sent either as a message body or as message
headers.  If so, why does the response handling vary depending on which of
these ways is chosen?  (So, if the mid-session information is carried in
headers, the draft mandates a 200 OK response, but if the same information
is carried in a body, the response is "outside the scope of this document".)

[X. Reliability]  I think a short reliability section should be added,
similar to that in RFC2543.  Should 200 OK or other final responses be
retransmitted (I think not).  Should a client retransmit an INFO method if a
final response is not received (I think yes).

[2.2 Responses to the INFO Request Method]  (Not really a "comment", but a
"nit".)  The two "tables" are labeled "figures", though they are referred to
as "tables" in the text.  They are consistently called and labeled "tables"
in RFC2543.

Tim Schroeder