LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Proposal: HTML Extensions Registry (Was: HTML extension version numbers)
From: [log in to unmask] (Murray Altheim)
Reply-To:[log in to unmask]
Date:Thu, 28 Sep 95 19:39:12 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (247 lines)



[Joyce Reynolds, IANA: your attention to question #1 at the bottom of this
document is requested. Thank-you!]

Dennis J Bouvier <[log in to unmask]> writes:
>Given:
>   1. HTML 2.0 is relatively stable (yeah!).
>   2. Extensions to it are forthcoming in an unknown order.
>
>Problem:
>   A version number system that can be defined now but accept
>additions in any order.
>
>Proposed Solution:
>
> An encoding of "feature flags" into version numbers.
[...]
>This numbering system limits the number of extensions to 6 [...]

If we begin building the HTML (or any other SGML language) feature set
completely from modules, we'll need many more than six options. DocBook 2.3
has quite a few, and it was a fixed delivery date document, where multiple
extensions from multiple authors were not an issue.

The problem with feature flags, hex or decimal, is that they attempt to
catalog HTML extensions based on the arbitrary chronology of the draft
approval process, while still not addressing the question of a naming
authority. For example, even if the requirement is to designate what power
of two or ten to attach to the HTML tables draft, we still don't have an
authority to perform that task, or to arbitrate disagreements, vide the
flak over the 2.x/2.1 labelling of i18n. Flipping a coin is not a solution
-- we can't assume a feature set to remain stable for any length of time.
The industry will always demand the "next best thing", and we need a method
for incorporating extensions to the core DTD while in a less than "proposed
standard" status.

I here submit an alternative HTML Extensions Registry proposal based on
suggestions from John Beck to look into the SMTP service extensions
solution. If acceptable, this proposal will be incorporated into the
Modular DTD proposal I am currently drafting. Please pardon the length -
I'm going to cover a fair amount of territory:

---------------------------------------------------------------------------
John Beck <[log in to unmask]> writes:
>Murray wrote:
>> I certainly lean on the side of feature set designation, but
>> apart from RFC numbers, I don't see a recognizable/standardizable scheme.
>> We would still need a naming authority, unless some existing character
>> string from each draft (name/number/version/content, etc.) could be used
>> as the designation.
>
>ESMTP, IMHO, solved this problem, or one much like it, quite well.
>RFC 1651 specified how extensions would work in general, then each
>subsequent extension (RFCs 1652, 1653, possibly others) defined
>their own extension keyword.  A similar extension mechanism for IMAP
>was adopted at the Seattle IETF meeting in March 94.
>
>I respectfully submit that such a keyword-list method would work quite
>well.

John, I've looked into the RFCs you recommended, and I agree. John Klensin
actually has a more recent "SMTP Service Extensions" draft that supercedes
RFC 1651 [SMTPEXT]. I think this may be the ticket we're looking for. One
hitch still remains: name registration.

As with SMTP, we would increment the HTML version number based on
fundamental changes to the "core" DTD only (version numbers would *not*
increment for HTML extensions), with all extensions indicated by registered
keywords. HTML extension authors would register their extension with the
IANA and receive (or propose?) their four character mnemonic, which would
henceforth be used to declare the extension.

------ excerpt from [SMTPEXT] -------

5.  Initial IANA Registry

   The IANA's initial registry of SMTP service extensions consists of
   these entries:

   Service Ext   EHLO Keyword Parameters Verb       Added Behavior
   ------------- ------------ ---------- ---------- ------------------
   Send             SEND         none       SEND    defined in RFC 821
   Send or Mail     SOML         none       SOML    defined in RFC 821
   Send and Mail    SAML         none       SAML    defined in RFC 821
   Expand           EXPN         none       EXPN    defined in RFC 821
   Help             HELP         none       HELP    defined in RFC 821
   Turn             TURN         none       TURN    defined in RFC 821

------ end of excerpt -------

I would recommend this becoming:

x.  Initial IANA Registry for HTML Extensions

   The IANA's initial registry of HTML extensions consists of
   these entries:

   HTML Extension            Keyword       Reference
   ---------------------- ------------ ---------------
   Tables                     TABL         [RFC xxxx]
   Math                       MATH         [RFC xxxx]
   Internationalization       I18N         [RFC xxxx]
   Client Side Image Maps     IMAP         [RFC xxxx]
   Form-based File Upload     UPLD         [RFC xxxx]
   Embedded Document Types    EMBD         [RFC xxxx]


We _could_ specify a change to the MIME headers to cue servers that they
should check for specific extensions. Of course, they _should_ be parsing
the DOCTYPE for this, but apart from one UA previously mentioned, this has
been ignored in the past.  On conversation with Terry Allen, it seems no
formal registry of FPIs has been proposed to the IETF (if I'm wrong I'd
love to be contradicted). We need both FPI registration plus either an
implemented URI/URN suite or a temporary HREF inclusion to allow UAs to
locate the necessary DTD files. Since the latter is both stopgap and
serviceable I would advocate the inclusion of a URI (sic URL) entity to
define a location for the DTD. Alternatives are welcomed.


EXTENSION REGISTRATION

The specific mechanism for SMTP service extension registration is well laid
out. I have excised and added to the text of [SMTPEXT] to illustrate my
proposal. This assumes IANA involvement (obviously):

    "The IANA maintains a registry of HTML service extensions.
    Associated with each such extension is a corresponding keyword
    value. Each service extension registered with the IANA
    must be defined in an RFC. Such RFCs must either be on the
    standards-track or must define an IESG-approved experimental
    protocol.  The definition must include:

     (1)   the textual name of the HTML extension;

     (2)   the keyword value associated with the extension;

     (3)   the syntax and possible values of parameters associated
           with the keyword value; [see Q#2 below]

     (4)   a complete DTD specifying the extension;

     (5)   how support for the extension affects the behavior of a
           server and client [HTTP/HTML].

    In addition, any keyword value that starts with an upper
    or lower case "X" refers to a local SMTP service extension,
    which is used through bilateral, rather than standardized,
    agreement. Keywords beginning with "X" may not be used in a
    registered service extension.

    Any keyword values presented in the EHLO response that do not
    begin with "X" must correspond to a standard, standards-track,
    or IESG-approved experimental HTML service extension
    registered with IANA.  A conforming server must not offer non
    "X" prefixed keyword values that are not described in a
    registered extension.

    Additional verbs are bound by the same rules as EHLO keywords;
    specifically, verbs begining with "X" are local extensions
    that may not be registered or standardized and verbs not
    beginning with "X" must always be registered." [SMTPEXT]


As an aside, I think we'd all do well to heed Klensin's admonishments from
the SMTP extensions draft. I've substituted HTML for SMTP to make the
point:

   "It must be emphasized that any extension to the [HTML] service
    should not be considered lightly. [HTML]'s strength comes
    primarily from its simplicity.  Experience with many protocols
    has shown that:

         protocols with few options tend towards ubiquity, whilst
         protocols with many options tend towards obscurity.

    This means that each and every extension, regardless of its
    benefits, must be carefully scrutinized with respect to its
    implementation, deployment, and interoperability costs. In
    many cases, the cost of extending the [HTML] service will likely
    outweigh the benefit." [SMTPEXT]

A few questions remain:

 #1. How would we go about registering HTML extensions with the IANA?
     What type of proposal needs to be made to move this forward? Is
     this something I can/should do, or would it be better for Eric
     as chair of the HTML working group?
 #2. If we go about registering extensions with the IANA, should we be
     including anything besides name, keyword and ref'd RFC? Any other
     parameters?
 #3. What types of proposed changes would be considered extensions, as
     apart from the changes that would increment the HTML version number?
 #4. In the absence of an FPI/DTD registry and dissemination service,
     suggestions on how to appropriately include the URL to each fragment
     DTD is needed. Is this another issue for the IANA? Who else could we
     turn to?
 #5. Some language changes ("service extensions" vs. "extensions"), etc.
 #6. Should we follow the extension naming lead and use "X" prefixed
     keywords for experimental extensions? Pro/con?


This whole ball of wax is completely irrelevant if we go about business as
usual (ignoring DOCTYPE, FPI, MIME header info, etc.), and then have no way
of specifying a 2.0+ feature set. I don't have an all-encompassing content
negotiation scheme, that's why I'm bringing this to the table. We have a
lot of good minds here and I believe we can find a viable solution.

I agree entirely with Amanda's recommendation to stick with an SGML
solution for factoring DTDs. I also agree with many that by next year we
will actively be seeing and using SGML browsers. I hope to make this
proposal part of that evolution.

Parsing the document for a META element is really ugly, and I would not
endorse it as a solution, or even recommend specification language to even
obliquely endorse such behaviour. We do need to assume that a "new way" is
necessary, as the current methods will not support "very complex documents
containing highly structured or compound content" [AWALKER] unless the
entire currently proposed feature set suddenly and simultaneously reaches
the same status and stability as HTML 2.0. We will always be dealing with
feature sets at different stages of development. Hopefully the Modular DTD
draft will address these issues in a simple and attractive way that allows
for incremental growth.

As stated above, if the above proposal sounds good to others, I will
incorporate these ideas in the Modular DTD draft. As always, suggestions,
comments, criticisms welcome.

--Murray

[SMTPEXT]  J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.
    SMTP Service Extensions, (August 27, 1995).
   <URL: ftp://ietf.cnri.reston.va.us/internet-drafts/
           draft-ietf-smtpext-extensions-05.txt>

[AWALKER] Amanda Walker <[log in to unmask]> Thu, 28 Sep 95 12:38:15 EDT
    "Re: proposal: HTML extension version numbers"

__________________________________________________________________
      Murray M. Altheim, Information Systems Analyst
      National Technology Transfer Center, Wheeling, West Virginia
      email: [log in to unmask]
      www:   http://ogopogo.nttc.edu/people/maltheim/maltheim.html





Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager