Frederic
> From www-talk@www0.cern.ch Thu Aug 25 21:23 MET 1994
> Date: Thu, 25 Aug 1994 21:19:59 +0200
> Originator: www-talk@info.cern.ch
> From: "Daniel W. Connolly" <connolly@hal.com>
> To: Multiple recipients of list <www-talk@www0.cern.ch>
> Subject: Re: Client Compliance
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>
> In message <8317.199408251852@discovery.brad.ac.uk>, "Mark Cox" writes:
> >
> >What we ought to start then is a definative compliance list! Hopefully
> >when clients as popular as "WinMosaic" see they are fairly low in
> >the table they will be motivated to improve!
> >
> >| 3. We need a way for users to know which client to choose to
> >| depending on independent conformance testing.
> >
> >Which does imply that we have standards that everyone adheres too - the
> >Location/URI http header stuff is all to common. Is this a function
> >of the new W3O?
>
> Eventually, perhaps yes.
>
> But I personally prefer the Linux development model: a motivated
> individual senses a need, and takes the initiative. If thier specialty
> is technical, they write the code. If they're effective communicators,
> the write doc. If they're good organizers, they coordinate the effort.
>
> The WWW is much the same. Folks that see a need march forward and fill
> it.
>
> Your choice is to wait until commercial entities fill the void. If you
> wait for that, you deserve what you get. :-{
>
> Building this information infrastructure is a huge project. I suspect
> W3O will have its hands full just coordinating things. Progress and
> functionality enhancements will remain the responsibility of the community
> at large for some time to come.
>
> Dan
> From www-talk@www0.cern.ch Thu Aug 25 23:46 MET 1994
> Date: Thu, 25 Aug 1994 19:38:46 +0200
> Originator: www-talk@info.cern.ch
> From: Martijn Koster <m.koster@nexor.co.uk>
> To: Multiple recipients of list <www-talk@www0.cern.ch>
> Subject: Re: Client Compliance
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>
>
> > We need some sort of "Compliance Test".
>
> Absolutely. But until there is a rigid standard it is difficult to
> comply with it. When the standards arrive I'm sure companies will
> start quoting compliance, which one can test.
>
> > The Compliance level should be sent from the client along with the
> > standard User-Agent field. "Hi, I'm XYZZYBrowser version 2.2, I can
> > handle forms as long as they are not Posted to authenticated areas
> > and I use the file extension instead of the mime type for working
> > out inline images apart from that I'm compliant with HTTP X.Y and
> > HTML Z.X"
>
> That's a complete waste of bytes, IMHO. One can use the User-agent
> string to index a list describing compliance; there is no point
> sending it with every request. Besides, there is no way to add
> to the User-agent once it's fielded, so how usful would it be
> when new bugs are found?
>
> > You might think that clients would at least get "User-Agent" right,
> > its amazing how many dont...
> > You could argue that the User-Agent field isn't very important. But
> > so many clients are not fully-compliant with the standards - it's
> > useful to be able to tell a user of an interactive service if their
> > client will work at all. How? The only way is for me to have
> > a huge table of clients with reasons for them not being able to
> > handle the service
>
> Sure, what's so bad about that? Make that table available somewhere
> prominent so others can use it...
> > 2. Some of the problems are due to bugs in the clients and
> > I'm not blaming either the protocol writers or the browser
> > authors; we need a way of the server knowing!
>
> You want to build knowledge of every protocol bug in a client
> into the server? I certainly don't...
>
> 3. We need a way for users to know which client to choose to
> depending on independent conformance testing.
>
> -- Martijn
> __________
> Internet: m.koster@nexor.co.uk
> X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
> X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
> WWW: http://web.nexor.co.uk/mak/mak.html
>