On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote:
So if we're allowing SIP-T, which builds off of a baseline SIP
requirement that if you get a MIME type or method (INFO) that you
don't
understand, that you gracefully handle this: send a 415/488 or send a
405, respectively, then why are we disallowing other uses of INFO that
do not introduce ANY requirements beyond those of SIP-T which we are
allowing?
This raises the argument that SIP-T should be revisited to more
clearly negotiate support for the material being tunneled, including
the context in which it is being tunneled. My UA might, for example,
know how to render an ISUP message using a pretty-printer. That
doesn't mean it knows how to do SIP-T for gateways.
So, SIP-T is broken and likely to give surprising results. That is
not a hearty argument for endorsing the technique of SIP-T for other
functions.
Here's another question for the readers: let's say Eric's draft
becomes
an RFC as written for sake of argument. What happens when a UA that
does
not support SIP-T gets a call from an ISUP gateway and gets an INFO
with
encapsulated ISUP in the message body? How does this processing differ
from an endpoint getting encapsulated DTMF in a format it may not
understand? It doesn't differ because it can't: the UA cannot
differentiate between two different MIME types when it does not
recognize either of them.
But assume the UA DOES recognize the MIME type. How does it know what
to do with it? Is content-disposition adequate?
If it were, why would we have the higher-level negotiation of event
contexts?
--
Dean
_______________________________________________
Sip mailing list https://www1.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
