Subject: RE: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE

From: Adam Roach <[email-masked]>
Date: Fri, 18 Jul 2003 02:12:07 -0500

Paul Kyzivat [mailto:[email-masked]] writes:

> For one thing, the application already has an opportunity to pick the 
> address to which the MESSAGEs are sent. So it should be able 
> to ensure 
> that the recipient knows these messages shouldn't be 
> displayed directly 
> to an end-user.

The problem really is one of a slippery slope. You already
heard a participant get up in the meeting and suggest that
MESSAGE should be the mechanism by which a server pushes a
KPML script to a UA. This is just one use case away from
sending a MESSAGE to a UA from which no message has yet been
received, which will undoubtedly cause the relic I described
earlier.

> Beyond that, there is the Content-Disposition header, which seems 
> intended for purposes like this. In the normal use of MESSAGE for IM, 
> the obvious content type is "render". Here we don't want that, so we 
> should pick some other content type.

Without well-defined semantics in the MESSAGE RFC, I can
confidently assert that many, if not most, UAs will not bother
with checking the Content-Disposition when they receive a MESSAGE.
MESSAGE has an explicit render semantic built in.

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jul 2003 15:48:31 -0400

> received, which will undoubtedly cause the relic I described

While there may be better ways, I will walk out on a limb as say that 
this proposal doesn't strike me as too outlandish. But were we to go 
that way I think there is more specification work to do.

> MESSAGE has an explicit render semantic built in.

I agree that this needs some additions to the MESSAGE RFC before it can 
fly. Or maybe someplace else that better defines content disposition in 
general, for all messages. That shouldn't be any harder than inventing a 
new message.

And at the same time, it will be nailing down an ambiguity in the 
existing specs. (What should a UAS do if it receives a MESSAGE whose 
content disposition isn't "render"?)

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Jul 2003 15:17:04 -0700

> received, which will undoubtedly cause the relic I described

I don't think I understand the scenario you are getting at here. Are you
saying that the UA will just automatically send any key press to whatever UA
it is talking to with no KPML - sort of like the old DTMF over INFO idea?

I'd agree this was really broken but if someone did it, rendering the key
presses would probably be about as good a semantic as any. This could all be
mitigated by the choice of the body in the message.

Anyways, everything to do with DTMF is sort of a slippery slope no matter
which direction we go. I would  consider anything that created "automatic"
KPML subscription very broken.

> MESSAGE has an explicit render semantic built in.

Agreed

I wonder what a PSTN GW should do if it receives a IM with a plain text body
that contains "7" - it could "render it". Ooh that is gross :-)