On 9/26/07 11:45 AM, Hadriel Kaplan wrote:
-----Original Message-----
From: Adam Roach [mailto:[EMAIL PROTECTED]
Sent: Monday, September 24, 2007 11:26 AM
The problem isn't _in_ that direction. The problem is: how do I say "I
am capable of receiving DTMF digits in an INFO message"?
The "Accept" header-field lets you say you understand the syntax, but
doesn't convey what contexts it makes sense in.
When you say "doesn't convey what contexts it makes sense in", in what way
do you mean that if the topic is DTMF?
This isn't just about DTMF; it's about INFO in general.
Do you mean because it doesn't
specify which methods it's acceptable in (e.g., INFO)?
That's the symptom I'm trying to illustrate, yes. Note that this isn't
the underlying cause per se; it's a symptom of the cause. The root cause
is that one must infer intention from an INFO, and Content-Type isn't
sufficient for this purpose.
I ask because the argument of "not conveying context semantics" has come up
a few times, and I'm trying to figure out if the problem is one that can be
solved by standardization, or if the problem is something bigger.
I think it can be solved by standardization -- however, I'm not sure
that standardization within the framework of INFO is the right approach.
The "Allow" header-field lets you say you can process INFO for some
mime-types, but doesn't let you say which ones.
There is no current mechanism that lets you tie the semantics together,
the way that event packages do. I've shown, in previous messages, how
this can lead to ambiguity and consequent interoperability failure.
I agree with you, but that problem already exists today. There are plenty
of cases where there are constraints on the combination of method+mime that
cannot be described with Accept and Allow headers.
But the difference is that those methods have inherent semantics that
constrain things in a way that avoids the problem. "INVITE" means "I'm
trying to start a session." The MIME types that make sense in this
context are only those which support description of a session. "MESSAGE"
means "I'm sending content for rendering." Only those MIME types which
can be rendered make sense in a MESSAGE. SUBSCRIBE and NOTIFY have
inherent semantics, and the only MIME types that make sense are those
which describe resource state.
Note that all of those MIME types are completely disjoint. There is no
overlap, because the methods mean radically different things. So, for
example, if a UA advertises support for INVITE and for
"application/pidf+xml", it's trivial to figure out that they cannot go
together -- there is a semantic mismatch.
"INFO" means... well... it doesn't mean *ANY*thing. It means "here's
some stuff, now you guess what you're supposed to do with it." So, it is
conceivable that INFO could carry content that describes a session, or
contains renderable content (DTMF!), or describes the state of a
resource. Because these content types necessarily make sense in the
context of other methods that may be supported, it is impossible to tell
whether they make sense in an INFO. So, if a UA advertises support for
INFO and for "image/jpeg", it's not as clear whether they support them
in conjunction with each other. Maybe you think you can use this to
update your user icon in my buddy list... maybe it's just there because
I can receive them in MESSAGE requests. It's impossible to tell, because
INFO *has* *no* *inherent* *meaning*. In theory, every MIME type
imaginable "makes sense" in an INFO.
I also think for this dtmf case, we can define the usage for
application/dtmf such that it is tied to a specific method, in specific
session contexts. (or not)
I'll concede that there *might* be ways to band-aid the situation for
DTMF as a point solution, but it's not obvious that all the problems can
be worked around. No one has even put enough thought into the issues to
put together an internet-draft describing an INFO DTMF solution (at
least, as far as I can recall). (n.b.: I'm not encouraging such a draft;
I'm just saying that proponents of what you're proposing has been
profoundly apathetic about it for nearly a decade).
However, the problems with INFO in general -- that is, when looking at
the problem without DTMF blinders on -- are intractable without some
kind of explicit indication of intended meaning. And, at the risk of
sounding like a broken record, intended meaning should be conveyed by
method type; that's what the method type is for.
To be clear: I don't really care much whether we come up with INFO
packages or whether we formally deprecate INFO, but the current
situation is untenable.
I guess that's the $64k question: is the current situation untenable? If we
think rfc2833 will ultimately become ubiquitous and address the application
needs, then we don't need to worry about this.
Again, this isn't solely about DTMF. It's about INFO. The underlying
problem is that INFO doesn't mean anything, and overloading Content-Type
in an attempt to give it meaning causes ambiguity.
/a
_______________________________________________
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
