Frequently the editor's wait until the end of the WGLC before processing the comments, so I am sure that it has not been forgotten.
It does have the advantage of making sure that we do not swap and change when we get conflicting comments. regards Keith > -----Original Message----- > From: Brett Tate [mailto:[email protected]] > Sent: Monday, March 02, 2009 1:19 PM > To: DRAGE, Keith (Keith); SIP IETF > Cc: [email protected]; [email protected]; > [email protected] > Subject: RE: WGLC on draft-ietf-sip-info-events > > > A reminder of the current WGLC on this document, which completes > > Wednesday. > > > > Please submit your comments as soon as possible. > > > > If you are reviewing the document, and you consider there may be a > > delay in your comments appearing, then please send a mail to the > > chairs so they can ascertain whether more time is needed. > > I haven't received a reply concerning my February 16 > (archived on 17) email: "draft-ietf-sip-info-events-03: > comments and questions". Thus I'm not sure if I will have > follow-up comments based upon the reply. > > http://www.ietf.org/mail-archive/web/sip/current/msg26621.html > > The following is a snapshot of my questions and comments in > case the authors did not see my prior email. > > 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? > > 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. > > 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. > > 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)". > > 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". > > 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". > > 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. > > _______________________________________________ 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
