Re: [Sip] comments on draft-ietf-sip-info-events-01

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 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.

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 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 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 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.

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.

Re: [Sip] comments on draft-ietf-sip-info-events-01

Attachment: smime.p7s