Re: INFO

On 9/20/07 10:58 PM, Brian Stucker wrote:
> You've made some assertions in your arguments that I
believe need some substantiation. You've said that the
content-type is not enough to figure out what is going on at
all. I disagee. I think a content type that says "I'm
sending you DTMF digits in a particular format" is
every bit as robust as the content-type that conveys MWI for
instance, and a heck of a lot more specific than SDP is. 

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.

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.

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'm looking for consistent arguments that can be
applied to problems outside of INFO so when the next bad
idea (tm) comes along we can clearly point to this document
and say "you're trying to do X which we can clearly
show is bad and does not align to the things we think are
good." I haven't read such an argument yet.
>   

The argument you're looking for is part of Jonathan's
service 
identification draft -- INFO, as currently defined, is a
"Do What I 
Mean" method. For proper behavior, it requires either a
closed-garden 
approach or implementations that can perform mind reading.

INFO with packages is a "Do What I Say" method.
The arguments against it 
are weaker, but mostly resolve to this: Why would you send
INFO, a 
message with no inherent semantics, with a package header
that gives the 
intended meaning? The method itself is ostensibly what gives
the message 
its intended meaning. These cases all cry out for a new
method, and the 
IANA charges the same amount to register a new SIP method as
they would 
to register a new INFO package. ;)

/a


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hey Adam,
Comments inline...

> -----Original Message-----
> From: Adam Roach [mailto:adamnostrum.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?  Do you mean because
it doesn't
specify which methods it's acceptable in (e.g., INFO)?  Or
do you mean
because it won't indicate that an INFO with DTMF is only
acceptable in the
context of an Invite-based dialog, for example?  

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.  When I
think of "context", I think of it in a bigger
sense than protocol syntax,
and more of application semantics.  But DTMF has no such
semantics at the
UAC.  The UAC has no idea what a button push means from an
application
perspective, beyond just "the user pressed #". 
There is a protocol issue,
though, in terms of "if and how do I tell someone the
user pressed #".  But
I think that's something that can be solved.


> 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.  There
are devices which
won't accept Invites or re-Invites without application/sdp,
and there are
devices which don't accept Options with mime types they do
accept Invites
with, etc.  (You can call them broken I guess)  What does it
mean for an
application/sdp mime body to be in a Message method, or in a
Bye?

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) 


> 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.  There are
devices that
already convert 2833 to Info and vice versa, and they'll be
happy to keep
doing so for the short term.  If we think 2833 is not going
to solve this
problem ultimately, or the application usage for dtmf is not
possible by
2833 for all cases, then I think we need a solution.  KPML
isn't it, IMHO.

-hadriel



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip