Re: Updated agenda
To: Jim Whitehead <email@example.com>
Subject: Re: Updated agenda
From: "Daniel W. Connolly" <firstname.lastname@example.org>
Date: Tue, 09 Jul 1996 09:24:53 -0400
cc: Larry Masinter <email@example.com>, Dennis Hamilton <firstname.lastname@example.org>, Lee Farrell <email@example.com>, Dave Long <firstname.lastname@example.org>, Christopher Seiwald <email@example.com>, Ralph Ferris <firstname.lastname@example.org>, Kenji Ota <email@example.com>, Henrik Frystyk <firstname.lastname@example.org>, Keith Dawson <email@example.com>, Tom Wills <firstname.lastname@example.org>, Bruce Brown <Bruce@sb.aol.com>, Ron Fein <email@example.com>, Andy Schulert <firstname.lastname@example.org>, Ed Burns <email@example.com>
From firstname.lastname@example.org Tue Jul 9 09: 23:36 1996
In-reply-to: Your message of "Mon, 08 Jul 1996 18:15:32 MST." <email@example.com>
In message <firstname.lastname@example.org>, Jim Whitehead writes:
>At present, there are 15 confirmed attendees for the San Mateo meeting,
I'm sorry I won't be there.
But I'll try to get my two cents in via email here...
>Here is an updated agenda for the meeting
> - Introductions
> - Overview of efforts to date on distributed authoring
I suggest you put this overview before the business of defining
the group. Perhaps put the talks here too.
> - Discussion of the direction and purpose of the working group
Just to reiterate: it's not a W3C working group yet. For details
on how a W3C working groups works, see:
But that shouldn't stop us from using the w3c-dist-auth mailing list,
since it has a handy archive.
In particular, we have to nail down the following:
1.The overall goal of the group;
2.Criteria for completeness of the group's work;
3.Deliverables with target dates;
5.Expected amount of W3C resources which the WG will take to run;
6.Commitments from non-W3C staff upon which the running of the WG is
Here's my take on the above:
1: make web editing as reliable as browsing, and nearly
2: the group is done when there's shared understanding of
distributed authoring mechanisms in the development
community and the market. For example, the top
3 to 5 editing clients and servers all interoperate
according to published specs.
3: here's a guess:
spec: "Considerations for authoring tool support
in HTTP servers" (covering issues like
Derived-From/Version, reliable PUT, etc.)
code: server that supports the above (based on jigsaw)
spec: "Editing Hypertext" (covering issues
like re-writing URLs during cut/paste, save-as)
code: client that supports the above (based on Amaya)
spec: "On Link Maintenance in the Web"
(covering things like linkmaps,
server-to-server link maintenance protocols,
and authoring tool support for redirects)
code: client/server support for the above
4: based on acceptance of a (short: one page) position paper
from Jim and the rest of the group.
5: W3C is probably in a position to contribute
1/5 FTE Jigsaw engineer, 1/2 FTE Amaya engineer,
plus supporting Jim W. as chair.
In particular, the Amaya group (led by Vincent Quint at INRIA) is
going to be the main W3C resource for this effort. Be sure to take
good minutes, since I won't be there, and we don't plan to have Henrik
do much of the follow-up work on this.
6: 10 FTEs from each of the vendors :-) Just kidding... but
please do be concrete (and generous!) about this part.
> - Identification of key areas in which existing systems are unable to
>interoperate (e.g., HTTP method employed to write contents, access control,
About access control: I see on the group page, I see:
The breakout session at WWW4 recommended not pursuing a common access
control scheme and interface across HTTP servers. This is a mistake.
Due to the importance of access control, and its centrality to the
content control process at many organizations, an access control
standard is one of the most important artifacts that should be
generated by this working group.
I suspect there has been a misunderstanding. We didn't agree that
there would be _no_ common access control _interface_: in fact, we
pretty much agreed that the interface would be a button that takes you
(by following a link constructed by convention from the page's address
ala the way NaviPress does it) to a form where you can do access
control administration. So a spec for that would be dandy.
But a common access control model? Will it be capabilities or access
control lists? This has been an open problem in distributed systems
for tens of years. It was the model in the server that we recommended
against persuing at WWW4. We don't expect to solve this long-standing
problem, do we?
> - Review of current distributed web authoring systems and the mechanisms
> o Invited talk: Henrik Frystyk on Amaya, PUT model
> o Invited talk: Dave Long on GNNpress/GNNserver
> o Invited talk: Andy Schulert on FrontPage
As time is short, I would like folks to concentrate on the
_differences_ between the systems, and in particular: the non-standard
features/mechanisms in the systems.
At the WWW4 break-out, we were able to triage the features fairly
(a) those that don't interfere with interoperability
and should remain features to compete on
(b) mechanisms that aren't covered by the standard, but
(c) mechanisms that _are_ covered by the standard, but
couldn't be used in practice due to limitations
in the installed base of cruft... er... software.
Experience reports about particularly tricky parts of implementing the
standard is really valuable as "advice to implementors" as well --
after all, we're after reliability in practice, not just a nice spec.