| 3. Tables
|
| A draft was released just before the deadline for this meeting.
| Few had read it. None of those who had read it had problems
| with it. Two people felt that they might have commenst if they were to
| read i. The draft will be left for review on the net for 30 days
| and then be sent to the IESG for last call for proposed standard.
| (STTIESGFLCTPS)
Presumably it will be sent for last call only if consensus develops
around it?
| The metadata fields have been in discussion and flux for so long it
Discussion by whom?
| There is a real proposal for metadata syntax in the URC group.
| There is a solution to resolve the unknown HEAD element but
| it involves look-ahead (-LM).
What does "unknown HEAD element" mean?
| 5. SUP-SUB
|
| The current consensus allows no nested SUP and SUB but does allow
| anchor and highlighting within a SUP or SUB.
As I understand it from having been told, consensus may be reached
only in email, not at meetings. Please correct me if I'm wrong.
There's no consensus in email at all on this issue; I posted a short
note in response to Eric's agenda earlier this month, and never
saw any response.
| Stu Weibel will put this consensus into a very short draft by Aug 1.
Then we can develop consensus. (Stu, anything you do on this is
okay by me.)
| 7. Internationalization.
|
| Currently Netscape and Spyglass Mosaic will accept different
| character encoidings. They use a user-overridable heurstic to
| guess the character set, but will work properly if they
| see a charset= parameter on the MIEM content-type.
| No one in the roomwas doing anything to further any spec writing here,
| and previous volunteers had gone quiet. Dan Connolly volunteered
| to see to the writing of a spec for the charset parameter, by delegation
| or action as need be, by December.
|
| Language tags were a different issue. They should not be lumped
| together with "charset" or SUP/SUB as one would hold the otehr back.
| Some work on laguage tags has been done and should be
| disenterred.
|
| There is a problem with unicode that it uses the same code to
| represent different glyphs as a function of the language being Chinese
| or Korean. EBT solve this problem by regarding it as a font
| choice issue in a style sheet. Noone else had a solution.
I believe this is where you need to know what language you are in.
So language attributes may well be needed. Glenn Adams, some
mail to you bounced recently; are you still around?
| Dirk-Willem van Gulik/Centre for Earth Observation of the EC
| offers a database of multinational documents
| as test data to developers in the group.
|
| 8. Any Other Business
|
| Ther is a draft (*eastlake*) on putting information about
| payment into HTML etc.
There are four eastlake drafts; according to the text of
draft-eastlake-internet-payment-00.txt
it's the only one that involves HTML, specifically sections 4.3 and 4.4,
which I excerpt here. Note that the proposal that info in the HTML
should condition access might be generalized to cover other conditions
(use of required style sheet, refusal of involuntary transclusion).
4.3 Page Header Price Tag
The cost for accessing an HTML page can be included in the header.
For example:
<HTML>
<head><title>Mating Habits of the Red Breasted Geek</title>
<cost> 0.75usd 0.99cad cybercash:A8jne8W2/sw== </cost></head>
<body> ... </body></HTML>
An attempt to get such a document without payment or with inadequate
payment should fail (see Payment Required Error section below). A
second attempt with payment will be required. This could be done in
a manner similar to an access restriction failure followed by a
second attempt with access authorization information.
Implementing page header cost requires that the HTML for a web page
be partly understood by the server, at least through the head, but
this is necessary to implement the "title:" and "link:" response
entity header fields anyway.
4.4 HTML Form Price Tags
A cost can be associated with a form and with multiple choice items
within the form. For example:
<form COST="CyberCash:A8jne8W2/sw== 0.75usd 0.99cad" ACTION=POST>
Miscellaneous text, etc.
<input type="radio" name="extras" value="omit">plain vanilla
<input type="radio" name="extras" value="include"
COST="0.25usd 0.40cad">chocolate fudge
<p>Your quality of service: <select name="quality">
<option value="bronze"> Low<p>
<option value="silver" cost="0.10usd 0.17cad"> Medium<p>
<option value="gold" cost="0.20usd 0.34cad">
High<p> </select>
</form>
The COST associated with the form is a base price to which any
multiple choice item costs are added. The form level COST may be
omitted and COSTs can still appear with multiple choice items. The
COST associated with a "select" is a default which applies only if no
item is selected. When an item is selected, it over-rides the
selection level cost and become the price component added into the
total form price for that selection.
The normally required payment system string can be omitted from some
of the form COST parameters, in which case any prices add to the
amount for all payment systems. But one or more payment systems and
their payment system specific parameters must be determinable if any
payment is to be sent. The payment system specific information
associated with the last encountered instance of a payment system
field in processing the form is used. If no payment system field is
encountered, then no payment will be sent with the request even
though "COST=" parameters are present.
As with anchor costs, it is desirable to indicate the cost of
multiple choice items by color coding and the cost of activating the
form by color coding the submit button. Note that the submit button
could change from free to toll or the like as choices are made in the
form.
Regards,
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 101 Morris St. Sebastopol, Calif., 95472A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html