- From: <amir.herzberg@il.ibm.com>
- Date: Tue, 29 Jun 1999 10:09:46 +0300
- To: Al Gilman <asgilman@iamdigex.net>
- cc: Ian Jacobs <ij@w3.org>, tmichel@w3.org, w3c-wai-ua@w3.org, Jacobs@w3.org, dd@w3.org, mpay_markup@il.ibm.com
Al: I'm copying on my response the mailing list as they should all be able to comment. Best Regards, Amir Herzberg Manager, E-Business and Security Technologies IBM Research - Haifa Lab (Tel Aviv Office) http://www.hrl.il.ibm.com New e-mail: amir@il.ibm.com New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL Please respond to Al Gilman <asgilman@iamdigex.net> To: Ian Jacobs <ij@w3.org>, Amir Herzberg/Haifa/IBM@IBMIL cc: tmichel@w3.org, w3c-wai-ua@w3.org, Jacobs@w3.org, dd@w3.org Subject: Re: [Fwd: UAGL/Micropayments dependency.] Please consider that WAI-PF also holds a dependency, here. The issues that we have raised with the X-Link working group about the model of link activation overlap the considerations here. Hopefully we can get X-Link to consolidate the behavior and information model for links. Some instant comments, however: It is not clear why there should be a text field for the price when the price is an amount in currency. Will XML Schema have a way for us to make this a typed currency amount by the time that micropayments are entering on service? If not, is the upgrade path to typed quantities clear? Rather than defining a behavior on the assumption of GUI use and adding special attributes for other uses, we would rather define the maximally refined process that works for phone, blind, etc. users with full consumer protection as the reference model and define quicker processes as shortcuts against the full process. Or at least that this kind of tradeoff should be considered. Al At 01:34 PM 6/28/99 -0400, Ian Jacobs wrote: >Hi Amir, > >Thank you for answering my question. I am looking at the 9 June >draft of the Micropayment Markup spec [1], in section 4.5, which >I believe to be the pertinent section. Some comments: > >1) The current text begins: > > "The price parameter, which takes a character string, > displays the amount and currency to the Customer." > > I propose that this be changed to: > > "The price parameter, which takes a character string, > specifies the amount and currency that the Customer > will be charged upon dereferencing the link." > > (Question: How does caching work? Is this dealt with elsewhere? > I'm sorry if this is not a pertinent question.) > >2) Perhaps there should be a reserved value for non-fee links. > For example, "0", with no currency specified. This would be > more international than "free", for example. > >Please let me know if these comments make sense. Thank you >again, > > - Ian > >[1] http://www.w3.org/TR/1999/WD-Micropayment-Markup-19990609 > >amir.herzberg@il.ibm.com wrote: >> >> Ian says, >> >> > There's a dependency between User Agent (Accessibility >> > Guidelines) and Micropayments: users agents must be able >> > to indicate to users that following a link will require >> > them to pay a fee. The question is how to indicate >> > to user agents that a link is a fee link. For example, >> >> Actually I believe we have addressed this perfectly well in the existing >> markup proposal. Specifically, per-fee-links have been defined in a >> _different_ way than regular (free) links. Indeed we even gave some >> guidelines as to how the user agent (in our case we call this agent the >> `per fee link handler`) is to indicate the fee. However of course for >> accessibility reasons, special per-fee-link-handlers may implement special >> ways of indicating fees (e.g. for blind users). In summary - I believe >> you'll find our existing recommendation is fine >> regarding this particular comment. Your feedback on this and other points >> welcome! >> >> Best Regards, >> Amir Herzberg >> Manager, E-Business and Security Technologies >> IBM Research - Haifa Lab (Tel Aviv Office) >> http://www.hrl.il.ibm.com >> New e-mail: amir@il.ibm.com >> New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL > >-- >Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs >Tel/Fax: +1 212 684-1814 >
Received on Tuesday, 29 June 1999 03:16:57 UTC