[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:
> 1. HTML 2.0 is relatively stable (yeah!).
> 2. Extensions to it are forthcoming in an unknown order.
> A version number system that can be defined now but accept
>additions in any order.
> 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
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:
>> 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
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
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
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.
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
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
"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
#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
#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.
[SMTPEXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.
SMTP Service Extensions, (August 27, 1995).
[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]