Some comments: "Info Package negotiation is similar, but not the same, as negotiating SDP [RFC3264]. It is similar, in that the UAC may offer a set of Send-Info and Recv-Info packages in the initial INVITE, the UAS offers its set of Send-Info and Recv-Info pacakges in provisional 1xx and final 2xx responses, and the UAC may offer a final set of Send- Info and Recv-Info packages in the ACK." This sounds like a 3-way exchange, which is not the same as for SDP. I believe a 2-way exchange, as for SDP, is intended. This interpretation seems to be in line with 4.2 and 4.3, but 4.1 seems to suggest a 3-way handshake. Clarification is needed in several places.
"The general rule is before a UA may begin sending INFO methods with a given Info Package, the UAC must have first indicated it wants to send the Info Package by listing it in a Send-Info header in the most recent dialog negotiation and the UAS must have positively indicated it is willing to receive the Info Package by listing it in a Recv- Info header in the most recent dialog negotiation." Not necessarily. This only applies before a UAC can begin sending. Before a UAS can begin sending, the opposite must have happened, i.e., the UAS must have indicated willingness to send and the UAC must have indicated willingness to received. "Once the UAC and UAS establish an early dialog through a 1xx provisional response with To-tags, and the UAC has received a Recv- Info header field values from the UAS in the response, the UAC MAY send any Info Packages supported by the UAS in an INFO message. The 2xx final response updates the state of the supported Info Packages, such that the 2xx contains the full and final list of Send-Info and Recv-Info Info Packages." This text does not seem to allow for receipt of a 2xx response without having received a 1xx provisional response. "Any proposal to have INFO change the state of a SIP call is an architectural error and one MUST NOT allow it." Who or what is "one"? For any normative statement, we have to be clear to whom or what it applies. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of DRAGE, Keith (Keith) > Sent: 21 October 2008 00:39 > To: [email protected] > Subject: Re: [Sip] I-D Action:draft-ietf-sip-info-events-00.txt > > (As WG chair) > > This is the draft that is supposed to solve all the INFO problems we > ever had and ever will have in future. > > Note that the current version of the draft obsoletes (replaces) RFC > 2976, i.e. the existing INFO method documentation. > > There are a couple of open issues in the document where I believe the > editor's will be initiating discussion shortly - so you may > want to wait > for those on the TBD. > > Otherwise, let the discussion commence. You may want to try and raise > different issues in different emails, in order to allow these > to be kept > track of. > > Regards > > Keith > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of [EMAIL PROTECTED] > > Sent: Tuesday, October 21, 2008 12:15 AM > > To: [EMAIL PROTECTED] > > Cc: [email protected] > > Subject: [Sip] I-D Action:draft-ietf-sip-info-events-00.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol > > Working Group of the IETF. > > > > > > Title : Session Initiation Protocol (SIP) > > INFO Method and Package Framework > > Author(s) : E. Burger, et al. > > Filename : draft-ietf-sip-info-events-00.txt > > Pages : 29 > > Date : 2008-10-20 > > > > This document defines the new INFO method and a mechanism for > > defining, negotiating and exchanging Info Packages that use > > the INFO method. Applications which need to exchange > > session-related information within a SIP INVITE-created > > dialog use these INFO requests. This draft addresses issues > > and open items from RFC 2976, and replaces it.Conventions > > Used in this Document > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as > > described in RFC 2119 [RFC2119]. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-info-events-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail > > reader implementation to automatically retrieve the ASCII > > version of the Internet-Draft. > > > _______________________________________________ > 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 > _______________________________________________ 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
