Subject: RE: Capability detection

From: Graham Klyne <[email-masked]>
Date: Wed, 24 Mar 1999 12:49:10 +0000

At 11:18 23/03/99 -0500, [email-masked] wrote:
>## A big advantage of IOTP is that if it is installed at the merchant
>## and the consumer, the merchant need only display a single "buy" or
>## "pay" button even as the merchant adds new payment schemes.
>## Without IOTP, you are generally reduced to having a button per
>## payment scheme and if the poor user clicks on the wrong one, the
>## transaction fails.
>
>## There is a "standards way" of solving this: the Accepts header.  But
>## Netscape and Microsoft, in their competitive scramble have produced
>## a very jumbled browers landscape out there as to what is actually
>## deployed.  In terms of 'acceptance', I think that waiting
>## around a couple of years for there to be an almost universally
>## deployed "standards way" of doing this is to guarantee little
>## acceptance of IOTP or anything else that encounters this problem on
>## the global Internet.  (They could, of course, always be used in
>## controlled pilot or intranet environments.)

The work of 'conneg' was motivated in part by a desire to extend and clean
up the expressive power of constructs like "Accept".  The root idea is that
features other than just content-type can be used to characterize a
recipient's capabilities, and the 'conneg' framework is a standards-track
mechanism to do just this.

What 'conneg' does not to is define a specific *mechanism* for
communicating capability information, as that was seen as something that
must depend upon the particular protocol used.

Given the extensible 'conneg' framework, defining a simple header to
indicate capabilities should be a relatively easy matter.  For Internet
fax, an additional field in an MDN may be used, and (in time) 'rescap' will
provide an alternative mechanism.  For HTTP, I can imagine a header like
'Accept-features:' that provides capability information.

For IOTP (and I don't know the spec in any detail) I would imagine that an
IOTP-specific field containing a 'conneg' string, and appropriate media
feature registrations as required for IOTP, might be used.

I am not trying to claim that 'conneg' and related work is the Right Way
for IOTP, just to ensure that it is not rejected for the wrong reasons.

>## I agee that the TRADE WG shouldn't care about a "general" solution to
>## this class of problem. But I havn't figured out a way to construct a
>## solution such that the type of solution only works for applicaiton/iotp.

Well, yes, exactly.

#g

------------
Graham Klyne
([email-masked])

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]