Re: WGLC on draft-ietf-sip-info-events

It absolutely has not been forgotten: I was hoping to get more  
comments, but I'll get back with comments to the comments by the end  
of the week.

Thanks for your read of the document!

On Mar 3, 2009, at 6:59 AM, DRAGE, Keith (Keith) wrote:

> 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