RE: [Sip] INFO considered harmful

[Michael Thomas <mat@cisco.com>]

Dean,

I think the important part of the observation here
is that if SIP defines a way to transport data,
somebody really, really ought to define the
color/shape/consistency of that data too. To not
do that is to create interoperability problems by
definition. Now there is a management question of
_who_ defines those semantics -- eg, the SIP wg or
somebody else, but I don't think there should be
too much debate that it really ought to be done.
Opening up the door for un(der)defined semantics
seems really dangerous to me. A high energy
barrier for new semantics is probably a Good Thing
at this point as SIP is already a terribly
complicated beast. To end up with an official
backdoor for whatever kruft people want to wrap in
a SIP packet seems, well, like shortcut on the
road to hell.

	Mike

Dean Willis writes:
 > 
 > Christer said:
 > > I agree that the semantics of the commands are different. 
 > > However, one IS allowed to include any kind of message body 
 > > in the INVITE request, to provide whatever "extra 
 > > information" about the session (text, HTML, whatever...), so 
 > > someone could argue that whatever stuff they put into the 
 > > INVITE does provide "extra information" about the session...
 > > 
 > > And, since it IS allowed to send re-INVITE, or UPDATE, 
 > > without actually updating the session description (the SDP 
 > > message body) someone could include that whatever stuff also 
 > > in those messages...
 > 
 > That's actually quite interesting. One can get the same functionality as
 > INFO using UPDATE methods. For example, SIP-T could encode the mid-session
 > ISUP and send it using UPDATE.
 > 
 > So, what is the semantic differentiation?
 > 
 > I propose that we've been operating under a logic system where "UPDATE
 > affects SIP state and INFO doesn't". It might be that this exposes a fallacy
 > (which one might call "telephone centric" thinking) in our logic. There are
 > really two different "sessions" in a typical SIP exchange: 1) The SIP-level
 > session, or "dialog", framed in INVITE and BYE or SUBSCRIBE and BYE, and 2)
 > the negotiated session, expressed in SDP, which may or may not exist.
 > 
 > Since there may or may not be a negotiated session, and since SIP works just
 > fine either way, is it reasonable to divide SIP mid-dialog semantics into
 > "things that we think might affect the negotiated session", and "things that
 > we think don't"? Perhaps all we're really doing is handing a blob of data to
 > the application (which exists ABOVE the SIP layer), which then uses that
 > information to affect its own state, and may consequently affect the SIP
 > state?
 > 
 > In any case, I think there is a much deeper semantic problem lurking here
 > that we really haven't thought out.
 > 
 > --
 > Dean
 > 
 > _______________________________________________
 > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
 > This list is for NEW development of the core SIP Protocol
 > Use sip-implementors@cs.columbia.edu for questions on current sip
 > Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip