Editor's note: These minutes have not been edited.
HTML Working Group Meeting, Monday, March 4th, 1996
Eric Sink welcomed people to the meeting, and introduced Area Director John Klinsen.
JK: If the practice in industry is broken, we should be leading; else
solidifying behind them. Currently, though, not a healthy situation. What purpose does this WG, or a successor, serve?
1) Forget about HTML in the IETF
2) Numbered versions may be hopeless
3) Can we do feature-based discussions? (after
implementation) And then leave numbered versions to 'someone else' (the 'applicability statement' approach in IETF-speak (i.e. Chinese menu)).
Parting shot: if not tied to market, the WG has no role at IETF.
ES: No formal agenda. "This working group as it lives cannot go
on". He's got a new .sig from Cosby: "The key to failure is trying to please everyone" Open comment forum.
Question from the audience, unidentified: What's the current charter?
ES: Hasn't been revised since group formation. As written, asks WG to lead the
standard. "I humbly assert that this charter has not been fulfilled."
[Charter read]
Brian Behlendorf: What is the role the W3C wants to play in HTML
standardization, and how does that work with the IETF model?
Dave Raggett: The W3C's role is to lead the development of HTML in
coordination with vendors. W3C can provide first-pass collaboration on standards docs to hand off to the IETF.
Ted Hardie: the real question is interoperability.
DSR: The vendors, whose fault this is, are very interested in maintaining
interoperability.
JK: W3C seems to not be doing better than us here. The W3C, though, has
charter to go off ahead of the market, which this WG is not currently defined to do.
Murray Altheim: Fundamental question is, must HTML continue to be
specifed as a DTD? This is not current practice, and if both orgs are not requiring DTDs and SGML compliance. If only 5% of docs validate, we're irrelevant to begin with.
DSR: AFAIK, there is no pressure from the people I am working with to move away
from 'HTML-as-SGML-application'
MA: pragmatically, the industry is not moving towards valid documents.
Dirk vanGulik: even if people buy DTDs, what about people who don't take the
organizational infrastructure that an SGML system provides.
Alex Hopmann: the fundamental problem is describing what is being done
[even reverse eng!] To some degree, we're going to have to go do these vendors' work for them.
Larry Masinter: I'm reacting negatively to the assertion that vendors aren't
"here" and don't participate. 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.
Three poll questions: What results to record?
DSR: I suggest that it might be very relevant to have a new WG later, in
6 mos or so.
Paul Hoffman: 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.
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.
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.
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: if we don't a WG, how do we contain vendor fragmentation?
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: 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: Wait, IETF WGs have fixed issues, start and finish
dates. The IETF does not have a mechanism for a permanent review board.
Marc Hedlund: 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: 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: 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]