Inline. On Feb 16, 2009, at 7:18 PM, Brett Tate wrote:
Howdy,The following are a few comments and questions concerning draft-ietf- sip-info-events-03.Thanks, Brett -------------Section 3.1 paragraph 1: Concerning "MUST advertise" and "provisional 1xx", please clarify that the "MUST advertise" is not applicable to the 100 response. Does the "MUST advertise" and "provisional 1xx" apply to all (first and subsequent within dialog) INVITE non 101-199 (intentionally indicated 199)? Concerning ACK for initial INVITE's 2xx, does the "MUST advertise" always apply?
I would offer "MUST advertise" is appropriate. What is the rationale to not require it? We are expecting "early INFO," so no reason to screw up UACs by having random appearances and disappearances of Recv- Info headers.
Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 indicates "session parameters" and sentence 2 indicates "dialog parameters" concerning Info Package negotiation, I'm not sure when the negotiation/renegotiation occurs. Does it follow SDP offer/answer rules or something else; if something else, what? I have the same question concerning "dialog refresh" text discussed later within the same section since incorrect interpretations might trigger deactivation.
Should be dialog parameters everywhere. Would that clear up the confusion?
Section 4.3: When sending a 489, it indicates "MUST terminate the INVITE dialog". The "MUST terminate" seems severe even if all the negotiation race conditions are adequately addressed. The mentioned "protocol failure" reason seems contrary to the "strictly send and lenient receive" mantra.
Maybe living in New Hampshire has made me more conservative. A lot of folks will today say that while "Be conservative in what you send and liberal in what you receive" may have been the greatest mistake we ever made in protocol design. Let us look at this from a practical perspective. If you are a bad implementor and send a 489 you didn't mean to, who knows what else you will get wrong. Conversely, if you are a bad implementor and forget to tear down a 489-ed INFO, bad things probably will not happen.
I will defer to the WG on this one. Any other opinions?
Section 5.1 Table 1: The usage of "g" seems potentially outdated or incorrectly reference since discussed within RFC 2543 instead of RFC 3261. The same applies to usage Via row concerning "(2)".
Poor cutting & pasting. Will fix.
Section 5.2.2: The "general-header" reference is outdated or incorrectly reference since defined within RFC 2543 instead of RFC 3261. RFC 3261 uses "Message-Header".
Ditto.
Section 7.7 paragraph 2: The following potentially could be reworded since it is okay to return failure responses (401, 503, 500, ...) even when overlapping occurs: "in the event a UAC issues overlapping INFO requests for an Info Package, the UAS MUST NOT return an error response".
Good idea. Will do.
Section 8: Why specifically defining and using "nil"? I'm mainly just curious of the benefit over not having defined "nil" for similar use within the Supported header.
That is a good one. since we go to the trouble of registering "nil", it is just an Info-package-type. Will fix.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
