To comment on the multipart body question below, my understanding of the requirement from the previous discussion is that it does not come from the need to send two info packages at the same time.
Rather it comes from the need to send an info package plus some other associated but yet to be described message body that happens to be needed to be sent at the same time (e.g. info package containing a Geolocation header pointing to a geolocation body in the same message). If we could eliminate this, we could get rid of it, but I suspect we cannot. Given this, the support of multiple packages comes for free, so why eliminate it. However, whatever the result of this discussion, that does not mean that we should in any sense make draft-ietf-sip-body-handling optional for any method - it has to remain a mandatory part of RFC 3261. regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jonathan Rosenberg > Sent: Monday, November 17, 2008 5:35 AM > To: IETF SIP List > Subject: [Sip] comments on draft-ietf-sip-info-events-01 > > General comments: > > * I really dislike how the meaning of UAC/UAS has been > changed from RFC3261. This is really confusing and I think > complicates presentation of the material > > * I think the negotiation of supported types is not > sufficiently well defined. We're going to run into many of > the hard cases we ran into for offer/answer - so lets address > them now. What happens if, in an early dialog, there is a > reverse UPDATE that changes the send/recv packages, and then > a 2xx to the INVITE arrives with a different set? Which takes > priority? What about mid-dialog exchanges that are rejected, > do we revert back to the previous set? Indeed I don't think > we should model this on O/A at all. > > * The draft allows for multiple packages to be in a single > INFO. Egads, that just complicates life. Multipart support is > already a mess in SIP. > Do we REALLY need this? Cant you just send two INFO requests? > If a single INFO has a single package, we also don't need the > cid mechanism. > Less is more (I know this had some discussion already on the list...) > > * I don't like the behavior whereby, if a UA receives an INFO > with an unknownn package, we terminate the dialog. Why so extreme? > > > * I know we've discussed this one, but I disagree that the > event packages HAVE to be specification required. I think we > should allow for vendor prorpietary usage. My suggestion is > to define a vendor tree for info event packages. > > > * Section 7.1 includes some of the considerations in the > info-litmus draft, but only some. We should either fold it > all in or else split it all out. In either way, its really > important to separately consider the question on whether the > exchange should take place in the signaling vs. > media path, and then if signaling, whether to use INFO, event > pakcage, or new method, etc. > > > Specific comments: > > > > > The purpose of > > the INFO message [RFC2976], on the other hand, is to carry > > application level information along the SIP signaling path. > > There is no clear definition here of 'application'. I think > that merits some discussion. > > > Info Package negotiation is an offer/offer mechanism. 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 > > I think its a bad idea to use the term 'offer/offer' since it > sounds like this is related to the SDP offer/answer > mechanism. Suggest the word 'propose' instead of offer. > > > In this section, "UAC" is the User Agent Client from the perspective > > of the INVITE method. That is, it is the User Agent > (UA) that sends > > the initial INVITE method request. This may be somewhat > confusing if > > the User Agent Server (UAS) from the perspective of the > INVITE method > > sends an INFO method request. > > This contradicts the definition in rfc3261; the role of UAC > and UAS are on a per-transaction basis, not fixed for the > duration of the call based on the initiate INVITE that > established the session! > > > > The > > general rule is before a UA may begin sending INFO methods with a > > given Info Package, the sending UA must first indicate > it wants to > > send the Info Package by listing it in a Send-Info > header in the most > > recent dialog negotiation and the receiving UAS must positively > > indicate it is willing to receive the Info Package by > listing it in a > > Recv-Info header in the most recent dialog negotiation. > > what if the previous exchange omitted Send-Info or Recv-Info, > but an exchange prior had contained it? > > > A UA MAY list multiple packages by enumerating the package name(s), > > separated by commas, as values for the Send-Info and Recv-Info > > headers in the session establishment. > > not just at establishment, but at any time. > > > Such Info Package capability negotiation MUST occur within the > > context of a single session negotiation exchange. > > this is very vague in terms of what it means. > > > Similar rules apply for late Send-Info / Recv-Info negotiation, such > > as an empty INVITE, followed by an offer in the 200 OK and the > > response in the ACK. > > In which case, this should be defined more generically rather > than writing it in terms of INVITE and just say, 'oh, it > works in other use cases too' > > > The INFO message MUST NOT change the state of the SIP dialog. The > > only exception to this rule is for specific failure responses as > > documented in RFC 5057 [RFC5057], which may cause the > INVITE dialog > > to terminate. > > We should clearly enumerate what this is. Can we update > Contacts? Is INFO a target refresh request? What about > P-A-ID? Or From/To URI? > > > OPTIONS Processing > > > > A UAC, the sender of the OPTIONS request, MAY include > Send-Info and > > Recv-Info headers, populated appropriately for the > packages the UAC > > > > > > > > Burger, et al. Expires May 7, 2009 > [Page 14] > > > > > Internet-Draft INFO Framework > November 2008 > > > > > > supports. The UAS MAY include its set of Send-Info and Recv-Info > > packages. > > I think you should make this a SHOULD (inclusion of Send/Recv Info). > > > Because there are numerous situations where a SIP method request can > > carry a payload, any INFO method may contain body parts > in addition > > to the payload associated with the Info Package. > > hmm, why? This complicates things. KISS. > > > > 9.5. Creation of the Info Packages Registry > > You should show an example of what the actual table in the > IANA registry looks like and include the 'nil' there. > > There are no specific security issues for this mechanism, beyond > > those already applicable to SIP-based session signaling. In > > particular, if one does not protect the SIP signaling from > > eavesdropping or authentication and repudiation attacks, > for example > > by using TLS transport, > > I disagree with this statement. There are new considerations > here - we're now exchanging APPLICATION data in SIP, and this > increases sensitivity of the data depending on the > application. For example considering using INFO to send > typical form-data, like a credit card number.... > > > Minor: > > > [RFC2976] to include explicit negotiation of supported Info Packages > > in the INVITE transaction and indication of the Info > Package to use > > by using a new header field in the INFO request. > > > > [RFC EDITOR NOTE: Please replace "This draft proposes > replacing" > > with "This draft replaces" in the final edition.] > > there is no need to make rfc-ed do this work. Write the > document to reflect what it is meant to look like as an RFC. > > > > The signaling path for the INFO method is the signaling path > > established as a result of the call setup. > > dialog setup > > > a signaling > > path involving SIP proxy servers that were involved in > the call setup > > and added themselves to the Record-Route header on the > initial INVITE > > message. > > or b2bua's. > > > The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message > > if the INFO request does not match any existing dialog. > > > this repeats already-defined behavior in rfc3261. Remove. > > > > By definition, such uses > > have relied on either static local configuration or > implicit context > > determination based on the body Content-Type or > Content-Disposition > > value, or some proprietary mechanism. > > 'have relied on..." you don't say what they've relied on these FOR. > > > 7.2.7. Rate of notifications > > I think this should be rate of INFOs > > > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > [EMAIL PROTECTED] > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > _______________________________________________ > 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
