|
List Info Thread: Re: INFO
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: INFO |
|
List Info Thread: Re: INFO
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
nostrum.com]
>> 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