CURRENT MEETING REPORT
Reported by Eric Sink, Spyglass, Inc.
Minutes of the Hypertext Markup Language
Working Group (html)
SESSION ONE
Eric Sink welcomed people to the meeting,
and introduced Area Director John Klinsen.
The following discussion ensued.
John Klinsen stated that if the practice in industry is broken, then we should be leading or else solidifying behind them. Currently, though, it is not a healthy situation. It was then asked what is the purpose of this working group (or any of its successors). The following ideas were put forth:
We concluded that if we are not tied to
the market, this working group has no role in the IETF.
Eric Sink noted the lack of a formal agenda
for this group. In light of this situation, the HTML Working Group
cannot continue. He's got a new .sig from Cosby: "The key
to failure is trying to please everyone." An open comment
forum followed.
The following questions and responses followed.
What's the current charter?
Eric Sink (ES): Hasn't been revised since group formation. As written, it allows the working group to lead the standard. It seems quite evident that the charter has not been fulfilled. (The charter was then read to the group)
What is the role the W3C wants to play
in HTML? Also, how does standardization work with the IETF model?
The W3C's role is to lead the development of HTML in coordination with vendors. W3C can provide first-pass collaboration on standards documents to hand off to the IETF.Ted Hardie suggested that the real question is interoperability. It was then noted that the vendors, whose fault this is, are very interested in maintaining interoperability. Klinsen stated that W3C seems to not be doing better than this working group. The W3C, though, has a charter to go off ahead of the market, which this group is not currently defined to do.
Murray Altheim stated that the fundamental question is, must HTML continue to be specifed as a DTD? This is not current practice, and if both organizations are not requiring DTDs and SGML compliance and if only 5% of documents validate, we're irrelevant.
One attendee noted that there is no pressure from the people he is working with to move away from 'HTML-as-SGML-application.' It was then noted that, pragmatically, the industry is not moving towards valid documents. Dirk vanGulik said that even if people buy DTDs, there are those people who don't take the organizational infrastructure that an SGML system provides. Alex Hopmann suggested that the fundamental problem is describing what is being done and that, to some degree, we're going to have to go do these vendors' work for them.
Larry Masinter (LM) reacted negatively to the assertion that vendors aren't "here" and don't participate. He feels the main point is that we have made some progress on particular features: I18N, etc. We've also had real difficulty with numbered versions, but applicability statements might work.
Dave Raggett (DSR) suggested that it might
be very relevant to have a new working group in about six months
time. Paul Hoffman (PH) asked how much W3C work is going to be
open to view in the next few months? How can we advise people
on proposals by reference to old mailing lists, etc.
DSR: we make WDs freely available. Smaller
groups may choose their own policy for disclosure.
PH: examples?
DSR: INSERT, stylesheets.
ES introduces the W3C "Editorial Review
Board", and now is speaking as ERB chair, not W3C chair:
The W3C wishes to state that they will take a leadership role,
but not be a standards body. W3C has actually got all the people
talking to each other, to develop new *specs*, not standards.
They are not claiming the same bredth of support and review the
IETF could.
One of the big str. of the IETF is that
everyone knows how the process works, and some vendors ignore
it; the W3C is a vague process, but does work.
Alex Hopmann (AH): Since the W3C is slow
to contribute to I-D and list archives, it's easy for people to
not know what's going on.
Bert Bos (BB): The real problem is that
we have a very piss-poor platform for the evolution of HTML today,
and that is server manipulation of data based on the HTTP "User-Agent"
field.
ES: It may be a good thing to not have a
WG for 6 mos, and find how much we needed it.
LM: In my view, text/html is only one of
many internet media types that we ship around. People traffic
in proprietary media types all the time... (examples: PostScript,
PDF, GIF) We generally understand vendor-specific formats. HTML
has taken on a unique role that IETF might standardize an internet
media type.
Murray Altheim (MA): The W3C has the vendors
behind them, they will be the prime specification house, where
they will dump specs in our laps. If anyone believes that true
public discussion can happen AFTER the vendors have agreed, that's
delusional. I'm not sure there's a dialogue there, and I don't
want us as a rubber stamp.
Josh Cohen (JC): if we don't a WG, how do
we contain vendor fragmentation?
Ted Hardie (TH): As a content provider,
I see that W3C is anxious to move HTML forward with vendors. This
group has a role as a forum for publishers, to test 'cores' and
interop testing.
Keith Moore (KM): Here's my list of what we can do: the vendors have incentives not to announce until shipping, etc and we need to counteract such messes.
1) document existing practice
2) recommend containment policy for vendor messes
3) where there are multiple solutions, offer criteria
4) sanity check proposals in advance
5) feature profiles
ES: The W3C is very interested in exactly
that.
ES: I'm hearing 2 purposes for this WG:
1) a front-end that leads HTML (may not be successful; tried this)
2) a back-end group, testing, standardizing,
resolving conflicts
MA: There's a third, version numbering (FPIs).
We can't issue versions fast enough for vendors... we have a 2.0
dtd, an i18n dtd. If we use those as reference DTDs to build upon,
and then come up with a modular way to add features, and negotiatie
them. This issue is good work for us, and allows for healthy communication
among all parties.
Harald Alvestrand (HA): Wait, IETF WGs have fixed issues, start and finish
dates. The IETF does not have a mechanism
for a permanent review board.
Marc Hedlund (MH): In addition to Althiem's versioning, guidelines for usage
and design considerations.
Stef(?): The obvious problem is the relationship
between W3C and IETF. Where does the responsibility for failure
lie -- can we unambiguously put the responsibility on the W3C
-- they're getting paid to do it, and we're getting dragged around,
and should be not be held resp.
Pete Resnick (PR): This is very odd: in the mail groups, we don't dictate to Eric
Allman. We can be a [good housekeeping seal]
to critique the practice. Create new feature-based groups to review
W3C proposals, keep creating and destroying groups as we go.
ES: WGs are supposed to end -- in fact it's a success to close one out.
2nd, WGs are VERY expensive!
TH: One of the IETF/W3C problems is that
W3C keeps quacking and won't say duck they do most of a standards
body's work without having to clean up and ask for compliance
-- the IETF can have much more open membership and take proposals
from much more than vendors. We do have a very serious INTEROPERABILITY
problem to be addressed.
PH: A reasonable place for this WG to stop
is to ratify a platform to experiment upon -- this is the story
of successful standards. We need to come up with an extensible
HTML base, and stop the WG. New WGs could form and go further,
especially when 'bad' extentions come up.
JK: Note that the consortium has said duck
many times, just not in the presence of the IETF. Second, what
exactly are you suggesting for a Base target.
BB: 2.0 would not be a good base: it's not
yet a good compound document standard. Tables, objects, I18N,
some others needed, but some HTML 3.0 elements can be ditched.
Example: math support, lots want it, but not all -- make math
a media type of its own, which can be embedded.
ES: Assert: the IETF cannot solve the interop
problem, nor can the W3C. The list of people who care about HTML
is vastly longer than for almost any other IETF issue.
BB: Without interoperability, what good
are standards?
LM: This WG has to complete the work in
progress and close: style sheets, tables, insert, I18N, and converge
all of these together and maybe a modular mechanism for adding
extensions.
KM: What's done we should finish, and give
ourselves one more meeting, and that's it.
JK: E-mail has as large a consumer base
as the Web. If the difference is the rate of change in this market,
then we have to accomodate this.
ES: "The general level of cluelessness
among people who care about HTML is astronomical"
PH: Well, perhaps people who are offended
by the lack of standards should go beat on the people paid to
work on it. We don't have 3.0 frameworks, etc. If the W3C screws
up, we can return.
MH: Well, not all extention proposals emanate
from W3C...
KM: Trying to develop new standards in a
group this size is not gonna work.
DM: Critical need: we need a conditional
in HTML. We know "User-Agent" doesn't work, so how about
client-side processing.
Roy Fielding (RF): What's wrong in HTTP
neg, is that it assumes that there's a way to label content --
text/html is meaningless. The ideal use of this group is to label
HTML, and I like Murray's start in this area.
MA: If we can use the public text identifier
to indicate feature, status, and owner, and reuse auch strings,
that would be good progress.
ES: I want this to also be a low-risk WG.
I don't want to push forward with a possibly-irrelevant proposal.
JK: People want something: 1) either a rigid
version number or 2) feature lists.
ES: Who out there are content providers?
PH: There is great interest among server
vendors to compete on features. There is strong commercial demand
to follow standards, so the feature list can get longer, and some
products tick off more of them. I think this is lower risk than
you think.
ES: 1) close this group 2) create a new
group on negot. (a bounded, finite problem!)
MH: Let's look at existing systems for content
negotiation: Insert/embed, frames, etc are already doing conditional
text. Can we learn from those examples, perhaps use their syntax
for a more general conditional HTML framework?
LM: HTTP feature set negotiation is needed
for many internet media types. TIFF parameters, even general ones:
color, res, printer res, etc. There are *many* non-DTD feature
sets: color, URI types supported, etc -- not grammatically limited
by media type.
BB: Yet it is a hallmark for well-designed
media types that they themselves degrade gracefully. Example:
GIF89a animations which appear as regular gifs in browsers which
support GIF but not animated GIF. HTML should be like this.
MA: What about a new WG on feature set negotiation?
ES: we could drive through a close-up of
this group. This is a charter upgrade to doing a PS, perhaps.
finish-what-we've-started will take a lot of effort.
HA: take this Thursday slot and do two things
1) Feature-negotiation BOF-like discussions
2) Triage on current tasks. Triage slides for the "htmlfinishwhatwestarted"
group - to obtain a base HTML core and close the WG
[On each subject, much discussion took place,
which was hard to take down as easily... the summary is below]
Internationalization (existing I18N proposal):
YES
Object/Embed/Applet: Wait for W3C to release
spec they are happy with, if non-controversial, then YES, otherwise
punt.
Tables: YES
Stylesheet Embedding proposal: No resolution.
No hope that debate about "Style" attribute could cease.
Let W3C coordinate vendors in this area for interoperability.
Style sheet syntax is out of scope.
Form File Upload: YES (draft spec well on
its way to RFC, implemented)
Client-Side Imagemaps: (Eric added it to
the list but crossed it out. Discussion about how resistance to
proposed spec was more political than technological - no resolution)
Specifically tabled:security considerations (sec-html)
REL, REV attribute defn'sFrames (listed
in a sub-frame :-)
ES: Look, the so-far-unnamed vendors are
Netscape & Microsoft, and they most want to work W3C
BB: Object is *essential* to a credible
base standard - basis of a real compound document architecture.
Terry Allen moves that security and REL
and REV be reserved, but not standardized.
HA: If there is no open document of the
semantics of some feature, then it is a candidate for deletion
from the spec.
Concluded, to be continued Thursday.
SESSION TWO
Chaired by Harald Alvestrand (Eric Sink
not present)
(Minutes not as complete as last meeting's)
More discussion about Murray Altheim's FPI
proposal - "we need to solve the naming problem".
Larry Masinter: Once we have a true conditional
HTML system, use HTTP content negotiation to solve the backwards-compatibility
problem by labelling conditional HTML "text/c-html"
for example.
Terry Allen would prefer to have conditionals
switch on content outside the document rather than contain the
conditionals alternate between content within the document itself.
Harald proposes a chart of the solution
space, with descriptions to be posted by March 15th:
DTD identification
Murray to further revise draft document
Marked Sections
Dan Connolly's post to HTML-WG in the previous few days can serve as the base, should be extended and illustrated, best of all implemented
Feature set ID
What does the feature set domain look like? From a browser perspective. - Brian B.
Other conditional HTML systems
Methods other than marked sections - why are they insufficient? Processing instructions?
Multipart MIME-related? - David Morris
Server-side conditionals
Properties of conditionalizing HTML on the server - Rohit Khare
Harald: New working group on negotiation framework? Any volunteers?
Brian B. To write charter proposal, but can not chair or edit drafts. Due 3/22.
Discussion about proposals on the table for the WG ensued:
The Hyperlink proposal, definitions for attributes to REL and REV.
Terry: We need this.
Brian: There are costs to standardizing this - it suddenly defines the
"World Wide Web Link Model", something that seems out of scope of HTML Roy: This needs editorial work.
No resolution.
Internationalization (I18N)
Larry: There are still unresolved issues about default form input encodings - what is the charset? Different if in POST or GET. (discussion about how Unicode is insufficient or unacceptible) Redefines RFC1766? Still more work needed.
Embed/Insert/Object
Confusion about the status of drafts - are there two? Has "insert" changed to "object"? "We can't make any progress since the W3C owns change control over the draft". Proposal made to remove draft from the archive - others agreed. Wait until W3C can produce another draft.
File Upload
Labeled Experimental in the RFC submission process - Netscape 2.0 does not implement completely - do we need a revision? Larry will update draft.
Style
No consensus.
Meeting concluded.