Thanks for the review! Responses inline.
On Nov 16, 2008, at 11:35 PM, Jonathan Rosenberg wrote:
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
The sense of UAC/UAS has not been changed at all, which is why it is complicated. The document talks about a situation where (for example) a phone (UAC) calls a B2BUA (UAS) and then that selfsame B2BUA (UAC) sends an INFO to the phone (UAS). Adam suggested a better way to describe the scenarios that will eliminate this confusion. Namely, since this document focuses on INFO, when we talk about a phone calling a B2BUA, we will talk about the calling UA and the called UA.
* I think the negotiation of supported types is not sufficiently welldefined. We're going to run into many of the hard cases we ran into foroffer/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 werevert back to the previous set? Indeed I don't think we should model this on O/A at all.
Lots of people noticed this, and I will fix it.
* 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 asingle 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 was 80% finished the text of why we had only one package per INFO when I realized an implementation would need 99% of the parsing machinery to deal with multiple packages per INFO 100% of the time.
The only cogent argument I have heard for why it would be nice to have one package per INFO is to be able to hand off the entire body to a subprocess dedicated to processing the info package type. However, that process would need to parse out its relevant body part, which makes this identical to handing the entire body to multiple subprocesses, which means one instantly gets processing multiple packages per INFO free. Another way of implementing this is to have the SIP stack parse the multiple body parts to find the relevant INFO body part, but again one finds that you again get multiple packages per INFO free.
I will admit to a subversive reason for allowing multiple packages per INFO: it is a way of ensuring no one confuses a SIP transaction with an application transaction. Check out MSCML. There is a lot of application logic to handle the fact an INFO transaction can succeed while the application transaction fails. In this case, one had better return a 200 OK for the INFO request, and then some other indication (most likely an INFO in the reverse direction) of the problem with the payload. Otherwise, I can envision people writing packages with language, "If you don't like the body for this transaction, send a 498 SIP response code."
* I don't like the behavior whereby, if a UA receives an INFO with an unknownn package, we terminate the dialog. Why so extreme?
Because it represented a protocol failure. However, note the tense of the last sentence. A race condition was identified which hints that we really should just ignore unknown packages. However, we want to make sure we have the strongest language that a UAC MUST NOT send an INFO the UAS has not indicated it will receive.
* I know we've discussed this one, but I disagree that the eventpackages HAVE to be specification required. I think we should allow forvendor prorpietary usage. My suggestion is to define a vendor tree for info event packages.
Theoretical world: give folks a vendor tree because there are truly proprietary usages that no one will care about; the only thing we care about is not colliding with the proprietary info package name.
Real world: this is where we get (just looking at THIS e-mail) X- Original-To, X-Virus-Scanned, X-Spam-Flag, X-Spam-Score, X-Spam-Level, X-Spam-Status, X-Mailer, X-Beenthere, X-Mailman-Version, of which 3 are really used by the Internet infrastructure. That is, they are beyond common usage and should be specified somewhere.
Also real world: no matter what we say, people will do proprietary usages. I would offer specification required encourages some documentation - the bar is VERY low to publish an Individual Informational Proprietary document or, better yet, a link to the documentation on your corporate web site.
Obviously, this is not an issue for me personally to decide. What does the work group want to do?
* 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.
Yup - as said two weeks ago, I forgot your document. Definitely should be folded in.
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
