From timbl  Mon Oct 28 16:33:14 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06989; Mon, 28 Oct 91 16:33:14 GMT+0100
Date: Mon, 28 Oct 91 16:33:14 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9110281533.AA06989@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-interest@nxoc01.cern.ch
Subject: WorldWideWeb mailing list:  Introduction

We have (at last!) started the www-interest mailing list. Your name  
is, for one reason or another, on it. The list is a list for  
announcements about the World Wide Web (W3) distributed information  
system, mainly about

	   o	New online information available

	   o	New W3 software releases

If you do not want to be on this list, please accept our apologies  
and mail listserv@info.cern.ch with the message body 

	
	delete www-interest

If others wish to subscribe to this list, they should mail  
listserv@info.cern.ch with the message body

	add www-interest

There is a similar list, called www-talk, for developers of W3  
software. Members of www-talk get www-interest automatically.

If you have any queries for a human response, mail  
www-interest-request@info.cern.ch.

	Tim BL
__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155





From steved%bullwinkle@relay.eu.net  Mon Oct 28 18:51:28 1991
Return-Path: <steved%bullwinkle@relay.eu.net>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07169; Mon, 28 Oct 91 18:51:28 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA02040; Mon, 28 Oct 91 18:46:02 +0100
Received: from wupost.wustl.edu by mcsun.EU.net with SMTP;
	id AA09434 (5.65a/CWI-2.120); Mon, 28 Oct 1991 18:48:29 +0100
Received: by wupost.wustl.edu (5.65b/WUSTL-0.3) with UUCP 
	id AA20884; Mon, 28 Oct 91 11:45:35 -0600
Received: by bullwinkle.UUCP (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02000; Mon, 28 Oct 91 11:09:48 CST
Date: Mon, 28 Oct 91 11:09:48 CST
From: steved%bullwinkle@relay.eu.net (Steve Dieringer)
Message-Id: <9110281709.AA02000@bullwinkle.UUCP>
To: www-talk@nxoc01.cern.ch
Subject: add www-talk

add www-talk

Please note that my return address should be:
steved%bullwinkle.uucp@wupost.wustl.edu


From timbl  Tue Oct 29 10:03:11 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07413; Tue, 29 Oct 91 10:03:11 GMT+0100
Date: Tue, 29 Oct 91 10:03:11 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9110290903.AA07413@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: connolly@pixel.convex.com, www-talk
Subject: Re: status. Re: X11 BROWSER for WWW 

Dan,

> I've made some tangible progress on the X11 browser, so I though 

> I'd let you know.
> ...
> This code is not in any shape to distribute, or even show anybody.
> But it works, and it's pretty speedy. That's enough to encourage me  
> to polish it off.

Sounds like great progress! The TCL sounds interesting -- where did  
you get it? 


> [If you wan't my stuff, you'll have to be C++ capable. I can't
> think in C any more. :-]

Don't worry - we can handle C++, although for the line mode browser  
we wanted portability into places where C++ could not reach. That's  
why the common code (in WWW/Implementation) is all in C. Believe me,  
after writing the NeXT browser in Objective-C it was a wrench to  
conclude that it would have to be deobjectified.

> If you could round up some info on exactly what I can expect to see  
> in an HTML file, and some idea of how you want it formatted [I have  
> the HTML doc and the LineMode browser, but if you've got time to
> give me a little more info...] I'll be ready to tackle that pretty  
> soon.

You ask for info on exactly what you can expect to find in an HTML  
file, but you've read the two HTML files about HTML.  What is missing  
from there?

Here is some discussion about the tags -- where it's not in  
http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html I have updated  
that document now.

Most of the tags are just style tags: this goes for the headings H1  
to H6, the lists UL and OL with list elements LI, the glossary DL  
with elements DT and DD.

<TITLE> ..<TITLE> is designed to be used for putting in the top  
banner of a window, or using as the window  name. It also is what you  
would use in a history list. It shouldn't be displayed in the text  
itself, as usually there is a <H1> heading atteh top of the text  
anyway. A difference is that thet title is designed to make sense out  
of context, whereas the heading is within context. For example,
a title might be "Formatting Characters for Printf -- C reference  
manual" whereas the heading may just be "Formatting characters".

The base address tag is not used, nor is highlighting HP1 etc.

Anchors are used!  The REL attribute is NOT used.

<ISINDEX> is sent by servers to indicate that they will accept a  
search given this document name plus keywords. It turns on a search  
panel when the document is the main window.  An even better  
implementation would have a keyword field at the bottom of the text  
window if the document is a searchable index.  That would make the  
document more self-contained as an item in the user's eyes, and  
reduce screen clutter.

<NEXTID> can be ignored by browsers, only needed for editors.

<XMP> and <LISTING> are used to indicate inserted literal text.
To make life easier for those writing documents (and because we don't  
have entities in the code yet) they are special in that EVERYTHING is  
litteral text until the closing tag - so one can use XMP for giving
examples of HTML for example.  (We really need an escaping method -  
the next parser will have simpl entities like "&lt." for "<".)
Within XMP or LISTING, newlines are significant (and mean "new  
line"!)

<PLAINTEXT> is used to indicate that the rest of the file is in fact
just ASCII. It turns off SGML parsing completely. It's a fudge for
the moment, until we have the document format negociation.
______________________________________

	Structure of documents:

In writing a new generic parser, I wondered whether your text object  
will store the nested structure of a document. At the moment, the  
document is a linear sequence of styles: you can't have lists within  
lists, etc. Ideally, it would be able to handle this - although its  
more difficult for a human writer to handle when formatting the  
document. I would in fact prefer, instead of <H1>, <H2> etc for  
headings [those come from the AAP DTD] to have a nestable  
<SECTION>..</SECTION> element, and a generic <H>..</H> which at any  
level within the sections would produce the required level of  
heading.

For a browser, it is quite satisfactory to flatten the structure back  
into a sequence of styles, but for an editor it isn't. Are you going  
to go for editing capability?

Tim

PS: Shall I put you on the www-talk list?

From timbl  Wed Oct 30 15:33:16 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08339; Wed, 30 Oct 91 15:33:16 GMT+0100
Date: Wed, 30 Oct 91 15:33:16 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9110301433.AA08339@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-interest
Subject: Telnet access to W3 information server


			TELNET ACCESS to W3

You can new telnet to our information server. 


		Telnet to:      info.cern.ch
		User name:      www
		(no password)

You will be presented with the home page which is used at CERN on the
central machines. From there, you can follow links whatever documents  
and indexes we know about at CERN or elsewhere in the world of online  
information. You will be using the line mode brower, which assumes  
nothing about your terminal capabilities.

This trial service is provided for those who want to try out the  
software, or who need information and are away from home. If you use  
this service frequently, it is much more efficient and faster for you  
to install the browser locally.

You can of course get help, including installation instructions, by  
following the "Help" link from the home page.

__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155





From timbl  Thu Oct 31 11:49:15 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09130; Thu, 31 Oct 91 11:49:15 GMT+0100
Date: Thu, 31 Oct 91 11:49:15 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9110311049.AA09130@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Edward Vielmetti <emv@ox.com>
Subject: Re: Home page design, WAIS gateway bug, MSEN
Cc: www-talk

Ed, you asked:

>> Any chance that you could put the "home page" from CERN and some   
other sample good pages up for anonymous FTP? <<

Done for the CERN home page:  
//info.cern.ch/pub/WWWLineModeDefaults.tar.Z

> I'd be interested to hear any thoughts you have on what it takes to
> make a good home page.  I suppose you want to be sure that a user
> doesn't get so completely lost that they can't find their way out,  
> enough local information that people feel more or less at home.
> hm hm hm.

Yes, Good home page design is an art -- like the cover of a magazine,  
or a quick-reference card. Of course it depends on the readership.  
The CERN home page has to start with the CERN things to minimise the  
number of keystokes/clicks for the largest number of users. At the  
same time, it needs pointers for someone with a broader interest to  
rapidly find a wider topic, and it has to suggest to people what is  
behind it so that later they will use it again on another topic.
The competition for the first 24 lines is hot! I have thought of  
having a "Latest additions" link, so that people who though they know  
the web can check for new bits.

There is also the question of whether to make the layout really open  
(lots of white space), with 5 well-explained links on each page, or  
to cram in as much as possible. I feel one should start with  
something very open and obvious, but then get more compact once the  
reader is into something he is interested in and has got the hang of  
the program. Having a fast scollbar make it much easier to cope with  
lots of open text. People must have done their PhDs on this sort of  
thing...

I suspect one should have, for each site/organisation, a public home  
page for those from outside, as well as a private one for those who  
will underderstand terms differently. For example, a link to the CERN  
phone book from outside could mention that the numbers need to be  
prefixed with +41(22)767!

Also, both pages should be linked to some list of other sites.  
Perhaps a tree of pages which emulate the domain/x500 naming scheme a  
little would be useful because people are used to browsing that way,  
and will be able to once x500 is part of the web. This is only one  
structure which is useful, though. A tree by subject a la Dewey  
decimal system would be another - hypertext would get over the tree  
restriction which limits Dewey's usefulness. In fact, making  
hypertext overviews and making indexes of third party data should be  
"value added services" which anyone - library, or company like  
yourselves, should be able to do on top of existing data. Making  
sense of the morass of data (as you have been doing for years) is a  
very valuable contribution to the world of knowledge. Such ordered  
overview or review information is likely to be much more widely read  
than the underlying documents.  The best reviews will be most quoted,  
and hence most read, so survival of the fittest will ensure that most  
people don't spend their time reading junk.

> By the way, it's possible to build a Sun 3 client with no problem
> at all - just make a "sun3" directory, copy in the Sun 4 makefile, 

> and make.

Thanks - I don't have sun3 to test on, but I'll make the directory
any copy the makefile: thanks!


> "Document address invalid or access not authorised" on 

 'http://info.cern.ch./hypertext/Products/WAIS/NewsGroupRelated.html'
> could you check on it?)

Oops .. [Long story: The default home page in the last release has a  
pointer to a file ...Products/WAIS/Sources.html which had just been  
renamed  ...Products/WAIS/Sources/Overview.html. When you read it,  
there was a soft link from the old to the new so you read the new  
file but with the client thinking it was at the old address. This  
worked until I put in the new relative link to your list. Then, the  
relative link was parsed relative to the old address, generating the  
bad adderss above]. It should be ok now. 


___________________________________________________________________

>> I figured out how to store a WAIS query.  For your "What is MSEN"  
pointer,  something like
<A  
HREF=http://info.cern.ch:8001/quake.think.com:210/wais-discussion-arc 
hives?msen> will work just fine. <<

Well done! .. I've linked "MSEN" in your list to you main document.

By the way, I want to make that address

	wais:/quake.think.com:210/wais-discussion-archives?msen

but first I have to put into the client a table of gateway addresses  
for protocols the client doesn't know himself.

>> I hacked the line mode client so that "RECALL" and "LIST" spit  
things out in a format that's ready to cut and paste into a source  
document; that was the easiest way to get documents of my own going  
quickly. <<

Ok...I wondered whether a command "Append a reference to this node in  
HTML to file xxx" would be useful. It would allow people to keep  
lists of interesting nodes in their own space. It's in the Line Mode  
bug list now.

________________________________

>> WAIS database names can include / in them, which
gums up your heuristics for figuring out how to parse them. <<


Yes -- that's true.  I should escape them or something...

Thanks for all your feedback, Ed.  MSEN sound like something heading  
in the right direction.  By the way, do your [prospective] clients  
have workstations in general, or is it all MDOS? Do they dial in, or  
have leased lines?

I wish I could have gone to the IETF to meet a few people in person,  
yourself included, but Robert Cauilliau and I are going to HyperText  
91 (Dec 15-18 in San Antonio TX), and that blows my US Travel quota.  
Will you be at HT91 by any chance?

Tim BL



From jkp@sauna.cs.hut.fi  Sun Nov  3 08:19:02 1991
Return-Path: <jkp@sauna.cs.hut.fi>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00811; Sun, 3 Nov 91 08:19:02 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA26085; Sun, 3 Nov 91 08:15:29 +0100
Received: by sauna.cs.hut.fi id AA25310
  (5.65c8/HUTCS-C-91-07 for www-talk@info.cern.ch); Sun, 3 Nov 1991 09:15:13 +0200
Date: Sun, 3 Nov 1991 09:15:13 +0200
Message-Id: <199111030715.AA25310@sauna.cs.hut.fi>
From: Jyrki Kuoppala <jkp@cs.hut.fi>
Sender: jkp@sauna.cs.hut.fi
To: www-talk@nxoc01.cern.ch
Subject: www server at tky.hut.fi
Return-Receipt-To: jkp@cs.hut.fi
Organization: Helsinki University of Technology, Finland.

OK, now there is quite a lot of stuff added into the www server at
otax.tky.hut.fi - though it's not a web, but a tree.  The html files
for directories are automatically created by a simple shell script
from the normal Unix-style directory tree, and the text files itselves
are normal ascii to which links are created in the html files.

There's one problem: the otax files have tab characters in them and
the server or the line mode client seems to mostly convert them to
line breaks.

//Jyrki

From timbl  Fri Nov  8 10:00:33 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04556; Fri, 8 Nov 91 10:00:33 GMT+0100
Date: Fri, 8 Nov 91 10:00:33 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111080900.AA04556@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-talk
Subject: WWW and prospero



Begin forwarded message:

To: rusty@mail.cornell.edu
Cc: tbl@cernvax.cern.ch, bcn@june.cs.washington.edu
Subject: WWW and prospero
Date: Thu, 07 Nov 91 19:36:05 -0500
From: Edward Vielmetti <emv@ox.com>
X-Mts: smtp


   Does anyone know about WWW (World Wide Web) and Prospero, and how I can find
   out more information about them? Thanks!

Prospero is a remote file system.  If you have an archie client (like
the archie clients at ftp.cs.widener.edu:/pub/archie/) you'll be
using the Prospero protocol to send queries to the servers.  You can
pick up the server at june.cs.washington.edu:/pub/prospero.tar.Z, and
look at the documentation in june.cs.washington.edu:/pub/pfs/doc/.

WWW is an interesting hypertext system from CERN.  You can try it out
by telnetting to info.cern.ch (login: www) or by ftp'ing the clients
or servers from that site.  What's particularly neat is that you can
embed references in a WWW document which point to WAIS servers (as
well as to other WWW documents or files on anonymous FTP) - that makes
it quite straightforward to build on-line systems with a mix of
structured menus and searching stuff.

I'd compare WWW with "gopher" from U of Minnesota (see
boombox.micro.umn.edu:/pub/gopher/); both of them would be suitable
for building a campus-wide information system with.  WWW is much more
of a web with links sending you off hither and yon; selections on
gopher menus can set you talking to servers a long distance away, but
it seems from what I've looked at to be much more of a hierarchical
approach.  WWW also lets users design their own menus.  You can test
out gopher by telnetting to consultant.micro.umn.edu, login gopher.

Both WWW and gopher offer snappy user interfaces for NeXT machines.

   Aaron (Rusty) Lloyd			Cornell Information Technologies
   rusty@mail.cornell.edu			SCAdian, and proud of it!

As an aside, it would be really nice if WWW could be taught the
Prospero protocol like it knows WAIS....

-- 

Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120



From timbl  Fri Nov  8 11:17:05 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04649; Fri, 8 Nov 91 11:17:05 GMT+0100
Date: Fri, 8 Nov 91 11:17:05 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111081017.AA04649@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-interest@nxoc01.cern.ch
Subject: WWW-WAIS Gateway

(Now its been running for some time, I guess I should announce it!) 


		World-Wide Web <-> WAIS Gateway Running

A gateway running on info.cern.ch provides access by any WWW browser  
to the world of information provided by "WAIS" servers. WAIS servers  
are full-text search servers using software from Thinking Machines  
Corporation. There's more infomation about WAIS and the gateway in  
the web.

[By the way, if you have an old WWW default page which may not have  
links to everything of interest, you can pick up by ftp (or link to)  
a new one from file://info.cern.ch/pub/default.html]

HYPERTEXT GUIDE

You can find WAIS indexes by browsing a hypertext guide to WAIS  
(linked from our default page), and/or doing an index search on the  
WAIS index of indexes. 

The guide starts at  
http://info.cern.ch/hypertext/Products/WAIS/Sources/Overview.html
Here is an sample of what there is: 


Biochemistry	 The EC enzyme database of Amos Bairoch , REBASE  
		restriction enzymes , the annotation of the 	 
		GenBank(R) DNA sequence database (Bacterial 

		Division), the Peter Karps CompoundKB database of 981  
		metabolic intermediate compounds ,  periodical 

		references to journals in the area of molecular 

		biology , BIOSCI mailing lists and newsgroup archives

Geography	 Asia Pacific region: Curriculum Resources & Course 

		outlines;  India: Miscellaneous information 


Humanities	 Discussion, Poetry 


Meterology	 The weather (around MIT)

Music		 MIDI interfacing ,  Song lyrics ,

Religion	 The Bible (King James version) , The Holy Qur'an 




Computing & Networking:


	AARNet	 Australian Academic and Research Network Resources
		 Guide

	Fidonet	 List of nodes

	Usenet	 FAQ, cookbook, science

	Internet RFCs, resource guide, etc etc

	(etc etc)


			By Organsiation

 E.F.F.	 	Electronic Frontier Foundation: Documents, 

		discussion

 N.S.F.	 	National Science Foundation: bulletins

 M.I.T.	 	Algorithms book: Bugs , excercises , suggestions  for 

		the book, 'Introduction to Algorithms' by Tom Cormen, 

		Charles Leiserson, and Ron Rivest, all members of 

		Theory of Computation Group, Laboratory for Computer 

		Science.  Weather .

 University of Noth Carolina	 Phone book 


 University of North Texas	 Documents 


 Univ. Oslo	 		Publications bibliography 



Mail me with any problems/questions/suggestions.
__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155





From jfg@bernd.cern.ch  Fri Nov  8 12:20:51 1991
Return-Path: <jfg@bernd.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04713; Fri, 8 Nov 91 12:20:51 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA18954; Fri, 8 Nov 91 12:13:07 +0100
Received: by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
          id AA11283; Sat, 9 Nov 91 12:13:19 +0100
Date: Sat, 9 Nov 91 12:13:19 +0100
From: jfg@bernd.cern.ch (Jean-Francois Groff)
Message-Id: <9111091113.AA11283@bernd.cern.ch>
To: Edward Vielmetti <emv@ox.com>
Cc: bcn@june.cs.washington.edu, www-talk@nxoc01.cern.ch,
        rusty@mail.cornell.edu
Subject: Re: WWW and prospero
References: <9111080900.AA04556@ nxoc01.cern.ch >

> As an aside, it would be really nice if WWW could be taught the
> Prospero protocol like it knows WAIS....

This has a high priority in our wish-list, but we are very busy
preparing a new kernel for WWW (you can call it WOW if you can't
pronounce that !), which features multiple TYPED links from/to each
anchor, so you can write knowbots for instance, and fast (we hope)
format negotiation between clients and servers.

The availability of this will be announced on the www-interest mailing
list. To register on that, send a mail to listserv@info.cern.ch with
body text "add www-interest". Your mail address will be extracted from
the From: field.

Sorry, no firm dates yet, but expect it by the end of the year.

----
	Jean-Francois Groff (jfg@cernvax.cern.ch)
	World-Wide Web project
	CERN, ECP division
	CH-1211 Geneva 23, Switzerland
	Phone: +41 22 767 3755
	Fax:   +41 22 767 7155
----

From timbl  Fri Nov  8 13:35:26 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04757; Fri, 8 Nov 91 13:35:26 GMT+0100
Date: Fri, 8 Nov 91 13:35:26 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111081235.AA04757@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: connolly@pixel.convex.com
Subject: Re: Motif browser status
Cc: kharris@pixel.convex.com, www-talk

Dan,

Thanks for your message.  Obviously you know what you are doing with  
X11 browsers - we are impressed by what you have done to date. I was  
interested to hear that you are working on AVS - I have had some  
contact with AVS people at UNC.

You make a good point that the world has been waiting for a good  
formatted text widget under Motif. One exists under NeXTStep, Robert  
Cailliau is just adapting one for the Mac for hypertext, but under  
Motif it has been lacking.  Of course, hundreds of people have  
written them: all the word processors have them in, and products like  
dynaText, etc. However, there is none in the public domain.

CERN like Convex has a copyright on all code, but we are doing our  
best to release W3 code as widely as possible, and possibly overcome  
this limitation. Why?

The concept of the web is of universal readership. If you publish a  
document on the web, it is important that anyone who has access to it  
can read it and link to it. In order to make this possible, we don't  
need very new technology -- what we do need is

	1.	A common open naming/addressing format
	2.	Sufficiently powerful underlying protocols
	3.	Sufficiently powerful data formats
	4.	Some free implementations

Now we have defined the (1), which did not exist before. We have  
supplemented the (2), where some protocols do exist. We have added a  
little to (3) though we will use all existing and new formats. We  
have written some code.

You say your work would be of considerable valuer to convex. Yes,  
that is true. You must ask yourself whether it would be of more value  
to convex if kept private or released for general consumption. If you  
release it,

  -	Convex gets the credit and a higher profile,
	  (as Thinking Machines has with WAIS indexers for example).

  -	Anyone in the world can read the information you supply
	  with the same tool as they use for other information.

  -	You get a lot of useful feedback from users on the network

  -	A lot of people would be able to profit from what you have
	 done

You have to compare this scenario with that if you keep the code  
private. You will be able to use it internally. Would convex be able  
to profit from by selling it? If so, how many people would actually  
buy it? Will the AVS project benefit from a closed private  
documentation scheme?

On these grounds alone, you may conclude that it is in Convex's  
interest to release the code. Still, you ask what we can "put on the  
table".  If it would make it easier to justify the release of code,  
we would be happy to make all CERN-developed W3 code officially  
available to Convex under a more or less formal joint project  
agreement. Note that we are producing a parallel set of parsers and  
access mechanisms for HTML, newgroups, WAIS, prospero, etc. We have  
gateways, and other browsers. The line-mode browser you know, the Mac  
one is coming along, we may have a full-screen character grid browser  
too. We are currently unifying the browser architecture so that all  
access mechanisms can be used by all browsers. I'm not sure that  
either of our sides would want to be contractually bound to produce  
or maintain anything - the agreement would be just as-is code sharing  
of what exists when it exists, no strings.

You ask about graphics. That cannot be our next priority, as we need  
to get the new architecure and general format negociation worked out.  
In many cases, we find that there are GIF/TIFF viewers on various  
platforms, and one can link in to them. We don't want to make a new  
graphics file format a la Mac/PICT, but we are intrerested in  
conversion code. Have you heard of editable Postscript? That might be  
what you are looking for. (See  
http://info.cern.ch/hypertext/Standards/PostScript/IPF.html)

I don't know whether your company has a mechanism for allowing code  
to be released into the public domain (or General Public License). If  
it is politically impossible, then that's a pity.  (We do have a  
group of students in Finland working on an X implementation, and if  
that doesn't work out we could write it ourselves. It may also be  
that more that one implementation with a different style will be  
interesting. Obviously it would be rather a duplication of effort,  
though we are under a lot of pressure from our management and users  
to put this at the top of the agenda.)

I hope I have clarified the W3 team's philosophy, and perhaps  
convinced you to contribute, to our mutual (and the world's) benefit.

	Tim

PS: Yes, I think you ought to be on www-talk, Dan. I'll put you on.  
The traffic is not too high.
__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155








From emv@cato.aa.ox.com  Mon Nov 11 11:52:03 1991
Return-Path: <emv@cato.aa.ox.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00223; Mon, 11 Nov 91 11:52:03 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA04235; Mon, 11 Nov 91 11:20:43 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA07388; Mon, 11 Nov 91 08:18:22 +0100
Received: from cato.aa.ox.com by mcsun.EU.net with SMTP;
	id AA19550 (5.65a/CWI-2.123); Mon, 11 Nov 1991 08:22:42 +0100
Received: by cato.aa.ox.com (/\==/\ Smail3.1.22.1 #22.9)
	id <m0kgVyd-000Bt4C@cato.aa.ox.com>; Mon, 11 Nov 91 02:22 EST
Message-Id: <m0kgVyd-000Bt4C@cato.aa.ox.com>
To: www-interest@nxoc01.cern.ch
Cc: archive-index@cs.toronto.edu, emv@msen.com
Subject: some of the stuff on ftp.cs.toronto.edu:/pub/emv/ is in WWW format
Date: Mon, 11 Nov 91 02:22:35 -0500
From: Edward Vielmetti <emv@ox.com>
X-Mts: smtp

I'm slowly but surely converting the files on ftp.cs.toronto.edu:/pub/emv
to be in the WWW format.  Right now the stuff in news-archives.README is
referred to that way, and some of the rest of the things in news-archives too.

I'm going out on a limb a tiny bit and writing references to things that
none of the clients know how to deal with yet, in the expectation that
useful data will inspire code.  In particular, I have some references
that look like

<a name=1 href=aftp://anonymous@ftp.cs.toronto.edu:/pub/emv/news-archives.README>
</a>

This aftp: tag is new.  I'm not completely happy with the use of the
file: tag to refer to remote files, since it can lead to situations
where references are ambiguous depending on whether you're dealing with
a file on the local system or that same file accessed via anonymous FTP
on the local system.  Adding an aftp: tag should help that.  The format
//user@host:/filename/ is quite similar to that used by ange-ftp, so
these references are immediately quite usable by existing code.
There's also the hope that if the aftp: thing gets to be popular it'll
be easier to pick out references to files from usenet postings, distinguishing
them from references to ftp (the protocol or the program).

It's useful (even necessary) to include the anonymous@ bit; there are some
sites (lib.stat.cmu.edu and research.att.com) with two parallel
"anonymous FTP" trees that have different user names to get to them;
a reference to
	<a href=aftp://netlib@research.att.com:/> </a>
is quite different than
	<a href=aftp://anonymous@research.att.com:/> </a>

comments etc welcomed.

at some point this archive is going to migrate back to ftp.msen.com,
but I'm waiting there on getting equipment a little more suitable to
the task.  

Tim, feel free to glue these into the web as best you see fit; I have
to go back and stick in all of the WAIS newsgroup mappings that
I collected before.
I'm also using
	<a href=wais://wais.domain.org:210/database?>
in anticipation of that tag being supported, it should be a matter of
a simple sed or perl script to convert those tags to their current
preferred format.

--Ed

From jfg@bernd.cern.ch  Tue Nov 12 16:44:43 1991
Return-Path: <jfg@bernd.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01728; Tue, 12 Nov 91 16:44:43 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA14518; Tue, 12 Nov 91 16:36:14 +0100
Received: by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
          id AA05532; Tue, 12 Nov 91 16:36:46 -2300
Date: Tue, 12 Nov 91 16:36:46 -2300
From: jfg@bernd.cern.ch (Jean-Francois Groff)
Message-Id: <9111131536.AA05532@bernd.cern.ch>
To: Edward Vielmetti <emv@ox.com>
Cc: www-interest@nxoc01.cern.ch
Subject: Re: some of the stuff on ftp.cs.toronto.edu:/pub/emv/ is in WWW format
References: <m0kgVyd-000Bt4C@cato.aa.ox.com>

>>>>> On Mon, 11 Nov 91 02:22:35 -0500, Edward Vielmetti <emv@ox.com> said:

Ed> I'm slowly but surely converting the files on ftp.cs.toronto.edu:/pub/emv
Ed> to be in the WWW format.  Right now the stuff in news-archives.README is
Ed> referred to that way, and some of the rest of the things in news-archives too.

I just tried to read your news-archives.README with the line-mode
browser through the traditional file: access. First-minute comments :

- Currently, any file retrieved through the file: access, local or
remote, is considered a plain text file unless its name ends with
`.html'. As a consequence, the anchors that you have inserted in
news-archives.README are not interpreted by the browser, so they
cannot be jumped to, except by cutting the reference and pasting it to
another www command line. Moreover, the text is just echoed in its
original format, which sadly happens to be double-spaced (CR-LF ?).
The easy fix is to append `.html' to the name of any file that
contains HTML tags, but I understand that it will bother people who
look at your files without www. The upcoming format negociation could
help with this, especially in the case of a dedicated www server that
could pass and possibly negotiate the document type. For anonymous
ftp, the browser should run simple heuristics to try and guess the
type of the file from its name.extension. We'll think about it.

Ed> This aftp: tag is new.  I'm not completely happy with the use of
Ed> the file: tag to refer to remote files, since it can lead to
Ed> situations where references are ambiguous depending on whether
Ed> you're dealing with a file on the local system or that same file
Ed> accessed via anonymous FTP on the local system.  Adding an aftp:
Ed> tag should help that.

- We agree that the current syntax can be ambiguous, but we want to
keep references to local and remote files in the same format, because
the very notion of a `remote' file should disappear with wide-area
hypertext (remember the new WAN cliche: the network IS the computer).
A less philosophical reason for that is to avoid referring to a
particular retrieval protocol : the reference to the file should be
the same regardless of whether it is retrieved through anonymous ftp
or through the Andrew file system, for instance. Of course, we would
like to introduce X.500 naming in the (more or less) long term.

Ed> It's useful (even necessary) to include the anonymous@ bit; there are some
Ed> sites (lib.stat.cmu.edu and research.att.com) with two parallel
Ed> "anonymous FTP" trees that have different user names to get to them;
Ed> a reference to
Ed> 	<a href=aftp://netlib@research.att.com:/> </a>
Ed> is quite different than
Ed> 	<a href=aftp://anonymous@research.att.com:/> </a>

So we want to keep `file:' for both local and remote file, but we must
take into account your other suggestion : allowing for a different
user name. I suggest the following :

	* allow an optional `user@' part before a host name.
	* if the user is not specified, make it the current user name
	  if the host is the local machine, and `anonymous' otherwise.
	  (this avoids the ambiguity that you mentioned)

Examples :
	file://ftp.cs.toronto.edu/pub/emv/news-archives.README.html
	file://netlib@research.att.com/

Ed> The format //user@host:/filename/ is quite similar to that used by
Ed> ange-ftp, so these references are immediately quite usable by
Ed> existing code.

- Currently, a colon after the host name is used to specify an alternate
TCP port number, but a good browser should ignore it if no number is
present. In this way, www can be compatible with ange-ftp syntax.

- Your examples make me think of another feature we should add for the
browsers to support them : the ability to display a directory as a
list of references, with maybe the README file (if any) prepended as
introductory text. Currently, on your reference to
	file://pit-manager.mit.edu/pub/usenet/
the browser would try to `get' the directory through ftp and fail. So
I'll add this to the wish-list for the `file:' access method :

	* if the address ends with a `/', try `ls' instead of `get'.
	* try to get an appropriate README file. Try those in order :
	  README.html, *README*.html, README, *README*, *readme*
	* Display that file if found, then build a list of references
	  for all the files contained in the directory.

Note that if you supply both a README.html and a traditional README,
you won't have to apologize about `all those funky angle brackets' !

- From your news-archives.README :

  blah blah blah. Check out
  <a href=aftp://anonymous@pit-manager.mit.edu:/pub/usenet/> </a>
  for lots more information.

With the line-mode browser, this will look fine :

  blah blah blah. Check out [1] for lots more information.

But with any mouse-driven browser (NeXT, X-Windows, emacs, Mac), the
anchor should sit on a piece of text that will serve as a button. With
your current example, your reader would only see :

  blah blah blah. Check out for lots more information.

with possibly a tiny highlighted space between `out' and `for'. Some
human-readable description of what the anchor points to will do fine.
For instance :

  blah blah blah. Check out the
  <a href=file://pit-manager.mit.edu/pub/usenet/> MIT usenet archives
  </a> for lots more information.

would yield

  Check out the MIT usenet archives[1] for lots more information.

or a highlighted `MIT usenet archives' on a mouse-driven browser.
Before that in your README, it would be nice to have an anchor
associated with the `List of periodic informational postings' and to
the archive that you mention. Same for the `news.answers' group (the
`news:' access is implemented in the new architecture. Use this simple
syntax : `<a href=news:news.answers> news.answers </a>'.)

- As an aside, the `name=' part of the anchor tag is not necessary in
your context : it is needed if someone wants to make a link TO that
particular anchor, not to the whole document.

Ed> I'm also using
Ed> 	<a href=wais://wais.domain.org:210/database?>
Ed> in anticipation of that tag being supported, it should be a matter of
Ed> a simple sed or perl script to convert those tags to their current
Ed> preferred format.

- Agreed. OK for the `wais:' access.

Thank you for all your suggestions. Please continue to provide
feedback as you write more html. We're looking forward to read your
data seamlessly and pave the way for other ftp site managers.

--- Jean-Francois

From emv@shelley.aa.ox.com  Wed Nov 13 01:11:01 1991
Return-Path: <emv@shelley.aa.ox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02121; Wed, 13 Nov 91 01:11:01 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA03747; Wed, 13 Nov 91 01:02:22 +0100
Received: by shelley.aa.ox.com (/\==/\ Smail3.1.22.1 #22.9)
	id <m0kh855-000Ds7C@shelley.aa.ox.com>; Tue, 12 Nov 91 19:03 EST
Message-Id: <m0kh855-000Ds7C@shelley.aa.ox.com>
To: jfg@bernd.cern.ch (Jean-Francois Groff)
Cc: www-interest@nxoc01.cern.ch
Subject: Re: some of the stuff on ftp.cs.toronto.edu:/pub/emv/ is in WWW format 
In-Reply-To: Your message of Tue, 12 Nov 91 16:36:46.
             <9111131536.AA05532@bernd.cern.ch> 
Date: Tue, 12 Nov 91 19:03:47 -0500
From: Edward Vielmetti <emv@ox.com>
X-Mts: smtp

>> I just tried to read your news-archives.README with the line-mode
>> browser through the traditional file: access. First-minute comments :

Thanks for the comments.  I realize this is just a first pass for some
of this -- I'm hand editing the files for now, but before too long I
really want to start generating stuff more automatically, best to get
the formats down pat before writing code.

>> The easy fix is to append `.html' to the name of any file that
>> contains HTML tags, but I understand that it will bother people who
>> look at your files without www. 

I'm expecting to generate two (or three, or n) different files
eventually from an SGML source; one will be relatively flat ASCII that
people can read real easily, another will be nice pretty postscript
suitable for paper, and the third the HTML for the browser.  I'm
pretty sure that the available SGML tools (either now or within the
year) will make this reasonable to do, one way or the other.

>> - We agree that the current syntax can be ambiguous, but we want to
>> keep references to local and remote files in the same format, because
>> the very notion of a `remote' file should disappear with wide-area
>> hypertext (remember the new WAN cliche: the network IS the computer).

I guess the only problem here is that the frame of reference (or the
top level directory) may change depending on your access mode;
anonymous FTP shows that tendency, and AFS seems to as well.  I've
abandoned the aftp: bit as I rewrite things, they're just file: now.

>> - Currently, a colon after the host name is used to specify an alternate
>> TCP port number, but a good browser should ignore it if no number is
>> present. In this way, www can be compatible with ange-ftp syntax.

Thanks.  I think it's important -- ange-ftp users includes me, and
since I don't have a real super WWW browser other than line mode I
need to be sure that I don't have to rewrite stuff.  I don't think it
would be to hard to cons up a similar setup to 

>> I'll add this to the wish-list for the `file:' access method :
>> 
>> 	* if the address ends with a `/', try `ls' instead of `get'.
>> 	* try to get an appropriate README file. Try those in order :
>> 	  README.html, *README*.html, README, *README*, *readme*
>> 	* Display that file if found, then build a list of references
>> 	  for all the files contained in the directory.

There's work going in the IETF Anonymous FTP working group (headed up
by Alan Emtage and Peter Deutsch of archie fame) to work on improving
access to anonymous FTP areas.  A standard for directory description
is sorely lacking, and I think (cross fingers) than an SGML approach
like WWW would have as good a chance as any to get acceptance That's
especially true, *if* can be generated with minimal or no effort by a
site admin.  I'm inclined to called the file
	archie.html
just to steal their good name :-) and make it clear that the file is
designed to be scooped up and processed by other things (future
archies, WWW, WAIS, other hypertext browsers, other indexes).

A first pass would be to take a big archive that you're familiar with
and that is already reasonably well indexed (say the index files from
one of the NeXT archives, or maybe simtel20, or something like that)
and convert the indexes into WWW format.  

>> With the line-mode browser, this will look fine :
>> 
>>   blah blah blah. Check out [1] for lots more information.

Fixed (more or less)in the stuff that I'm going back over.  I don't
have a formatter just yet that will display things as they will show
on-screen, & there are style and design conventions involved which I'd
really rather steal from someone than do myself.  A style guide for
html (and a dtd, if you can manage one, so that these things can be
munged with sgml tools) would be great to have.

>> Thank you for all your suggestions. Please continue to provide
>> feedback as you write more html. We're looking forward to read your
>> data seamlessly and pave the way for other ftp site managers.

Happy to be of help, thanks for the comments.  It's a big enough job
to try to map out what's out there on the net, I'd just as soon let
someone else write the nice GUI so I don't have to.

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120



From emv@crane.aa.ox.com  Wed Nov 13 05:18:38 1991
Return-Path: <emv@crane.aa.ox.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02197; Wed, 13 Nov 91 05:18:38 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA09904; Wed, 13 Nov 91 05:15:00 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA08967; Wed, 13 Nov 91 05:09:56 +0100
Received: by crane.aa.ox.com (/\==/\ Smail3.1.22.1 #22.9)
	id <m0khBzh-00081pC@crane.aa.ox.com>; Tue, 12 Nov 91 23:14 EST
Message-Id: <m0khBzh-00081pC@crane.aa.ox.com>
To: www-interest@nxoc01.cern.ch
Subject: references in the web to paper documents.
Date: Tue, 12 Nov 91 23:14:28 -0500
From: Edward Vielmetti <emv@ox.com>
X-Mts: smtp

I will be using the format

<a href=isbn:0-13-484080-1> Carl Malamud's "Stacks" </a>

to handle references to books.  The hope (such as it is) is that
a browser will be able to take the isbn magic cookie and feed it
into a library on-line catalog and get a meaningful result back.

If there has been an SGML coding proposed or in use for MARC format
records that would be the appropriate way to return the results.
I don't have MARC details on-line, but that's OK since most library
on-line catalogs don't yet give you access to raw cards.

Until there's an isbn-to-www gateway they're still quite useful
as absolute reference markers, easy to get the full cataloging
information that way.

Similar treatment is expected for issn (serials) numbers.  In some
distant far-off future electronic serials and electronic documents
will get card catalog entries for them if they're suitably permanent
and distinctive to warrant them.  Until then there are plenty of books
out there that I'd like to have pointers to.

Bonus points if you can deliver fully formed hypertext to the
desktop based on the isbn number :-)

--Ed

From emv@heifetz.msen.com  Wed Nov 20 10:30:27 1991
Return-Path: <emv@heifetz.msen.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08265; Wed, 20 Nov 91 10:30:27 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA11177; Wed, 20 Nov 91 10:26:56 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA01645; Wed, 20 Nov 91 10:21:09 +0100
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0kjoAF-000HftC@heifetz.msen.com>; Wed, 20 Nov 91 04:24 EST
Message-Id: <m0kjoAF-000HftC@heifetz.msen.com>
To: www-talk@nxoc01.cern.ch
Cc: archie-maint@cc.mcgill.ca, prospero@isi.edu
Subject: prototype of www-prospero-archie interface
Date: Wed, 20 Nov 91 04:24:09 -0500
From: Edward Vielmetti <emv@msen.com>

What I say prototype, I mean just a little teeny tiny idea
turned into a few lines of code.

This is a piece of perl that is a gateway between archie and
WWW.  It should be set up to run as a server under inetd.  It
takes incoming requests of the form
	GET /nic.funet.fi/exact?wais
and returns HTML formatted archie results back.  It depends on the
C language Prospero archie client that you can get from (e.g.)
ftp.cs.widener.edu.

My HTML is really bad but you get the idea, it should look somehow
somewhat reasonable and something you can click on.

With a little bit of work any dbm file looks like it can be turned
into a WWW queryable server along the same lines.

Take note that you are inviting truly perverse packet transport,
with a query from one site resutling in hundreds of packets being
shuttled all around the world ....

--Ed

#!/usr/local/bin/perl

# gateway from www to archie
# this is the "brute force" kind of approach; a tidier solution
# would speak the prospero protocols directly.

while (<>) {
	if (m,^GET /(.*)/(.*)\?(.*)$,) {
		$archie = $1;
		$type = $2;
		$query = $3;
	} else {
		exit 0; # XXX 
	}
#	print "$node $database $query \n";
	if ($type eq 'exact') {
		$arg = " -e ";
	} else {
		$arg = " -s ";
	}
	$archcmd = "archie -l -t " . $arg . " -h " . $archie . " " . $query ;
	print "<title>archie $type search for $query on $archie </title>\n";
	@result = `$archcmd`;
	foreach (@result) {
		($time, $size, $host, $file) = split;
		print "<a href=file://anonymous@$host:$file>\n";
		print "$_</a>\n";
	}
}


From timbl  Thu Nov 21 17:51:35 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11536; Thu, 21 Nov 91 17:51:35 GMT+0100
Date: Thu, 21 Nov 91 17:51:35 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111211651.AA11536@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Anders Gillner <awg@sunic.sunet.se>
Subject: Re: Internet-gopher , WWW, WAIS, etc
Cc: NIR, www-talk

Anders,

>> systems within systems within systems!

> [expletive deleted] mess !!. I have written to Joyce R. and said  
that we need some kind of structure and a worldwide cooperation about  
datastructure.

There two areas -- orgainzing the data structure itself, and  
coordinating addressing/protocols/formats. Both are in embryonic  
stages at the moment so a few concurrent ideas must be useful to the  
world. Both can also, to a certain extent, be resolved by a "survival  
of the fittest" principle (as Brewster argues in [1]): Those reviews,  
overviews and indexes which have the best coverage, signal to noise  
ratio and good links will be read most, and quoted most. It would  
save time, though, if all the projects pooled resources a bit more.  
Some unaligned funding would help of course...

 Various people (CC'd on this mail) are talking about putting  
together a mailing list about resolving technical issues. Personally,  
I don't mind where the list is -- it sounds like a good idea. The  
problem seems to be working out the overlap with lists such as  
www-talk, wais-talk, archie-people, the anon. ftp IETF WG., various  
public lists [2], etc etc.  Perhaps someobody could try to make a  
"state of the nation(?)" list of who's doing what now.

	Tim

__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155


References:

[1]Brewster Kahle on WAIS concepts (much applies to other systems  
too)
 www file://quake.think.com//pub/wais/doc/wais-concepts.txt
[2] List of some lists involved in NIR:
www http://info.cern.ch:8001/wais.cic.net:210/lists network  
information retrieval



From timbl  Mon Nov 25 09:48:57 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13665; Mon, 25 Nov 91 09:48:57 GMT+0100
Date: Mon, 25 Nov 91 09:48:57 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111250848.AA13665@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: connolly@pixel.convex.com
Subject: Re: X/motif browser status
Cc: www-talk

Dan,

> The AVS help system is all but finished.

> I went back tonight and tried browsing WWW files.
> My html2rtf converter is still a little rusty, but
> other than that, it works well.

Thanks for the pearl script. It prompted us to bring perl up on some machines
we didn't previously have it on.

> Features I've implemented since I last wrote you:
>
>	* multiple fonts (with menu options for changing them)
>	* colored text
>	* full color raster images
>
> I've been considering the idea of building this thing on a Sparc
> and sending you the binary for evaluation. I _might_ have time
> before the end of the year. Would you have time to look at it?
> Is it worth bothering, considering we don't have an agreement
> about the source?

Certainly we we would have time, and we'd be interested to compare the user  
interfaces.  It's a pity you can't release the source, but to to see the look and  
feel would be intresing all the same.

> I used to keep up on the hypertext newsgroups, WWW, and WAIS mailing
> lists, but for about two months now, I've been too busy. The AVS project
> is winding down. I should be able to start thinking about using WWW or
> WAIS technology (or both) some time soon.

Good. We are still (with many distraction) working toward getting the new browser  
out. That'll be able to have WAIS and WWW in the same package, fairly seamless  
[Have you tried browsing through the WAIS gateway with your WWW browser?]

Keep up the good work

Tim

From timbl  Thu Nov 28 08:57:45 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16501; Thu, 28 Nov 91 08:57:45 GMT+0100
Date: Thu, 28 Nov 91 08:57:45 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111280757.AA16501@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-talk
Subject: Document identifiers



[from clifford lynch via brewster kahle]

The Coalition for Networked Information
Architectures & Standards Working Group

Workshop on ID and Reference Structures
for Networked Information

There is an increasingly urgent need to develop working
standards for referencing networked information objects.
This has a wide range of applications, including links from
MARC records to source material, references from courseware
to published material in electronic form, networked
hypertext pointers, and digital document IDs of the sort
used in the Wide Area Information Server (WAIS) system.
Many projects underway today need these types of
identifiers, and a number of efforts have developed ad-hoc
solutions so that they can progress. Unfortunately, the
proliferation of these ad-hoc solutions is a major barrier
to interoperability.

Responding to this need, the Coalition for Networked
Information's Architectures and Standards Working Group is
initiating an effort to develop such a working standard, or
agreement. One outcome of this work may be a draft
specification that is forwarded to standards-making bodies
such as the National Information Standards Organization for
consideration as the basis of an actual standard. In
addition, the resulting specification may be submitted to
the Internet Engineering Task Force for consideration as a
draft Request for Comment (RFC).

I propose the following process to reach agreement. I am
distributing this announcement, which includes a number of
assumptions towards such a specification; redistribution is
encouraged. Discussion can be carried out electronically on
the new LISTSERV mailing list that has been set up for the
Architectures and Standards Working Group, which you can
subscribe to by sending a mail message in the form

SUB CNI-ARCH yourname

to

LISTSERV@UCCVMA.BITNET

Barring the unlikely event that rapid and full agreement on
the specification is reached through electronic discussion,
CNI will sponsor a one-day invitational meeting in early
November (date and place to be determined). If you have a
strong interest in this topic and feel you should attend the
meeting, contact me either by electronic mail
(CALUR@UCCMVSA.BITNET or CALUR@UCCMVSA.UCOP.EDU) or by
telephone (510) 987-0522 to have your name added to the
invitation list.

Aspects of the problem that need to be addressed include
those below, which I have listed along with some assumptions
(all subject to question) to provide a starting point for
our discussions. I do not claim that this list is complete;
look for areas overlooked as well as react to those
mentioned. Many people have contributed ideas that appear in
the list below, but I must make special note of the
contributions of Brewster Kahle of Thinking Machines and his
excellent document "Document Identifiers, or International
Standard Book Numbers for the Electronic Age" (5/9/90).

1. The need for identifiers, as distinct from location
information. This is best handled by a number (much like an
ISSN or ISBN), but the system must accomodate multiple
number-assigning agencies. Thus, the identifier is proposed
as <numbering-authority>,<identifier> where numbering
authorities are registered.

2. The pointers must be representable as an ASCII string to
facilitate inclusion in a wide range of material, including
documents and electronic mail.

3. Location information must support multiple Locations for
the document, including the "location of record" and one or
more redistribution centers, local caches, etc. The means of
specifying a location should be sufficiently general to span
at least the set of networks covered under the Internet
Domain Naming system (DNS).

4. Objects may be retrieved by a variety of access
mechanisms from servers, including FTP, LISTSERV, Z39.50,
and perhaps FTAM and SQL-based database access, as well as
requests for paper copies. The location information should
be sufficiently general to include information about these
different types of access techniques, and extensible to
include new access methods that may develop in future.

5. Perhaps the location identifier should include some
information about the format and size of the object; on the
other hand, perhaps it should not. Discussion?

6. It should be possible to further qualify a reference to a
"sublocation" within an object (which would have meaning
only to the server that houses it). This is needed, for
example, for hypertext-type links.  Such a sublocation might
be the 25th paragraph of a text, for a hypertext-type
pointer.

7. Indirection should be supported. In other words, one
should be able to format the location as the name of a
server that can be passed the identifier and which would
return location information. The protocol mechanism(s) for
doing this need to be specified as well.

8. While full rights and permissions data would seem to be
outside the scope of such a pointer, it might be useful to
include at least some basic information. This might be an
indication that the object is not copyrighted and can be
freely distributed, that it is copyrighted but can be freely
distributed, that it can be redistributed for noncommercial
use, or that restrictions apply to redistribution. Also, it
might make sense to include a pointer of some sort (an
e-mail address? a host address?) for further information
about rights.

9. Perhaps there might be some type of checksum that can be
calculated on the retrieved object to ensure that the
pointer and the object have not gotten out of synch?



From timbl  Thu Nov 28 11:32:02 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16716; Thu, 28 Nov 91 11:32:02 GMT+0100
Date: Thu, 28 Nov 91 11:32:02 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9111281032.AA16716@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-talk@nxoc01.cern.ch
Subject: misc. architecture notes



Begin forwarded message:

To: timbl@nxoc01.cern.ch
Subject: misc. architecture notes
Date: Wed, 27 Nov 91 15:06:02 CST
From: connolly@pixel.convex.com

[Any minute now, my ride to Kansas City for the holidy
 will arrive. In the mean time, here are some ideas.]

WAIS

It's beginning to look like you should try to fit WWW inside
WAIS, rather than the other way around. You need to talk with
those guys about format negotiation and document representation,
and both groups need to combine WAIS docid's and WWW anchor
addresses.

In other words, I think the WWW browser should be a WAIS client.
But come to think of it, there's no reason a browser can't be a WAIS
client, a HTTP client, an FTP client, and an ARCHIE client all at
the same time.

For example, I used to compile WWW support into my browser. Lately,
I changed my mind. Now I compile a separate programe that supports
WWW access. I invoke
	htaccess HTML_ADDRESS
and the stdout of that process is the HTML content of the node.
I pipe that through html2rtf.pl, and display the output. The user clicks
on anchors, and the whole process repeats.

I could, however, use waisq, or an archie client, or an nntp client, or
an ftp client in place of htaccess, write a few more foo2rtf converters,
and support all this stuff. Hmmm... lots to think about.

TEXT OBJECT

I've been reading some of the design notes in your web, and I
was particularly interested in your ideas for a portable text
object. My software uses many of these concepts. I gave up
editing capabilities to simplify the design and make it doable
in two months.

I think you would be crazy to try to do the text object without C++.
Perhaps you could provide a C interface and a sample implementation
in C that doesn't have all the features. But for WYSIWYG displays,
the problem is just too complex to maintain in C.

You should take a close look at TMLib. Some of the implementation
needs rework, but the architecture fits your needs pretty well.
I'm not using any of that code, but I'm using lots of their ideas,
e.g. the model-format-view architecture.

HTML

You need a DTD. Have you seen the SGMLS tools? They parse SGML and
write a line-oriented representation as output. This would be ideal
for format negociation. You could support plaintext and cerainly RTF,
and probably make stabs at TROFF, TeX, and perhaps PostScript.

Have you considered how to embed links in other formats? Please let
me know how you decide to do it in RTF. My idea is to translate:
	<A HREF=foo>text</A>
		to
	{\field{\fldinst HREF=foo}{\fldrslt text}}
[for implementation reasons, I'm currently putting the \fldinst group
 after the \fldrslt group, but that's a minor detail.]

The resulting files still work when loaded into MS Word, though if you
saved them again I doubt the HREF would still be there.

[my ride is here. more later]

Dan



From jfg@bernd.cern.ch  Mon Dec  2 10:07:44 1991
Return-Path: <jfg@bernd.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19808; Mon, 2 Dec 91 10:07:44 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA25300; Mon, 2 Dec 91 09:58:00 +0100
Received: by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
          id AA14185; Mon, 2 Dec 91 10:08:04 -2300
Date: Mon, 2 Dec 91 10:08:04 -2300
From: jfg@bernd.cern.ch (Jean-Francois Groff)
Message-Id: <9112030908.AA14185@bernd.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from connolly@pixel.convex.com

WWW folks may like to comment on this, posted to wais-talk and
cni-arch... Sorry if you've already read it there !

-- Jean-Francois

------- Start of forwarded message -------

From: connolly@pixel.convex.com
To: wais-talk@Think.COM
Cc: cni-arch@uccvma.BITNET
Subject: Re: Document identifiers 
Date: Mon, 02 Dec 91 01:32:36 CST


>The Coalition for Networked Information
>Architectures & Standards Working Group
>
I don't like the direction this technology is headed.

What is the desired functionality of these identifiers?

If you want an identifier that uniquely identifies a file,
why not use a checksum, such as returned by the unix
sum command?

Let's see how a checksum solves these issues, and then see
what functionality I'd like to see in stead.

>1. The need for identifiers, as distinct from location
>information. This is best handled by a number (much like an
>ISSN or ISBN), but the system must accomodate multiple
>number-assigning agencies. Thus, the identifier is proposed
>as <numbering-authority>,<identifier> where numbering
>authorities are registered.
>
There's no location info in a checksum. Done deal.

>2. The pointers must be representable as an ASCII string to
>facilitate inclusion in a wide range of material, including
>documents and electronic mail.
>
Check.

>3. Location information must support multiple Locations for
>the document, including the "location of record" and one or
>more redistribution centers, local caches, etc. The means of
>specifying a location should be sufficiently general to span
>at least the set of networks covered under the Internet
>Domain Naming system (DNS).
>
Ah! Now we want to be able to get location info out of the
identifier. Checksums don't help. Well, in fact, they help
no more or less than <numbering authority>-<id> helps, unless
a numbering authority implies a location. I'm not clear on
this at all.

>4. Objects may be retrieved by a variety of access
>mechanisms from servers, including FTP, LISTSERV, Z39.50,
>and perhaps FTAM and SQL-based database access, as well as
>requests for paper copies. The location information should
>be sufficiently general to include information about these
>different types of access techniques, and extensible to
>include new access methods that may develop in future.
>
Hmmm... now it looks like the doc id should tell how to
get the document... but not exactly. What we're relly looking
for is some client software that interprets these numbers
and queries servers. Checksums look as good as anything again.

>5. Perhaps the location identifier should include some
>information about the format and size of the object; on the
>other hand, perhaps it should not. Discussion?
>
Checksums do not contain type/size info. If that's what we want,
the checksum idea is no good.

>6. It should be possible to further qualify a reference to a
>"sublocation" within an object (which would have meaning
>only to the server that houses it). This is needed, for
>example, for hypertext-type links.  Such a sublocation might
>be the 25th paragraph of a text, for a hypertext-type
>pointer.
>
Now we raise the question: just what does a document identifier
identify? Until this item, it appeared that a document was
a file. Now it's not so clear. Perhaps a document should be anything
from a single character to a paragraph to a file to a chapter to
a book to an encyclopedia to a library. That would be a good trick.
Is that what we're after?

>7. Indirection should be supported. In other words, one
>should be able to format the location as the name of a
>server that can be passed the identifier and which would
>return location information. The protocol mechanism(s) for
>doing this need to be specified as well.
>
Ah. Now the objectives of the location info become more clear.
Sounds to me like the location is a TCP connection, or enough
information on how to establish one.

>8. While full rights and permissions data would seem to be
>outside the scope of such a pointer, it might be useful to
>include at least some basic information. This might be an
>indication that the object is not copyrighted and can be
>freely distributed, that it is copyrighted but can be freely
>distributed, that it can be redistributed for noncommercial
>use, or that restrictions apply to redistribution. Also, it
>might make sense to include a pointer of some sort (an
>e-mail address? a host address?) for further information
>about rights.
>
Ack! This stuff seems totally orthogonal to the rest of the
stuff, but in practice, this looks like a crucial issue.
I don't have any good ideas here.

>9. Perhaps there might be some type of checksum that can be
>calculated on the retrieved object to ensure that the
>pointer and the object have not gotten out of synch?
>
This is what sparked the checksum idea.


My response to all this:

I don't think we need [yet another] document identifier format.
If you want location info, use an internet address; if you want
data integrity, use a checksum; if you want format, we are lacking
a standard here; if you want copyright info, ditto;

What we need is some nifty client software to glue all the parts
together. I guess there is some room for standardization, but please:
	LET'S LEVERAGE EXISTING SYSTEMS!

Where these systems are robust, I think we should support them. I'd
also like to see support for ad-hoc document identifiers. Here's
an example to clarify:

I'm browsing some email, netnews, or a README file from somewhere.
I see a reference to more info:

	A full discussion of the BLURF protocol is available via
	anonymous FTP from frob.mit.edu as blurf-proto.tex
	in the directory /pub/protos.

I select some or all of that text, and I click one of the buttons
in my document retrieval tool:

	make ftp id --	extract the relevant information and display
			a well-formed identifier acceptable to some
			existing FTP client (I've heard of something
			called ange FTP. Another idea is to make
			a shell script that would do the retrieval:
ftp frob.mit.edu
cd /pub/protos
get blurf-proto.tex
			)

	make wais id --	get enough info to make a WAIS doc ID
			[scrap this unless it stabilizes]
	make WWW id --	same thing for World Wide Web HTTP addresses.
	make NNTP id --	same thing for USENET news message id's.
	make LISTSERV id --	you get the idea
			Rather than making up a new format, these id's
			are instructions to EXISTING clients to retrieve
			a document.

	verify id --	connect to the necessary server(s) and verify
			that the id references an existing document.
			Append to the id a "verification date," which
			is the last time a server acknowledged the
			existence of the document.

	get id info --	connect to the necessary server(s) and get about
			1K of miscellaneous info: document size in bytes,
			date of last modification, available formats,
			short summary, etc.

	retrieve raw --	connect and retrieve the document in whatever
			format is convenient to the server, e.g.
			a compressed tar archive of C and troff sources.

	retrieve text --	connect and retrieve the document as
			plain text [defined, e.g. as the body of an 
			RFC-822 mail message]

	retrieve... --	the user or the supporting client software
			specifies the supported information formats,
			(compression schemes, archiving formats,
			image file formats, typesetting languages)
			the client and the server hash over their options,
			[perhaps with user intervention]
			and the server sends the most desireable version
			of the document it has available.

If we add a few buttons, we begin to encompass the scope of many existing
systems:

	expand --	change the doc id to reference the "document"
			containing it. In the ftp example, rather than
			"get blurf.tex," it would have "ls."
			Click again and get "cd ..; ls."
			Obviously, this operation depends on the access
			mechanism. For WAIS documents, the expansion of
			a document is the source that contains it.

	select --	narrow the document to some of its parts. For a
			text file, select some of the characters/paragraphs
			for a WAIS source, select some of the documents.
			For a WWW node, select a neighboring node. For
			a directory, select some files.

I guess my point is, let's think about how folks are going to use this
document referencing technology, and let's see how well existing systems
meet these needs.

I guess some groups have come to the conclusion that the existing systems
don't cut it. I'm beginning to agree.

I guess we'd all agree that we should decide how we're going to use these
doc id's and let that drive the design of the format. i.e. Let's decide
on the methods of this object before we decide on its representation.

[an idea: for syntax, the WAIS folks chose LISP. What about using
something akin to RFC-822 syntax? I think it works well: define a bunch
of standard headers; require some, allow some, disregard others; allow
free-form text in the body. examples:

ISBN: 0-13-590126-X
	or
MESSAGE-ID: usenet-thing
	or
FTP-HOST:  frob.mit.edu
USER:	anonymous
	or
WAIS-PORT:	8001@think.com


This would allow us to leverage all the email technology out there, plus 
the emerging multi-part mail format.
(and it would allow me to use PERL on these beasties! :-)
]

Another thing I hope folks are keeping in mind: I don't think any one
client can meet the information-retrieval needs of everybody. We need
to support multiple platforms, for one thing. But I hope other folks are
considering using mulitple clients at the same time! I'd like to use
one slick X-windows front end to the whole ball of wax, in some ways like
emacs does for programming, and in some ways like the mac GUI does for
office-productivity applications. But I'm going to be using POST mail
servers, NNTP servers, WAIS servers, FTP servers, etc, and I don't
expect one client to do it all. The crucial trick is to make all this
intuitive and interactive, i.e. to support hypertext browsing, fulltext
retrieval, USENET news reading, and maybe email correspondence, all in
one environment. Let's get started!

Dan

------- End of forwarded message -------

From connolly@pixel.convex.com  Thu Dec  5 19:25:22 1991
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03918; Thu, 5 Dec 91 19:25:22 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA01254; Thu, 5 Dec 91 19:14:08 +0100
Received: from pixel.convex.com by convex.convex.com (5.61/1.35)
	id AA08473; Thu, 5 Dec 91 12:19:25 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA29899; Thu, 5 Dec 91 12:16:12 -0600
Message-Id: <9112051816.AA29899@pixel.convex.com>
To: wais-talk@think.com
Cc: tcl@allspice.berkeley.edu, www-talk@nxoc01.cern.ch
Subject: documents, files, types, and access methods
Date: Thu, 05 Dec 91 12:16:11 CST
From: connolly@pixel.convex.com

Someone mentioned that WAIS should obviate the need for FTP. I disagree.
I think that the WAIS protocol is good for finding documents, but not
necesarily for transferring or displaying them.

There are two scenarios that WAIS is good for:

A. The database is built for wais. For example, DowQuest. That database is
stored so that it can be efficiently acessed and delivered through WAIS.

In this case, it makes sense to transfer the contents of the documents through
WAIS and to use the nifty chunking ideas.

B. The database is built for system X, and somebody sicked waisindex on it.
This is currently, by far the most common case. Look at all the USENET
archives, biology databases, library catalogs, etc. that weren't designed for
use with WAIS, but they work pretty well.

In this case, it makes more sense to me to transfer and/or present the
documents using the clients that the database was designed for. The WAIS server
should send enough information to retrieve and/or display the document using the
other client.

Example: the archie database. As a user, I want to query the archie
database using WAIS's fulltext and relevance feedback queries, but I want to
retrieve the documents with FTP, and I may want to "present" them with
uncompress and tar, or lpr, or ghostscript, etc.

Example: USENET news. I want to query using WAIS, but read it with my
news reader.

Example: my mail box. Query with wais, display with Xmh, Elm, mh, emacs, etc.

Retrieving the whole document with WAIS and saving it to a file is no good in
this day and age of client-server computing. The WAIS client may be on a
machine with no disk space to spare. And I may want to use the file on a
different host.

So we see that the WAIS client needs to hand off documents to other clients.
This raises the question: what information should the WAIS search client pass
to the retrieval/display slave clients, and how?

The CNI-ARCH folks are discussing a standard for document identifiers. I
think this is definitely one of the things that WAIS should pass, but it's
not the only thing.

I'm beginning to look at documents sort of like records in a relational
database. The WAIS client should negociate with the slave client what fields
they have or are interested in. An obvious representation for these records
is the RFC-822 mail message format.

Example: the archie database.

I use my xwais client to query archie.src on "vgrind." My xwais client gets a
list of docids from the WAIS server. These docids contain at least the score
and the CNI-ARCH style docid, which in this case would be enough info to
construct a prospero file handle [I'm not sure there is such a thing as a
prospero file handle, but play along anyway...].

I play gui-games with xwais until I get the list of documents that I like.
Then, using some mechanism like the X selection mechanism or drag-and-drop
(combined with SMTP, perhaps), I select a document and give it to my xftp
application. The xwais client and the xftp client agreed earlier that they
would send messages like:

From:		xwais@x.server.host
To:		xftp@x.server.host
CNI-ARCH-ID:	<12345@prospero:quiche.cs.mcgill.ca>
SIZE-IN-BYTES:	120034
FTP-HOST:	export.lcs.mit.edu
FTP-USER:	anonymous
FTP-CD:		pub/util
FTP-GET:	vgrind.tar.Z

blah blah blah about vgrind, perhaps explaining what query found this file,
or perhaps some stuff from the README in vgrind.tar.Z
.

I have already played gui-games with xftp to tell it where to put the files
it retrieves. When it gets this message, it does the HOST, USER, CD, and GET
commands, and presto! I've got my document.

I think if we had a suite of these gui tools talking SMTP to each other, they
could get a lot of work done. More examples:

To:	xtar@x.server.host
fopen:	/home/connolly/vgrind.tar
	or perhaps
popen:	zcat /home/connolly/vgrind.tar.Z

	xtar has a gui for selecting a place to extract the archive

To:	xlpr@x.server.host
fopen:	/home/connolly/vgrind-2.1/manual.ps
	or
popen:	zcat /home/connolly/vgrind-2.1/manul.ps.Z |

	xlpr selects destination printer, copies, etc.


Most tools fit in naturally. The $PAGER and $EDITOR, and perhaps $SHELL tools
could be MUCH more powerful if they could interoperate this way. [Has anybody
used mx and tx from John Osterhout(sp?) ? Those and the Tk toolkit allow X
applications to send commands back and forth.]

For example, the World-Wide-Web browser would fit the role of $PAGER in this
environment. It would receive messages to display WWW nodes, containing their
HTTP address (or NNTP, FTP, etc.). It would then display the node and allow
the user to scroll around and choose anchors etc. It could handle most
anchors by itself, but it might want to let the user select a region of text
and send it to the WAIS client.

I don't think there's an $EDITOR that fits very well, though emacs is always a
contender, and you have to have vi.
[I think the mouse support in emacs needs a LOT of work, but I probably
haven't seen the latest and greatest stuff.]

I'm not sure how $SHELL fits into all this but, for example, folks send shell
commands in mail messages to each other all the time. You could just select
the shell command in your mail $PAGER, and drag it to your $SHELL x-client
for invocation.

I hope I get time to try to implement a couple of these ideas. Then we can
all see whether they're worth persuing.

Dan

From emv@shelley.aa.ox.com  Fri Dec  6 01:33:36 1991
Return-Path: <emv@shelley.aa.ox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04159; Fri, 6 Dec 91 01:33:36 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA20299; Fri, 6 Dec 91 01:22:17 +0100
Received: by shelley.aa.ox.com (/\==/\ Smail3.1.22.1 #22.9)
	id <m0kpTDB-000Ds7C@shelley.aa.ox.com>; Thu, 5 Dec 91 19:14 EST
Message-Id: <m0kpTDB-000Ds7C@shelley.aa.ox.com>
To: connolly@pixel.convex.com
Cc: wais-talk@think.com, tcl@allspice.berkeley.edu, www-talk@nxoc01.cern.ch
Subject: Re: documents, files, types, and access methods 
In-Reply-To: Your message of Thu, 05 Dec 91 12:16:11 -0600.
             <9112051816.AA29899@pixel.convex.com> 
Date: Thu, 05 Dec 91 19:14:37 -0500
From: Edward Vielmetti <emv@ox.com>
X-Mts: smtp

data, data, data, data, data.

if you have good ideas about document structure and ways to send
messages around that have magic cookies in them, that's good.  but in
order to convince anyone to do anything substantial in terms of
software development you need to provide data.

get 100 entries describing 100 things that are useful, add enough
structure that a motivated party can pull your database apart and
create something new from it, and people will start to write code.
(honest.)  produce another 10 entries a month for a year and more
people will write code or bend their existing code to work with your
system.

Don't wait for an all-singing, all-dancing standard before you start
to collect information.  If you gather enough stuff and organize it
well, other people will do the work of bringing it up to what is
considered standard (if and when that happens).  You do need to be
thorough in making sure that whatever you do is consistent and regular
enough to be worth retrofitting.

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120


From rusty@groan.berkeley.edu  Fri Dec  6 02:18:12 1991
Return-Path: <rusty@groan.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04188; Fri, 6 Dec 91 02:18:12 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA22015; Fri, 6 Dec 91 02:06:59 +0100
Received: by groan.Berkeley.EDU (5.57/1.41)
	id AA26777; Thu, 5 Dec 91 17:13:22 -0800
Date: Thu, 5 Dec 91 17:13:22 -0800
From: rusty@groan.berkeley.edu (Rusty Wright)
Message-Id: <9112060113.AA26777@groan.Berkeley.EDU>
To: emv@ox.com
Cc: connolly@pixel.convex.com, wais-talk@think.com, tcl@allspice.berkeley.edu,
        www-talk@nxoc01.cern.ch
In-Reply-To: <m0kpTDB-000Ds7C@shelley.aa.ox.com> "emv@ox.com"
Subject: documents, files, types, and access methods 

I don't understand what this all has to do with tcl.

From vanandel@rsf.atd.ucar.edu  Fri Dec  6 17:52:35 1991
Return-Path: <vanandel@rsf.atd.ucar.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04815; Fri, 6 Dec 91 17:52:35 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA18576; Fri, 6 Dec 91 16:38:59 +0100
Received: from keel.atd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Office 04/10/90)
	id AA19557; Fri, 6 Dec 91 08:44:17 MST
Message-Id: <9112061544.AA04345@rsf.atd.ucar.EDU>
Received: from wabbit4.atd.ucar.edu by rsf.atd.ucar.EDU (5.65/ NCAR Mail Server 04/10/90)
	id AA04345; Fri, 6 Dec 91 08:44:01 MST
To: wais-talk@think.com, www-talk@nxoc01.cern.ch
Cc: tcl@allspice.berkeley.edu
Subject: What's "wais" and "wwv" ?
In-Reply-To: Your message of Thu, 05 Dec 91 19:14:37 -0500.
             <m0kpTDB-000Ds7C@shelley.aa.ox.com> 
Date: Fri, 06 Dec 91 08:43:57 -0700
From: vanandel@rsf.atd.ucar.edu


Some of us on the tcl mailing list feel like we came in on the middle
of a discussion and don't know the context.  Since there are apparently
mailing lists for 'wais' and 'wwv',could someone give a general description
of what "wais" and "wwv" are?

Thanks much!

	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	NCAR / RSF  			
	P.O Box 3000		Fax:	 303-497-2044
	Boulder, CO 80307-3000	Voice:	 303-497-2071 

From welch@parc.xerox.com  Fri Dec  6 18:56:17 1991
Return-Path: <welch@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04914; Fri, 6 Dec 91 18:56:17 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA00186; Fri, 6 Dec 91 18:45:04 +0100
Received: from corvina.parc.xerox.com ([13.2.116.10]) by alpha.xerox.com with SMTP id <11798>; Fri, 6 Dec 1991 09:48:42 PST
Received: by corvina.parc.xerox.com id <36899>; Fri, 6 Dec 1991 09:46:21 -0800
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.corvina.parc.xerox.com.sun4.40
          via MS.5.6.corvina.parc.xerox.com.sun4_40;
          Fri,  6 Dec 1991 09:46:19 -0800 (PST)
Message-Id: <IdDvRfgB0bE_87aBRm@corvina.parc.xerox.com>
Date: 	Fri, 6 Dec 1991 09:46:19 PST
Sender: Brent Welch <welch@parc.xerox.com>
From: Brent Welch <welch@parc.xerox.com>
To: connolly@pixel.convex.com
Subject: Re: documents, files, types, and access methods
Cc: wais-talk@think.com, www-talk@nxoc01.cern.ch, tcl@allspice.berkeley.edu
In-Reply-To: <9112051816.AA29899@pixel.convex.com>
References: <9112051816.AA29899@pixel.convex.com>

The model that TCL has it that each tool has an embedded TCL
interpreter, and tools can issue commands to each other in the TCL
language.  TCL is designed to be simple for simple things, and it is
fully programmable.  TCL provides basic language features, and the
application that embeds an interpreter can define new commands, either
as C procedures or as TCL command procedures (scripts).  For example,
the Tk X toolkit defines a number of TCL commands to create widgets, so
it is possible to write window programs with a script.  Since each
window (ideally) has a TCL interpreter behind it, you can control your
tools by sending around TCL commands.  This is a more powerful
alternative to using mail header formats for messages. You can send
whole programs, not just commands.  The way I use this currently is to
couple a control panel with a shell window.  The control panel is put
together as a TCL/Tk script that uses the Tk toolkit to display buttons,
etc.  Clicking on buttons in the control panel can cause messages to be
sent to the terminal emulator (tx).  One very useful command passes a
string along to the shell running in the terminal emulator.  In this way
I can create buttons that run commonly used programs.  Other commands
control the terminal emulator itself, such as its size and placement on
the screen, the message in its status line, etc.  The whole model of a
bunch of tools that have a common language and can fire off commands to
each other is very powerful.

	Brent Welch

From timbl  Mon Dec  9 15:33:46 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06290; Mon, 9 Dec 91 15:33:46 GMT+0100
Date: Mon, 9 Dec 91 15:33:46 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9112091433.AA06290@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: wei@xcf.berkeley.edu (Pei Y. Wei)
Subject: Re: SGML/HTML docs, X Browser
Cc: www-talk

Pei,

I have added you to www-talk as requested.

> I'm now browsing through parts of the WWW distribution, and I'm  
seeing
> lots of potential in it. It seems that the only browser is for the  
NeXT,
> a platform most people don't have access to, which is a shame. 

> I'm now seriously considering writing an X11 browser for HTML files
> by extending a program I've been working on (called VIOLA, a  
program 

> somewhat like HyperCard)...

Ok.. sounds like a good idea.  Dan Conolly (Convex Inc) has put  
together a W3 browser for X but could not release the code.  A group  
of students in Finland were also going to do this for a project -- I  
don't know the status of that work.  Anyone who makes a good X11 W3  
browser will be very popular.

Now we have just got a new architecure for the browser code, with a  
generic (simple!) SGML parser, and basically all the browser code  
common (networking, name resulution, parsing) between different  
browsers. The new line mode browser is under test - it has NNTP  
access to news built in as well as HTTp and FTP access to indexes and  
files.

> I'm wondering if you could give me some pointers to the standards 

> SGML and HTML (which seems to be the HyperText extention of SGML?).

SGML is very general. HTML is a specific application of the SGML  
basic syntax applied to hypertext documents with simple structure.  
The HTML tags used are in our documentation. (If you browse to our  
test document, it has a link to its own source which you can take as  
an example.) Type

www http://info.cern.ch/hypertext/WWW/Test/test_source.html

and follow the first link to see the source.  Our code therefore has  
a simple generic SGML parser engine which handles nested tags and  
feeds a HTML parser which has hypertext-specific code in it.  That  
feeds a stream of style-changes and text and anchor start/end points  
into a hypertext object which is what we don't have under X.

> Anymore relevant documentation on SGML/HTML, tips, and whatever you 

> think may help me in my task, would be gratfully accepted.

I could make up a tar file of our alpha-test code, including the HTML  
SGML parser. Any pointers to SGML I have are in the web - not much  
public stuff. Two books are "SGML Handbook" by Charles Goldfarb, and  
"Practical SGML" by Eric van Herwijnen.

> Pei Y. Wei (wei@scam.Berkeley.EDU)
> Experimental Computing Facility, 

> University of California @ Berkeley

Thanks for your interest, welcome to the list.

	Tim



__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155






From timbl  Mon Dec  9 17:31:23 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06470; Mon, 9 Dec 91 17:31:23 GMT+0100
Date: Mon, 9 Dec 91 17:31:23 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9112091631.AA06470@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Daniel J. Oberst <oberst@hitam.princeton.edu>
Subject: Re: WWW implementation of PNN
Cc: www-talk, Howard@pucc.princeton.edu, fuchs@tsar.princeton.edu


> From: Daniel J. Oberst <oberst@hitam.princeton.edu>
> Cc: Howard@pucc.princeton.edu, fuchs@tsar.princeton.edu
> 

> Tim,
> 

> Our group has been working with WWW and looking at implementing our  
locally-developed PNN (Princeton News Network) Campus Wide  
Information Service.  Howard Strauss, who designed PNN, has written  
an EXEC that takes the PNN "menu" files and converts them into WWW  
html documents.  We're working on setting up the files and finding a  
place for them so that they can be accessed from WWW.  One nice  
by-product is that we will now have a line-mode access to the  
information in PNN, something that had been requested before (PNN  
only works in 3270 mode on our 3090, VT100 or curses mode on our unix  
implementation, and with Hypercard on a Mac).
- - - - -
> Parenthetically, I thought I had seen something about a 3270  
implementation of WWW, but can't seem to locate it (*even* with  
WWW!). Is there a 3270 implementation different from the line-mode  
version?

   No, it's just the line mode version, with a few clear screen
   calls. As the v1.0 line mdoe browser can scroll backward, we
   should be able to link the PF keys to the browser's commands
   while in WWW. There's no "move-cursor-hit-enter" functionality.
 - - - - - -
> I asssume that the best way to make these available is via HHTP?   
The PNN files here are NFS exported to all machines on campus, so our  
first implementation just used local file hypertext pointers.  I  
assume to make these available, we'd need to use the hhtp tags on the  
file references. Is this what you have done at CERN with your WWW?  
We'll try and get a hhtp server up and running on a test machine and  
try it out

    Great.  If you have a set of html files, an HTTP server (The
    distributed daemon) gives faster access than using anonymous FTP.
    The documentation about setting up the daemon should be complete
    on the web -- if there are holes in it just let me know.
    We use the daemon (httpd) to publish our own documentation on W3,
    but the documenattion comming from VM is actually transcibed
    into html on the fly by a custom server. [The regular daemon
    runs in a service machine, calls an EXEC which leaves the
    html on the stack for the daemon to read off. I  could send you
    C code if you like]. This has the advantage that it takes the
    data right from the source -- it's only stored in one place --
    but the disadvantage for me that a server has to be maintained on
    the strange IBM machine ;-).

> We'll keep you posted on our progress.

   Thanks.

> One side benefit could be that other sites running the PNN code  
could use the same tools to make their info WWW-able!!

    How many other sites are running PNN? It would be great to see
    some more CWISs coming onto the web.


> FYI - I've included below a sample file and conversion that was  
created.

    Looks good. [You could chop the leading spaces on the heading, as
    w3 will center it anyway. Also, the line "
    "Move the cursor to any topic below and press Enter"
    is a little misleading for www users - you might want to
    "hand-craft" just the top level menu page to remove that,
    and possibly put links to other CWISs, etc.]


> Daniel J. Oberst
> Director, Advanced Technology and Applications
> Computing and Information Technology
> Princeton University
> 116 Prospect Avenue
> Princeton, NJ 08544-2089

    Tim Berners-Lee                       timbl@info.cern.ch
    World Wide Web project                (NeXTMail is ok)	
    CERN                                  Tel: +41(22)767 3755
    1211 Geneva 23, Switzerland           Fax: +41(22)767 7155





__________________________________________________________________
- - - - -
FILE: pnn.mainmenu

@T@          PNN - The Princeton News Network
@M@            Click ONCE on any topic below
@M@
@T@   Move the cursor to any topic below and press Enter
@T@
help dialog*@D@HELP
@A@
index node@N@Index to Information in PNN
new node@N@What's New on PNN
@A@
about inter@I@About PNN
events inter@I@Calendars and Events
org inter@I@Campus Organizations
gphone dialog*@E@Campus Phone Book@GETPHONE
service inter@I@Campus Services & Facilities
computr inter@I@Computing Resources
course inter@I@Curriculum & Course Information
@*@                                Column 2 starts here
@C@
@E@Dial-a-Fortune@FORTUNE
facstaff inter@I@Faculty & Staff Activities
library inter@I@Library Information
misc inter@I@Potpourri
police inter@I@Safety Information
student inter@I@Student & Grad Student Activities
transpor inter@I@Travel & Visitor Information
uemploy inter@I@University Employment Information
policy inter@I@University Policies & Procedures
whoswho inter@I@University Who's Who
weather node@N@Weather Forecast
----------------------------
SCREEN: PNN main menu:

           PNN - The Princeton News Network
    Move the cursor to any topic below and press Enter

HELP                                   Dial-a-Fortune
                                       Faculty & Staff Activities
Index to Information in PNN            Library Information
What's New on PNN                      Potpourri
                                       Safety Information
About PNN                              Student&GradStudent Activities
Calendars and Events                   Travel & Visitor Information
Campus Organizations                   University Employment Info
Campus Phone Book                      University Policies&Procedures
Campus Services & Facilities           University Who's Who
Computing Resources                    Weather Forecast
Curriculum & Course Information        Exit PNN

----------------------------
FILE: pnn.html

<H1>          PNN - The Princeton News Network</H1>
<H2>   Move the cursor to any topic below and press Enter</H2>
<H3></H3>
<UL>
<LI><A HREF=help.dialogww>HELP</A>
<LI><A HREF=index.node>Index to Information in PNN</A>
<LI><A HREF=new.node>What's New on PNN</A>
<LI><A HREF=about.html>About PNN</A>
<LI><A HREF=events.html>Calendars and Events</A>
<LI><A HREF=org.html>Campus Organizations</A>
<LI><A HREF=service.html>Campus Services & Facilities</A>
<LI><A HREF=computr.html>Computing Resources</A>
<LI><A HREF=course.html>Curriculum & Course Information</A>
<LI><A HREF=facstaff.html>Faculty & Staff Activities</A>
<LI><A HREF=library.html>Library Information</A>
<LI><A HREF=misc.html>Potpourri</A>
<LI><A HREF=police.html>Safety Information</A>
<LI><A HREF=student.html>Student & Grad Student Activities</A>
<LI><A HREF=transpor.html>Travel & Visitor Information</A>
<LI><A HREF=uemploy.html>University Employment Information</A>
<LI><A HREF=policy.html>University Policies & Procedures</A>
<LI><A HREF=whoswho.html>University Who's Who</A>
<LI><A HREF=weather.node>Weather Forecast</A>
</UL>



From timbl  Fri Dec 13 17:55:53 1991
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11835; Fri, 13 Dec 91 17:55:53 GMT+0100
Date: Fri, 13 Dec 91 17:55:53 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9112131655.AA11835@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-interest, www-talk
Subject: WWW to SPIRES on SLACVM - Experimental
Cc: pfkeb@kaon.slac.stanford.edu (Paul Kunz)

There is an experimental W3 server for the SPIRES High energy Physics preprint  
database, thanks to Terry Hung, Paul Kunz and Louise Addis of SLAC.  It's only just  
been put up, so don't expect perfection.   With the w3 line mode browser, follow a  
link to it from our home page, then type for example

	K FIND AUTHOR KUNZ

the "FIND" is necessary at the moment, though it may change later.

	- Tim

Paul Kunz wrote a few days ago:-

   "The SLAC Library maintainer of SPIRES databases, Louise Addis, is absolutely  
delighted.   She will ask for a permanent VM service machine and finish off the  
polishing.   Things are really moving now."

   "By the way, we certainly have the impression that accessing SPIRES from www on  
a UNIX machine is faster than using a terminal logged into SLACVM.   Even a real  
3278 terminal is not as fast.   Actually, accessing CERNVM FIND via www seems  
faster than logging into cernvm and doing the same command as well."


From wei@xcf.berkeley.edu  Fri Dec 13 20:53:09 1991
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11940; Fri, 13 Dec 91 20:53:09 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA13707; Fri, 13 Dec 91 20:47:33 +0100
Received: by swindle.berkeley.edu (5.57/Ultrix3.0-C)
	id AA25342; Fri, 13 Dec 91 11:45:05 -0800
Date: Fri, 13 Dec 91 11:45:05 -0800
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9112131945.AA25342@swindle.berkeley.edu>
To: www-talk@nxoc01.cern.ch
Subject: X Browser

Forgot to CC...

>To: timbl@nxoc01.cern.ch
>Subject: X Browser

Hi, Tim.

Thanks for most helpful information for my research on SGML.

>Now we have just got a new architecure for the browser code, with a
>generic (simple!) SGML parser, and basically all the browser code
>common (networking, name resulution, parsing) between different
>browsers. The new line mode browser is under test - it has NNTP
>access to news built in as well as HTTp and FTP access to indexes and
>files.
>I could make up a tar file of our alpha-test code, including the HTML
>SGML parser.

Yes, I'm very interested in using that code, and do the testing...
Regarding the X browser, I was able to rig up an X11 W3 browser by 
using viola as the front end to www (I only had to make very few and 
minor changes to www.c). It's not very sophisticated at this point
(a one nite hack...), and does not much more than display the output 
of www in a scrollable text field, highlite the reference numbers for
visibility, make references and commands (Back, Help...) clickable 
or keyable, and has a few buttons corresponding to the www commands.

One thing I'd like to do soon, if I have time, is to teach the parser
about viola object descriptions, and basically embed viola objects
(GUIs & programmability) into html files.

Thanks.

-Pei

From timbl  Thu Jan  9 12:34:24 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08666; Thu, 9 Jan 92 12:34:24 GMT+0100
Date: Thu, 9 Jan 92 12:34:24 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9201091134.AA08666@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Mark Alexander Davis-Craig <mad@merit.edu>
Subject: Re: Is there a paper which describes the www protocol?
Cc: www-talk



> From: Mark Alexander Davis-Craig <mad@merit.edu>
> 

> I was looking through the web and found information on servers and
> clients.  I saw mention in the "History" section about wanting to
> develop a good protocol for information exchange, but haven't seen a
> paper specifically about the www protocol.  Is there one?  If not,
> could you describe it in some detail?

You are right that the protocol documentation was not as good as it could
have been. I have improved it. To save you browing through the web for it,
I append to this message the information as plain text.

> I ask because we at the University of Michigan are evaluating www,
> wais, and gopher for campus-wide information delivery.
>

I have no need to tell you what our suggestion would be!  The W3 architecure
will give you (almost) everything you can get from WAIS and Gopher rolled into one.
The trick is that almost anything is representable by hypertext links and index searches. The  
Gopher menus and plain text, for example, are both special cases of hypertext.  As it is more  
work to do the job for hypertext in general, we do not yet have software to cover as many  
platforms as Gopher, for example. However, when we do, the W3 system will be more flexible.   
Running a W3 server on top of a WAIS or Gopher world in fact makes these worlds subsets of the W3  
web. The reverse is not possible because the WAIS and Gopher information models are not flexible  
enough
to encompass the W3 model.

That said, if you want an indexer we can only recommend the wais code (or NeXT code) and we do  
not yet supply (as Gopher does) an off-the shelf index server for either of those indexes yet. It  
is easy to do, however, with our generic server code.

Please keep me informed of your thinking, whether you plan to go W3 or Gopher.  If we can help  
you set up a demonstration system, then mail me.
 

>Thanks in advance.
>  -----------------------------------------------------------------
>  Mark Davis-Craig, Merit/MichNet Technical Support Consultant
>  mad@merit.edu        mad@merit.bitnet        (313)-936-2110


Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155

_________________________________ protocol notes follow ___________


                                         The HTTP Protocol As Implemented In W3


                          HTTP AS IMPLEMENTED IN WWW
                                       

   This document defines the Hypertext Transfer protocol  (HTTP) as currently
   implemented by the WorldWideWeb initaitive software. This is a subset of the
   proposed full HTTP protocol.  No client profile information is transferred
   with the query. Future HTTP protocols will be back-compatible with this
   protocol.
   

    The protocol  uses the normal internet-style telnet protocol style on a
   TCP-IP link. The following describes how a client acquires a (hypertext)
   document from an HTTP server, given an HTTP document address .
   

Connection

   The client makes a TCP-IP connection to the host using the domain name or IP
   number , and the port number  given in the address.
   

    During development, the default HTTP TCP port number is 2784 -- this will
   change when an official port number is allocated.
   

    The server accepts the connection.
   

    Note: HTTP currently runs over TCP, but could run over any
   connection-oriented service.   The interpretation of the protocol below in
   the case of a sequenced packet service (such as DECnet(TM) or ISO TP4) is
   that that the request should be one TPDU, but the repose may be many.
   

Request

   The client sends a document request consisting of a line of ASCII characters
   terminated by a CR LF (carriage return, line feed) pair. A well-behaved
   server will not require the carriage return character.
   

    This request consists of the word "GET", a space, the document address ,
   omitting the "http:, host and port parts when they are the coordinates just
   used to make the connection. (If a gateway is being used, then a full
   document address may be given specifying a different naming scheme).
   

    The search functionality of the protocol lies in the ability of the
   addressing syntax to describe a search on a named index .
   

    A search should only be requested by a client when the index document
   itself has been descibed as an index using the  ISINDEX tag .
   

Response

   The response to a simple GET request is a message in hypertext mark-up
   language ( HTML ). This is a byte stream of ASCII characters.
   

    Lines shall be delimited by an optional carriage return followed by a
   mandatory line feed chararcter. The client should not assume that the
   carriage return will be present.  Lines may be of any length. Well-behaved
   servers should retrict line length to 80 characters excluding the CR LF
   pair.
   

    The format of the message is HTML - that is, a trimmed SGML document. Note
   that this format allows for menus and hit lists to be returned as hypertext.
   It also allows for plain ASCII text to be returned following the  PLAINTEXT
   tag .
   

    The message is terminated by  the closing of the connection by the server.
   

    Well-behaved clients will read the entire document as fast as possible. The
   client shall not wait for user action (output paging for example) before
   reading the whole of the document.  The server may impose a timeout of the
   order of 15 seconds on inactivity.
   

    Error responses are supplied in human readable text in HTML syntax. There
   is no way to distinguish an error response from a satisfactory response
   except for the content of the text.
   

Disconnection

   The TCP-IP connection is broken by the server when the whole document has
   been transferred.
   

    The client may abort the transfer by breaking the connection before this,
   in which case the server will not record any error condidtion.
   

    Requests are idempotent .  The server need not store any information about
   the request after disconnection.
   

    _________________________________________________________________
   

                                                                         Tim BL
                                                                               

                               W3 NAMING SCHEMES
                                       

   (See also: a discussion of design issues involved , BNF syntax , W3
   background)
   

    The format of a hypertext name consists of the name of the naming
   sub-scheme to be used, then a name in a format particular to that subscheme,
   then an optional anchor identifier within the document. For example, the
   format is for all internet-based access methods:
   

      scheme : // host.domain:port / path / path  # anchor
   

    A suffix # anchor id allows one to refer to a particular anchor within a
   document.
   

    A suffix ? followed by words separated by + signs  allows one to seach an
   index (see details ).
   

    References from one document to another with a similar name may be
   abbreviated to a relative name . This imposes certain restrictions on the
   way that the "path" is represented.
   

    A special format is used to represent a search on an index . See also: the
   full BNF description , about escaping illegal characters .
   

Examples


         file://cernvax.cern.ch/usr/lib/WWW/defaut.html#123

   This is a fully qualified file name, referring to a document in the file
   name space of the given internet node, and an imaginary anchor 123 within
   it.
   


         #greg

   This refers to anchor "greg" in the same document as that in which the name
   appears.
   

Naming sub-schemes

   Different schemes usually use different protocols on the network. The format
   of the address after the scheme name is a function of the particular scheme.
   In practice, all internet-based schemes have a common format for the node
   name and port.   Schemes currently defined are as follows, with links to
   more details.
   

  file                    Access is provided to files, using whatever means the
                         browser and/or gateways have to reach files on obscure
                         machines.
                         

  news                    Access is provided to news articles, and newsgroups,
                         normally using the NNTP protocol.
                         

  http                    Access is provided to any other information using the
                         HTTP search and retrieve protocol . The internal
                         addressing of the information system is mapped onto a
                         W3 path.
                         

  telnet                  Access is provided by an interactive telnet session.
                         This is provided ONLY as an interface to other
                         existing online systems which cannot or have not been
                         mapped onto the W3 space.
                         

  gopher                  Access is provided using the "gopher" protocol. The
                         gopher protocol is similar to HTTP but uses separate
                         concepts of menus and text files rather than
                         hypertext.
                         

   Other schemes we foresee are wais and x500.  Systems (such as WAIS) which
   are not currently accessed directly be W3 servers may be accessed though
   gateways, in which case the document address is encoded within the http
   address of the document in the gateway.  Browsers which do not have the
   ability to use certain protocols may (in principle) be configured to
   automaticaly use certain gateways for certain addressing schemes.
   

    This will allow, for example, simple PC-based clients to follow links
   through X500 name servers.
   

                                RELATIVE NAMING
                                       

   The address of a hypertext document is normally given within the context of
   another hypertext document. Where the addresses of the two documents are the
   similar, this allows only the difference between the two names to be given,
   saving space. An example is the address of the destination of a hypertext
   link , which is specified relative to the source document address.
   

    (A futher practical advantage is that a group of documents may be
   transmitted without internal changes, or accessed using more than one
   address.)
   

    In the WWW address format , the rules for relative naming are:
   

       If the "scheme" parts  are different, the whole absolute address must be
          given. Other wise, the scheme is omitted, and:
          

       If the "host" and/or "port" parts are the different, the host name and
          all the rest of the address must be given. The host name may be given
          using internet hostname conventions, ie domains may be omitted where
          different. This is not very well defined:  one tends to assume that
          if any dot is present, then the full domain name is being given, up
          to the root (.) domain, while if there are no dots, the domain is the
          same as that of the hostname part of the the base address.
          

       If the access and host parts are the same, then the path may be given
          with the unix convention, including the use of  ".." to mean indicate
          deletion of a path element. Within the path:
          

       If a leading slash is present, the path is absolute. Otherwise:
          

       The last part of the path of the base address (e.g. the filename of the
          current document) is removed, and the given relative address appended
          in its place.
          

       Within the result,  all occurences "xxx/.."  are recursively removed,
          where xxx is one path element (directory).
          

   The use of the slash "/" and double dot ".." in this case must be respected
   by all servers. If necessary, this may mean converting their local
   representations in order that these characters should not appear within path
   elements (see "escaping").
   

                          ADDRESS FOR AN INDEX SEARCH
                                       

   If a given hypertext node is an index, or the server has an index associated
   with it, then a search may be done on that index by suffixing the name of
   the index with a list of keywords, after a question mark:
   


        address_of_index ? keywordlist

   The address of the index is a normal hypertext address. In the keuwordlist,
   multiple keywords are separated by plus signs (+) .  (See BNF syntax
   description .)  The resulting string still does not contain any spaces. It
   may be considered to be the hypertext address of a document which is the
   result of making the keyword search on the index. Normally, if the search
   was successful, the document returned will contain anchors leading to other
   documents which match the selection criteria.
   

    The search method, and the logical and lexical functions, weights, etc
   applied to the keywords will depend on the index address.  One actual index
   may have several hypertext addresses,  which when searched on will behave in
   different ways. For example, one may allow a search on author-given keywords
   only, while another may be a full text search.  These things particular to
   an index should be descibed in the hypertext page for the index node itself
   (or in linked documents). For example, a server may allow specific boolean
   search combinations may be represented by the words "and", "or" and "not".
   

Example:


                http://cernvm/FIND/?sgml+cms

   indicates the result of perfoming a search for keywords "sgml" and "cms" on
   the index http://cernvm/FIND/.
   

                                HTTP ADDRESSING
                                       

   With an access code of http:,  a protocol introduced for  the WWW initiative
   is used to acquire data from a server. This is the "Hypertext Transfer
   protocol", HTTP , a simple search and retrieve (S and R) protocol.
   

    The syntax of an http address is, with [] indicating optional parts (see
   BNF description ),
   


        http : // hostname [ : port ] / path [ ? searchwords ]

   for example, the following are valid addresses:
   


        http://info.cern.ch/hypertext/WWW/TheProject.html

        http://crnvmc.cern.ch/FIND?sgml+examples

   HTTP addresses conform to the WWW conventions,  including the possibility of
   using the search format . The significance of the items in the path part of
   the document name is completely up to the server. Different paths may be
   used to select different databases, different views of the same database,
   etc.
   

  hostname                This is the name of the server in internet form. A
                         numeric form (e.g. 128.141.201.74) may be used, by the
                         domain name form (e.g. info.cern.ch) is preferred. The
                         hostname is mandatory.
                         

  port                    This is a numeric port number. If a non-numeric
                         string is used, it must be a defined service name.
                         Note that as there is no central repository for
                         service names (they are defined locaaly for each
                         host), a service name is NOT an appropriate way to
                         specify a port number for a hypertext address. If the
                         port number is omitted the preceding colon must also
                         be omitted. In this case, port number 2784 is assumed
                         [This may change!].
                         

  See also: WWW addressing in general , HTTP protocol .
                         

   _________________________________________________________________
   

                                                                         Tim BL
                                                                               

                             W3 ADDRESSES OF FILES
                                       

   The format of a hypertext reference to a file is an extension of the unix
   naming system. The full explicit format is:
   

       file :  //  node /  directories /  name
   

    The actual protocols used by the client depend on the implementation of the
   browser and the environment. Typically, the browser will check to see
   whether the node is the local node,  or a node for which files are available
   mounted in some form of distributed file system.  If neither of these are
   the case, then the browser may try rpc, anonymous FTP or other protocols.
   

Examples


         file://cernvax.cern.ch/usr/lib/WWW/defaut.html

   This is a fully qualified file name.
   


         fred.html

   This relative name , used within a file, will refer to a file of the same
   node and directory as that file, but the name fred.html.
   

Improvements : Directory access

   The final file name should be optional. If the address ends with a '/', the
   browser should retrieve the contents of the specified directory and generate
   a page of virtual hypertext pointing to its contents. In addition, it could
   display an information file contained in that directory, if any is present.
   Suggested file names to search for in order : README.html, *README*.html,
   README, *README*, *readme*.
   

   

   

                        HYPERTEXT ADDRESS FOR NET NEWS
                                       

   The format of a hypertext reference to information in the internet/usenet
   news system can take any of the following forms:
   

  news: newsgroup         This refers to a list of articles currently available
                         in the given newsgroup. The newsgroup is a series of
                         alphanumeric characters and dots.
                         

  news:*                  This refers to a list of valid newsgroups.
                         

  news: message_id        This refers to a given article explicitly. The
                         message_id is optionally surrounded by angle brackets,
                         and must contain an @ sign.
                         

  

                         

   Possible extensions to this are more generous wildcarding for the list of
   newsgroups. It takes too long to load the whole list, and it would be more
   useful to be able to browse through a set of newsgroups.
   

    There is no way of referring to "unread" articles. Keeping track of this is
   the job of the browser.
   

Examples


         news:<12345678@cernvax.cern.ch>

         news:12345678@cernvax.cern.ch

   These addresses both refer to the same (imaginary!) article by its unique
   message-id.
   



news:comp.sys.next.announce

   This refers to a list of articles in the newsgroup comp.sys.next.announce.
   The list is, of course, a list of references to article by message-id.
   

                               TELNET ADDRESSING
                                       

   A telnet address is a spcecial case of a W3 address.
   

    When a telnet address is used, information can only be rertrieved using an
   interactive telnet session. This has the disadvantage that information
   cannot be indexed, searched, etc automatically, nor can it be gatewayed into
   other systems.  The telnet addressing form is used to allow a pointer to
   information systems such as library information systems which have not been
   gatewayed into the web properly yet.
   

    The syntax is, with [] indicating optional parts (see full BNF)
   


        telnet : / /  [ user @ ] host  [ : port ]

   There should be no spaces. For example, the following are valid telnet
   addresses:
   


        telnet://www@info.cern.ch:23

        telnet://www@info.cern.ch

        telnet://info.cern.ch

  user                   is the optional name of the user to be used for login.
                         If the username  is omitted, then so must be the "@"
                         sign. This is equivalent to the argument used with the
                         -l option on the ucb telnet command. When the username
                         is omitted, some access servers will prompt for a
                         username and password.
                         

  host                   This is the name of the server in internet form. A
                         numeric form (e.g. 128.141.201.74) may be used, by the
                         domain name form (e.g.  info.cern.ch) is preferred.
                         The host is mandatory.
                         

  port                   This is a numeric port number. If a non-numeric string
                         is used, it must be a defined service name. Note that
                         as there is no central repository for service names
                         (they are defined locaaly for each host),  a service
                         name is NOT an appropriate way to specify a port
                         number for a hypertext address. If the port number is
                         omitted the preceding colon must also be omitted. In
                         this case, port number 23 is assumed.
                         

   _________________________________________________________________
   

                                                                         Tim BL
                                                                               

                               GOPHER ADDRESSING
                                       

   Gopher addresses indicate that the gopher protocol should be used to access
   the information.  The Gopher protocol is a simple internet protocol similar
   to HTTP . It allows the transfer of menus or plain text files.  (HTTP
   expresses both menus and plain text files as special cases of hypertext
   files). See the gopher protocol notes .
   

    The syntax is, with [] indicating optional parts (see BNF )
   


        gopher:// hostname [: port ] [/gtype/ [selector] ] [ ? search ]

   There should be no spaces. For example, the following are valid addresses:
   


        gopher://gopher.micro.umn.edu:70

        gopher://gopher.micro.umn.edu:70/1/

        gopher://gopher.micro.umn.edu:70

   The W3 address for a gopher item may be derived from the fields of a gopher
   menu line which has the format
   

  host                    This is the name of the server in internet form. A
                         numeric form (e.g. 128.141.201.74) may be used, by the
                         domain name form (e.g. info.cern.ch) is preferred. The
                         hostname is mandatory.
                         

  port                    This is a numeric port number. If a non-numeric
                         string is used, it must be a defined service name.
                         Note that as there is no central repository for
                         service names (they are defined locaaly for each
                         host), a service name is NOT an appropriate way to
                         specify a port number for a hypertext address. If the
                         port number is omitted the preceding colon must also
                         be omitted. In this case, port number 70 is assumed.
                         

  gtype                   This is a gopher item type number, a (hopefully
                         printable!) ASCII character.  Currently these types
                         are all ASCII decimal digit characters. Character "0"
                         (hex 30)  signifies a plain text file. Character "1"
                         signifies a Menu.  Character "7" signifies a
                         searchable index.  Character "8" should not be used in
                         a W3 address: use telnet addressing instead.  In
                         general W3 terms, the type is the first part of the
                         path. The rest of the path is the gopher selector
                         string. The type field is a hint to the client as to
                         how to represent the anchor, and how to follow it.
                         

  selector                This is the string to be sent to the gopher server to
                         identify the information required.
                         

   _________________________________________________________________
   

                                                                         Tim BL
                                                                               

                          ESCAPING ILLEGAL CHARACTERS
                                       

   The W3 address syntax allows a path to contain most printable ASCII
   characters, but some are inevitably used for punctuation are excluded. W3
   addresses are sometimes used to represent addresses in some other space.
   This happens when an HTTP server, for example, uses file names as its
   document names, or when addresses from some other protocol (Gopher, WAIS,
   etc) are mapped into the W3 web.
   

    In these cases, a convention is normally used to map illegal characters in
   these "foreign" names onto the allowed set.
   

    In the case of an HTTP server,  any mapping may be used.
   

    A suitable convention is that a percent sign (%) followed by two
   hexadecimal digits (0-9 or a-f)  stands for the single character with ASCII
   hexadecimal code represented by those two digits (Most significant digit
   first).
   

    A percent sign itself must therefore be represented by %25, as 25 hex is
   the ASCII code for "%".
   

    _________________________________________________________________
   

                                                                         Tim BL
                                                                               

                            W3 ADDRESS SYNTAX: BNF
                                       

   This is a BNF-like description of the W3 addressing syntax . We use a
   vertical line "|" to indicate alternatives, and [brackets] to indicate
   optional parts.   Spaces are representational only: no spaces are actually
   allowed within a W3 address. Single letters stand for single letters. All
   words of more than one letter below are entites described elsewhere in the
   syntax description.  (Entity names are here linked to their definitions,
   probably making this unreadable with the line mode browser.)
   

    An absolute address specified in a link is an anchoraddress . The address
   which is passed to a server is a docaddress .
   

  anchoraddress           docaddress [ # anchor ]
                         

  docaddress              httpaddress | fileaddress | newsaddress |
                         telnetaddress | gopheraddress
                         

  httpaddress             h t t p :   / / hostport  [  / path ] [ ? search ]
                         

  fileaddress             f i l e : / / host / path
                         

  newsaddress            n e w s : groupart
                         

  groupart               * | group | article
                         

  group                  ialpha [ . group ]
                         

  article                xalphas @ host
                         

  telnetaddress           t e l n e t : / / [ user @ ] hostport
                         

  gopheraddress           g o p h e r : / / hostport  [/ gtype  [ / selector ]
                         ] [ ? search ]
                         

  hostport                host [ : port ]
                         

  host                    hostname | hostnumber
                         

  hostname                ialpha [  .  hostname ]
                         

  hostnumber              digits . digits . digits . digits
                         

  port                    digits
                         

  selector                path
                         

  path                    void |  xalphas  [  / path ]
                         

  search                  xalphas [ + search ]
                         

  user                    xalphas
                         

  anchor                  xalphas
                         

  gtype                   xalpha
                         

  xalpha                  alpha | $ | _ | @ | ! | % | ^ | | * |  (  |  ) | . |
                         digit
                         

  xalphas                 xalpha [ xalphas ]
                         

  ialpha                 alpha [ xalphas ]
                         

  alpha                   a | b | c | d | e | f | g | h | i | j | k | l | m | n
                         | o | p | q | r | s | t | u | v | w | x | y | z | A |
                         B | C | D | E | F | G | H | I | J | K | L | M | N  | O
                         | P | Q | R | S | T | U | V | W | X | Y | Z
                         

  digit                   0 |1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
                         

  digits                  digit [ digits ]
                         

  alphanum                alpha | digit
                         

  alphanums               alphanum [ alphanums ]
                         

  void
                         

  See also: General description of this syntax, Escaping conventions.
                         

   _________________________________________________________________
   

                                                                         Tim BL
                                                                               

                                     HTML
                                       

   The WWW system uses marked-up text to represent a hypertext document for
   transmision over the network. The hypertext mark-up language is an SGML
   format. This defines the basic syntax used. The particular language, the set
   of tags and the rules about their use, and their significance is not part of
   the SGML standard. There being no standard on this, we have adopted a set
   which seems sensible. We call them HTML -- hypertext markup language. HTML
   is not an alternative to SGML, it is a particular format within the SGML
   rules (an SGML "DTD"). HTML parsers should ignore tags which they do not
   understand, and ignore attributes which they do not understand of tags which
   they do understand.
   

    See also:
   

  The tags                A list of the tags used in HTML with their
                         significance.
                         

  Example                 A file containing a variety of tags used for test
                         purposes.
                         

Default text

   Unless otherwise defined by tags, text is transmitted as a stream of lines.
   The division of the stream of characters into lines is arbitrary, and only
   made in order to allow the text to be passed through systems which can only
   handle text with a limited line length. The recommended line length for
   transmission is 80 characters. The division into lines has no significance
   (except in the case of  example sections and PLAINTEXT ) apart from
   indicating a word end. Line breaks between tags have no significance.
   

                                   HTML TAGS
                                       

   This is a list of tags used in the HTML language.  Each tag starts with a
   tag opener (a less than sign) and ends with a tag closer (a greater than
   sign).   Many tags have corresponding closing tags which identical except
   for a slash after the tag opener. (For example, the TITLE tag).
   

    Some tags take parameters, called attributes. The attributes are given
   after the tag, separated by spaces. Certain attributes have an effect simply
   by their presence, others are followed by an equals sign and a value. (See
   the Anchor tag, for example). The names of tags and attributes are not case
   sensitive: they may be in lower, upper, or mixed case with exactly the same
   meaning.  (In this document they are generally represented in upper case.)
   

    Currently HTML documents are transmitted without the normal SGML framing
   tags, but if these are included parsers will ignore them.
   

Title

   The title of a document is given between title tags:
   


        <TITLE> ... </TITLE>

   The text between the opening and the closing tags is a title for the
   hypertext node. There should only be one title in any node. It should
   identify the content of the node in a fairly wide context, and should
   ideally fit on one line.
   

    The title is not strictly part of the text of the document, but is an
   attribute of the node. It may not contain anchors, paragraph marks, or
   highlighting. the title may be used to identify the node in a history list,
   to label the window displaying the node, etc. It is not normally displayed
   in the text of a document itself. Contrast titles with headings .
   

Next ID

   This tag takes a  single attribute which is the number of the next
   document-wide numeric identifier to be allocated (not good SGML). Note that
   when modifying a document,  old anchor ids should not be reused, as there
   may be references stored elsewhere which point to them.  This is read and
   generated by hypertext editors. Human writers of HTML usually use mnemonic
   alpha identifiers.  Browser software may ignore this tag. Example of use:
   


        <NEXTID 27>

Base Address

   Anchors specify addresses of other documents, in a from relative to the
   address of the current document. Normally, the address of a document is
   known to the browser because it was used to access the document. However, is
   a document is mailed, or is somehow visible with more than one address (for
   example, via its filename and also via its library name server catalogue
   number), then the browser needs to know the base address in order to
   correctly deduce external document addresses.
   

    The format of this tag is not yet specified.
   

Anchors

   The format of an anchor is as follows:
   


        <A NAME=xxx HREF=XXX> ... </A>

   The text between the opening tag and the closing tag is either the start or
   destination (or both) of a link. Attributes of the anchor tag are as
   follows.
   

  HREF                    If the HREF attribute is present, the anchor is
                         senstive text: the start of a link. If the reader
                         selects this text,  he should be presented with
                         another document whose network address is defined by
                         the value of the HREF attribute . The format of the
                         network address is specified elsewhere . This allows
                         for the form HREF=#identifier to refer to another
                         anchor in the same document. If the anchor is in
                         another document, the atribute is a relative name ,
                         relative to the documents address (or specified base
                         address if any).
                         

  NAME                    The attribute NAME allows the anchor to be the
                         destination of a link. The value of the parameter is
                         that part of a hypertext address which follows the
                         hash sign.
                         

  TYPE                    An attribute TYPE may give the relationship described
                         by the hyertext link. The type is expressed by a
                         string for extensibility.  Strings for types with
                         particular semantics will be registered by the W3
                         team. The default relationship if none other is given
                         is void.
                         

   All attributes are optional, although one of NAME and HREF is necessary for
   the anchor to be useful.
   

IsIndex

   This tag informs the reader that the document is an index document. As well
   as reading it, the reader may use a keyword search.
   

    Format:
   


        <ISINDEX>

   The node may be queried with a keyword search by suffixing the node address
   with a question mark, followed by a list of keywords separated by plus
   signs. See the network address format.
   

Plaintext

   This tag indicates that all following text is to be taken litterally, up to
   the end of the file.  Plain text is designed to be represented in the same
   way as example XMP text, with fixed width character and significant line
   breaks. Format:
   


                <PLAINTEXT>

   This tag allows the rest of a file to be read efficiently without parsing.
   Its presence is an optimisation. There is no closing tag.
   

Example sections

   These styles allow text of fixed-width characters to be embedded absolutely
   as is into the document. The format is:
   


        <LISTING>

                ...

        </LISTING>

   The text between these tags is to be portrayed in a fixed width font, so
   that any formatting done by character spacing on successive lines will be
   maintained. Between the opening and closing tags:
   

       The text may contain any ISO Latin printable characters, including the
          tag opener, so long as it does not contain the closing tag in full.
          

       Line boundaries are significant, and are to be interpreted as a move to
          the start of a new line.
          

       The ASCII Horizontal Tab (HT) character should be interpreted as the
          smallest positive nonzero number of spaces which will leave the
          number of characters so far on the line as a multiple of 8. Its use
          is not recommended however.
          

   The LISTING tag is portrayed so that at least 132 characters will fit on a
   line.  The XMP tag is portrayed in a font so that at least 80 characters
   will fit on a line but is otherwise identical to LISTING. The examples of
   markup are here given using the XMP tag.
   

Paragraph

   This tag indicates a new paragraph. The exact representation of this
   (indentation,  leading, etc) is not defined here, and may be a function of
   other tags, style sheets etc. The format is simply
   


        <P>

   (In SGML terms, paragraph elements are transmitted in minimised form).
   

Headings

   Several levels (at least six) of heading are supported. Note that a
   hypertext document tends to need less levels of  heading than a normal
   document whose only structure is given by the nesting of headings. H1 is the
   highest level of heading, and is recommened for the start of a hypertext
   node.   It is suggested that the first heading be one suitable for a reader
   who is already browsing in related information, in contrast to the title tag
   which should identify the node in a wider context.
   


        <H1>, <H2>, <H3>, <H4>, <H5>, <H6>

   These tags are kept as defined in the CERN SGML guide. Their definition is
   completely historical, deriving from the AAP tag set.  A difference is that
   HTML documents allow headings to be terminated by  closing tags:
   


        <H2>Second level heading</h2>

Highlighting

   The highlighted phrase tags may occur in normal text, and may be nested. For
   each opening tag there must follow a corresponding closing tag. NOT
   CURRENTLY USED.
   



        <HP1>...</HP1>   <HP2>... </HP2> etc.

Glossaries


   A glosary (or definition list) is a list of paragraphs each of which has a
   short title alongside it.  Apart from glossaries, this format is useful for
   presenting a set of named elements to the reader. The format is as follows:
   



        <DL>

        <DT>Term<DD>definition pagagraph

        <DT>Term2<DD>Definition of term2

        </DL>

Lists


   A list is a sequence of paragraphs, each of which is preceded by a special
   mark or sequence number. The format is:
   



        <UL>

        <LI> list element

        <LI> another list element ...

        </LI>

   The opening list tag (UL for an unordered list, OL for an ordered one) must
   be immediately followed by the first list element. The representation of the
   list is not defined here, but a bulleted list for unordered lists,  and a
   sequence of numbered paraghraphs for an ordered list would be quite
   appropriate.
   

    "OL" IS NOT CURRENTLY USED



From timbl  Fri Jan 24 16:07:49 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12579; Fri, 24 Jan 92 16:07:49 GMT+0100
Date: Fri, 24 Jan 92 16:07:49 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9201241507.AA12579@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-interest@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: WorldWideWeb news: New software includes Gopher, News, Telnet access


           World Wide Web:          WHAT'S NEW IN '92
                                       

   Here's the latest (that we know) about W3, the hypertext information
   system. The High-Energy Physics world got
   its first official announcement of W3 in the CERN computer newsletter
   released at Christmas, with an introductory article. However, there are
   already many users of W3 outside HEP!
   

New browser

   The new year starts with a release (version 1.1 - our first official
   "version1" release) of the line mode browser.  This has protocol code in for
   a wealth of new information, with:
   

       o  Direct access to internet news groups
          

       o  Direct access to " gopher " campus-wide information systems etc.
          (Gopher  is system similar to W3 but using a web of menus and
	  plain text files rather than hypertext.  It is all readable as
	  hypertext using W3)
          

       o  Browsing of remote directories using FTP. Before, files could be
          read - now you can browse around as well. Any FTP site becomes a W3
          information source.
          

       o  Links directly to telnet (and rlogin) sites.  This allows
          hypertexts to point to online communications facilities which don't
          have servers.
          

       o  Extensibility using gateways - you can configure www to use specific
          gateways for any access protocol which might turn up in the future
          which it can't handle directly.
          

   The user interface is slightly improved,  and  you can save a document to a
   file, pipe it, or print it (under unix).
   

   The browser version can be picked up by anonymous FTP in the usual way
   including source binaries for several platforms.
   

   Those who have built other hypertext systems (such as Hyperbole and Viola)
   on top of the www browser will immediately gain access to the all this newly
   accessible information.
   

W3 at SLAC

   Hot on the heels of the announcement of the W3 server for the "SPIRES"
   High-Energy Physics preprint database at the Stanford Linear ACcelerator lab
   comes news from Paul Kunz that the line mode browser is installed on all
   unix systems at SLAC. Happy browsing, folks.
   

Browsing on VM/CMS

   The IBM mainframe at CERN now has a copy of the w3 browser (v0.14) running
   in line mode. We are considering ways to make it more full-screen in the VM
   style.  The v1.1 browser is under test and may be installed by the time
   you get this. Other VM sites mail me for details.
   

Browsing under X with Viola

   A version of www running in the "Viola" hypertext system looks neat - I just
   saw it running on an apollo and on a decstation. We shall release it soon
   with the coming new version of viola.
   

Conferences

   The W3 demonstration had an enthusiastic reception at " HyperText'91 " in
   San Antonio, Texas.
   

   Jean-Francois Groff presented W3 live at the Software Engineering
   and AI for High-Energy Physics workshop in La Londe, France.  We've also
   been asked to demonstrate, as well as present a paper, at the Joint European
   Networking Conference (JENC3) in Innsbruck, Austria, in May.

As usual, details by telnetting info.cern.ch (no username or password),
then selecting the "WorldWideWeb" link, software by anonymous FTP
from node info.cern.ch.
__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web project                (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155







From timbl  Fri Jan 24 17:12:46 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12783; Fri, 24 Jan 92 17:12:46 GMT+0100
Date: Fri, 24 Jan 92 17:12:46 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9201241612.AA12783@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: wei@xcf.berkeley.edu (Pei Y. Wei)
Subject: Viola - WWW interface
Cc: www-talk@nxoc01.cern.ch

Pei,

ViolaWWW works great!  It has impressed us here. Its fine on decstation and apollo  
displays (The crashing HP display was an HP X server problem.)   A strange thing is  
that it seems to be so fast -- a search in the CERN phone book seems instantaneous
(when done at CERN).  Perhaps the line mode browser's critical path is the
time taken for the terminal emulator to display the characters, and Viola is  
faster.

We're going to have to standardize (have a competetion for) the WWW icon.
I like the web, though some may be arachnophobic. We use a globe on the NeXT.
I wondered about some combination of an open book and a globe...

The viola changes aren't in www v1.1, but are in the master code for 1.2
(or 1.1a) already.

Now for details about the marking of fields for viola:

>To answer your questions:
>
>> Do I correctly assume that anything which is displayed on the screen  

>> surrounded by SI..SO characters can be clicked on and will then be  

>> sent to www?
>
>That's correct, for the old version of Viola. This scheme, however, has
>changed in the new version... (see below).
>
> Here are two important things Viola need to interface to www. Both might
> be effected by -viola:
>
>1) A consistant and hopefully unique prompt ending. It should always look
>the same ("::: " or whatever is predictable).

    Are you sure it isn't safer to use a non-printable character? That would
    be guaranted unique.

> 2) Instead of the old (and limiting) SI..SO scheme, the new scheme is to use
> the \h()\e() combination thusly:
>
>	See also CERN copyright[\h(2)\e(2)].
>
> The text within \h(...) is displayed highlited, and text within \e(...) 

> is ``embedded'' into the text field for retrieval (when clicked) by Viola
> scripts.

To separate the anchor text (highlished bit) and the meaning is a good idea.
In that case we would highlight the whole phrase: in the underlying mark-up,
the beginning of the anchor is marked as well as the end, although that is not
apparent with the line-mode browser normally. Using your example, this would come  
out like

	See also \h(CERN copyright)\e(2).

without any [numbers] displayed at all.

Again, the use of printable brackets () is a bit dangerous, as in fact
there will be cases in which unmatche dbrackets appear within the highlighted bit.


-------------


> I'm very interested in producing a usable WWW front-end (the current
> ViolaWWW was a one-nite hack to prove feasibility). I am also thinking
> of incorporating the HHTP code into Viola. Thou I have to look at the 

> code more...
>

If you want to look at the code, see whether your text widget can implement the
"Object Building" methods in HText.h.  These are the calls made by the www
communications code and parsers to build the hypertext.  If you can provide those,
it should be easy.  You just call one of the routines in HTAccess.h to
load a document by name, and it calls you back to create and build the document.


>> More qustions:
>> Did you need any mods to viola, or is everything you needed put into  

>> the "ht" stack?  In other words, was the viola directory a stnadrd  

>> release which we can replace with new versions when they come out?
>
> No modification was made to Viola in order to front-end the modified
> www.

Great stuff.


> [...] No problem! Give me a few days, and I may have the new ViolaWWW ready. 

> It will have a lot of improvements such as multiple fonts and geometry
> management.

If you really do multiple fonts, that would be great!  In that case
you will probably want to combine the www access code with viola itself
in order to get the style changes as a hypertext document is parsed.
That would be really neat.  It would remove all this marking of fields with
funny characters, as well.

>>      Tim 

>   -Pei
  Tim


From dkrieger%monty@rand.org  Fri Jan 24 19:09:34 1992
Return-Path: <dkrieger%monty@rand.org>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13051; Fri, 24 Jan 92 19:09:34 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA19386; Fri, 24 Jan 92 19:03:37 +0100
Received: from monty.rand.org by rand.org; Fri, 24 Jan 92 09:48:06 -0800
Received: from thoreau by monty; Fri, 24 Jan 92 09:48:03 PST
Received: from localhost by thoreau (4.1/SMI-4.1)
	id AA12826; Fri, 24 Jan 92 09:48:02 PST
Message-Id: <9201241748.AA12826@thoreau>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: www-interest@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: WorldWideWeb news: New software includes Gopher, News, Telnet access 
In-Reply-To: Your message of Fri, 24 Jan 92 16:07:49 N.
             <9201241507.AA12579@ nxoc01.cern.ch > 
Date: Fri, 24 Jan 92 09:48:01 PST
From: David Krieger <dkrieger%monty@rand.org>

WHOEVER IS IN CHARGE OF THESE MAILING LISTS -- PLEASE REMOVE ME.
		dkrieger%monty@rand.org


From timbl  Tue Feb  4 08:44:25 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24645; Tue, 4 Feb 92 08:44:25 GMT+0100
Date: Tue, 4 Feb 92 08:44:25 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202040744.AA24645@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: emv@cic.net
Subject: Re: using WWW to follow gopher links 
Cc: www-talk@nxoc01.cern.ch, gopher@boombox.micro.umn.edu,
        wais-talk@quake.think.com

Ed,

All good stuff -- the world is coming together.

What do you think is the most useful www option for tracing what's out there?
I have two suggestions - one is a -list option (or something) which makes
www return only list of related documents, one on each line.
Another is one which will recursively run down a tree. The
trouble with the latter is telling it where to stop. Depth isn't really good enough
as probably you also want to constrain it to only gopher files, for example.
Perhaps the most flexible would be just the first option, with a perl etc script  
around ir to be flexible. I'd link to see for example lists of all telnet sites
references by gopher or www links, a wais server for www documents and gopher  
nodes.  My guess is that one index could handle the lot so long as one trimmed
off the few places where people have gatewayed in the entire ftp world, etc.
Then I'd like to see a www server for that index so that one could jump straight to  
the docoument wherever it came from.... I have to write an articel today, maybe
tomorrow I'll put in www -list.

KUTGW
	Tim

[PS: I assume you meant -p rather than -np in the www command. Perhaps we
should put in -np if it is more intuitive than -p for no paging.
I'll look at the CR problem.]

__________________original message follows
Tim,

Some more results of wais/www/gopher collaboration.

I have a new WAIS server running at wais.cic.net, called
"midwest-weather".  It's fed by loading in a bunch of weather reports
from a gopher at Minnesota every hour.  That system gets them from the
"weather underground" at Michigan using some hairy expect scripts, I
figured it'd be easier to get things out of gopher instead.

The script looks like:

WEATHER=gopher://mermaid.micro.umn.edu:150/00/Weather
www -n -np ${WEATHER}/Indiana/Fort%20Wayne | sed -e 's/.$//' > fort-wayne.in
www -n -np ${WEATHER}/Indiana/Indianapolis | sed -e 's/.$//' > indianapolis.in
www -n -np ${WEATHER}/Indiana/South%20Bend | sed -e 's/.$//' > south-bend.in
[...]

For some reason the gopher files are coming out of www with extra ^M's
on the end, as if they were DOS files; so the sed thing gets rid of them.

I don't see a way to do this with just one invocation of www, so
instead it runs once for each file.

Neither gopher nor WWW have the notion of a "recursive directory
listing", either some complete overview of the structure of the system
or some skeleton outline.  (I realize it's arbitrarily hard to do so
since any link could point off anywhere else.)  That makes it tougher
to do an archie-style catalog.  I think it wouldn't be that hard to
build a tree-walker for gopher that prints out a list of the
directories on every system that it can find and also the text of all
of the stuff that's in the ".about" directories.  At the very least
I'm doing some of that by hand now (just a script like the one above)
& waising it so I have some clue what all is out there.  *not* a 

replacement for the per-site indexes, but a cross-section.

--Ed


From jfg@bernd.cern.ch  Tue Feb  4 10:14:38 1992
Return-Path: <jfg@bernd.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24750; Tue, 4 Feb 92 10:14:38 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA08874; Tue, 4 Feb 92 10:08:04 +0100
Received: by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
          id AA12890; Tue, 4 Feb 92 10:07:25 -2300
Date: Tue, 4 Feb 92 10:07:25 -2300
From: jfg@bernd.cern.ch (Jean-Francois Groff)
Message-Id: <9202050907.AA12890@bernd.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from emv@cic.net

------- Start of forwarded message -------
Received: from cernvax.cern.ch by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
          id AA13075; Tue, 4 Feb 92 00:59:29 -2300
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA02837; Tue, 4 Feb 92 00:59:58 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA24681; Tue, 4 Feb 92 00:59:56 +0100
Received: from nic.cic.net by quake.think.com (4.1/SMI-4.0)
	id AA02414; Mon, 3 Feb 92 15:42:59 PST
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA09725; Mon, 3 Feb 92 18:41:34 EST
Message-Id: <9202032341.AA09725@nic.cic.net>
In-Reply-To: Your message of "Mon, 20 Jan 92 10:19:51 +0100."
             <9201200919.AA05201@ nxoc01.cern.ch > 
From: emv@cic.net
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: jfg@cernvax.cern.ch, gopher@boombox.micro.umn.edu,
        wais-talk@quake.think.com
Subject: Re: using WWW to follow gopher links 
Date: Mon, 03 Feb 92 18:41:32 -0500

Tim,

Some more results of wais/www/gopher collaboration.

I have a new WAIS server running at wais.cic.net, called
"midwest-weather".  It's fed by loading in a bunch of weather reports
from a gopher at Minnesota every hour.  That system gets them from the
"weather underground" at Michigan using some hairy expect scripts, I
figured it'd be easier to get things out of gopher instead.

The script looks like:

WEATHER=gopher://mermaid.micro.umn.edu:150/00/Weather
www -n -np ${WEATHER}/Indiana/Fort%20Wayne | sed -e 's/.$//' > fort-wayne.in
www -n -np ${WEATHER}/Indiana/Indianapolis | sed -e 's/.$//' > indianapolis.in
www -n -np ${WEATHER}/Indiana/South%20Bend | sed -e 's/.$//' > south-bend.in
[...]

For some reason the gopher files are coming out of www with extra ^M's
on the end, as if they were DOS files; so the sed thing gets rid of them.

I don't see a way to do this with just one invocation of www, so
instead it runs once for each file.

Neither gopher nor WWW have the notion of a "recursive directory
listing", either some complete overview of the structure of the system
or some skeleton outline.  (I realize it's arbitrarily hard to do so
since any link could point off anywhere else.)  That makes it tougher
to do an archie-style catalog.  I think it wouldn't be that hard to
build a tree-walker for gopher that prints out a list of the
directories on every system that it can find and also the text of all
of the stuff that's in the ".about" directories.  At the very least
I'm doing some of that by hand now (just a script like the one above)
& waising it so I have some clue what all is out there.  *not* a 
replacement for the per-site indexes, but a cross-section.

- --Ed



------- End of forwarded message -------

From ojala@dolphin.funet.fi  Tue Feb  4 20:29:53 1992
Return-Path: <ojala@dolphin.funet.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25924; Tue, 4 Feb 92 20:29:53 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA02208; Tue, 4 Feb 92 20:23:20 +0100
Received: by dolphin.funet.fi id AA12182
  (5.65c/IDA-1.4.3 for www-talk@nxoc01.cern.ch); Tue, 4 Feb 1992 21:23:28 +0200
Date: Tue, 4 Feb 1992 21:23:28 +0200
Message-Id: <199202041923.AA12182@dolphin.funet.fi>
From: Petri Ojala <ojala@funet.fi>
Sender: ojala@dolphin.funet.fi
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9202040744.AA24645@ nxoc01.cern.ch >
Subject: Re: using WWW to follow gopher links 


I would prefer the latter suggestion plus some additions.  For example in
X environment it would be nice to be able to get a overview of the
"hypertext network" around the current location.  A sort of scan to the
next level following all the links at the current document.  (Maybe
with possibility see more than one level with the client keeping book
of not following one document more than once.)

The other feature would be fully recursive list of documents (or
references).  However this list would not follow all the links but
only those marked to be followed in the anchor specification.  As this
is quite dangerous feature it should be avoided but still possible
for example in Gopher-environments.  Of course the client could in
any case keep book of the documents shown and not follow same page
more than once.

Petri

From timbl  Fri Feb  7 16:40:18 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00647; Fri, 7 Feb 92 16:40:18 GMT+0100
Date: Fri, 7 Feb 92 16:40:18 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202071540.AA00647@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-talk@nxoc01.cern.ch
Subject: W3 server at NIKHEF;  Scripst as w3 servers


From W.vanLeeuwen@nikhef.nl (Willem van Leeuwen):

I installed the server on our recently installed network sun (nic.nikhef.nl).
With a very crude change in HTRetrieve it is possible to activate
a script in case of a keyword search:

/*		Handle a Retrieve request from a WWW client	HTRetrieve.c
...
extern int HTWriteASCII(int soc, char * s);	/* In HTDaemon.c */

	char *command;
	char string[80];
	char *ip;

/*		Read a file
...
    if (keywords) {
/*
	if (TRACE) fprintf(logfile,"HTHandle: can't perform search %s\n",
		arg);
	HTWriteASCII(soc,
	    "Sorry, this server does not perform searches.\n");
*/
	ip = string;
	command = "/user/a03/bin/WWWsh ";
	for (;*command!='\0';) *ip++ = *command++;
	for (;*arg!='\0';) *ip++ = *arg++;
	*ip++ = '?';
	for (;*keywords!='\0';) *ip++ = *keywords++;
	system (string);
	return fd;
    }
    

    StrAllocCopy(arg2, arg);
...

With the following script the finger information is sent to the client:

	name=`echo $@ | awk -F? '{print $2}`
	echo '<plaintext>'
	/usr/ucb/finger $name@nikhefh

This script only serves to demonstrate that this solution works.

Our default file is //nic.nikhef.nl./user/a03/www/default/default.html
but we are still experimenting so it is too early to hook nikhef into WWW.
I'll let you know when we have more useful information.

Best regards,
Willem van Leeuwen


From timbl  Fri Feb  7 17:58:24 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00861; Fri, 7 Feb 92 17:58:24 GMT+0100
Date: Fri, 7 Feb 92 17:58:24 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202071658.AA00861@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: emv@cic.net
Subject: Re: gopher can read www links right now!
Cc: www-talk



Begin forwarded message:

To: timbl@nxoc01.cern.ch
Subject: gopher can read www links right now!
Date: Fri, 07 Feb 92 09:15:54 -0500
From: emv@cic.net

> ho ho ho!  take a look at this:
> 

> www gopher://info.cern.ch:2784//GET%20/hypertext/WWW/FileFormat.html
> 

> accidental compatibility...

Ha!  There's a man who knows what's going on.... of course the slash just before
the GET is interpreted as a gopher type character which happens to be
invalid, so www just reads the document as plain text. With versiuon 1.1c or later  
(no, it's not released yet but I will if you want it), an "h" field means "html  
format". So I can say:(spot of the difference)

www gopher://info.cern.ch:2784/hGET%20/hypertext/WWW/FileFormat.html

File format

   The system uses marked-up text to represent a hypertext document when one is
   being stored in a file or transmitted over the network. Some of the formats
   available are illustrated in a test hypertext[1]. The hypertext mark-up
   language is an SGML format. This means basically that it uses angle brackets
   to delimit language constructs embedded within the text. The particular
   language 1 the set of tags and the rules about their use, and their
   significance 1 is not part of the SGML standard. There being no standard on
   this, we have adopted a set which seems sensible. Let's call them HTML --
   hypertext markup language. HTML is not an alternative to SGML, it is a
   particular format within the SGML rules (an SGML "DTD"). We have included in
   HTML  tags from the SGML tagset used at and once supported at CERN by  quite
   a lot of documentation and SGML examples.[2] The HTML parser will ignore
   tags which it does not understand, and will ignore attributes which it does
   not understand of CERN-SGML tags.
     [End]


Basically, Gopher addresses and w3 addresses are fairly interconvertable. And you  
are right, http and gopher protocols are very similar.  [The "w" field can only be  
used in a gopher menu. It means "The selector string is in fact a w3 address, don't  
expect a port number or host address to follow it".]

From timbl  Mon Feb 17 17:32:58 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18163; Mon, 17 Feb 92 17:32:58 GMT+0100
Date: Mon, 17 Feb 92 17:32:58 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202171632.AA18163@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Eelco van Asperen <evas@cs.few.eur.nl>
Subject: Re: WWW LineMode browser
Cc: www-talk

> From: Eelco van Asperen <evas@cs.few.eur.nl>
>
> I've been working on a curses-version of the line mode browser
> and I think the code works reasonably well. The modifications
> I made to v1.1 have now been incorporated into v1.2. Most
> changes are in the form of #ifdef CURSES ... #endif.
> I've also added lots of checks where malloc ea. are used to
> make sure that they return a non-NULL pointer.

Great to have a curses full-screen browser!  Something we has always throught ought  
to be done, but hadn't had the time.  Send me the patches, and I'll insert them  
into our current code and into the next release.

> Unfortunately, the PC version keeps crashing lately; I'm not sure
> if the problem is the PC-NFS toolkit or the browser code.
> The program hangs when one of the PC-NFS toolkit routines tries 

> to free a memory block; this could be caused by a corrupted memory
> chain. This in turn can be caused by freeing some pointer that
> was not malloc'ed.  The code runs ok under Unix even when I add
> the malloc-debugging library.

Sounds like a PC-sepcific bug there... but you never know. We have found something  
weird with realloc() under aix but that looks like an aix bug.

> Some other points;
> - a lot of files (especially *.html and *.txt files) don't end
>   with a linefeed; the SCCS source code control system does not
>  like this. Perhaps this can be fixed in future releases ?

I think this may be Edit on the NeXT which is happy to leave an uncompleted line on  
the end of a file.  I'll have to look at it.

> - could you make context diffs from the last to the current
>  release ? This would make it easier to see what has changed
>  and merge those changes with the ones I've made to my copy
>  of the last release.

Assuming your patches are useful -- which they certainly have been up till now,  
we'll incorporate them into the release.

> So, if you are interested in my patches, please let me now and I'll
> send them.

	yes please!


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155








From timbl  Tue Feb 18 11:30:44 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19728; Tue, 18 Feb 92 11:30:44 GMT+0100
Date: Tue, 18 Feb 92 11:30:44 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202181030.AA19728@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: "Timo Harmo - SocSci U of Helsinki" <HARMO@valt.helsinki.fi>
Subject: W3 and other systems
Cc: www-talk@nxoc01.cern.ch

> From: "Timo Harmo - SocSci U of Helsinki"  <HARMO@valt.helsinki.fi>

>> In the end, there will be hypertext, certainly.
> Yes, I agree (I hate hierarchical information systems). But meanwhile
> gopher (wais I don't know about) offers working systems for many
> platforms, doesn't it?
>
> Let's continue on the list.

Ok, a discussion of the proliferation of protocols is a thing suitable for the
list.  Timo had been saying - why not broadcast about W3 on the WAIS and Gopher
lists/groups? Well, every now and again I mention it, but I do not want to misuse
the groups.

Yes, gopher offers working systems for many platforms.  The gopher protocol
is VERY like the basic HTTP protocol.  We feel that the W3 model is more general.
Its very easy to write gopher and w3 servers, but more difficult to write w3  
browsers. The trouble is, it takes longer to write a hypertext browser because the  
hypertext widgets won't exist. The gopher people are doing really good work by  
getting information out there.  This gives everyone experience. We run the w3 web  
with the gopher web as a subset. This gives a lot of data. It means w3-based search  
engines and indexers can include gopher data.

The disappointing thing of course is that a lot of information is better presented
as hypertext. If you like, a gopher menu page is ulrra-simple hypertext. Real  
hypertext, with the little formatting you get in HTML, is more powerful, and leads  
to better communication between the information provider and the reader. And  
communication is what we are talking about.

Actually, the HTTP protocol is not te most important thing for people to use. There  
will always be many S&R protcols. The W3 addressing syntax is much more important.

>> - Timo
	- Tim


From timbl  Tue Feb 18 14:25:04 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19967; Tue, 18 Feb 92 14:25:04 GMT+0100
Date: Tue, 18 Feb 92 14:25:04 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202181325.AA19967@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: kean@talon.ucs.orst.edu
Subject: Re: archie wais server - WWW access directly to files
Cc: wais-talk@think.com, www-talk@nxoc01.cern.ch


> If there's no improvement to the disk space used by these I'll announce the
> server to the world Wednesday morning in alt.wais and the archie-people mailing
> list.

Magic -- I really like it.  I have modified the WAIS-WWW gateway so that is the  
database is an archie one (i.e.database name contains "archie" :-| ) a W3 search of  
the database will give links directly to the files.  This relies on the headline  
starting with host:/filename.

For the first test I ran www, followed a pointer to your archie server, looked for
"html" to find any hypertext files out there. At the bottom of the list is a file  
of Ed Vielmetti's "archie.html" in Toronto.  Jumped over there.. it has a pointer  
to the comp.archives newgroup ... jumped into the newsgroup... jumped into an  
article...  This is how things SHOULD work!

Now the things which need neatening up. The gateway I was using is here in CERN,  
and the server is at ordst.edu. This implies a transatlantic link for every search.

- Would you or anyone like to run the gateway locally? Volunteers?

- Perhaps we should run the WAIS archie here, mirroring files.

- One of us could run a direct W3 archie server rather than using a gateway
     process.

To use www as an archie client,

	setenv  WWW_wais_GATE  http://info.cern.ch:8001/

(or point to a more local gateway!) and 


	alias archie  www wais://archive.orst.edu:9000/archie-orst.edu

I've put a pointer to the archie index in our CERN home page, but not publicised it  
yet.

Tim BL

From brewster@quake.think.com  Tue Feb 18 15:05:19 1992
Return-Path: <brewster@quake.think.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20087; Tue, 18 Feb 92 15:05:19 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA20506; Tue, 18 Feb 92 14:59:37 +0100
Received: by quake.think.com (4.1/SMI-4.0)
	id AA28643; Tue, 18 Feb 92 05:58:16 PST
Date: Tue, 18 Feb 92 05:58:16 PST
Message-Id: <9202181358.AA28643@quake.think.com>
From: Brewster Kahle <brewster@think.com>
Sender: brewster@quake.think.com
To: timbl@nxoc01.cern.ch
Cc: kean@talon.ucs.orst.edu, wais-talk@think.com, www-talk@nxoc01.cern.ch
In-Reply-To: Tim Berners-Lee's message of Tue, 18 Feb 92 14:25:04 GMT+0100 <9202181325.AA19967@ nxoc01.cern.ch >
Subject: archie wais server - WWW access directly to files

   Date: Tue, 18 Feb 92 14:25:04 GMT+0100
   From: timbl@nxoc01.cern.ch (Tim Berners-Lee)

   ...
   Magic -- I really like it.  I have modified the WAIS-WWW gateway so that is the  
   database is an archie one (i.e.database name contains "archie" :-| ) a W3 search of  
   the database will give links directly to the files.  This relies on the headline  
   starting with host:/filename.

I wish we used /filename@hostname so that waisretrieve could handle it (and
be compatible with the WAIS doc-id.

   Now the things which need neatening up. The gateway I was using is here in CERN,  
   and the server is at ordst.edu. This implies a transatlantic link for every search.

   - Would you or anyone like to run the gateway locally? Volunteers?
WAIS packets are small, but the distance makes reduces reliability.

   - Perhaps we should run the WAIS archie here, mirroring files.

   - One of us could run a direct W3 archie server rather than using a gateway
	process.

   To use www as an archie client,

	   setenv  WWW_wais_GATE  http://info.cern.ch:8001/

   (or point to a more local gateway!) and 


	   alias archie  www wais://archive.orst.edu:9000/archie-orst.edu

   I've put a pointer to the archie index in our CERN home page, but not publicised it  
   yet.

   Tim BL

This is really cool.

-brewster


From timbl  Tue Feb 18 16:44:35 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20333; Tue, 18 Feb 92 16:44:35 GMT+0100
Date: Tue, 18 Feb 92 16:44:35 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202181544.AA20333@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Brewster Kahle <brewster@think.com>
Subject: Documet ids (was Archie, WWW access directly to files, and document ids
Cc: jcurran@nnsc.nsf.net, kean@talon.ucs.orst.edu, wais-talk@think.com,
        www-talk@nxoc01.cern.ch

From: Brewster Kahle <brewster@think.com>

   Date: Tue, 18 Feb 92 14:25:04 GMT+0100
   From: timbl@nxoc01.cern.ch (Tim Berners-Lee)

Tim:
  ... This relies on the headline [of an archie index] 

	starting with host:/filename.

Brewster:

  I wish we used /filename@hostname so that waisretrieve could handle it (and
  be compatible with the WAIS doc-id.

Tim:

Well, Brester, I wish that we used //hostname/filename so that it would be
directly compatible with the W3 doc-id ;-). In fact, of course, the user never ses  
the doc-ids themselves as he browses.

But seriously, Brewster, you suggested to John Curran <jcurran@nnsc.nsf.net> that,  
on the subject of document ids, "[Brewster's] proposal that is on the table is  
worth implementing for a good run".  I would suggest that John look at w3 Universla  
Document Identifiers as a similar but more open and more established scheme.  W3  
has been running now for 18 months or so using the UDI syntax and the addressing  
syntax has expanded easily to include wais and now gopher. The www retrieval engine  
will handle any of these, FTP access and news access etc.

When x500 document naming becomes practical, it will be important that the UDI  
scheme can expand to accept x500 names.

There is nothing proprietory or w3-specific about w3 UDIs.  They are generic,  
caonnonical and univeral. Could I strongly suggest that you extend waisretrieve to  
use UDIs?

[Your objection to the w3 UDIs was that you prefered "@" to "//" because you wanted  
to use parsers written for mail.  Is that is a strong enough reason for inventing a  
new, wais-specific scheme instead of using an existing, open one?  Actually, the w3  
scheme uses @ for  //user@hostname/ when a username is needed, which is even more  
mail-like. The choice of punctuation is of course fairly arbitrary.]

The universal document identifier syntax is dead simple. It is described in BNF in  
/pub/www/doc/udi.txt.  Comments from all parties who haven't seen it before are  
solicited.

We must to put systems together to make the information universe happen, and not  
quarrel about trivia. We must remain open to the future.

I must put down the reasons for UDIs in a paper, but they're probably obvious to  
everyone on these lists....

	Tim

From kean@argh.ucs.orst.edu  Tue Feb 18 19:30:51 1992
Return-Path: <kean@argh.ucs.orst.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20651; Tue, 18 Feb 92 19:30:51 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA20672; Tue, 18 Feb 92 19:25:11 +0100
Received: from argh.UCS.ORST.EDU by mcsun.EU.net with SMTP;
	id AA14104 (5.65a/CWI-2.143); Tue, 18 Feb 1992 19:24:40 +0100
Received: from localhost.ucs.orst.edu by argh.UCS.ORST.EDU (4.1/SMI-DDN)
	id AA28008; Tue, 18 Feb 92 10:21:46 PST
Message-Id: <9202181821.AA28008@argh.UCS.ORST.EDU>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: kean@talon.ucs.orst.edu, wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: Re: archie wais server - WWW access directly to files 
In-Reply-To: Your message of Tue, 18 Feb 92 14:25:04 +0100.
			 <9202181325.AA19967@ nxoc01.cern.ch > 
Date: Tue, 18 Feb 92 10:21:42 PST
From: kean@argh.ucs.orst.edu

We've a T1 to the T3 backbone, so mirroring the archie stuff I have isn't 
a problem (from my end).

I'll provide the scripts and the glue etc to do the mirroring and indexing to
whoever wants to do it.  

**** I'd really like to see a few more waised archie servers out there ****
Why?  Well, mostly mercenary self-interest (archive.orst.edu is the campus 
news server too) + redundancy.  Takes 600 Mb to do it properly (if you have
400Mb main memory you could get away with 450 Mb disk space 8) ).

Kean

Kean Stump (503)-737-4740                 Why choose the *lesser* of
two evils?
OSSHE Network Operations                  Vote for Cthulu, '92
DOMAIN: kean@ucs.orst.edu                 UUCP: hplabs!hp-pcd!orstcs!kean

From kean@argh.ucs.orst.edu  Tue Feb 18 19:32:02 1992
Return-Path: <kean@argh.ucs.orst.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20657; Tue, 18 Feb 92 19:32:02 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA20691; Tue, 18 Feb 92 19:26:23 +0100
Received: from argh.UCS.ORST.EDU by mcsun.EU.net with SMTP;
	id AA14194 (5.65a/CWI-2.143); Tue, 18 Feb 1992 19:25:52 +0100
Received: from localhost.ucs.orst.edu by argh.UCS.ORST.EDU (4.1/SMI-DDN)
	id AA28016; Tue, 18 Feb 92 10:23:03 PST
Message-Id: <9202181823.AA28016@argh.UCS.ORST.EDU>
To: Brewster Kahle <brewster@think.com>
Cc: timbl@nxoc01.cern.ch, kean@talon.ucs.orst.edu, wais-talk@think.com,
        www-talk@nxoc01.cern.ch
Subject: Re: archie wais server - WWW access directly to files 
In-Reply-To: Your message of Tue, 18 Feb 92 05:58:16 -0800.
			 <9202181358.AA28643@quake.think.com> 
Date: Tue, 18 Feb 92 10:23:02 PST
From: kean@argh.ucs.orst.edu

I'm going to reformat the database to the /filename@hostname convention on 
the next mirror run I do.  I haven't forgotten 8)

Kean 

Kean Stump (503)-737-4740                 Why choose the *lesser* of
two evils?
OSSHE Network Operations                  Vote for Cthulu, '92
DOMAIN: kean@ucs.orst.edu                 UUCP: hplabs!hp-pcd!orstcs!kean

From emv@heifetz.msen.com  Wed Feb 19 05:48:30 1992
Return-Path: <emv@heifetz.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21309; Wed, 19 Feb 92 05:48:30 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA19551; Wed, 19 Feb 92 05:42:51 +0100
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lGj60-000HxNC@heifetz.msen.com>; Tue, 18 Feb 92 23:39 EST
Message-Id: <m0lGj60-000HxNC@heifetz.msen.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: Brewster Kahle <brewster@think.com>, jcurran@nnsc.nsf.net,
        kean@talon.ucs.orst.edu, wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: Re: Documet ids (was Archie, WWW access directly to files, and document ids 
In-Reply-To: Your message of Tue, 18 Feb 92 16:44:35 +0100.
             <9202181544.AA20333@ nxoc01.cern.ch > 
Date: Tue, 18 Feb 92 23:39:44 -0500
From: Edward Vielmetti <emv@msen.com>

Throughout the years people have used different ways to 
describe files available for anonymous ftp.  that has never
been standardized ever.  no reason to believe it ever will
be.

If we are going to come up with a special kind of document
that refers to a new document type that has the semantics
of "pointer to file available for anonymous ftp", then it
should be assigned a WAIS type tag, described, and specified.
I'd suggest the tag AFTP.  Someone write a spec, we'll all
write code, & be done with it.  (There's plenty of data after
all.)  It would be better to do that rather than to use a TEXT
type tag and bicker about the format.

I don't think it would be hard for the WWW gateway to WAIS to
do special things to documents if they had a different type,
and then use that to convert AFTP type documents to WWW format.
Ditto gopher, archie, etc. clients.

If it's TEXT, on the other hand, it can be *anything*.  Please
don't overload the semantics of the name of the server or the 
accidental formatting of the contents of the document.  I would
like to create AFTP records to stick into many servers.

--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120
     "Things are glued together with spit and bailing wire now."

From emv@heifetz.msen.com  Wed Feb 19 05:49:40 1992
Return-Path: <emv@heifetz.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21315; Wed, 19 Feb 92 05:49:40 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA19574; Wed, 19 Feb 92 05:44:01 +0100
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lGj7D-000HxNC@heifetz.msen.com>; Tue, 18 Feb 92 23:41 EST
Message-Id: <m0lGj7D-000HxNC@heifetz.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: bug in HTAccess.c confused me - WWW_wais_GATEWAY
Date: Tue, 18 Feb 92 23:41:05 -0500
From: Edward Vielmetti <emv@msen.com>

the error message refers to WWW_wais_gateway, but the code
wants WWW_wais_GATEWAY.  either way is fine by me so long
as you're consistent...

--Ed

From timbl  Wed Feb 19 10:41:35 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21668; Wed, 19 Feb 92 10:41:35 GMT+0100
Date: Wed, 19 Feb 92 10:41:35 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202190941.AA21668@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: Documet ids (was Archie, WWW access directly to files)
Cc: Brewster Kahle <brewster@think.com>, jcurran@nnsc.nsf.net,
        kean@talon.ucs.orst.edu, wais-talk@think.com, www-talk@nxoc01.cern.ch



Date: Tue, 18 Feb 92 23:39:44 -0500
From: Edward Vielmetti <emv@msen.com>

> Throughout the years people have used different ways to 

> describe files available for anonymous ftp.  that has never
> been standardized ever.  no reason to believe it ever will
> be.
	Is there a similey for a big sigh?...

> If we are going to come up with a special kind of document
> that refers to a new document type that has the semantics
> of "pointer to file available for anonymous ftp", then it
> should be assigned a WAIS type tag, described, and specified.
> I'd suggest the tag AFTP.  Someone write a spec, we'll all
> write code, & be done with it.  (There's plenty of data after
> all.)  It would be better to do that rather than to use a TEXT
> type tag and bicker about the format.

This Archie-wais-www has to get around the fact that the doc-id in  
the search response is not the doc-id of the file, it's the id of a  
line in the site listing which refers to the file.  However, one  
wants to jump straight to the file, rather than to the site listing.  
For this reason, the gateway throws away the wais doc-id and  
generates an id for the file itself from the headline. If the doc-id  
itself was that of the file (in any format), that would be cleaner of  
course, as the headline could be in any human readable format. [Would  
that be easy, Kean?]

> I don't think it would be hard for the WWW gateway to WAIS to
> do special things to documents if they had a different type,
> and then use that to convert AFTP type documents to WWW format.
> Ditto gopher, archie, etc. clients.

It would be possible, sure. Do we want to have to access an AFTP type  
document just to get a pointer to an FTP site? This takes time, I'd  
prefer top skip that step.

> If it's TEXT, on the other hand, it can be *anything*.  Please
> don't overload the semantics of the name of the server or the 

> accidental formatting of the contents of the document.  I would
> like to create AFTP records to stick into many servers.

I agree that overloading the database name is horrible! Its a hack to  
show what is possible. You can only do it cleanly if you has  
universal document ids of some form or other.

Sure, clients and gateways can convert UDI formats -- avoids the  
bickering but not as cool as having a common format. (Need that  
smiley again!)

[BTW, If you're going to have an AFTP file format for pointing to  
aftp sites, will you also need a GOPH file format for pointing to  
gopher sites, and a NEWS file format for pointing to newsgroups...?   
Suppose you do have some universal id scheme. Then you could have one  
format for a file of pointers. Using the SES filter system, indexing  
that file could (if it looked like a README for example) retrieve the  
referenced document and index the actual document rather than just  
the name.]

	Tim


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155






From timbl  Fri Feb 21 10:52:53 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28042; Fri, 21 Feb 92 10:52:53 GMT+0100
Date: Fri, 21 Feb 92 10:52:53 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202210952.AA28042@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: brennan@hal.com (Dave Brennan)
Subject: Making an http gateway
Cc: www-talk@nxoc01.cern.ch

Dave,

> In our network environment there is only one machine that has  
direct access
> to the Internet for security reasons.  Is there a way to run the  
client on
> some other system in our net and have it use the "gateway" machine?   
I am
> very interested in learning more about the WWW and similar  
projects.  It's
> kind of annoying that the setup here makes this difficult.
>
> Thanks,
>
> Dave Brennan

That's a very good question, as lots of companies have this  
restriction.
Fortunately, the browser is set up so that you can
pass requests (according to protocol in the document id) to a  
gateway.  You can on the client node setenv WWW_http_GATEWAY and  
WWW_wais_GATEWAY etc to point gateway addresses. At that address you  
need to set up a server to access the remote whateveritis and send  
the results back as hypertext.

	HTTP gateway:

I've just tried this and it seems to work fine. You use the www  
client as a server. On your gateway machine,

1. Put a new service (htgate, 8002 say) into /etc/services or  
whatever you use instead.

2. Set up inetd.conf to run /usr/local/bin/htgate when a tcp  
connection to htgate comes in. You have to kill -HUP the inetd  
process to get it to take the change into account.

3. Use this htgate script which reads the command line and then calls  
www with its second parameter and sends the source to the caller:

#! /bin/sh
read get docid
/usr/local/bin/www -source -n -na -p "$docid"

That will handle anything where the source is HTML.  It won't handle  
internet news, gopher, etc.  (For that we need an option on the  
browser -html which generates HTML
from news, etc, which we haven't done yet -- but you're not the first  
to ask)

I suggest you run the wais gateway separately, but you could change  
the shell script to check the protocol on the doc-id and run www or  
WAISGate as appropriate. That means you set separately on the client

	setenv WWW_http_GATEWAY http://gate.hal.com:8002/
	setenv WWW_wais_GATEWAY http://gate.hal.com:8001/

For the wais gateway, you get the sources from info.cern.ch  
/pub/www/stcWWWDaemon_v.vv.tar.Z and compile it. The documentation is
http://info.cern.ch/hypertext/WWW/Daemon/User/Guide.html and linked  
documents.

I hope this solves the problem and opens up the web for the  
organsiation.  If you need the option for news or gopher, we'll have  
to put the -html option in. Let me (and the list) know how you get  
on...

	Tim

From timbl  Mon Feb 24 17:21:19 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02717; Mon, 24 Feb 92 17:21:19 GMT+0100
Date: Mon, 24 Feb 92 17:21:19 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202241621.AA02717@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)
Subject: Re: www @ nikhef
Cc: www-talk@nxoc01.cern.ch

Willem,

Great to see the NIKHEF server on the web!  For others on the list,
see Willem's message below for examples of how to put together
www servers, including indexes, out of simple shell scripts.

I have put links to NIKHEF from our home page, and from the subject and  
organisation index.

There is one little bug in Xfind: the reference to //nic/ rather than //nic.nl./  
will work for those in the Netherlands but not for the rest of us.
(By the way, xfind is the name of a program by Bernd Pollermann which runs on VM  
... he might feel that the name is his.)

This is a neat server, particularly as it uses existing unix tools and data to  
provide a useful service.... keep up the good work!

	Tim BL

______________________________________________________________________
Date: Thu, 20 Feb 92 14:58:11 +0100
From: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)
Organisation: Nikhef-H (National Institute for Nuclear and High-Energy Physics)
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 5920411, +31 2995 2499 (home)
Telex: 10262 hef nl
Telefax: +31 20 5925155
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Subject: Re: www @ nikhef
Cc: a03@nikhef.nl

Hi,

There is a very preliminary version of xfind working on a very stupid set
of helpfiles.
These helpfiles are input to a VAX like help, so browsing with www
does not give very useful information, I only want to show that
the principle works.

If you want to try you may link NIKHEF into WWW with

	http://nic.nikhef.nl./user/a03/www/default/NikhefGuide.html

I now have 2 files which can be searched with keywords: the telephone
directory and this set of helpfiles.

The http daemon calls the script WWWsh:

WWWsh
=====

name=`echo $@ | awk -F? '{print $1}`
keys=`echo $@ | awk -F? '{print $2}`
name=`basename $name .html`
/user/a03/bin/$name.sh $keys

which may call Phone.sh or Xfind.sh

Phone.sh
========

name=$1
echo "<title> $name at NIKHEF</title>"
echo "<h1> $name</h1>"
grep -i $name /user/a03/www/default/phone.html

phone.html is a file which is generated every night from the finger
information on our central server.

Xfind.sh
========

name=$1
echo "<title> $name at XFIND </title>"
echo "<h1> $name</h1>"
#
# Do not forget to put 

#	pass	/user/a03/www/xfind/*
# in httpd.conf
#
cd /user/a03/www/xfind
files=`echo $name | /usr/lib/refer/hunt -Fn -Ty Index`
echo $files | sed -e "s/\///g" | awk '{for (i=1;i<=NF;i++) printf("<a  
href=http://nic/user/a03/www/xfind/%s>%s</a><p>",$i,$i)}'

The helpfiles are in a different directory, which has to be mentioned
in httpd.conf.

The index is made with the command

	/usr/lib/refer/mkey -w -f files | /usr/lib/refer/inv

files contains the names of the files to be indexed.
This is a rather crude approach, since the index contains a lot of keywords,
but again the first aim was to get something working.

I'll try to write down wy experiences with www in a more coherent way,
until then I hope this information is of some help.

Regards, Willem


From timbl  Tue Feb 25 15:44:49 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04800; Tue, 25 Feb 92 15:44:49 GMT+0100
Date: Tue, 25 Feb 92 15:44:49 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202251444.AA04800@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)
Subject: Browser append to file, and SPIRES server
Cc: www-talk@nxoc01.cern.ch, pfkeb@slacvm.slac.stanford.edu



> Date: Tue, 25 Feb 92 13:40:05 +0100
> From: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)


> Some remarks about the new browser:
> 

> The use of >> to add text of a document to an existing file should  
be
> documented in the help:
>
>  > file          Save the text of this document in a file.
>  >>file          Add the text of this document to a file.
>

	Good point -- In fact I hadn't noticed that it works by
	virtue of the same code which makes ">" work!
	It's in the help for the next version.

> When browsing the SPIRES database one has to type find twice:
> the first is interpreted by the browser, the second by SPIRES.
> (The old browser used K, which could be omitted).

	Yes - This should be fixed at the server end.

> SPIRES does not give always the promised number of references.
> Try f find author holthuizen, there should be 111 references, only
> 104 are shown.

	This too.  The last one's a bit odd, as the limit seems to 

	vary. Perhaps its in lines. Another thing is taht the lines
	trainling spaces to 80 characters which makes them wrap aound
	a 79-character terminal. They could be stripped in the server
	EXEC too.

>Willem
	-Tim


From timbl  Tue Feb 25 15:52:17 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04826; Tue, 25 Feb 92 15:52:17 GMT+0100
Date: Tue, 25 Feb 92 15:52:17 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202251452.AA04826@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
Subject: Re: Size limits for text files? 
Cc: emv@cic.net, JONZY@cc.utah.edu, gopher-news@boombox.micro.umn.edu,
        www-talk@nxoc01.cern.ch

> Another thing clients should do (but don't yet) is to cache  
information.
> That is, the client ought to keep the previous list of gopher items  
in memory 

> so you don't have to fetch it again. Of course, there should also  
be a timer...

As happens, the www client caches information. The number of  
documents (text files or menus) cached is currently 2, defined by  
LOADED_LIMIT in GridText.c. We'll increase it next release, as 5  
seems more useful.  There's no timer, but it its a good idea.

	Tim BL

From emv@cic.net  Tue Feb 25 18:25:12 1992
Return-Path: <emv@cic.net>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05367; Tue, 25 Feb 92 18:25:12 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA01587; Tue, 25 Feb 92 18:19:45 +0100
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA15081; Tue, 25 Feb 92 12:19:14 EST
Message-Id: <9202251719.AA15081@nic.cic.net>
To: timbl@nxoc01.cern.ch
Cc: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>, JONZY@cc.utah.edu,
        gopher-news@boombox.micro.umn.edu, www-talk@nxoc01.cern.ch
Subject: Re: Size limits for text files? 
In-Reply-To: Your message of "Tue, 25 Feb 92 15:52:17 +0100."
             <9202251452.AA04826@ nxoc01.cern.ch > 
Date: Tue, 25 Feb 92 12:19:12 -0500
From: emv@cic.net

> WWW caches texts

hmmm.  If you were running a WWW "http" gateway, I suppose you
could do a big pile of caching - rather than have every individual
user go out to the world to fetch documents individually, they
would go to your relay server which might well have the things
they were interested in already.

Such things have also been proposed for FTP servers, I guess I
would add -- you'd connect to a local caching FTP server, from
which you could 'cd' to other anonymous FTP sites; if the local
cache didn't have what you wanted it'd go off to the real place
to get it.

Fortunately gopher and WWW both seem more amenable to 
hacking^H^H^H^H^H^H^H research in this regard than the
usual FTP demon.

w/r/t size - like I say I don't want to have hard coded limits
for things, but people doing design need to keep in mind that
if a menu pick results in a megabyte worth of text being thrown
at my client I'm not going to be happy about it...

--Ed

From timbl  Thu Feb 27 17:22:44 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09065; Thu, 27 Feb 92 17:22:44 GMT+0100
Date: Thu, 27 Feb 92 17:22:44 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9202271622.AA09065@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: chi-arch@uccvms.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
        iafa@cc.mcgill.ca
Subject: Draft: Universal Document Identifiers
Cc: Rare WG3 <rare-wg3@surfnet.nl>, nisi@merit.edu


An information universe on the [Inter]net requires a cannonical form  
for the name or address of a document.  Building on much previous  
network discussion, a draft discussion paper

	Universal Document Identifiers on the Network

 is now availableby anonymous FTp from node info.cern.ch as
	/pub/www/doc/udi1.ps   (or if desperate .txt)

or, to use its UDI, file://info.cern.ch/pub/www/doc/udi1.ps.
This describes an addressing scheme encompassing many objects on the  
network including archived files, news articles and groups, gopher
things, wais indexes, queries, and documents.

Comments are solicited.

A shorter paper on the requirements a universal hypertext system
such as WWW imposes on WAIS and x.500 protocols is
file://info.cern.ch/pub/www/doc/wais_x500_www.ps (or .txt)
is intended as input to the IETF wais/x500 BOF in March
(which I might be able to go to)

	Tim

__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155






From bcn@isi.edu  Thu Feb 27 19:59:31 1992
Return-Path: <bcn@isi.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09473; Thu, 27 Feb 92 19:59:31 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA10546; Thu, 27 Feb 92 19:54:05 +0100
Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-3)
	id <AA02373>; Thu, 27 Feb 1992 10:55:15 -0800
Date: Thu, 27 Feb 92 10:52:44 PST
Posted-Date: Thu, 27 Feb 92 10:52:44 PST
Message-Id: <9202271852.AA05956@tgo.isi.edu>
Received: by tgo.isi.edu (4.1/4.0.3-4)
	id <AA05956>; Thu, 27 Feb 92 10:52:44 PST
From: bcn@isi.edu (Clifford Neuman)
Sender: bcn@isi.edu
To: timbl@nxoc01.cern.ch
Cc: chi-arch@uccvms.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
        iafa@cc.mcgill.ca, rare-wg3@surfnet.nl, nisi@merit.edu
In-Reply-To: Tim Berners-Lee's message of Thu, 27 Feb 92 17:22:44 GMT+0100 <9202271622.AA09065@ nxoc01.cern.ch >
Subject: Draft: Universal Document Identifiers

I have glanced through your document on universal directory
identifiers, and you seem to have left out Prospero.

Prospero is a little different in that it does late binding of the
access method.  In particular, a Prospero link consists of two parts,
a host name, and a name of the object on that host.  The latter part
is usually a path name, but in reality, it can be any string,
including simply a unique ID.  Thus, a Prospero link might look like

TGO.ISI.EDU /a/b/c  or   GUM.ISI.EDU 27

A Prospero link has a few other fields as well, but perhaps less
important.  There is a type field for the hostname.  It indicates
whether the hostname is an Internet name or address, or perhaps some
other kind of name or address.  Only one type is presently supported
(INTERNET-D) though, and that type includes Internet host names or
addresses, with or without an optional Internet UDP port.

  examples: TGO.ISI.EDU, TGO.ISI.EDU(191), 128.9.224.123, or 128.9.224.123(191)

Only a single type is used for all four types of Internet addresses
since they are not syntactically ambiguous.

The name relative to the host is also typed.  Presently, the only type
supported is ASCII, but the type field is there just in case.

Three other fields are a version number, a unique ID, and a type.  The
meaning of the version number should be fairly obvious.  A version
number of 0 matches the most recent version.  At present, most objects
don't have version numbers, but I felt it was important to include in
in the link data.  The purpose of the unique ID is less obvious.  It
is there to provide a mechanism for detecting when an object has been
deleted and replaced with an object of the same name.  In some cases,
it might be important to note that the object being retrieved is not
the same as the one to which the original link was made.  I will talk
about the type field later since it is not what you might think.

So, that is a Prospero link.  Note, that it does not specify the
access method.  Binding to an access method is accomplished by sending
a message to the Prospero server at the address in the link, and
requesting the access method for the named object.  The response
includes a sequence of tokens, the first identifies the access method,
and the remainder identify the information specific to the access
method (beyond that which already is part of the link).  If you
understand the access method, then you also know how to interpret the
remaining tokens.

For example, a response indicating access by anonymous FTP might be

  ANONYMOUS-FTP /pub/pfs/guest/README BINARY

Note that the host name is not specified since the hostname from the
link is assumed.  If the host name were different than that in the
link, then it would be specified in the response.  The path is
specified, however, because the path to be passed to the FTP program
is different than that in the link (in this case, the link included
the prefix /homes/june/ftp.

Similar responses are supported for other methods, and a response
might include more than one access method, in which case the
application choose the method that best suits its needs.

Now, back to the type field.  One of the shortcomings of the approach
as described so far is that it requires a Prospero server to run on
the system storing the object to be referenced.  This shortcoming is
addressed by the external link.  The type field in a Prospero link
provides information on what can be done with the link.  The three
common types are FILE, DIRECTORY, and EXTERNAL.  The links described
above were of type FILE.  If a links type is directory, its contents
can be listed by contacting the Prospero server (i.e. the links in the
directory can be returned).  If a links type is EXTERNAL, it means
that the object should be accessed without contacting a Prospero
server to obtain the access method (usually because a Prospero server
is not running on the target site).  Instead, the access information
that would otherwise have been returned is encoded as part of the
type.  Thus for example the type of an external link to the file
mentioned above would be.

  EXTERNAL(AFTP,BINARY)

Note that for external links using the AFTP or FTP method, the name
field of the link contains the path name to be passed to FTP.  For
other access methods, the meaning of the field is defined by the
particular access method to be used.

Anyway, I hope this adequate explains the form of Prospero
identifiers, and I hope that you can fit it in to your proposed
format. 

	~ Cliff





From timbl  Mon Mar  2 12:36:33 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14036; Mon, 2 Mar 92 12:36:33 GMT+0100
Date: Mon, 2 Mar 92 12:36:33 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203021136.AA14036@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: bcn@isi.edu (Clifford Neuman)
Subject: Re: Draft: Universal Document Identifiers
Cc: cni-arch@uccvma.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
        iafa@cc.mcgill.ca

Cliff,

Thanks for your input, with explanations of addressing in Prospero.

Prospero should certainly go into the document. Indeed, it seems to  
fit in very well.   The small differences raise some interesting  
questions -- reactions off the top of my head follow, in the sequence  
of you messsage.

	Tim
  _______________________________________________

> Date: Thu, 27 Feb 92 10:52:44 PST
> From: bcn@isi.edu (Clifford Neuman)
> 

> I have glanced through your document on universal directory
> identifiers, and you seem to have left out Prospero.

Omission was from ignorance of the details you provide here and will  
certainly be corrected. Prospero is very relevant.

> In particular, a Prospero link consists of two
> parts, a host name, and a name of the object on that host.  The
> latter part is usually a path name, but in reality, it can be any 

> string, including simply a unique ID.  Thus, a Prospero link might 

> look like
>
> TGO.ISI.EDU /a/b/c  or   GUM.ISI.EDU 27

The UDI syntax //TGO.ISI.EDU/a/b/c or //GUM.ISI.EDU/27 matches that  
very well.  I suggest the prefix "prospero:" for prospero addresses.

> A Prospero link has a few other fields as well, but perhaps less
> important.  There is a type field for the hostname.  It indicates
> whether the hostname is an Internet name or address, or perhaps  
some
> other kind of name or address.  Only one type is presently  
supported
> (INTERNET-D) though, and that type includes Internet host names or
addresses, with or without an optional Internet UDP port.
>
>  examples: TGO.ISI.EDU, TGO.ISI.EDU(191), 128.9.224.123, or  
128.9.224.123(191)

The UDI scheme foresees these possibilities. These would map onto
//TGO.ISI.EDU/, //TGO.ISI.EDU:191/, //128.9.224.123/ and  
/128.9.224.123:191/ respectively. The whole UDI of the file above  
would be (if quoted out of the "prospero:" context),

	prospero://TGO.ISI.EDU:191/a/b/c


We, also, wondered about how to extend the system when other  
underlying protcols are used with the same higher-level protocol.  
Suppose for example later one adds dial-up prospero. Should one write

	prospero://dialup:+12025672654:200/a/b/c

or 	prospero-dialup:/+12025672654:200/a/b/c ?

My feeling is that the number of underlying network layers which have  
complete world-wide coverage will remain low. Furthermore, one can  
even imagine gateways there, so that those without X25 acces, say,  
can go throuh some transport level gateway from TCP/IP if the need  
arises. This suggests putting other low-level addresses into the  
"host/port" field, encoded in some fashion. One would hope that there  
will be less forms of transport service access point address than  
there will be application layer protocols.

> The name relative to the host is also typed.  Presently, the only  
type
> supported is ASCII, but the type field is there just in case.

The rule we have used is to put type information, if part of the  
link, into the path.  protocols differ upon whether they regard it as  
part of the link or it is returned when you try to retrieve the data.
In the latter case (which I prefer) it should not be in the UDI at  
all.

> Three other fields are a version number, a unique ID, and a type.  


The version number should I suggest be part of the path. Its  
significance will tend to vary between servers. The trouble is, as  
you say, noone has really put up a system dealing with multiple  
versions. We imagined having hidden links from a document to its  
previous, next and latest versions, and to a table of versions.

>The purpose of the unique ID is ... to provide a mechanism for  
detecting when an object has been
> deleted and replaced with an object of the same name.  In some  
cases,
> it might be important to note that the object being retrieved is  
not
> the same as the one to which the original link was made.

This is non-obvious.  My feeling is that a unique id is a useful  
thing, which I would regard as "header" information, ie information  
you can ask the server for.  Putting it into the link I'm not so sure  
about.  Suppose, for example, the retrieval goes through several  
stages of pointers, being referenced by serveral servers. Do you want  
to check that the final document, or the first link, was really the  
same as the one you made the original link to?

> Binding to an access method is accomplished by sending
> a message to the Prospero server at the address in the link, and
> requesting the access method for the named object.  The response
> includes a sequence of tokens, the first identifies the access  
method,
> and the remainder identify the information specific to the access
> method (beyond that which already is part of the link).  If you
> understand the access method, then you also know how to interpret  
the
> remaining tokens.

That "late binding" is just the sort of "name-server" function which  
I was talking about, and which for example x500 might also fit into.
So long as both the input and the output to the process are UDIs,  
it's very flexible.

> For example, a response indicating access by anonymous FTP might be
> 

>  ANONYMOUS-FTP /pub/pfs/guest/README BINARY

We'd write that now as file:/(samehost)/pub/pfs/guest/README.  
Currently, if the access protocol has to be specified, then the host  
does too. It could default ot the host of the context of the UDI even  
when protcol fields are different.

The "binary" flag is an interesting one and a perennial question.  My  
assumption was that if you know how to handle a file when you've got  
it, then you must know how to transfer it.  In practice with FTP both  
mean that you have to have a table of file suffixes.

> Similar responses are supported for other methods, and a response
> might include more than one access method, in which case the
> application choose the method that best suits its needs.

Sounds fine.

> Now, back to the type field.  One of the shortcomings of the  
approach
> as described so far is that it requires a Prospero server to run on
> the system storing the object to be referenced.  This shortcoming  
is
> addressed by the external link.  The type field in a Prospero link
> provides information on what can be done with the link.  The three
> common types are FILE, DIRECTORY, and EXTERNAL.  The links  
described
> above were of type FILE.  If a links type is directory, its  
contents
> can be listed by contacting the Prospero server (i.e. the links in  
the
> directory can be returned).  If a links type is EXTERNAL, it means
> that the object should be accessed without contacting a Prospero
> server to obtain the access method (usually because a Prospero  
server
> is not running on the target site).  Instead, the access  
information
> that would otherwise have been returned is encoded as part of the
> type.  Thus for example the type of an external link to the file
mentioned above would be.

  EXTERNAL(AFTP,BINARY)

Your "EXTERNAL" type is a pointer to a document in another naming  
scheme which neat, and expandable -- I like it.  The UDI syntax was  
basically invented to allow one to to that, so that all these systems  
can work together. Basically, type EXTERNAL(xxx) maps onto putting an  
xxx: prefix on the UDI. In your example, it maps to giving a file:  
reference.

You have, for prospero, the flag in the link as to whether the object  
is a directory or a file.  So does the Gopher.  This is useful for  
displaying different icons, etc. for the user.  A snag is that if we  
include anonymous FTP file systems, the NLIST command doesn't tell  
you that information, so it doesn't map.  You have to try to retrieve  
it and if that fails, cd to it.  If the flag is considered useful,  
then we could use the converntion (of ls-F) that a/c/b/ is a  
directory and a/b/c is a file. The trouble is, that you can't get  
that information from an FTP server without assuming unix to parse a  
long listing.

Do I _have_ to know in advance whether a Prospero item is a directory  
or a file?

> Note that for external links using the AFTP or FTP method, the name
> field of the link contains the path name to be passed to FTP.  For
> other access methods, the meaning of the field is defined by the
> particular access method to be used.

Yup - the UDI assumptions exactly.

> Anyway, I hope this adequate explains the form of Prospero
> identifiers, and I hope that you can fit it in to your proposed
> format. 

>
>	~ Cliff

Thanks for a very clear explanation.  It soudds as though Prospero  
will fit very well into the format.  I'll put it into the next draft  
of the document.

	- Tim





From timbl  Wed Mar  4 10:42:32 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17545; Wed, 4 Mar 92 10:42:32 GMT+0100
Date: Wed, 4 Mar 92 10:42:32 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203040942.AA17545@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: jcurran@nnsc.nsf.net
Subject: Re: Draft: Universal Document Identifiers
Cc: cni-arch@uccvma.bitnet@nnsc.nsf.net, wais-talk@think.com,
        www-talk@nxoc01.cern.ch

> Date: Thu, 27 Feb 92 19:45:42 -0500
> From: jcurran@nnsc.nsf.net

>Even if the exact scheme is not used, the requirement
> discussion contained in the paper is quite valuable.
> I have a few comments:
> 

>] Terms
>]
>] The objects on the network which are to be named include
>] objects which can be retrieved, and objects which can be searched.

> Using this definition, one would infer that document identifiers
> would allow reference to a distinct file, a particular mail
> message, news article, etc. I would not anticipate that a document
> identifier would be used to identify a newsgroup, interactive
> service, archive directory , or a wais source.  Are  we trying to
> define a universal id or a universal document id?  Might it be
> better to defer the definition of non-document resources and then
> come back and make the document specific id's be a subset of a
> future general resource identifier?

You are right that the UDIs were inteneded to be able to refer to any  
of those things. (In the W3 world, they all look pretty similar  
anyway -- they are all represented as [hyper]text objects.)  It is  
largely in order to be able to make references to any of those things  
that we need a UDI rather than a WAIS-DI and a W3-DI and a news-DI  
etc etc.  A UDI allows references between systems, and expandability  
for the future.  My answer would be that we are trying to define a  
universal document id, but where "document" has the very wide  
interpretation as any data which can be retrieved, viewed or  
searched: anything to which you might want to make a reference.
For example, a person is not a document (although to have a document  
on the net representing each person might be useful... their  
signature/disclaimer with links to their published works, etc etc.)  
If we can't cope with the objects which are on the net now, how can  
we hope to cope with the wierd things to come .. video clips from the  
news last night etc...


] Relevance
] 

] The life of a name is limited by any information contained within  
it which 

] may become prematurely invalid. It is therefore necessary to limit  
the 

] contents of a name to the information required for the operations  
above. 

] Other extraneous information about the document (its size, data  
format, 

] authorization details, etc) may in general change with time and  
should 

] not be part of the name.

> The proposed document identifiers have many characteristics which 

> may change with time: storage location, access protocol, format, 

> etc. If we focus instead on the "information content" of a \
> document, then it might be possible to form identifiers that are
>  more robust.  Many people consider:
>
> file://info.cern.ch./pub/www/doc/udi1.ps      and 

> file://info.cern.ch./pub/www/doc/udi1.txt
>
> to be the same document; just in different formats.

Precisely. We look forward to the day when a name like

	x500:/CH/CERN/CN/TBL/TechNote-15

will be put through a name server which will return a set of  
addresses. In the mean time, we don't have that ubiquitous name  
server (directory) facility. So we have to make do with physical  
addresses. And different versions of the same document look like  
different documents. Its a shame. The plan is that UDIs can migrate  
from physical addresses to registered names.



> It would be nice to be able to recognize this
> and allow  the user (and user interface) to determine which
> instance should be used for retreival.

Yes. Absolutely.  (The neatest way is for the client to send a set of  
preferences over with the request, and for the server to decide which  
to format to send. This is a suggestion for an evolved wais and/or  
http protoccol.) Another way if for the client to ask a name server  
for addresses, and retrieve the headers of each one to find out which  
representation he'd prefer -- But I'd prefer all the represenattions  
of the document to have the same name right down to the retrieval  
protocol level.

> This recognition may only
> be perform if the document id's (now being used document content
> ids) contain only location and format independant data.  It is easy
> to imagine that uniqueness could be assured by combining
> an organization, author, and title:
>
>
> cern.ch:www-staff:udi1 

>
> ietf:osids:archdirectory-00 


There are two functions: One, to find out whethre two documents are  
the same. Two, to derive a (set of) addresses for retrieval of the  
document. To be able to do the first, any unique id (like OSF/DCE  
UUIDs or RFCxxxx message ids) will work. To be able to do the second,  
a directory service is needed.

> Note that the actual location of the information might be far
> removed from the point of creation, and the format might be
> changed:
>
>cern.ch:www-staff:udi1;file://ftp.uu.net/doc/univeral-docids.PS.Z
>cern.ch:www-staff:udi1;news:<1992Feb21.121919.1@quake.think.com>
>cern.ch:www-staff:udi1;wais://nnsc.nsf.net/info-retrieval-notes?udi1

I see the usefulness of quoting both the unique identifier and the  
physical address. I hope that in the future, though, one will only  
need the first part "cern.ch:www-staff:udi1". That, fed into the  
directory service, will produce a list of addresses.

You can, of course, still quote both: "You need document  
x500:/cern.ch/www-staff/udi1 which I found on  
file://ftp.uu.net/doc/univeral-docids.PS.Z".

I would also suggest that if a document has a unique registered name  
then it should certainly contain that name, so that if you find it  
some otherway, you can refer to it (make links to it) by its official  
name.

> That's all
> /John

Good points -- thanks for the input...I think more needs to go in  
about registered unique names in the document.

	Tim BL



From timbl  Thu Mar  5 15:25:08 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20144; Thu, 5 Mar 92 15:25:08 GMT+0100
Date: Thu, 5 Mar 92 15:25:08 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203051425.AA20144@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: ses@cmns.think.com, peterd@expresso.cc.mcgill.ca (Peter Deutsch)
Subject: Re: Draft: Universal Document Identifiers
Cc: iafa-request@kona.cc.mcgill.ca, cni-arch@uccvma.bitnet,
        www-talk@nxoc01.cern.ch, wais-talk@think.com, iafa@cc.mcgill.ca,
        rare-wg3@surfnet.nl, nisi@merit.edu

[Admin: If anyone is missing documents from this discussion which I  
have, they are all in a mailbox  
file://info.cern.ch/pub/www/doc/udi/discussion.mbox. Some of the  
messages were sent to only some of the lists.  Also, I mis-spelled  
the name of cni-arch.uccvma in my original posting, so some replies  
have not gone there. I will not repost them.  The orginal udi paper  
is slightly updated now. Same UDI -- no versioning ;-)]

Now, about these USDNs:

> Date: Thu, 5 Mar 92 07:32:50 EST
> From: ses@cmns.think.com

There have been several messages now with a common theme: That what I  
called in the udi1 paper a "lasting registered name" is better than  
an "address".

Peter Deutsch argues the point at length in  
<9203042206.AA12411@expresso.cc.mcgill.ca>, using the term USDN by  
analogy with ISBN.

John Curran on <Thu, 27 Feb 92 19:45:42 -0500> argues the same, and  
also suggests quoting both registered name and address (which I  
wasn't so sure about in case they get out of sync).

I completely agree with Peter and Simon's point of view, and I have  
modified the paper to put more emphasis on this. What I obvioulsy  
didn't make clear enough is my feeling that:-

1.There may be more than one USDN scheme, just as there are many  
physical addres schemes.

2. There may be more than two stages: it is  an oversimplifiaction to  
talk of only a USDN and an address: For example, an ISO standard may  
dereference (or as Ed says, "swizzle") to a document produced by the  
IETF which may dereference down to a prospero name which may be a  
pointer to an FTP file.

3. We can't use USDNs now because they aren't there. We need a  
transision strategy.

Therefore, UDis were supposed to be able to hold _either_ a USDN _or_  
a physical address. They weren't intended to get involved with the  
discussion of which USDN/ISBN/ISSN/ISDN (?!) scheme is better. So, I  
say, by all means define an USDN scheme, then register it as a  
possible UDI. If is good and everybody uses it, everything will end  
up with a USDN, and the context will always be USDN documents, so the  
usdn: prefix (or whatever) will not in practice be used. I'm all for  
the market deciding between protocols.

Simon:

> I'm strongly in favour of the two stage lookup process; X.500 is  
obvious
> technology, although it is rather heavyweight for personal  
computers. An 

> alternative might be some sort of DNS/archie-like service. These  
could return
> Tim's UDIs, which could then deliver the good themselves.

I would say "a server takes x500 UDIs and returns physical UDIs which  
deleiver the goods themselves.", meaning the same thing.  (I would  
allow it the option of delivering a set of addresses, not just one.)  
Yes, x500 is heavyweight so one can have a lighter protocol which  
accesses a real x500 engine via a gateway with a large cache.

> Of course, invdidual information sources should still use local  
document 

> numbers where possible, but should provide a way of mapping from  
local-id
> to universal-id when needed.

Yes.

> One little question: What should be done about document versions?
> Obviously, different versions of a document should have different
> UDSNs, but should there be a simple way to compare USDNs modulo
> versions? 


Good point.  What about versions which split?  A great spin-off of  
having versions available is that you can refer to a line number in  
them. A line number in a document which is not frozen is useless.  
[This solves a recurring problem in hypertext systems, when one wants  
to link to part of a document to which one has no write access, and  
which may change].

> Here are some suggestions.. Eat hot ASN, Cultural Cringer.
> [...]

We must be careful not to reinvent the wheel: if the USDN problem is  
the same as the phone book problem (which it seems to be) then we  
should pick up on x500.

An important thing about x.500 is that it was designed to scale (I  
hope!).  By contrast as Ed says:

| Date: Wed, 04 Mar 92 23:52:05 -0500
| From: Edward Vielmetti <emv@msen.com>
| [...]
| ISBN is hierarchical so you can stamp out your own
| unique ID's; ISSN (international standard serial number) has
| a central cataloging authority.

and i doubt whether either of those will scale to allow document  
publishing on the net by every kindergarten child etc etc twice a  
minute. That's why I assume x500 is best in theory at least. But tell  
me I'm wrong.

Ed also mentions message-ids which are after all unique. The trouble  
is, there's no way of looking up where to find them.

	Tim

__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155






From ses@cmns.think.com  Thu Mar  5 16:15:18 1992
Return-Path: <ses@cmns.think.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20281; Thu, 5 Mar 92 16:15:18 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA02722; Thu, 5 Mar 92 16:10:07 +0100
Received: by Cmns.Think.COM (5.57/Ultrix2.4-C)
	id AA13491; Thu, 5 Mar 92 10:09:58 EST
Date: Thu, 5 Mar 92 10:09:58 EST
From: ses@cmns.think.com (Simon Edward Spero)
Message-Id: <9203051509.AA13491@Cmns.Think.COM>
To: timbl@nxoc01.cern.ch
Cc: peterd@expresso.cc.mcgill.ca, iafa-request@kona.cc.mcgill.ca,
        cni-arch@uccvma.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
        iafa@cc.mcgill.ca, rare-wg3@surfnet.nl, nisi@merit.edu
In-Reply-To: Tim Berners-Lee's message of Thu, 5 Mar 92 15:25:08 GMT+0100 <9203051425.AA20144@ nxoc01.cern.ch >
Subject: Draft: Universal Document Identifiers


   usdn: prefix (or whatever) will not in practice be used. I'm all for  
   the market deciding between protocols.

"That's the nice think about standards- there are so many of them to choose
 from" :-) Universal is as Universal does...

   Simon:

   I would say "a server takes x500 UDIs and returns physical UDIs which  
   deleiver the goods themselves.", meaning the same thing.  (I would  
   allow it the option of delivering a set of addresses, not just one.)  
   Yes, x500 is heavyweight so one can have a lighter protocol which  
   accesses a real x500 engine via a gateway with a large cache.

I think we're getting on to the really big problem I've seen in every
single Doc-ID discussion: every body seems to use the same words to
mean different things. To me, there's no such thing as a physical UDI.
There can be a reference to a physical copy of a document named by a
UDI, but that doesn't seem to be what you mean. confusing everybody
else. Anybody want to offer up an 'official' notation?


   Good point.  What about versions which split?  A great spin-off of  
   having versions available is that you can refer to a line number in  
   them. A line number in a document which is not frozen is useless.  
   [This solves a recurring problem in hypertext systems, when one wants  
   to link to part of a document to which one has no write access, and  
   which may change].

   > Here are some suggestions.. Eat hot ASN, Cultural Cringer.
   > [...]

   We must be careful not to reinvent the wheel: if the USDN problem is  
   the same as the phone book problem (which it seems to be) then we  
   should pick up on x500.

Just a couple of tyres...there should be no problem using those PDUs
with X.500 (Steve?). 


   and i doubt whether either of those will scale to allow document  
   publishing on the net by every kindergarten child etc etc twice a  
   minute. That's why I assume x500 is best in theory at least. But tell  
   me I'm wrong.

Distinguished names are ok, but I'd still rather have an OID associated
with each naming authority (maybe in the future, everybody will be 
issued with an OID at birth! What's your clearance, citizen?)

Simon

From timbl  Wed Mar 11 12:07:28 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28084; Wed, 11 Mar 92 12:07:28 GMT+0100
Date: Wed, 11 Mar 92 12:07:28 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203111107.AA28084@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: Draft: Universal Document Identifiers
Cc: peterd@expresso.cc.mcgill.ca, cni-arch@uccvma.bitnet,
        www-talk@nxoc01.cern.ch, wais-talk@think.com, iafa@cc.mcgill.ca


>> Peter Deutsch's message  <9203051920.AA14978@expresso.cc.mcgill.ca>
>> Actually, Mike Schwartz has suggested using CRC checksums,

> From: Larry Masinter <masinter@parc.xerox.com>
> You can do better than that by either:
> a) use a good digital signature (MD5 or Snefru or ...). [...]
> b) rely on something else that's unique, e.g., hostid + timestamp, ISO
> DFR's DORs, Object Identifiers, etc. 


> We've been using 256-bit UDSNs and are happy with the scheme. I'm
> hoping we'll have a writeup together before next week.

Peter, USDN is your term, so you decide what is and isn't one.

However, a UDI I define to be something you can use to get the object. You can't  
use digital signatures, or mail-style message-ids for that. You need some hints in  
the identifier as to where to start looking. (We're talking scalable distributed  
system here, no central hash tables allowed.) Knowing when you have a document that  
you have the right document is a different problem, but with a good name space  
(like x500) you can do both operations.

Tim

From peterd@expresso.cc.mcgill.ca  Wed Mar 11 19:04:39 1992
Return-Path: <peterd@expresso.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28995; Wed, 11 Mar 92 19:04:39 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA05278; Wed, 11 Mar 92 18:59:29 +0100
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA00781  (mail destined for timbl@nxoc01.cern.ch) on Wed, 11 Mar 92 12:45:46 -0500
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA02532; Wed, 11 Mar 92 12:45:32 EST
Message-Id: <9203111745.AA02532@expresso.cc.mcgill.ca>
In-Reply-To: Tim Berners-Lee's message as of Mar 11, 12:07
From: peterd@expresso.cc.mcgill.ca (Peter Deutsch)
Date: Wed, 11 Mar 92 17:45:31 GMT-0:02
In-Reply-To: Tim Berners-Lee's message as of Mar 11, 12:07
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Tim Berners-Lee <timbl@nxoc01.cern.ch>,
        Larry Masinter <masinter@parc.xerox.com>
Subject: Re: Draft: Universal Document Identifiers
Cc: cni-arch@uccvma.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
        iafa@cc.mcgill.ca

> From timbl@nxoc01.cern.ch Wed Mar 11 06:03:54 1992
> >> Peter Deutsch's message  <9203051920.AA14978@expresso.cc.mcgill.ca>
> >> Actually, Mike Schwartz has suggested using CRC checksums,
> 
> > From: Larry Masinter <masinter@parc.xerox.com>
> > You can do better than that by either:
> > a) use a good digital signature (MD5 or Snefru or ...). [...]
> > b) rely on something else that's unique, e.g., hostid + timestamp, ISO
> > DFR's DORs, Object Identifiers, etc. 
> 
> > We've been using 256-bit UDSNs and are happy with the scheme. I'm
> > hoping we'll have a writeup together before next week.
> 
> Peter, USDN is your term, so you decide what is and isn't one.

I want a UDSN to be something that lets me identify the
contents of a file and compare the contents of multiple
files to test for uniqueness. In the long run I'd also
like them to permit me to identify contents across
multiple encodings, but that's harder and I'm prepared to
wait for that.

I wouldn't be so bold as to try and decide what makes a
suitable UDSN but I hope that we can discuss the issue at
IETF next week (since we will have so many of the players
there) and arrive at some sort of consensus.

I can say what _I_ want them for, and hope that this is
something that would be useful to enough other people that
we can agree to deploy something soon. Certainly there are
a number of candidates, and Larry has named some of the
most likely. I think something that can be applied
retroactively (MD5?) would be preferable to something like
hostID and timestamp, which would be hard to retrofit to
the existing archive collections.

> However, a UDI I define to be something you can use to get the object. .  .
> .  .  . Knowing when you have a document that  
> you have the right document is a different problem, but with a
> good name space (like x500) you can do both operations.

I'm principally interested in UDSNs at this point to allow
comparisions between multiple items (perhaps found in disparate
environments). I don't see how the X.500 name space can
help me here (unless I'm misunderstanding what you mean?).
Certainly it seems that UDIs should help locate items.
That seems to be their raison d'etre.


				- peterd

-- 

From masinter@parc.xerox.com  Wed Mar 11 19:22:44 1992
Return-Path: <masinter@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29032; Wed, 11 Mar 92 19:22:44 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA06015; Wed, 11 Mar 92 19:17:45 +0100
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <13949>; Wed, 11 Mar 1992 10:15:39 PST
Received: by poplar.parc.xerox.com id <101795>; Wed, 11 Mar 1992 10:15:28 -0800
To: timbl@nxoc01.cern.ch
Cc: peterd@expresso.cc.mcgill.ca, cni-arch@uccvma.bitnet,
        www-talk@nxoc01.cern.ch, wais-talk@think.com, iafa@cc.mcgill.ca
In-Reply-To: Tim Berners-Lee's message of Wed, 11 Mar 1992 04:07:28 -0800 <9203111107.AA28084@nxoc01.cern.ch>
Subject: Re: Draft: Universal Document Identifiers
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <92Mar11.101528pst.101795@poplar.parc.xerox.com>
Date: 	Wed, 11 Mar 1992 10:15:21 PST

Um, I think when I tell you about a document, I can tell you:
a)Some attributes about it that you can remember and use for
  finding it again.
b)its signature/fingerprint/checksum whatever
  This helps you know whether you already have exactly what I'm
  referring to or can get it more locally.
c)some information about where I think you can get it and how
d)a set of instructions you can use for getting it.

So I have a book here. a) It is called "Programming Perl", by Larry
Wall and Randal L. Schwartz. b) it is ISBN 0-937175-64-1. c) it is
part of the O'Reilly & Associatiates series of Unix books, try a
technical library d) If it were available for FTP, it would be in
//ora.com/nuts/books/perl/1991-edition.

The last two are a little strained in the analogy; don't jump on the
analogy, please, I just want to point out that it is reasonable and
customary to supply *MORE THAN ONE* of unique identifier, serial
number, access path, common attributes, etc.








From peterd@expresso.cc.mcgill.ca  Wed Mar 11 19:49:19 1992
Return-Path: <peterd@expresso.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29109; Wed, 11 Mar 92 19:49:19 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA07104; Wed, 11 Mar 92 19:44:15 +0100
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA01153  (mail destined for timbl@nxoc01.cern.ch) on Wed, 11 Mar 92 13:28:55 -0500
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA02675; Wed, 11 Mar 92 13:28:40 EST
Message-Id: <9203111828.AA02675@expresso.cc.mcgill.ca>
In-Reply-To: Larry Masinter's message as of Mar 11, 10:15
From: peterd@expresso.cc.mcgill.ca (Peter Deutsch)
Date: Wed, 11 Mar 92 18:28:36 GMT-0:02
In-Reply-To: Larry Masinter's message as of Mar 11, 10:15
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Larry Masinter <masinter@parc.xerox.com>, timbl@nxoc01.cern.ch
Subject: Re: Draft: Universal Document Identifiers
Cc: cni-arch@uccvma.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
        iafa@cc.mcgill.ca

> From masinter@parc.xerox.com Wed Mar 11 13:18:12 1992
.  . .
> Um, I think when I tell you about a document, I can tell you:
> a)Some attributes about it that you can remember and use for
>   finding it again.
> b)its signature/fingerprint/checksum whatever
>   This helps you know whether you already have exactly what I'm
>   referring to or can get it more locally.
> c)some information about where I think you can get it and how
> d)a set of instructions you can use for getting it.
.  .  .
[* analogy deleted *]
> The last two are a little strained in the analogy; don't jump on the
> analogy, please, I just want to point out that it is reasonable and
> customary to supply *MORE THAN ONE* of unique identifier, serial
> number, access path, common attributes, etc.

I have no trouble with this. Obviously, I'm not sure I
need all of these for each query, since I'm trying to
accomplish different things at different times so what I
want back will change but that's just detail.

I suspect that only a) and b) are really permanently
associated with the information and the other two may or
may not be provided by external services. Of course, if
someone's favorite information delivery service wanted to
provide all four, (either directly or through gateways)
that's fine by me.


				- peterd

-- 

From emv@cic.net  Sat Mar 21 23:59:30 1992
Return-Path: <emv@cic.net>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16035; Sat, 21 Mar 92 23:59:30 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA10793; Sat, 21 Mar 92 23:54:52 +0100
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA01687; Sat, 21 Mar 92 17:54:20 EST
Message-Id: <9203212254.AA01687@nic.cic.net>
To: www-talk@nxoc01.cern.ch
Subject: problem yacc'ing violaWWW
Date: Sat, 21 Mar 92 17:54:19 -0500
From: emv@cic.net

these errors making gram.y:

cc -g -I/usr/X11/include  -I/usr/X11/include/Xaw  -I/usr/X11/include/X11  -I/usr/X11/in
clude/X11/Xmu  -I/usr/X11/include/X11/Xaw  -I/usr/X11/include/Xmu  -Iwww/LineMode/Imple
mentation  -Iwww/Implementation  -target sun4 -c  gram.c
gram.y: 860: syntax error (in preprocessor if)
/usr/lib/yaccpar: 119: syntax error (in preprocessor if)
/usr/lib/yaccpar: 179: syntax error (in preprocessor if)
/usr/lib/yaccpar: 187: syntax error (in preprocessor if)
/usr/lib/yaccpar: 224: syntax error (in preprocessor if)
/usr/lib/yaccpar: 229: syntax error (in preprocessor if)
/usr/lib/yaccpar: 318: syntax error (in preprocessor if)
/usr/lib/yaccpar: 334: syntax error (in preprocessor if)
/usr/lib/yaccpar: 378: syntax error (in preprocessor if)
*** Error code 2
make: Fatal error: Command failed for target `gram.o'

this is on a sun sparcstation. any clues?  i don't grok yacc...

--Ed

From emv@heifetz.msen.com  Sun Mar 22 05:26:34 1992
Return-Path: <emv@heifetz.msen.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16158; Sun, 22 Mar 92 05:26:34 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA22231; Sun, 22 Mar 92 05:22:04 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA29898; Sun, 22 Mar 92 06:21:52 +0200
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lSK12-000HpjC@heifetz.msen.com>; Sat, 21 Mar 92 23:18 EST
Message-Id: <m0lSK12-000HpjC@heifetz.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: behavior of ">" and ">>" in line mode browser
Date: Sat, 21 Mar 92 23:18:39 -0500
From: Edward Vielmetti <emv@msen.com>

I wanted to download a piece of html that I had written (and that Tim
had prettied up) so that I could bring it up to date.  When I did

% www -source http://......NewsGroupRelated.html

it started to show me the file as I would have properly expected to see
it.  But when I did 
	<RETURN> for more, etc: > /tmp/ng.html
the file that appeared was fully formatted (not what I expected or wanted).

i'll try to track down the problem...

--Ed


From emv@heifetz.msen.com  Sun Mar 22 06:10:07 1992
Return-Path: <emv@heifetz.msen.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16179; Sun, 22 Mar 92 06:10:07 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA27945; Sun, 22 Mar 92 06:05:36 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA00994; Sun, 22 Mar 92 07:05:24 +0200
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lSKhB-000HcYC@heifetz.msen.com>; Sun, 22 Mar 92 00:02 EST
Message-Id: <m0lSKhB-000HcYC@heifetz.msen.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: "Cannot connect to information gateway %s\n", gateway
Date: Sun, 22 Mar 92 00:02:11 -0500
From: Edward Vielmetti <emv@msen.com>

(that's from HTAccess.c)

I want to be able to make references like
	   www rfc:934
	or www rfc:934.txt
and have that turned into
	www file://ftp.nisc.sri.com/rfc/rfc934.txt

what should I set "WWW_rfc_GATEWAY" to to do something like that?

it looks like the code in HTAccess.c is only set up to use HTTP as
a gateway scheme, which is fair and good, though I would expect that
if I say
	setenv WWW_rfc_GATEWAY file://ftp.nisc.sri.com/rfc/
that it would look and say "aha, a file, better FTP it".

this is with the 1.2c version of the line mode browser.

thanks,

--Ed

From HARMO@valt.helsinki.fi  Sun Mar 22 09:55:31 1992
Return-Path: <HARMO@valt.helsinki.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16284; Sun, 22 Mar 92 09:55:31 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA06249; Sun, 22 Mar 92 10:50:53 +0200
Received: from charon-gw.pc.Helsinki.FI by kruuna.helsinki.fi with SMTP id AA10617
  (5.65c/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Sun, 22 Mar 1992 10:50:19 +0200
Received: From HYLKN1/WORKQUEUE by charon-gw.pc.Helsinki.FI
          via Charon 3.4 with IPX id 100.920322105033.256;
          22 Mar 92 10:51:56 +0200
Message-Id: <MAILQUEUE-101.920322104940.179@valt.Helsinki.FI>
To: www-talk@nxoc01.cern.ch
From: "Timo Harmo - SocSci U of Helsinki"  <HARMO@valt.helsinki.fi>
Date:     22 Mar 92 10:49:40 EET
Subject:  Graphical browsers in hypertext
X-Pmrqc:  1
X-Mailer: Pegasus Mail v2.2 (R3).

Is there, or is there planned, some kind of standard for
presenting graphical browsers in WWW?
I think it would be great to have maps of the hyperterritories one is
about to explore. And it could be quite simple, too. The map could be
just a list of links with coordinates (and maybe some formatting
info?), line-mode clients could ignore the coordinates and present
the browsers as lists.
 -Timo

From emv@heifetz.msen.com  Mon Mar 23 00:56:45 1992
Return-Path: <emv@heifetz.msen.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16785; Mon, 23 Mar 92 00:56:45 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA22856; Mon, 23 Mar 92 00:52:15 +0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA27154; Mon, 23 Mar 92 01:51:59 +0200
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lScHN-000HntC@heifetz.msen.com>; Sun, 22 Mar 92 18:48 EST
Message-Id: <m0lScHN-000HntC@heifetz.msen.com>
To: www-talk@nxoc01.cern.ch
Cc: timbl@nxoc01.cern.ch
Subject: WAISGate support for WAIS 'HTML' doc type
Date: Sun, 22 Mar 92 18:48:43 -0500
From: Edward Vielmetti <emv@msen.com>

In WAISGate.c (part of the WAIS/WWW gateway in the Daemon distribution)
there's a little hunk of code that says basically

	pick up the doctype of the document
	if it's WSRC (a WAIS source),
		it's an index description file,
		parse the WSRC
	else
		it's a plain text document,
		send it as a straight text file

It strikes me as a reasonable idea to extend this to put in another
case that says
	if it's HTML
		it's an HTML file,
		send it with no extra parsing

If can agree that this is a reasonable thing to do, then I'll make
the necessary changes to "waisindex" to index up the html files I've
written to date and serve them up.  

--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120
"Not to panic.  Networking will eventually get to Michigan.  Remember
 the decades it took IBM to discover virtual memory."  Randy Bush


From timbl  Mon Mar 23 16:30:33 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17902; Mon, 23 Mar 92 16:30:33 GMT+0100
Date: Mon, 23 Mar 92 16:30:33 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203231530.AA17902@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: "Timo Harmo - SocSci U of Helsinki" <HARMO@valt.helsinki.fi>
Subject: Re: Graphical browsers in hypertext
Cc: www-talk@nxoc01.cern.ch

> From: "Timo Harmo - SocSci U of Helsinki"  <HARMO@valt.helsinki.fi>
> Date:     22 Mar 92 10:49:40 EET
>
> Is there, or is there planned, some kind of standard for
> presenting graphical browsers in WWW?
> I think it would be great to have maps of the hyperterritories one is
> about to explore. And it could be quite simple, too. The map could be
> just a list of links with coordinates (and maybe some formatting
> info?), line-mode clients could ignore the coordinates and present
> the browsers as lists.
>  -Timo

There are three possibilities here.

One is a general graphics browser -- that is, instead of being limited to
hypertext, go for hypergraphics. This would mean picking a graphics
standard and adding an anchor representation to add to it. As you say, a
line mode browser could just list the links from a graphics node.

Another is building a graphical map of part of the web. This is a good way
to navigate, but it is quite a challenge to decide which nodes and links
to put in and leave out, and where to put the nodes. Bear in mind that some
nodes have just a few links, some have hundreds. Trying to get the most into a
window and at the same time make it look natural is an interesting problem.
If it was computationally intensive it could be done off-line.

The third is combining the two above by making a "map" window for an existing
browser. This could serve the "History" function of showing where a user
has been, but with links off to other nodes too.  As most people seem to prefer
to think of the data they browse as a tree, one could start by representing the
paths the user took as a tree, and then put in cross-links and links to
other referenced nodes.

Yes, its a great idea -- anyone want to implement it?   :-)

	Tim


From timbl  Mon Mar 23 17:32:29 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18049; Mon, 23 Mar 92 17:32:29 GMT+0100
Date: Mon, 23 Mar 92 17:32:29 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203231632.AA18049@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: WAISGate support for WAIS 'HTML' doc type
Cc: www-talk@nxoc01.cern.ch

Ed,

Great.  I have put in the mod into the WAIS gateway running here. -- I have no
HTML WAIS index to try it on though, so let me know when you do.

BTW, are you using Simon Spero's filter mods to filter out control information
(and weight title information and headings)?

Tim

From jfg@bernd.cern.ch  Mon Mar 23 17:53:17 1992
Return-Path: <jfg@bernd.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18099; Mon, 23 Mar 92 17:53:17 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA08402; Mon, 23 Mar 92 17:48:43 +0100
Received: by bernd.cern.ch (AIX 3.1/UCB 5.61/4.03)
          id AA15238; Mon, 23 Mar 92 17:47:01 -2300
Date: Mon, 23 Mar 92 17:47:01 -2300
From: jfg@bernd.cern.ch (Jean-Francois Groff)
Message-Id: <9203241647.AA15238@bernd.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: behavior of ">" and ">>" in line mode browser
References: <m0lSK12-000HpjC@heifetz.msen.com>

  Thank you Ed for more useful bug reports. Here are your answers...

----------------------------------------------------------------------------
problem yacc'ing violaWWW

I don't know. I never compiled it myself... The error is not in gram.y...
Looks like your cc doesn't understand the "#if" preprocessor directive (ANSI).
Try gcc instead.

----------------------------------------------------------------------------
behavior of ">" and ">>" in line mode browser

Here's a diff on HTBrowse.c to handle this. The line numbers and the
"the_choice" variable will not correspond to your code because they're
from the unreleased 1.2e (soon to become 1.3 on ftp...)

*** 1080,1087 ****
  
                command  = (char *) malloc(
                        strlen(address)+strlen(the_choice)+30);
!               sprintf(command, 
!                       "www -n -na -p \"%s\" %s", address, the_choice);
                result = system(command);
                if (result) printf("  %s  returns %d\n", command, result);
                free(command);
--- 1080,1087 ----
  
                command  = (char *) malloc(
                        strlen(address)+strlen(the_choice)+30);
!               sprintf(command, "www -n %s \"%s\" %s", 
!                       HTDiag ? "-source" : "-na -p", address, the_choice);
                result = system(command);
                if (result) printf("  %s  returns %d\n", command, result);
                free(command);

----------------------------------------------------------------------------
rfc: "gateway"

I see your point. However, the only intention of the WWW_foo_GATEWAY syntax
is to enable access to protocols not understood by the www client by means
of a gateway that translates those to/from HTTP/HTML. Ideally, what we need
to be able to fetch RFCs properly is a naming service, x500 or whatever.
Your rfc: access is rather an address alias. For that, you could direct it
to your own HTTP server with WWW_rfc_GATEWAY, and then insert

	map	rfc:	file://ftp.nisc.sri.com/rfc/

in your httpd.conf rule file. But beware that if you start serving HTML
files with rfc: addresses instead of file://host/rfc, every www client in
the world will have to set WWW_rfc_GATEWAY.

----------------------------------------------------------------------------
WAISGate support for WAIS 'HTML' doc type

Tim answered this one. As he said, "Great!".

----------------------------------------------------------------------------
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"If we were directed from Washington when to sow and when to reap,
 we would soon want bread."
	- Thomas Jefferson


From timbl  Tue Mar 24 11:23:31 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19187; Tue, 24 Mar 92 11:23:31 GMT+0100
Date: Tue, 24 Mar 92 11:23:31 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203241023.AA19187@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: jfg@bernd.cern.ch (Jean-Francois Groff)
Subject: Mapping names in the server
Cc: www-talk@nxoc01.cern.ch

Ed,

As JF says, you can  map logical document names to real file names in the server by  
means of the rule file. We didn't put the rule file into the client,
because we didn't want the start-up time to be long. Also,
we wanted a W3 document name to be followable by anyone, not just
the few who have picked up the latest gems of rule file titbits.

(There were a couple of starts missing from JF's example, which should have been

	map	rfc:*	file://ftp.nisc.sri.com/rfc/*

)

Actually the current distributed server expects the output of the rule file
to be a local filename. You would have to modify it to expect a w3 address.

In the long term, a name service should exist to translate

	name-service:/org/isoc/rfc/959

into say file://ftp.nisc.sri.com/rfc/rfc959.ps and .txt.  As noone seems to
want to extend the DNS, it looks as though x500 is the best bet. There was
some discussion on this at the IETF, though it'll be a while before x500 is all  
over.

Tim

From timbl  Thu Mar 26 15:25:12 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23337; Thu, 26 Mar 92 15:25:12 GMT+0100
Date: Thu, 26 Mar 92 15:25:12 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203261425.AA23337@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Jonny Goldman <jonathan@think.com>
Subject: Openning the WAIS document-id syntax
Cc: www-talk@nxoc01.cern.ch, wais-talk@think.com

> Date: Tue, 24 Mar 92 09:46:21 PST
> From: Jonny Goldman <jonathan@think.com>

Jonny,

This is relevant to the WAIS-FTP work Jim is doing.

Unfortunately none of the WAIS crowd could get to discussions at the IETF -- though  
John Curran represented the WAIS side. Those discussions were very interesting. 


The data model of WAIS (documents in databases) could be deconstrained to allow  
documents themselves to be or contain lists of documents, and for lists of  
documents to point to things other than documents in the same database.

This is the way the second part can work.  Normally, a search returns a list of  
doc-ids, each one (basically) like

	/usr/local/lib/wais/mydatabase/fred/myfile.txt

which is in fact a filename. There's a load of other stuff in there which we can  
ignore for now.  What a WAIS search needs to be able to do, when you are pointing
to files, is to return a pointer to a file in FTP say. We do that in two steps.
First, we recognise that that id is local to the conext of a wais server on host  
myhost and port myport. When the server returns that string, the client
uses knowledge of the context in which it was quoted to exapnd that to

	wais://myhost.dom.net:myport/usr/local/lib/wais/mydatabase/fred/myfile.txt

This is a refernece you can quote to anyone as it makes sense anywhere. No context.
I called it a UDI but we'll have to change the name. Document Access Token maybe.
It's like Brewster's proposal but extendable to other protocols.  [Yes, WAIS is a  
good protocol but there are others. Including name servers and directories which  
will be needed for long-lived but movable documents.]

Now suppose one day a server returns a doc-id INCLUDING the protocol, host, etc.  
For example, your WAIS FTP engine (like the ARCHIE WAIS) returns what are basically
pointers to files. Just now, because of the constraints of the model, it has to  
return a part of a file within the database. Suppose we change that, so that
in your case it just returns a doc-id which specifies anonymous ftp access, like:

	file://otherhost.com/pub/doc/mydoc.txt

The client has a general retrieval engine which can accept doc-ids in many domains  
-- not just WAIS. That allows it to go out over a different protocol to retrieve  
the object.

This is the way WWW and Gopher work.  They are open systems -- you can link into
any other system within reason.  That's why the fuss about universal document  
identifiers.  Maybe the WAIS people would to incorporate them -- that is, just
make sure that the normal WAIS server return things which are -- like the one
above -- special cases of the more general syntax.

I haven't had much comment from the WAIS side about the UDIs, but I'd like to have  
some. (file://info.cern.ch/pub/www/doc/udi1.ps was background for the IETF  
discussions.) We plan a small working group hacking out the details before an RFC  
is submitted.


> I like the idea of generalized interfaces, customized servers.

You bet!


- Tim BL


From jonathan@quake.think.com  Thu Mar 26 18:53:00 1992
Return-Path: <jonathan@quake.think.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23811; Thu, 26 Mar 92 18:53:00 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA06767; Thu, 26 Mar 92 18:48:28 +0100
Received: from philo.quake.think.com. by quake.think.com (4.1/SMI-4.0)
	id AA00347; Thu, 26 Mar 92 09:48:02 PST
Received: by philo.quake.think.com. (4.1/SMI-4.1)
	id AA00262; Thu, 26 Mar 92 09:47:34 PST
Date: Thu, 26 Mar 92 09:47:34 PST
Message-Id: <9203261747.AA00262@philo.quake.think.com.>
From: Jonny Goldman <jonathan@think.com>
Sender: jonathan@quake.think.com
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch, wais-talk@think.com
In-Reply-To: Tim Berners-Lee's message of Thu, 26 Mar 92 15:25:12 GMT+0100 <9203261425.AA23337@ nxoc01.cern.ch >
Subject: Openning the WAIS document-id syntax

First, I'd like to point out the WAIS-FTP doesn't mean a client or server
understands FTP protocol.  It's simply a customized server that functions
like FTP (but is read-only).  It's mainly an experiment in modifying
servers and providing services under WAIS.

   Date: Thu, 26 Mar 92 15:25:12 GMT+0100
   From: timbl@nxoc01.cern.ch (Tim Berners-Lee)

   [...]

   The data model of WAIS (documents in databases) could be deconstrained
   to allow documents themselves to be or contain lists of documents, and
   for lists of documents to point to things other than documents in the
   same database.

I take it you're suggesting a new TYPE for a document: Derived types?  In a
sense the catalog is one of these.

   This is the way the second part can work.  Normally, a search returns a
   list of doc-ids, each one (basically) like

	   /usr/local/lib/wais/mydatabase/fred/myfile.txt

   which is in fact a filename.

Let me also point out that this is just the method used in the sample
server.  The CM server does not return DocID's that are derived from
filenames.

In fact, DocID's are "any"s, and that means they can have anything in them,
so long as the server understands how to return a specified amount of data
to a client when presented a DocID and a range.

   There's a load of other stuff in there which we can ignore for now.
   What a WAIS search needs to be able to do, when you are pointing to
   files, is to return a pointer to a file in FTP say. We do that in two
   steps.

I don't agree.  I think the server should do the retrieval.  The client
should not have to know anything about the REAL location of the document.
More on that below.

   First, we recognise that that id is local to the conext of a wais server
   on host myhost and port myport. When the server returns that string, the
   client uses knowledge of the context in which it was quoted to exapnd
   that to

	   wais://myhost.dom.net:myport/usr/local/lib/wais/mydatabase/fred/myfile.txt

   This is a refernece you can quote to anyone as it makes sense anywhere.
   No context.  I called it a UDI but we'll have to change the name.
   Document Access Token maybe.  It's like Brewster's proposal but
   extendable to other protocols.  [Yes, WAIS is a good protocol but there
   are others. Including name servers and directories which will be needed
   for long-lived but movable documents.]

This is a good idea, but I feel rather strongly that we should be very
careful in overloading the protocol.  Specifying a syntax for DocID's is
one way of overloading the protocol.  Standardizing types is another.

   Now suppose one day a server returns a doc-id INCLUDING the protocol,
   host, etc.  For example, your WAIS FTP engine (like the ARCHIE WAIS)
   returns what are basically pointers to files. Just now, because of the
   constraints of the model, it has to return a part of a file within the
   database. Suppose we change that, so that in your case it just returns a
   doc-id which specifies anonymous ftp access, like:

WAIS-FTP doesn't return pointers to remote files.  It returns local DocIDs
for use in retrieving a file local to the server.  Archie WAIS (and
ftpable-readmes) returns these pointers.  That's a different story.

Now for a small discussion of WAIS DocID's. So far WAIS DocID's have only a
few fields:

typedef struct DocID{
   any* originalServer;
   any* originalDatabase;
   any* originalLocalID;
   any* distributorServer;
   any* distributorDatabase;
   any* distributorLocalID;
   long copyrightDisposition;
} DocID;

The part you refer to is just the LocalID part.  If you look at some of the
DocID's returned by the serial server, you'll see the other fields are
filled in (though the Server fields don't contain much useful information -
it's that part we were trying to standardize with the doc-id proposal).

	   file://otherhost.com/pub/doc/mydoc.txt

   The client has a general retrieval engine which can accept doc-ids in
   many domains -- not just WAIS. That allows it to go out over a different
   protocol to retrieve the object.

There are two ways to handle this, of course.  Either the client or the
server could do the retrieval.  I believe the server should handle the
protocol part (if the document is stored on some FTP server somewhere, the
WAIS server can just fetch the file, and return it to the client).  This
reduces client complexity.  I have no objection to specifying the
protocol/server in the DocID (perhaps with another field), but we must
standardize the meanings.

   This is the way WWW and Gopher work.  They are open systems -- you can
   link into any other system within reason.  That's why the fuss about
   universal document identifiers.  Maybe the WAIS people would to
   incorporate them -- that is, just make sure that the normal WAIS server
   return things which are -- like the one above -- special cases of the
   more general syntax.

   I haven't had much comment from the WAIS side about the UDIs, but I'd
   like to have some. (file://info.cern.ch/pub/www/doc/udi1.ps was
   background for the IETF discussions.) We plan a small working group
   hacking out the details before an RFC is submitted.

Come up with an RFC, and we'll try to abide by it.  I'd like to caution you
against overloaded strings.  We've got enough of them already.

For a start, I'd suggest we use the originalServer as the identifier for
the HOST, and the originalDatabase can inform us of the protocol.

- Jonny G

From timbl  Fri Mar 27 09:58:11 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24800; Fri, 27 Mar 92 09:58:11 GMT+0100
Date: Fri, 27 Mar 92 09:58:11 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203270858.AA24800@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: more WWW/WAIS gateway hacks
Cc: www-talk@nxoc01.cern.ch

From: Edward Vielmetti <emv@msen.com>
Date: Fri, 27 Mar 92 00:07:40 -0500

(I'm going to have to get the WWW gateway up and running myself.)

	Sound like a good idea, Ed!  Especially no I've released it
	"properly" :-)

Here's a thought to make WWW/WAIS gateways for netnews even more
useful than they already are.

Some WAIS db's are really db's full of news articles.  comp.archives
is one, there's collections of current comp.sys.* and sci.* groups,
etc etc.

The WWW approach to news articles is really cool cause it builds links
based on embedded message ID's, links on the newsgroups: line, stuff
like that.

If you could somehow note (maybe on a per-gateway basis?  it might
not be possible to discern on the fly, so you'd perhaps configure
it ahead of time) that the texts coming back from a WAIS server were
really news articles instead of arbitrary globs of texts, and theny
you added the set of news-parsing stuff, you'd have a big win on your
hands.

(eg. try
	<a href=wais://wais.oit.unc.edu:210/comp-sys?jpeg> jpeg in comp.sys </a>
and explain why you can't chain back to things from there.)

will get the code and see what I can do to add this.

--Ed

	Two ideas here. One is to add a "MailNews" RFC850/822 message type
	which switches on client message parsing.  The other is to have a
	converter in the gateway which offes the message as TEXT or as HTML.
	For those clients which have HTML, they pick up the hypertext
	version. The first seems easier. Can we use the same type for mail
	and news messages?

	Another idea. Suppose you run a server on the NNTP machine, so it
	has direct access to the news, and when news comes in you cross-link
	the references, so that you can follow links to replies to messages
	references BY a message as well as the messages it references.

	Maybe this could be done on the fly when the message is read.

	-Tim


pls pass on to the whole www crew....

ps.  you interested in starting a "comp.infosystems.web" group?
     should get a lot of attention.  my WAIS newgroup vote has
     150+ yes votes in the first two days !

	Sure, if you think it'll fly. I guess we have to gateway the mail
	for a while. Maybe comp.infosystems.www --- there is the "web and Cweb"
	toolset from Knuth (?) which we don't want to get confused with.


From timbl  Fri Mar 27 11:45:43 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25109; Fri, 27 Mar 92 11:45:43 GMT+0100
Date: Fri, 27 Mar 92 11:45:43 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203271045.AA25109@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Linda Murphy <murphy@dairp.upenn.edu>
Subject: WWW NeXT client, telnet feature; Web traversal
Cc: www-talk@nxoc01.cern.ch

> Date: Thu, 26 Mar 92 18:06:51 GMT-0500
> From: Linda Murphy <murphy@dairp.upenn.edu>

> My environment: a NeXT.
> ...I am running pre-release b of version 0.13 of the WWW application.
> I get ... Invalid access prefix for 'telnet://info.cern.ch'
> Can be one of news: but not 'telnet:'.


The NeXT client was frozen last summer, so it has no innovations which occured  
since then. I have it relatively high on my (rather large) agenda to bring it  
up-to-date from a prototype to  include the re-engineerd common library, and  
rerelease it.  (I was under pressure here not to put too much work into it because  
NeXTs were not official CERN workstations for a while: everyone wanted X. Now X is  
coming from other people, the pressure should ease.)

Another problem you will find is that the NeXT client can't cope with the very long  
identifiers returned by the latest WAIS servers such as the directory of servers.  
It just crashes becuase I put in an arbitrary hard limit (bad! :-().

Apart from telnet: it also can't handle gopher:.

I'm really sorry for that lack of functionality.  I use the app all the time myself  
so it bugs me too. I'll do it when I have time, but better server functionality I  
think should come first.  Someone in Hawaii whose mail address I don't seem to have  
(are you out there?) thought they might find six person-months to put into the NeXT  
app which would be great,

> Further down in the bug list, you mention serialisation and web
> traversal.  What do you mean by this term?
> 

> --lam

I mean a feature to turn a web into a serial document, like to print it on paper,  
by traversing the web. This is really needed -- the world is looking for ways of  
turning text into hypertext, but the moment you do it, you want to turn it back  
again for people who want paper! A traversal, and concatenation followed by a sed  
file to turn it into TeX macros should cover it.

Also one imagines tools which traverse the web recursively in a breadth-first way  
looking for things -- interesting data and indexes for example. I image terminating  
the search as a function of number of links traversed modified by the  
"interestingness" of documents found on the way (judged by the words the contain  
matched against a query).  This is a step toward a "knowbot"-like tool for resource  
discovery. Now we have a real web to play with, we can start making such machines  
in earnest.

	Tim



From timbl  Fri Mar 27 12:37:47 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25222; Fri, 27 Mar 92 12:37:47 GMT+0100
Date: Fri, 27 Mar 92 12:37:47 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9203271137.AA25222@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re: CURIA - WWW server for Irish manuscripts coming soon
Cc: www-talk@nxoc01.cern.ch

> Date: Thu, 26 Mar 92 21:38:55 GMT
> From: pflynn@curia.ucc.ie (Peter Flynn)

> OK, I still have to get the daemon running, but I should have that next
> week. You can then add us to the list of stuff available in W3. Details are:

<DT><a name=??? href=http:curia.ucc.ie//usr/local/lib/WWW/CURIA_menu.html>The
CURIA Project
<DD>Browseable Irish manuscripts from the Royal Irish Academy and University
College Cork.

	(BTW You can omit name==??? -- you don't need a name unless you
	want to refer TO the anchor.)

	I think you mean http://curia.ucc.ie/usr/local/lib/WWW/CURIA_menu.html
	the souble slash introduced the host.

We are still waiting reverse IP registration, so currently I guess we are
only accessible as 143.239.1.8

	Ok, http://143.239.1.8/usr/local/lib/WWW/CURIA_menu.html
	will have to do for now. Let me know when it's up. A few tips.

	Please run the server on port 80 as new software will default
	to this official IANA port number. In the mean time quote it
	as http://143.239.1.8:80/usr/local/lib/WWW/CURIA_menu.html
	to be safe.

	In the configuration file, you can put a map line
	  map / /usr/local/lib/WWW/CURIA_menu.html
	so that someone accessing http://143.239.1.8:80/ will
	get something useful about the site. You have to make
	all the refernces in that document absolute, as it will
	appear in two places in the web.

At the moment there's just one or two pages of test stuff, but this is
defined in a status report which I will keep up to date as part of the
documentation. We have nearly finished scanning vol 1 of the _Annals of
the Four Masters_ and the _Chronicon Scotorum_ so we'll be editing them into
shape in the next month or so. As I won't be at JENC, I want to try hard
to get a useable chapter or two up and browseable by then.

	Sounds great!  Admitedly the Irish might be understandable by
	a limite audience, but it will be available to gaelic
	academia worldwide.  (Are you putting up parallel translations?)

I fudged the five lowercase accent-aigu vowels into HTML.c as you suggested.

	Great -- can you send me the list and I'll incorporate it
	into all the sources.  We should put in all the European set
	of characters in fact.

It works fine for the sun-cmd X shell window, but when I replaced them with
the five char codes for the IBM PC, and then access it over telne from
my PC logged into my VAX, something somewhere en route is mapping the
8-bit chars into 7-bit, so an acute-a (decimal 160) ends up as a space
and an acute-e as a double-quote (whoops, sorry, acute-a comes out as
an @-sign). This is not WWW code, but either the sun terminfo/termcap
being intrusive or something in the comms side. It's going to be a major
headache to get it sorted...all help welcome.

	If someone en route is killing the 8th bit, then you are stuck.
	The best thing then seems to be to run WWW on the PC directly.
	In fact some of the PC graphic characters are in non-graphic
	psoitions of the table (0X, 1X, 8X, 9X hex), so telnet is
	likely to have trouble anyway.
	There's a port done for SUN/NFS: what type of TCP/IP for
	the PC do you use?

Have a nice weekend!
///Peter

	You too.
	- Tim


From emv@heifetz.msen.com  Fri Mar 27 15:34:58 1992
Return-Path: <emv@heifetz.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25727; Fri, 27 Mar 92 15:34:58 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA02049; Fri, 27 Mar 92 15:30:29 +0100
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lUHtT-000HqgC@heifetz.msen.com>; Fri, 27 Mar 92 09:26 EST
Message-Id: <m0lUHtT-000HqgC@heifetz.msen.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: pflynn@curia.ucc.ie (Peter Flynn), www-talk@nxoc01.cern.ch
Subject: Re: CURIA - WWW server for Irish manuscripts coming soon 
In-Reply-To: Your message of Fri, 27 Mar 92 12:37:47 +0100.
             <9203271137.AA25222@ nxoc01.cern.ch > 
Date: Fri, 27 Mar 92 09:26:55 -0500
From: Edward Vielmetti <emv@msen.com>

w/r/t encoding of non-Latin characters, I'd recommend at least looking
at the work of the "Text Encoding Initiative" (the TEI) - they're
a scholarly bunch who have standards for how to do SGML encoding
of scholarly texts esp. including representation of glyphs from languages
other than English.

as to a reference, hm.  so far as I know none of the discussions
are WAISed yet, the best bet is the listserv at UICVM.UIC.EDU.

<title> tei - text encoding initiative </title>

<p>
michael sperberg-mcqueen at uic
some !@#$ listserv somewhere, let's see
<a href=wais://wais.cic.net/lists?tei> look in lists </a>
<p>

--Ed

From emv@heifetz.msen.com  Mon Mar 30 16:37:34 1992
Return-Path: <emv@heifetz.msen.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00108; Mon, 30 Mar 92 16:37:34 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA27949; Mon, 30 Mar 92 17:32:52 +0200
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA07840; Mon, 30 Mar 92 17:32:40 +0200
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lVOIS-000Hp1C@heifetz.msen.com>; Mon, 30 Mar 92 10:29 EST
Message-Id: <m0lVOIS-000Hp1C@heifetz.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: bad doc-id via WAIS/WWW gateway
Date: Mon, 30 Mar 92 10:29:20 -0500
From: Edward Vielmetti <emv@msen.com>

For some WWW searches on WAIS databases, I get an error response.  
My hunch is that there are statically sized buffers hiding somewhere
in the system and that absurdly long WAIS document-id's are overflowing
them.

--Ed



Index comp-sys contains the following 1 item relevant to ''.
<dl>
Code: SF, Bad DocID in request
</DL>
<h2>No text was returned!</h2>



From emv@heifetz.msen.com  Tue Mar 31 07:02:32 1992
Return-Path: <emv@heifetz.msen.com>
Received: from cernvax.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00954; Tue, 31 Mar 92 07:02:32 GMT+0100
Received: by cernvax.cern.ch (5.57/Ultrix2.0-B)
	id AA24304; Tue, 31 Mar 92 07:57:52 +0200
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA20113; Tue, 31 Mar 92 06:43:10 +0200
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lVadT-000HtvC@heifetz.msen.com>; Mon, 30 Mar 92 23:39 EST
Message-Id: <m0lVadT-000HtvC@heifetz.msen.com>
To: www-talk@nxoc01.cern.ch
Cc: cddev@sterling.com
Subject: Changing NNTP servers on the fly.
Date: Mon, 30 Mar 92 23:39:50 -0500
From: Edward Vielmetti <emv@msen.com>

I have a CD-ROM (Netnews/CD from Sterling Software) that has a big
pile of news in it -- and I'd like to support reasonable access to
it via WWW.  However; the current support for NNTP reading in WWW
assumes that there's a single NNTP server through which all
"news:" access will go, so it's not straightforward to support
a second system which might have an alternative access to a news spool.

I'd suggest extending the syntax to read as follows
	news:comp.sys.foo		comp.sys.foo on default system
	news://nntp.archive.msen.com/comp.sys.foo       nntp.archive.msen.com
	news://nntp.archive.msen.com:1990/comp.sys.foo  (on port 1990)
with similar extensions for referencing individual articles.

--Ed

From timbl  Tue Mar 31 09:17:36 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01065; Tue, 31 Mar 92 09:17:36 GMT+0200
Date: Tue, 31 Mar 92 09:17:36 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9203310717.AA01065@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: Changing NNTP servers on the fly.
Cc: www-talk@nxoc01.cern.ch, cddev@sterling.com, lear@oni.sgi.com (Eliot Lear)


> I have a CD-ROM (Netnews/CD from Sterling Software) that has a big
> pile of news in it -- and I'd like to support reasonable access to
> it via WWW.  However; the current support for NNTP reading in WWW
> assumes that there's a single NNTP server through which all
> "news:" access will go, so it's not straightforward to support
> a second system which might have an alternative access to a news spool.
> 

> I'd suggest extending the syntax to read as follows
> 	news:comp.sys.foo		comp.sys.foo on default system
> 	news://nntp.archive.msen.com/comp.sys.foo       nntp.archive.msen.com
> 	news://nntp.archive.msen.com:1990/comp.sys.foo  (on port 1990)
> with similar extensions for referencing individual articles.
>
> - Ed

The syntax would certianly fit in with the UDI format -- however, are the semantics
well defined?  In general, the whole point of news is that it is held locally,
avoiding millions of WAN accesses.

If you put in a node name, then you are changing the way the protocol works  
altogether.  This might be conveient, but its not really "news". You're saying
that we can use NNTP as a file retrieval protocol. Obviously, once you have given  
out a reference like that above you have to make nntp.archive.msen.com available  
for everyone in the world.

Maybe this is a way to solve the news archive retrieval problem. It isn't  done
that way at the moment of course: Its a big headache right now. Messages are tared  
and compressed and put on some machine under the date of the message -- you have to  
know which newsgroup the message was sent to, and then look the archive hostname up  
in a list which doesn't (correct me?) exist. (Another use for the X-500 directory?)

It doesn't fit very well into the news model, all the same. For example, when you  
find a reference to another newsgroup/article on your CD rom, There's no way of  
knowing whether you should look it up on the CD rom or on a "live" news server.
We really need some NNTP extensions to insist that the message-id can carry some  
hints as to where it might be archived -- unfortunately I missed the NNTP session  
at the IETF but I know that Eliot Lear (ietf nntp wg chair) for example is thinking  
about such problems, and indeed from talking to him I got the impression that the  
NNTP group's discussions were overflowing into the retrieval and resource discovery  
areas.

It's not _trivial_ to put it in the code for (One will have to keep a cache of  
network connections to hosts) so I won't do it now.  I'd point out you could set up  
an HTTP server to serve the news data, although it would have (currently) to  
convert the news format into HTML which it (currently) doesn't (yet) do (yet).

Tim

--Ed


From lear@yeager.corp.sgi.com  Tue Mar 31 18:48:05 1992
Return-Path: <lear@yeager.corp.sgi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02572; Tue, 31 Mar 92 18:48:05 GMT+0100
Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
	id AA08030; Tue, 31 Mar 92 19:43:27 +0200
Received: from relay.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
	for www-talk@nxoc01.cern.ch id AA05925; Tue, 31 Mar 92 09:42:46 -0800
Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (911016.SGI/911001.SGI)
	for @sgi.sgi.com:timbl@nxoc01.cern.ch id AA10133; Tue, 31 Mar 92 09:42:44 -0800
Received: by yeager.corp.sgi.com (911016.SGI/911001.SGI)
	for @sgi.com:cddev@sterling.com id AA14310; Tue, 31 Mar 92 09:42:43 -0800
Date: Tue, 31 Mar 92 9:42:42 PST
From: Eliot Lear <lear@yeager.corp.sgi.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: Edward Vielmetti <emv@msen.com>, www-talk@nxoc01.cern.ch,
        cddev@sterling.com
Subject: Re: Changing NNTP servers on the fly.
In-Reply-To: Your message of Tue, 31 Mar 92 09:17:36 GMT+0200
Message-Id: <CMM.0.90.2.702063762.lear@yeager.corp.sgi.com>


Hello all,

It is true that the nntp working group has been pushing against all
sorts of retrieval issues.  How any of the following would be
implemented is completely an open question, right now.  I should say
that much of what follows was the result of informal brainstorming,
and a lot of discussion at various USENIXes.  I think everyone agrees
that the NNTP people do not yet have enough information to make a
decision, and there is a growing concern about scope of whatever
project we would choose to take on, as one could quickly envision a
very broad all-encompassing project that would serve everyone's needs
but never be implemented.  As we begin to discuss best ways to present
news to the user, we immediately come up against five questions.
Briefly described, they are the following:

[1]	How shall the user select and receive new information?
	Are we talking SQL or Z.39 or what?

[2]	Should the mechanism be a pull-update/lockstep mechanism, as
	it is now, or does the server need to have enough smarts about
	things like priorities such that the mechanism should be
	async/interrupt driven?

[3]	Should we be writing the protocol with some sort of RPC
	mechanism in mind, such that the application doesn't even know
	if the service is local?

[4]	How do we handle archives?  Should a saved article be treated
	just as any other article, or do we need stronger archive
	search mechanisms in NNTP?  OR, should archive support be
	placed in the netnews model, itself (e.g., sendme style
	retrieval)?
	OR, should netnews reading become a distributed model, as
	access to the Internet approaches ubiquity?  Here is where
	we begin to delve into resource and information location
	issues.

[5]	Should whatever mechanism we design be limited to netnews, or
	should we also leave enough rope for someone to use it for
	mail?

So what we have right now is a growing list of questions, and not very
many answers - YET.

I must clarify one point Tim made.  News is currently stored and read
locally mostly for historical reasons.  The plain fact of the matter
is that netnews has been and continues to be more popular than the
Internet, simply because it costs less.  Thus in past people have not
considered reading over the Internet as ``the mechanism'' because it
could not be used as such by a large portion of the participants.
There is also an issue of how to find new and interesting articles
under a distributed model.  That's an area I haven't given much
thought at all to.

The statement that the current NNTP is nothing more than a file
transfer protocol is largely correct.  It's a specialized version that
takes advantage of the netnews architecture.  In fact, it would have
been quite possible to implement NNTP *in* FTP as an extension.

Eliot Lear
[lear@sgi.com]




From wei@sting.berkeley.edu  Mon Apr  6 06:07:39 1992
Return-Path: <wei@sting.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03043; Mon, 6 Apr 92 06:07:39 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24917; Mon, 6 Apr 92 06:02:33 +0200
Received: by sting.Berkeley.EDU (5.65/XCF-1.34)
	id AA00155; Sun, 5 Apr 92 21:02:27 -0700
Date: Sun, 5 Apr 92 21:02:27 -0700
From: wei@sting.berkeley.edu (Pei Y. Wei)
Message-Id: <9204060402.AA00155@sting.Berkeley.EDU>
To: www-talk@nxoc01.cern.ch
Subject: HTML printing

Hi,

Does there exists something like a HTML to postscript/troff/* converter?
I'm looking for something better than ``www -n foo.html > lpr''.

Thanks.

-Pei

From emv@heifetz.msen.com  Mon Apr  6 06:20:26 1992
Return-Path: <emv@heifetz.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03055; Mon, 6 Apr 92 06:20:26 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26318; Mon, 6 Apr 92 06:15:21 +0200
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0lXl49-000HcJC@heifetz.msen.com>; Mon, 6 Apr 92 00:12 EDT
Message-Id: <m0lXl49-000HcJC@heifetz.msen.com>
To: wei@sting.berkeley.edu (Pei Y. Wei)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML printing 
In-Reply-To: Your message of Sun, 05 Apr 92 21:02:27 -0700.
             <9204060402.AA00155@sting.Berkeley.EDU> 
Date: Mon, 06 Apr 92 00:12:19 -0400
From: Edward Vielmetti <emv@msen.com>

Pei,

You should look on the various SGML archives for tools.  If you
search
	www 'wais://wais.msen.com:210/web?sgml'
you should be led off in the right direction.

--Ed

From RASHTY@hujivms.bitnet  Mon Apr 13 17:28:35 1992
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20004; Mon, 13 Apr 92 17:28:35 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA08959; Mon, 13 Apr 92 17:28:22 +0200
Message-Id: <9204131528.AA08959@dxmint.cern.ch>
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R1)
   with BSMTP id 8169; Mon, 13 Apr 92 17:28:06 SET
Received: from HUJIVMS (RASHTY) by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 1105; Mon, 13 Apr 92 17:28:05 SET
Received: by HUJIVMS (HUyMail-V6j); Mon, 13 Apr 92 18:28:03 +0300
Date:     Mon,  13 Apr 92 18:28 +0300
From: Dudu Rashty +972-2-584848 <RASHTY@hujivms.bitnet>
To: www-talk@nxoc01.cern.ch
Subject:  few bugs in www

Hi,

when i have tried to create a telnet session than

1) it used the rlogin instead of the telnet
2) the way the rlogin is used is wrong.. it sends the command
   RLOGINtelnet /username= ...  WITHOUT THE HOSTNAME


C++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++C
HTACCESS.C   as it is now
C++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++C

	BOOL rlogin = strcmp(access, "rlogin");
	.
	.
	.

	if (!rlogin) {			/* telnet */
	    if (user) printf("When you are connected, log in as %s\n", user);
	    sprintf(command, "TELNET %s%s %s",
		port ? "/PORT=" : "",
		port ? port : "",
		hostname);
	} else {
	    sprintf(command, "RLOGIN%s%s%s%s %s", access,
		user ? "/USERNAME=" : "",
		user ? user : "",
		port ? "/PORT=" : "",
		port ? port : "",
		hostname);
	}
	if (TRACE) fprintf(stderr, "HTaccess: Command is: %s\n", command);
	system(command);
	return HT_NO_DATA;		/* Ok - it was done but no data */

C++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++C
correct code is :
C++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++C
HTACCESS.C

	BOOL rlogin = strcmp(access, "rlogin");
	.
	.
	.

	if (rlogin) {			/* telnet */
	    if (user) printf("When you are connected, log in as %s\n", user);
	    sprintf(command, "TELNET %s%s %s",
		port ? "/PORT=" : "",
		port ? port : "",
		hostname);
	} else {
	    sprintf(command, "RLOGIN%s%s%s%s %s",
		user ? "/USERNAME=" : "",
		user ? user : "",
		port ? "/PORT=" : "",
		port ? port : "",
		hostname);
	}
	if (TRACE) fprintf(stderr, "HTaccess: Command is: %s\n", command);
	system(command);
	return HT_NO_DATA;		/* Ok - it was done but no data */

C++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++C


                                              thanks
   	                                       __o     o__
	                                     _ \<,_   _.>/ _
	                                    (_)/ (_) (_) \(_)

                                             d    u   d    u
                                             Hebrew University
                                             Computation Center
                                             Jerusalem, Israel


From timbl  Tue Apr 14 12:00:05 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21572; Tue, 14 Apr 92 12:00:05 GMT+0200
Date: Tue, 14 Apr 92 12:00:05 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9204141000.AA21572@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: wei@sting.berkeley.edu (Pei Y. Wei)
Subject:  HTML printing: Conversion HTML->LaTeX->dvi->Postscript
Cc: www-talk@nxoc01.cern.ch

> Does there exists something like a HTML to postscript/troff/* converter?
> I'm looking for something better than ``www -n foo.html > lpr''.

Here's a simple html to latex converter using "sed". It's not complete, but it  
produces reasonable results on the W3 documentation, so I can now (at last) make a  
W3 book.  (A minor problem is that sed ignores any characters at the end of a file  
which are not followed by a final newline, and the NeXT editor sometimes generates  
HTML without the final newline.)

You have to prepend the document style you want to the output of sed. My makefile  
looks like

	echo " \\\\batchmode \\\\documentstyle{book}" > the_www_project.tex
	sed -f html2latex.sed $(THE_HTML) >> the_www_project.tex
	latex  the_www_project.tex


For a large book, I concatenate several html files, passing some of them through  
another sed file which removes the <TITLE> elements and demotes the <H1> to <H2>  
etc.  The file below italicises anchors, but in general it might be best to remove  
them altogether. The smartest thing would be to generate the TeX to make a little  
superscript reference to the page number to which a link refers.  Any TeX experts  
out there?

I'll put the "W3 Book" in postscript up for anonymous FTP shortly.


 Tim BL
__________________________________________ html2latex follows
1i\
\\begin{document}
$a\
\\end{document}
/<XMP>/,/<.XMP>/b lit
/<.XMP>/b lit
/<xmp>/,/<.xmp>/b lit
/<.xmp>/b lit
/s?&amp.?\\&?g
s?&gt.?>?g
s?&lt.?<?g
s?\\?\\backslash ?g
s?{?\\{?g
s?}?\\}?g
s?%?\\%?g
s?\$?\\$?g
s?&?\\&?g
s?#?\\#?g
s?_?\\_?g
s?~?\\~?g
s?\^?\\^?g
s?<TITLE>?\\author{Generated from the Hypertext}\\title{?g
s?</TITLE>?}\\maketitle ?g
s?<ADDRESS>??g
s?</ADDRESS>??g
s?<P>?\\par?g
s?<p>?\\par?g
s?<Hn>?\\part{?g
s?</Hn>?}?g
s?<H1>?\\chapter{?g
s?</H[0-9]>?}?g
s?<H2>?\\section{?g
s?<H3>?\\subsection{?g
s?<H4>?\\subsubsection{?g
s?<H5>?\\paragraph{?g
s?<H6>?\\subparagraph{?g
s?<UL>?\\begin{itemize}?g
s?</UL>?\\end{itemize}?g
s?<LI>?\\item ?g
s?<ul>?\\begin{itemize}?g
s?</ul>?\\end{itemize}?g
s?<li>?\\item ?g
s?<DL>?\\begin{description}?g
s?</DL>?\\end{description}?g
s?<DT>?\\item[?g
s?<DD>?]?g
s?<dl>?\\begin{description}?g
s?</dl>?\\end{description}?g
s?<dt>?\\item[?g
s?<dd>?]?g
s?<NEXTID[^>]*>??g
s?<A[^>]*>?\\it  ?g
s?</A>?\\/\\rm  ?g
: lit
s?<XMP>?\\begin{verbatim}?g
s?</XMP>?\\end{verbatim}?
s?<xmp>?\\begin{verbatim}?g
s?</xmp>?\\end{verbatim}?

From timbl  Thu Apr 16 08:59:03 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26309; Thu, 16 Apr 92 08:59:03 GMT+0200
Date: Thu, 16 Apr 92 08:59:03 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9204160659.AA26309@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: wathu@lanka.ccit.arizona.edu (Wije Wathugala)
Subject: Extracting the source of HTML documents, menus etc.
Cc: www-talk@nxoc01.cern.ch

> Date: Wed, 15 Apr 92 16:16:31 MST
> From: wathu@lanka.ccit.arizona.edu (Wije Wathugala)

> Hi Tim,
> Thank you very much for your mail and all the work you are doing
> with WWW.

> I have one more questions. 

>
> (1)I would like to down load some menus from WWW server in HTML so  
> that I can
> edit them and use locally.  I knwo how to get text file with the
> command but do not know how to get HTML file.  I tried to start WWW
> by www -source but still I could not get the HTML file.  Is there a  
> command
> to get them. 


The trick is to browse to the document (menu etc) you want normally  
with www. Then type "help" to get the www address of the document.  
Copy it down.

Then, separately, give the command

	www -source -n -p documentaddress > file

to extract the source into a file.  You have to do this because if  
you start www in -source mode, you can't follow any links. We paln to  
add a command to extract the source of an article when you're  
browsing normally.

> (2) Can I post this type of questions to www-interest list ?

You should send them to www-talk@info.cern.ch, not to -interest.  
Interest is used for announcements to a larger number of people.

> Thank you
>
> Wije

	You're welcome!
	Tim

PS: I'm away next week (back 27th April) but others on the list may  
be prepared to answer more questions.



From timbl  Wed May 20 12:21:37 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07372; Wed, 20 May 92 12:21:37 GMT+0200
Date: Wed, 20 May 92 12:21:37 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9205201021.AA07372@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Peter Huang <peter@hpkslx.mayfield.hp.com>
Subject: Re: www on hp3/800 at HP
Cc: www-talk@nxoc01.cern.ch


>	I saw your posting for new release of WWW and I pulled the
>	source over.  I'm quite thrill about the work you have
>	done with WWW.  I was able to compile and run the "www" on
>	hp3/800 (hpux 8.0) machine (attached is the Makefile).

	Thanks ... help me understand what the difference is between
	hp700 and hp800 -- are they binary compatible? What does the
	term "snake" cover?

>	The 300 version will coredump if the /etc/services entry
>	for www is missing.

	You mean www will or, httpd?  Or inetd? www shouldn't use the
	/etc/services file. Whats a 300?

>   	The Daemon portion also compiled and run,
>	(need to add non-protoize function declaration in HTDaemon.c and
>	HTRetrieve.c.)  I'll try to contrib when I got time.

	Shucks --I thought we'd done all that in the 0.4 release!
	What are the functions which needs de-ansiing?  We compiled in
	on a sun ok, thought that was basic enough cc.

>	I have read the copyright page and know the restriction.


	We are considering forming a consortium to allow lots of contribution
	and well-defined sharing of code, and a role for commercial
	participation (buying, selling, sponsoring!)

> 	Let me know if I can help in any other ways.

	There is a list of "how to support the web" on the project page.
	I guess a server at HP might be comercially tricky unless for
	marketting info?  Any tools, neat server scripts all gratefully accepted!
	And pass the word around...
	
>	kudos for a software nicely done.

	Thanks -- on behalf of all the people involved!

	Tim BL

>	============================================================
>	Peter Huang 		HP Response Center Lab
>	Phone: (415)691-3417  	Email: peter@hpkslx.mayfield.HP.COM
>	100 Mayfield Avenue, MS 37MA, Moutain View, CA 94043
>	============================================================


From timbl  Wed May 20 13:38:20 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07560; Wed, 20 May 92 13:38:20 GMT+0200
Date: Wed, 20 May 92 13:38:20 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9205201138.AA07560@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Rama Porrat <rama@noa.huji.ac.il>
Subject: Line mdeo browser Q & A
Cc: www-talk@nxoc01.cern.ch

Rama Porrat <rama@noa.huji.ac.il> writes,

> I am trying to write a help online manual using www. I think www can be very
> useful and the stuff I deal with really needs such a system.
> BUT there are things which must be corrected in order that www will be
> usable, and I am writing in the hope that you can correct the www
> or tell me if those things can be corrected soon.

> The most annoying thing is the appearance of a "listing" file
> on screen when displayed by www.  The fact that pages
> are displayed "backward", that is, you repeat portions of the
> file alsready displayed when you come to the last page of a file,
> is unacceptable. It makes a mess out of the display.
> The way a listing file is displayed should adhere to what's in the
> file, without any "going back". This is essential.

We haven't noticed this!  By "listing" file, do you mean a plain text
file, or part of a marked-up file which uses the <listing> tag?
What you describe seems very strange.  Please give me a reference to the file
if it on a server, or else mail it to me. Thanks.

> The way the word [end] is displayed at the end of a screen is not nice.
> It is too close to the last line and in the "middle" of the line.
> The www writer should have the option not to display this [end]
> at all, or otherwise put it in a lower and to the side of the
> screen.

This is question of taste. It is easy to recompile the browser (just GridText.c)  
with the option to define the macro END_MARK as "".  You can do that locally. The  
[end] mark was put in to stop people trying to scroll past the end of the file,  
having to press RETURN every time just to see whether there was any more left. It  
would be simpler not to have it!

Note that the X11 browsers do not have an [end] mark. On VM/XA  and MVS systems
it is <End>.  You could make a void (or Hebrew) version if you needed to.
All these things are in the file GridText.c in the browser implementation.
You could make a local variant.  If others on this list agree, then we could  
incorporate certain options in the master source.

> The h1 header displays numbers which are confusing for the reader.
> For example, in my listing file, the addition of <h1> displays the numbers (on
> sequential pages)  no numbers on first page
> (50/64) on next page (64/64) on last page.
> This is quite confusing.

These numbers should not be connected with the <h1> header.  They are the line  
number of the bottom line on the screen, and the line number of the last line in  
the file. They were asked for by users, to give some indication of how far through  
the document one is.  The numbers are not displayed on the first page as that
is displayed before the whole file has been read, for speed.

>  You even get numbers like (69/64).

If you could scroll down so that blank space after the document were
displayed, the bottom line would be greater than the last line.  But I can't get it  
to happen. Could you give me the exact sequence you are using, please, along with  
document addresses?  And tell me the version number you have (type help to get it).

> Please erase those numbers, or display something clear, like:
> Page 1 out of 3          etc.

The file is not divided strictly into pages, so to displaying page numbers
would be confusing. For example, when one returns to a document one has left by a  
link, that link is displayed, if possible, a third of the way down the page. This  
will not necessarily allign with a "page".

> The <title> is inconsistent - at times it appears on screen, 

> at other times it doesn't.

	Yes. This is a feature of the pipeline optimisation of
	the code. When the document is started, its title is not
	known and neihter is its length. The first characters are
	displayed on the screen as soon as they come in. This
	gives a faster response time

> There should be a possibility to enter the www with a pre-known
> pointer.  For example, saying     www tex
> should be able to give you the top screen pertaining to tex, without
> going through a number of previous screens.

	There is.
	You have to give the network address of the document, which is
	not so simple. It would have to be something like

		www http://info/tex

	as "www tex" will cause www to read a file "tex" in the local directory.

	Note you can define alises for users
	
		alias texhelp www http://info/help/tex/html
		texhelp

	for example

>It is also very important to give the possibility of including
>comments in html sources.

	Yes. The <comment> junk </comment> tag is respected by
	recent browsers, but only recent ones: Not the NeXT browser.

I hope this at least explains the raesons for a few things. I have put the  
intermittency of the title on our list of bugs to be fixed. We may put in options
to control some of the other things. If anyone else on this list has views on these  
things, they should say. It is only from comments from real users what break away  
from our own view of what if "nice" in a browser: Thanks for your feedback.

	Tim BL



From timbl  Thu May 21 10:21:30 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10391; Thu, 21 May 92 10:21:30 GMT+0200
Date: Thu, 21 May 92 10:21:30 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9205210821.AA10391@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: frenkiel@cdfap2.in2p3.fr (Pierre Frenkiel)
Subject: Re: www line mode browser
Cc: www-talk@nxoc01.cern.ch


> Date: Thu, 21 May 92 10:04:16 +0200
> From: frenkiel@cdfap2.in2p3.fr (Pierre Frenkiel)

>  I'm using an X terminal, with a mterm window of 60 lines.
> it's rather frustrating to see that the browser only uses 24 lines.
> I thought that the use of the terminfo corresponding to the TERM variable 

> was a standard unix feature.
> Pierre Frenkiel - tel:(331)/44.27.15.27 - e-mail:frenkiel@cdfap2.in2p3.fr


1.  Unfortunately it is only standard unix, and www runs also on vms, vm, pc,...
    However, if you contribut the code to return the width and height of
    the terminal for unix, I'll put it in to a unix-specific section
    and many will be grateful.

2.  Try
		alias www /usr/local/bin/www -p60

3. I guess a shell script could do that too -- that's what we do on VM/CMS

	Tim BL

From bloemer@helios.tnt.uni-hannover.dbp.de  Thu May 21 12:21:57 1992
Return-Path: <bloemer@helios.tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10668; Thu, 21 May 92 12:21:57 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10114; Thu, 21 May 92 12:20:28 +0200
Date: 21 May 92 10:18
From: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>
To: www-interest@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Message-Id: <RFC-822*C=de;ADMD=dbp;PRMD=uni-hannover;OU=tnt;OU=helios;S=AA06131;G=9205211018>
Subject: Program Links in WWW

RFC-822-HEADERS:
Return-Path: <@CDC2.RRZN.UNI-HANNOVER.DE:bloemer@helios.tnt.uni-hannover.de>
Cc: bloemer

==================
I would like to know, whether anybody has extended WWW such, that it is possible
to start arbitrary programs by hitting a button in a WWW browser.

Hyberbole has this feature and it could also make WWW much more mighty.

Included is a short discussion with Pei Y. Wei on this issue. 

By the way, many thanks to Tim Berners-Lee in general, to Pei Y. Wei for his 
wonderful violaWWW browser and to all people involved in the WWW project.

Arnold

________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.dbp.de    Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1
phone:  +49-511-762-5320           Germany
________________________________________________________________________________


From bloemer Tue May 12 18:13:06 1992
To: timbl@info.cern.ch, wei@xcf.berkeley.edu
Subject: World Wide Web and Viola
Cc: bloemer

...
1. Is it possible to define pseudo hyperlinks which start a subprocess?
That would be really phantastic because it allows for nice tutorials with
trial buttons. On xcf.berkely.edu I saw:


About XMap ... 

<P>
Click here for a demo.
<S>/*script*/
	if (accessible("/usr/users/ftp") != "") {
		print("doing /usr/users/ftp/ftp_public/misc/ht/projects/xmap/ultrix.ws.2.1 /usr/users/ftp/ftp_public/misc/ht/projects/xmap/sf_oak &amp \n");
/*		system("/usr/users/ftp/ftp_public/misc/ht/projects/xmap/ultrix.ws.2.1 /usr/users/ftp/ftp_public/misc/ht/projects/xmap/sf_oak &amp ");*/
	} else if (accessible("/map" != "")) {
		/* in case this is running in xcfdemo */
		print("doing /xmap/ultrix.ws.2.1 /xmap/sf_oak &amp \n");
/*		system("/xmap/ultrix.ws.2.1 /xmap/sf_oak &amp ");*/
	} else {
		/* can't guess where xmap executables might be */
		bell(); /* later, use dialogbox */
	}
</S>

Unfortunately it doesn't work, in Viola no button was shown.

...


From wei@sting.Berkeley.edu Wed May 13 16:38:52 1992
Subject: Re:  World Wide Web and Viola
To: bloemer@helios.tnt.uni-hannover.de, timbl@nxoc01.cern.ch,
        wei@sting.Berkeley.edu

> 1. Is it possible to define pseudo hyperlinks which start a subprocess?
> That would be really phantastic because it allows for nice tutorials with
> trial buttons. On xcf.berkely.edu I saw:

> 	About XMap ... 
...
> 	<P>
> 	Click here for a demo.
> 	<S>/*script*/
> Unfortunately it doesn't work, in Viola no button was shown.

Whoops, I guess I really have to clean up the HTML files on our site :-)
Most of this stuff was for internal demonstrations, and the scripting 
stuff was an unfinished experiment. It doesn't work for you because you must 
have the demonstration Xmap program locally. But, yes, the intent of the 
<S> tag is to embed viola scripts in HTML, so that you can ``program links''
to do lots of complicated and neat things... In this case, the script 
tries to start up another process.

...

From timbl  Thu May 21 14:21:41 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10960; Thu, 21 May 92 14:21:41 GMT+0200
Date: Thu, 21 May 92 14:21:41 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9205211221.AA10960@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>
Subject: Program Links in WWW
Cc: www-talk@nxoc01.cern.ch



> I would like to know, whether anybody has extended WWW such, that it is possible
> to start arbitrary programs by hitting a button in a WWW browser.
>
> Hyberbole has this feature and it could also make WWW much more mighty.
>
> Included is a short discussion with Pei Y. Wei on this issue. >
> By the way, many thanks to Tim Berners-Lee in general, to Pei Y. Wei for his 

> wonderful violaWWW browser and to all people involved in the WWW project.
>
> Arnold

Very  good question. The problem is that of programming language. You need  
something really powerful, but at the same time ubiquitous. Remember a facet of the  
web is universal readership. There is no universal interptreted programming  
language. But there are some close tries. (lisp, sh).  You also need something  
which can run in a very safe mode, to prevent virus attacks.

Ideally, the language should include object-oriented inheritance, a basically  
functional nature, and a clean syntax. It should be interpretable and compilable.
At least one public domain. A pre-compiled standard binary form would be cool too.  
It isn't here yet.

In reality, what we would be able to offer you real soon now with document format  
negotiation is the ability to return a document in some language for execution,  
with the option of being able to provide it in several languages, the language  
being a "data format" which can be negotiated between client and server at  
run-time.  For, for example, one could provide it in viola script and/or in /bin/sh  
which would cover most ofthe unix world.

	Tim BL



From raisch@cthulhu.control.com  Thu May 21 18:53:00 1992
Return-Path: <raisch@cthulhu.control.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11993; Thu, 21 May 92 18:53:00 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06060; Thu, 21 May 92 18:51:25 +0200
Received: by control.com (4.1/Spike-2.0)
	id AA06599; Thu, 21 May 92 12:50:20 EDT
From: raisch@cthulhu.control.com (Robert Raisch)
Message-Id: <9205211650.AA06599@control.com>
Subject: Links and Type
To: www-talk@nxoc01.cern.ch
Date: Thu, 21 May 92 12:50:19 EDT
X-Mailer: ELM [version 2.3 PL11]

First of all, hearty congrats to the WWW people.  It's a great tool, and
since it is based on SGML, it has the broadest scope of any solution I have
yet seen.

To others, see the current issue of Byte magazine regarding "Info-Glut" and
SGML.  Interesting.

----------------------

I have a few recommendations regarding new link types in WWW.  This is based
on thinking about hyper-applications for almost 15 years, (ever since I 
first had the pleasure of hearing Ted Nelson speak in 1977.)

First though, there are a few ideas which I feel should be mentioned to 'set
the stage' for my list.

	Transparent Documents  --

		a transparent document is one which a user creates locally,
		and that is a new representation of an existant document.
		Transparent documents are used to create new local links on
		a document which I do not have permission to modify.

		Transparent documents can then be made available to others,
		(published) just as a "regular" document is, thus facilitating
		the creation of new works from old.

	User Documents --

		a user document is where I keep my "bookmarks", links to
		local documents, links to messages from others, links to
		my "attention" links, (see below).  User documents are where
		we, as navigators of the docuverse, are defined as individuals.

		They are also where we can keep links to other user documents
		which have been permitted to view/modify my own local documents.

		Another function of the User document is to collect users into
		an abstract group. (Thus, based on my membership in user 
		document 'Research Group', I am permitted access to materials
		'owned' by that group. Of course, messages sent to an abstract
		group then become available to all members of that group.)

		(Please note that a User Document is nothing more or less than
		 a collection of links, (as all documents are).)

------------------

Now, on to my list of link types....

There are 4 'minimal' link types which, I believe, a useful h-app *must* 
support.

	1.	Replacement
			-- when activated, replaces the current document
			   with a new document.

	2.	Annotation
			-- when activated, overlays a new document on the
			   current document, partially obscuring the original.

	3.	Inclusion
			-- when the document is created, elements from other
			   documents are collection to be included in the
			   representation of the current document.  (Quotes)

	4.	Expansion
			-- when activated, new information is added to the 
			   current document, expanding the original scope.
			   (Think of outline processors, and the collapse
			    of detail.)  This is also a reflection of
			   Nelson's concept of 'stretch text'.  (Stretch text
			   is where a sentence is constructed in such a 
			   way that when it is collapsed it states it's thesis 
			   in simple terms, and when expanded adds detail to
			   further express itself.

There are 3 further types which I believe are necessary to complete the
function paradigm.


	6.	Execution

			-- when activated, some arbitrary function is performed.
			   The point that was mentioned about the lack of an
			   ubiquitious scripting language is well made.  Lisp
			   is too arcane for most.  Shell languages are too
			   platform specific.  What is needed is a simple
			   to understand, freely available scripting platform.
			   Although I hesitate to mention it, REXX might be
			   a reasonable choice due to it's broad availability.

	5.	Attention   (a specialisation of the Execution type)

			-- when the current document is modified (a link is
			   added, or removed, or the document is merely read)
			   a message is sent to the 'owner' of the attention
			   link.  This message creates a new link in the 'user
			   document' of the individual who placed the attention.

			   In this way, I could place a link onto a document I 
			   had interest in, and when it was changed or accessed 			   in some manner, I would be informed.

	7.	Collection  (a non-local specialisation of the Execution type)

			-- when activated, a collection link leaves the current
			   document, and 'travels' the docuverse, in search of
			   other documents which satisfy it's internal criteria.
			   This is the concept of a 'knowbot'.

			   Collection links can be activated based on day and
			   time, much like the WAIS questions in the MAC 
			   WAIS interface, WAIS-Station.  They could also be
			   activated based on external events, such as the 
			   activation of an attention link.

			   Collection links would be written in the ubiquitious
			   scripting language, and would only be allowed to 
			   operate on documents which were EXPLICITLY permitted.


----------------------------


One of the missing pieces here is the ability of creating new h-texts, and 
adding new links to old h-texts.

Hypertext, and like systems, are of limited use if they do not support 
collaboration.  I feel that this is a VERY important point.


----------------------------

So.....

	Scenerio:

		I start my session with my h-app, and open my user
		document.

		I notice that 17 of my attention links have been activated 
		in the last day.

		I select the most interesting and activate the link which
		it created in my personal user document.

		I am now reading an article which I previously linked, and
		see that an annotation which I made some time ago has been
		added to, by a colleague.

		The comments are pertinant to my current work, so I create
		a new local 'transparent' document to mirror the original 
		work.

		On this new document, I make a few new annotations and decide
		to made this new work available to the research group of which
		I am leader.  I place a link to it in the user document which
		represents my working group.

		I also send a new document link to the colleague who made the
		original comments, so that he can see how I have interpreted 
		his ideas, and included them into my own research.

		I move ever onwards...

---------------------

Ok, I hope that that fuels a little discussion, and I would *love* to hear 
from others regarding these ideas.  

(Yes, some of what I have talked about here exists, in various forms, on my 
own personal system, but I would be *very* interested in hearing from 
developers who might be interested in making something real and useful from 
it.  I, sadly, have too little time to make these ideas real.  My ultimate
goal would be to make the realisation of these ideas available in the public
domain.)

Regards, /rr

"knowledge is the *only* weapon"
-- 

From emv@nigel.msen.com  Fri May 22 06:12:06 1992
Return-Path: <emv@nigel.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12915; Fri, 22 May 92 06:12:06 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10097; Fri, 22 May 92 06:10:38 +0200
Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0loQxU-000A6nC@nigel.msen.com>; Fri, 22 May 92 00:10 WET DST
Message-Id: <m0loQxU-000A6nC@nigel.msen.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>,
        www-talk@nxoc01.cern.ch
Subject: Re: Program Links in WWW 
In-Reply-To: Your message of Thu, 21 May 92 14:21:41.
             <9205211221.AA10960@ nxoc01.cern.ch > 
Date: Fri, 22 May 92 00:10:08 EDT
From: Edward Vielmetti <emv@msen.com>

the "atomicmail" work from bellcore / nat borenstein on a programming
language to embed in active mail messages sounds like what you want.
they have a patent on it :(.  ask nsb for details.  --Ed

From timbl  Mon May 25 16:40:01 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18996; Mon, 25 May 92 16:40:01 GMT+0200
Date: Mon, 25 May 92 16:40:01 GMT+0200
From: timbl (Tim Berners-Lee)
Message-Id: <9205251440.AA18996@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re: search engines & views
Cc: www-talk@nxoc01.cern.ch

>        All you do is map the parameters of the virtual search engine
>        onto a document name -- like
>
>        /INDEX/full-text/tryhard/depth=5/boolean
>
> Does this mean (at a primitive level) you could code a grep command
> as a document name?
>
	Yes -- sure.  Its a question of writing down the
	algorithm. In perl, I'm sure its a cinch ... you could
	also do it with sh and sed :-( but basically for example
	you need to take say

	/grep/mydir/i?joe+bloggs

	and turn that into

	grep -l -i "(joe)|(bloggs)" | awk -f ls2html.awk

where ls2html.awk looks something like:

	BEGIN {  print "Select one of:\n<MENU>" }
	{ printf "<LI><A HREF=./%s>   %s</A>\n", $1, $1 }
	END { print "</MENU>" }

The awk generates the HTML for a menu.  I guess you could use awk in fact to  
generate the grep command too.  But these are just ideas.  or are you using VMS?  
Yes, you could probably do it with DCL and SEARCH.

Of course if you can handle C, then hack the sample httpd.

> ///Peter

	Tim

From kim@usceast.cs.scarolina.edu  Mon May 25 18:05:56 1992
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19313; Mon, 25 May 92 18:05:56 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03674; Mon, 25 May 92 18:04:35 +0200
Received: from Relay.Prime.COM by mcsun.EU.net with SMTP
	id AA28869 (5.65b/CWI-2.163); Mon, 25 May 1992 18:04:29 +0200
Received: from usceast by Relay.Prime.COM; 25 May 92 12:04:48 EST
Return-Path: <kim@usceast.cs.scarolina.edu>
Received: by usceast.cs.scarolina.edu (cs.grandpoobah.043092)
From: Su-Hee Kim <kim@usceast.cs.scarolina.edu>
Message-Id: <9205251600.AA14397@usceast.cs.scarolina.edu>
Subject: Installation of viola
To: www-talk@nxoc01.cern.ch
Date: Mon, 25 May 92 12:00:50 EDT
Cc: kim@mcsun.eu.net (Su-Hee Kim)
X-Mailer: ELM [version 2.3 PL11]

	To whom it may  concern	

	I am trying to install your viola www package on my account,
not public.  When I make the Makefile, it gives me a message which says 
" don't know to make -lXmu''. The file libXmu.a is under the /usr/lib.
In the Makefile, there are many variables such as CONFIGSRC =
$(TOP)/config,  LIBSRC = $(TOP)/lib which are not available under my 
account.  Am I missing some?  I got ViolaWWW_920515.tar.Z from your
place.  I want to make this package run as soon as possible.        
	Thank You very much.




From wei@xcf.berkeley.edu  Tue May 26 02:47:31 1992
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19834; Tue, 26 May 92 02:47:31 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16395; Tue, 26 May 92 02:46:12 +0200
Received: by xcf.Berkeley.EDU (5.65/XCF-1.34)
	id AA21056; Mon, 25 May 92 17:46:02 -0700
Date: Mon, 25 May 92 17:46:02 -0700
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9205260046.AA21056@xcf.Berkeley.EDU>
To: kim@usceast.cs.scarolina.edu, www-talk@nxoc01.cern.ch
Subject: Re:  Installation of viola
Cc: kim@mcsun.eu.net

You should first run xmkmf to generate a Makefile that is specific to 
your system. 

If the resulting Makefile still gives you trouble, then manually change
the Makfile accordingly...

Ie: in my particular Makefile, you see
		...
        CONFIGSRC = $(TOP)/config
       DOCUTILSRC = $(TOP)/doc/util
        CLIENTSRC = $(TOP)/clients
          DEMOSRC = $(TOP)/demos
           LIBSRC = $(TOP)/lib
          FONTSRC = $(TOP)/fonts
       INCLUDESRC = $(TOP)/X11
        SERVERSRC = $(TOP)/server
		...

> "don't know to make -lXmu".  The file libXmu.a is under the /usr/lib.

So, change the LIBSRC line to something like:

           LIBSRC = /usr/lib

> I want to make this package run as soon as possible. I sent a
> mail regarding this problem to Dan. But I found that he is not there.

Cool. Have no idea who Dan is thou...

Mail me if you still have trouble setting it up.

-Pei

From timbl@www2.cern.ch  Tue May 26 16:01:05 1992
Return-Path: <timbl@www2.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21392; Tue, 26 May 92 16:01:05 GMT+0200
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04242; Tue, 26 May 92 15:59:45 +0200
Received: by  www2.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00465; Tue, 26 May 92 15:55:11 GMT+0100
Date: Tue, 26 May 92 15:55:11 GMT+0100
From: timbl@www2.cern.ch
Message-Id: <9205261455.AA00465@ www2.cern.ch >
Received: by NeXT Mailer (1.63)
To: John O'Neall <JON@frcpn11.in2p3.fr>
Subject: Making a simple file server for unix
Cc: www-talk@nxoc01.cern.ch

> Date:         Tue, 26 May 92 09:16:33 EST
> From: John O'Neall <JON@frcpn11.in2p3.fr>

John,

Thanks for your mails asking about how to make a simple hypertext  
list of files. 


Let me take your model of the three layers. I sugest that the 1st  
layer

>helppage (1st-layer):  various info and pointers to local
>         info that won't change much as well as to WWW proper.
>         Among other things, it'll point to a [...]

you write by hand.  You can read the HTML documentation in    
http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
or you can just copy another node which looks like what you want.   
(Get its address and then read it with www -source address). Or both.

You might want to put pointers to the general subject index, and the  
index of HEP sites.  Let me know when you set up a server so that I  
can put in on the list!

For the second layer,

> 2nd-layer list:  this is the thing that will point to ALL the
>    local flat files.  Then I need an automatic (cron'd) procedure
>    to regenerate the list every time I add more flat data
>     files (or periodically).


This is easy: you generate it with a little shell script. How about  
the one appended to this message?  It generates a hypertext menu of  
files in a set of directories (passed as arguments). You can massage  
it to put in your own title, heading, etc. If you can generate some  
human-readable description of each file, so much the better.  You  
could run this as a cron job into an Overveiw.html file which you  
then publish with httpd, or run it from a server daemon script so  
that the list is generated fresh for every read, and always  
up-to-date.

The third layer is your set of files.  If you publish these with a  
server script, you can add to each one a title (if you can generate  
it) and maybe a link back to the list of other documents befre you  
just send the plain text file.

You could read some of the tips on the web about ettiquette, etc.

>By the way, if such a list already exists in W3 somewhere, I'll be
>happy to point to it too.  And then there's no reason why our server
>shouldn't be accessible to the rest of W3.

It would be a great addition to the web!  Let me know when it's up  
and I'll put pointers to it from some overview documents. (evn at the  
experimental stage, I'll mark the links "experimental" if you like).

>Tim, any chance of getting the hypertext editor for something other
>than Next one day?  I realize that was the simplest thing to develop
>it on, but I suspect it's not the commonest workstation in HEP.

It's on the "hit-list" and we're lookig for volunteers. Maybe the Mac  
browser will be the first to be also an editor. Or maybe one of hte X  
browsers.  I agree the NeXT is not the most common platform! (Though  
it is neat ;-)

>Excuse me for rushing, but I'm supposed to present this project to  
the
>HEPIX-F meeting in Paris on Tuesday and this weekend will be a long  
one
> (at least, in France).

Good luck! Mail cailliau@(I'm off to the US -- so I'm rushing too!)

Mail me or www-talk@info.cern.ch if you have any problems... 


If you have smart ideas, circulate them to this list too.

	Tim

__________________

#! /bin/sh
# Generate hypertext menu from directory list
echo "<TITLE>Information under: $*</TITLE>"
echo "<H1>$*</H1>"
# If there is a README file include that as plain text
if [ -f $1/README ]; then
    echo "<XMP>"
    cat $1/README
    echo "</XMP>"
fi
# Now generate a list of links to files
echo "<DIR>"
for dir in $*
do (
    cd $dir
    for file in *.html *.txt
    do 

	echo "<LI><A HREF=./$dir/$file>Title of $file</A>" 

    done
    )
done
echo "</DIR>"


From jfg@dxcern.cern.ch  Wed Jun  3 10:13:46 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06062; Wed, 3 Jun 92 10:13:46 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13620; Wed, 3 Jun 92 10:11:44 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA01209; Wed, 3 Jun 92 10:11:30 +0200
Date: Wed, 3 Jun 92 10:11:30 +0200
Message-Id: <9206030811.AA01209@dxcern.cern.ch>
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Sender: jfg@dxcern.cern.ch
To: Craig A. Summerhill <craig@cni.org>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Just a question
References: <9205272153.AA19773@a.cni.org>

>>>>> On Wed, 27 May 92, Craig A. Summerhill <craig@cni.org> was worried:

Craig> What happened to the hacker's dictionary that used to be on WWW?
Craig> I can't seem to find it anymore.  It was a good resource... :*)

  The hacker's dictionary that once was on the default home page was a
demonstration of Hyper-G, a hypertext system developed by Frank Kappe
and others at the University of Graz, Austria. Hyper-G is now fully
operational and includes much more information than just the hacker's
jargon. We have a pointer to it on the list of W3 servers. There is
also a direct pointer to the hacker's jargon from the list of academic
information, under `Computing'. You will find that the presentation
has changed. For reference, the UDIs to Hyper-G and the Hacker's
Jargon are http://iicm.tu-graz.ac.at:80/ROOT and
http://iicm.tu-graz.ac.at:80/Cjargon

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"In general, it is safe and legal to kill your children and their children"
-POSIX Prg Gt, by Donald Lewine, O'Reilly & Associates, 1991, p.110
(On process termination)


From jfg@dxcern.cern.ch  Wed Jun  3 10:13:12 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06058; Wed, 3 Jun 92 10:13:12 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13602; Wed, 3 Jun 92 10:11:16 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA01201; Wed, 3 Jun 92 10:11:11 +0200
Date: Wed, 3 Jun 92 10:11:11 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206030811.AA01201@dxcern.cern.ch>
To: www@nxoc01.cern.ch, www-talk@nxoc01.cern.ch, www-interest@nxoc01.cern.ch
Subject: Mailing list problems

  An error of configuration has prevented recent messages from being
broadcast to the list. Also, many new addresses that we collected were
wrong. My apologies to those who tried to post and received loads of
bounces. If you come to Geneva, I'll owe you a drink :-) Everything
should work fine now, and I'll re-post the messages that I know of.

  I'd like to take the opportunity of this administrative message to
ask for your cooperation: if you know a valid address for one of the
people mentioned below, please mail it to me. They have been removed
for now...

kova!floss
Elizabeth Porteneuve CNET CRPE Net Mgr -- JENC92 <porteneu@frcrpe61.bitnet>
Ermanno Polli - INFN Frascati - AIHEP-92 <polli@lnf.infn.it>
Marc de Lyon -- JENC92 <Marc.deLyon@ica.Rulimberg.nl>
John McMillan - Univ. Leeds - AIHEP-92 <phybjem@sun.leeds.ac.uk>
Gottfried Mayer-Kress <gmk@pegasos.ucsc.edu>

  Your devoted list manager,

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"The future will be better tommorrow."  -- Dan Quayle


From jkp@lusmu.cs.hut.fi  Wed Jun  3 19:10:23 1992
Return-Path: <jkp@lusmu.cs.hut.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09993; Wed, 3 Jun 92 19:10:23 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19336; Wed, 3 Jun 92 19:08:25 +0200
Received: from lusmu.cs.hut.fi by mcsun.EU.net with SMTP
	id AA06080 (5.65b/CWI-2.165); Wed, 3 Jun 1992 17:58:45 +0200
Received: by lusmu.cs.hut.fi id AA18097
  (5.65c8/HUTCS-C-91-07 for www-talk@nxoc01.cern.ch); Wed, 3 Jun 1992 18:57:19 +0300
Date: Wed, 3 Jun 1992 18:57:19 +0300
Message-Id: <199206031557.AA18097@lusmu.cs.hut.fi>
From: Jyrki Kuoppala <jkp@cs.hut.fi>
Sender: jkp@lusmu.cs.hut.fi
To: www-talk@nxoc01.cern.ch
Subject: Virtual newsgroups and creating the memory of Usenet via www and wais 
Organization: Helsinki University of Technology, Finland.

Here's an article I sent a while ago to various Usenet newsgroups:

>With the enormous numbers of groups now existing, tracking
>through all of them to find interesting and relevant topics
>is becoming very hard, and it seems clear that the namespace
>is becoming hopelessly muddled by democracy in action, so
>a software solution might be the only way out. 

An idea just popped up in my head.

Currently we have a news gateway to www (a www client can be used as a
newsreader), which helps to organized groups better than the flat
namespace of the newsgroups most other newsreaders seem to have.  Ie. you
create www nodes which have topically similar newsgroups listed
together in a node and hypetext links to those newsgroups.  Each user
can make personal nodes having the groups or use ones someone else has
published on the net.

Now, as www works very well with dynamic node creation (which is the
way the nntp and wais gateways work), to have a "virtual newsgroup"
you would just instead of having a link to a "real" newsgroup in a www
node have a link to a FIND node with suitable keywords, and then wais
would be used to search the articles mathing the find criteria and
would create a virtual node for the matches, like the nntp gateway
currently creates a virtual node with the current contents of a real
Usenet group.

As the www news client / gateway already has the capability to follow
links to earlier dicussions (References: field), following the tree
from the virtual newsgroups would be easy.  For more usability, the
www / news gateway (or the news system) should also create forward
references, ie. to backtrack the References field when new articles
come in and thus keep track of articles which are comments to a
certain article.

To apply the same principles to other newsreaders, nntp should be
extended to have the "newsgroup" instead be a "search criteria", which
would be interpreted by the wais (or some other search engine) server
and transparent to nntpd (except if it's the old-fashioned newsgroup
name).  People would have the search criteria - keywords from the
text, poster names, whatever - in their .newsrc files alongside with
the newsgroup names.

I'm not sure how to keep track of what articles the user has already
read, as there are no article numbers for the virtual groups.  Keeping
track of message IDs takes a lot of space.  But even as a browsing
tool it would be nice.

Hmm, come to think of it to combine a wais server indexing the news
database with the www / nntp gateway seems like the obvious thing to
do, so somebody must have done it already?

Also, are there any anonymous nntp servers which function as archives
for some or all of the groups, ie have long-term storage available by
nntp?  CD-ROM online or something.  With the www news gateway and some
minor modifications for some purposes saving an interesting article to
local disk would be unnecssary, instead just the message ID would be
saved (or added to a node on an organized www document so one could
find it later) and the article could later be found on a generic nntp
archive.  To save bandwidth and avoid single points of failure the
nntp archive could be a distributed database with servers on various
parts of the world and cooperation and caching between them - the
servers could compute a hash from the message ID and archive a certain
percentage of the article.  With some coordination the burden of disk
space could be shared so there needn't be one gigantic nntp archive.

//Jyrki

From davis@willow.tc.cornell.edu  Wed Jun  3 21:56:06 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12314; Wed, 3 Jun 92 21:56:06 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02089; Wed, 3 Jun 92 21:54:17 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA29791; Wed, 3 Jun 92 15:56:01 EDT
Date: Wed, 3 Jun 92 15:56:01 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206031956.AA29791@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: HTML and bitmaps

I would like to include non-text data (e.g. bitmaps, sound)
in my hyperdocuments.

One way to do this would be:

1) extend HTML to allow for such data, e.g.  a tag like
<BITMAP height=100 width=100 encoding=FAXG4>

(I think the WWW protocols would require that the data be uuencoded,
since I don't think they will allow 8bit data)

2) extend Viola (my WWW browser of choice) to recognize
this tag and do the right thing with it, i.e. uudecode it then
start a display program (or place the bitmap into the
document)

A related generalization would be if the browsing program were able to
choose among a set of alternative display programs based on the "type"
of the document linked to.  In this case, I could have an anchor
that pointed to a bitmap file in addition to (or instead of) placing
bitmaps within HTML files.

This sort of thing is possible in both WAIS and MetaMail.  In document
has a type known to the WAIS server, the client inspects this type and
selects a display program according to the values in the Xwais.filters
X resource; In MetaMail each piece of mail is labeled with an explicit
type; MetaMail consults the mailcap file to determine how to display
each type.

I see that anchors in WWW can have a TYPE attibute, but I can't tell
whether this is the type of the link or of the thing linked to.  If
the former, then I see no easy way to do it in WWW, short of adding
the facility to Viola to decide the document type by inspecting it
(e.g. looking for magic header bits which at least some data formats
support.)

I would be grateful for your comments on this matter.

best wishes

From davis@willow.tc.cornell.edu  Wed Jun  3 21:57:49 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12337; Wed, 3 Jun 92 21:57:49 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02217; Wed, 3 Jun 92 21:55:59 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA29814; Wed, 3 Jun 92 15:57:46 EDT
Date: Wed, 3 Jun 92 15:57:46 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206031957.AA29814@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: WWW vs DynaText

The current issue of Byte has an article on electronic books
written by two folks from the Electronic Book Technologies
company of Providence, RI, USA.  These folks sell a system
called DynaText which delivers electronic books including hypertext
using SGML.  

Can anyone compare this system with WWW?

From timbl  Wed Jun  3 22:45:52 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13287; Wed, 3 Jun 92 22:45:52 MET DST
Date: Wed, 3 Jun 92 22:45:52 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206032045.AA13287@ nxoc01.cern.ch >
To: davis@willow.tc.cornell.edu, www-talk@nxoc01.cern.ch
Subject: Re: WWW vs DynaText
Cc: timbl

When we looked at dynatext, about a year ago, it was a system which
built (like compiled) a bunch of already written SGML into a "book"
which ould be scanned on-line. The book was kept in some dynatxtext-special
form, with indexes etc. It did not parse SGML on the fly as W3 does.

There is no client-server protcol to dynatext, so you ahve to have the
"book" mounted by NFS say where you want to read it.

A strange thing was that if you made some incremental
change to the underlying SGML then you had to remake the
whole book. The licencing was by the number of books
you made, so every time you reran "make book" or whatever it
was called, you had you rlicense edcremented by one.

I think there is a bit of a review about in on the web... try
www   http://info.cern.ch/hypertext/Products/DynaText/Overview.html
which Ifound by a link from
  http://info.cern.ch/hypertext/Products/Overview.html

Dynatext may have improved since we tried it. The mail
addreses of peopl einvolved are linked to those documents.

Hope this helps.

Tim BL
 PS: It was more like 2 years ago.

From jfg@dxcern.cern.ch  Fri Jun  5 19:55:55 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06212; Fri, 5 Jun 92 19:55:55 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12751; Fri, 5 Jun 92 19:53:57 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA03322; Fri, 5 Jun 92 19:53:52 +0200
Date: Fri, 5 Jun 92 19:53:52 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206051753.AA03322@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML and bitmaps
References: <9206031956.AA29791@willow.tc.cornell.edu>

  One more comment on this: 

> (I think the WWW protocols would require that the data be uuencoded,
> since I don't think they will allow 8bit data)

  WWW can inherently use several protocols to fetch data. Some of them
may be limited to 7-bit characters, but the WWW architecture itself is
designed with full 8-bit bytes. In particular, the HTTP protocol that
we have defined supports 8-bit data. However, HTML, our language for
describing hypertext, is based on SGML which is essentially a 7-bit
construct (actually, it can only handle a predefined set of characters).

  Your impression may come from the fact that in the current
implementation, as HTTP can only return HTML documents, the
distinction between them is not clear. The new phase of HTTP that we
are currently designing will be able to handle documents of arbitrary
types. These documents are then processed by the client program
depending on its own capabilities, with the possible help of external
converters or applications, much like the Xwais.filters stuff.

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
Engineers  think that theory  approximates reality.   |   Mathematicians never
Physicists think that reality approximates theory.    |   make the connection.

From connolly@pixel.convex.com  Sat Jun  6 07:56:12 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07371; Sat, 6 Jun 92 07:56:12 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16481; Sat, 6 Jun 92 07:54:08 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA24856; Sat, 6 Jun 92 00:53:24 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23369; Sat, 6 Jun 92 00:53:21 -0500
Message-Id: <9206060553.AA23369@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=-
Subject: MIME as a hypertext architecture
Date: Sat, 06 Jun 92 00:53:20 CDT
From: Dan Connolly <connolly@pixel.convex.com>

NOTE: This message uses existing and proposed MIME structuring
conventions. Some parts of it may look strange on pre-MIME viewers.

---

The WWW project needs an architecture for interchange of structured
multimedia hypertext documents. The original architecture, HTML,
introduced some structuring conventions and a way of specifying
hypertext links.

The HTML format is under stress from several issues:
	* We need an SGML DTD so that we can parse HTML using
	something besides the public implementation of WWW, and so that
	we can verify documents converted from other authoring
	systems such as GNU info, Andew's EZ, or FrameMaker.

	* We need to be able to distribute documents and document
	elements in other formats, including raw 8 bit data streams.
	The SGML NOTATION feature falls short of providing and
	adequate mechanism.

	* The UDI syntax doesn't match the SGML attribute syntax.
	There are problems with quoting out-of-band characters, and
	the length of complex UDI's may exceed SGML limits and/or
	line-length limits of transport mechanisms. Also, the
	terse syntax of UDI's conflicts with the goal that they
	be human-readable.

This is a proposed architecture for global hypertext, addressing
the issues raised by the WWW project, but using the MIME architecture.

We define a new subtype of the MIME multipart content type called
x-HTDOC. The syntax is the same as multipart/mixed, but the semantics
are that of a WWW client: the first part is displayed, and the rest
represent links to other documents or other elements of this document.

Then we define a new subtype of the MIME text content type called
x-HTML. This is an SGML markup language using the default SGML declaration
(i.e. the reference concrete syntax, default processing limits, etc.)
and the HTML DTD (included below).

---

<!-- This DTD was produced by DeveGram on Tue Jun  2 18:58:16 1992 -->
<!-- and hand-edited by connolly@convex.com -->

<!--     Parameter Entities       -->

<!--      Terminal symbols        -->

<!ENTITY % words "#PCDATA" >

<!--    Non-ELEMENT symbols       -->

<!ENTITY % inline	"%words | A" >
<!ENTITY % text         "%inline | P" >
<!ENTITY % heading "H1|H2|H3|H4|H5|H6" >

<!ENTITY lt "<">
<!ENTITY gt ">">
<!ENTITY amp "&">

<!ENTITY lt. "<">
<!ENTITY gt. ">">
<!ENTITY amp. "&">

<!--     Document structure       -->

<!ELEMENT html	O O  (TITLE, NEXTID?, ISINDEX?, section+, ADDRESS?)>

<!ELEMENT TITLE	- -  (%inline)+>
<!ELEMENT ADDRESS - - (%text)+>

<!ELEMENT NEXTID - O EMPTY >
<!ATTLIST NEXTID N NUMBER #IMPLIED>

<!ELEMENT ISINDEX - O EMPTY >


<!ELEMENT section O O ((%heading)?,
			(
			%text |
			section |
			MENU |
			UL |
			OL |
			DIR |
			DL)+)>

<!ELEMENT (H1|H2|H3|H4|H5|H6)	- -  (%inline) >

<!ELEMENT P	- O  EMPTY -- paragraph SEPARATOR -->


<!ELEMENT A	- -  (%inline)+>
<!ATTLIST A
	NAME CDATA #IMPLIED
	PART ENTITY #IMPLIED >

<!ELEMENT MENU	- -  (LI+)>

<!ELEMENT UL	- -  (LI+)>

<!ELEMENT OL	- -  (LI+)>

<!ELEMENT DIR	- -  (LI+)>

<!ELEMENT LI	- O  (%text)+>

<!ELEMENT DL	- -  ((DT, DD)+)>

<!ELEMENT DT	- O  (%inline)+>

<!ELEMENT DD	- O  (%text)+>

---

An HTML document would use external entities to reference other parts
of the multipart message. The system identifier matches the
Content-Id field of the intended part. The content-type of the indicated
part could be image, audio, or video for multimedia inclusions; text for
quotes etc., or message/external-body for references to other documents.

MIME defines access-types for local-file and anon-ftp. We could define
x-HTTP, x-NEWS, x-WAIS, and the other UDI access types.

Within HTML documents, SGML IDREFs and IDs are used to reference and define
elements of a document. (I think HYTIME defines a way to reference elements
without explicit IDs.)


The next part of this message is a default.html from the WWW
distribution adapted to use the conventions here.

It should interoperate with existing MIME systems,
though they will not be able to do anyting intelligent with HTML.

---
Content-Type: multipart/x-HTDOC; boundary=cut-here

--cut-here
Content-Type: text/x-HTML

<!DOCTYPE HTML SYSTEM 
[
<!ENTITY part1 SDATA "QuickGuide.html">
<!ENTITY part2 SDATA "http://info.cern.ch/hypertext/WWW/TheProject.html">
<!ENTITY part3 SDATA "http://crnvmc.cern.ch./WHO">
<!ENTITY part4 SDATA "http://crnvmc.cern.ch./FIND/yellow?">
<!ENTITY part5 SDATA "http://crnvmc.cern.ch./FIND/jaune?">
<!ENTITY part6 SDATA "http://crnvmc.cern.ch./FIND">
<!ENTITY part7 SDATA "http://crnvmc.cern.ch/NEWS/?">
<!ENTITY part8 SDATA "http://crnvmc.cern.ch./NEWS/cern">
<!ENTITY part9 SDATA "http://crnvmc.cern.ch./NEWS/vmnews">
<!ENTITY part10 SDATA "http://crnvmc.cern.ch/NEWS/student">
<!ENTITY part11 SDATA "http://info.cern.ch/hypertext/DataSources/NewsFromVM/Overview.html">
<!ENTITY part12 SDATA "http://info.cern.ch/hypertext/DataSources/News/Overview.html">
<!ENTITY part13 SDATA "http://info.cern.ch/hypertext/DataSources/bySubject/Overview.html">
<!ENTITY part14 SDATA "http://info.cern.ch./hypertext/DataSources/Overview.html">
<!ENTITY part15 SDATA "http://slacvm.slac.stanford.edu./FIND/spires">
<!ENTITY part16 SDATA "http://crnvmc.cern.ch/FIND/DESY?">
<!ENTITY part17 SDATA "http://info.cern.ch:8001/archive.orst.edu:9000/archie-orst.edu">
<!ENTITY part18 SDATA "http://iicm.tu-graz.ac.at./jargon">
<!ENTITY part19 SDATA "http://info.cern.ch./hypertext/Products/WAIS/Sources/Overview.html">
<!ENTITY part20 SDATA "http://info.cern.ch/rpc/doc/User/UserGuide.html">
<!ENTITY part21 SDATA "http://otax.tky.hut.fi/tky/default.html">
<!ENTITY part22 SDATA "gopher://gopher.micro.umn.edu:70/11/Other%20Gopher%20and%20Information%20Servers">
<!ENTITY part23 SDATA "http://info.cern.ch./hypertext/WWW/LineMode/Defaults/default.html">
]>
<TITLE>CERN Information</TITLE>
<NEXTID N=10>
<SECTION><H1>CERN Information - Select by number</H1>
<DL>
<DT><A PART="part1">Help</A>
<DD>On this program, or the
<A PART="part2">World-Wide Web project</A>.
<DT><A PART="part3" NAME=2>Phone book</A>
<DD>People, phone numbers, accounts and email addresses.
See also the analytical
<A PART="part4" NAME=yellow>Yellow Pages</A>, or
the same index in French :
<A PART="part5" NAME=jaune>Pages Jaunes</A>.
<DT><A PART="part6" NAME=1>"XFIND" index</A>
<DD>Index of computer centre documentation, newsletters, news,
help files, etc...
<DT><A PART="part7" NAME=groups>News</A>
<DD>A complete list of all public CERN news groups, such as
<A PART="part8" NAME=3>news from the CERN User's
Office</A>,<A PART="part9" NAME=4>
CERN computer center news</A>,<A PART="part10">
student news</A>. See also <A PART="part11" NAME=5>private
groups</A> and <A PART="part12" NAME=inews>Internet
news</A>.
</dl>
</section>
<section>
<SECTION><H2>From other sites</h2>
See online data by
<A PART="part13" NAME=subject>subject</A>,
pointers to
<A PART="part14">other forms of online data</a>, and the following specific databases:
<DL>
<DT><A PART="part15" NAME=spires>SLAC SPIRES</A>
<DD>The High Energy Physics preprint index at Stanford Linear Accelerator, California.
(This is the same information avialable via the QSPIRES facility on BITNET.
Include the word "FIND" as the first keyword, eg: K FIND AUTHOR FRED.).
<DT><A PART="part16" NAME=desy>DESY documents</a>
<DD>Documents and help files from the DESY lab in Hamburg.
<DT><A PART="part17" NAME=archie>
Archie</a>
<DD>An index of almost everything available by "anonymous FTP".
<DT><A PART="part18" NAME=7>Hacker Jargon</a>
<DD>An index to a cross-referenced set of hacker terms. A demonstration
of the WWW gateway to the Graz Technical University Hyper-G database.
<DT><A PART="part19" NAME=9>W.A.I.S.</a>
<DD>All kinds of information available from "Wide Area Information Servers".
<DT><A PART="part20" NAME=6>CERN RPC</A>
<DD>The user guide for the RPC system developed in CERN CN division
(not Sun/RPC). This is an example of documentation (partially) converted
into hypertext.
<DT><A PART="part21" NAME=hut>Helsinki</a>
<DD>Helsinki Technical University information service (Mostly Finnish).
<DT><A PART="part22" NAME=gopher>Gophers</a>
<DD>Campus-wide information systems using "Gopher" software. (Requires www version 1.1 or higher)
</DL>
(This page may be an out of date copy. See the
<A PART="part23" NAME=latest>latest version</a>.)

--cut-here
Content-id: QuickGuide.html
Content-type: message/external-body
	;access-type=x-relative
	;name="QuickGuide.html"

Content-Type: message


--cut-here
Content-id: http://info.cern.ch/hypertext/WWW/TheProject.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch
	;name=/hypertext/WWW/TheProject.html

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch./WHO
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch.
	;name=/WHO

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch./FIND/yellow?
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch.
	;name=/FIND/yellow?

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch./FIND/jaune?
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch.
	;name=/FIND/jaune?

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch./FIND
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch.
	;name=/FIND

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch/NEWS/?
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch
	;name=/NEWS/?

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch./NEWS/cern
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch.
	;name=/NEWS/cern

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch./NEWS/vmnews
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch.
	;name=/NEWS/vmnews

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch/NEWS/student
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch
	;name=/NEWS/student

Content-Type: message


--cut-here
Content-id: http://info.cern.ch/hypertext/DataSources/NewsFromVM/Overview.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch
	;name=/hypertext/DataSources/NewsFromVM/Overview.html

Content-Type: message


--cut-here
Content-id: http://info.cern.ch/hypertext/DataSources/News/Overview.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch
	;name=/hypertext/DataSources/News/Overview.html

Content-Type: message


--cut-here
Content-id: http://info.cern.ch/hypertext/DataSources/bySubject/Overview.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch
	;name=/hypertext/DataSources/bySubject/Overview.html

Content-Type: message


--cut-here
Content-id: http://info.cern.ch./hypertext/DataSources/Overview.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch.
	;name=/hypertext/DataSources/Overview.html

Content-Type: message


--cut-here
Content-id: http://slacvm.slac.stanford.edu./FIND/spires
Content-type: message/external-body
	;access-type=x-HTTP
	;site=slacvm.slac.stanford.edu.
	;name=/FIND/spires

Content-Type: message


--cut-here
Content-id: http://crnvmc.cern.ch/FIND/DESY?
Content-type: message/external-body
	;access-type=x-HTTP
	;site=crnvmc.cern.ch
	;name=/FIND/DESY?

Content-Type: message


--cut-here
Content-id: http://info.cern.ch:8001/archive.orst.edu:9000/archie-orst.edu
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch
	;port=8001
	;name=/archive.orst.edu:9000/archie-orst.edu

Content-Type: message


--cut-here
Content-id: http://iicm.tu-graz.ac.at./jargon
Content-type: message/external-body
	;access-type=x-HTTP
	;site=iicm.tu-graz.ac.at.
	;name=/jargon

Content-Type: message


--cut-here
Content-id: http://info.cern.ch./hypertext/Products/WAIS/Sources/Overview.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch.
	;name=/hypertext/Products/WAIS/Sources/Overview.html

Content-Type: message


--cut-here
Content-id: http://info.cern.ch/rpc/doc/User/UserGuide.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch
	;name=/rpc/doc/User/UserGuide.html

Content-Type: message


--cut-here
Content-id: http://otax.tky.hut.fi/tky/default.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=otax.tky.hut.fi
	;name=/tky/default.html

Content-Type: message


--cut-here
Content-id: gopher://gopher.micro.umn.edu:70/11/Other%20Gopher%20and%20Information%20Servers
Content-type: message/external-body
	;access-type=x-gopher
	;site=gopher.micro.umn.edu
	;port=70
	;type=11
	;selector="Other Gopher and Information Servers"

Content-Type: message


--cut-here
Content-id: http://info.cern.ch./hypertext/WWW/LineMode/Defaults/default.html
Content-type: message/external-body
	;access-type=x-HTTP
	;site=info.cern.ch.
	;name=/hypertext/WWW/LineMode/Defaults/default.html

Content-Type: message
--cut-here--

---

Here's the perl script I used to convert default.html into
the above message. It's full of gross hacks, but it worked
this evening.

---

#!/usr/local/bin/perl

print "Content-Type: multipart/x-HTDOC; boundary=cut-here\n\n";
print "--cut-here\n";
print "Content-Type: text/x-HTML\n\n";
print "<!DOCTYPE HTML SYSTEM \n[\n";

$o = 0;
$/ = ">";

while(<>){
    s/(<A[^>]*>)/&fix_anchor($1)/ige;
    s/<NEXTID\s*(\d*)\s*>/<NEXTID N=$1>/g;
    if(/<H(\d)/){
	local($n) = $1;
	if($n>$o) { $rep = "<SECTION>"; }
	else { $rep = "</SECTION><SECTION>"; }
        s/(<H\d)/$rep$1/g;
	$o = $n;
    }
    $doc .= $_;
}

@entities = @anchors;
while(@entities){
    local($id) = shift(@entities);
    local($_) = shift(@entities);
    local($name) = shift(@entities);
    local($type) = shift(@entities);

    print "<!ENTITY part$id SDATA \"$_\">\n";
}

print "]>\n", $doc;

while(@anchors){
    local($id) = shift(@anchors);
    local($_) = shift(@anchors);
    local($name) = shift(@anchors);
    local($type) = shift(@anchors);
    local($access_type);

    print "\n\n--cut-here\n";
    print "Content-id: $_\n";
    print "Content-type: message/external-body\n";

    $access_type = $1 if s/^(\w+)://;
    if(s/#([^#]+)$//){
	print "\t;x-element-id=\"$1\"\n";
    }

    if($access_type =~ /file/i){
	print "\t;access-type=LOCAL-FILE\n";
	print "\t;name=$_\n";
    }elsif($access_type =~ /http/i){
	print "\t;access-type=x-HTTP\n";
	if(s-//([^:/]+)--){
	    print "\t;site=$1\n";
	    print "\t;port=$1\n" if s/^:(\d+)//;
	}
	&unescape;
	print "\t;name=$_\n";
    }elsif($access_type =~ /news/i){
	print "\t;access-type=x-news\n";
	&unescape;
	if(/@/){
	    print "\t;message-id=$_\n";
	}else{
	    print "\t;group=$_\n";
	}
    }elsif($access_type =~ /telnet/i){
	print "\t;access-type=x-telnet\n";
	&unescape;
	print "\t;user=$1\n" if s/^(.*)@//;
	print "\t;port=$1\n" if s/:(.*)$//;
	print "\t;site=$_\n";
    }elsif($access_type =~ /gopher/i){
	print "\t;access-type=x-gopher\n";
	if(s-^//([^:/]+)--){
	    print "\t;site=$1\n";
	    print "\t;port=$1\n" if s/:(\d+)//;
	}
	print "\t;type=$1\n" if s-^/(\d+)/--;
	&unescape;
	print "\t;selector=\"$_\"\n";
    }elsif($access_type =~ /wais/i){
	print "\t;access-type=x-wais\n";
	if(s-//([^:/]+)--){
	    print "\t;site=$1\n";
	    print "\t;port=$1\n" if s/:(\d+)//;
	}
	if(m-^/-){
	    print "\t;type=$1\n" if s-^/(\w+)--;
	    print "\t;size=$1\n" if s-^/(\d+)--;
	    &unescape;
	    print "\t;path=\"$_\"\n";
	}else{
	    &unescape;
	    print "\t;words=\"$1\"\n" if /\?(.*)/;
	}
    }elsif($access_type eq ""){
	print "\t;access-type=x-relative\n";
	&unescape;
	print "\t;name=\"$_\"\n";
    }else{
	warn "unknown access type: $access_type in $_";
    }

    print "\nContent-Type: message\n";
}

print "--cut-here--\n";

sub unescape{
    s/%(\w\w)/sprintf("%c",hex($1))/ge;
}

sub fix_anchor{
    local($_) = @_;
    local($name, $href, $type);
    $href = $1 if /HREF\s*=\s*(\S+)/i;
    return $_ unless $href;
    $href =~ s/>$//;

    $name = $1 if /NAME\s*=\s*(\S+)/i;
    $type = $1 if /TYPE\s*=\s*(\S+)/i;

    $content_id{$href} = $content_id++ unless $content_id{$href};
    push(@anchors, $content_id, $href, $name, $type);
    local($ret) = "<A PART=\"part$content_id\"";
    $ret .= " NAME=$name" if $name;
    $ret .= ">";
    return $ret;
}

-----

From connolly@pixel.convex.com  Sun Jun  7 06:37:07 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09218; Sun, 7 Jun 92 06:37:07 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07900; Sun, 7 Jun 92 06:35:09 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA11346; Sat, 6 Jun 92 23:34:53 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA08877; Sat, 6 Jun 92 23:34:50 -0500
Message-Id: <9206070434.AA08877@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: <ISINDEX> and anchor types
Date: Sat, 06 Jun 92 23:34:49 CDT
From: Dan Connolly <connolly@pixel.convex.com>

Just a note: I prefer gopher's model of interaction when it
comes to index nodes. Rather than having a special <ISINDEX>
tag and a "find" command, have a different anchor type. The
user first chooses the "search this index" anchor; then, to
follow an index anchor link, the client prompts for the
query details and makes the query.

Seems cleaner, simpler, and more flexible.

Dan

From connolly@pixel.convex.com  Sun Jun  7 07:15:06 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09233; Sun, 7 Jun 92 07:15:06 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10393; Sun, 7 Jun 92 07:13:11 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12453; Sun, 7 Jun 92 00:12:57 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA17832; Sun, 7 Jun 92 00:12:55 -0500
Message-Id: <9206070512.AA17832@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML is not SMGL
Date: Sun, 07 Jun 92 00:12:55 CDT
From: Dan Connolly <connolly@pixel.convex.com>

My grandiose scheme to convert HTML to MIME and SGML
works fine.

Now I'm going back to the idea of writing a DTD for
the existing HTML format. I can't seem to do it.
HTML has so little rigid structure that I'm running
into mixed content problems (I have to allow #PCDATA
almost anywhere, hence mixed content, which screws
up everything).

How much extant HTML is really out there? And how
much of it is generated on the fly by gateways
and servers?

This MIME/SGML stuff sure seems like the way to go.

Now if I make it possible to create such documents
with FrameMaker and a perl script, I bet it will
catch on. I suspect I'll get some resistance against
abandoning UDI's, but I don't think they work.

Dan

From connolly@pixel.convex.com  Sun Jun  7 08:20:25 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09268; Sun, 7 Jun 92 08:20:25 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14076; Sun, 7 Jun 92 08:18:31 +0200
Received: from convex-inet.convex.com by mcsun.EU.net with SMTP
	id AA06010 (5.65b/CWI-2.167); Sun, 7 Jun 1992 08:18:19 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA14512; Sun, 7 Jun 92 01:15:38 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA15478; Sun, 7 Jun 92 01:15:36 -0500
Message-Id: <9206070615.AA15478@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: overkill on portability macros
Date: Sun, 07 Jun 92 01:15:34 CDT
From: Dan Connolly <connolly@pixel.convex.com>

Are these abuses of the preprocessor really necessary?

----
PRIVATE char from_hex ARGS1(char, c)
{
}
----
Ok, I've seen PRIVATE before (though I don't know what it's
for. Some sort of MS DOS near/far thing?)

But ANSI C and PCC share syntax for _defining_ functions.
The preprocessor dancing is necessary for _declaring_ functions
like so:

int foo __ARGS__((int x, int y, int z));

but in the .c files, you can just do the usual

int foo(x,y,z)
int x;
int y;
int z;

and ANSI an PCC compilers alike will be happy, with one
exception: varargs. Functions with

int foo(int x, ...);

style declarations need corresponding

int foo(int x, ...)
{
}

style definitions.

Dan

From jfg@dxcern.cern.ch  Mon Jun  8 00:43:17 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10106; Mon, 8 Jun 92 00:43:17 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26188; Mon, 8 Jun 92 00:41:24 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA24685; Mon, 8 Jun 92 00:41:18 +0200
Date: Mon, 8 Jun 92 00:41:18 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206072241.AA24685@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: revised MIME architecture
References: <9206062231.AA23867@pixel.convex.com>

	Dan,

  OOPS... You sent this one to www-interest instead of www-talk...
I'm getting ready for some flamage from clueless list members :-)

  Regarding your proposal, the idea is exciting, although I find it
annoying that small documents, like most HTML pages are, will suddenly
take 4 times as much storage and bandwidth due to verbosity. When
multimedia comes into play, of course, this is a non-issue. I do agree
that the current UDI syntax is too terse, though.

  I'd like to develop on this, but I lack MIME background and, believe
it or not, I couldn't find the MIME RFC in the archive indexes ; could
you tell me (and the list) its number? Also, pointers to existing MIME
readers would be welcome.

  More later...

	Jean-Francois

From jfg@dxcern.cern.ch  Mon Jun  8 01:03:03 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10129; Mon, 8 Jun 92 01:03:03 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA27827; Mon, 8 Jun 92 01:01:09 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA26164; Mon, 8 Jun 92 01:01:02 +0200
Date: Mon, 8 Jun 92 01:01:02 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206072301.AA26164@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML is not SMGL
References: <9206070512.AA17832@pixel.convex.com>

Dan asked:
> How much extant HTML is really out there? And how much of it is
> generated on the fly by gateways and servers?

  Our hypertext documentation is certainly the largest quantity of
HTML you can find in the world. Besides, we know all the people who
have produced their own, so making the Big Change would be relatively
simple for them (esp. given your impressive perl script). Gateways can
be changed easily too. But all the browsers must be updated before,
and that will take more time !!!  (There are thousands of copies
installed...)

> I suspect I'll get some resistance against abandoning UDI's, but I
> don't think they work.

  Well, you still use them internally, don't you ? ;^)

	Jean-Francois

From emv@nigel.msen.com  Mon Jun  8 02:29:05 1992
Return-Path: <emv@nigel.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10171; Mon, 8 Jun 92 02:29:05 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03499; Mon, 8 Jun 92 02:27:12 +0200
Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0luXZf-0009YoC@nigel.msen.com>; Sun, 7 Jun 92 20:26 WET DST
Message-Id: <m0luXZf-0009YoC@nigel.msen.com>
To: jfg@dxcern.cern.ch (Jean Francois Groff)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML is not SMGL 
In-Reply-To: Your message of Mon, 08 Jun 92 01:01:02.
             <9206072301.AA26164@dxcern.cern.ch> 
Date: Sun, 07 Jun 92 20:26:48 EDT
From: Edward Vielmetti <emv@msen.com>

The UDI vs. MIME argument is a non-arguement.  MIME is sufficiently
flexible that if you construct an appropriate Content-type and define
its semantics appropriately it will accept UDI's and work accordingly.
"Simple matter of programming" :).

Explicit "attribute=value" tags are more flexible than the W3 approach
to turn the entire document ID into a big long string.  I guess it 
depends on whether you believe you are dealing with a big database
or a big file system.  Both approaches have their place.  Again as
a simplified case you have "udi=//host:port/path" as a MIME identifier
and all is well.

I expect that MIME will be available in many e-mail products over the next
3-5 years.  Since the only application that has anywhere near universal
appeal on the net is e-mail, it strikes me as only appropriate that 
hypertext systems try to get as much leverage from mail as they possibly
can.

--Ed

From connolly@pixel.convex.com  Mon Jun  8 05:32:01 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10306; Mon, 8 Jun 92 05:32:01 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28567; Mon, 8 Jun 92 05:30:05 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12532; Sun, 7 Jun 92 22:29:47 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA28300; Sun, 7 Jun 92 22:29:45 -0500
Message-Id: <9206080329.AA28300@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: jfg@dxcern.cern.ch (Jean Francois Groff), www-talk@nxoc01.cern.ch
Subject: Re: HTML is not SMGL 
In-Reply-To: Your message of "Sun, 07 Jun 92 20:26:48 EDT."
             <m0luXZf-0009YoC@nigel.msen.com> 
Date: Sun, 07 Jun 92 22:29:44 CDT
From: Dan Connolly <connolly@pixel.convex.com>


>The UDI vs. MIME argument is a non-arguement.  MIME is sufficiently
>flexible that if you construct an appropriate Content-type and define
>its semantics appropriately it will accept UDI's and work accordingly.
>"Simple matter of programming" :).
>
>Explicit "attribute=value" tags are more flexible than the W3 approach
>to turn the entire document ID into a big long string.  I guess it 
>depends on whether you believe you are dealing with a big database
>or a big file system.  Both approaches have their place.  Again as
>a simplified case you have "udi=//host:port/path" as a MIME identifier
>and all is well.
>
The problems is that the syntax of a UDI doesn't fit into the syntax
of a MIME parameter (or an SGML attribute value...) because a UDI
might be arbitrarily long, and it cannot contain any whitespace (so
it can't be split across lines).

So these 200+ character UDI's for WAIS documents can't be
mailed around safely (even SGML has limits on the length of an
attribute value).

Heck, my WWW client (perhaps it's not the latest version, but still...)
can't even retrieve wais documents due to these problems.

Dan

From connolly@pixel.convex.com  Mon Jun  8 05:39:39 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10313; Mon, 8 Jun 92 05:39:39 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00160; Mon, 8 Jun 92 05:37:46 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12756; Sun, 7 Jun 92 22:37:31 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA28980; Sun, 7 Jun 92 22:37:29 -0500
Message-Id: <9206080337.AA28980@pixel.convex.com>
To: jfg@dxcern.cern.ch (Jean Francois Groff)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: revised MIME architecture 
In-Reply-To: Your message of "Mon, 08 Jun 92 00:41:18 +0200."
             <9206072241.AA24685@dxcern.cern.ch> 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=cut-here
Date: Sun, 07 Jun 92 22:37:29 CDT
From: Dan Connolly <connolly@pixel.convex.com>


--cut-here

>	Dan,
>
>  OOPS... You sent this one to www-interest instead of www-talk...
>I'm getting ready for some flamage from clueless list members :-)
>
Did I? I sent several messages, and I though I was careful to
send them all to www-talk. Oh well... Sorry!

>  Regarding your proposal, the idea is exciting, although I find it
>annoying that small documents, like most HTML pages are, will suddenly
>take 4 times as much storage and bandwidth due to verbosity.
>
They won't necessarily take 4 times as much storage: the verbose part
_could_ be generated on the fly. by the server.

On the other hand, it _is_ simpler to store things in the format that
they'll be used. This brings up the issue of authoring documents in
this format. I'm developing some ideas on interactive composition
of MIME messages (using EMACS, FrameMaker, or perhaps a Tk application)
but for now, it's somewhat tedious.

>  I'd like to develop on this, but I lack MIME background and, believe
>it or not, I couldn't find the MIME RFC in the archive indexes ; could
>you tell me (and the list) its number? Also, pointers to existing MIME
>readers would be welcome.
>
I've gotten several "nifty... so what is MIME?" responses. So I'll
tell you what I told them...

--cut-here

>Where can I get more information about MIME?
>
>			Thanks.

The author of the rfc is Nathaniel Borenstein <nsb@thumper.bellcore.com>.
Most of the publicly available material is on thumper.bellcore.com in
pub/nsb.

--cut-here
Content-Description: RFC-XXXX (MIME)
Content-Type: multipart/alternative; boundary=alt

--alt
Content-Type: message/external-body;
	access-type=ANON-FTP;
	site=thumper.bellcore.com;
	dir=pub/nsb;
	name="BodyFormats.txt"

Content-Type: text/plain

--alt
Content-Type: message/external-body;
	access-type=ANON-FTP;
	site=thumper.bellcore.com;
	dir=pub/nsb;
	name="BodyFormats.ps"

Content-Type: application/postscript

--alt--

--cut-here--


From connolly@pixel.convex.com  Mon Jun  8 05:52:19 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10330; Mon, 8 Jun 92 05:52:19 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00534; Mon, 8 Jun 92 05:50:21 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA13067; Sun, 7 Jun 92 22:49:54 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA00415; Sun, 7 Jun 92 22:49:51 -0500
Message-Id: <9206080349.AA00415@pixel.convex.com>
Subject: MIME for global hypertext
To: www-talk@nxoc01.cern.ch, wais-talk@think.com
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Sun, 07 Jun 92 22:49:51 CDT
From: Dan Connolly <connolly@pixel.convex.com>


[This was posted to several newsgroups, but someone from wais-talk
suggest I forward it there also.]


The WAIS, gopher, and world-wide-web projects are all client/server
information retrieval systems. All three deliver plain text information
quite well, and they each have evolving mechanisms for delivering
other forms of information.

The MIME RFC defines a system for processing multi-part, multimedia
messages on the internet. I would like to see these systems, along
with USENET news and internet mail, interoperate with MIME as the substrate.

The clients for these systems go something like this:
0	user invokes client (and chooses a starting point)
1	client displays user's request
2	user reads page, chooses a reference to more info
3	user informs client of choice
		 (e.g. "show me item #1," or "search for googoo")
4	go to step 1

These systems often consist of a hierarchy of menus with text files at
the leaf nodes. The system allows the user to interactively navigate
the menus and browse leaf nodes. But 1) the format of the menus is
particular to the system (USENET newsgroups/articles, unix
directories/files, WAIS source/database/document). And 2) once a user
is at a leaf node, the system can no longer interactively follow
references.

The novel aspect of hypertext is that the distinction between the
menu pages and the text pages disappears. In the world-wide-web,
text documents have machine-readable links inside them, and all
menus are represented as hypertext documents.

The WWW format works well, but it would benefit from use of MIME's
features.

For a common hypertext document format, I propose we define a
subtype of the MIME multipart message: X-HYPERTEXT. The first
part of a multipart/X-HYPERTEXT message is the content of
the document, and the remaining parts are multimedia attachments
and links to other documents.

The content part contains references (by Content-ID) to the
attachments and links. The client software allows the user
to interactively choose references to display/follow.

The remaining parts may be attached image/audio/video using
MIME's various types and transfer encodings (text attachments
would work too) or they may be references to information
accessible elsewhere using MIME's message/external-body type.
The parameters to the external-body content-type provide the
same information as WWW's Universal Document Indentifier.
(MIME only defines ANON-FTP, FTP, TFTP, LOCAL-FILE and AFS.
The remaining access-types (WAIS, gopher, etc) would be
experimental (X-WAIS, X-GOPHER) until standardized.)

The emerging standard for structured, platform-independent text
is SGML. The WWW project defines an SGML document type with
traditional elements (title, heading, paragraph, list) and
new hypertext elements (anchor). Soon it will have multimedia
elements (image, audio).

The current design places external document references (to files,
WWW servers, WAIS documents, gophers, etc.) inside the SGML as
attributes. There are lexical incompatibilities, and the design
is under strain. I suggest that we implement references as
as SGML entities that identify message/external-body parts
by content-id.

Representing document content in SGML allows the same information
to be accessed using different user interface paradigms (e.g. dumb
terminals vs. curses style vs. x windows point-and-click).

Short of full SGML parsing, we could adopt the MIME text/richtext
format, with the addition of a <REF ID="xxx">...</REF> tag.
In fact, any representation that allows the user to interactively indicate
one of the attached body parts by content-id will do. For example,
plain text with one-line descriptions would do. The Andrew ez
data stream would also work, but only Andrew sites could parse it.

This brings up the issue of format negociation. No one format is
optimal for all information. Clients are likely to be able to process
information in several formats, and servers are likely to be able
to provide different representations.

The various formats can be enclosed in a MIME multipart/alternative
message. And rather than including the data for all formats in
the message, the data could be in message/external-body parts. The
client chooses the type of data it likes and retrieves the corresponding
external-body. This (modified) example from the MIME rfc may help explain:

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=42

--42
Content-Type: message/external-body;
	name="BodyFormats.ps";
	site="thumper.bellcore.com";
	access-type=ANON-FTP;
	directory="pub";
	mode="image";

Content-type: application/postscript

--42
Content-Type: message/external-body;
	name="/u/nsb/writing/rfcs/RFC-XXXX.ez";
	site="thumper.bellcore.com";
	access-type=AFS;

Content-type: application/x-ez

--42
Content-Type: message/external-body;
	name="BodyFormats.txt";
	site="thumper.bellcore.com";
	access-type=ANON-FTP;
	directory="pub";

Content-type: text/plain

--42--

The client can choose between postscript, ez, and plain text, and
retrieve the corresponding message body.


The question then becomes: how do these systems interoperate?
By making information available as multipart/X-HYPERTEXT MIME
messages.

The WWW client interfaced to the other systems by defining
"addressing schemes" and implementing the various protocols
and translating the data into HTML. Gopher has a similar
typing scheme -- one character is reserved to indicate
the access type and the data type. WAIS clients have yet
another method of resolving types, though they only support
one protocol. The NewsGrazer application has its own
encapsulation mechanism. This is becoming a mess.

In the short term, global hypertext viewers will have to support
the access-type and content-type of each system with which it
interoperates (so we have X-WAIS, X-HTTP, X-GOPHER, X-NNTP, as well as
X-WAIS-SRC, X-HTML, X-GOPHER-1 thru X-GOPHER-9).

Some of the access types will become standard, and some will die out.
But all the data types should be encapsulated in MIME messages. Any
data that has machine-readable pointers to other data should be made
into a multipart/X-HYPERTEXT message. For example, a WAIS question
should have attachments for each of the result documents (the content
part can stay application/x-wais-question, or it could be converted to
a text type, or both), at least in the case where those documents are
available by some standard access method.  [I wrote a perl script that
will change an HTML document into a MIME message with attachments.]

Leaf documents, i.e. documents with no external links, can stay in
single part types. e.g. Plain text files become MIME messages by simply
adding a blank line at the beginning (to separate the headers (none)
from the body).

Under this model, a mail message can point to a news article
which references a WAIS document which contains several drawings
and pointers to several more available by FTP, and a user could
just point-and-click between them. The only need for
protocols like gopher and HTTP is to encapsulate data that's not
already MIME compliant.

This is clearly a pipe dream, but it's the kind of thing we can work
towards today.

Dan


From connolly@pixel.convex.com  Mon Jun  8 07:20:13 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10475; Mon, 8 Jun 92 07:20:13 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07520; Mon, 8 Jun 92 07:18:19 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA16259; Mon, 8 Jun 92 00:17:52 -0500
Received: by pixel.convex.com (5.64/1.28)
	id AA20948; Mon, 8 Jun 92 00:17:48 -0500
Date: Mon, 8 Jun 92 00:17:48 -0500
From: connolly@pixel.convex.com (Dan Connolly)
Message-Id: <9206080517.AA20948@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Cc: enag@ifi.uio.no
Subject: Re: using NOTATIONs inline
Newsgroups: comp.text.sgml
In-Reply-To: <23177A@erik.naggum.no>
References: <1992Jun5.205639.21823@news.eng.convex.com>
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Cc: 

In article <23177A@erik.naggum.no> you write:
>Dan Connolly <connolly@convex.com> writes:
>|
>|   The WWW group is attempting to define a multimedia interchange
>|   format called HTML.  . . .
>
>Why not use HyTime?
>
Eric:
Partyly because of ignorance (we've heard of HyTime, but we don't
know the details). I'd expect a HYTIME engine to be quite a bit
of work to implement. And partly because, as I understand it, HYTIME
doesn't go as far as to perscribe a DTD. The WWW project needs
one particluar language, not a whole architecture.

I'd certainly like to know more about HYTIME's techniques for addressing
documents, esp. elements of documents.

Now for the WWW gang:
>:
>|   That is, is it possible to put an arbitrary 8 bit binary stream
>|   _inside_ an SGML document? My guess is: no. But if we use
>|   CDATA, can we include anything that doesn't contain the closing
>|   tag in full?
>
>If you by "the closing tag in full" mean the entire end-tag, complete
>with etago, generic identifier, and tagc, as in "</image>", this is not
>the way SGML does it.  CDATA and SDATA are terminated by a etago
>"delimiter-in-context", which is an etago (end-tag open, "</") delimiter
>followed by a name start character, or a grpo (group open, "(")
>delimiter if concurrent document types are allowed.  In the reference
>concrete syntax, this means that the regular expression "</[(a-z]"
>matches the end of CDATA and SDATA elements.
>
>You can also use marked sections, with a CDATA status keyword, in which
>case the CDATA is terminated by the mse delimiter (marked section end,
>"]]>").
>
>:
>|   Someone made the point that an SGML document is only allowed to
>|   include SGML characters as specified by the SGML declaration, and if
>|   we're going to use the default SGML declaration, we have to stick to
>|   the characters blessed by it.
>
>Blessed and blessed.  The SGML declaration is supposed to reflect the
>reality of the document, not enforce arbitrary limits on them.  So you
>write an SGML declaration which fits the document.
>
>|   That's not my understanding. I thought that inside CDATA (or SDATA,
>|   I think) you could put _anything_ but the closing tag in full.
>
>As said above, the etago delimiter-in-context terminates the data,
>regardless of whether it's a legal end-tag in that context.
>
>You should be aware that the SGML parser will parse the contents of the
>"binary" content, and ignore record start, and treat record ends
>different from other characters.  In addition, it's an error for an SGML
>entity to contain characters with any of the numbers listed in the
>SHUNCHAR part of the SYNTAX declaration.  This is _not_ what you want
>with binary data.
>
>|   What's the scoop? Do we have to use external entities for raw data?
>
>Yes.  An external entity that is not an SGML text entity requires a
>notation identifier, so you only need to list the entities in the DTD,
>with notation, and refer to them by name in the document instance.
>
>If this is not satisfactory, you should declare the objects to be CDATA,
>and use a binary to text-only transformation scheme.  There are several
>such schemes.  Among them, base64 is the preferred encoding in my view,
>since it's available as part of the new Multipurpose Internet Mail
>Extensions (MIME) RFC-to-be.  (The latest draft is available for
>anonymous FTP as ftp.ifi.uio.no:/pub/SGML/MIME.6.ps and MIME.6.txt for
>two weeks from today.  Section 5.2 which concerns the base64 encoding is
>also available as ftp.ifi.uio.no:/pub/SGML/base64.txt.)  Transformation
>back to the binary form from the text-only form may be done on the fly
>by the application before sending the data to the notation interpreter.
>
My idea is to use MIME encodings, but put these attachments _outside_
the SGML text, in an attached (or external) body part.

>In addition to being much easier to deal with in SGML, this also makes
>SGML documents containing such content robust with respect to file
>transfer, etc.
>
>Hope this helps,
></Erik>

Thanks. Mostly it confirms my suspicions, but it should also provide
a somewhat authoritative answer (no references to ISO 8879 here :-)
to the WWW project.

>--
>Erik Naggum       |  +47-295-0313     |  ISO 8879 SGML     |  Memento,
>Naggum Software   |   "fuzzface"      |  ISO 10744 HyTime  |  terrigena.
>Boks 1570, Vika   | <erik@naggum.no>  |  JTC 1/SC 18/WG 8  |  Memento,
>0118 OSLO, NORWAY | <enag@ifi.uio.no> |  SGML UG SIGhyper  |  vita brevis.



From davis@willow.tc.cornell.edu  Mon Jun  8 15:28:24 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11057; Mon, 8 Jun 92 15:28:24 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA20617; Mon, 8 Jun 92 15:26:33 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA17632; Mon, 8 Jun 92 09:28:20 EDT
Date: Mon, 8 Jun 92 09:28:20 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206081328.AA17632@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: HTML terseness/verbosity

Re the recent comments on terseness of UDIs and the
extra verbosity in Dan Connolly's proposal to
use Mime for WWW documents:

My understanding is that nobody should have to type
"naked" SGML (or HTML or Mime-language) anyway.
We should have programs like WYSIWYG editors
manipulating the markup for us.  (Now of course
at present we do have to type HTML, at least I do
here, but hopefully this will not persist).  If
that's right, then the more explicit and simple
the document structure is, the easier to parse
and manipulate by programs, the better we are.

One thing I like about Dan's proposal - it makes
it possible to collect a hyperdocument into a single
file (by embedding the docs within one mime file)
which will make transporting easier

From jfg@dxcern.cern.ch  Mon Jun  8 17:34:55 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11440; Mon, 8 Jun 92 17:34:55 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01254; Mon, 8 Jun 92 17:32:28 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA21936; Mon, 8 Jun 92 17:32:23 +0200
Date: Mon, 8 Jun 92 17:32:23 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206081532.AA21936@dxcern.cern.ch>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: overkill on portability macros
References: <9206070615.AA15478@pixel.convex.com>

> But ANSI C and PCC share syntax for _defining_ functions.
> The preprocessor dancing is necessary for _declaring_ functions
> like so:
>
> int foo __ARGS__((int x, int y, int z));
>
> but in the .c files, you can just do the usual
>
> int foo(x,y,z)
> int x;
> int y;
> int z;

  True, but in the latter case you don't get any type checking of the
parameters in functions that happen NOT to be declared before their
definition. I agree that the syntax with extra commas is ugly, though,
but there was no better way.

	JF

From mitra%pandora@fernwood.mpk.ca.us  Mon Jun  8 22:23:03 1992
Return-Path: <mitra%pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12313; Mon, 8 Jun 92 22:23:03 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24770; Mon, 8 Jun 92 22:21:08 +0200
Received: by fernwood.mpk.ca.us; id AA13324; Mon, 8 Jun 92 13:16:50 -0700
From: mitra@pandora.sf.ca.us ()
X-Mailer: SCO System V Mail (version 3.2)
To: connolly@pixel.convex.com, wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: MIME for global hypertext
Date: Mon, 8 Jun 92 13:11:15 PDT
Message-Id:  <9206081311.aa26440@pandora.sf.ca.us>

Dan,

Thanks for that proposal. I must admit to not having read the MIME RFC,
being mostly concerned with text rather than multimedia, so I wasnt
aware of the hypertext implications of it.

My question is on a fairly minor point of your document, you mention that 
a MIME document typically consists of a content and then the pointers, 
with the hypertext links being references to the pointers.  In Wais, it 
is quite possible to return part of a document (by byte position), and 
if the pointers are part of the document itself then they may not be 
returned at the time the user chooses to try and follow a link? 

My concerns are around doing these things for users on low-speed (2400 baud)
modems. For them, protocols need to be easy to handle at slow speed, and 
need to be meaningfull BEFORE the whole document has been received. As the
Internet extends out to more and more users beyond the high-speed links
currently assumed the need for protocol designers to consider those users
becomes more important. 

- Mitra
------------------------------------------------------------------
Mitra - technical director, Pandora Systems
mitra@pandora.sf.ca.us


From connolly@pixel.convex.com  Mon Jun  8 22:52:36 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12426; Mon, 8 Jun 92 22:52:36 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA27128; Mon, 8 Jun 92 22:50:38 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA03927; Mon, 8 Jun 92 15:50:19 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA15921; Mon, 8 Jun 92 15:50:17 -0500
Message-Id: <9206082050.AA15921@pixel.convex.com>
To: mitra@pandora.sf.ca.us ()
Cc: wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: Re: MIME for global hypertext 
In-Reply-To: Your message of "Mon, 08 Jun 92 13:11:15 PDT."
             <9206081311.aa26440@pandora.sf.ca.us> 
Date: Mon, 08 Jun 92 15:50:17 CDT
From: Dan Connolly <connolly@pixel.convex.com>



>My question is on a fairly minor point of your document, you mention that 
>a MIME document typically consists of a content and then the pointers, 
>with the hypertext links being references to the pointers.

Well, this is not typical, but it's the model I'm proposing for
hypertext. Typically MIME message bodies are either single part
text/image/audio, or multipart. The standard multipart types
are mixed, meaning "show these one after the other," parallel,
meaning "show these at the same time," or alternative, meaning
"these all represnt the same info. Take your pick."

The "content and then list of pointers [or attachments]" model
is my own proposed format for hypertext.

>  In Wais, it 
>is quite possible to return part of a document (by byte position), and 
>if the pointers are part of the document itself then they may not be 
>returned at the time the user chooses to try and follow a link? 
>
I would suggest that the WAIS server interpret the byte positions
as offsets into the content part of the hypertext. So the structure
remains in tact. Byte offsets into a MIME multipart message
don't mean much. Transport systems may mess with the headers and
trailing whitespace on body lines. Line offsets may be meaningful
inside text body parts, as long as none of the lines have to be
split due to line length constraints.

Keep in mind that this multipart structure is only necessary for
hypertext (i.e. contains links) and hypermedia (i.e. contains
multimedia attachments) documents.

Traditional documents can be simple single part bodies. For example,
A plain text file starting with a new-line will be interpreted as
a body part with no headers, which defaults to the type
"text/plain; charset=US-ASCII" ,i.e. plain old text.

>My concerns are around doing these things for users on low-speed (2400 baud)
>modems....

From connolly@pixel.convex.com  Wed Jun 10 01:11:39 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15414; Wed, 10 Jun 92 01:11:39 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25378; Wed, 10 Jun 92 01:11:32 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA29288; Tue, 9 Jun 92 18:10:43 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA20418; Tue, 9 Jun 92 18:10:31 -0500
Message-Id: <9206092310.AA20418@pixel.convex.com>
To: mitra@pandora.sf.ca.us ()
Cc: emv@msen.com, wais-talk@quake.think.com, www-talk@nxoc01.cern.ch,
        gopher-news@boombox.micro.umn.edu
Subject: Re: WAIS APIs 
In-Reply-To: Your message of "Tue, 09 Jun 92 10:08:51 PDT."
             <9206091008.aa08978@pandora.sf.ca.us> 
Date: Tue, 09 Jun 92 18:10:29 CDT
From: Dan Connolly <connolly@pixel.convex.com>


There are several issues that WAIS and MIME both face. For some
issues, the systems have different requirements, so different
solutions make sense. But for the issue of typing document
content, I feel stronly that WAIS should adopt MIME semantics.

WAIS defines a :type field in the :document structure. Right
now, it's a string with loosely defined semantics. It's a
simple matter to obsolete the :type field with a :content-type
field with MIME semantics as follows:

	obsolete	MIME compliant
	:type "TEXT"	:content-type "text"
	:type "GIF"	:content-type "image/gif"
	:type "TIFF"	:content-type "image/x-tiff"
	:type "PS"	:content-type "application/postscript"
	:type "WSRC"	:content-type "application/x-wais-source"
	:type "MIME"	:content-type "message"

I believe data served up by existing WAIS servers fits the MIME
content typing system as is. A WAIS client already implements the
semantics of the text, image, audio, video, and application types:
Either you present it, hand it off to something that can,
or punt to a file.

There are other semantics defined by MIME that would be nice
in WAIS clients. But these require that you handle pretty much
the whole MIME syntax. It's not clear that WAIS should adopt
the MIME solutions in these cases.

[I would like to see the world-wide web adopt MIME solutions
for these issues, though.]

In <9206081956.AA03908@cmns.think.com.Think.COM>, Mr. Spero suggests
that WAIS might be expanded to offer data in a number of types. The MIME
solution to this problem is the "multipart/alternative" body type.

Someone else suggested that the WAIS server might return only
a pointer to the data, and the client could retrieve the actual
content. MIME defines a "message/external-body" type for this.

And I suggested that the server might return a complex document
with text, graphics, and pointers to other data. (World Wide
Web servers return text with pointers, and they're trying to
deal with graphics). I suggested a new "multipart/hypertext"
type to handle this.

Resolving these issues is going to take a lot more thought.
Let's keep interoperability in mind while we do it.

Dan

From morris@quake.think.com  Wed Jun 10 07:55:32 1992
Return-Path: <morris@quake.think.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15757; Wed, 10 Jun 92 07:55:32 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28784; Wed, 10 Jun 92 07:55:34 +0200
Received: by quake.think.com (4.1/SMI-4.0)
	id AA01284; Tue, 9 Jun 92 22:56:59 PDT
Date: Tue, 9 Jun 92 22:56:59 PDT
Message-Id: <9206100556.AA01284@quake.think.com>
From: Harry Morris <morris@think.com>
Sender: morris@quake.think.com
To: connolly@pixel.convex.com
Cc: mitra@pandora.sf.ca.us, emv@msen.com, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch, gopher-news@boombox.micro.umn.edu
In-Reply-To: Dan Connolly's message of Tue, 09 Jun 92 18:10:29 CDT <9206092310.AA20418@pixel.convex.com>
Subject: WAIS APIs 


   Date: Tue, 09 Jun 92 18:10:29 CDT
   From: Dan Connolly <connolly@pixel.convex.com>

	   obsolete	MIME compliant
	   :type "TEXT"	:content-type "text"
	   :type "GIF"	:content-type "image/gif"
	   :type "TIFF"	:content-type "image/x-tiff"
	   :type "PS"	:content-type "application/postscript"
	   :type "WSRC"	:content-type "application/x-wais-source"
	   :type "MIME"	:content-type "message"

excuse the novice question, but doesn't x-tiff and x-wais-source imply that
a particular program (running on an X Windows display) is to be called?

how do you support other platforms?


From burchard@horizon.math.utah.edu  Wed Jun 10 08:09:00 1992
Return-Path: <burchard@horizon.math.utah.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15796; Wed, 10 Jun 92 08:09:00 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05143; Wed, 10 Jun 92 08:09:02 +0200
Received: from horizon.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server)
	id AA09200; Wed, 10 Jun 92 00:08:51 MDT
Received: by horizon.math.utah.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01628; Wed, 10 Jun 92 00:09:54 MDT
Date: Wed, 10 Jun 92 00:09:54 MDT
From: burchard@horizon.math.utah.edu (Paul Burchard)
Message-Id: <9206100609.AA01628@horizon.math.utah.edu>
Received: by NeXT Mailer (1.63)
To: Harry Morris <morris@think.com>
Subject: Re: WAIS APIs 
Cc: connolly@pixel.convex.com, mitra@pandora.sf.ca.us, emv@msen.com,
        wais-talk@quake.think.com, www-talk@nxoc01.cern.ch,
        gopher-news@boombox.micro.umn.edu

> excuse the novice question, but doesn't x-tiff and x-wais-source 

> imply that a particular program (running on an X Windows display) 

> is to be called?

If I'm not mistaken the "x-" refers to "experimental".  I.e,. these  
are not an officially registered MIME types.  (There is no X Windows  
program called x-tiff, by the way.)

Since these naming schemes serve the same purpose there is no reason  
not to have them interoperate; this could be fitted nicely into an  
OOP API.

PB



From timbl@zippy.lcs.mit.edu  Thu Jun 11 18:21:47 1992
Return-Path: <timbl@zippy.lcs.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20470; Thu, 11 Jun 92 18:21:47 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16880; Thu, 11 Jun 92 18:21:50 +0200
Received: by zippy.lcs.mit.edu 
	id AA03819; Thu, 11 Jun 92 12:22:56 -0400
Date: Thu, 11 Jun 92 12:22:56 -0400
From: timbl@zippy.lcs.mit.edu (Tim Berners-Lee)
Message-Id: <9206111622.AA03819@zippy.lcs.mit.edu>
To: connolly@pixel.convex.com, enag@ifi.uio.no, www-talk@nxoc01.cern.ch
Subject: MIME, SGML, UDIs, HTML and W3
Cc: timbl@zippy.lcs.mit.edu


I have printed off the recent discussion on the new
HTTP, HTML and MIMe and UDIs and done what I can
to disentangle it all in my mind.  I will reply
in one message, becase many of the points are linked.
I know this should be hypertext, with references but
(a) I am away from home and (b) we don't yet have a
universal mail/news archive server running to link to.

	HTTP and HTML

First of all, Jean-Francois <jfg@dxcern.cern.ch>
points out very properly that the enhaced HTTP
protocol and the enhanced HTML spec are quite
separate things, and should be specified separatedly.
I agree wholeheartdly about all this, and
I aplogize for muddling the levels up till now.

(As a small aside, I would point out that wheras a
HTERR file is not very useful, a HTFWD file IS.
It is like a hypertex soft link. But I am happy to
leave that as a separate type of file. It should
certainly get a different extension so that it gets a
different icon)

        HTTP: SGML vs ASN/1

Let's look at the HTTP protocol first. Carl <barker@cernnext.cern.ch>
is mapping out  the requirements for this, and assuming that SGML
would be a reasonable representation for it in practice.
And so it is.  When the requirements are clear,
it would certainly be interesting to look at mapping them
onto a z39.50 - style ASN/1 implementation. This would
be useful for two reasons. First, the comparison would
point out to us things in z39.50 which we might not have thought of
which would b useful for HTTP. Second, the comparison might give
a nice short or at least well-defined things which the WAIS
guys might like to take into account in the next version
of their protocol.  (I demod W3 to Brewster who hadn't
seen it before live, and was very keen that WAIS and W3
should merge, changing the WAIS protocol if necessary.

There is no reason why we shouldn't try both protocols.
If they map well onto each other, its just a question
of having two separate prasers at the low level, building
the same internal structures.

When we're talking about an SGML representation,
and describe a file to come later down the link,
I don't think we have to use the NOTATION= attribute with a notation
type, because we won't in fact be talking about
the notation of an SGML element.
The format in this case is not something which the SGML
parse is aware of.

I must admit I was disappointed to learn that SGML
didn't allow for any way of including 8 bit data. Thanks Eric
<enag@ifi.uio.np> for your explanations.


	MIME and SGML

Dan <connolly@pixel.convex.com> rightly points out
the relevance of the coming MIME standards. There
are several things which we must separate here, though:

   1. The MIME classification of data formats
   2. The MIME format for multi-part messages
   3. The MIME format for rich text.
   4. The MIME formal for external document addresses (MIME UDIs)

1. MIME classification of data formats

	We must do the same disentangling job which JF did
	on HTML to MIME.

	First of all, the MIME job of classifying data formats
	is a useful job which is ideally done by just one
	bunch of people. Ther has been some suggestion that
	the MIME classifications are not well enough defined,
	but they seem to be the best effort yet and one can only
	assume they will eveolve in the right direction. So I'd
	back the use of these for W3.


2. The MIME format for multi-part messages

	This is necessary for sending a multi-part
	document over a mail link.  We have to ask ourselves
	whether it is reasonable to use over a binary link.
	Personally, my initial impression is that the MIME
	stuff, using as it does terminators such as
	--xxx-- separated by blank lines, looks more horrible
	to work with in this respect than SGML! Still we have
	the problem of restrictions on the content:
	Must not contain delimiters, limited 7 bit character set,
	line orientation, in fact all the things which email
	carries as a restriction.  This is really taking on board
	a legacy of all the mail which has evolved over the years.
	Do we need that for our new ultra-fast hypertext access
	protocol?

	[Compare the MIME format with the rather cleaner NeXT
	Mail format which is as far as I understand simply
	a uuencoded compressed tar file of all the bits, where
	uuencoding is designed as an optimal way of getting over
	mail transport restrictions, compress does what it says
	and tar is a multipart wrapper designed for that only. Not
	standard outside unix, perhaps, but cleaner in that the
	mail formatting is done at the last minute and doesn't
	affect the other operations]

	If course, with HTTP2, multipart/alternative shouldn't
	be needed.

  Multipart for hypetext?

	Now, Dan not only suggests the use of this for
	multipart messages, but also suggests that a hypetext
	document shoudl necessarily contain many parts,
	one on SGML and one for each link as a MIME external document.
	This means that an SGML hypertext document can never stand
	on its own! An SGML parser will always need to have
	a MIME parser sitting just outside.  I don't like
	this: I feel we have to separate these two things.

	Suppose that an SGML document does want to
	be sent in a MIME message and does want to
	refer to other parts of that MIME message. In that case,
	it seems reasonable to have a format for that.
	However, when an SGML document is seen by itself, and
	refers to a news message for example, then there is
	no resaon for it not to be able to contain a
	complete reference within itself.

	When SGML documents include other files, then
	the SYSTEM value is typically a file name.
	It is a reeference to something outside. The
	precedent is set that SGML documents are allowed
	to refer to things outside.

	I think part of you objection, Dan is based on 
	a dislike of the UDI syntax -- which I'll come to later.
  
3. The MIME format for rich text.

	Here, I am not so impressed.  Basically, the MIME
	people are at the same level that we were before we started
	this cleanup, that they have SGML-LIKE stuff which isn't SGML.
	As its not difficult to make it SGML, they should do that.
	Comparing MIME's rich text and HTML, I see that
	we lack the characetr formatting attributes BOLD and ITALIC
	but on the other hand I feel that our treatment of
	logical heading levels and other structures is much more powerful
	and has turned out to provide more flexible formatting	
	on different platforms than explicit semi-references
	to font sizes.  This is born out by all the systems which
	use named styles in preference to explicit formatting,
	LaTeX or other macros instead of TeX, etc etc.

	So technically, HTML has some things to give MIME's rich
	text. Are the MIME people still open to additions?
	If not, I would suggest we add BOLD and ITALIC (or
	two emphasis styles for characters), and keep HTML
	separete from MIME's rich text, proposing it as a
	MIME text standard.
	(HP0 and HP1 were in the HTML spec but as unimplemented)
  
4. The MIME format for external document addresses (MIME UDIs)

	As Ed <emv@msen.com> says, this is a bit of a non-issue,
	as MIME addersses and currnet style UDIs map onto
	each other. However, we have to agree on a "concrete
	syntax" (or two... :-) in the end.

	It's like the difference between an x400 style mail address
	generated from an internet address, and that internet address.
	Which do you prefer

		timbl@zippy.lcs.mit.edu

	where the sections of the domain name are defined
	to have no semantics at all, or

		S=timbl; HO=zippy; OU=lcs; O=MIT; SECTOR=edu

	(this is not real x400 - don't use it!) or

		user=timbl
		host=zippy
		group=lcs
		organization=mit
		sector=education

	You say, Dan, that you "don't think [UDIs] work".
	Do you mean people don't use them in all correspondance?
	Well, what DO they use? They use ange-ftp addresses	
	for FTP (like info.cern.ch:/pub/www/doc/*.ps),
	which are even more terse than UDIs! They use news
	message-ids which are UDIs.

	Let me say that I personally don't much care about the
	arbitrary punctuation. There are a few things, though,
	which are important:

	-  The thing should be printable 7-bit ASCII.

	   Unlike arbitrary document formats,
	   UDIs must be sendable in the mail

	- White space should not be significant. I would
	  accept the presence of some arbitrary white space
	  as a delimiter, but one cannot distinguish between
	  different forms and quantities of white space.
	  This is because things get wrapped and unwrapped.

	  Dan, you object to UDIs because they don't
	  contain white space. But that is purely so that
	  to CAN wrap them onto several lines and still
	  recuperate them.  You can put white space
	  in but it shouldn't mean anything. (This is not possible
	  in W3 as is but it is in the UDI document)

	  I don't see why you say they
	  can't be put as an SGML attribute. They are just
	  text strings. They will be quoted of course
	  (Yes, I know the old NeXT browser doesn't quote them)
	  Is that not allowed? What are the problem characters?
	  If there SGML problem characters in the UDI spec, they
	  probably are ruled out of SGML for a reason.

	  (I recently saw in a galley proof of an article in which
	  our mail adress had been hypernated! UDIs must be
          squeezable into 2 inch columns.)

        There is a sematic difference between a tagged
	list and a punctuation-divided set, and that is that
	the former has defined semantics but the latter doesn't and
	can therefore be extended more easily.  I suggest that tagging
	could be used for the four bits of an address
	that must be separable by all sides, which are
	limited in number (4). Within those bits, the string should
	be transparent as the protocol does not require
	every party to understand the innards. 

	The bits are
			MIME		Used by

	name space:	ACCESS		Used by client

	server details:	HOST, PORT	used by client, protocol-dependent
	
	local doc id:	PATH		used by server only

	anchor id: 	(none)		used by presntation application only

	It seems useful to maintain the ability to work out which
	bits are seen by whom.

	I only used punctation to separate these parts in the W3 UDI
	because people like internet addresses and mail addresses
	and filenames and telephone numbers and message-ids and
	room numbers and zip codes which don't have tags and
	do make do with punctuation.  If the groundswell of
	opionion on this list is that tags are better, then
	let's use tags!

	Whatever we sue, it should be as quotable in an SGML
	attribute as in a MIME external reference as in a
	scribbled note or a link-pasteboard or whatever.
	(The U is for Universal, NOT Unique!)

PHILOSOPHY

	In the W3 world, the model is of a dynamic world of
	documents which generally have some "home" or
	(or several), which can be found using sufficient
	intelligence and the help of ones friends given the UDI.

	A mail message has no home, and so in principle the parts
	of it have no home. When a hypertext multipart message
	(really consisting of multiple hypertext documents)
	has links between its parts they refer to each other
	within a completely isolated conetext.

	There are now two possibilites when the message is in fact
	archived and made readable. One is we say that the parts
	are then addressed as parts ofthe message, wherever it
	may be. The other is to say that the parts of the message
	are very likely things which had some original home.
	In that case, the message is just giving the reciever
	a copy to save him the (perhaps insurmountable) trouble
	of retrieving it.  In this case the parts should be
	identified with thier original UDIs so that the
	receiver is not confsed with multiple documents which
	are in fact the same thing. 
	

I think that's all the comments I have on what I've read so far..

	Tim
________________________________________________________________
Tim Berners-Lee
World-Wide Web initiative
CERN, 1211 Geneva 23, Switzerland        timbl@info.cern.ch
Visiting MIT: NE43-513, (617)234 6016    timbl@zippy.lcs.mit.edu














From wathu@lanka.ccit.arizona.edu  Thu Jun 11 19:58:10 1992
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20867; Thu, 11 Jun 92 19:58:10 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21933; Thu, 11 Jun 92 19:58:18 +0200
Return-Path: wathu@lanka.ccit.arizona.edu
Received: from Lanka.CCIT.Arizona.EDU by Arizona.edu (PMDF #12663) id
 <01GL32SFED9CAL44H9@Arizona.edu>; Thu, 11 Jun 1992 10:36 MST
Received: by lanka.ccit.arizona.edu; Thu, 11 Jun 92 10:37:01 MST
Date: Thu, 11 Jun 92 10:37:01 MST
From: wathu@lanka.ccit.arizona.edu (Wije Wathugala)
Subject: SGML Converters
To: www-talk@nxoc01.cern.ch
Cc: wathu@arizona.edu
Message-Id: <9206111737.AA05287@lanka.ccit.arizona.edu>
X-Envelope-To: www-talk@info.cern.ch

SGML Converters
===============

We are in the process of setting up a WorldWideWeb (WWW) server for computer
center documentation.  Our current documents are in many different 
word processor formats, such as Ventura, WordPerfect (DOS), MS-Word (Mac)
TeX, LaTeX, PostScript, RTF and etc.  We would like to convert them to SGML 
so that we can link them to WWW.

We would like recommendations for good products (commercial or free).
If any of you have tried this type of conversions, please comment on 
your experiences.

Thank you

Wije Wathugala
wathu@arizona.edu

Note: This was also posted to comp.text.sgml


From timbl  Thu Jun 11 20:19:28 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20943; Thu, 11 Jun 92 20:19:28 MET DST
Date: Thu, 11 Jun 92 20:19:28 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206111819.AA20943@ nxoc01.cern.ch >
To: www-talk@nxoc01.cern.ch
Subject: Paper on use of W3, anyone? NSC-92 Pisa

From nir-request@kona.cc.mcgill.ca Mon Jun  8 14:03:43 1992
Return-Path: <nir-request@kona.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10963; Mon, 8 Jun 92 14:03:39 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14481; Mon, 8 Jun 92 14:01:45 +0200
Received: by kona.cc.mcgill.ca (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA00594  on Mon, 8 Jun 92 07:42:58 -0400
Received: from relay.cdnnet.ca by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA00590  (mail destined for /usr/lib/sendmail -odq -oi -fnir-request nir-out) on Mon, 8 Jun 92 07:42:50 -0400
From: Jill.Foster@newcastle.ac.uk
Received: by relay.CDNnet.CA (4.1/1.14)
	id AA11925; Mon, 8 Jun 92 04:42:40 PDT
Date:  7 Jun 92 17:24 +0100
To: nir@cc.mcgill.ca
Reply-To: Jill.Foster@newcastle.ac.uk
Message-Id: <emu-ov07.1992.0607.172441.cl54(a)uk.ac.ncl.mts>
Subject: PISA conference: paper deadline extended
Status: RO

 This is being posted to several lists.
 
 The deadline for papers for the Network Services Conference has been
 extended to June 21st.  I'm particularly keen to see papers on
 information services and perhaps someone could do a "consumer report"
 on some of the applications such as WWW, WAIS, Gopher archie etc.  -
 with particular emphasis on the information management tools (for the
 information providers).
 
 I'm also interested in papers for the user support sections, and would
 like to see case studies presented in building "electronic
 communities".
 
 I'll forward any papers sent to me - or you can forward them to the
 conf.  secretariat as indicated below.
 
 Thanks,
 
 Jill Foster
--------------------------- cut here --------------------------------
 
              First Call for Participation / Call for Papers
                                  NSC'92
                  The Network Services Conference 1992
                     Pisa, Italy, November 3-5, 1992
 
 
                Network Services Conference 1992
 
                            Overview
 
 
 The world of  academic and research networking has evolved  to the point
 where  the  protocol  wars  have  become  largely  irrelevant.  This  is
 demonstrated  by the  recent appearance  of high-level  networking tools
 which  are worldwide  in scope  and which  run simultaneously  over many
 different lower layers.
 
 NSC 92  will focus on  issues in  providing services to  customers, with
 special attention  paid to the  recent and exciting developments  in new
 global high-level tools such as  World-Wide Web, Prospero, Archie, Alex,
 Gopher, and WAIS. We will address the  impact of the new global tools on
 service development and  support, the  changing function  of traditional
 tools and services  (such as archives), upcoming  specific services such
 as new  databases, and the future  role of the library.  User support at
 the campus level, and the role  of support in accessing global services,
 will be addressed.
 
 The conference will be of greatest interest to network service providers
 and sophisticated users  who are changing their focus  from providing or
 obtaining  bandwidth  to  offering,  supporting, and  using  varied  and
 powerful services.  Talks and  other conference activities  will address
 the  needs   of  the  research,  academic,   educational,  governmental,
 industrial, and commercial network communities.
 
 NSC 92  is being  organized by EARN  in conjunction  with EUnet/EurOpen,
 NORDUnet, RARE, and RIPE.
 
     Conference Venue
 
 Pisa is situated in Tuscany on the Arno river. The Italian poet Gabriele
 D'ANNUNZIO named  Pisa's Piazza della  Torre: "The Square  of Miracles",
 and yet the definition could be extended with equal justice to the whole
 city. Pisa is not  only an art center with few rivals;  it is steeped in
 culture  and  science  and  offers  an  up-to-date  infrastructure.  The
 conference will  be held  at the  Palazzo dei  Congressi, near  the city
 center and at walking distance to the Hotels.
 
     Program and Registration Information
 
 The conference program with information on how to register will be
 distributed with the second announcement around 1 August 1992.
 
     Papers
 
 Papers for presentation at the conference are solicited in the following
 areas:
 
 -  Dealing with the Information Explosion
    . New Global Information Access Tools
    . Utilizing Established Information Access and Distribution Tools
 
 -  Managing Global Network Information Services
    . Coordination/Duplication, Security, Privacy, Authentication
    . Closed Group Applications
 
 -  The Electronic Library
    . Local Databases, Remote Databases, OPACS, CD/ROMS
    . Inter-Library Cooperation
 
 -  User / Customer Support
    . Help Desks, Documentation, Reaching the Customers
 
 -  Assessing Customer Needs
 
 -  Special Interest Communities
 
 -  Group Communication Technologies & Services - "Groupware"
 
 -  Networking for Schools
 
 -  Delivering Messaging to the Desktop
    . Practical Experiences, Products, Security, Interface issues
 
 -  Beyond ASCII
    . Character sets, Multimedia
    . Creating, Encoding, Receiving
 
 -  Economic Aspects of Networking
    . Bandwidth, E-mail Access, Efficiency, Control
 
 -  Recent European Networking Developments
 
 Please submit  title and abstract,  by mail, fax or  PREFERRABLY e-mail,
 not later than 31 May 1992 to:
 
   Hans Deckers (DECK@FRORS12.BITNET)
   EARN Office
   c/o CIRCE
   BP 167
   F91403 Orsay France
   Tel: +33 1 6982 3973
   Fax: +33 1 6928 5273
 
     Posters and Demonstrations
 
  A poster  wall will  be available  to participants  for the  display of
  their posters and  projects. A terminal room with  connectivity to EARN
  and the Internet will be available to delegates.
 
  A  room will  be available  for  workstations and  PCs to  be used  for
  demonstrations. An Ethernet connected to the Internet will be available
  in the room. Connectivity to the Internet  will be via a 64Kbps line to
  CNUCE. The minimum bandwidth between  CNUCE and CERN is 512Kbps. People
  interested in  setting up  demonstrations may  send their  questions to
  NSCINFO@FRORS12.BITNET
 
     Further Information and General Inquiry
 
  Further  information will  be available  through an  ad hoc  conference
  mailing list.  If you want to  make sure you receive  the invitation as
  well  as the  preliminary program  please ask  for subscription  to the
  conference mailing  list ( NSC92@FRORS12.BITNET )  sending mail, e-mail
  or fax specifying your e-mail address to:
 
   Nadine Grange  (GRANGE@FRORS12.BITNET)
   EARN Office
   c/o CIRCE
   BP 167
   F91403 Orsay France
   Tel: +33 1 6982 3973
   Fax: +33 1 6928 5273
 
  General inquiries can be made at NSCINFO@FRORS12.
 
 
     Program and Organizing Committee
 
     Program Committee
 
    Dennis  Jennings, Ireland  (Chair);  Rob  Blokzijl, the  Netherlands;
    Daniele  Bovio,  France;  Paul  Bryant, United  Kingdom;  Avi  Cohen,
    Israel;  Laszlo  Csaba,  Hungary;  Hans  Deckers,  France;  Jean-Loic
    Delhaye, France; Jill Foster, United Kingdom; Frode Greisen, Denmark;
    Glenn Kowack,  the Netherlands; Stelios Orphanoudakis,  Greece; David
    Sitman, Israel; Stefano Trumpy, Italy
 
     Organizing Committee
 
    Frode  Greisen,  Denmark  (Chair  );  Hans  Deckers,  France;  Dennis
    Jennings,  Ireland; Glenn  Kowack,  the  Netherlands; Marco  Sommani,
    Italy
 
 
     Corporate Sponsors (Preliminary list )
 
    IBM


From connolly@pixel.convex.com  Fri Jun 12 03:31:28 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21811; Fri, 12 Jun 92 03:31:28 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14764; Fri, 12 Jun 92 03:31:33 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12883; Thu, 11 Jun 92 20:31:12 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA29502; Thu, 11 Jun 92 20:31:09 -0500
Message-Id: <9206120131.AA29502@pixel.convex.com>
To: timbl@zippy.lcs.mit.edu (Tim Berners-Lee)
Cc: enag@ifi.uio.no, www-talk@nxoc01.cern.ch
Subject: Re: MIME, SGML, UDIs, HTML and W3 
In-Reply-To: Your message of "Thu, 11 Jun 92 12:22:56 EDT."
             <9206111622.AA03819@zippy.lcs.mit.edu> 
Date: Thu, 11 Jun 92 20:31:08 CDT
From: Dan Connolly <connolly@pixel.convex.com>


Now my comments on your comments:

>There is no reason why we shouldn't try both protocols.
>If they map well onto each other, its just a question
>of having two separate prasers at the low level, building
>the same internal structures.
>
On the other hand, I'd like to keep a telnet based protocol
around -- maybe gopher is good enough.

>When we're talking about an SGML representation,
>and describe a file to come later down the link,
>I don't think we have to use the NOTATION= attribute with a notation
>type, because we won't in fact be talking about
>the notation of an SGML element.
>The format in this case is not something which the SGML
>parse is aware of.
>
I don't believe this is true. From the horse's mount (Erik Naggum, that is):
----
|   What's the scoop? Do we have to use external entities for raw data?

Yes.  An external entity that is not an SGML text entity requires a
notation identifier, so you only need to list the entities in the DTD,
with notation, and refer to them by name in the document instance.

----

>1. MIME classification of data formats
>
>	 So I'd
>	back the use of these for W3.
>
Yeah!!

>
>2. The MIME format for multi-part messages
>
>	This is necessary for sending a multi-part
>	document over a mail link.  We have to ask ourselves
>	whether it is reasonable to use over a binary link.
>	Personally, my initial impression is that the MIME
>	stuff, using as it does terminators such as
>	--xxx-- separated by blank lines, looks more horrible
>	to work with in this respect than SGML!

The algorithm to separate a MIME multipart message into its
parts is simply: search the data stream for CRLF--boundary--CRLF.
It can be done by a finite state machine. Even the simplest
SGML documents require a pushdown automaton to parse.

> Still we have
>	the problem of restrictions on the content:
>	Must not contain delimiters, limited 7 bit character set,
>	line orientation, in fact all the things which email
>	carries as a restriction.  This is really taking on board
>	a legacy of all the mail which has evolved over the years.
>	Do we need that for our new ultra-fast hypertext access
>	protocol?
>

No, we don't. MIME _allows_ transfer of data over 7 bit ASCII
channels, but it hardly requres it. The Content-transfer-encoding
can be:
	7 bit (default): line oriented 7 bit data
	8 bit : line oriented 8 bit data
	binary : raw 8 bit data, no CRLF's required
	base64: uuencode standardized
	quoted-pritable: text with escape sequences

The MIME standard explicitly supports expansion to 8 bit transport
mechanisms.

>	[Compare the MIME format with the rather cleaner NeXT
>	Mail format which is as far as I understand simply
>	a uuencoded compressed tar file of all the bits, where
>	uuencoding is designed as an optimal way of getting over
>	mail transport restrictions, compress does what it says
>	and tar is a multipart wrapper designed for that only. Not
>	standard outside unix, perhaps, but cleaner in that the
>	mail formatting is done at the last minute and doesn't
>	affect the other operations]
>
It was a requirement of MIME that the structure of the document
be accessible without decoding or uncompressing data, especially
since MIME messages are recursive and complex messages might
otherwise go through more than one encoding.

Compression was not addressed by the MIME standard, and uuencode
doesn't make it though some gateways.

>	If course, with HTTP2, multipart/alternative shouldn't
>	be needed.
>
What does HTTP2 define that obviates the multipart/alternative
type?


>  Multipart for hypetext?
>
>	Now, Dan not only suggests the use of this for
>	multipart messages, but also suggests that a hypetext
>	document shoudl necessarily contain many parts,
>	one on SGML and one for each link as a MIME external document.
>	This means that an SGML hypertext document can never stand
>	on its own!

That's exatly the point. Anything besides text should be handled
as an external entity to be resolved by the parsing system. I just
suggested that a portable way to resolve SGML external entities
is to refer to MIME attachments.

> An SGML parser will always need to have
>	a MIME parser sitting just outside.  I don't like
>	this: I feel we have to separate these two things.
>
Well, it has to have something sitting outside. The SGML parsers
I've seen resolve system entities using the file system. I proposed
we use a MIME message like a mini file system, with links to
other file systems.

>	Suppose that an SGML document does want to
>	be sent in a MIME message and does want to
>	refer to other parts of that MIME message. In that case,
>	it seems reasonable to have a format for that.
>	However, when an SGML document is seen by itself, and
>	refers to a news message for example, then there is
>	no resaon for it not to be able to contain a
>	complete reference within itself.
>
OK, I can see that we should be able to resolve the lexical
issues and put the whole UDI/MIME access specification inside
the SGML document.

But what about multimedia web nodes?

SGML describes text and references to other texts just fine.
But if we want a format that can include more than just
text, I don't think we should try to fit it _inside_ SGML.

I think SGML should be used to convey text and document
structure. But I still like the idea of wrapping it in
a MIME message for multimedia interoperability.


>3. The MIME format for rich text.
>
>	Here, I am not so impressed.
Nor am I.


>4. The MIME format for external document addresses (MIME UDIs)
>
>	As Ed <emv@msen.com> says, this is a bit of a non-issue,
>	as MIME addersses and currnet style UDIs map onto
>	each other. However, we have to agree on a "concrete
>	syntax" (or two... :-) in the end.
>
Exactly. And why not the MIME concrete syntax?

>	Let me say that I personally don't much care about the
>	arbitrary punctuation. There are a few things, though,
>	which are important:
>
>	-  The thing should be printable 7-bit ASCII.
>
MIME: check.

>	   Unlike arbitrary document formats,
>	   UDIs must be sendable in the mail
>
MIME: check.

>	- White space should not be significant. I would
>	  accept the presence of some arbitrary white space
>	  as a delimiter, but one cannot distinguish between
>	  different forms and quantities of white space.
>	  This is because things get wrapped and unwrapped.
>
MIME: check.

>	  Dan, you object to UDIs because they don't
>	  contain white space. But that is purely so that
>	  to CAN wrap them onto several lines and still
>	  recuperate them.  You can put white space
>	  in but it shouldn't mean anything. (This is not possible
>	  in W3 as is but it is in the UDI document)
>
I must not have read the UDI document closely. I certainly
got the impression that a UDI should look like one word
when "written on the back of an envelope."

>	  I don't see why you say they
>	  can't be put as an SGML attribute. They are just
>	  text strings.

The WAIS UDIs are huge. An SGML declaration defines a maximum
for the length of an attribute value. The default value is ...
oh. ahem. it's 960. I think the MIME 72 character line length
is a little more restrictive than that :-)

> They will be quoted of course
>	  (Yes, I know the old NeXT browser doesn't quote them)
>	  Is that not allowed? What are the problem characters?
>	  If there SGML problem characters in the UDI spec, they
>	  probably are ruled out of SGML for a reason.
>
Good question. These are the things we should research before
we go _any_ further implementing this stuff.

>	Whatever we sue, it should be as quotable in an SGML
>	attribute as in a MIME external reference as in a
>	scribbled note or a link-pasteboard or whatever.
>	(The U is for Universal, NOT Unique!)
>
Here's an idea for a quoting strategy for the four parts: Either
	a) it'a a quoted string delimited by "" with \" allowed
	in the middle, or
	b) it's a base-64 representation of an arbitrary
	binary stream.
Just an idea.

I'm late for an appointment. Gotta go.

Dan

From davis@willow.tc.cornell.edu  Fri Jun 12 13:51:03 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22825; Fri, 12 Jun 92 13:51:03 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06860; Fri, 12 Jun 92 13:51:11 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA27811; Fri, 12 Jun 92 07:52:59 EDT
Date: Fri, 12 Jun 92 07:52:59 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206121152.AA27811@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: file: access does not use RCP?

It would be a good idea if WWW tried to use RCP for
file access in addition to using anonymous FTP.

(I think it does not use RCP because I made a link to a file
on another computer and WWW was not able to access it.  But
I was able to RCP the file.  I set up a link to a different
file to which I verified anonymous FTP access, and that worked
fine.)

I would guess that RCP copying would be faster than FTP, so
maybe it should be tried first.

Best wishes... Viola and WWW are excellent.


From timbl  Fri Jun 12 18:11:08 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23957; Fri, 12 Jun 92 18:11:08 MET DST
Date: Fri, 12 Jun 92 18:11:08 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206121611.AA23957@ nxoc01.cern.ch >
To: davis@willow.tc.cornell.edu, www-talk@nxoc01.cern.ch
Subject: Re: file: access does not use RCP?

Good idea -- I guess RCP would be faster, though I don't
know the protocol. The client code would have to keep a
list of hosts for which it had succeded with one or other method,
to save time always trying rcp first on distant sites.

Something for the agenda...
Where is the rcp protocol defined?

Tim BL

From peterson@choctaw.csc.ti.com  Fri Jun 19 20:30:42 1992
Return-Path: <peterson@choctaw.csc.ti.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16044; Fri, 19 Jun 92 20:30:42 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05105; Fri, 19 Jun 92 20:30:59 +0200
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA26952; Fri, 19 Jun 92 13:30:22 CDT
Received: from choctaw.csc.ti.com (choctaw) by tilde.csc.ti.com id AA29287; Fri, 19 Jun 1992 13:29:16 -0500
Received: by choctaw.csc.ti.com (4.1/SMI-4.1)
	id AA23472; Fri, 19 Jun 92 13:29:15 CDT
From: peterson@choctaw.csc.ti.com (Bob Peterson)
Message-Id: <9206191829.AA23472@choctaw.csc.ti.com>
Subject: Re: MIME, SGML, UDIs, HTML and W3
To: timbl@zippy.lcs.mit.edu (Tim Berners-Lee)
Date: Fri, 19 Jun 92 13:29:14 CDT
Cc: connolly@pixel.convex.com, enag@ifi.uio.no, www-talk@nxoc01.cern.ch,
        timbl@zippy.lcs.mit.edu
In-Reply-To: <9206111622.AA03819@zippy.lcs.mit.edu>; from "Tim Berners-Lee" at Jun 11, 92 12:22 pm
Reply-To: peterson@choctaw.csc.ti.com
Mime-Version: 1.0
X-Mailer: ELM [version 2.3 PL11]

You said:
> 
> 	...
> PHILOSOPHY
> 
> 	In the W3 world, the model is of a dynamic world of
> 	documents which generally have some "home" or
> 	(or several), which can be found using sufficient
> 	intelligence and the help of ones friends given the UDI.

  My group has thought about the identity issue in the context of
object identifiers in a distributed object-oriented database.

> 	A mail message has no home, and so in principle the parts
> 	of it have no home. When a hypertext multipart message
> 	(really consisting of multiple hypertext documents)
> 	has links between its parts they refer to each other
> 	within a completely isolated conetext.

  In the OODB we think of an address (UDI or object identifier) as
relative to some enclosing context.  Different parts of an address make
sense only in the correct context.  For example, the mail system
accesses several address contexts to resolve a mail address such as
peterson@csc.ti.com: .com, ti.com, csc.ti.com, and the email address
namespace.  Each context understands its part and returns a reference
to the next, usually more specific, context.  The program(s) attempting
to resolve the address understand the result of an address lookup, and
use each result appropriately.

  I claim a UDI makes sense only in a particular context.  If a UDI
makes explicit all contexts except the most global, then a UDI easily
refers to a different part of the same multipart message.

> 	There are now two possibilites when the message is in fact
> 	archived and made readable. One is we say that the parts
> 	are then addressed as parts of the message, wherever it
> 	may be.

  This might enable operating on a message when the "home" is the
process' address space, i.e., before the message is placed into a file
system or other addressing context.  In effect the context is the
machine and the process' address space, but these can be, and generally
are, defaulted or assumed rather than explicitly stated.

>	         The other is to say that the parts of the message
> 	are very likely things which had some original home.
> 	In that case, the message is just giving the reciever
> 	a copy to save him the (perhaps insurmountable) trouble
> 	of retrieving it.  In this case the parts should be
> 	identified with thier original UDIs so that the
> 	receiver is not confsed with multiple documents which
> 	are in fact the same thing. 

  I wonder about attaching two UDI's to a message: a (required)
absolute UDI, referring to the original home, and a second (optional)
UDI referring to a "less expensive" copy.  ("Less expensive" is, of
course, arbitrarly defined.)  Think of the latter as a hint, i.e., if
the user attempts to resolve the UDI the system first looks for the
hint and, if found, uses it.  If the hint is absent or fails, then the
system tries to use the (more expensive) required UDI.

  Of course thinking about this might be simpler if we refer to one UDI
with two parts: one required, the other optional.

  Benefits of this approach include retaining the reference to the
original site while, at the same time, supporting replication of the
document in an arbitrary number of locations.  If the optional UDI is
relative to the containing message then (1) the reference never fails,
and (2) performance is excellent.  Retaining the original UDI should
help some applications monitor the original for revisions, e.g., an
archive site could cache a document but check periodically with the
original site for an updated version.  Retaining the original can also
help resolve the validity of a document, e.g., by enabling comparison
of the original and cached copies.

  One could implement the optional UDI as a table external to the
document.  When dereferencing a UDI the table is checked first and, if
the UDI is found, the associated optional UDI is used.  This has the
advantage of not modifying the original document, including not
changing the result of any error detection arithmetic, e.g., checksums.

> 
> I think that's all the comments I have on what I've read so far..
> 
> 	Tim

    Bob

-- 
Bob Peterson             Work: peterson@csc.ti.com              Expressway Site
Texas Instruments        Home: peterson@zgnews.lonestar.org     North Building
P.O. Box 655474, MS238   TIMSG: RWP  Landline: +1 214 995 6080  Aisle A4
Dallas, Tx USA 75265                 FAX line: +1 214 995 0304  2-88V97

From raisch@cthulhu.control.com  Mon Jun 22 19:27:14 1992
Return-Path: <raisch@cthulhu.control.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20886; Mon, 22 Jun 92 19:27:14 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14855; Mon, 22 Jun 92 19:27:25 +0200
Received: by control.com (4.1/Spike-2.0)
	id AA04177; Mon, 22 Jun 92 13:25:37 EDT
From: raisch@cthulhu.control.com (Robert Raisch)
Message-Id: <9206221725.AA04177@control.com>
Subject: Links, Type and Documents (Third time's a charm)
To: www-talk@nxoc01.cern.ch
Date: Mon, 22 Jun 92 13:25:35 EDT
Cc: One@cthulhu.control.com, of@cthulhu.control.com, the@cthulhu.control.com,
        missing@cthulhu.control.com, pieces@cthulhu.control.com,
        here@cthulhu.control.com, is@cthulhu.control.com,
        the@cthulhu.control.com, ability@cthulhu.control.com,
        of@cthulhu.control.com, creating@cthulhu.control.com,
        new@cthulhu.control.com, h-texts@cthulhu.control.com,
        and@cthulhu.control.com
Action: dding new links to old h-texts.
X-Mailer: ELM [version 2.3 PL11]

[ This is the third time I have tried to post this.  Drop me a line,
  Francois, if you see this on the list.  Thanks.  </rr> ]

<!-- 

  I first posted this some weeks ago on the 'www-interest' list, and 
  received only one reply, (complementing me on my reference to Rexx.)

  I really had hoped that this post would start an interesting discussion
  on the topics I address, specifically the ideas of 'attention links' 
  'user documents' and 'transparent documents'.

  Are these ideas so obvious that they merit no discussion whatsoever?

  Always interested in replies, </rr>

 -->

<Preface>
First of all, hearty congrats to the WWW people.  It's a great tool, and
since it is based on SGML, it has the broadest scope of any solution I have
yet seen.

To others, see the current issue of Byte magazine regarding "Info-Glut" and
SGML.  Interesting.


<Query>
One of the missing pieces here is the ability of creating new h-texts, and
adding new links to old h-texts.

Hypertext, and like systems, are of limited use if they do not support
collaboration.  I feel that this is a VERY important point.

When might we expect extensions to WWW that support collaboration?
</Query>
</Preface>

I have a few recommendations regarding new link types in WWW.  This is based
on thinking about hyper-applications for almost 15 years, (ever since I 
first had the pleasure of hearing Ted Nelson speak in 1977.)

Please keep in mind that these are 'front end' issues.  They should not
affect the manner in which documents are stored.

------------------

There are 4 'minimal' link types which, I believe, a true hypertext application
*must* support.

	1.	Replacement
			-- when activated, replaces the current document
			   with a new document, (this is what WWW offers
			   today).

	2.	Annotation
			-- when activated, overlays a new document on the
			   current document, partially obscuring the original.
			   (An annotation must be dismissed by the reader.)

	3.	Inclusion
			-- when the document is created, elements from other
			   documents are collection to be included in the
			   representation of the current document.  (Quotes)
			   (This is a non-interactive link.  The user does
			    not activate this link. It is activated before 
			    the document is presented to the user.)

	4.	Expansion
			-- when activated, new information is added to the 
			   current document, expanding the original scope.

			   (Think of outline processors, and the collapse
			    of detail.)  

			   This is also a reflection of Nelson's concept of 
			   'stretch text'.  

			   A stretch-text definition of "stretch text" might be:

{Collapsed}		   "Stretch text is{}a sentence{}that when{}collapsed
			    states it's thesis{}and when expanded adds detail." 

{Expanded}		   "Stretch text is where a sentence is constructed in 
			    such a way that when it is collapsed it states it's 
			    thesis in simple terms, and when expanded adds 
			    detail to further express itself."

There are 3 further types which I believe are necessary to complete the
function paradigm.  (Of particular interest is the 'attention link'.)


	6.	Execution

			-- when activated, some arbitrary function is performed.
			   The point that was mentioned about the lack of an
			   ubiquitious scripting language is well made.  Lisp
			   is too arcane for most.  Shell languages are too
			   platform specific.  What is needed is a simple
			   to understand, freely available scripting platform.
			   Although I hesitate to mention it, REXX might be
			   a reasonable choice due to it's broad availability.

	5.	Attention   (a specialisation of the Execution type)

			-- when the current document is modified (a link is
			   added, or removed, or the document is merely read)
			   a message is sent to the 'owner' of the attention
			   link.  This message creates a new link in the 'user
			   document' of the individual who placed the attention.
			   (See definition of 'user document' below.)

			   In this way, I could place a link onto a document I 
			   had interest in, and when it was changed or accessed
			   in some manner, I would be informed.

	7.	Collection  (a non-local specialisation of the Execution type)

			-- when activated, a collection link leaves the current
			   document, and 'travels' the docuverse, in search of
			   other documents which satisfy it's internal criteria.
			   This is the concept of a 'knowbot'.

			   Collection links can be activated based on day and
			   time, much like the WAIS questions in the MAC 
			   WAIS interface, WAIS-Station.  They could also be
			   activated based on external events, such as the 
			   activation of an attention link.

			   Collection links would be written in the ubiquitious
			   scripting language, and would only be allowed to 
			   operate on documents which were EXPLICITLY permitted.


Along with the various links presented, two new varieties of document would
be used.

	Transparent Documents  --

		a transparent document is one which a user creates locally,
		and that is a new representation of an existing document.

		Transparent documents are used to create new local links on
		a document which I do not have permission to modify.

		Transparent documents can then be made available to others,
		(published) just as a "regular" document is, thus facilitating
		the creation of new works from old.

	User Documents --

		a user document is where I keep my "bookmarks", links to
		local documents, links to messages from others, links to
		my "attention" links, (see below).  User documents are where
		we, as navigators of the docuverse, are defined as individuals.

		They are also where we can keep links to other user documents
		which have been permitted to view/modify my own local documents.

		Another function of the User document is to collect users into
		an abstract group. (Thus, based on my membership in user 
		document 'Research Group', I am permitted access to materials
		'owned' by that group. Of course, messages sent to an abstract
		group then become available to all members of that group.)

		(Please note that a User Document is nothing more or less than
		 a collection of links, (as all documents are).)

----------------------------

So.....

	Scenerio:

		I start my session with my hypertext-application, and open 
		my user document.

		I notice that 17 of my attention links have been activated 
		in the last day.

		I select the most interesting and activate the link which
		it created in my personal user document.

		I am now reading an article which I previously linked, and
		see that an annotation which I made some time ago has been
		added to, by a colleague.

		The comments are pertinant to my current work, so I create
		a new local 'transparent' document to mirror the original 
		work.  (Or use the 'transparent' document I may have created
		previously.)

		On this new document, I make a few new annotations and decide
		to made this new work available to the research group of which
		I am leader.  I place a link to it in the user document which
		represents my working group.

		I also send a new document link to the colleague who made the
		original comments, so that he can see how I have interpreted 
		his ideas, and included them into my own research.

		I move ever onwards...

---------------------

Ok, I hope that that fuels a little discussion, and I would *love* to hear 
from others regarding these ideas.  

Regards, </rr>

"knowledge is the *only* weapon"
-- 

From raisch@cthulhu.control.com  Mon Jun 22 19:32:37 1992
Return-Path: <raisch@cthulhu.control.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20902; Mon, 22 Jun 92 19:32:37 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15255; Mon, 22 Jun 92 19:32:51 +0200
Received: by control.com (4.1/Spike-2.0)
	id AA04308; Mon, 22 Jun 92 13:30:55 EDT
From: raisch@cthulhu.control.com (Robert Raisch)
Message-Id: <9206221730.AA04308@control.com>
Subject: Links, Types and Documents (Third time's a charm)
To: jfg@dxcern.cern.ch
Date: Mon, 22 Jun 92 13:30:55 EDT
Cc: www-talk@nxoc01.cern.ch
X-Mailer: ELM [version 2.3 PL11]

[ 
  ARRRGGGGHHHHHH!!!! I goofed.  This is the full message, please 
  disregard the previous one, since I am not sure that it got out
  properly.

  This is the third time I have tried to post this.  Drop me a line,
  Jean Francois, if you see this on the list.  Thanks.  </rr> ]

<!-- 

  I first posted this some weeks ago on the 'www-interest' list, and 
  received only one reply, (complementing me on my reference to Rexx.)

  I really had hoped that this post would start an interesting discussion
  on the topics I address, specifically the ideas of 'attention links' 
  'user documents' and 'transparent documents'.

  Are these ideas so obvious that they merit no discussion whatsoever?

  Always interested in replies, </rr>

 -->

<Preface>
First of all, hearty congrats to the WWW people.  It's a great tool, and
since it is based on SGML, it has the broadest scope of any solution I have
yet seen.

To others, see the current issue of Byte magazine regarding "Info-Glut" and
SGML.  Interesting.


<Query>
One of the missing pieces here is the ability of creating new h-texts, and
adding new links to old h-texts.

Hypertext, and like systems, are of limited use if they do not support
collaboration.  I feel that this is a VERY important point.

When might we expect extensions to WWW that support collaboration?
</Query>
</Preface>

I have a few recommendations regarding new link types in WWW.  This is based
on thinking about hyper-applications for almost 15 years, (ever since I 
first had the pleasure of hearing Ted Nelson speak in 1977.)

Please keep in mind that these are 'front end' issues.  They should not
affect the manner in which documents are stored.

------------------

There are 4 'minimal' link types which, I believe, a true hypertext application
*must* support.

	1.	Replacement
			-- when activated, replaces the current document
			   with a new document, (this is what WWW offers
			   today).

	2.	Annotation
			-- when activated, overlays a new document on the
			   current document, partially obscuring the original.
			   (An annotation must be dismissed by the reader.)

	3.	Inclusion
			-- when the document is created, elements from other
			   documents are collection to be included in the
			   representation of the current document.  (Quotes)
			   (This is a non-interactive link.  The user does
			    not activate this link. It is activated before 
			    the document is presented to the user.)

	4.	Expansion
			-- when activated, new information is added to the 
			   current document, expanding the original scope.

			   (Think of outline processors, and the collapse
			    of detail.)  

			   This is also a reflection of Nelson's concept of 
			   'stretch text'.  

			   A stretch-text definition of "stretch text" might be:

{Collapsed}		   "Stretch text is{}a sentence{}that when{}collapsed
			    states it's thesis{}and when expanded adds detail." 

{Expanded}		   "Stretch text is where a sentence is constructed in 
			    such a way that when it is collapsed it states it's 
			    thesis in simple terms, and when expanded adds 
			    detail to further express itself."

There are 3 further types which I believe are necessary to complete the
function paradigm.  (Of particular interest is the 'attention link'.)


	6.	Execution

			-- when activated, some arbitrary function is performed.
			   The point that was mentioned about the lack of an
			   ubiquitious scripting language is well made.  Lisp
			   is too arcane for most.  Shell languages are too
			   platform specific.  What is needed is a simple
			   to understand, freely available scripting platform.
			   Although I hesitate to mention it, REXX might be
			   a reasonable choice due to it's broad availability.

	5.	Attention   (a specialisation of the Execution type)

			-- when the current document is modified (a link is
			   added, or removed, or the document is merely read)
			   a message is sent to the 'owner' of the attention
			   link.  This message creates a new link in the 'user
			   document' of the individual who placed the attention.
			   (See definition of 'user document' below.)

			   In this way, I could place a link onto a document I 
			   had interest in, and when it was changed or accessed
			   in some manner, I would be informed.

	7.	Collection  (a non-local specialisation of the Execution type)

			-- when activated, a collection link leaves the current
			   document, and 'travels' the docuverse, in search of
			   other documents which satisfy it's internal criteria.
			   This is the concept of a 'knowbot'.

			   Collection links can be activated based on day and
			   time, much like the WAIS questions in the MAC 
			   WAIS interface, WAIS-Station.  They could also be
			   activated based on external events, such as the 
			   activation of an attention link.

			   Collection links would be written in the ubiquitious
			   scripting language, and would only be allowed to 
			   operate on documents which were EXPLICITLY permitted.


Along with the various links presented, two new varieties of document would
be used.

	Transparent Documents  --

		a transparent document is one which a user creates locally,
		and that is a new representation of an existing document.

		Transparent documents are used to create new local links on
		a document which I do not have permission to modify.

		Transparent documents can then be made available to others,
		(published) just as a "regular" document is, thus facilitating
		the creation of new works from old.

	User Documents --

		a user document is where I keep my "bookmarks", links to
		local documents, links to messages from others, links to
		my "attention" links, (see below).  User documents are where
		we, as navigators of the docuverse, are defined as individuals.

		They are also where we can keep links to other user documents
		which have been permitted to view/modify my own local documents.

		Another function of the User document is to collect users into
		an abstract group. (Thus, based on my membership in user 
		document 'Research Group', I am permitted access to materials
		'owned' by that group. Of course, messages sent to an abstract
		group then become available to all members of that group.)

		(Please note that a User Document is nothing more or less than
		 a collection of links, (as all documents are).)

----------------------------

So.....

	Scenerio:

		I start my session with my hypertext-application, and open 
		my user document.

		I notice that 17 of my attention links have been activated 
		in the last day.

		I select the most interesting and activate the link which
		it created in my personal user document.

		I am now reading an article which I previously linked, and
		see that an annotation which I made some time ago has been
		added to, by a colleague.

		The comments are pertinant to my current work, so I create
		a new local 'transparent' document to mirror the original 
		work.  (Or use the 'transparent' document I may have created
		previously.)

		On this new document, I make a few new annotations and decide
		to made this new work available to the research group of which
		I am leader.  I place a link to it in the user document which
		represents my working group.

		I also send a new document link to the colleague who made the
		original comments, so that he can see how I have interpreted 
		his ideas, and included them into my own research.

		I move ever onwards...

---------------------

Ok, I hope that that fuels a little discussion, and I would *love* to hear 
from others regarding these ideas.  

Regards, </rr>

"knowledge is the *only* weapon"
-- 

From M.Hu@cs.ucl.ac.uk  Mon Jun 22 20:56:31 1992
Return-Path: <M.Hu@cs.ucl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21169; Mon, 22 Jun 92 20:56:31 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA18429; Mon, 22 Jun 92 20:56:54 +0200
Message-Id: <9206221856.AA18429@dxmint.cern.ch>
Received: from tooting.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19271-0@bells.cs.ucl.ac.uk>; Mon, 22 Jun 1992 19:53:34 +0100
To: raisch@cthulhu.control.com
Cc: jfg@dxcern.cern.ch, www-talk@nxoc01.cern.ch, M.Hu@cs.ucl.ac.uk
Subject: Re: Links, Types and Documents (Third time's a charm)
In-Reply-To: Your message of Mon, 22 Jun 92 13:30:55 -0500. <9206221730.AA04308@control.com>
Date: Mon, 22 Jun 92 19:55:27 +0100
From: M.Hu@cs.ucl.ac.uk


On Mon, 22 Jun 92 13:30:55 EDT ,
raisch@COM.CONTROL.CTHULHU  wrote:

> 
><Query>
>One of the missing pieces here is the ability of creating new h-texts, and
>adding new links to old h-texts.

I agree with you that it is important for hypertext to create automatically
new h-texts and add new links to old ones. In my point of view, the first
step to realize it is to divide links from the texts. In WWW model, links
are inside the hypertexts, which makes it very difficult.


> 
>Hypertext, and like systems, are of limited use if they do not support
>collaboration.  I feel that this is a VERY important point.


Talking about collaboration of different hypertexts (IT IS VERY IMPORTANT.),
I feel it is more complicating. Interchange of formats of hypertexts and links
among different systems needs a better-structured hypertext model as a core.
WWW can not do it, and furthermore, it is not a good model to do it...

> 
>When might we expect extensions to WWW that support collaboration?
></Query>
></Preface>
> 
>I have a few recommendations regarding new link types in WWW.  This is based
>on thinking about hyper-applications for almost 15 years, (ever since I
>first had the pleasure of hearing Ted Nelson speak in 1977.)
> 
>Please keep in mind that these are 'front end' issues.  They should not
>affect the manner in which documents are stored.
> 
>------------------
>--


Mike

From connolly@pixel.convex.com  Mon Jun 22 21:39:12 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21341; Mon, 22 Jun 92 21:39:12 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19580; Mon, 22 Jun 92 21:39:28 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12765; Mon, 22 Jun 92 14:38:42 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA17202; Mon, 22 Jun 92 14:38:27 -0500
Message-Id: <9206221938.AA17202@pixel.convex.com>
To: raisch@cthulhu.control.com (Robert Raisch)
Cc: jfg@dxcern.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: Links, Types and Documents (Third time's a charm) 
In-Reply-To: Your message of "Mon, 22 Jun 92 13:30:55 EDT."
             <9206221730.AA04308@control.com> 
Date: Mon, 22 Jun 92 14:38:26 CDT
From: Dan Connolly <connolly@pixel.convex.com>


><!-- 
>
>  I first posted this some weeks ago on the 'www-interest' list, and 
>  received only one reply, (complementing me on my reference to Rexx.)
>
I keep my copy of this posting handy and I check lots of ideas against it.

>  I really had hoped that this post would start an interesting discussion
>  on the topics I address, specifically the ideas of 'attention links' 
>  'user documents' and 'transparent documents'.
>
I don't have any well defined systems (implementations or just specs.)
that address these issues. WWW is headed in this direction, but it's
a long way off.
 
>  Are these ideas so obvious that they merit no discussion whatsoever?
>
No, it's more like they're so novel we haven't thought seriously enough
to comment yet.

><Query>
>One of the missing pieces here is the ability of creating new h-texts, and
>adding new links to old h-texts.
>
>Hypertext, and like systems, are of limited use if they do not support
>collaboration.  I feel that this is a VERY important point.
>
>When might we expect extensions to WWW that support collaboration?
></Query>

You might look to Andrew for a more mature system in these regards.
While I think Andrew is a great breeding ground for ideas, I think
the resulting technology is too off-beat (for example, they implemented
their own object-oriented C preprocessor, and now C++ has come along
and writing Andrew code looks like a pain in comparison).

I'm toying with the idea of a FrameMaker inset editor to interface
Frame's direct-manipulation editing capabilities with global
hypertext on the internet. I shouldn't even mention it until I have
some sort of implementation, but it's an idea...

>I have a few recommendations regarding new link types in WWW.  This is based
>on thinking about hyper-applications for almost 15 years, (ever since I 
>first had the pleasure of hearing Ted Nelson speak in 1977.)
>
>Please keep in mind that these are 'front end' issues.  They should not
>affect the manner in which documents are stored.
>
Well, we should be careful not to store documents in a way that
conflicts with these useful concepts.


>------------------
>
>There are 4 'minimal' link types which, I believe, a true hypertext applicatio
n
>*must* support.
>
>	1.	Replacement
>			-- when activated, replaces the current document
>			   with a new document, (this is what WWW offers
>			   today).
>
FrameMaker: gotolink
GNU Info: menus, notes
WWW: <A HREF=...>
EBT: link

>	2.	Annotation
>			-- when activated, overlays a new document on the
>			   current document, partially obscuring the original.
>			   (An annotation must be dismissed by the reader.)
>
FrameMaker: openlink
GNU Info: n/a
WWW: n/a
EBT: link window=new

>	3.	Inclusion
>			-- when the document is created, elements from other
>			   documents are collection to be included in the
>			   representation of the current document.  (Quotes)
>			   (This is a non-interactive link.  The user does
>			    not activate this link. It is activated before 
>			    the document is presented to the user.)
>
FrameMaker: import by reference (bitmapped graphics ONLY)
GNU Info: n/a
WWW: n/a
EBT: n/a

>	4.	Expansion
>			-- when activated, new information is added to the 
>			   current document, expanding the original scope.
>
FrameMaker: conditional text
GNU Info: n/a
WWW: n/a
EBT: change stylesheets so that HIDE property changes

>
>There are 3 further types which I believe are necessary to complete the
>function paradigm.  (Of particular interest is the 'attention link'.)
>
>
>	6.	Execution
>
>			-- when activated, some arbitrary function is performed
.
>			   The point that was mentioned about the lack of an
>			   ubiquitious scripting language is well made.  Lisp
>			   is too arcane for most.  Shell languages are too
>			   platform specific.  What is needed is a simple
>			   to understand, freely available scripting platform.
>			   Although I hesitate to mention it, REXX might be
>			   a reasonable choice due to it's broad availability.
>
Ah... if you want commentary, state an arguable thesis. No one can argue
against a platitude like "What is needed is a simple to undertand,
freely available scripting platform." I vote for some brand of Lisp, perhaps
XLisp or ELK.

But there's a larger issue: should documents be turing machines? Using SGML,
it is a well defined problem to determine whether a document is valid. As
soon as we allow documents to be programs (like TeX, nroff, or Lisp), we
run into the halting problem and we lose any hope of converting documents
from one representation to another. If a document is a program that, when run,
conveys its content, then we lose the ability to use that content in any
other way than the author originally intended.

>	5.	Attention   (a specialisation of the Execution type)
>
>			-- when the current document is modified (a link is
>			   added, or removed, or the document is merely read)
>			   a message is sent to the 'owner' of the attention
>			   link.  This message creates a new link in the 'user
>			   document' of the individual who placed the attention.

Hmmm... I need a clear explanation of the underlying model here. In the
model in my mind, a "document" is never modified. But the functionality
you describe is interesting. Certainly we want to be able to collect
usage statistics.

>	7.	Collection  (a non-local specialisation of the Execution type)
>
>			-- when activated, a collection link leaves the current
>			   document, and 'travels' the docuverse, in search of
>			   other documents which satisfy it's internal criteria.
>
>			   This is the concept of a 'knowbot'.
>
It looks like a query to me. I need either 1) a good definition of the
capabilities of a knowbot, or 2) an implementation of a knowbot (any
sort of hack will do) to get a feel for the functionality. Until
then, it's just a very vague idea. Fortunately, there are some
implementations of this idea: cron/find, WAIS, USENET news (kill files, etc.)

>
>	Transparent Documents  --
>
>		a transparent document is one which a user creates locally,
>		and that is a new representation of an existing document.
>
>		Transparent documents are used to create new local links on
>		a document which I do not have permission to modify.
>
>		Transparent documents can then be made available to others,
>		(published) just as a "regular" document is, thus facilitating
>		the creation of new works from old.
>
This looks like a local copy of a document to me. No?

>	User Documents --
>
>		a user document is where I keep my "bookmarks", links to
>		local documents, links to messages from others, links to
>		my "attention" links, (see below).  User documents are where
>		we, as navigators of the docuverse, are defined as individuals.
>
>		They are also where we can keep links to other user documents
>		which have been permitted to view/modify my own local documents
.
>
>		Another function of the User document is to collect users into
>		an abstract group. (Thus, based on my membership in user 
>		document 'Research Group', I am permitted access to materials
>		'owned' by that group. Of course, messages sent to an abstract
>		group then become available to all members of that group.)
>
>		(Please note that a User Document is nothing more or less than
>		 a collection of links, (as all documents are).)
>
Now we've opened up the whole PIM can of worms. Current implementations
include mail user agents (MH, Elm), news readers (with their .newsrc and
kill files, etc.) wais-questions, WWW home documents. I haven't looked
at the hyperbole model, but I understand it addresses this issue at length.

>So.....
>
>	Scenerio:
>
I'd like to see how a MIME user agent would satisfy this scenario...

>		I start my session with my hypertext-application, and open 
>		my user document.
>
I start my MIME UA.

>		I notice that 17 of my attention links have been activated 
>		in the last day.
>
There are 17 mail messages (with certain tell-tale headers) in my inbox.

>		I select the most interesting and activate the link which
>		it created in my personal user document.
>
I read the message. It's a message/external-body type message that points
to an article in a USENET database at this site.

>		I am now reading an article which I previously linked
that is, I had saved the article by creating a message/external-body
type message in my mail box.

>		, and
>		see that an annotation which I made some time ago
i.e. my followup article

>		 has been
>		added to, by a colleague.
>
i.e. has been followed-up.

>		The comments are pertinant to my current work, so I create
>		a new local 'transparent' document to mirror the original 
>		work.  (Or use the 'transparent' document I may have created
>		previously.)
>
I just save a reference to the news artile, as above, in a message/external-body
type message.

>		On this new document, I make a few new annotations

i.e. I follow up to the document. It would be nice to be able to do
some direct-manipulation style annotation to articles, ala FrameMaker.

>		and decide
>		to made this new work available to the research group of which
>		I am leader.  I place a link to it in the user document which
>		represents my working group.
>
I mail a message/external-body style reference to the thread to the
alias that represents my working group.

I really think that Internet Mail, Usenet News, and WAIS could be
a great platform for CSCW. A MIME user agent that could make
WAIS and NNTP queries and act as a FrameServer client would
be a great start. If I have time, I'll try to cook something up.

Dan

From HARMO@valt.helsinki.fi  Tue Jun 23 10:01:10 1992
Return-Path: <HARMO@valt.helsinki.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22326; Tue, 23 Jun 92 10:01:10 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29759; Tue, 23 Jun 92 10:01:30 +0200
Received: from charon-gw.pc.Helsinki.FI by kruuna.helsinki.fi with SMTP id AA04453
  (5.65c/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Tue, 23 Jun 1992 11:00:35 +0300
Received: From HYLKN1/WORKQUEUE by charon-gw.pc.Helsinki.FI
          via Charon 3.4 with IPX id 100.920623110021.448;
          23 Jun 92 11:00:49 +0200
Message-Id: <MAILQUEUE-101.920623105426.28@valt.Helsinki.FI>
To: jfg@dxcern.cern.ch, www-talk@nxoc01.cern.ch
From: "Timo Harmo - SocSci U of Helsinki"  <HARMO@valt.helsinki.fi>
Date:     23 Jun 92 10:54:27 EET
Subject:  Re: Links, Types and Documents (Third time's a charm) 
X-Pmrqc:  1
X-Mailer: Pegasus Mail v2.2 (R3).

> > 3.  Inclusion
> >             not activate this link. It is activated before
> >             the document is presented to the user.)

Is this something that could be done by the server?

> > 6.  Execution
> freely available scripting platform." I vote for some brand of
>Lisp, perhaps  XLisp or ELK.
How about a simple Prolog? Prolog is quite hypertextish and relatively
easy to implement (I suppose).
 -Timo


From bridges@nas.nasa.gov  Tue Jun 23 19:03:22 1992
Return-Path: <bridges@nas.nasa.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25071; Tue, 23 Jun 92 19:03:22 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07321; Tue, 23 Jun 92 19:03:46 +0200
Received: by orville.nas.nasa.gov (5.61.a/1.34)
	id AA21186; Tue, 23 Jun 92 10:03:15 -0700
Date: Tue, 23 Jun 92 10:03:15 -0700
From: bridges@nas.nasa.gov (Michael D. Bridges)
Message-Id: <9206231703.AA21186@orville.nas.nasa.gov>
To: www-talk@nxoc01.cern.ch
Subject: add me to mailing list


Please add me to your www-talk mailing list.

                                Thank you,
                                                Mike Bridges
                                                NASA/AMES
                                                bridges@nas.nasa.gov


From koellner@lbl.bitnet  Tue Jun 23 19:13:52 1992
Return-Path: <koellner@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25120; Tue, 23 Jun 92 19:13:52 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07876; Tue, 23 Jun 92 19:14:18 +0200
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R1)
   with BSMTP id 2560; Tue, 23 Jun 92 19:13:30 SET
Received: from Lbl.Bitnet by CEARN.cern.ch (Mailer R2.07B) with BSMTP id 7452;
 Tue, 23 Jun 92 19:13:30 SET
Date:    Tue, 23 Jun 92 10:13:02 PDT
From: koellner@lbl.bitnet (Werner Koellner, LBL)
Message-Id: <920623101302.23e16263@csa3.lbl.gov>
Subject: WWW (Viola) question
To: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"www-talk@info.cern.ch"

                                         LBL, Physics Division, 23-JUN-1992

    Hi,
         what might be the cause of the following error message when I
         start up WWW?

    Unknown character: 43WWW: home = /home/ux5/ux5c/phyd/cern/WWW/lbl.html

                  Best regards,

                                   Werner

From jfg@dxcern.cern.ch  Tue Jun 23 20:34:17 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25415; Tue, 23 Jun 92 20:34:17 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10610; Tue, 23 Jun 92 20:34:39 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA25813; Tue, 23 Jun 92 20:34:11 +0200
Date: Tue, 23 Jun 92 20:34:11 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206231834.AA25813@dxcern.cern.ch>
To: koellner@lbl.bitnet (Werner Koellner, LBL)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: WWW (Viola) question
References: <920623101302.23e16263@csa3.lbl.gov>

	Werner,

  This may be a problem either with Viola, or with the home document
you're trying to read. Try it with the line-mode browser:

	www /home/ux5/ux5c/phyd/cern/WWW/lbl.html

and see if it works. Did you create the lbl.html yourself ? In any
case, you can mail it to me (privately to not bother the list) and
I'll tell you if there's something wrong with it. Are you trying to
set up a WWW server about LBL ? That would be great !

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"Life may at times be boring, but is it more fun to be dead ?"
                                                  -- Alcor


From davis@willow.tc.cornell.edu  Wed Jun 24 17:47:51 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28638; Wed, 24 Jun 92 17:47:51 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02889; Wed, 24 Jun 92 17:48:17 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA13062; Wed, 24 Jun 92 11:49:48 EDT
Date: Wed, 24 Jun 92 11:49:48 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206241549.AA13062@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: logical types of links (Re:  Links, Types and Documents)

I want to take issue with the set of links proposed by R Raisch.  They
are very intriguing and I praise him for bringing them up, while also
apologizing for not responding to them sooner.  This is the first
of several letters addressing some problems I see in his proposal
and some general issues for WWW and hypertext which are raised
by his list.

In this message, I want to discuss the logical types of links.  It
seems to me that hyperlinks could encoding knowledge of several
different types.  Three that come to mind are:

1 structural - relations between documents, e.g. document X cites
document Y; word X is defined in document Y; possibly extending to
the kind of argumentation links used in e.g. gIBIS, NoteCards (e.g.
claim X is refuted by argument Y)

2 presentation - the user should see X and Y at same time if possible.

3 construction - to build document X, include files Y and Z, and
run procedure W at display time.

It is not obvious to me that these three should be treated in the
same way.  In particular, I doubt the need for presentation information.
The lesson of SGML is that documents should be marked with logical
structure, leaving presentation out.

It also seems to me that Raisch's list mixes several types, and
this is undesirable.

For example, I see the "annotation" link as encoding presentation
information.  It differs from "replacement" only in that you see the
original and the target at the same time.  (At least, that's how he
describes it.  One could also define it as a kind of logical relation
- it is a comment on the target.  But that's a different subject.)

A second example is that one might want to use an "Execution" link (or
its subtype "collection") to implement any of the first four types
(replacement, annotation, inclusion, expansion).

To continue the discussion, we might consider whether there are
other logical types for links, how to decompose Raisch's links 
into these categories, and whether to encode presentation in links.

Best wishes

From davis@willow.tc.cornell.edu  Wed Jun 24 17:53:39 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28667; Wed, 24 Jun 92 17:53:39 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03527; Wed, 24 Jun 92 17:54:04 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA13109; Wed, 24 Jun 92 11:55:33 EDT
Date: Wed, 24 Jun 92 11:55:33 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206241555.AA13109@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re:  Links, Types and Documents

In considering R. Raisch's link types, it seems to me that the
expansion and replacement can be combined and generalized.  In both
cases portion of the document is replaced.  In expansion case, the
condensed text is replaced (perhaps temporarily) with the enlarged
text, in replacement the entire document is replaced with some other.
So the more general case is a link which labels a range in both the
source and target document.  The replacement link labels the entire
document, the expansion labels only a portion.

As for execution links in general, I see Dan's point that adding
procedures to documents makes them difficult to manipulate.  And N
Borenstein has pointed out (in Mime) the dangers of executing
arbitrary code.  But I still see that there are functions which only
code can provide, and so we just face the challenge of designing a
language that is both powerful and safe, perhaps sacrificing Turing
completeness.  Is Atomicmail [tm?] such a language?


From davis@willow.tc.cornell.edu  Wed Jun 24 17:58:51 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28710; Wed, 24 Jun 92 17:58:51 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03786; Wed, 24 Jun 92 17:59:18 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA13167; Wed, 24 Jun 92 12:00:50 EDT
Date: Wed, 24 Jun 92 12:00:50 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206241600.AA13167@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Links that refer to a range of text, not just a point.

In my last piece of mail (I hope they arrive in order) I tried to
generalize replacement and expansion links.  But this way of
describing links presupposes that links have a range in the source
document.  You need this (or is this obvious?) e.g. because you must
know whether an annotation applies to the entire document, a section,
or just one word.  Likewise for replacements, you need to know how
much to replace.

But as far as I know, in most (all?) hypertext systems, the origin and
destination of links are points.  Certainly this is true in WWW, e.g.
The destination of a link is a position in a document, never a section
of a document.  On the other hand, in some sense WWW's Anchors do label
a region of the origin, since the anchor has an explicit beginning
and end.

But then this raises another issue: does WWW allow anchors within
anchors?  I think not - in which case I could not use WWW anchors to
both label a paragraph (e.g. for attaching an annotation) and a word
within it (e.g. for definition).  This worries me quite a bit.  Nor
can I attach multiple links to the same point (e.g. definitions of a
word in multiple languages).


From davis@willow.tc.cornell.edu  Wed Jun 24 18:00:30 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28723; Wed, 24 Jun 92 18:00:30 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03892; Wed, 24 Jun 92 18:00:54 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA13181; Wed, 24 Jun 92 12:02:25 EDT
Date: Wed, 24 Jun 92 12:02:25 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9206241602.AA13181@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject:  Raisch's Attention link
Cc: 
Mime-Version: 1.0
Content-Type:  text/richtext
Content-Transfer-Encoding:  7bit

<paragraph>
In a previous message, R. Raisch proposed a number of interesting
link types.  One of them was the attention link, which I want to
discuss here.  I am uncertain about the need for this link, the
technical ability to provide it, and the definition.

<nl>
<paragraph>
Let me discuss the function first.  The function seems to be
providing a means of notifying an "owner" of a document when certain
conditions obtain.  The conditions Raisch mentions are:<nl>
<indent>
 1) someone has read the document<nl>
 2) someone has modified the document<nl>
</indent>

<nl><paragraph>
There is some doubt in my mind about read notifications.  I am not sure I
want other people to know what I read.  I can see only two reasons
for this feature:<nl>
<indent>
 1) as a form of "proof of delivery".  Some email systems provide
this, but I don't like it.<nl>
 2) as a means of collective revenue (pay-per-read)<nl>
</indent>

<nl><paragraph>
As for charging, fairness requires that the link not be activated
until I have seen a warning (otherwise I might get charged a zillion
dollars to read the document - just like 900 phone numbers in the
USA).  So this will add complexity to the client.

<nl><paragraph>
Also, attention links are not sufficient for a charging.  They
support a model where I am charged once per read, no matter how much
of the document I read.  But it seems likely that there might be need
for other charging models.  It is also unclear that they are technically
sufficient.  For economic purposes, you would want the message to be sent
by the server, not the client.  But this would cease working if the
document were copied.  (But maybe this is not a fair objection, since
I know of no scheme that can preserve property rights given the
possibility of perfect digital  copying.)

<nl><paragraph>
Continuing on the more general question of read notification,
regardless of purpose, it is possible that one might desire
notification on a finer grain that the entire document.  But this, I
think, requires the cooperation of the client.  Indeed, the client
can tell the server that a given piece of text has been displayed,
but not whether the user actually read it (unless we go further, and
implement it with an executable function which requires the user to
click on a button)

<nl><paragraph>
As for the second form (modification notification), it seems to me
that there is a need to inform not just the owner, but also other
people.  There are two reasons for this:  

<nl><paragraph>
First, as owner of a document, I am not likely to allow other people
to modify my document at all.  On the other hand, I might be
interested in notifications when someone adds or deletes a link <bold>to</bold>
my document.  But attention links don't address this problem.

<nl><paragraph>
Second, as a reader of a document I don't own, I might want to be
notified when the owner modifies it, since I might wish to re-read it
(or at least the changed sections.)  Let's call these "monitor"
links.  Monitor links might be a useful means of reducing effort
required for some kinds of network retrievals - those where I am
interested in new developments in certain areas.  Now, instead of
polling documents to see whether they've changed, I can just leave an
"attention link" and get a notification.

<nl><paragraph>
On the other hand, this has some problems.  One of them is the
question of who pays the cost of sending all these notifications.
Can you imagine the load on your workstation as it sends out 10,000
monitor notifications?  Perhaps this can be answered by bringing in
more economics - that is, to attach a monitor link I need to set up
an account such that I can be charged for the delivery.  Or maybe the
notifications are sent by the document server, so as an author I am
not affected.

<nl><paragraph>
A second problem (or at least issue) is that monitor links require
finer grain of size and time.  Some users will want to monitor only
select portions of a document.  Likewise, we may not want
notifications sent when <italic>any</italic> editing is made, but
rather only when the author completes a session.  That is, if I edit
the document for a day, saving changes six times, you don't want six
notifications.  This might require some notion of "transactions" such
as used in data bases.  

<nl><paragraph>
Finally though, I don't think it is correct to call these things
links.  They are not related to logical structure, nor are they
explicitly activated by the reader (or writer), indeed that person
not even be aware that it was activated.  Consider the more general
question - if attention links are a subcase of execution links, and
attention links can be activated without knowledge of the user,
should all  execution links be capable of such activation?  Do you
want to read documents which can cause arbitrary computations to
occur without your choice, or even knowledge?


From connolly@pixel.convex.com  Wed Jun 24 19:16:14 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28939; Wed, 24 Jun 92 19:16:14 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09163; Wed, 24 Jun 92 19:16:36 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA29352; Wed, 24 Jun 92 12:15:55 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA10088; Wed, 24 Jun 92 12:15:53 -0500
Message-Id: <9206241715.AA10088@pixel.convex.com>
To: davis@willow.tc.cornell.edu (Jim Davis)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Links that refer to a range of text, not just a point. 
In-Reply-To: Your message of "Wed, 24 Jun 92 12:00:50 EDT."
             <9206241600.AA13167@willow.tc.cornell.edu> 
Content-Type: multipart/mixed; boundary="8<--"
Mime-Version: 1.0
Date: Wed, 24 Jun 92 12:15:52 CDT
From: Dan Connolly <connolly@pixel.convex.com>

--8<--

>But then this raises another issue: does WWW allow anchors within
>anchors?  I think not - in which case I could not use WWW anchors to
>both label a paragraph (e.g. for attaching an annotation) and a word
>within it (e.g. for definition).  This worries me quite a bit.  Nor
>can I attach multiple links to the same point (e.g. definitions of a
>word in multiple languages).
>
This and other related questions (can I have lists within lists?)
are precisely the reason for using a well-defined structural markup
language governed by SGML processing rules.

Right now we have no DTD for HTML, and the only answers lie in
the browser source code. The documentation "in the web" is too
vague. But I hardly think we want the browser source code to
be the definition of HTML.

On the other hand, I tried and failed to come up with a DTD which
described HTML in such a way that the existing documents are legal.

Before this situation gets out of hand, we need to establish a
(possibly evolving, but at least exsting) SGML DTD for HTML.
This will require incompatible changes to the definiton of HTML
(for instance, the PLAINTEXT, XMP, and LISTING features of HTML
don't quite fit into SGML).

Enclosed* is a proposed DTD, a perl hack to patch existing files,
and a sample patched file. I invite:

= SGML experts to round out the DTD (should we include
  stuff from the ISO General DTD? the AAP article DTD?
  ISOnum, ISOpub etc. standard entities? How about
  using the QWERTZ LaTeX-like DTD?)

= SGML non-experts to become conversant in SGML (it's
  coming whether you like it or not)

= HyTime experts to add to the confusion. Seriously, I'd
  like to know what HyTime has to offer.

= DSSSSSSSSSSL experts to do the same

= the WWW team to adapt existing code to match this DTD
  (or some real DTD)

= HTTP server sites to then update their HTML files


	*encosed in the MIME multipart/mixed enclosure sense

--8<--

<!-- This DTD was produced by DeveGram on Tue Jun  2 18:58:16 1992 -->
<!-- and hand-edited by connolly@convex.com -->

<!-- typical usage:

  <!DOCTYPE web-node SYSTEM 
    [
    <!ENTITY UDI011 SDATA
      "http://info.cern.ch/hypertext/DataSources/NewsFromVM/Overview.html">
    ]>
 -->

<!--     Parameter Entities       -->

<!--      Terminal symbols        -->

<!ENTITY % words "#PCDATA" >

<!--    Non-ELEMENT symbols       -->

<!ENTITY % inline       "%words | A" >
<!ENTITY % text         "%inline | P | IMAGE" >
<!ENTITY % heading "H1|H2|H3|H4|H5|H6" >

<!ENTITY lt "<">
<!ENTITY gt ">">
<!ENTITY amp "&">

<!ENTITY lt. "<">
<!ENTITY gt. ">">
<!ENTITY amp. "&">

<!--     Document structure       -->

<!ELEMENT WEB-NODE      O O  (TITLE, NEXTID?, ISINDEX?, section+, ADDRESS?)>

<!ELEMENT TITLE - -  (%inline)+>
<!ELEMENT ADDRESS - - (%text)+>

<!ELEMENT NEXTID - O EMPTY >
<!ATTLIST NEXTID N NUMBER #IMPLIED>

<!ELEMENT ISINDEX - O EMPTY >


<!ELEMENT section O O ((%heading)?,
                        (
                        %text |
                        section |
                        MENU |
                        UL |
                        OL |
                        DIR |
                        DL)+)>

<!ELEMENT (H1|H2|H3|H4|H5|H6)   - -  (%inline) >

<!ELEMENT P     - O  EMPTY -- paragraph SEPARATOR -->

<!ELEMENT IMAGE - O EMPTY>
<!ATTLIST IMAGE DATA ENTITY #REQUIRED>

<!ELEMENT A     - -  (%inline)+>
<!ATTLIST A
        NAME CDATA #IMPLIED
        HREF ENTITY #IMPLIED
        TYPE CDATA #IMPLIED --@@-- >

<!ELEMENT MENU  - -  (LI+)>

<!ELEMENT UL    - -  (LI+)>

<!ELEMENT OL    - -  (LI+)>

<!ELEMENT DIR   - -  (LI+)>

<!ELEMENT LI    - O  (%text)+>

<!ELEMENT DL    - -  ((DT, DD)+)>

<!ELEMENT DT    - O  (%inline)+>

<!ELEMENT DD    - O  (%text)+>

--8<--

And here's a perl script that attempts to patch up existing
HTML files:

--8<--

#!/usr/local/bin/perl
#
# USE
#   fix-html.pl <W3-file.html >W3-file.sgml
#
# SEE ALSO
#   the web-node.dtd.
#

print "<!DOCTYPE WEB-NODE SYSTEM \n[\n";

@html = <>;                     # read whole file
$_ = join('', @html);
$out = '';

$header = 0;
$anchor = "UDI000";
while(/</){
    $out .= $`;
    $_ = $';
    if(s/^A\s+//i){
        &fix_anchor;
    }elsif(s/^NEXTID\s+(\d+)\s*>//){
        $out .= "<NEXTID N=$1>";
    }elsif(s/^H(\d)>//){
        local($n) = $1;
        while($n<=$header){ $out .= "</SECTION>"; $header--; }
        while($n>$header){ $out .= "<SECTION>"; $header++; }
        $out .= "<H$n>";
    }else{
        $out .= '<';
    }
}

$out .= $_;

foreach(keys %anchor){
    local($ent) = $anchor{$_};

    print "<!ENTITY $ent SDATA \"$_\">\n";
}

print "]>\n", $out;

sub fix_anchor{
    local($name, $href, $type);

    # What exactly is the syntax of an SGML attribute value?
    while(s/^(\w+)\s*=\s*((\"[^\"]*\")|([^\s>]+))\s*//){
        local($v) = ($3 || $4);
        local($a) = $1;
        $href = $v if $a =~ /^href$/i;
        $name = $v if $a =~ /^name$/i;
        $type = $v if $a =~ /^type$/i;
    }
    s/[^>]*>//;

    $out .= "<A";
    $out .= " NAME=\"$name\"" if $name ne '';
    $out .= " TYPE=\"$type\"" if $type ne '';
    if($href ne ''){
        if(!defined($anchor{$href})){
            $anchor{$href} = ++$anchor;
        }
        $out .= " HREF=" . $anchor{$href};
    }
    $out .= ">";
}

--8<--

Here's my default.html run through the above script:

--8<--

<!DOCTYPE WEB-NODE SYSTEM 
[
<!ENTITY UDI011 SDATA
"http://info.cern.ch/hypertext/DataSources/NewsFromVM/Overview.html">
<!ENTITY UDI006 SDATA "http://crnvmc.cern.ch./FIND">
<!ENTITY UDI020 SDATA "http://info.cern.ch/rpc/doc/User/UserGuide.html">
<!ENTITY UDI013 SDATA
"http://info.cern.ch/hypertext/DataSources/bySubject/Overview.html">
<!ENTITY UDI021 SDATA "http://otax.tky.hut.fi/tky/default.html">
<!ENTITY UDI017 SDATA
"http://info.cern.ch:8001/archive.orst.edu:9000/archie-orst.edu">
<!ENTITY UDI010 SDATA "http://crnvmc.cern.ch/NEWS/student">
<!ENTITY UDI019 SDATA
"http://info.cern.ch./hypertext/Products/WAIS/Sources/Overview.html">
<!ENTITY UDI002 SDATA "http://info.cern.ch/hypertext/WWW/TheProject.html">
<!ENTITY UDI007 SDATA "http://crnvmc.cern.ch/NEWS/?">
<!ENTITY UDI001 SDATA "QuickGuide.html">
<!ENTITY UDI012 SDATA
"http://info.cern.ch/hypertext/DataSources/News/Overview.html">
<!ENTITY UDI003 SDATA "http://crnvmc.cern.ch./WHO">
<!ENTITY UDI022 SDATA
"gopher://gopher.micro.umn.edu:70/11/Other%20Gopher%20and%20Information%20Servers">
<!ENTITY UDI005 SDATA "http://crnvmc.cern.ch./FIND/jaune?">
<!ENTITY UDI004 SDATA "http://crnvmc.cern.ch./FIND/yellow?">
<!ENTITY UDI016 SDATA "http://crnvmc.cern.ch/FIND/DESY?">
<!ENTITY UDI009 SDATA "http://crnvmc.cern.ch./NEWS/vmnews">
<!ENTITY UDI008 SDATA "http://crnvmc.cern.ch./NEWS/cern">
<!ENTITY UDI023 SDATA
"http://info.cern.ch./hypertext/WWW/LineMode/Defaults/default.html">
<!ENTITY UDI015 SDATA "http://slacvm.slac.stanford.edu./FIND/spires">
<!ENTITY UDI018 SDATA "http://iicm.tu-graz.ac.at./jargon">
<!ENTITY UDI014 SDATA "http://info.cern.ch./hypertext/DataSources/Overview.html">
]>
<TITLE>CERN Information</TITLE>
<NEXTID N=10>
<SECTION><H1>CERN Information - Select by number</H1>
<DL>
<DT><A NAME="0" HREF=UDI001>Help</A>
<DD>On this program, or the
<A HREF=UDI002>World-Wide Web project</A>.
<DT><A NAME="2" HREF=UDI003>Phone book</A>
<DD>People, phone numbers, accounts and email addresses.
See also the analytical
<A NAME="yellow" HREF=UDI004>Yellow Pages</A>, or
the same index in French :
<A NAME="jaune" HREF=UDI005>Pages Jaunes</A>.
<DT><A NAME="1" HREF=UDI006>"XFIND" index</A>
<DD>Index of computer centre documentation, newsletters, news,
help files, etc...
<DT><A NAME="groups" HREF=UDI007>News</A>
<DD>A complete list of all public CERN news groups, such as
<A NAME="3" HREF=UDI008>news from the CERN User's
Office</A>,<A NAME="4" HREF=UDI009>
CERN computer center news</A>,<A HREF=UDI010>
student news</A>. See also <A NAME="5" HREF=UDI011>private
groups</A> and <A NAME="inews" HREF=UDI012>Internet
news</A>.
</dl>
<SECTION><H2>From other sites</h2>
See online data by
<A NAME="subject" HREF=UDI013>subject</A>,
pointers to
<A HREF=UDI014>other forms of online data</a>, and the following specific databases:
<DL>
<DT><A NAME="spires" HREF=UDI015>SLAC SPIRES</A>
<DD>The High Energy Physics preprint index at Stanford Linear
Accelerator, California.
(This is the same information avialable via the QSPIRES facility on BITNET.
Include the word "FIND" as the first keyword, eg: K FIND AUTHOR FRED.).
<DT><A NAME="desy" HREF=UDI016>DESY documents</a>
<DD>Documents and help files from the DESY lab in Hamburg.
<DT><A NAME="archie" HREF=UDI017>
Archie</a>
<DD>An index of almost everything available by "anonymous FTP".
<DT><A NAME="7" HREF=UDI018>Hacker Jargon</a>
<DD>An index to a cross-referenced set of hacker terms. A demonstration
of the WWW gateway to the Graz Technical University Hyper-G database.
<DT><A NAME="9" HREF=UDI019>W.A.I.S.</a>
<DD>All kinds of information available from "Wide Area Information Servers".
<DT><A NAME="6" HREF=UDI020>CERN RPC</A>
<DD>The user guide for the RPC system developed in CERN CN division
(not Sun/RPC). This is an example of documentation (partially) converted
into hypertext.
<DT><A NAME="hut" HREF=UDI021>Helsinki</a>
<DD>Helsinki Technical University information service (Mostly Finnish).
<DT><A NAME="gopher" HREF=UDI022>Gophers</a>
<DD>Campus-wide information systems using "Gopher" software. (Requires
www version 1.1 or higher)
</DL>
(This page may be an out of date copy. See the
<A NAME="latest" HREF=UDI023>latest version</a>.)

--8<----



From connolly@pixel.convex.com  Thu Jun 25 01:04:53 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29544; Thu, 25 Jun 92 01:04:53 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28907; Thu, 25 Jun 92 01:05:12 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA15721; Wed, 24 Jun 92 18:04:30 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA04497; Wed, 24 Jun 92 18:04:27 -0500
Message-Id: <9206242304.AA04497@pixel.convex.com>
To: davis@willow.tc.cornell.edu (Jim Davis)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Raisch's Attention link 
In-Reply-To: Your message of "Wed, 24 Jun 92 12:02:25 EDT."
             <9206241602.AA13181@willow.tc.cornell.edu> 
Date: Wed, 24 Jun 92 18:04:27 CDT
From: Dan Connolly <connolly@pixel.convex.com>


><paragraph>
>In a previous message, R. Raisch proposed a number of interesting
>link types.  One of them was the attention link, which I want to
>discuss here.  I am uncertain about the need for this link, the
>technical ability to provide it, and the definition.
>
[side note: Jim: what did you use to compose richtext? Ez?]

While all these ideas are very interesting, I sometimes get
lost in a haze of ideas and scenarios. I'd like to get a handle
on just what application we're developing here.

The pie-in-the-sky seems to be a distributed, hypermedia CSCW
(computer supported collaborative work) platform, where multiple authors
discover, research, read, reply, refute, annotate, author, and otherwise
exchange information.

Features of such a system might include:
- distributed access to documents, i.e. a document can be processed
	by a client on another host
- fulltext searching of large bodies of information
- direct manipulation query, i.e. point-and-click at the information
	that you're interested in
- hypertext, i.e. random-access both within documents
	and between documents
- direct manipulation editing, i.e. editing a representation of
	the end product rather than the source format (WYSIWYG)
- multimedia documents (formatted text, raster images, line drawings,
	audio, video, structured enclosures)
- hypermedia (just a term for multimedia hypertext)

In order to refine the model behind such an application and explore
the functionality different models support, let's have a look at some
existing applications and an abstract of the model they present.

(terms introduced by _underscores_ are objects defined by the model.)


Internet mail: distributed text message interchange

With _user agent_, a user composes a _message_, which
is delivered by a _transfer agent_ to a _mailbox_, possibly in
another _domain_, where another user can read the message.
	MIME defines various _types_ of messages, including
	text, images, audio, video, included messages, and
	multipart (complex) types.
The recieving user may forward the message or reply to the message
by composing a new message including part or all of the original.


USENET news: distributed bulletin board

An _article_ is a special kind of message, addressed to
a _newsgroup_ rather than a _mailbox_. _Posting software_ enters the
article into a _repository_. A _news reader_ is a variant of a
mail user agent that helps a user navigate the articles in the
repository. It maintains a record of which articles the user
has read. (Transfer agents fit in somehow, and NNTP adds a client/server
separation between the news reader/poster and the repository).


WAIS: distributed fulltext search and multimedia retrieval

With a _wais client_, a user composes a _question_ consiting of
some relavent text and some _sources_ to consult. The wais client
contacts the _server_ for each source and makes a _query_ using the
relavent text. The servers respond with a scored list of _document
identifiers_. The user can select a document identifier and instruct
the client to _retrieve_ the corresponding _document_. The user
can then refine the question by adding relavent documents or _chunks_
of relavent documents.


FTP: distributed file exchange

A user invokes a _client_ on one _host filesystem_. The client
logs into a _server_ on another _host filesystem_ using a _username_
and a _password_. The user indicates a _mode_ and a _directory_
to the server through the client. The user can request that the
client display a _directory listing_ from the server, or transfer
a _named_ _file_ from the server's filesystem to the client's.


archie (prospero, really): a distributed file system

A user indicates a _host_, _search term_,
and _search mode_ to a _client_. The client contacts the _server_
on that host, issues a query, and displays the resulting list
of (host|dir|mode|date|seq|size|name|type) _items_.


Gopher: distributed hierarchical information browser

The _client_ connects to a _server_ (a _port_ on a _host_)
and sends it a _selector_. The server either sends back a _document_
or a _directory_, depending on the _type code_ corresponding to
the selector (the null selector is defined to be the root directory
of the server). A directory is a list of _items_. Each item consists
of a type code, a _name_, a selector, a host, and a port.

The client displays the names for the user, and the user chooses one.
The client sends the selector to the server indicated by the corresponding
host and port, and depending on the type code, 0) display the resulting
document, 1) display the resulting directory, 4-6) decode the resulting
archive  9) save the resulting document to a file. Codes 2, 7, and
8 request services from CSO phone book servers, fulltext gopher servers,
and telnet hosts respectively.

The client maintains a _stack_ of the directories the user has visited,
and the user can choose to "go back" in addition to choosing a
directory item.


WWW: a distributed hypertext browser

a WWW _client_ parses an _address_ into a _scheme_, a _server_,
a _path_, an _anchor id_, and some _search terms_. The client retrieves
a _document_ from the server using the path and search terms (using
one of several protocols), and displays the document, indicating
the _anchor element_ indicated by the anchor id. Documents contain
_structural elements_ such as headings, lists, etc.

The user requests the next document by either a) choosing one of the
anchor elements of the document (which specifies an address), or b)
if the document is an _index_, the user can request a search by supplying
search terms. The client combines the address of the document with the
search terms and begins again. Otherwise, the user can choose one of the
anchor elements and instruct the client to use the corresponding
address for the next document.


GNU Info: online hypertext documentation for applications and products

An info _browser_ displays the root _node_. A user indicates another node
to display by choosing _up_, _next_, _previous_, choosing a
_menu item_, or indicating a _note_ to follow.


Unix manual: structured text documentation for unix commands and fuctions

A user may request _formatted text display_ of a _page_ by its _name_,
and _section_, or they may request display of all _permuted index entries_
(containing names of pages) that match a _string_. The database is defined
on a per-user basis as a list of _trees_, each contatining a permuted
index and one or more sections containing one or more pages.


Frame: direct manipulation hypermedia editor, hypermedia browser

FrameMaker supports point-and-click editing of _documents_ composed
of _frames_ containing _objects_ (geometrics graphics and raster images)
and _textflows_ of _paragraphs_ of formatted text and _markers_, including
_link sources_ and _link destinations_.

FrameViewer displays a _page_ frame of a document, and allows point-and-click
access to the link sources. Every document has an implicit firstpage and
lastpage link destination. Every page has an implicit link to the next
and previous page.


Compare and contrast objects:

Mail messages vs. WAIS documents vs WWW documents vs FTP files
	(unique id's? writable?)
WAIS source vs. news group
WAIS server vs. NNTP server vs. gopher server vs HTTP server
Message-ID vs WAIS docid vs WWW UDI
WAIS chunk vs. WWW anchor vs. FrameMaker marker
Info node vs. FrameMaker page vs. WWW document

Compare and contrast features

- distributed access to documents
	mail: no
	news: NNTP allows retrieval of headers by newsgroup or date
	wais: 
- fulltext searching: WAIS vs. WWW vs. gopher
- direct manipulation query: xwais vs. xgopher vs. NeXT WWW
- hypertext: WWW vs. GNU Info vs. FrameMaker
- direct manipulation editing: FrameMaker vs. Andrew vs. Interviews
- multimedia documents: FrameMaker vs. Gopher vs. MIME vs. WAIS vs. WWW

I'm formulating a model that will hopefully put all these features
and objects into one framework for discussion, at least.

Dan

From fkappe@fiicmds04.tu-graz.ac.at  Thu Jun 25 14:26:08 1992
Return-Path: <fkappe@fiicmds04.tu-graz.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00925; Thu, 25 Jun 92 14:26:08 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25968; Thu, 25 Jun 92 14:25:47 +0200
Received: by iicm.tu-graz.ac.at (5.57/Ultrix3.0-C)
	id AA25321; Thu, 25 Jun 92 14:25:18 +0200
Date: Thu, 25 Jun 92 14:25:18 +0200
From: fkappe@fiicmds04.tu-graz.ac.at (Frank Kappe)
Message-Id: <9206251225.AA25321@iicm.tu-graz.ac.at>
To: www-talk@nxoc01.cern.ch
Subject: HTML DTD and related problems (rather long)

>>>>> On Wed, 24 Jun 92 12:15:52 CDT, Dan Connolly <connolly@pixel.convex.com> said:

>>But then this raises another issue: does WWW allow anchors within
>>anchors?  I think not - in which case I could not use WWW anchors to
>>both label a paragraph (e.g. for attaching an annotation) and a word
>>within it (e.g. for definition).  This worries me quite a bit.  Nor
>>can I attach multiple links to the same point (e.g. definitions of a
>>word in multiple languages).
>
> This and other related questions (can I have lists within lists?)
> are precisely the reason for using a well-defined structural markup
> language governed by SGML processing rules.

> Right now we have no DTD for HTML, and the only answers lie in
> the browser source code. The documentation "in the web" is too
> vague. But I hardly think we want the browser source code to
> be the definition of HTML.

The situation with anchors in SGML is even worse. In addition to the cases where
you want to have anchors within lists, list items, headlines etc. and lists,
list items, headlines etc. within anchors, you also have anchors within anchors.
Actually, anchors within anchors look like this:

<BEGIN ANCHOR A>
!
!
!   <BEGIN ANCHOR B>
!   !
!   !
!   !
!   <END ANCHOR B>
!
!
<END ANCHOR A>

This case is trivial (you just allow anchors within anchors in the DTD).
However, consider the case where you want to have a destination anchor marking,
say, paragraphs 1 and 2, and another one marking 2 and 3:

<BEGIN ANCHOR A>
!
! para 1
!
!   <BEGIN ANCHOR B>
!                  !
! para 2           !
!                  !
<END ANCHOR A>     !
                   !
  para 3           !
                   !
    <END ANCHOR B>-+

This situation cannot be implemented with SGML Tags like <A ....>text</A>, as
it is proposed in HTML. Also, I doubt that it is possible to construct an anchor
spanning, e.g., a few items of list A and a few items of list B, because the
SGML parser would implicitly close openened anchor tags when reaching </list>:

<list A>
  <item>...
<A .....>
  <item>...
  <item>...
</list>

<list B>
  <item>...
</A>
  <item>...
  <item>...
</list>

The reason why it is possible to construct such things using the NeXT-based WWW
viewer/editor is simply that HTML is not SGML. Therefore it is impossible to
specify a DTD for HTML (as Dan has already pointed out).

In our Hyper-G system that uses HTF, a SGML-based format similar to HTML, we
overcome the anchor-nesting problem by specifying TWO tags for anchors: an
anchor-start (<AS>) tag and an anchor-end (<AE>) tag with an additional ID
attribute. So, the examples are coded like this:

<AS ID="A">
para 1
<AS ID="B">
para 2
<AE ID="A">
para 3
<AE ID="B">

and

<list A>
  <item>...
<AS ID="C">
  <item>...
  <item>...
</list>

<list B>
  <item>...
<AE ID="C">
  <item>...
  <item>...
</list>

which is perfectly legal in our DTD. I don't want to waste more internet
bandwidth sending the DTD, but you may get it by anonymous ftp from
iicm.tu-graz.ac.at in file pub/Hyper-G/sgml/hyper-g.dtd. There is also a
corresponding style sheet as well as styles used to convert HTF to HTML and
LateX with a stand-alone SGML parser. 

Let me say one final word about anchors: In my (and others) opinion, it is
generally not a good idea to store anchors (or even links) in documents. This
requires a modification of the document whenever an anchor is
inserted/modified/deleted and is problematic in multi-user environments with
private links, etc. Rather, the links should be stored and manipulated in a
seperate link database (like in Intermedia and also in Hyper-G). This also
allows for backwards-tracing of links, which is essential for maintaining the
integrity of the hypertext and providing a graphical overview of the hypertext
to the users.

However, in certain circumstances (like document modification) it is convenient
to supply the anchor information with the document. That is the reason why it's
in the DTD.

-----------------------------------------------------------------------------
Frank M. Kappe                                      fkappe@iicm.tu-graz.ac.at
Institute for Information Processing                     Fax: ++43 316 824394
Technical University Graz, Austria           "Sorry, no kangaroos in Austria"
-----------------------------------------------------------------------------

From sean@coombs.anu.edu.au  Thu Jun 25 17:27:39 1992
Return-Path: <sean@coombs.anu.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01526; Thu, 25 Jun 92 17:27:39 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10252; Thu, 25 Jun 92 17:27:22 +0200
Received: by coombs.anu.edu.au (5.61/1.0)
	id AA13539; Fri, 26 Jun 92 01:27:14 +1000
Date: Fri, 26 Jun 92 01:27:14 +1000
From: sean@coombs.anu.edu.au (Sean Sebastian Batt)
Message-Id: <9206251527.AA13539@coombs.anu.edu.au>
To: www-talk@nxoc01.cern.ch
Subject: HTML -> Postscript? Text?

G'Day,

its late at night and my eyesight is fading so I'm simply not up to
parsing the installation instructions for variuos parts of WWW written
as they are in HTML.

Is there an HTML -> Postscript processor anywhere? HTML -> troff? Text
even?

Thanks in advance...

Sean
--
------------- Sean Sebastian Batt - sean@coombs.anu.edu.au --------
-------- Coombs Computing Section - Telephone: +61 6 249 3296 -----
-- Australian National University - GPO Box 4 Canberra City 2601 --
-------------------------------------------------------------------

From timbl  Thu Jun 25 22:50:05 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02447; Thu, 25 Jun 92 22:50:05 MET DST
Date: Thu, 25 Jun 92 22:50:05 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206252050.AA02447@ nxoc01.cern.ch >
To: davis@willow.tc.cornell.edu
Subject: Re: Links that refer to a range of text, not just a point.
Cc: www-talk@nxoc01.cern.ch


On types of links: Link types can descibe

-- hints at presentation (Footnote, in-line, embed, automatic or
   on demand, print this if you print me, don't search this if
   you search me, etc etc)

-- semantics of the documents (a is a previous version of b, etc)

-- semantics of THAT DESCIBED by the document, eg
   "The W3 software" is a part of "the W3 project" where the
   'is part of' in fact applies to the unquoted things, not the
   documents. There is something on link types on the web in

   http://info.cern.ch/hypertext/WWW/DesignIssues/LinkTypes.html


On areas and points:  No, the WWW links are not (in general) points
they are areas. In the broad sense they can be any object within
the document, as identified by the anchor ID. In the specific
case of HTML, they are areas which have a beginning and an end.
In the case of the actual W3 software, noone can handle
overlapping anchors because the text object underneath isn't powerful
enough.  There is also a problem showing overlapping source anchors
(buttons) to the user. But in principle, there is no reason'
why one shouldn't have overlapping anchors, or at least
nested ones.

But not now.

Tim

From timbl  Fri Jun 26 15:35:05 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04694; Fri, 26 Jun 92 15:35:05 MET DST
Date: Fri, 26 Jun 92 15:35:05 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206261335.AA04694@ nxoc01.cern.ch >
To: connolly@pixel.convex.com, timbl@nxoc01.cern.ch
Subject: Re: HTML DTD
Cc: www-talk@nxoc01.cern.ch

Dan, you say

<<
I suppose you could come up with a DTD that describes something
close to the current HTML, but I'm not sure of the value of it.
HTML allows tags to be pretty much sprinkled wherever you feel
like putting them. Any DTD that allows that much leeway just
looks like this:

        <!ENTITY % alltags "TITLE|H1|H2|H3|MENU|OL|UL">
        <!ELEMENT %alltags (%alltags)*>

i.e. every element is just a repeatable or-group of all the elements.
Then the SGML parser can't do any minimization cuz nothing's required. >>

Yes, current SGML currently is just a linear sequence of
elements. (Sorry, current HTML -- I'm typing this in serially
and can't edit!).  There is a reason for this:  it is very
convenient for HTML to map onto a series of styles -- for two
reasons.

Firstly, a lot of rich text objects can hold styles but can't hold
structure.  You can deduce structure from the styles -- like
Word deucing outlining from Heading styles, and WWW deducing
a list <UL> from a lot of <LI> paragraphs. But you can't go
very far.  If you want to make a HT editor out of such a
text object, you ahve to regenerate the elements from the
styles.

Secondly, it may be that the wysiwyg editors have a linear style
structure because that is intuitive to people. I don't know
a lot of people who use author/editor (which maintains
structure). Maybe real people actually think in terms of styles
and fix the document to look right, then they are happy to have the
structure deduced.

So if we went for a nestable HTML which would be cleaner for
those who apreciate recursion, we would have to have a hypertext
editor which made the structure visible.  I don't have experience
enough to know whether real information providers (group secretaries,
for example) would be into generating nested elements -- maybe
the styles are useful to keep as the current `user interface metaphor'
of word processors.

(It also makes making the editor easier!)

Or maybe we should have two levels of DTD -- one basically linear
and mandatory (and precompiled for fast access) and one more
sophisticated for larger documents.

Of course, when you are writing hypertext the large documents are
normally broken down into small bits to make traveing them quick.
So whereas each hypertext node may contain only H1 and H2 headings,
when a book is generated a la the_www_book.ps you get 5 levels
of heading from the whole tree.

So that is why the HTML strcuture is so simple. I am open to
a more sophisticated alternative.

Tim
____________________________
From connolly@pixel.convex.com Fri Jun 26 00:00:33 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02722; Fri, 26 Jun 92 00:00:27 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25540; Fri, 26 Jun 92 00:00:11 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA10700; Thu, 25 Jun 92 17:00:01 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA05209; Thu, 25 Jun 92 17:00:00 -0500
Message-Id: <9206252200.AA05209@pixel.convex.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Subject: Re: HTML DTD 
In-Reply-To: Your message of "Thu, 25 Jun 92 23:07:25 +0700."
             <9206252107.AA02534@ nxoc01.cern.ch > 
Date: Thu, 25 Jun 92 16:59:59 CDT
From: Dan Connolly <connolly@pixel.convex.com>
Status: R


>thanks for that contribution.   Not being as hot on SGML
>as I ought to be, I don't see why the HREF has to refer to
>and entity declared separately rather than directly having
>a string argument.
>
That's actually left over from when I was trying to point
HREF attributes to MIME attachments. It's not really
necessary to move the UDIs into entities as long as you're
careful that the UDI syntax is a subset of the SGML
attribute literal syntax.

Beware, for example, that an
SGML parser will expand entity references in an attribute literal
to produce the CDATA for the attribute value. So that
<A HREF="A&P"> might be OK for the linemode browser,
but an SGML parser will try to resolve &P.

Also, SGML attribute values have a maximum length specified
in the SGML declaration. The default value is 960 or something
around there.

>The title is in fact optional currently, by the way ...
>we could keep it so though it "ought" always to have one.
>
>I'd like a DTD which as closely reflects the current HTML as
>possible.

I suppose you could come up with a DTD that describes something
close to the current HTML, but I'm not sure of the value of it.
HTML allows tags to be pretty much sprinkled wherever you feel
like putting them. Any DTD that allows that much leeway just
looks like this:

	<!ENTITY % alltags "TITLE|H1|H2|H3|MENU|OL|UL">
	<!ELEMENT %alltags (%alltags)*>

i.e. every element is just a repeatable or-group of all the elements.
Then the SGML parser can't do any minimization cuz nothing's required.

> Then, if we change HTML to HTML2, I would
>change it in a number of ways, in particular to include
>separate header and body parts.  I have come across the
>"Davenport" group of publishers who are defineing DTDs for
>technical documentation.  They include Steve Newcombe who
>is the HyTime guy (or one of the two I should say).
>I would like to get some input from them.
>

Certainly we should keep tabs on things like the Davenport
group and HyTime.

But my immediate concern is these little sytactic differences
that render HTML documents worthless to an SGML parser. The
current HTML and UDI syntax make a good proof of concept, but
we need to move toward formal definitions so that we can
have confidence that correct implementations will interoperate.

More later...

Dan


From timbl  Fri Jun 26 20:35:20 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00771; Fri, 26 Jun 92 20:35:20 MET DST
Date: Fri, 26 Jun 92 20:35:20 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206261835.AA00771@ nxoc01.cern.ch >
To: sean@coombs.anu.edu.au, www-talk@nxoc01.cern.ch
Subject: Re: HTML -> Postscript? Text?

Sean,

You say, "its late at night and my eyesight is fading so I'm simply not up to
parsing the installation instructions for variuos parts of WWW written
as they are in HTML".

The basic installation instructions are also in the line mode
browser tar file in plain text.  That will allow you to get the
line mode browser (www) up.  9You can probably get a binary anyway).
Then you can use that to change HTML into text 

	www -n -p -na xxxx.html

will give you a non-interactive unpaged link-free formatted
text output. What more can you want? 

If there is something crucial missing from the .txtx files
shipped, then tell www-bug@info.cern.ch.  If you want more
information about other bits without getting www up, then
just telnet to info.cern.ch and read it on line.


Actually, we plan to make a combined user manual availabl
in postscript and TeX in the same way as the_www_book.ps.Z
dumped from the hypertext.  Later.


Tim

From timbl@zippy.lcs.mit.edu  Fri Jun 26 22:03:28 1992
Return-Path: <timbl@zippy.lcs.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01144; Fri, 26 Jun 92 22:03:28 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AB01707; Fri, 26 Jun 92 22:02:46 +0200
Received: by zippy.lcs.mit.edu 
	id AA29919; Fri, 26 Jun 92 16:04:23 -0400
Date: Fri, 26 Jun 92 16:04:23 -0400
From: timbl@zippy.lcs.mit.edu (Tim Berners-Lee)
Message-Id: <9206262004.AA29919@zippy.lcs.mit.edu>
To: ietf-udi@merit.edu, ietf@isi.edu, nir@nxoc01.cern.ch,
        www-talk@nxoc01.cern.ch
Subject: IETF BOF on Universal Document Identifiers
Cc: erik.huizer@surfnet.nl, mdavies@nri.reston.va.us



		Universal Document Identifiers UDI BOF

        Time:                  Monday 13th July 1992 1:30 pm

	Chair:                 Tim Berners-Lee

	Background document:   file://info.cern.ch/pub/www/doc/udi2.ps

Aim:  To define some clear decisions to be made by a small WG to be
formed.    A skeleton charter for such a working group is appended,
and may be discussed at the BOF.  The overall aim is to standardize
on one unifying printable representation for names and addresses of
retrievable objects in existing and future name and address spaces.

Those who have not been following the discussion are asked to read the
background document first.  An archive of some of the discussion is
available as file://info.cern.ch/pub/www/doc/udi/discussion.mbox .
The BOF will avoid philosophy and a discussion of the differences
between names and addresses, or the relative merits of different naming
schemes, or the combination of names in different spaces recommended to
refer to an object.  If new schemes are required, a separate effort
may be forked off to create them.
_________________________________________________________________

Provisional Charter:

	To define a printable string syntax to the allow

1.	The expression of the address on the network of any
	accesable object using existing information retrieval protocols;

2.	The expression of the name of any object held in
	a directory system or unique naming space on the network;

3.	The distinction to be made easily in the syntax
	between such protocols and directories and name spaces;

4.	New protocols, directories and naming schemes to be included as
	and when they are developed.


The aim of the working group is to further the exchange of information
between people and applications using the network by allowing an
unambiguous reference to be cited to accessible units of information.

The working group will build on experience with existing information retrieval
protocols and will not invent new protocols or name spaces. The working
group will note the properties of established name and address spaces.

Deliverable:

A	Document describing:
		Overall syntax, character sets and limitations
		Formats for addresses of:-
		   FTP files and directories
		   WAIS documents and databases
		   HTTP objects
		   NNTP newsgroups and articles
		   Gopher items.

	Standards track.

B	Appendices to document A for x500 distinguished name spaces

C	Appendices to document A for selected established
	unique identifier name spaces. (possible separate parallel
	working group).


Milestones:

	Define at BOF.


From serrano@osage.csc.ti.com  Mon Jun 29 23:19:44 1992
Return-Path: <serrano@osage.csc.ti.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08231; Mon, 29 Jun 92 23:19:44 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09219; Mon, 29 Jun 92 23:19:09 +0200
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA16612; Mon, 29 Jun 92 16:09:38 CDT
Received: from osage.csc.ti.com (osage) by tilde.csc.ti.com id AA24636; Mon, 29 Jun 1992 16:07:53 -0500
Received: from localhost by osage.csc.ti.com (4.1/SMI-4.1)
	id AA28545; Mon, 29 Jun 92 16:07:51 CDT
Message-Id: <9206292107.AA28545@osage.csc.ti.com>
To: wei@xcf.berkeley.edu
Cc: www-talk@nxoc01.cern.ch
Date: Mon, 29 Jun 92 16:07:51 -0500
From: serrano@osage.csc.ti.com


Hi, 

1) I was wondering where I can get an editor to create hypertext
documents for the Viola WWW browser (html source editor)?

2) Where can I find "TheProject.html"? I checked under
/info.cern.ch/hypertext/WWW but there is no such path.

ANY HELP will be greatly appreciated.

Yonson
serrano@csc.ti.com
=====================================================

           ,_             ___@            __@
      ,______\@          _`__\-'         / /\__
  ^^^^,__'    \^^^      (')\/(`)       ___/\
              '                            /_
======================================================

From timbl  Tue Jun 30 00:08:31 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08352; Tue, 30 Jun 92 00:08:31 MET DST
Date: Tue, 30 Jun 92 00:08:31 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9206292208.AA08352@ nxoc01.cern.ch >
To: serrano@osage.csc.ti.com, wei@xcf.berkeley.edu
Subject: Hypertext editor
Cc: www-talk@nxoc01.cern.ch


Well, this is one of theings we're all hoping is high on Pei's
agenda -- to make Viola an editor too.

Right now, all there is is a NeXTStep editor which was frozen last
summer so is not all up-to-date and bug-free but exists and
we use it but you need a NeXT. Available by aftp from
info.cern.ch in /pub/www/src

You ask, "Where can I find "TheProject.html"? I checked under
/info.cern.ch/hypertext/WWW but there is no such path."

I guess you tried the FTP server. Bad news: the ftp server and the
http server serve different things on that machine.
If you want the source, assuming you have the www line mode
browser, just say

 www -source  http://info.cern.ch/hypertext/WWW/TheProject.html > junk.html

This will give you an idea of what HTML looks like. Read the document
about what the tags mean, and then edit it to make your own.
For a limited quantity, a text editor on hypertext isn't too bad.
I'm away from home and so using emacs to make a hypertext trip report.
I make it with emacs then check it with  viola. A temporary solution
I know, till we get editors available.

Tim

From wei@xcf.berkeley.edu  Tue Jun 30 11:25:23 1992
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09837; Tue, 30 Jun 92 11:25:23 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01341; Tue, 30 Jun 92 11:24:46 +0200
Received: by xcf.Berkeley.EDU (5.65/XCF-1.34)
	id AA25967; Tue, 30 Jun 92 02:20:10 -0700
Date: Tue, 30 Jun 92 02:20:10 -0700
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9206300920.AA25967@xcf.Berkeley.EDU>
To: serrano@osage.csc.ti.com
Subject: Re:  Hypertext editor
Cc: timbl@nxoc01.cern.ch, wei@xcf.berkeley.edu, www-talk@nxoc01.cern.ch

Yup... an editor is in the works. The very current state of the viola-based
browser uses output from a standard SGML parser (sgmls), and the displaying
page is composed of multiple structured textfield/bitmap/whatever objects,
instead of the unstructured single textfield as in the currently released 
version. 

Basically I'm taking a crack at a rough 1-1 mapping of SGML document 
structure to viola objects. Allow editing in the objects (ie textfield, 
bitmap), and convert back to SGML. It'll probably be highly structured 
s.t. some people might find needing some getting-used-to. But as the 
document source is SGML, there should eventually be many alternative 
editors. I can't say when this version will be releasable, as there are 
about a zillion of things to do to get there.

In the meanwhile, however, I could release a version (HTML based) that 
displays bitmaps (XBM and XPM). I hesitate releasing that version because
it has some fundamental limitations (hence the remodeling), b/c XBM and 
XPM are very X-ish, and, and b/c it kinda affects WWW's relatively uniformed
interoperability (linemode browser may then have to say "a picture is here,
but..."). I don't know. Maybe it's better to freeze HTML now?


-Pei
			"All I know-- we've got to change what's happening
			 Something good could happen"	The B-52's


From jfg@dxcern.cern.ch  Tue Jun 30 11:30:38 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09853; Tue, 30 Jun 92 11:30:38 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01640; Tue, 30 Jun 92 11:29:53 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA11026; Tue, 30 Jun 92 11:29:57 +0200
Date: Tue, 30 Jun 92 11:29:57 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206300929.AA11026@dxcern.cern.ch>
To: serrano@osage.csc.ti.com
Cc: www-talk@nxoc01.cern.ch
Subject: your WWW questions
References: <9206292107.AA28545@osage.csc.ti.com>

	Hello !

  Viola doesn't have an integrated editor yet. All you can do for now
is edit the html files separately and then display them with Viola.
Once you understand the few tags and the Doc IDs, it isn't hard to do.
Details are available in the hypertext documentation starting from the
"TheProject" page that you were looking for...

  ..."TheProject.html" is the hypertext page that you obtain when
clicking on the "?" icon in Viola, and then on the first link named
"World-Wide Web". If it doesn't work, it probably means that your
Internet connection has a problem, perhaps a bad configuration of the
name server. Try typing this in the "Doc ID" field at the bottom of Viola:

	http://128.141.201.74/hypertext/WWW/TheProject.html

and hit Return.

  Cheers !

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"Life may at times be boring, but is it more fun to be dead ?"
                                                  -- Alcor


From jfg@dxcern.cern.ch  Tue Jun 30 11:58:23 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09909; Tue, 30 Jun 92 11:58:23 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04144; Tue, 30 Jun 92 11:57:48 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA19493; Tue, 30 Jun 92 11:57:55 +0200
Date: Tue, 30 Jun 92 11:57:55 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9206300957.AA19493@dxcern.cern.ch>
To: davis@willow.tc.cornell.edu (Jim Davis)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Raisch's Attention link
References: <9206241602.AA13181@willow.tc.cornell.edu>

> As for charging, fairness requires that the link not be activated
> until I have seen a warning (otherwise I might get charged a zillion
> dollars to read the document - just like 900 phone numbers in the
> USA).  So this will add complexity to the client.

  This is of course very important! But just adding an alert in the
client before spending money is not a complex change. It might just be
annoying to the user (had you rather be annoyed or spend $$$ ?) The
user could also want to authorize access without warning to trusted
data sources, e.g. a pay-by-time database that he uses frequently
(with the stress of the ticking $ clock in the corner...)

> Also, attention links are not sufficient for a charging.  They
> support a model where I am charged once per read, no matter how much
> of the document I read.  But it seems likely that there might be need
> for other charging models.

  For a discussion of the many problems of a read-based charging scheme
(which was to be implemented in Xanadu as an answer to the Copyright
issues), you may want to read a paper presented at the Hypertext'91
conference in San Antonio, by Pamela Samuelson and Robert Glushko,
"Intellectual Property Rights for Digital Library and Hypertext
Publishing Systems: an Analysis of Xanadu" (unfortunately not
available online to my knowledge...)

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"Life may at times be boring, but is it more fun to be dead ?"
                                                  -- Alcor


From peterson@choctaw.csc.ti.com  Tue Jun 30 13:50:53 1992
Return-Path: <peterson@choctaw.csc.ti.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10109; Tue, 30 Jun 92 13:50:53 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11099; Tue, 30 Jun 92 13:50:01 +0200
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA25959; Tue, 30 Jun 92 06:50:33 CDT
Received: from choctaw.csc.ti.com (choctaw) by tilde.csc.ti.com id AA00135; Tue, 30 Jun 1992 06:48:47 -0500
Received: by choctaw.csc.ti.com (4.1/SMI-4.1)
	id AA10506; Tue, 30 Jun 92 06:48:46 CDT
From: peterson@choctaw.csc.ti.com (Bob Peterson)
Message-Id: <9206301148.AA10506@choctaw.csc.ti.com>
Subject: Re: your WWW questions
To: jfg@dxcern.cern.ch (Jean Francois Groff)
Date: Tue, 30 Jun 92 6:48:45 CDT
Cc: serrano@osage.csc.ti.com, www-talk@nxoc01.cern.ch
In-Reply-To: <9206300929.AA11026@dxcern.cern.ch>; from "Jean Francois Groff" at Jun 30, 92 11:29 am
Reply-To: peterson@csc.csc.ti.com
Mime-Version: 1.0
X-Mailer: ELM [version 2.3 PL11]

You said:
> 
> 	Hello !
> 	...
>   ..."TheProject.html" is the hypertext page that you obtain when
> clicking on the "?" icon in Viola, and then on the first link named
> "World-Wide Web". If it doesn't work, it probably means that your
> Internet connection has a problem, perhaps a bad configuration of the
> name server. Try typing this in the "Doc ID" field at the bottom of Viola:
> 
> 	http://128.141.201.74/hypertext/WWW/TheProject.html
> 
> and hit Return.

  The problem is caused, as I understand it, by the (single) gateway
between the company's internal networks and the Internet.  That gateway
allows _NO_ TCP/IP connections between an internal machine and an
external machine.  Also, the gateway machine offers no compiler and, in
general, refuses to allow ordinary users to install arbitrary code,
e.g., www.

>   Cheers !
> 
> --
>   Jean-Francois Groff (jfg@info.cern.ch)

    Bob

-- 
Bob Peterson             Work: peterson@csc.ti.com              Expressway Site
Texas Instruments        Home: peterson@zgnews.lonestar.org     North Building
P.O. Box 655474, MS238   TIMSG: RWP  Landline: +1 214 995 6080  Aisle A4
Dallas, Tx USA 75265                 FAX line: +1 214 995 0304  2-88V97

From jfg@dxcern.cern.ch  Wed Jul  1 20:12:54 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14289; Wed, 1 Jul 92 20:12:54 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00575; Wed, 1 Jul 92 20:12:07 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA10061; Wed, 1 Jul 92 20:12:16 +0200
Date: Wed, 1 Jul 92 20:12:16 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207011812.AA10061@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Testing. Please ignore.

This message boldly goes where no VM user never went...

From jfg@dxcern.cern.ch  Wed Jul  1 20:29:19 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14357; Wed, 1 Jul 92 20:29:19 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01127; Wed, 1 Jul 92 20:28:29 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA14104; Wed, 1 Jul 92 20:28:38 +0200
Date: Wed, 1 Jul 92 20:28:38 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207011828.AA14104@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Testing again (Sorry, this may not be the last one...)

This message boldly goes where no VM user EVER went...

From S.Kille@isode.com  Sat Jul  4 16:44:02 1992
Return-Path: <S.Kille@isode.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04041; Sat, 4 Jul 92 16:44:02 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA20899; Sat, 4 Jul 92 16:43:37 +0200
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP 
          id <g.02151-0@haig.cs.ucl.ac.uk>; Sat, 4 Jul 1992 15:43:01 +0100
Received: from localhost.cs.ucl.ac.uk by glengoyne.isode.com with SMTP (PP) 
          id <02364-0@glengoyne.isode.com>; Sat, 4 Jul 1992 15:42:41 +0100
To: timbl@zippy.lcs.mit.edu (Tim Berners-Lee)
Cc: ietf-udi@merit.edu, ietf@isi.edu, nir@nxoc01.cern.ch,
        www-talk@nxoc01.cern.ch, erik.huizer@surfnet.nl,
        mdavies@nri.reston.va.us
Subject: Re: IETF BOF on Universal Document Identifiers
Phone: +44-71-223-4062
In-Reply-To: Your message of Fri, 26 Jun 92 16:04:23 -0400. <9206262004.AA29919@zippy.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 04 Jul 92 15:42:10 +0100
Message-Id: <2362.710260930@isode.com>
From: Steve Hardcastle-Kille <S.Kille@isode.com>

Tim,

I know that this is late in the day, but could I request that you reschedule
your meeting?   

Let me suggest Tuesday: 4-6

The reason is that you are clashing with the OSI-DS group.  I think
that X.500 has a massive role to play in this.   It has also been a
definite part of the disucssions, which I have not ahd time to be
active in.   This timing will exclude me, and probably most of the
other interested X.500 experts.  

Could I request that you consider this seriously, even at this late
stage


Steve

From S.Kille@isode.com  Sun Jul  5 17:41:21 1992
Return-Path: <S.Kille@isode.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00294; Sun, 5 Jul 92 17:41:21 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09752; Sun, 5 Jul 92 11:06:52 +0200
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP 
          id <g.01343-0@haig.cs.ucl.ac.uk>; Sun, 5 Jul 1992 10:06:30 +0100
Received: from localhost by glengoyne.isode.com with SMTP (PP) 
          id <00912-0@glengoyne.isode.com>; Sun, 5 Jul 1992 07:54:07 +0100
To: peterd@expresso.cc.mcgill.ca (Peter Deutsch)
Cc: timbl@zippy.lcs.mit.edu (Tim Berners-Lee), ietf-udi@merit.edu,
        ietf@isi.edu, nir@nxoc01.cern.ch, www-talk@nxoc01.cern.ch,
        erik.huizer@surfnet.nl, mdavies@nri.reston.va.us
Subject: Re: IETF BOF on Universal Document Identifiers
Phone: +44-71-223-4062
In-Reply-To: Your message of Sat, 04 Jul 92 18:27:13 +0000. <9207041827.AA22331@expresso.cc.mcgill.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 05 Jul 92 07:54:01 +0100
Message-Id: <910.710319241@isode.com>
From: Steve Hardcastle-Kille <S.Kille@isode.com>

I did not notice that Tim was in transit.    If there is no immediate
objection to a reschedule, how about booking a second slot for the BOF
(e.g., the Tuesday 4-6 I suggested).   This will give Tim the option

1) To go ahead and ignore the second slot

2) To cancell the meeting and switch

3) To use both slots (eeek)

By deciding a slot now, it means that the mechanics can be sorted
prior to the meeting.   Megan, is this slot available?  (If not, are
there many other options?)


Steve


From peterd@expresso.cc.mcgill.ca  Sun Jul  5 17:45:08 1992
Return-Path: <peterd@expresso.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00448; Sun, 5 Jul 92 17:45:08 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00943; Sat, 4 Jul 92 20:33:08 +0200
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA02201  (mail destined for nir@nxoc01.cern.ch) on Sat, 4 Jul 92 14:27:41 -0400
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA22331; Sat, 4 Jul 92 14:27:13 EDT
Message-Id: <9207041827.AA22331@expresso.cc.mcgill.ca>
In-Reply-To: Steve Hardcastle-Kille's message as of Jul  4, 15:42
From: peterd@expresso.cc.mcgill.ca (Peter Deutsch)
Date: Sat, 4 Jul 92 18:27:13 GMT-0:02
In-Reply-To: Steve Hardcastle-Kille's message as of Jul  4, 15:42
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Steve Hardcastle-Kille <S.Kille@isode.com>,
        timbl@zippy.lcs.mit.edu (Tim Berners-Lee)
Subject: Re: IETF BOF on Universal Document Identifiers
Cc: ietf-udi@merit.edu, ietf@isi.edu, nir@nxoc01.cern.ch,
        www-talk@nxoc01.cern.ch, erik.huizer@surfnet.nl,
        mdavies@nri.reston.va.us


Hmmm, I see this is going back to a lot of people.
apologies in advance for all of the duplicates that this
implies...

[ Steve Hardcastle-Kille writes: ]
> 
> Tim,
> 
> I know that this is late in the day, but could I request that you reschedule
> your meeting?   
> 
> Let me suggest Tuesday: 4-6


For those that missed the note that Karen Sollins sent
out, Tim Berners-Lee has left MIT and is "in transit" to
Boston so probably wont be able to vote on this request
before the start of the IETF conference. Since he was the
one who called the meeting, I suggest that we wait and try
to work out a suitable time and room on day 1 (or day zero
if enough people are around). Everyone watch the notice
board!


> 
> The reason is that you are clashing with the OSI-DS group.  I think
> that X.500 has a massive role to play in this.   It has also been a
> definite part of the disucssions, which I have not ahd time to be
> active in.   This timing will exclude me, and probably most of the
> other interested X.500 experts.  
> 
> Could I request that you consider this seriously, even at this late
> stage

I don't see why anyone would object, but I guess it's Tim's
call.


				- peterd

-- 
----------------------------------------------------------------------
I'm desperately seeking the words to 'Till h\"ogar, Swenson!'
If you have a digitized version, _please_ send me a copy...
                                                -peterd@cc.mcgill.ca
----------------------------------------------------------------------

From peterd@expresso.cc.mcgill.ca  Sun Jul  5 19:10:28 1992
Return-Path: <peterd@expresso.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00741; Sun, 5 Jul 92 19:10:28 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19513; Sun, 5 Jul 92 19:09:36 +0200
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA11192  (mail destined for nir@nxoc01.cern.ch) on Sun, 5 Jul 92 13:04:15 -0400
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA24719; Sun, 5 Jul 92 13:03:46 EDT
Message-Id: <9207051703.AA24719@expresso.cc.mcgill.ca>
In-Reply-To: Steve Hardcastle-Kille's message as of Jul  5,  7:54
From: peterd@expresso.cc.mcgill.ca (Peter Deutsch)
Date: Sun, 5 Jul 92 17:03:45 GMT-0:02
In-Reply-To: Steve Hardcastle-Kille's message as of Jul  5,  7:54
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Steve Hardcastle-Kille <S.Kille@isode.com>
Subject: Re: IETF BOF on Universal Document Identifiers
Cc: timbl@zippy.lcs.mit.edu (Tim Berners-Lee), ietf-udi@merit.edu,
        ietf@isi.edu, nir@nxoc01.cern.ch, www-talk@nxoc01.cern.ch,
        erik.huizer@surfnet.nl, mdavies@nri.reston.va.us

[ Steve Hardcastle-Kille writes: ]
> 
> I did not notice that Tim was in transit.    If there is no immediate
> objection to a reschedule, how about booking a second slot for the BOF
> (e.g., the Tuesday 4-6 I suggested).   This will give Tim the option

I hadn't looked closely at the slot you're suggesting, but
now I've actually checked out the schedule I notice that
it would conflict with the second UserGlos session. As
many of the participants for the NIR session are User
Services people, this seems unwise. I don't see anything
scheduled for Thursday night after the 6pm tech
presentations. Any reason why we can't book a tentative
slot then? It seems that all of the other potential slots
have something of interest (at least to me... :-)

> 1) To go ahead and ignore the second slot
> 
> 2) To cancell the meeting and switch
> 
> 3) To use both slots (eeek)

Actually, judging from the fervor we found at the various
related sessions last time, I bet we _could_ use them
both, but since the objective is to allow everyone to
participate I think finding a new slot is the best we can
hope for. Going for Thursday night means we can go for a
while, i is nothing after except the Bar BOF. :-)

> By deciding a slot now, it means that the mechanics can be sorted
> prior to the meeting.   Megan, is this slot available?  (If not, are
> there many other options?)

I agree that we should reserve something now, and
tentatively suggest Thursday night after the 4-6pm
technical sessions. Obviously people have to eat, so how
about 7pm? Megan? Steve? Others?

				- peterd

-- 
----------------------------------------------------------------------
"It never ceases to amaze me how otherwise decent people
 are willing to pass on these malicious stories that have
 absolutely no validity."  - Ann Landers (writing about urban folklore)
----------------------------------------------------------------------

From wathu@lanka.ccit.arizona.edu  Mon Jul  6 23:43:21 1992
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10965; Mon, 6 Jul 92 23:43:21 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09779; Mon, 6 Jul 92 23:42:49 +0200
Return-Path: wathu@lanka.ccit.arizona.edu
Received: from Lanka.CCIT.Arizona.EDU by Arizona.edu (PMDF #12663) id
 <01GM28O4S39SALD7GU@Arizona.edu>; Mon, 6 Jul 1992 14:42 MST
Received: by lanka.ccit.arizona.edu; Mon, 6 Jul 92 14:43:02 MST
Date: Mon, 6 Jul 92 14:43:02 MST
From: wathu@lanka.ccit.arizona.edu (Wije Wathugala)
Subject: vms reader
To: www-talk@nxoc01.cern.ch
Cc: wathu@arizona.edu
Message-Id: <9207062143.AA10638@lanka.ccit.arizona.edu>
X-Envelope-To: www-talk@info.cern.ch

Hi

I noticed that the vms reader available in info.cern.ch
does not understand <comment> </comment> tags.

Wije

From timbl  Tue Jul  7 01:05:44 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11233; Tue, 7 Jul 92 01:05:44 MET DST
Date: Tue, 7 Jul 92 01:05:44 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9207062305.AA11233@ nxoc01.cern.ch >
To: S.Kille@isode.com, peterd@expresso.cc.mcgill.ca
Subject: Re: IETF BOF on Universal Document Identifiers
Cc: erik.huizer@surfnet.nl, ietf-udi@merit.edu, ietf@isi.edu,
        mdavies@nri.reston.va.us, nir@nxoc01.cern.ch, timbl@zippy.lcs.mit.edu,
        www-talk@nxoc01.cern.ch

I'm sorry that I can only be at the IETF Monday, and Tuesday morning.
I'd like to start things off as soon as possible so that discussions
can then range throughout the week (alas without me).

I will be reading mail on and off until Friday am (from Fermilab).

Tim

Let's sort it out on Monday morning -- there seems to be no clear
soloution (move x500 BOF to second slot though it clashes with
the User Glass?  Actually, interest in user glass and udis may
coincide but the subject areas are not in fact much related...

Tim

From jfg@dxcern.cern.ch  Wed Jul  8 14:56:30 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16658; Wed, 8 Jul 92 14:56:30 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25610; Wed, 8 Jul 92 14:55:59 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA04938; Wed, 8 Jul 92 14:55:41 +0200
Date: Wed, 8 Jul 92 14:55:41 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207081255.AA04938@dxcern.cern.ch>
To: wathu@lanka.ccit.arizona.edu (Wije Wathugala)
Cc: wathu@arizona.edu, www-talk@nxoc01.cern.ch
Subject: Re: vms reader
References: <9207062143.AA10638@lanka.ccit.arizona.edu>

	Wije,

  Thanks for the comment. The binary there is a little older than its
Unix counterparts, and these tags had not been introduced yet. The
next version will have this fixed.

	Jean-Francois

From jfg@dxcern.cern.ch  Wed Jul  8 15:00:06 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16683; Wed, 8 Jul 92 15:00:06 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25818; Wed, 8 Jul 92 14:59:37 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA05277; Wed, 8 Jul 92 14:59:19 +0200
Date: Wed, 8 Jul 92 14:59:19 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207081259.AA05277@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: need assistance on setting up a WWW server


Forwarded From: timbl@nxoc01.cern.ch (Tim Berners-Lee)

Someone just the other day pointed out that the rules file wasn't very well
documented.  I then put in a couple of examples.

Here is the example code (its on the web, linked to the
documentation node about the rule file)

                                             Examples of HTTP daemon rule files
                              RULE FILE EXAMPLES
                                       
   A basic rule file for the http daemon might look like this:
   

map    /          /welcome.html
map    /*         /u/john/public/*
pass   /u/john/public/*
fail   *

   The first line maps the root document onto a specific document about the
   server.
   
   The second line maps all document names onto filenames in a particular
   directory.
   
   The third line allows access to all documenst in that directory.
   
   The fouth line disallows access to all other documents. (There won't be in
   any in this case because of the mapping, but its wise to put in for later).
   
Second example


map    /            /tnotes/welcome.html
map    /tnotes/*    /u/john/public/*
map    /seminars/*  /u/jane/seminars/*
pass   /u/john/public/*
pass   /u/jane/seminars/*.html
fail   *

   The first line maps the root document onto a specific document about the
   server. (See etiquette)
   
   The second line maps all document names starting with /tnote/ onto filenames
   in a particular where john maintains the technical notes. If someone else
   takes over the technical notes, we can change this. Here we are starting to
   distinguish between document names and file names. This can be carried much
   further if necessary, but one level of mapping is enough to allow for
   changes of administration of different areas.
   
   The third line separately maps the seminar information into Jane's
   directory.
   
   The third and forth line enable access to anything in John's "public"
   directory, and any .html file in Jane's "seminar" directory tree. Note here
   that the * maps to any sequence INCLUDING SLASHES so all files in any
   subdirectory of /u/jane/seminars will be enabled so long as they end in
   .html.
   
   The bottom line will pick up for example any attempt to use the server to
   access non-html files in Jane's seminar directory.

From timbl  Thu Jul  9 18:50:36 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20803; Thu, 9 Jul 92 18:50:36 MET DST
Date: Thu, 9 Jul 92 18:50:36 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9207091650.AA20803@ nxoc01.cern.ch >
To: joslyn@kong.gsfc.nasa.gov
Subject: Re: HyTime in WWW?
Cc: www-talk@nxoc01.cern.ch

If there is a hytime construct which is better than what we
have then I'd be very happy to get it included in the next format.
We just need some people to work on that format formally.
Basically, anything which worries you is going to worry us just
as much!

There is a mailing list ww-announce, and another www-talk.
How to join ius on the web (under "mailing lists").
Annocuncements are (too) rare, talk is sometimes heavy,
sometimes not.

Tim
____
From joslyn@kong.gsfc.nasa.gov Thu Jul  9 16:14:32 1992
Return-Path: <joslyn@kong.gsfc.nasa.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20246; Thu, 9 Jul 92 16:14:27 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26395; Thu, 9 Jul 92 16:14:01 +0200
Received: from kong.gsfc.nasa.gov by lego.gsfc.nasa.gov (5.61/1.35)
	id AA22531; Thu, 9 Jul 92 10:13:33 -0400
Received: by kong.gsfc.nasa.gov (4.1/SMI-4.1)
	id AA02563; Thu, 9 Jul 92 10:13:30 EDT
From: joslyn@kong.gsfc.nasa.gov (Cliff Joslyn)
Message-Id: <9207091413.AA02563@kong.gsfc.nasa.gov>
Subject: Re: HyTime in WWW?
To: timbl@nxoc01.cern.ch (Tim@GIBBS.GSFC.NASA.GOV Berners-Lee)
Date: Thu, 9 Jul 92 10:13:29 EDT
In-Reply-To: <9207090441.AA19281@ nxoc01.cern.ch >; from "Tim@GIBBS.GSFC.NASA.GOV Berners-Lee" at Jul 9, 92 6:41 am
X-Mailer: ELM [version 2.3 PL11]
Status: R

> I have to admit that although I have skip-read HyTime I am not
> an expert. Charles Goldfarb suggested we write a generic HyTime
> engine, but my impression was that most of HyTime we didn't
> want (Finite coodinate systems, for example). 

Yes, us too. But my impression is that the INTENTION of HyTime is to
be able to use whichever portions are appropriate. Certainly
hypertext-only applications were envisioned. Personally, I think that
HyTime's alinks are the most elegant link structures I've seen.
They're completely generic n-ary relations.

The gain would be standard adherence for  long-run compatibility. I'd
hate to start marking our nodes up in your HTML only to find it's of
limitted compatibility with the world 10 years from now.

Thanks for the reply. I'm glad that Newcomb is involved. What's the
best way to keep informed about how W3 is proceedingd? Just
periodically reading the "What's New" node? Or do you have a separate
pamil or email list?

O----------------------------------------------------------------------------->
| Cliff Joslyn, Cybernetician at Large, 327 Spring St #2 Portland ME 04102 USA
| Systems Science, SUNY Binghamton      NASA Goddard Space Flight Center
| cjoslyn@bingsuns.cc.binghamton.edu    joslyn@kong.gsfc.nasa.gov
| ^^^^^^   !NOTE NEW EMAIL!   ^^^^^^
V All the world is biscuit shaped. . .


From emv@nigel.msen.com  Thu Jul  9 21:02:13 1992
Return-Path: <emv@nigel.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21209; Thu, 9 Jul 92 21:02:13 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16604; Thu, 9 Jul 92 21:01:43 +0200
Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0m63k2-0009ZdC@nigel.msen.com>; Thu, 9 Jul 92 15:01 WET DST
Message-Id: <m0m63k2-0009ZdC@nigel.msen.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: joslyn@kong.gsfc.nasa.gov, www-talk@nxoc01.cern.ch
Subject: Re: HyTime in WWW? 
In-Reply-To: Your message of Thu, 09 Jul 92 18:50:36.
             <9207091650.AA20803@ nxoc01.cern.ch > 
Date: Thu, 09 Jul 92 15:01:07 EDT
From: Edward Vielmetti <emv@msen.com>

I got a mailing today (from an SGML development firm which I will name
upon request) asking $20,000 in advance for a beta copy of their Hytime
engine.  From that bit of pricing information I gather
 - a full Hytime engine in all its glory is going to be a lot of work
   to write
 - the marketplace is not very mature

Needless to say I have other things that I'd like to spend $20K on....

--Ed

From connolly@pixel.convex.com  Tue Jul 14 20:40:47 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01449; Tue, 14 Jul 92 20:40:47 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29445; Tue, 14 Jul 92 20:40:28 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA06435; Tue, 14 Jul 92 13:39:59 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA10602; Tue, 14 Jul 92 13:39:54 -0500
Message-Id: <9207141839.AA10602@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: rethinking the HTML DTD.
Date: Tue, 14 Jul 92 13:39:53 CDT
From: Dan Connolly <connolly@pixel.convex.com>

I have been troubled by the fact that HTML documents look like SGML documents,
but technically, they are not. So I have tried to come up with a DTD that
captures the features of HTML.

I have come to the conclusion that HTML has very little structure, and that this
is by design.

I am beginning to wonder how much the needs of WWW have in common with the
features of SGML.

It seems to me that SGML is the technology of choice when you have a community
of information consumers and producers that share a common structure. e.g. the
construction industry might use SGML to exchange bill of materials, parts lists,
inventories, etc. The SGML parser would be used to verify part numbers, make
sure every widget has a corresponding gadget, etc.

The WWW project is a form of electronic publishing, however, and publishing is a
natural application of SGML. But the value of SGML is that you can verify the
structure of the text. A publisher can specify in his DTD the format
of references, bibliography entries, the placement of the abstract, etc.

The WWW project has no such editorial policies to enforce. The editorial
policies set forth in the HTML tag set are things like "you can have a title, if
you want, and we'll keep it visible for the user; you can have headings and
paragraphs and glossaries and lists and menus, and as long as you use them
in pretty much the traditional way, they'll be formatted reasonably. And
you can have anchors -- references from/to other documents."

The question that recently came into my mind is: why is the WWW project
defining such a tag set? The practical answer is that the NeXT implementation
has a nifty editor, and we'd like to be able to write nicely formatted documents
and display them nicely on nice terminals and simply on simple terminals.

Honestly, for that purpose, RTF is a more mature technology. The NeXT has
extensive support for RTF, and the Mac and the PC have some support.

I think all we're lacking is public implementations of RTF->ASCII,
RTF->Postscript, and RTF->X Windows renderers. MS Word and NeXT
edit would be fine editors. Really, for the kind of casual documents
the WWW project deals with, SGML is not a good match. Who really
uses all the "format independent" features of WWW? I haven't seen
anything that the RTF stylesheet features can't handle.

Unless we want some part of the WWW system to verify the structure
of documents, why are we using SGML (and using it poorly)?

Granted RTF doesn't have very good hypertext and multimedia features,
but that's what the WWW project is all about: experimenting with
hypertext and multimedia. We could standardize multimedia RTF conventions
as well as we have done for SGML.

Comments?

Dan

From timbl  Tue Jul 14 20:51:26 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01479; Tue, 14 Jul 92 20:51:26 MET DST
Date: Tue, 14 Jul 92 20:51:26 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9207141851.AA01479@ nxoc01.cern.ch >
To: CNI-ARCH@uccvma.bitnet
Subject: Re: Citations Using Message Ids for Notes in Logs
Cc: www-talk@nxoc01.cern.ch


By the way, I see a really useful project which is up for grabs
right now is a server which hoards mail, inexes it, and fills
in all the back-links so you can follow messages which have
refered to article X, follow a link to people and lists
of messages they have written, etc.  The server could
simultaneously handle news, and eliminate the barrier (and
duplication) between the two methods of propogation.

This would be a cool excercise in the management of unruly
information, and a tool which most project managers would jump
at.

Any takers?

   Tim

From connolly@pixel.convex.com  Tue Jul 14 21:55:57 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01631; Tue, 14 Jul 92 21:55:57 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04062; Tue, 14 Jul 92 21:55:33 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA10403; Tue, 14 Jul 92 14:55:01 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA20257; Tue, 14 Jul 92 14:54:59 -0500
Message-Id: <9207141954.AA20257@pixel.convex.com>
To: davis@willow.tc.cornell.edu (Jim Davis)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: rethinking the HTML DTD. 
In-Reply-To: Your message of "Tue, 14 Jul 92 15:48:32 EDT."
             <9207141948.AA04895@willow.tc.cornell.edu> 
Date: Tue, 14 Jul 92 14:54:58 CDT
From: Dan Connolly <connolly@pixel.convex.com>


>As far as I can tell the richtext in RFC1143 is kind of a quick
>and dirty hack.  I had no experience with the microsoft standard
>so of course I cant compare it but the rfc1143 richtext looks
>like a step backwards from html even.
>
In what way? This is exactly the point of my message: that HTML
is nothing more than rtf1143 RichText plus anchors. I'd like
to hear the flip side of the argument.

>is there an online definition of RTF?

I have an old (and in my opinion, poorly written) RTF
spec from a Microsoft programming journal. There's another
thing often called Rich_Text_Format_Specs.hqx (see archie
for FTP site nearest you), but it has at least one
inaccuracy (regarding newlines) and I don't know where it came from.

The best work I've seen on RTF is:
---------------------
.NH
Distribution and Update Availability
.LP
The RTF
distribution may be freely circulated and is available for
anonymous FTP access under the
.I ~ftp/pub
directory on host
.I ftp.primate.wisc.edu .
Updates appear there as they become available.
.LP
If you do not have FTP access, send requests to the address
.I software@primate.wisc.edu .
Bug reports, questions, suggestions and comments may be sent to
this address as well.
---------------------

by:
Paul DuBois
dubois@primate.wisc.edu


Have at it.

Dan

From timbl  Wed Jul 15 00:03:56 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02008; Wed, 15 Jul 92 00:03:56 MET DST
Date: Wed, 15 Jul 92 00:03:56 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9207142203.AA02008@ nxoc01.cern.ch >
To: connolly@pixel.convex.com, www-talk@nxoc01.cern.ch
Subject: Re: rethinking the HTML DTD.

Dan,

You say HTML is not SGML.  It is true that the HTML generted by the NeXT editor
is not good. (example, lack of quotes around attributes which need them.)
Hwoever, the current parser wil parse real SGML. 

I feel it IS important to keep the higher-level markup.
Ypu ask, " Who really
uses all the "format independent" features of WWW? I haven't seen
anything that the RTF stylesheet features can't handle."

Well, the line-mode browser uses these features to generate a particular
style which is different from the Xwindows style.  The LaTeX generation
scripts which we use to make the "www book" use the high-level markup.

It is true that HTML does not have a deep structure, so that we can
be compatible with software whichcannot handle nested elements.
There is nothing wrong with having a simple SGML DTD as a basic case.
SGML does not HAVE to be complicated.  You can use SGML to map any
(non-overlapping) structure you like.

In the future, the web will inclued more complex DTDs, and dynamically
loaded DTDs, and people will want to use the same parser for it.

You suggest that we should use RTF because it is better supported.
Maybe we could use RTF in parallel in an experiment.  Soe problems
I have are that

RTF uses a fudge of specially names styles to represent headings
(for example, in Word) from which the WP deduces a structure
(for outline mode, etc).

RTF has styles, but as far as I could see Microsoft RTF documents
have teh actuall formatting information always tucked in there even
if it there is a style name attached.

RTF has various extensions fopr handling for example embedded documents
and links, but are these standard ized, or are different manufacturers
going to use different tagsets in RTF just like SGML?


Perhaps I am out of date in my knowledge of RTF (I certainly am).
However, I see the WP manufacturers trying to escape from a position
where they are historically bound to an RTF view, when they would like
to be able to handle SGML.

If you're talking about displaying things, to make HTML into RTF
is trivial.  You can make HTML into MIF too. You have to add
style information of course.  When you go back you have to do this
fudge of requiring the same style names to be used.

So I feel RTF would be a backward step. It is true that the current
W3 software is at a point level with RTF rather than general SGML.
But why tie ourselves to that point?

	Tim

From connolly@pixel.convex.com  Wed Jul 15 00:26:56 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02064; Wed, 15 Jul 92 00:26:56 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13260; Wed, 15 Jul 92 00:26:28 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA18318; Tue, 14 Jul 92 17:25:58 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA07409; Tue, 14 Jul 92 17:25:57 -0500
Message-Id: <9207142225.AA07409@pixel.convex.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: rethinking the HTML DTD. 
In-Reply-To: Your message of "Wed, 15 Jul 92 00:03:56 +0700."
             <9207142203.AA02008@ nxoc01.cern.ch > 
Date: Tue, 14 Jul 92 17:25:56 CDT
From: Dan Connolly <connolly@pixel.convex.com>


Ok, so we really do want to use SGML. Good. I agree. I just
wanted to hear from the WWW community.

>
>You say HTML is not SGML.  It is true that the HTML generted by the NeXT editor
>is not good. (example, lack of quotes around attributes which need them.)
>Hwoever, the current parser wil parse real SGML. 
>
The biggest problem with HTML files is that they have only 1 of the 3
basic parts of an SGML document: the SGML declaration, the prologue,
and the instnace. HTML documents only have the instance. It's legal
to omit the SGML declaration -- there's a default. But you've got
to have a prologue, or you end up with a non-standard way of infering
the prologue (for example, every WWW client infers the DTD described
in "http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html".)

So if we're commited to SGML, let's start putting something like

<!DOCTYPE HTML SYSTEM "http://info.cern.ch/hypertext/WWW/MarkUp/html.dtd">

at the front of every HTML file (we don't have to store it in the
file -- servers that distribute HTML could generate it on the fly.)
And let's put _some_ kind of DTD there.

>In the future, the web will inclued more complex DTDs, and dynamically
>loaded DTDs, and people will want to use the same parser for it.
>
Interesting! There are plans to support more than one DTD!
This makes SGML a clear winner.

>So I feel RTF would be a backward step. It is true that the current
>W3 software is at a point level with RTF rather than general SGML.
>But why tie ourselves to that point?
>

I guess that's what I wanted to hear: that the goals of WWW and the
features of SGML really _do_ have a lot in common, but the current
implementation doesn't support many of them.

Just to make sure I've beat this horse to death: let's begin to
formalize HTML and validate existing HTML documents before the
distance between HTML and SGML gets too big.

Dan

p.s. I'm working on a DTD that reflects the structure of most existing
word-processor documents: a sequence of paragraphs (maybe broken
into flows, sections, or whatever). I'll have RTF and MIF translators
for the DTD when it's ready. Maybe HTML2 can use some of the features --
the low level character-set related features, anyway.



From timbl  Wed Jul 15 00:33:09 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02089; Wed, 15 Jul 92 00:33:09 MET DST
Date: Wed, 15 Jul 92 00:33:09 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9207142233.AA02089@ nxoc01.cern.ch >
To: fkappe@fiicmds04.tu-graz.ac.at, www-talk@nxoc01.cern.ch
Subject: Re: HTML DTD and related problems (rather long)

I am replying very late to a message of Frank Kappe,
dated 25 Jun 1992.

First of all, to clear up some things about W3 HTML.
You can't nest anchors.
You can't nest anything EXCEPT you can put any elements inside
an anchor (excpt for other anchors) and you can put an anchor
inside any elements.
Then there is the slight structure of the <DL>[<DT><DD>]*</DL>
etc which is required.

I think I emntioned in earlier messages that the lack of structure
is to make it easier to process HTML on systems which have styled
text (like most systems, MSWord etc).

Now it is interesting that you in Gyper-G allow anchors to be
any section of the text.  This of course is counter to the
SGML philosophy of strict nesting (SGML people can get quite
religeous about this, but I can't.)  I think it is useful
to be able to refer to two separate overlapping anchors.
The problem is it is taken as given by any SGML DTD designer
that this sort of structure in a document is "BAD". This
means that SGML tools won't be able to process the <AS>
and <AE> (anchor start and anchor end) tags, you'll have to
write something special on top which keep track of anchors.
AGML parsers won't be able to verify the anchor structure.
So though the DTD is valid, but it doesn't in fact representthe restrictions.

You say that you feel it is better to store the links separately
rather than in the document.  First of all let me say that W3 does NOT
require you to do that -- it just requires that the links, anchors
and text are transmitted at the same time on the net. That is very different.
Many systems generate the HTML on the fly from other sources of link
information.

Nowlooking at this question of where to store the links, the 'link database"
model you propose is the Intermedia model of Norman Meyrowitz et al.
This was developped in a non-distributed environment, where a "web"
(database of links) was available to the readers and centrally coordinated.
If you expand that system to more than one web server, and scale it to
global, then you find that the same problems of ensuring consistency
occur between the multiple link databases when before they occured between dcouments.  You can't set up a system of bidirectional links for example,
which you could in the non-distributed case.

Link databases have their advantages, though.  A model I am rather keen on
atthe moment is of servers which are both link databases and
source code control (sccs, rcs etc) systems.  In this world,
you don't need to store anchors at all -- you just quote the
character number AND VERSION number of the document.  To find an
anchor, if you have a more recent version than the one referred to in the anchor,
you have to ask the server to translate the anchor's position in the
old document into a position in the new one. It may reply with
the same or a didfferent position, or that as far as its "diff"
algorithms go, it can't find where the original anchor text would
be in the new document, or it might really have gone.
This would allow links to be made around source code (for which you want
source code control anyway).

There would be common problems when you do the sorts of changes which
diff can't handle intelligently, like you swap the two halves of a file,
or you change all the "a_"s to "A_".  In these cases, a smart editor
would be able to explian each editing change to the server as it goes,
to the server would understand the relationship between the pre-edit
and post-edit versions.  If you are going to do that, then you can
go a small extra step and make the server coordinate simultaneous edits
by many people, which gives you a group editor.

   Tim

From timbl  Wed Jul 15 00:55:36 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02153; Wed, 15 Jul 92 00:55:36 MET DST
Date: Wed, 15 Jul 92 00:55:36 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9207142255.AA02153@ nxoc01.cern.ch >
To: connolly@pixel.convex.com, timbl@nxoc01.cern.ch
Subject: Re: rethinking the HTML DTD.
Cc: www-talk@nxoc01.cern.ch

Dan,

You had a DTD which was almost HTML as it now is. I can't remeber the
syntax but it needs to have something along the lines of

   nonanchor = H! | H2 | text | DL ...
   anchor =    <A> nonanchors </A>
   document_bit = anchor | nonanchor

to get the restriction of not nesting anchors, not nesting DLs,
but being able to put anchors within DLs OR DLs within anchors.
If you could write that in DTD and mail it ten (when I come back
from vacation I or someone else) will put it into the web for
people to refer to.  If we get complains from some SGML parsers that
its not right, we can fix it. But we should have something there
as an attempt to document current practice.

I don't think the Daveport group (who are thinking about DTDs for
documentation seriously) are in on this list, and I'm not in on theirs.
I would like to get some UDI (The meeting att he IETf yesterday decided
to call them URLs -- Uniform Resource Locators -- minutes are in
 http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html)
(but I digress) of the davenport group's working documents.
I'll go to their meeting in Sebastopol 16th-18th August if I can
and see what they are doing...

Tim

From wei@xcf.berkeley.edu  Wed Jul 15 19:45:27 1992
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04292; Wed, 15 Jul 92 19:45:27 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19791; Wed, 15 Jul 92 19:45:11 +0200
Received: by con.Berkeley.EDU (5.65/XCF-1.34)
	id AA04407; Wed, 15 Jul 92 10:46:00 -0700
Date: Wed, 15 Jul 92 10:46:00 -0700
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9207151746.AA04407@con.Berkeley.EDU>
To: www-talk@nxoc01.cern.ch
Subject: viola update (with latest W3 library)

There's now a version of the viola WWW browser that uses the latest W3
library (extracted from the LineMode Browser 1.2h).

ftp://xcf.berkeley.edu/src/local/viola
-rwxr-xr-x  1 root      1011631 Jul 15 08:03 viola.decstation.Z
-rwxr-xr-x  1 root       516420 Jul 15 09:00 viola.sparc.Z
-rw-r--r--  1 root       697658 Jul 15 09:03 viola.tar.Z

Anyone up for kicking the tires? It's slightly evermore reliable than
the previous version, and should be gentler than the previous version in
regards to network traffic (how substantial is hard for me to measure).
I'm particularly interested in knowing if the font metrix problem is
still present (the "gosh, it's eating up lots of CPU doing nothing" bug).

-Pei


From connolly@pixel.convex.com  Thu Jul 16 05:36:01 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05320; Thu, 16 Jul 92 05:36:01 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02349; Thu, 16 Jul 92 05:35:44 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA25162; Wed, 15 Jul 92 22:35:21 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA24812; Wed, 15 Jul 92 22:35:19 -0500
Message-Id: <9207160335.AA24812@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML DTD enclosed
Date: Wed, 15 Jul 92 22:35:19 CDT
From: Dan Connolly <connolly@pixel.convex.com>

<!-- html.dtd - document type declaration subset for
                HyperText Markup Language as defined
		by the World Wide Web project.

	15 Jul 92 by connolly@convex.com

	See also: http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
  -->

<!--      Terminal symbols        -->

<!ENTITY lt "<">
<!ENTITY gt ">">
<!ENTITY amp "&">

<!-- some existing html uses these. I think they meant
	&amp;
     in stead of 
	&amp.
     -->
<!ENTITY lt. "<">
<!ENTITY gt. ">">
<!ENTITY amp. "&">

<!--    Non-ELEMENT symbols       -->

<!ENTITY % heading "H1|H2|H3|H4|H5|H6" >
<!ENTITY % list "UL|OL|DIR|MENU|DL">
<!ENTITY % text "P|#PCDATA">
<!ENTITY % raw "XMP|LISTING">
<!-- PlainText is more than 8 characters, and changing the
     NAMELEN capacity involves including a lengthy SGML declaration
     in every HTML file. Besides: the semantics of PlainText can't
     be captured by real SGML anyway. -->
<!ENTITY % body "%heading|%list|%text|%raw">

<!--     Document structure       -->

<!ELEMENT HTML	O O  ((TITLE? & NEXTID? & ISINDEX?), BODY, ADDRESS?)>

<!ELEMENT TITLE	- -  (#PCDATA)>

<!ELEMENT NEXTID - O EMPTY >
<!ATTLIST NEXTID N NUMBER #REQUIRED>
<!-- as noted in Tags.html, the conventional <NEXTID 10> is
     illegal. Use <NEXTID N=10> to comply with this DTD. -->

<!ELEMENT ISINDEX - O EMPTY >

<!ELEMENT BODY O O ((%heading), (%body)+) +(A)>
<!-- The BODY element is necessary to avoid mixed content
     in the HTML element. Mixed content and optional elements
     don't mix very well. -->

<!ELEMENT (%heading)	- -  (%text)+
	--Tags.html says titles should fit on one line, but
	the browser handles paragraph breaks inside headings
	gracefully. -->

<!ELEMENT (MENU|UL|OL|DIR) - -  (LI+)>

<!ELEMENT DL	- -  ((DT, DD)+)>

<!ELEMENT LI	- O  (%text)+>
<!ELEMENT DT	- O  (#PCDATA)+>
<!ELEMENT DD	- O  (%text)+>
<!ELEMENT ADDRESS - O (%text)+ +(A)>
<!-- Tags.html says "This tag is for address information, signatures,
etc, normally at the top or bottom of a document." Here, it is only
allowed at the end of a document. -->

<!ELEMENT (%raw) - -  CDATA>
<!-- BUG:
tags.html says that you can put anything but </XMP> in the
text of an XMP element. SGML says that ETAGO, "</" ends a CDATA
section.
-->

<!ELEMENT P	- O  EMPTY -- paragraph SEPARATOR -->

<!-- We could use this to let blank lines separate paragraphs
  <!ENTITY   ptag   STARTTAG "p">
  <!SHORTREF bodymap "&#RS;&#RE;" ptag>
  <!USEMAP   bodymap  BODY;>
  -->

<!ELEMENT A	- -  (%body)+>
<!ATTLIST A
	HREF CDATA #IMPLIED -- attribute values with colons etc. must
				be quoted. --
	NAME CDATA #IMPLIED
	TYPE CDATA #IMPLIED >


From connolly@pixel.convex.com  Thu Jul 16 05:50:02 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05332; Thu, 16 Jul 92 05:50:02 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05889; Thu, 16 Jul 92 05:49:45 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA25548; Wed, 15 Jul 92 22:49:23 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA25229; Wed, 15 Jul 92 22:49:22 -0500
Message-Id: <9207160349.AA25229@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: perl script to legalize HTML files
Date: Wed, 15 Jul 92 22:49:21 CDT
From: Dan Connolly <connolly@pixel.convex.com>

#!/usr/local/bin/perl
#
# USE
#   fix-html.pl <W3-file.html >W3-file.sgml
#
# SEE ALSO
#   the html.dtd.
#

print "<!DOCTYPE HTML SYSTEM>\n";

@html = <>;			# read whole file
$_ = join('', @html);

while(/</){
    &out($`);
    $_ = $';
    if(s/^A\s+//i){
	&fix_anchor;
    }elsif(s/^NEXTID\s+(\d+)\s*>//){
	&out("<NEXTID N=$1>");
    }else{
	&out('<');
    }
}

&out($_);

sub out{
    print $_[0];
}

sub fix_anchor{
    local($name, $href, $type);

    # What exactly is the syntax of an SGML attribute value?
    while(s/^(\w+)\s*=\s*((\"[^\"]*\")|([^\s>]+))\s*//){
	local($v) = ($3 || $4);
	local($a) = $1;
	$href = $v if $a =~ /^href$/i;
	$name = $v if $a =~ /^name$/i;
	$type = $v if $a =~ /^type$/i;
    }
    s/[^>]*>//;

    &out("<A");
    &out(" NAME=\"$name\"") if $name ne '';
    &out(" TYPE=\"$type\"") if $type ne '';
    &out(" HREF=\"$href\"") if $href ne '';
    &out(">");
}

From connolly@pixel.convex.com  Thu Jul 16 06:07:03 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05357; Thu, 16 Jul 92 06:07:03 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11230; Thu, 16 Jul 92 06:06:44 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA26267; Wed, 15 Jul 92 23:06:19 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA28878; Wed, 15 Jul 92 23:06:17 -0500
Message-Id: <9207160406.AA28878@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: RE: Minutes of the "UDI" BOF at the 24th IETF
Mime-Version: 1.0
Content-Type: text/x-html
Date: Wed, 15 Jul 92 23:06:17 CDT
From: Dan Connolly <connolly@pixel.convex.com>

<!DOCTYPE HTML SYSTEM>
<H1>RE: 
<A HREF=
"http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
Minutes of the "UDI" BOF at the 24th IETF</A></H1>

[The gopher folks are dicussing how to add the "reply"
feature from USENET newsreaders to gopher clients.
I wish www had that feature too. The "followup" feature
is currently beyond the scope of WWW, but...]
<p>

[I'm beginning to wish www was a mail user agent and
a gopher client and a news reader and a WAIS client
all in one. Soon...]
<p>

[We need a DTD that models the USENET thread model,
with posts, followups, quotes, points, counterpoints,
flames, signatures, etc.<p>

Right now, I have to modify a destination document (add an anchor) to
link to an element of that document. We should look at what HyTime and
the TEI use for references to SGML elements without IDs. I saw a
HyTime description that said you could link to non-hyptime documents.
Maybe we could use this to reference passages of news articles etc.  ]

<p>

<H2>Quote</H2>

The information one quoted in a reference to an object could comprise
many things, among which were possible one unique name, (Unique
Resource Number, URN was one acronym), and zero or more addresses
(Uniform Resource Locators or URLs) which gave instructions for
retrieving the object.

<h2>Response</H2>

Cool! The model for global hypertext that swims around in my mind
includes references which consist of identifiers and addresses. On the
subject of URNs, it sure would be nice to be able to verify that the
data mentioned in the link and the data retrieved from the URL are the
same.
<p>

For instance, I could reference an FTP file, and somebody could
write over it. I might look like a fool arguing against old
information. If I give a URN in the link, the browser could warn
that it doesn't match the URN of the retrieved document.

<h2>Quote</h2>

NOT to be discussed were the differences between names and addresses,
URN schemes (which are not yet well enough defined), the full set of
information to be given in a reference, or IPv7.
<p>

<h2>response</h2>

I think internet message ID's make great URN's.

<h2>quote</h2>

To be discussed were the overall string syntax, including allowed
characters and escaping systems for unallowed characters, the order of
components (little/big-endian), punctuation characters, the particular
prefix to be used to identify each namespace.

<h2>Response</h2>

Cool. This makes URLs orthogonal to MIME external body part
references. I believe where they are not orthogonal, they should
coincide.

<h2>quote</h2>

It was pointed out that for WAIS one could imagine a separate name
space for databases and for documents. If this was taken futher, a
separate prefix would be used for each type of object. It was on
balance agreed that this could go too far. One prefix should be used
per protocol, but it should be made clear how to determine the type of
an object from the URL.

<h2>response</h2>

Note how nicely all this coincides with MIME external body part
constructs. Such a body part looks like, for example:<XMP>
Content-Type: message/external-body;
	access-type=x-http;
	host="info.cern.ch";
	path="/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html"

Content-Description: Minutes of the "UDI" BOF at the 24th IETF
Content-Type: text/x-html

</XMP>
<p>

In general, a MIME external body part looks like:<XMP>
Content-Type: message/external-body;
	access-type=_type_; /* local-file, anon-ftp, afs, or x-token */
	_other_parameters_ /* path, host, name, database, etc. */

Content-ID: _message-id_ /* of external body part */
Content-Description: here's what you'll get!
Content-Type: _base_/_subtype_ /* type of data in external body part */

ghost body goes here. This is _not_ the contents of the body part,
but it is available to the user agent that's fetching the data.
It could be used, for example, for the seed-words of a WAIS reference.
</XMP>

It looks like a URL is a condensed version of the MIME external body
part headers. The URL scheme:____blah____ syntax maps nicely to
MIME access-type=scheme; ___parameters for blah___.

<h2>quote</h2>

The class of object you get back should be predictable (--C Lynch).
W3 has a real problem with that, since everything is a "document" and
handled in a similar way.

<h2>response</h2>

I don't agree that "everything is a 'document'" to the W3 browser. The
browser knows it's getting gopher directory info from gopher UDI's,
for example. I think the type of data it returns can and should be
classified by the MIME typing system, even if it does so implicitly.

<h2>quote</h2>

Should one use punctuation, or attribute-value pairs? Attribute value
pairs get mispelt. (note x.400 vs.internet addresses)<p>
   
It was decided to use a short string with punctuation rather than an
attribute-value pair system.<p>

<h2>response</h2>
I have doubts about the ability to be able to encode all this
information (scheme, host, path/selector-string, type, etc) in
something akin to a phone number that can be written on one line of
text with no spaces. I think that within each scheme, folks develop
printable syntaxes for making references (ange-ftp, WAIS source files,
etc.).<p>

But the scope of URLs is so vast that I wonder if folks will form
habits over this whole domain.<p>

I advocate that the W3 format include, at least experimentally, an
SGML element for each access type, with the URL pre-parsed into
attribute-value pairs. The anchor element could become more complex,
including sub-elements for URLs and URNs. Data type information could
be included somewhere.<p>

The HTTP access type doesn't require type information: format
negociation is part of the HTTP protocol. But WAIS and Gopher
references require these types, and it would be nice for FTP
references (at least to choose between image and text transfers.)<p>

I'll think it over and work on a DTD that uses these pre-parsed URLs.

How do these examples look?
<XMP>
<A HREF=
"http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
Minutes of the "UDI" BOF at the 24th IETF< /A>

becomes

<A><HTTP host="info.cern.ch"
 path="/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
Minutes of the "UDI" BOF at the 24th IETF< /A>

and

<A NAME=gopher
HREF=gopher://gopher.micro.umn.edu:70/11/Other%20Gopher%20and%20Information%20Servers>
list of sites< /A>

becomes

<A NAME=gopher>
<Gopher type="text/x-gopher-1"
        host="gopher.micro.umn.edu" port=70
        selector="1/Other Gopher And Information Servers">
list of sites< /A>
</XMP>

The idea here is that we've got a parser already: the SGML parser.
Why not use it to parse the various bits of data we need to reference
data located elsewhere?

<h2>quote</h2>

A separate issue of whether human or only machine readable.
Previously, included issue of printable.  This is needed because don't
have names now.  Question arose of whether once these addresses exist
will be replaceable with names - will be presented as new
functionality, not replacing existing systems. Agreement on some way
of specifying class of objects.

<h2>response</h2>

This reminds me of <A HREF="AUGMENT:132082,#11l"> Knowledge-Domain
Interoperability & an Open Hyperdocument System
</A>
 by Douglas C. Engelbart in which he gives requirements for his
system.
<p>

One of them is:

<H4>Hard-Copy Print Options to Show Addresses of Objects and Address
Specification of Links</H4>

<h5> ... so that, besides online workers being
able to follow a link-citation path (manually, or via an automatic
link jump), people working with associated hard copy can read and
iterpret the link-citation, and follow the indicated path to the cited
object in the designated hard-copy document.<p>
<p>

Also, suppose that a hard-copy worker wants to have a like to a given
object established in the online file. By visual inspection of the
hard copy, he should be able to determine a valid address path to that
object and for instance hand-write an appropriate link specification
for later online entry, or dicate it over a phone to a colleague.</H5>

That document deserves a thorough reading by the whole
comp.infosystems.* community.

<h2>quote</h2>

IT WAS AGREED that the context, or namespace, prefix be the first
(leftmost) part of the URL, and be separated from the rest of the URL
by a colon.

<h2>response</h2>

Has anybody given any thought to a syntax with implied schemes so that
the ange-ftp style URLs and internet message ID URNs that are out
there can be used?<p>

If we reserved a character to _start_ UDIs, then we could try to infer
the scheme of strings that don't start with that char. Let's take
() for URL schemes and [] for URN schemes.

<XMP>
For example: host:path == (ANON-FTP)host:path
             path@host == (ANON-FTP)host:path
             <message-id@host> == [rfc-822]<message-id@host>
</XMP>

Well, I suppose this type of thing is really akin to the W3 local
UDI scheme: it's application specific.<p>

<h6>Postscript: This document was prepared using emacs with the help
of Eric Naggum's
<A HREF="file://ftp.ifi.uio.no/pub/SGML/elisp/sgml-mode.el">
sgml-mode</A>, and verified by sgmls-0.8 with the DTD in <A
HREF="message-id:<9207160335.AA24812@pixel.convex.com>">html.dtd
</a>
. This is proof of concept that the W3 browser handles conforming
SGML. I also wrote
<a
href="message-id:<9207160349.AA25229@pixel.convex.com>"> a short perl
script</a> that will bring many existing HTML files into conformance.

</h6>

From davis@willow.tc.cornell.edu  Thu Jul 16 14:50:20 1992
Return-Path: <davis@willow.tc.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06423; Thu, 16 Jul 92 14:50:20 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26980; Thu, 16 Jul 92 14:50:04 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
	id AA23237; Thu, 16 Jul 92 08:51:35 EDT
Date: Thu, 16 Jul 92 08:51:35 EDT
From: davis@willow.tc.cornell.edu (Jim Davis)
Message-Id: <9207161251.AA23237@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: reading HTML mail

I don't know how many of you are using Mime for your mail (other
than Dan) but I am starting to.  So today I modified my mailcap
to be handle text/x-html messages, and since there was a little
difficulty I thought I share it with you.

Here is what I added to my mailcap

text/x-html; mime-show-html -f %s; needsterminal

The command mime-show-html is a new script I wrote.  It starts
up the Viola WWW browser (for which I thank the author!) but
there are some small problems with Viola

1) It seems that it requires that the file have suffix html
in order to work
2) You can't tell it what file to read from the command line,
rather you must set an environment variable.

So I wrote this little script:

#!/bin/csh
# Run the Viola WWW X windows hypertext system for a Mime message
# I expect caller (metamail) to supply the file to read with -f,
# and it will be a /tmp file

# Process args 
while ($#argv > 0 && "$1" =~ -*)
  switch ($1)
  case -f:
    shift
    if ($#argv < 1) goto usage
    set TEMP = $1.html
    cp $1 $TEMP
    setenv WWW_HOME $TEMP
    shift
    breaksw
  default:
    goto usage
    breaksw
 endsw
end

set VIOLA=/usr/local/WWW/Viola
setenv VIOLA_PATH $VIOLA/apps
$VIOLA/bin/viola 
rm $TEMP
exit 0

usage:
 echo "usage: `basename $0` [-f HTML-FILE]"
 exit 1

If you wish to use this script you will need to change the
setting of VIOLA depending on where you installed it.

Best wishes, and now we can use Mime to send WWW to each
other more easily.  

From jfg@dxcern.cern.ch  Thu Jul 16 16:27:24 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06675; Thu, 16 Jul 92 16:27:24 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04099; Thu, 16 Jul 92 16:27:08 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA10071; Thu, 16 Jul 92 16:26:51 +0200
Date: Thu, 16 Jul 92 16:26:51 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207161426.AA10071@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML DTD enclosed
References: <9207160335.AA24812@pixel.convex.com>

  Thanks Dan for this revised HTML DTD. Some comments after a quick
glance (please bear with me as I'm no SGML expert...) :

> <!-- Tags.html says "This tag is for address information, signatures,
> etc, normally at the top or bottom of a document." Here, it is only
> allowed at the end of a document. -->

  We wanted addresses to be lawful both at the top or at the bottom of
a document because of the traditions of some information sources that
we can access, e.g. for Internet news, the address part is extracted
from various headers and displayed first. This makes sense in those
systems where the author name changes often from a document to the
next (in the order you read them). On the contrary, in technical
documentation like the WWW tree, it would be obnoxious to repeat the
author's name at the top of every page. There are even cases where
people cite several people at different points in the same document
within <Address> tags. So my opinion is that we should leave this tag
legal anywhere, or at least at both top and bottom.

> Tags.html says that you can put anything but </XMP> in the
> text of an XMP element. SGML says that ETAGO, "</" ends a CDATA
> section.

  This will be easy to fix in the next release of the browsers.

> 	HREF CDATA #IMPLIED -- attribute values with colons etc. must
>				be quoted. --

  The NeXT editor doesn't quote them: bad behaviour to be fixed. Also
fix every server generating anchors on the fly...

  I've put the DTD and the legalizer in the web: just follow HTML.

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"Life may at times be boring, but is it more fun to be dead ?"
                                                  -- Alcor


From mad@merit.edu  Thu Jul 16 18:13:35 1992
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07018; Thu, 16 Jul 92 18:13:35 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12513; Thu, 16 Jul 92 18:13:23 +0200
Return-Path: <mad@merit.edu>
Received: from home.merit.edu by merit.edu (5.65/1123-1.0)
	id AA11246; Thu, 16 Jul 92 12:13:00 -0400
Received: by home.merit.edu (4.1/client-0.9)
	id AA19009; Thu, 16 Jul 92 12:12:59 EDT
Message-Id: <9207161612.AA19009@home.merit.edu>
To: www-talk@nxoc01.cern.ch
Cc: eastgate@applelink.apple.com
Subject: Storyspace Mac hypertext tool
Date: Thu, 16 Jul 92 12:12:59 -0400
From: Mark Alexander Davis-Craig <mad@merit.edu>

I don't know how interesting this will be to people, but I called one
of the technical people on the project, Mark Bernstein, (he's cced on
this message) and this might be close to a Mac front end for the web.
------- Forwarded Message

From: Elli Mylonas <ELLI%BROWNVM.BitNet@pucc.PRINCETON.EDU>
Subject:      Re: Coover article in NYT Bk Rvw on electronic fiction
To: Multiple recipients of list PACS-L <PACS-L%UHUPVM1.BitNet@pucc.PRINCETON.EDU>



- ----------------------------Original message----------------------------
This is a rather tardy reply to the query about StorySpace.
 
StorySpace is a hypertext authoring system that runs on the
Macintosh. The person using it creates "spaces" which
can contain text and/or other spaces. Links can also be created between
different text spans, and the links can be keyworded.
It is then possible to use the keywords to select sets of links to
follow.
StorySpace was originally conceived as a writing tool, but has since
been used as an organizer, courseware authoring system, environment
for writing fiction, etc.
It is written by J. David Bolter, Michael Joyce and John B. Smith, and
is distributed by Eastgate Systems in Cambridge Mass.
 
I have played with StorySpace a little, and have also read some of the
fiction  written in it (also from Eastgate). It is an extremely
sophisticated and versatile hypertext system, and using it is a very
worthwhile initiation into this new medium (...?!).
 
 
I should also add that, although I am not affiliated with
Eastgate or StorySpace, I think their products are good, and
I am a supporter and friend of theirs, so I am not entirely
nonpartisan.
 
To get in touch with Eastgate, call 1-800-562-1638. The fiction
is in the $30 range, and really takes the shine out of the current
books on disk.

------- End of Forwarded Message


From jfg@dxcern.cern.ch  Fri Jul 17 10:18:38 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08627; Fri, 17 Jul 92 10:18:38 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29808; Fri, 17 Jul 92 10:18:12 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA10305; Fri, 17 Jul 92 10:17:49 +0200
Date: Fri, 17 Jul 92 10:17:49 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207170817.AA10305@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Cc: eastgate@applelink.apple.com
Subject: Re: Storyspace Mac hypertext tool
References: <9207161612.AA19009@home.merit.edu>

  Interesting... Mark (one or the other :-), could you tell us how you
think this product might be hooked up to the web ? The message you
sent doesn't mention any networking possibility, but we could perhaps
combine our WWW code library with your user interface to obtain a new
great browser/editor. What does your internal hypertext format look
like ? Could we map it to HTML ? Can we get a demo version here ?

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"Life may at times be boring, but is it more fun to be dead ?"
                                                  -- Alcor


From rama@noa.huji.ac.il  Sun Jul 19 13:30:54 1992
Return-Path: <rama@noa.huji.ac.il>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12016; Sun, 19 Jul 92 13:30:54 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21624; Sun, 19 Jul 92 13:30:34 +0200
Received: by noa.huji.ac.il (HU-2.5)
	id AA02425; Sun, 19 Jul 92 14:28:59 +0300
From: Rama Porrat <rama@noa.huji.ac.il>
Date: Sun, 19 Jul 92 14:28:59 +0300
Message-Id: <9207191128.AA02425@noa.huji.ac.il>
To: www-talk@nxoc01.cern.ch

                   TeX data base for WWW

We have a database containing information about TeX and related issues.
The database is built so that it can easily be accessed via 
     WWW  --  WorldWideWeb  -- 
a public domain interactive line browser. It is meant to be used
by both new and advanced TeX users.

Files within the database have been and are being copied (and modified) 
from information lists pertaining to TeX; others have been written here.
Files are constantly being updated and added.

Apart from general information pertaining to TeX, the database includes
information pertaining to Hebrew TeX. This can, of course, be skipped
by those who are not interested in the subject.

To use the TeX data base, you can telnet onto vms.huji.ac.il  
(currently 128.139.4.3) with the username  WWW

Once you are within WWW, choose the entry 
   "Computation Center Information"  [7]
by typing   7   <return>
 
in the next menu, choose
   "TeX News and Info"   [5]
by typing   5   <return>

All the files contained in the TeX database can be retrieved via
anonymous ftp from noa.huji.ac.il [132.64.254.10]   in  tex/www
The file   top.html   is the top of the information.:

Note: Our server is still running is the old port, not port 80.

Rama.

-- 
Rama Porrat   					rama@noa.huji.ac.il
Computation Center				voice:	+972-2-584539
The Hebrew University of Jerusalem		fax:	+972-2-527349
Jerusalem 91904, ISRAEL				bitnet: rama@hujivms



From jfg@dxcern.cern.ch  Tue Jul 21 09:46:32 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15563; Tue, 21 Jul 92 09:46:32 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09315; Tue, 21 Jul 92 09:46:27 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA19273; Tue, 21 Jul 92 09:46:09 +0200
Date: Tue, 21 Jul 92 09:46:09 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9207210746.AA19273@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: questionnaire on billing server for the Internet

  Forwarded from the wais-talk mailing list, FYI only (same disclaimer
as below...)

	Jean-Francois

------- Start of forwarded message -------
From: Steve Goldstein--Ph +1-202-357-9717 <sgoldste@cise.cise.nsf.gov>
To: wais-talk@quake.think.com
Subject: questionnaire on billing server for the Internet
Date: Mon, 20 Jul 92 14:58:50 EDT

Forwarded for the interest of WAIS-folk who might be interested in the
customer charging functions.  Perhsps somebody would like to respond
to these folks with WAIS-specific interests.  

This is not an endorsement of the request in any way: it is just forwarded
for your information and, possibly, to lead to WAIS-enlightenment for the
questioners.

						Thanks,

						Steve G.

- ------- Forwarded Message

          Mon, 20 Jul 1992 13:22:51 -0400 (EDT)
Message-Id: <keOjNfS00io1M1r1Q1@andrew.cmu.edu>
Date: Mon, 20 Jul 1992 13:22:51 -0400 (EDT)
From: Tao Jen <tj0u+@andrew.cmu.edu>
To: com-priv@psi.com
Subject: Internet Billing Server



			Information Networking Institute
			Carnegie Mellon University
			5000 Forbes Avenue
			Pittsburgh, PA  15213
			Tel:  (412) 268-8128
			Fax:  (412) 268-7196
			Email address:  tj0u@andrew.cmu.edu
 
To whom this may concern:
 
We are graduate students from Carnegie Mellon University's Information
Networking Institute.  Currently we are working on a project to design
and develop a "billing server" on the Internet.  This "billing server"
will provide billing functions for various service providers who could
sell their information services electronically over the Internet.  We
believe that many of you could be potential service providers (our
customers). Therefore, your input to this market survey will be valuable
to the success of our project, and greatly appreciated.
 
The "billing server" that we envision would include billing functions
such as customized billing, invoice creation, service charge calculation
and collection, centralzied authentication, topical directory service,
and customer inquiry handling.  Basically, it is like a credit card
service for the electronic services available on the Internet.
 
Following is a market survey that we are asking you to fill out for us. 
We greatly appreciate if you could respond to this survey as soon as
possible.  If possible, please reply by email, fax, or telephone calls.  


			Sincerely yours,
 
 
 
			Tao Jen
 

 
 
Name:						                       Title:
Company:
 
 
1.  Would you be interested in making your service or information
available electronically?
 
 
2.  Would you be interested in having a third party (e.g. a "billing
server") handle the billing functions for you?
 
 
3.  Would you prefer an uniform pricing scheme for all customers or an
individual pricing scheme on a customer by customer basis?
 
 
4.  Would you like a third party (e.g. a "billing server") to calculate
the service charges for you?
 
 
5.  Circle the following services in terms of the importance in order
for you to provide services electronically.  (1 is least important, 5 is
most important)
 
		- Centralized authentication.		   	1	2	3	4	5
		- Service charge calculation.	   	1	2	3	4	5
		- Customized billing.			          	1	2	3	4	5
		- Invoices creation.			           	1	2	3	4	5
		- Guaranteed payment		            	1	2	3	4	5
		- Service charge collection.	    	1	2	3	4	5
		- Directory service.		           	1	2	3	4	5
		- Customer inquires.		           	1	2	3	4	5
 
Please add to the list any additional service you feel is important.
 
 
 
6.  Would you prefer to handle customer inquiries by yourself or let the
centralized  "billing server"  handle them?
 
 
7.  What is the highest percentage of the total sale that you are
willing to pay for the billing service?  (Please try your best to answer
this question)
 
 
Other comments:
 


- ------- End of Forwarded Message

------- End of forwarded message -------

From connolly@pixel.convex.com  Fri Jul 24 07:19:47 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23830; Fri, 24 Jul 92 07:19:47 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA18179; Fri, 24 Jul 92 07:19:25 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA16637; Fri, 24 Jul 92 00:18:36 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06296; Fri, 24 Jul 92 00:18:35 -0500
Message-Id: <9207240518.AA06296@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: html2mml.l -- FrameMaker support for HTML
Content-Type: multipart/mixed; boundary="cut-here"
Date: Fri, 24 Jul 92 00:18:34 CDT
From: Dan Connolly <connolly@pixel.convex.com>

--cut-here

Here's a lisp program I cooked up to convert HTML files
to Frame's Maker Markup Language. It uses a real SGML
parser and a lisp interpreter, so you'll have to build
those if you don't have them handy.

I haven't tested it extensively, and I don't have a
down translator (MIF to HTML) yet... but I thought
I'd pass it along.

Oh... it assumes the HTML file conforms to the DTD
I sent out a while ago (I'd give you a WWW HREF/URL,
but the server's down right now and I can't find
it.)

Dan

--cut-here

;;; html2mml.l -- translate HyperText Markup Language to Maker Markup Language.
;;;
;;; USE
;;;  sgmls file.html | xlisp html2mml.l >file.mml
;;;
;;; Where xlisp is Tom Almy's improved release of David Betz's XLISP 2.1,
;;; available in export.lcs.mit.edu:/contrib/winterp/xlisp/xlisp-2.1.almy.tar.Z
;;; and sgmls is built from
;;; ifi.uio.no:/pub/SGML/SGMLS/sgmls-0.8.tar
;;; aka
;;; ftp.uu.net:/pub/text-processing/sgml/sgmls-0.8.tar.Z
;;;
;;; The resulting file will have the OS Banner from XLisp at the
;;; top. For some reason, XLisp writes everything to stdout.
;;; I patched it to write diagnostic output to stderr. I'll have
;;; to get the patches incorporated soon.
;;;
;;; Anyway, just edit the banner out so the first line of the file is
;;; <MML ...>
;;;
;;; Then import the mml file to FrameMaker.
;;;

(setq *tracenable* t)
(setq *breakenable* t)

(princ "<MML \"from html2mml.l by connolly@convex.com\">\n")
(setq *para-tags*
      '(title h1 h2 h3 h4 h5 body ol ul dl menu dir xmp listing))
(setq *literal-tags* '(xmp listing))

(setq *style-sheet* "
<!DefinePar Title
  <Alignment r>
  <plain> <pts 18> <bold>
>
<!DefinePar H1
  <Alignment c>
  <plain><pts 18>
  <SpaceBefore 12pt><SpaceAfter 12pt>
>
<!DefinePar H2
  <LeftIndent 0in><FirstIndent 0in>
  <SpaceBefore 12pt><SpaceAfter 6pt>
  <Alignment l>
  <plain><pts 14>
>
<!DefinePar H3
  <plain> <bold>
  <LeftIndent 0.25in><FirstIndent 0.25in>
  <SpaceBefore 6pt><SpaceAfter 3pt>
  <Alignment l><pts 12>
>
<!DefinePar H4
  <Alignment l>
>
<!DefinePar H5
  <Alignment l>
>
<!DefinePar BODY
  <LeftIndent 0.75in><FirstIndent 0.75in>
  <SpaceBefore 3pt><SpaceAfter 3pt><BlockSize 3>
  <Alignment l><plain><pts 12>
>
<!DefinePar OL
  <FirstIndent 1.0in> <LeftIndent 1.5in>
  <TabStops <TabStop 1.25in>>
  <SpaceBefore 3pt><SpaceAfter 3pt><BlockSize 3>
  <AutoNumber Yes> <NumberFormat \"<n+>\t\">
  <Alignment l><plain><pts 12>
>
<!DefinePar UL
  <SpaceBefore 3pt><SpaceAfter 3pt><BlockSize 3>
  <FirstIndent 1.0in> <LeftIndent 1.5in>
  <TabStops <TabStop 1.25in>>
  <AutoNumber Yes> <NumberFormat \"o\\t\">
  <Alignment l><plain><pts 12>
>
<!DefinePar DL
  <AutoNumber No>
  <SpaceBefore 3pt><SpaceAfter 3pt><BlockSize 3>
  <FirstIndent 0.5in> <LeftIndent 2.5in>
  <TabStops <TabStop 2.5in>>
  <Alignment l><plain><pts 12>
>
<!DefinePar MENU
  <AutoNumber No>
  <WithNext yes><WithPrev yes>
  <Alignment l><plain><pts 12>
>
<!DefinePar DIR
  <AutoNumber No>
  <Alignment l><plain><pts 12>
>
<!DefinePar XMP
  <AutoNumber No>
  <FirstIndent 0in> <LeftIndent 0in>
  <Alignment l><plain>
  <Family Courier><pts 9>
  <SpaceBefore 3pt><SpaceAfter 3pt><BlockSize 3>
>
<!DefinePar LISTING
  <AutoNumber No>
  <FirstIndent 0in> <LeftIndent 0in>
  <Alignment l><plain>
  <Family Courier><pts 8>
  <SpaceBefore 3pt><SpaceAfter 3pt><BlockSize 3>
>
")

(princ *style-sheet*)

;; From almy2.1
;; push and pop treat variable v as a stack
(defmacro push (v l)
        `(setf ,l (cons ,v ,l)))

(defmacro pop (l)
        `(prog1 (first ,l) (setf ,l (rest ,l))))


(defun start-para (stream tag)
  (format stream "<~A>~%" tag)
  )

(defun end-para (stream)
  (format stream "~%~%")
  )


(defun convert-data (literal)
  (do ((c (read-char) (read-char))
       d1 d2 d3
       )
      ((eq c #\Newline) nil)
      
      (cond ((eq c #\\)
	     (cond ((setf d1 (digit-char-p (setf c (read-char))))
		    (setf d2 (digit-char-p (read-char))) 
		    (setf d3 (digit-char-p (read-char)))
		    (princ (int-char (+ d3 (* 8 (+ d2 (* 8 d1))))))
		    )
		   ((eq c #\\) (princ "\\\\"))
		   ((eq c #\n) (format t (if literal "<HardReturn>" " ")))
		   ((eq c #\|) ;;nothing
		    )
		   ((eq c #\s) (princ " "))
		   ) )
	    ((member c '(#\< #\>)) (format t "\\~A" c))
	    ((eq c #\space) (format t (if literal "<HardSpace>" " ")))
	    ((eql c 7) (format t "<tab>"))
	    (t (princ c))
	) ) )

(defun html2mml ()
  (do ((c (read-char) (read-char))
       stack
       tag
       attrs
       )
      ((null c)) ;; quit at end of file
      
      (case c
	    (#\Newline ;; do nothing
	     )
	    
	    (#\( (let ((gi (read))
		       )
		   ;; open tag
		   (push gi stack)
		   (cond ((member gi *para-tags*)
			  (setq tag gi)
			  (start-para t tag)
			  )
			 ((eq gi 'a)
			  (let ((href (second (assoc 'href attrs)))
				)
			    ;; watch out for >'s and 's
			    (format t "<Marker <MType 8> <MText `message www ~A'>><italic>" href)
			    )
			  )
			 )
		   (setq attrs nil)
		   ))
	    (#\) (let ((gi (read))
		       )
		   (pop stack)
		   (cond ((member gi *para-tags*)
			  (setq tag nil))
			 ((eq gi 'a) (format t "<noitalic>"))
			 ((eq gi 'dt) (format t "<tab>"))
			 ((member gi '(p dd li)) (format t "<par>"))
			 )
		   ))
	    
	    (#\-
	     (unless tag
		     (end-para t)
		     (dolist (gi stack)
			     (when (member gi *para-tags*)
				   (setq tag gi)
				   (return)
				   ) )
		     (start-para t tag)
		     )
	     (convert-data (member tag *literal-tags*))
	     )
	    
	    (#\& (let ((name (read))
		       )
		   ;; name
		   ))
	    
	    (#\? (let ((pi (read-line))
		       )
		   ;; processing instruction
		   ))
	    (#\A (let ((name (read))
		       (token (read))
		       )
		   (case token
			 (IMPLIED ;; nothing
			  )
			 (CDATA (let ((data (read-line))
				      )
				  (push (list name data) attrs)
				  ))
			 (TOKEN (let ((tokens (read-line)) ;;@@ read tokens til \n
				      )
				  ;; tokens
				  ))
			 (NOTATION (let ((name (read))
					 )
				     ;; notation
				     ))
			 (ENTITY (let ((name (read))
				       )
				   ;; general entity
				   ))
			 (ID (let ((id (read))
				   )
			       ;; id
			       ))
			 (IDREF (let ((ids (read-line)) ;; @@ read ids til \n
				      )
				  ;; id's
				  ))
			 ) ) )
	    
	    (#\D (read-line) ;; do like A but for external data name
	     )
	    ) )
  )

(html2mml)

--cut-here--


From joe@athena.mit.edu  Fri Jul 24 17:17:17 1992
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25134; Fri, 24 Jul 92 17:17:17 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02797; Fri, 24 Jul 92 17:17:19 +0200
Received: from CALCULUS-1.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA25953; Fri, 24 Jul 92 11:16:58 EDT
From: joe@athena.mit.edu
Received: by CALCULUS-1.MIT.EDU (5.61/4.7) id AA09483; Fri, 24 Jul 92 11:16:50 -0400
Message-Id: <9207241516.AA09483@CALCULUS-1.MIT.EDU>
To: www-talk@nxoc01.cern.ch
Subject: Connecting WWW and Tk
Date: Fri, 24 Jul 92 11:16:49 EDT

I'm working on a frontend to World Wide Web navigation system
using the Tk2.1 toolkit.

I should have an alpha version ready to test in about a week or so.


From connolly@imagine.convex.com  Fri Jul 24 17:33:12 1992
Return-Path: <connolly@imagine.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25174; Fri, 24 Jul 92 17:33:12 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04630; Fri, 24 Jul 92 17:33:05 +0200
Received: from imagine.convex.com by convex.convex.com (5.64/1.35)
	id AA02942; Fri, 24 Jul 92 10:32:17 -0500
Received: from localhost by imagine.convex.com (5.64/1.28)
	id AA26087; Fri, 24 Jul 92 10:32:15 -0500
Message-Id: <9207241532.AA26087@imagine.convex.com>
To: cni-arch@uccvma.bitnet
Cc: wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: SGML for URLs
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cut-here"
Date: Fri, 24 Jul 92 10:32:14 CDT
From: Dan Connolly <connolly@imagine.convex.com>

--cut-here
Content-Type: multipart/alternamtive; boundary=alt

--alt

                                   OBJECTIVE
                                       
   The issue of what to call these things we're defining has been discussed at
   length. First it was Universal Document Identifier. The name has changed as
   the objective has been refined. The latest name is Universal Resource
   Locator. The provisional charter is;
   
    To define a printable string syntax to the allow
    
      The expression of the address on the network of any accesable object
      using existing information retrieval protocols;
      
      The expression of the name of any object held in a directory system or
      unique naming space on the network;
      
      The distinction to be made easily in the syntax between such protocols
      and directories and name spaces;
      
      New protocols, directories and naming schemes to be included as and when
      they are developed. [1]
      
      Clearly what we are about is defining a language, i.e.  a syntax and
      semantics for communicating some information.
      
      The information is the location and/or identity of some information
      object in the global hypertext. It's a citation or a reference or a
      hypertext link anchor.
      
      I propose a specification for the language of URLs, in the context of a
      specification for a language of global hypertext references.
      
      These global hypertext references include more semantics than just
      differentiating between protocols and accessing data. There are also
      issues of determining the type and the identity of the referent data.
      
SGML as a syntactic specification tool

   That's what it's for, after all. What I propose is a DTD that (with the
   default SGML declaration) defines the language of global hypertext
   references.
   
    Some examples of the language:
    

<http host="info.cern.ch" path="hypertext/TheProject.html">
<http host="info.cern.ch" path="hypertext/people.html" anchor="timbl">
<http host="info.cern.ch" path="XFIND" search="SGML">

<prospero host="archie.mgil.ca" path="pub/ftp">

<file host="snoopy" path="~connolly/bin/cgrep.pl" type=appl subtype=x-perl>

<ftp host="export.lcs.mit.edu" dir="contrib"
name="XcRichText-1.2.tar.Z">

<usenet group="comp.infosystems.gopher">
<usenet article="<abc@convex.com>">

<wais host="quake.think.com" database="INFO" search="help">
<wais host="quake.think.com" database="INFO" wtype="TEXT" size=1000
        path="/usr/local/wais/README" >

<telnet host="info.cern.ch">

<gopher host="boombox.umn.edu" port=70>
<gopher host="boombox.umn.edu" selector="foo &#34;bar&#34;" gtype=0 >

   The DTD uses only the most basic features of SGML, and thus the resulting
   language is not very complex. Implementation of a parser for this particular
   SGML language is a vastly more simple task than implementing an SGML parser.
   At the same time, we get the benefits of a rigorously defined language based
   on established standards.
   
  Note:                  I haven't studied the HyTime standard very carefully.
                         I think it's beyond the scope of the task at hand, but
                         I'd like to have that opinion substantiated by someone
                         who really knows. In particular, its Finite Coordinate
                         Systems could be used to model positions within
                         documents: characters, lines, paragraphs.
                         
  RELAVENT ISSUES
  
  Verbosity              This syntax is somewhat verbose, but I think that
                         implicit markup (punctuation rather than names) will
                         lead to a mass of quoting in many cases. And the
                         consistency between schemes is not necessarily very
                         high.
                         
  Long URLs              Extra whitespace between tokens has no effect. There
                         is still the problem of quoted strings that are longer
                         than a mailer allows. Certainly there's some SGML
                         feature that I'm not aware of that addresses the
                         issue.
                         
  I don't believe there's a way to restrict the length of an element, though
                         there is a 960 character limit on the length of an
                         attribute value (in the default SGML declaration).
                         
  Quoting                The SGML numeric character reference (e.g. &#128;)
                         allows an attribute value literal to represent any
                         sequence of bytes.
                         
  NAMELEN                The default SGML declaration specifies that names of
                         elements and attributes be 8 characters or less. It's
                         a conceptually simple matter to operate under an SGML
                         declaration where NAMELEN is higher.
                         
  Extensibility          One problem with the current UDI syntax specification
                         is that it seems to allow new schemes to add arbitrary
                         complexity to the grammar. This specification limits
                         the language to an SMGL start tag.
                         
  If we adopt this spec, we need to give it a public text identifier, and
                         maintain a registry of the names used (probably with
                         the IANA).
                         
  DEPLOYMENT AND USAGE
  
   The first place to try this specification out is in the WWW browser. (I'll
   try to make the code changes if I find time). It's a simple matter of
   elevating UDI's as SGML attributes to URLs as SGML elements. I'd like to
   have someone who really knows SGML to have a look at this DTD and see if it
   can be improved. And I'd like to study the HyTime standard, the Davenport
   DASH, the CFCM standard, etc. to see how this element meshes with their
   citation strategies. Also, it would be nice to have explicit support from
   WAIS and Gopher clients -- drag and drop comes to mind.
   
SGML and semantics

   SGML is famous for being divorced from application semantics. Most of the
   semantics of URLs is in the constituent protocols. All we need to do is
   define a way to parse a URL and pass the various bits to the protocol. But
   as long as we're going to all the trouble to gather information accessible
   with all these protocols into one specification, it makes sense to define
   some semantics common to most applications that will use URLs.
   
  DATA TYPES
  
   Some of the schemes have explicit type information (wais, gopher), some have
   implicit typing (html, USENET), and some have no typing at all (file, ftp).
   The MIME content-type system is general and useful enough to warrant
   support. An application should be able to determine the content-type of the
   data regardless of the protocol.
   
  RESOURCE IDENTITY
  
   Many applications have use for determining whether two URLs refer to the
   same information. Various schemes (such as USENET article id's) may have
   semantics for identifying resources. But I think this capability is so
   widely useful that it should be coherently supported for all protocols.
   
                                                            connolly@convex.com
--alt
Content-Type: text/x-html

<!DOCTYPE html SYSTEM>
<title>Using SGML to define Universal Resource Locators</title>

<H1>Objective</H1>

The issue of what to call these things we're defining has been
discussed at length. First it was Universal Document Identifier. The
name has changed as the objective has been refined. The latest name is
Universal Resource Locator. The provisional charter is;

<a HREF="x-message-id:<9206262004.AA29919@zippy.lcs.mit.edu>">
<h4>To define a printable string syntax to the allow</h4>

<ol>
<li>The expression of the address on the network of any accesable
object using existing information retrieval protocols;

<li>The expression of the name of any object held in a directory
system or unique naming space on the network;

<li>The distinction to be made easily in the syntax between such
protocols and directories and name spaces;

<li>New protocols, directories and naming schemes to be included as
and when they are developed.
</ol>
</a>

<p>
Clearly what we are about is defining a language, i.e.  a syntax and
semantics for communicating some information.
<p>

The information is the location and/or identity of some information
object in the global hypertext. It's a citation or a reference or a
hypertext link anchor.
<p>

I propose a specification for the language of URLs, in the context of
a specification for a language of global hypertext references.
<p>

These global hypertext references include more semantics than just
differentiating between protocols and accessing data. There are also
issues of determining the type and the identity of the referent data.

<H2>SGML as a syntactic specification tool</H2>

That's what it's for, after all. What I propose is a DTD that
(with the default SGML declaration) defines the language of
global hypertext references.
<p>

<h4>Some examples of the language:</h4>
<XMP>
<http host="info.cern.ch" path="hypertext/TheProject.html">
<http host="info.cern.ch" path="hypertext/people.html" anchor="timbl">
<http host="info.cern.ch" path="XFIND" search="SGML">

<prospero host="archie.mgil.ca" path="pub/ftp">

<file host="snoopy" path="~connolly/bin/cgrep.pl" type=appl subtype=x-perl>

<ftp host="export.lcs.mit.edu" dir="contrib"
name="XcRichText-1.2.tar.Z">

<usenet group="comp.infosystems.gopher">
<usenet article="<abc@convex.com>">

<wais host="quake.think.com" database="INFO" search="help">
<wais host="quake.think.com" database="INFO" wtype="TEXT" size=1000
	path="/usr/local/wais/README" >

<telnet host="info.cern.ch">

<gopher host="boombox.umn.edu" port=70>
<gopher host="boombox.umn.edu" selector="foo &#34;bar&#34;" gtype=0 >
</XMP>

The DTD uses only the most basic features of SGML, and thus
the resulting language is not very complex. Implementation
of a parser for this particular SGML language is a vastly
more simple task than implementing an SGML parser.

At the same time, we get the benefits of a rigorously
defined language based on established standards.

<dl><dt>Note:
<dd>I haven't studied the HyTime standard very
carefully. I think it's beyond the scope of the task at
hand, but I'd like to have that opinion substantiated by someone
who really knows. In particular, its Finite Coordinate Systems
could be used to model positions within documents: characters,
lines, paragraphs.
</dl><p>

<h3>Relavent Issues</h3>

<dl>
<dt>Verbosity <dd>This syntax is somewhat verbose, but I think that
implicit markup (punctuation rather than names) will lead to a mass of
quoting in many cases. And the consistency between schemes is not
necessarily very high.

<dt>Long URLs
<dd>Extra whitespace between tokens has no effect. There is still
the problem of quoted strings that are longer than a mailer allows.
Certainly there's some SGML feature that I'm not aware of that
addresses the issue.
<p>
I don't believe there's a way to restrict the length of an element,
though there is a 960 character limit on the length of an attribute
value (in the default SGML declaration).

<dt>Quoting
<dd>The SGML numeric character reference (e.g. &#128;) allows
an attribute value literal to represent any sequence of bytes.

<dt>NAMELEN
<dd>The default SGML declaration specifies that names of
elements and attributes be 8 characters or less. It's a
conceptually simple matter to operate under an SGML declaration
where NAMELEN is higher.

<dt>Extensibility
<dd>One problem with the current UDI syntax specification is that it
seems to allow new schemes to add arbitrary complexity to the grammar.
This specification limits the language to an SMGL start tag.
<p>
If we adopt this spec, we need to give it a public text identifier,
and maintain a registry of the names used (probably with the IANA).
</dl>

<h3>Deployment and Usage</h3>

The first place to try this specification out is in the
WWW browser. (I'll try to make the code changes if I find
time). It's a simple matter of elevating UDI's as SGML
attributes to URLs as SGML elements.

I'd like to have someone who really knows SGML to have a look
at this DTD and see if it can be improved. And I'd like
to study the HyTime standard, the Davenport DASH, the CFCM
standard, etc. to see how this element meshes with their
citation strategies.

Also, it would be nice to have explicit support from WAIS and Gopher
clients -- drag and drop comes to mind.

<h2>SGML and semantics</h2>

SGML is famous for being divorced from application semantics.
Most of the semantics of URLs is in the constituent protocols.
All we need to do is define a way to parse a URL and pass
the various bits to the protocol.

But as long as we're going to all the trouble to gather information
accessible with all these protocols into one specification, it makes
sense to define some semantics common to most applications that will
use URLs.

<h3>Data Types</h3>

Some of the schemes have explicit type information (wais, gopher),
some have implicit typing (html, USENET), and some have no typing at
all (file, ftp). The MIME content-type system is general and useful
enough to warrant support. An application should be able to determine
the content-type of the data regardless of the protocol.

<h3>Resource Identity</h3>

Many applications have use for determining whether two URLs refer
to the same information. Various schemes (such as USENET article
id's) may have semantics for identifying resources. But I think this
capability is so widely useful that it should be coherently supported
for all protocols.

<address>connolly@convex.com</>
</HTML>

--alt--
--cut-here

<!-- Universal Resource Locator specification
     derived from http://info.cern.ch/hypertext/WWW/Addressing/BNF.html
     on 24 July 1992
     by connolly@convex.com -->

<!-- Typical usage:
	<!DOCTYPE url SYSTEM>
		(we need a public identifier)
	or as part of another SGML document type:
	<!ELEMENT url SYSTEM>
	&url;
	-->

<!-- minimization? I believe you can omit the name= part
	of an SGML attribute specification in some circumstances.
	I don't think it works with CDATA attributes because
	order is not significant. -->

<!-- news: scheme renames USENET -->
<!-- file: is somewhat vague. I suggest explicit support for FTP: -->
<!ENTITY % schemes "http|file|ftp|usenet|telnet|prospero|gopher|wais">

<!ELEMENT url - - (%schemes;)* >
<!-- content model of URL: more than one element in a URL? (obviously
	an application can use multiple URLs. The question is whether
	to define semantics for multiple elements in a single URL.)

	Also, what about type, size, search information? Perhaps
	one element should describe the connection information,
	another element or elements describes the path to the data
	(allowing us to define semantics of hierarchical databases)
	and another element defines the type of information there.

	-->

<!ELEMENT (%schemes;) - O EMPTY >

<!-- TCP connection info: internet domain address and port number -->
<!ENTITY % host "host CDATA #REQUIRED" >
<!ENTITY % hostp "%host; port NUMBER #IMPLIED" >

<!ENTITY % types "text|image|audio|video|message|multi|appl">
<!ENTITY % stypes "plain|richtext|
	gif|g3fax|
	basic|
	mpeg|
	rfc822|external|partial|
	mixed|altern|parallel|
	octets|ps|oda">
<!-- content-type parameters? -->

<!ENTITY % cte "7bit|8bit|qp|base64|binary"
	-- we could define several of the gopher types
	   in terms of encodings and types
		e.g. x-binhex, application/x-stuffit
	-->

<!ENTITY % MD5 "datasig CDATA #IMPLIED" -- MD5 data signature -->
<!ENTITY % bytes "bytes NUMBER #IMPLIED">
<!ENTITY % lines "lines NUMBER #IMPLIED">

<!ATTLIST http
	-- information accessing attributes --
	%hostp;
	path CDATA #REQUIRED -- server local name --
		-- must match xalpha [/ path ] --
		-- can a CDATA attribute contain an arbitrary bytestream? --
	search CDATA #IMPLIED -- search terms --
	anchor CDATA #IMPLIED -- HTML anchor name --

	-- information content attributes --
	type (%types) text
	subtype (%stypes) #IMPLIED
	encoding (%cte) 7bit
	%MD5;
	%bytes;
	>

<!ATTLIST prospero
	%hostp;
	path CDATA #REQUIRED
	-- prospero path should not be constrained to WWW path syntax --


	-- information content attributes --
	type (%types) appl
	subtype (%stypes) octets
	encoding (%cte) binary
	%MD5;
	%bytes;
	>

<!ATTLIST file
	%host;
	path CDATA #REQUIRED
	-- unix path should not be constrained to WWW path syntax --

	-- information content attributes --
	type (%types) appl
	subtype (%stypes) octets
	encoding (%cte) binary
	%MD5;
	%bytes;
	>

<!ATTLIST ftp
	%hostp;
	dir CDATA #REQUIRED -- directory for cd command --
	name CDATA #REQUIRED -- name for get command --
	user CDATA "anonymous" -- anonymous ftp by default --
	password CDATA #IMPLIED -- not always needed --

	-- information content attributes --
	type (%types) appl
	subtype (%stypes) octets
	encoding (%cte) binary -- use 7bit for ascii transfers --
	%MD5;
	%bytes;
	>

<!ATTLIST usenet
	group CDATA #IMPLIED -- usenet newsgroup name --
	article CDATA #IMPLIED -- article message-id --

	-- information content attributes --
	type (%types) message
	subtype (%stypes) rfc822
	encoding (%cte) 7bit
	%MD5;
	%lines; -- you can add headers without changing a USENET
			article, so bytes isn't a good measure --
	>

<!-- should we split this into two nodes so that
	we can put #REQUIRED on the size and type for documents? -->
<!ATTLIST wais
	%hostp;
	database CDATA #IMPLIED -- WAIS database name --
	search CDATA #IMPLIED -- search terms --
		-- what about relavent documents? --
	wtype CDATA #IMPLIED -- WAIS data type --
		-- this should be obsoleted by the MIME type system --
	bytes NUMBER #IMPLIED
	path CDATA #IMPLIED -- split into original x, y? --

	-- information content attributes --
	type (%types) text
	subtype (%stypes) plain
	encoding (%cte) binary
	%MD5;
	>

<!ATTLIST telnet
	%hostp;
	user CDATA #IMPLIED -- username --
	>

<!ATTLIST gopher
	%hostp;
	gtype CDATA "1" -- gopher type --
		-- again, MIME types should be used --
		-- www browser can be inundated by non-text data
		   unless it recognizes other types --
	selector CDATA "" -- gopher object selector --
	search CDATA #IMPLIED -- fulltext search terms --

	-- information content attributes --
	type (%types) #IMPLIED
	subtype (%stypes) #IMPLIED
	encoding (%cte) binary
	%MD5;
	%bytes;
	>
--cut-here
Content-type: text/sgml
Content-Description: Example URLs

<!DOCTYPE url SYSTEM>
<url>
<http host="info.cern.ch" path="hypertext/TheProject.html">
<http host="info.cern.ch" path="hypertext/people.html" anchor="timbl">
<http host="info.cern.ch" path="XFIND" search="SGML">

<prospero host="archie.mgil.ca" path="pub/ftp">

<file host="snoopy" path="~connolly/bin/cgrep.pl" type=appl subtype=x-perl>

<ftp host="export.lcs.mit.edu" dir="contrib"
name="XcRichText-1.2.tar.Z">

<usenet group="comp.infosystems.gopher">
<usenet article="<abc@convex.com>">

<wais host="quake.think.com" database="INFO" search="help">
<wais host="quake.think.com" database="INFO" wtype="TEXT" size=1000
	path="/usr/local/wais/README" >

<telnet host="info.cern.ch">

<gopher host="boombox.umn.edu" port=70>
<gopher host="boombox.umn.edu" selector="foo &#34;bar&#34;" gtype=0 >
</url>

--cut-here--

From joe@athena.mit.edu  Sat Jul 25 14:15:38 1992
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26927; Sat, 25 Jul 92 14:15:38 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA20507; Sat, 25 Jul 92 14:15:41 +0200
Received: from CALCULUS-1.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA01267; Sat, 25 Jul 92 08:15:07 EDT
Received: by CALCULUS-1.MIT.EDU (5.61/4.7) id AA17334; Sat, 25 Jul 92 08:15:04 -0400
Message-Id: <9207251215.AA17334@CALCULUS-1.MIT.EDU>
To: cdsdev@athena.mit.edu, www-talk@nxoc01.cern.ch
Subject: tk interface to World Wide Web
Date: Sat, 25 Jul 92 08:15:02 EDT
From: Joseph Wang <joe@athena.mit.edu>


It looks like that I will have an alpha-test version of the tk
interface to WWW done by the end of next week.

Is there anyone out there who can donate some disk space to put it on
anonymous ftp?



From jfg@granit.dtb.dk.dtb.dk  Sat Jul 25 17:56:17 1992
Return-Path: <jfg@granit.dtb.dk.dtb.dk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27211; Sat, 25 Jul 92 17:56:17 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00407; Sat, 25 Jul 92 17:56:21 +0200
Received: by  granit.dtb.dk.dtb.dk  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01746; Sat, 25 Jul 92 17:54:10 MET DST
Date: Sat, 25 Jul 92 17:54:10 MET DST
From: jfg@granit.dtb.dk.dtb.dk (Jean-Francois Groff)
Message-Id: <9207251554.AA01746@ granit.dtb.dk.dtb.dk >
To: Joseph Wang <joe@athena.mit.edu>
Cc: www-talk@nxoc01.cern.ch, cdsdev@athena.mit.edu
Subject: Re: tk interface to World Wide Web
References: <9207251215.AA17334@CALCULUS-1.MIT.EDU>

  This interface will be most welcome. We had looked at Tcl/Tk to
create an X browser, but spent our time on other things as usual :-)
Do you use the hman object that appeared a few months ago (or was it
htext?)

  Please send it to us, and we'll put it up for ftp. I'll try to find
someone at Cern to test it, as I don't have Tcl here. Just drop it
into /pub/incoming at info.cern.ch...

  Thanks again !

--
  Jean-Francois Groff (jfg@info.cern.ch)
  World-Wide Web initiative
  CERN, ECP division, CH-1211 Geneva 23, Switzerland
  Phone +41 22 767 3755 -- Fax +41 22 767 7155
--
"Life may at times be boring, but is it more fun to be dead ?"
                                                  -- Alcor


From joe@athena.mit.edu  Sat Jul 25 18:02:55 1992
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27219; Sat, 25 Jul 92 18:02:55 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00498; Sat, 25 Jul 92 18:02:59 +0200
Received: from CALCULUS-1.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA03552; Sat, 25 Jul 92 12:02:26 EDT
Received: by CALCULUS-1.MIT.EDU (5.61/4.7) id AA21446; Sat, 25 Jul 92 12:02:22 -0400
Message-Id: <9207251602.AA21446@CALCULUS-1.MIT.EDU>
To: www-talk@nxoc01.cern.ch, tcl-archive@barkley.berkeley.edu
Cc: cdsdev@athena.mit.edu
Subject: tkWWW-0.1
Date: Sat, 25 Jul 92 12:02:21 EDT
From: Joseph Wang <joe@athena.mit.edu>


I've uploaded a very preliminary interface to World Wide Web using the
tk toolkit to export.lcs.mit.edu and the tcl archive in
barkley.berkeley.edu.

tkWWW Version 0.1 alpha (joe@athena.mit.edu)
--------------------------------------------

This a first pass at a browser for World Wide Web using the tk
library.  It is very buggy.  Use at your own risk.

The Tk browser has the following advantages.

1. Since the entire user interface is written in an interpreted 
   language, it should be very easy to make modifications and extensions
   to the system.

2. More important, it is possible to imbed Tk code into hypertext
   documents.  To see an example of this, load in the hypertext file
   file:$pwd/Tcl/text2.html


INSTALLATION
------------
In order to install tkWWW you will need

   The code for the WWW line-mode browser. (anon ftp from info.cern.ch)
   Libraries for tk and tcl (I'm using tk2.1 and tcl6.3)

   A wish intepreter which contains the Hyper and XYGraph widgets

To install this program, unpack the WWW line-mode browser source and 
cd to the directory WWW.  Unpack this tar file. 




From arl@cs.hut.fi  Sun Jul 26 00:31:43 1992
Return-Path: <arl@cs.hut.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27729; Sun, 26 Jul 92 00:31:43 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA18423; Sun, 26 Jul 92 00:31:48 +0200
Received: by cardhu.cs.hut.fi id AA11360
  (5.65c8/HUTCS-C 1.3 for www-talk@nxoc01.cern.ch); Sun, 26 Jul 1992 01:31:28 +0300
Date: Sun, 26 Jul 1992 01:31:28 +0300
Message-Id: <199207252231.AA11360@cardhu.cs.hut.fi>
From: Ari Lemmke <arl@cs.hut.fi>
Sender: arl@cs.hut.fi
To: www-talk@nxoc01.cern.ch
Subject: Erwise 0.1
Reply-To: <arl@cs.hut.fi>
Organization: Helsinki University of Technology, Finland.


	Tired for waiting my programming group to finish their
	work ;-) I released Erwise beta 0.1 sources ..

	Hmm. What's Erwise? WWW X client for Motif.
	[who needs Motif anyway .. ;-]

	FTP at nic.funet.fi:/pub/unix/hypertext/world-wide-web/src
		erwise-0.1.tar.Z

	Enjoy!

	arl		// A desperate student programming work tutor


From evas@cs.few.eur.nl  Wed Aug  5 16:51:42 1992
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23605; Wed, 5 Aug 92 16:51:42 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14996; Wed, 5 Aug 92 16:52:00 +0200
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA21544; Wed, 5 Aug 92 16:51:27 +0200
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA20447; Wed, 5 Aug 92 16:51:21 +0200
Date: Wed, 5 Aug 92 16:51:21 +0200
Message-Id: <9208051451.AA20447@slc01.cs.few.eur.nl>
To: www-talk@nxoc01.cern.ch
Subject: Converting preformatted documents to HTML


In our HTML files, I frequently want to refer the reader to man-pages
or the GNU documentation. So, I wrote two small scripts to convert
man-pages and GNU Info files to HTML and added a bit of code to
the HTTPD daemon to call these filters if it found a .man or a .info
file. With this, one can write f.e. 
	"<A HREF=http://kaa.cs.few.eur.nl/info/gcc/gcc.info>GCC</A>"
to refer to the (extensive) documentation for the GNU C compiler.
So far, so good.

The Info files are the GNU equivalent of man pages and they
are complete formatted documents that contain references. 
The problem I've run into is that HTML does not offer a mode in 
which all formatting is preserved *and* tags are recognised.
The LISTING mode does preserve the formatting but does not see the 
hypertext references; the NORMAL mode does recognise the references 
but destroys the formatting (indentation, line breaks). 
Switching from LISTING to NORMAL mode (and back) in the middle of 
a paragraph is not feasible either because that will cause a blank line 
to be inserted at that point.

It would be handy to have a mode that does preserve formatting and
recognizes SGML tags since there are no doubt other hypertext formats
that could be converted to HTML this way.

Thoughts anyone ?

Eelco van Asperen.           || Erasmus University Rotterdam
internet: evas@cs.few.eur.nl || Department of Computer Science, room H4-32
New, Improved, a disclaimer: || PObox 1738, 3000 DR Rotterdam, The Netherlands
*** publishing private email is not allowed by the author of this message. ***


From timbl  Wed Aug  5 18:59:38 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23998; Wed, 5 Aug 92 18:59:38 MET DST
Date: Wed, 5 Aug 92 18:59:38 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9208051659.AA23998@ nxoc01.cern.ch >
To: evas@cs.few.eur.nl, www-talk@nxoc01.cern.ch
Subject: Re: Converting preformatted documents to HTML
Cc: defert@cernvax.cern.ch

Eelco,

I agree that it would be useful to have a mono-spaced litteral
text format which would still accept tags other than the closing
tag.  Because tags, especially if
automatically generated, can easily produce very long lines
unless they are broken up, it might be useful for
thiat format to have explicit new lines. (The paragraph
mark <P> could be used, with hte convention that it
represents only a new line).  Like you, I have come
across the need for it mainly in converted information.

It would be very easy to put in the browsers.

By the way, have you seen the Gnu Info convertion
which Philippe Defert does, on http://asis01.cern.ch:80/info/ ?
He uses a perl script. Would you both like to publish
your scripts?  They would be useful examples for anyone
writing converters, and people might wantto set up their
own Gnu Info servers too.

Tim BL

From joe@athena.mit.edu  Wed Aug  5 19:19:54 1992
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24094; Wed, 5 Aug 92 19:19:54 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24222; Wed, 5 Aug 92 19:20:18 +0200
Received: from MAJOR.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA12712; Wed, 5 Aug 92 13:19:55 EDT
Received: by major (5.57/4.7) id AA23552; Wed, 5 Aug 92 13:19:53 -0400
Message-Id: <9208051719.AA23552@major>
To: www-talk@nxoc01.cern.ch (Tim Berners-Lee)
Subject: Re: Converting preformatted documents to HTML 
In-Reply-To: Your message of Wed, 05 Aug 92 18:59:38 +0700.
             <9208051659.AA23998@ nxoc01.cern.ch > 
Date: Wed, 05 Aug 92 13:19:51 EDT
From: Joseph Wang <joe@athena.mit.edu>


On a related topic, has anyone written a script that would convert
Usenet FAQ files (such as the one for comp.lang.c) into linked 
HTML files.  It seems that all this script would have to do is to
scan for a regexp that signifies begin question, chop it up into
little HTML files, and then create a HTML index with links to the
little files.



From timbl  Thu Aug  6 23:23:36 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27633; Thu, 6 Aug 92 23:23:36 MET DST
Date: Thu, 6 Aug 92 23:23:36 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9208062123.AA27633@ nxoc01.cern.ch >
To: www-talk@nxoc01.cern.ch
Subject: perl server script for Gnu info W3 server


Phillippe Defert has kindly provided  copy of his perl
script. The script is online as 
http://info.cern.ch/hypertext/WWW/Daemon/Implementation/asis.txt
and the results are visible as http://asis01.cern.ch:80/info/

Tim Berners-Lee

(Oh for a hypertext mail reader!)

From connolly@pixel.convex.com  Fri Aug  7 07:58:01 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28095; Fri, 7 Aug 92 07:58:01 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26524; Fri, 7 Aug 92 07:58:26 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12409; Fri, 7 Aug 92 00:57:25 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA10806; Fri, 7 Aug 92 00:57:16 -0500
Message-Id: <9208070557.AA10806@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: more on FrameMaker support
Date: Fri, 07 Aug 92 00:57:16 CDT
From: Dan Connolly <connolly@pixel.convex.com>

I've just cooked up a MIF->HTML filter (for frame docs created from
HTML files in the first place). It's written in XLISP, which is a
widely available lisp interpreter with OOP extensions (the thing builds
on PCs, Macs, and Unix boxes).

This completes the circle:
	# HTML to MML
	sgmls foo.html | xlisp html2mml.l >foo.mml
	# now you can load foo.mml into frame
	# Then you can save it as mif. Or, you
	# can just do
	mmltomif <foo.mml >foo.mif
	# Then you can convert it back to html:
	xlisp mif2html.l <foo.mif >foo.html

Note that this does not address the issue of converting "legacy
documents" currently in Frame to HTML. The Frame documents
have to use the right paragraph tags so that I can recognize
the SGML structure of the file.

But it has some interesting possibilities:

* Frame can be configured to convert files based on
their extension. So you can edit some frame config
file so that when you open foo.html, it invokes
the html2mml and mmltomif filters, and voila! you
can load WWW files into FrameMaker.

I think you can do the same thing for saving. So
you could use FrameMaker much like the NeXT browser.

* Frame has hypertext which is extensible through
RPC calls. I translated the HTML sequence
	<A HREF="scheme:addr">text</a>
to
	<italic>
	<Marker <MType 8> <MText "message www scheme:addr">>
	text
	<noitalic>
in MML. Marker type 8 is hypertext. So when you click on
"text", the MText is invoked. "message www" means make
an RPC call to www with "scheme:addr" as the argument.

So we could write a www RPC client that fetches WWW nodes
and hands them to Frame.

I'm not going to distribute the code right now,
because 1) it's not very polished, and 2) the www-talk
audience didn't respond to my html->mml filter with
much enthusiasm (I assume that's because it required
you to build XLISP (easy) and SGMLs (bigger, but still
easy)).

There are a few things that I didn't bother to code yet:

* mapping Frame's funkey apostrophies and quotes
to plain ASCII. (in general, we want to convert
Frame's funky "Diacritic Encoding" to whatever character
set HTML uses (ISO latin-1?))

* mapping <A NAME="2"> to <MText "newlink 2"> and back.

* mapping <A HREF="#2"> to <MText "gotolink 2"> and back.

* mapping <A HREF="file:foo#bar"> to <MText "gotolink foo:bar"> and back.

Good night.

Dan

p.s. I discovered that the DTD in the WWW browser code
considers <LI>, <DT>, and <DD> to be empty elements.
I changed my copy of html.dtd accordingly. The one
in the web will need to be changed.

This causes the UL, OL, DL, etc. items to have mixed
content, which gives newlines all sorts of tricky
twists.

Mixed content is something to be avoided in SGML DTD's,
for reasons that are far too ugly to explain right now.

From evas@cs.few.eur.nl  Fri Aug  7 15:30:40 1992
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29092; Fri, 7 Aug 92 15:30:40 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21386; Fri, 7 Aug 92 15:30:54 +0200
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA21300; Fri, 7 Aug 92 15:30:27 +0200
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA23666; Fri, 7 Aug 92 15:30:22 +0200
Date: Fri, 7 Aug 92 15:30:22 +0200
Message-Id: <9208071330.AA23666@slc01.cs.few.eur.nl>
To: www-talk@nxoc01.cern.ch
Subject: Re: Converting preformatted documents to HTML


> I agree that it would be useful to have a mono-spaced litteral
> text format which would still accept tags other than the closing
> tag.  Because tags, especially if
> automatically generated, can easily produce very long lines
> unless they are broken up, it might be useful for
> thiat format to have explicit new lines. (The paragraph
> mark <P> could be used, with hte convention that it
> represents only a new line).  Like you, I have come
> across the need for it mainly in converted information.
> 
> It would be very easy to put in the browsers.

ok, I'll look into that; any thoughts on a name for this format ?
"PREFORMATTED" ?

> By the way, have you seen the Gnu Info convertion
> which Philippe Defert does, on http://asis01.cern.ch:80/info/ ?
> He uses a perl script. Would you both like to publish
> your scripts?  They would be useful examples for anyone
> writing converters, and people might wantto set up their
> own Gnu Info servers too.

Yes, I've seen this script. My own script is also in perl but
performs a more complete conversion. For example, each Info
'node' has previous/next references and embedded in the text
can be references to other documents. Also, my script is explicitly
designed to perform the conversion for a single topic when the user
wants to read this topic. This means that there's no need to store
the converted document and that the data is always up to date.
The disadvantage of this approach is that the scripts has to been
every time a request is made.

The scripts and the modifications I made to the HTTP daemon are
now available via anonymous ftp from ftp.cs.few.eur.nl in the
/pub/www directory, files Daemon4.0.patch, info2html and man2html.
Or try http://kaa.cs.few.eur.nl/hypertext/filters/filters.html.

I'm on holiday next week so problems/flames/praise will have to
wait until I'm back.

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands



From erict@minnie.cs.su.oz.au  Tue Aug 11 04:45:41 1992
Return-Path: <erict@minnie.cs.su.oz.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07882; Tue, 11 Aug 92 04:45:41 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15453; Tue, 11 Aug 92 04:46:14 +0200
Received: from joyce.cs.su.OZ.AU by mcsun.EU.net with SMTP
	id AA14606 (5.65b/CWI-2.173); Tue, 11 Aug 1992 04:45:48 +0200
Message-Id: <9208110245.AA14606@mcsun.EU.net>
Date: Tue, 11 Aug 1992 12:45:12 +1000
From: erict@minnie.cs.su.oz.au (Eric Yin Wang Tse)
Subject: How do I join this mailing list?
To: www-talk@nxoc01.cern.ch


From timbl  Thu Aug 13 01:24:34 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14370; Thu, 13 Aug 92 01:24:34 GMT+0100
Date: Thu, 13 Aug 92 01:24:34 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9208130024.AA14370@ nxoc01.cern.ch >
To: boutell@isis.cshl.org
Subject: Pointers to Voice magazine on the web
Cc: www-talk@nxoc01.cern.ch

Tom,

There is no problem making your magazine reachable through CERN-
sourced lists. I would suggest an entry in the W3 servers list but
also more importantly an entry in the Sunject index.  It is great that
you are doing this.  I'll also send something around on the www-announce
list when you are happy with general access. (Sorry, Subject not Sunject
of course).

I would suggest a pre-release to get some feedback from W3 readers
on the format -- you could send a message to www-talk asking for
comments (a small list of people -- www-announce is much longer).
That would be the moment you have a rough version ready.

I'm looking forward to reading it!

    Tim Berners-Lee

______________________________________
	From boutell@isis.cshl.org Wed Aug 12 23:47:10 1992
	Return-Path: <boutell@isis.cshl.org>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA14136; Thu, 13 Aug 92 00:47:04 MET DST
	Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
		id AA21982; Wed, 12 Aug 92 23:47:46 +0200
	Received: from isis.cshl.org by cshl.org (4.1/2.1-Cold Spring Harbor Laboratory)
		id AA12588; Wed, 12 Aug 92 17:46:18 EDT
	Received: from athena.cshl.org by isis.cshl.org (4.1/SMI-4.1)
		id AA08223; Wed, 12 Aug 92 17:42:35 EDT
	Date: Wed, 12 Aug 92 17:42:35 EDT
	From: boutell@isis.cshl.org (Tom Boutell)
	Message-Id: <9208122142.AA08223@isis.cshl.org>
	To: www-request@nxoc01.cern.ch
	Subject: Making my Magazine Available...


	I will shortly be releasing the first issue of a new electronic
	magazine, which will be dedicated to a given topic of general
	interest in each issue. (The first issue deals with abortion,
	from multiple standpoints; I'll be printing pro - life, pro - choice
	and intermediate articles.) I'd like to make the magazine available
	over WWW.

	I'm a programmer by trade and have already hacked my base html a bit,
	so I think I can probably manage to get the hang of doing this.
	What I'd like to ask is how to get the magazine listed somewhere
	where it will be seen - on the CERN entry point page, for
	instance (or somewhere relatively close at least). Am I the
	only one requesting this sort of thing? Probably not, so I'm not
	expecting the world. But making it available in a reasonably prominent
	fashion would help the magazine (which is strictly free of course)
	get started, and in return I would explain how to get started
	with WWW in the other electronic and nonelectronic editions of
	the magazine.

	Let me know! I hope to release the first issue in early September.
	It'll be made available over the net by multiple means to increase
	readership, but WWW is actually probably the most elegant possible.
	It'll eventually make for a truly beautiful way of disseminating
	back issues, for instance.

	(The topic of the second issue is likely to be the limitations
	of free speech, obviously a hot issue for those pressing the
	limits of network technology!)

	Thanks for your help.

	-Tom Boutell, Editor, Voice (name of magazine likely to change
	before publication as it conflicts with a few others here
	stateside)


From emv@nigel.msen.com  Fri Aug 14 20:16:33 1992
Return-Path: <emv@nigel.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19640; Fri, 14 Aug 92 20:16:33 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11450; Fri, 14 Aug 92 19:17:15 +0200
Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mJ5GP-0009p0C@nigel.msen.com>; Fri, 14 Aug 92 13:16 WET DST
Message-Id: <m0mJ5GP-0009p0C@nigel.msen.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: boutell@isis.cshl.org, www-talk@nxoc01.cern.ch
Subject: Re: Pointers to Voice magazine on the web 
In-Reply-To: Your message of Thu, 13 Aug 92 01:24:34.
             <9208130024.AA14370@ nxoc01.cern.ch > 
Date: Fri, 14 Aug 92 13:16:17 EDT
From: Edward Vielmetti <emv@msen.com>

Tom, Tim, et al,

With regard to publishing magazines on the net, I would recommend sending
a notice of either each issue or at least the first issue to "alt.zines"
and/or "rec.mag".  There are a number of folks in each group who are 
tracking small publications and who would be happy to write reviews,
keep contact information, and otherwise generally get the word out to
a wider audience.

I would refer everyone interested also to
	file://ftp.msen.com/pub/newsletters/F5-E/
which is "Factsheet Five - Electronic", a 'zine that covers the very small
press and other non-commercial publishing.

thanks,

--Ed

From emv@nigel.msen.com  Fri Aug 14 20:45:22 1992
Return-Path: <emv@nigel.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19741; Fri, 14 Aug 92 20:45:22 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13084; Fri, 14 Aug 92 19:46:07 +0200
Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mJ5iY-0009pAC@nigel.msen.com>; Fri, 14 Aug 92 13:45 WET DST
Message-Id: <m0mJ5iY-0009pAC@nigel.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: preprint services
Date: Fri, 14 Aug 92 13:45:26 EDT
From: Edward Vielmetti <emv@msen.com>

Here's a set of materials that would be useful to go into the web, if
it isn't there already.  If there are clients out there that support
"reply to owner of node" that would be a way to support a direct
interface to email based services -- if I recall right the EIES system
has some of that in it.

--Ed


  Date: Fri, 14 Aug 92 09:15:42 EDT
  From: Roy Richter PH/32  <rrichter@ph.gmr.com>
  To: emv@msen.com
  Subject: preprint servers
  
  I guess sometimes things don't work right.  Oh well.
  
  Here a list following up on our discussion last night at SEMiSLUG.
  --
  Roy Richter                  Internet: rrichter@ph.gmr.com
  Physics Dept, GM Research    UUCP:     rphroy!rrichter
          and Environmental
  
  
  Some things I've found on preprint servers, following up on our
  SEMiSLUG discussion last night...
  
  --
  
  Article: 26257 of sci.physics
  Path: rphroy!zaphod.mps.ohio-state.edu!mips!mips!munnari.oz.au!uunet!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uimrl7.mrl.uiuc.edu!ercolessi
  From: ercolessi@uimrl7.mrl.uiuc.edu (furio ercolessi)
  Newsgroups: uiuc.announce,sci.physics,sci.astro,sci.math
  Subject: ANNOUNCE: Automated preprint distribution facility
  Keywords: preprint condensed matter physics astrophysics functional analysis
  Message-ID: <1992May21.064614.28349@news.cso.uiuc.edu>
  Date: 21 May 92 06:46:14 GMT
  Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  Reply-To: ercolessi@uimrl7.mrl.uiuc.edu (furio ercolessi)
  Organization: MRL - UIUC
  Lines: 30
  Xref: rphroy sci.physics:26257 sci.astro:19692 sci.math:23310
  
  
  	Starting from April 1992, fully automated bulletin boards 
  	for preprints in physics and mathematics are available 
  	at SISSA (International School for Advanced Studies), Trieste, 
  	Italy.   The service is free and people are welcome to use it.
  
  	Preprints can be submitted and retrieved.  It is also possible 
  	to subscribe to a daily distribution list, containing authors 
  	and abstracts of the papers just submitted to the board.
  
  	The boards are operated by sending commands by e-mail to
  	the appropriate Internet address:
  
  	- cond-mat@babbage.sissa.it   for condensed matter physics
  	- astro-ph@babbage.sissa.it   for astrophysics
  	- funct-an@babbage.sissa.it   for functional analysis
  
  	An analogous service, based on the same software, is
  	provided by Los Alamos National Lab for high energy
  	physics preprints:
  
  	- hep-th@xxx.lanl.gov         for high energy physics, theory
  	- hep-ph@xxx.lanl.gov         for high energy physics, phenomenological
  
  	Preprints are in TeX/LaTeX format. Facilities to use special 
  	macros are available.  Figures in PostScript format may be
  	also submitted.  Anonymous ftp access is also possible.
  	For further details, instructions, disclaimers, etc, please 
  	send a mail with Subject: help  to the address of the desired 
  	board.
  
  
  Article: 30771 of sci.physics
  Path: rphroy!zaphod.mps.ohio-state.edu!usc!sol.ctr.columbia.edu!destroyer!ncar!uchinews!curie.uchicago.edu!trivedi
  From: trivedi@curie.uchicago.edu (Anil Trivedi)
  Newsgroups: sci.physics,sci.astro,sci.math
  Subject: Re: Preprint Servers: Is there a list...?
  Message-ID: <1992Aug12.074607.10886@midway.uchicago.edu>
  Date: 12 Aug 92 07:46:07 GMT
  References: <l7ukasINNaem@pollux.usc.edu> <Bsu41w.7Ln@news.cso.uiuc.edu> <1992Aug11.221257.19812@unixg.ubc.ca>
  Sender: news@uchinews.uchicago.edu (News System)
  Organization: University of Chicago
  Lines: 35
  Xref: rphroy sci.physics:30771 sci.astro:22367 sci.math:26084
  
  keith@msmri.med.ubc.ca writes:
   > I think the automated preprint servers which are popping up at various
   > sites are a wonderful idea but how does one find out about new
   > servers and what topics the current servers cover?
  
  The servers I am aware of are:
  
   alg-geom@publications.math.duke.edu (algebraic geometry)
   astro-ph@babbage.sissa.it           (astrophysics)
   cond-mat@babbage.sissa.it           (condensed matter)
   funct-an@babbage.sissa.it           (functional analysis, n.b.: not fun-anal)
   hep-lat@ftp.scri.fsu.edu            (computational and lattice physics)
   
   gr-qc@xxx.lanl.gov		     (general relativity / quantum cosmology)
   gr-qc@babbage.sissa.it		     ...a duplicate of the above archive...
   
   hep-ph@xxx.lanl.gov                 (high energy physics phenomenological)
   hep-ph@babbage.sissa.it             ...a duplicate of the above archive...
   
   hep-th@xxx.lanl.gov                 (high energy physics formal)
   hep-th@babbage.sissa.it             ...a duplicate of the above archive...
   
   lc-om@alcom-p.cwru.edu              (liquid crystals, optical materials)
   e-mail@xxx.lanl.gov                 (e-mail address database)
  
  Notice that the last one is not a preprint server but an e-mail address
  database.
  
  Notice also that qc-gr, hep-ph, and hep-th archives are duplicated
  at two sites; so choose the nearer one.
  
  To get the basic information file from any server, send mail to that
  server with the Subject line set as "Subject: help".
  
  -----
  
  


From emv@cic.net  Wed Aug 19 07:52:52 1992
Return-Path: <emv@cic.net>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28758; Wed, 19 Aug 92 07:52:52 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21975; Wed, 19 Aug 92 06:53:48 +0200
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA09771; Wed, 19 Aug 92 00:53:19 EDT
Message-Id: <9208190453.AA09771@nic.cic.net>
To: www-talk@nxoc01.cern.ch
Subject: links for you all to look at - GopherCon trip report, X.500 gateway
Date: Wed, 19 Aug 92 00:53:16 -0400
From: emv@cic.net

take a look at
	gopher://gopher.msen.com:70/11/internet-review/v2n3
for a trip report to GopherCon.  I did an "alternative universe"
scenario in which the conference was really about World Wide Web
instead, the supercollider was in Michigan not Texas, and U Minnesota
was running a mainframe based CWIS.

the other thing coming out of that that's really cool is a gopher based
X.500 front end, see
	gopher://umich.edu:7777/
for that.  (subject to change).  Tim Howes did some work so that
a server speaks gopher on one side and X.500 on the other, something
which I think is quite reusable in the WWW world.

thanks,

--Ed

From connolly@pixel.convex.com  Wed Aug 19 10:14:50 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29023; Wed, 19 Aug 92 10:14:50 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04982; Wed, 19 Aug 92 09:15:43 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA21115; Wed, 19 Aug 92 02:15:05 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA01336; Wed, 19 Aug 92 02:14:34 -0500
Message-Id: <9208190714.AA01336@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: can now read/write html from FrameMaker!
Date: Wed, 19 Aug 92 02:14:32 CDT
From: Dan Connolly <connolly@pixel.convex.com>

I just spent some time integrating FrameMaker and
HTML. The open/save dialogs in frame can be configured
to automatically convert from/to HTML.

The tools are based on the XLisp interpreter and
the SGMLs SGML parser, but they work pretty well.

Anybody volunteer some FTP disk space?

Anybody else want me to email them a shar file?

Dan

From jfg@dxcern.cern.ch  Wed Aug 19 14:00:54 1992
Return-Path: <jfg@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29552; Wed, 19 Aug 92 14:00:54 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04735; Wed, 19 Aug 92 13:01:50 +0200
Received: by dxcern.cern.ch (5.57/Ultrix3.0-C)
	id AA14969; Wed, 19 Aug 92 13:01:26 +0200
Date: Wed, 19 Aug 92 13:01:26 +0200
From: jfg@dxcern.cern.ch (Jean Francois Groff)
Message-Id: <9208191101.AA14969@dxcern.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: can now read/write html from FrameMaker!
References: <9208190714.AA01336@pixel.convex.com>

  Great ! You can send your stuff to info.cern.ch:/pub/incoming, and
we'll transfer it to /pub/www/src for everyone to see.

	Jean-Francois

From timbl  Wed Aug 19 19:41:46 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00906; Wed, 19 Aug 92 19:41:46 GMT+0100
Date: Wed, 19 Aug 92 19:41:46 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9208191841.AA00906@ nxoc01.cern.ch >
To: JUDY@crnvma.cern.ch
Subject: Re: on-line dictionaries/thesaurus
Cc: www-talk@nxoc01.cern.ch

There are dictionary servers running, but the polite thing
to do is to limit their use to your own site. There is a pd
client and server system (not w3 compatible unfortunately
but I am sure very easily hackable) for the NeXT. Every NeXT
comes with Webster's and Roget's thesaurus. We could make
the dictionary of some NeXT available to teh CERN site
but it would be less than nice tomake it available worldwide.
(We can make a W3 server which only allows .cern.ch connections).

Good summer student project for a few days/weeks.

There is a public WAIS server for an early out of coipyright
Roget's thesaurus. Find it under "Reference" in the subject list
or www http://info.cern.ch:8001/wais.cic.net:210/roget-thesaurus

The copyright situation for online stuff is not well defined as far
as I know. You could trythe El;ectronic Frontier Foundation's
archives or their personel for leads .. theat is their speciality
(law of the electronic information revolution).

J-P and I spent a few seconds on the problem, but did not have
much time.

The Roget's thesaurus on that server (at CICnet) by hte way
is provided from teh Gutenberg project collection of out-of-copyright
littereature.


	Tim

Anyone else on the list know of a dictionary server on the web?

	From JUDY@crnvma.cern.ch Fri Aug 14 16:59:25 1992
	Return-Path: <JUDY@crnvma.cern.ch>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA19255; Fri, 14 Aug 92 17:59:20 MET DST
	Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
		id AA02451; Fri, 14 Aug 92 17:00:08 +0200
	Message-Id: <9208141500.AA02451@dxmint.cern.ch>
	Received: from CERNVM.cern.ch by CERNVM.CERN.CH (IBM VM SMTP V2R2)
	   with BSMTP id 7458; Fri, 14 Aug 92 17:00:36 SET
	Received: from CERNVM (JUDY) by CERNVM.cern.ch (Mailer R2.08) with BSMTP id
	 0267; Fri, 14 Aug 92 17:00:36 SET
	Date:         Fri, 14 Aug 92 16:48:18 SET
	From: Judy Richards <JUDY@crnvma.cern.ch>
	Subject:      on-line dictionaries/thesaurus
	To: Tim <timbl@nxoc01.cern.ch>

	I understand that a month or two back you discussed this with Jean-Pol
	Matheys and got hold of some software but it didn't work properly.

	My question is more general - do you know of any software, commercial or
	not, that would allow us to put a 'dictionaty server' in the computer
	centre? I find it hard to imagine that you could get something completely
	for free without breaking some sort of copyright law - at least the
	dictionaries themselves must be protected in some way. How much do you know
	about this subject, and how should one set about finding out more? Any
	leads would be appreciated!


From HARMO@valt.helsinki.fi  Thu Aug 20 16:30:03 1992
Return-Path: <HARMO@valt.helsinki.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03592; Thu, 20 Aug 92 16:30:03 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23770; Thu, 20 Aug 92 15:30:52 +0200
Received: from charon-gw.pc.Helsinki.FI by kruuna.helsinki.fi with SMTP id AA14484
  (5.65c8/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Thu, 20 Aug 1992 16:30:20 +0300
Received: From HYLKN1/WORKQUEUE by charon-gw.pc.Helsinki.FI
          via Charon 3.4 with IPX id 100.920820163145.320;
          20 Aug 92 16:32:14 +0200
Message-Id: <MAILQUEUE-101.920820161806.339@valt.Helsinki.FI>
To: www-talk@nxoc01.cern.ch
From: "Timo Harmo - SocSci U of Helsinki"  <HARMO@valt.helsinki.fi>
Date:     20 Aug 92 16:18:06 EET
Subject:  Help with lm-browser installation
X-Pmrqc:  1
X-Mailer: Pegasus Mail v2.2 (R3).

I told a friend of mine (who is a unix novice) about WWW, and
he got very excited about it and wanted to install the line-mode
browser into his system.
He is working on an information system for some 50 Finnish NGOs,
and WWW seems most promising media for small, non-governement
organizations.

As he turned to me from help, and I know nothing about unix, so
my only resource is to turn to this list.

The system he is running is Sun (os 4.1.2)
I have the feeling that it is a very simple unix-problem, and not
very fruitfull if discussed in public. He went thru the installation,
but something seems to be wrong. If there is anybody out there
willing to help, please reply to me and I will put him in
contact with you.
 -Timo

From emv@nigel.msen.com  Thu Aug 20 20:17:18 1992
Return-Path: <emv@nigel.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04471; Thu, 20 Aug 92 20:17:18 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13542; Thu, 20 Aug 92 19:18:14 +0200
Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mLG8n-0009bqC@nigel.msen.com>; Thu, 20 Aug 92 13:17 WET DST
Message-Id: <m0mLG8n-0009bqC@nigel.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: web, schmeb, give me a hierarchy
In-Reply-To: Your message of 20 Aug 92 16:18:06.
             <MAILQUEUE-101.920820161806.339@valt.Helsinki.FI> 
Date: Thu, 20 Aug 92 13:17:26 EDT
From: Edward Vielmetti <emv@msen.com>

a frustrating experience I want to relate...

i want to take a look at the trip reports that I know are on the CERN
server.  I even know pretty much where they are in the server, or at
least I can get to one of them (Hypertext '92) with some relatively
obvious browsing.  but there's no way I can see to get a screen full
of all of them, without having someone construct a .html file for that
directory, and even then that depends on there being an "obvious name"
for that file or a coded link.

the www stuff is organized in directories that make some sense.  I
would like to browse through them that way, ploddingly and
methodically, just like I can plow through gopherspace and examine
each document in turn.  I don't see a good way to do that, and it's
frustrating.

--Ed


From timbl  Fri Aug 21 02:13:42 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05573; Fri, 21 Aug 92 02:13:42 GMT+0100
Date: Fri, 21 Aug 92 02:13:42 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9208210113.AA05573@ nxoc01.cern.ch >
To: HARMO@valt.helsinki.fi, www-talk@nxoc01.cern.ch
Subject: Re: Help with lm-browser installation


If the information on the web itself (which he canalways access
using telnet info.cern.ch when desparate) is not sufficient,
he can ask www-bug@info.cern.ch which is the w3 support team at CERN.

This www-talk list is only if he has a puzzling thing he would like
to ask all interested technical people.

I would really suggest that on a sun one of the X browsers would
be more user-friendly, but the line moed browser will of course
work.

Tim BL

From timbl  Fri Aug 21 18:44:50 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07407; Fri, 21 Aug 92 18:44:50 GMT+0100
Date: Fri, 21 Aug 92 18:44:50 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9208211744.AA07407@ nxoc01.cern.ch >
To: emv@msen.com, www-talk@nxoc01.cern.ch
Subject: Re: web, schmeb, give me a hierarchy

Ed,

First off, thanks for the pointer to the Gophercon report.

You would like to be able to browse through the directories
of the http server's file system.  I gree this would be a useful
feature, and it is one we aim to put in one day (trivial like
all the other things to do :-).

Mind you, there are some things in the W3 team's directory
which are just temporary or junk or old versions, etc. So
we might feel that we don't want people reading for example
our c files as we edit them. There's a bit of security there
that if we temporarily leave in a WWW directory
something which we wouldn't want distributed (like a copy
of passwd -- unlikely but an example) then noone will
find it. These are our working directories. So probably when
we dop produce a server which will serve directories, which
will make it MUCH easier to publish plain text a la Gopher
server, then we might ourselves disable it.

What we SHOULD do is WAIS-index the lot and also make a
little recursive   "www -lR" which traverses a web.
Another trivial bit of code...  You have to have a 
terminating condition of course.

BTW thanks also for mentioning W3 again in Gopherville.
I liked teh bit in the report about W3 being the result of
"heavy investment" by the Physics community. At CERN we are
trying to arrange for a third person... Bothe W3 and Gopher
of course are basically grass-roots sourced. We are talking about
a W3 support consortium ... maybe a W3con is not too far off.

Tim

From koellner@lbl.bitnet  Sat Aug 22 02:33:54 1992
Return-Path: <koellner@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08701; Sat, 22 Aug 92 02:33:54 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15151; Sat, 22 Aug 92 01:34:55 +0200
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R1)
   with BSMTP id 0476; Sat, 22 Aug 92 01:36:16 SET
Received: from Lbl.Bitnet by CEARN.cern.ch (Mailer R2.07B) with BSMTP id 4989;
 Sat, 22 Aug 92 01:36:15 SET
Date:    Fri, 21 Aug 92 16:15:57 PDT
From: koellner@lbl.bitnet (Werner Koellner, LBL)
Message-Id: <920821161557.21807317@csa3.lbl.gov>
Subject: How to print a document from linemode www
To: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"www-talk@info.cern.ch"

                                         LBL, Physics Division, 21-AUG-1992

    Hi,
       using the LineMode www on a VAX, can a document that is displayed on
       the screen be sent to a printer? If so, how can that be done?

                     Many thanks,

                                   Werner

From fkappe@fiicmds04.tu-graz.ac.at  Sat Aug 22 13:33:45 1992
Return-Path: <fkappe@fiicmds04.tu-graz.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09315; Sat, 22 Aug 92 13:33:45 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23226; Sat, 22 Aug 92 12:34:47 +0200
Received: by iicm.tu-graz.ac.at (5.57/Ultrix3.0-C)
	id AA24442; Sat, 22 Aug 92 12:33:57 +0200
Date: Sat, 22 Aug 92 12:33:57 +0200
From: fkappe@fiicmds04.tu-graz.ac.at (Frank Kappe)
Message-Id: <9208221033.AA24442@iicm.tu-graz.ac.at>
To: emv@msen.com
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Edward Vielmetti's message of Thu, 20 Aug 92 13:17:26 EDT <m0mLG8n-0009bqC@nigel.msen.com>
Subject: web, schmeb, give me a hierarchy

>>>>> On Thu, 20 Aug 92 13:17:26 EDT, Edward Vielmetti <emv@msen.com> said:

Ed> a frustrating experience I want to relate...

Ed> ...

Ed> the www stuff is organized in directories that make some sense.  I
Ed> would like to browse through them that way, ploddingly and
Ed> methodically, just like I can plow through gopherspace and examine
Ed> each document in turn.  I don't see a good way to do that, and it's
Ed> frustrating.

What you tell us is part of the disorientation problem frequently reported by
hypertext users ("lost in hyperspace"). In my opinion, the solution you propose
- adding a hierarchical view of the docuverse like in gopherspace - makes a lot
of sense. Therefore Hyper-G, the hypermedia system that we are currently
developing offers not only a pure hypertext user interface metaphor, but
combines it with a hierarchy of browsable and searchable "collections" and
so-called "guided tours" where you can follow trails you or anybody else has
previously defined.

Greetings,
        Frank



From connolly@pixel.convex.com  Tue Aug 25 01:45:33 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13754; Tue, 25 Aug 92 01:45:33 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22162; Tue, 25 Aug 92 00:46:37 +0200
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA26432; Mon, 24 Aug 92 17:44:33 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA08880; Mon, 24 Aug 92 17:44:29 -0500
Message-Id: <9208242244.AA08880@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: anybody using www_and_frame?
Date: Mon, 24 Aug 92 17:44:28 CDT
From: Dan Connolly <connolly@pixel.convex.com>

I thought there was significant interest in the package,
but I haven't heard a word since I uploaded it.

Has anyone had a chance to look at it?

Dan

From mcclanah@dlgeo.cr.usgs.gov  Tue Aug 25 23:12:45 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16555; Tue, 25 Aug 92 23:12:45 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16285; Tue, 25 Aug 92 22:13:54 +0200
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA06212; Tue, 25 Aug 92 15:11:53 CDT
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA07756; Tue, 25 Aug 1992 15:13:01 -0500
Date: Tue, 25 Aug 1992 15:13:01 -0500
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9208252013.AA07756@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: www_and_frame


Dan,

Yes I downloaded your stuff 8-20 (or 21).  I am very interested in
it as we use Frame in our office.  Another project has used Maker
Markup Language (MML) to do something similar to what I want
to do and so I am trying to use some of his stuff, change it so
that I am not tied to a proprietary package, and use it in my
current project.  I realize that for the time being  I will be 
dependent on Frame to create HTML documents.  Hopefully there
will be other potential avenues to create HTML documents at
some point i the future.  Or perhaps if CERN provides SGML or
Hy-Time integration then there will be other products that I
can use. Who knows what the future will hold.

I am currently out of the office and so have not tried to play
with your stuff at all.  I got xlisp and compiled and I had sgml
parser but need to compile 0.8.  Will let you know when I get
it all put together.  I am sure I will have some questions when I try to
start using it.

Thanks
Pat

From timbl  Thu Sep 24 15:51:46 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23922; Thu, 24 Sep 92 15:51:46 GMT+0100
Date: Thu, 24 Sep 92 15:51:46 GMT+0100
From: timbl (Tim Berners-Lee)
Message-Id: <9209241451.AA23922@ nxoc01.cern.ch >
To: LAPPA@b.psc.edu
Subject: Re: A few questions about sgml
Cc: www-talk@nxoc01.cern.ch

Joseph,

Thanks for your mail.  It'll be great to see you documents on the web.

let me explain the relationship between SGML and HTML. As you probbly
know, when you use SGML, you must use a particular document type
(DTD). Our HTML is a particular document type -- it includes simple
formatting and hypertext links. We defined it because there was no standard
DTD for hypertext around (there still isn't).

So HTML is SGML but not necessarily the reverse.  If your documents are
in a different documen type then you can do one of two things:
one is to write a server which will take your SGML documents and convert
them into HTML (one th fly, probably) for W3 clients.  This will
probably mean translating some tags.

The second option is to wait until the format negotiation which we
are putting into the protocol comes out. This will anser your second
question too, in that it will allow graphics to be picked up.
The fact of life here is that there are no (or rather, too many)
standrads both for SGML DTDs and for graphics (and sound, video etc)
so futur clients will be configured to know which formats you can
use on your local machine. They will tell the server this, so that the
server can send a document in the "best"format possible.  You could define
your own DTD as a specific document format, and define the software which
you will want to run to handle documents in that format.

Now in parallel wit these developments (the format negotiation runs in
prototype form now), Pei Wei of O'Reilly Assoiciates, the author of the
Viola browser, is putting in generic SGML handling (ie coinfigurable
for many different DTDs) as well as embedded graphics. So his browser,
also currently in prototype form, will do just what you want, I think.

Tim Berners-Lee

	From LAPPA@b.psc.edu Wed Sep 23 22:42:59 1992
	Return-Path: <LAPPA@b.psc.edu>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA21828; Wed, 23 Sep 92 22:42:55 GMT+0100
	Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
		id AA22588; Wed, 23 Sep 92 22:42:58 +0200
	Date:    Wed, 23 Sep 1992 16:42:24 -0400 (EDT)
	From: LAPPA@b.psc.edu (What's Up?)
	Message-Id: <920923164224.22c0725b@B.PSC.EDU>
	Subject: A few questions about sgml
	To: timbl@nxoc01.cern.ch
	X-Vmsmail-To: SMTP%"timbl@info.cern.ch"

	Hello,

	  My name is Joseph Lappa and I work for the Pittsburgh Supercomputing Center. 
	We are currently evaluating information servers including WWW.  We have decided
	to write all of our documents in SGML and make them available to our users via 
	some protocol/server (WWW, wais, or gopher).


	I have a few questions (and I hope I'm asking the right person :-))


	1) Can WWW read in SGML directly into a document bypassing HMTL?  I was reading
	   one the in documents that SGML was very important to WWW but I'm not sure
	   where SGML fits in.

	2) Is there the capability to retrieve non-hmtl files such as GIF or CGM files
	   that are included within a SGML document.  We are very big on CGM file
	   format and our SGML file viewer allows CGM files to be included as figures
	   or even animations (this would be for viola and other graphic interfaces).  

	3) Do you plan on having a SGML text (like vt100 terminal) viewer in addition 
	   to a X-Windows version such as viola?


	I hope these questions make sense :-)

	Thank You very much,
	Joseph Lappa




From timbl  Mon Sep 28 13:40:33 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04048; Mon, 28 Sep 92 13:40:33 MET
Date: Mon, 28 Sep 92 13:40:33 MET
From: timbl (Tim Berners-Lee)
Message-Id: <9209281240.AA04048@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: www-talk@nxoc01.cern.ch
Subject: Man pages server code, anyone?
Cc: ruth@fnal.fnal.gov


I know I heard of someone with a filter for unix man page to HTML,
but I can't find it.  Does anyone on this list write one?

	Tim BL


From jones@online.cern.ch  Mon Sep 28 13:54:15 1992
Return-Path: <jones@online.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04132; Mon, 28 Sep 92 13:54:15 GMT+0100
Received: from ONLINE.DECnet MAIL11D_V3 by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13989; Mon, 28 Sep 92 13:54:30 +0100
Date: Mon, 28 Sep 92 13:54:29 +0100
Message-Id: <9209281254.AA13989@dxmint.cern.ch>
From: jones@online.cern.ch (Bob Jones ECP/DS tel:5014 or 4833)
To: www-talk@nxoc01.cern.ch
Cc: JONES@online.cern.ch
Subject: accessing FrameMaker documents through WWW
X-Mail11-Ostype: VAX/VMS

Tim BL, during a talk at the CHEP'92 conference last week, mentioned that there 
was some software available to make FrameMaker documents accessible from WWW. I 
tried finding any references to this in the web but came home empty-handed. Does 
anyone know if such a beast exists?

Bob Jones.


From mcclanah@dlgeo.cr.usgs.gov  Mon Sep 28 18:16:29 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05325; Mon, 28 Sep 92 18:16:29 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09094; Mon, 28 Sep 92 18:16:45 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA03530; Mon, 28 Sep 92 12:11:45 CDT
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA04307; Mon, 28 Sep 1992 12:16:04 -0500
Date: Mon, 28 Sep 1992 12:16:04 -0500
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9209281716.AA04307@dlgeo.cr.usgs.gov>
To: jones@online.cern.ch (Bob Jones ECP/DS tel:5014 or 4833),
        www-talk@nxoc01.cern.ch
Cc: JONES@online.cern.ch
Subject: Re: accessing FrameMaker documents through WWW

I have gotten ahold of the code and messed around with it to some degree
Contact Dan Connolly (connoly@pixel.convex.com) about what you need and
how to get it.

As long as I am on the subject:  I have found Dan's utility to work
pretty much as advertised, a few glitches but its a relatively young
piece of wotk.  Dan has been extremely expedient in responding
to my e-mail questions, and more than patient with my ignorance
about exactly how to use his tool.  I have encouraged Dan to 
continue his work, he has already (or will soon) addressed some
of the problems I have run into.

I think it a tool well worth looking into.  If you use it and find
it worthwhile, please let Dan know and encourage his efforts.

WWW gains another cog in its wheel of completeness!!! (or will it ever
really be complete?)

Pat McClanahan
EROS Data Center
Sioux Falls, South Dakota
USA

From mcclanah@dlgeo.cr.usgs.gov  Mon Sep 28 18:34:10 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05395; Mon, 28 Sep 92 18:34:10 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10712; Mon, 28 Sep 92 18:34:24 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA03717; Mon, 28 Sep 92 12:29:23 CDT
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA04321; Mon, 28 Sep 1992 12:33:44 -0500
Date: Mon, 28 Sep 1992 12:33:44 -0500
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9209281733.AA04321@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: Re: accessing FrameMaker documents through WWW

 
I have gotten ahold of the code and messed around with it to some degree
Contact Dan Connolly (connoly@pixel.convex.com) about what you need and
how to get it.
 
As long as I am on the subject:  I have found Dan's utility to work
pretty much as advertised, a few glitches but its a relatively young
piece of wotk.  Dan has been extremely expedient in responding
to my e-mail questions, and more than patient with my ignorance
about exactly how to use his tool.  I have encouraged Dan to
continue his work, he has already (or will soon) addressed some
of the problems I have run into.
 
I think it a tool well worth looking into.  If you use it and find
it worthwhile, please let Dan know and encourage his efforts.
 
WWW gains another cog in its wheel of completeness!!! (or will it ever
really be complete?)
 
Pat McClanahan
EROS Data Center
Sioux Falls, South Dakota
USA

From putz@parc.xerox.com  Mon Sep 28 18:43:35 1992
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05452; Mon, 28 Sep 92 18:43:35 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11525; Mon, 28 Sep 92 18:43:50 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11593>; Mon, 28 Sep 1992 10:43:10 PDT
Received: by spoggles.parc.xerox.com id <58401>; Mon, 28 Sep 1992 10:43:04 -0700
Date: 	Mon, 28 Sep 1992 10:42:41 PDT
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: Man pages server code, anyone?
In-Reply-To: <9209281240.AA04048@nxoc01.cern.ch>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: www-talk@nxoc01.cern.ch, ruth@fnal.fnal.gov
Message-Id: <92Sep28.104304pdt.58401@spoggles.parc.xerox.com>

Hi Tim,

I don't have a man page to HTML filter, but I did hack together a simple
man page http server implemented in C-shell.  The man pages are just
formatted by the man command (using nroff) and presented as <PLAINTEXT>.
Here is a sample session:

-------------------------------------------------------------------------------
                                                        PARC Unix Manual Search
                                   UNIX HELP
                                       
   Enter keywords to find Unix manual pages
   
   or select a man page[1] by name or return to the PARC Web[2]
     [End]

FIND <keywords>, 1-2, Back, Quit, or Help: f www

-------------------------------------------------------------------------------
                                                         PARC Unix Manuals: www
                                      WWW
                                       
   Select a man page[1] or return to the PARC Web[2] or enter another keyword
   
  viola[3] (1)           X-Windows World-Wide Web (WWW) browser
                         
  www[4] (1)             World-Wide Web line-mode browser
     [End]

FIND <keywords>, 1-4, Back, Quit, or Help: 4

-------------------------------------------------------------------------------
                                                        PARC Unix Manual: 1 www
                                      WWW
                                       
   Enter a keyword or select a man page[1] by name or return to the PARC Web[2]
   


www(1)                   USER COMMANDS                     www(1)

NAME
     www - World-Wide Web line-mode browser

SYNOPSIS
     www [options] [docaddress [keywords]]

DESCRIPTION
     The World-Wide Web line-mode  browser  allows  you  to  find
     information  by  following  references  and/or by using key-
     words.

     References  are  numbers  in  [brackets]  after   particular
     phrases.  Type the number and RETURN for more information on
FIND <keywords>, 1-2, Back, <RETURN> for more, Quit, or Help: q
-------------------------------------------------------------------------------

From rik@daneel.rdt.monash.edu.au  Tue Sep 29 04:47:50 1992
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07069; Tue, 29 Sep 92 04:47:50 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26793; Tue, 29 Sep 92 04:48:01 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA05803; Tue, 29 Sep 92 13:47:20 +1000
Message-Id: <9209290347.AA05803@daneel.rdt.monash.edu.au>
To: www-talk@nxoc01.cern.ch, ruth@fnal.fnal.gov
Subject: Re: Man pages server code, anyone? 
In-Reply-To: Your message of "28 Sep 92 13:40:33 +0100."
             <9209281240.AA04048@ nxoc01.cern.ch > 
Date: Tue, 29 Sep 92 13:47:19 -1000
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

> I know I heard of someone with a filter for unix man page to HTML,
> but I can't find it.  Does anyone on this list write one?

I'm currently writing one in perl.  It almost does the hypertext links
to the "See Also" manual pages, and anything else that looks like
another man page.  Unfortunately, it will probably have to be
customised to the -man macros that are in use on each system.  Mine is
currently customised for SunOS man pages, but I'm trying to make it
more general.  Sorry I won't give out code at the moment, not until it
works :-)

If anyone's got any great ideas, or suggestions for this, let me
know.

rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au         || Systems Programmer
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH) || and Administrator
Faculty of Computing and Information Technology,   || Vic. Institute of
Caulfield Campus, Monash University, Australia     || Forensic Pathology

From romig@cis.ohio-state.edu  Tue Sep 29 05:18:19 1992
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07117; Tue, 29 Sep 92 05:18:19 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04697; Tue, 29 Sep 92 05:18:29 +0100
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA01784; Tue, 29 Sep 92 00:17:53 -0400
Date: Tue, 29 Sep 92 00:17:53 -0400
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9209290417.AA01784@brachiosaur.cis.ohio-state.edu>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch, ruth@fnal.fnal.gov
In-Reply-To: Tim Berners-Lee's message of Mon, 28 Sep 92 13:40:33 MET <9209281240.AA04048@ nxoc01.cern.ch >
Subject: Man pages server code, anyone?

I wrote a simple set of scripts that ran the unformatted man sources
through nroff with a special set of man macros that did away with the
page headings/footings, and converted the formatted ascii output into
html.  I wanted to convert any references to things that look like man
pages (as in "man(1)") to links.  What I really wanted was to put the
man page in a <listing> environment to preserve the formatting, but
you can't embed anchors there.  </LISTING><A ...>...</A><LISTING>
seems to cause paragraph breaks, not quite what I had in mind.  

I finally settled on making a list of the man page references and
turned them into an extra See Also section at the end of the document.
Its ugly, but functional.  I'll clean up the code and make it
available if anyone is interested.

It would be nice if there were a thing like LISTING that allowed
anchors.  Are there any plans for such a thing (or maybe there's a way
to do it now that I don't know about)?  It would make the task of
converting misc text files into HTML much easier.

--- Steve

From connolly@pixel.convex.com  Tue Sep 29 18:25:37 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09698; Tue, 29 Sep 92 18:25:37 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01338; Tue, 29 Sep 92 18:25:39 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA07503; Tue, 29 Sep 92 12:25:00 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA20685; Tue, 29 Sep 92 12:24:56 -0500
Message-Id: <9209291724.AA20685@pixel.convex.com>
To: jones@online.cern.ch (Bob Jones ECP/DS tel:5014 or 4833)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: accessing FrameMaker documents through WWW 
In-Reply-To: Your message of "Mon, 28 Sep 92 13:54:29 BST."
             <9209281254.AA13989@dxmint.cern.ch> 
Date: Tue, 29 Sep 92 12:24:56 CDT
From: Dan Connolly <connolly@pixel.convex.com>


>Tim BL, during a talk at the CHEP'92 conference last week, mentioned that there 
>was some software available to make FrameMaker documents accessible from WWW. I 
>tried finding any references to this in the web but came home empty-handed. Does 
>anyone know if such a beast exists?
>
try:
www file://info.cern.ch/pub/WWW/src/www_and_frame-README

or
www file://info.cern.ch/pub/incoming/www_and_frame.html

(some of the links in the the html version won't work -- you'll
have to download the distribution and grab the files they point
to.)

Dan


From connolly@pixel.convex.com  Tue Sep 29 18:31:42 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09734; Tue, 29 Sep 92 18:31:42 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02011; Tue, 29 Sep 92 18:31:58 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA07795; Tue, 29 Sep 92 12:31:19 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA20953; Tue, 29 Sep 92 12:31:17 -0500
Message-Id: <9209291731.AA20953@pixel.convex.com>
To: jones@online.cern.ch (Bob Jones ECP/DS tel:5014 or 4833)
Cc: JONES@pixel.convex.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: accessing FrameMaker documents through WWW 
In-Reply-To: Your message of "Mon, 28 Sep 92 16:24:25 BST."
             <9209281524.AA27049@dxmint.cern.ch> 
Date: Tue, 29 Sep 92 12:31:17 CDT
From: Dan Connolly <connolly@pixel.convex.com>


>Hi Dan,
>	Robert Cailliau here at CERN told me you had done some work to integrat
e 
>FrameMaker and WWW. We have a fair number of documents written using FrameMake
r 
>which we would like to make available through WWW. Can you give me some detail
s 
>of the work you have done?

I wrote it up in:
www file://info.cern.ch/pub/WWW/src/www_and_frame-README

or you can try the html version with links (most of which point to
files in the distribution that it assumes you have downloaded...)
in:

www file://info.cern.ch/pub/incoming/www_and_frame.html

You might be disappointed: the aim of the project is to be able to
use FrameMaker to work on HTML documents, not to get www to grok
frame files.

Dan


From timbl  Thu Oct  1 09:29:13 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15067; Thu, 1 Oct 92 09:29:13 MET
Date: Thu, 1 Oct 92 09:29:13 MET
From: timbl (Tim Berners-Lee)
Message-Id: <9210010829.AA15067@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: jones@online.cern.ch (Bob Jones ECP/DS tel:5014 or 4833)
Subject: Re: accessing FrameMaker documents through WWW
Cc: www-talk@nxoc01.cern.ch

Sorry, Bob -- the tar file is available by anon ftp on info.cern.ch
as /pub/www/src/www_and_frame*


> Tim BL, during a talk at the CHEP'92 conference last week, mentioned that there 

> was some software available to make FrameMaker documents accessible from WWW. I 

> tried finding any references to this in the web but came home empty-handed. Does 

> anyone know if such a beast exists?
> 

> Bob Jones.



From timbl  Thu Oct  1 11:50:57 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15452; Thu, 1 Oct 92 11:50:57 MET
Date: Thu, 1 Oct 92 11:50:57 MET
From: timbl (Tim Berners-Lee)
Message-Id: <9210011050.AA15452@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: "Phillip M. Hallam-Baker" <HALLAM@zws012.desy.de>
Subject: Re: Setting up WWW at ZEUS, DESY:  Database 
Cc: www-talk@nxoc01.cern.ch


> Date: Mon, 28 Sep 1992 23:27 +0200
> From: "Phillip M. Hallam-Baker" <HALLAM@zws012.desy.de>
>
> Hello,

>	I would like to put the ZEUS online documentation online via WWW.I have
> already got the various sources etc to compile on the DECstation and can run the
>  browser on both VAX and Ultrix OK.

Great!  You might like to link up with Thomas Finnen who has a unix server running
at DESY.

>	What I really want to do is to set up the server on the VAX though. This
>  is where we do all the development etc, the DECstations belong to the offline
>  group and they won't let us get SU privs which are needed to put up daemons. Or
>  rather they might if they didn't suspect me of wanting to put up the TPU editor
>  so that EDT junkies like myself can use the things.

Fine. Lots of people have set up the server under VMS. We haven't incorporated
the changes needed into the distribution, but I'm sure a mail to www-talk would
get replies of people who had done it.  There is a DCL server example in
the W3 deamon documentation. The basic W3 files all compile under VMS, and there
is (in HTFile.c?) a routine to convert unix-style filenames to VMS style.
(The browser actually does that automatically when it runs on VMS, to read local
files).

>	Long term what I would like to do is to get the various RDB and Oracle
>  databases that the ZEUS online system is being reorganized arround up onto a W3
>  server. This would save me the hassle of writting and maintaining browsers etc.

Good idea.  If the code from the generic W3-Oracle gateway can be of use to
you then feel free...see  
http://info.cern.ch/hypertext/WWW/Daemon/Oracle/Overview.html

>	This raises a number of questions, particularly in the area of security.
>  I would like to use an authentication scheme. What I had in mind was that the
>  client making a request requiring validation should recieve back a key which
>  would be encoded at the client end and returned to the server where it would be
>  decoded to see if it matched. The key would be changed on each pass. This would
>  require a list of active keys to be kept in order to allow serving of multiple
>  requests concurrently which would of course make the server non-idempotent.

We have a prototype server running which operates in a similar way, but currently
without encryption: the passwords are simply sent in the clear over the net with
every document retrieval. This is not high security, but it is as high as we
currently have with telnet sessions.  This is being prototyped now.

>	The end product as far as ZEUS would be concerned would be just a single
>  database that could be interrogated via WWW protocols and a number of customized
>  form programs for interrogating it. However since we are using a G"odel
>  synthesizer to produce the servers the project will naturally generate what
>  amounts to a VHLL compiler for WWW compatible database servers.

I don't know about G"odel synthesisers nor VHLL though they both ring a bell...
Obviously it would be a good move to have a rapid customisation system for
producing hypertext views of relational databases. This could be perhaps a report
generator perhaps just producing HTML if it ran fast enough for real-time server
use. (A point-and click graphic view builder would be cool of course!)

>	Another idea I had was to integrate a HTML output window into my TROJAN
>  user interface synthesizer. This is a UIMS which spans Motif, Curses and SMG.
>  Other interfaces (particularly X-Windows related ones) can easily be added..
>  This would allow a fairly nice browser and possibly editor to be written, on the
>  VAX I would connect it to the LinkWorks package which is DECs own Hyper-product
>  which comes bundled in Motif. I suspect other vendors will shortly follow. What
>  I had in mind was a "WWW" output window which use a WWW hypertext link as the
>  linkable object thus allowing the DEC supplied "notepad" editor and cardfiler to
>  be used as a hypertext editor, I'm not clear on the design of this yet.

We have wondered about Linkworks integration, putting a W3 engine on so that
linkworks linsk could be makde to W3 objects, and maybe making a W3 retrieval
client which would use a table to fire up appropriate DEC tools when given
data in particular formats.

>		Phill M. Hallam-Baker

Tim Berners-Lee


From timbl  Fri Oct  2 15:34:18 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20700; Fri, 2 Oct 92 15:34:18 MET
Date: Fri, 2 Oct 92 15:34:18 MET
From: timbl (Tim Berners-Lee)
Message-Id: <9210021434.AA20700@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: accessing FrameMaker documents through WWW 
Cc: jones@online.cern.ch (Bob Jones ECP/DS tel:5014 or 4833),
        www-talk@nxoc01.cern.ch


>Tim BL, during a talk at the CHEP'92 conference last week, mentioned that there 

>was some software available to make FrameMaker documents accessible from WWW. I 

>tried finding any references to this in the web but came home empty-handed. Does 

>anyone know if such a beast exists?
>
I've put Dan's hypertext documentation from the tar file into the web.
at http://info.cern.ch./hypertext/WWW/Frame/fminit2.0/www_and_frame.html

Note there is now a list of tools for information providers
(.../WWW/Tools/Overbiew.html) on the web too.


If anyone has any tools, server scripts, etc which aren't on there then
mail me with the source and I'll put them up as examples and inspiration
to those who follow.

	Tim

From koellner%Csa6.LBL.Gov@lbl.bitnet  Mon Oct  5 16:46:04 1992
Return-Path: <koellner%Csa6.LBL.Gov@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01643; Mon, 5 Oct 92 16:46:04 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10223; Mon, 5 Oct 92 16:46:29 +0100
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 5280; Mon, 05 Oct 92 16:45:59 SET
Received: from Lbl.Bitnet by CEARN.cern.ch (Mailer R2.07B) with BSMTP id 7901;
 Mon, 05 Oct 92 16:45:58 SET
Received: from Csa6.LBL.Gov by Csa3.LBL.Gov via INTERNET ;
          Mon, 5 Oct 92 08:45:07 PDT
Date:    Mon, 5 Oct 92 08:44:42 PDT
From: koellner@csa6.lbl.gov%lbl.bitnet (Werner Koellner, LBL)
Message-Id: <921005084442.2c80272b@csa6.lbl.gov>
Subject: WWW/VIOLA "Memory leak" ?
To: timble@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"timble@nxoc01.cern.ch"
X-St-Vmsmail-Cc: ST%"www-talk@nxoc01.cern.ch"

                                         LBL, Physics Division,  5-OCT-1992

    I am running the Viola Version of www on a SUN Sparcstation using
    SunOS 4.1.2.

    Because after some time memory in use approaches the allocated swap
    space, I have kept statistics of memory in use by some partcicular
    processes that I normally start to run in the background. Besides www I
    have watched xrn, with the X11 or MOTIF window managers under both
    X11/R4 and X11/R5.

    I find that memory used by xrn remains about the same over time.

    However, the memory used by viola grows steadily with time even though
    no direct access www is being made.

    I see also some minor increase by X:0.

          I wonder if such apparent "memory leak" has been noticed by
          anyone else? Of, course I would also appreciate suggestions
          for correctiong this problem.

                   Best regards,

                                   Werner

From koellner%Csa6.LBL.Gov@lbl.bitnet  Mon Oct  5 16:54:44 1992
Return-Path: <koellner%Csa6.LBL.Gov@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01706; Mon, 5 Oct 92 16:54:44 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10970; Mon, 5 Oct 92 16:54:32 +0100
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 5320; Mon, 05 Oct 92 16:54:17 SET
Received: from Lbl.Bitnet by CEARN.cern.ch (Mailer R2.07B) with BSMTP id 8003;
 Mon, 05 Oct 92 16:54:11 SET
Received: from Csa6.LBL.Gov by Csa3.LBL.Gov via INTERNET ;
          Mon, 5 Oct 92 08:53:21 PDT
Date:    Mon, 5 Oct 92 08:53:13 PDT
From: koellner@csa6.lbl.gov%lbl.bitnet (Werner Koellner, LBL)
Message-Id: <921005085313.2c80272b@csa6.lbl.gov>
Subject: www/viola "memory leak" on SUN ?
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"timbl@nxoc01.cern.ch"
X-St-Vmsmail-Cc: ST%"www-talk@nxoc01.cern.ch"

                                         LBL, Physics Division,  5-OCT-1992

    I am running the Viola Version of www on a SUN Sparcstation using
    SunOS 4.1.2.

    Because after some time memory in use approaches the allocated swap
    space, I have kept statistics of memory in use by some partcicular
    processes that I normally start to run in the background. Besides www I
    have watched xrn, with the X11 or MOTIF window managers under both
    X11/R4 and X11/R5.

    I find that memory used by xrn remains about the same over time.

    However, the memory used by viola grows steadily with time even though
    no direct access www is being made.

    I see also some minor increase by X:0.

          I wonder if such apparent "memory leak" has been noticed by
          anyone else? Of, course I would also appreciate suggestions
          for correctiong this problem.

                   Best regards,

                                   Werner

From mcclanah@dlgeo.cr.usgs.gov  Mon Oct  5 17:12:58 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01822; Mon, 5 Oct 92 17:12:58 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12780; Mon, 5 Oct 92 17:13:25 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA25169; Mon, 5 Oct 92 11:13:33 CDT
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA19647; Mon, 5 Oct 1992 11:12:51 -0500
Date: Mon, 5 Oct 1992 11:12:51 -0500
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9210051612.AA19647@dlgeo.cr.usgs.gov>
To: koellner%csa6.lbl.gov%lbl.BITNET@your_bitnet_relay_goes_here.cern.ch (Werner Koellner, LBL),
        timble@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: WWW/VIOLA "Memory leak" ?

We just installed a piece of software called Purify, that is suppose
to detect memory leaks and some other goodies.  Let me see if I can
figure out how to use this stuff and maybe I can look at the output,
or mail it to you with an explanation about what it says.

Don't get to excited it may take a day or two (or three, or four).

Purify comes from Pure Software Inc, 211 Grant Road Los Altos CA,
94024 (support@pure.com)

Pat McClanahan

From mcclanah@dlgeo.cr.usgs.gov  Mon Oct  5 17:14:54 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01836; Mon, 5 Oct 92 17:14:54 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12961; Mon, 5 Oct 92 17:15:23 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA25229; Mon, 5 Oct 92 11:15:27 CDT
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA19668; Mon, 5 Oct 1992 11:14:45 -0500
Date: Mon, 5 Oct 1992 11:14:45 -0500
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9210051614.AA19668@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: Re: WWW/VIOLA "Memory leak" ?

 
We just installed a piece of software called Purify, that is suppose
to detect memory leaks and some other goodies.  Let me see if I can
figure out how to use this stuff and maybe I can look at the output,
or mail it to you with an explanation about what it says.
 
Don't get to excited it may take a day or two (or three, or four).
 
Purify comes from Pure Software Inc, 211 Grant Road Los Altos CA,
94024 (support@pure.com)
 
Pat McClanahan

From timbl  Thu Oct 15 15:23:13 1992
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08796; Thu, 15 Oct 92 15:23:13 MET
Date: Thu, 15 Oct 92 15:23:13 MET
From: timbl (Tim Berners-Lee)
Message-Id: <9210151423.AA08796@ nxoc01.cern.ch >
Received: by NeXT Mailer (1.62)
To: Jim Davis <davis@dri.cornell.edu>
Subject: Re: page break in HTML
Cc: www-bug@nxoc01.cern.ch, wei@xcf.berkeley.edu, www-talk@nxoc01.cern.ch

> From: Jim Davis <davis@dri.cornell.edu>
> I would like to be able to keep multiple topics in a single file
> (cross referenced by anchors of course) and also guarentee that the
> user does not see material from the next subject.  I use Viola with
> WWW, and it's distracting to see irrelevant material on the same  
page
> of the window.

Do you really need them in a single document?  Within a document, the  
user metaphor is a scrollable area. The user often has a choice of  
window size on that area.  It is unwise to make assumptions about  
that.

I think you are looking for page jumps, and so logically what you  
wnat is a set of documents.  Now you could of course store these in  
one file and write a little server script which would extract the  
documents from the file. (Note distinction between "document" = unit  
of data carried over the net per fetch, and "file" which is a concept
local to the server.

This is what Mike Sendall has done with his STING glossary, for  
example (I think).

It would also be neat for mailbox files.

	Tim BL

From davis@dri.cornell.edu  Fri Oct 16 17:11:18 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13607; Fri, 16 Oct 92 17:11:18 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09624; Fri, 16 Oct 92 17:12:09 +0100
Received: by willow.tc.cornell.edu id AA06348
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 16 Oct 1992 12:11:46 -0400
Date: Fri, 16 Oct 1992 12:11:46 -0400
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199210161611.AA06348@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: non-text documents

Can you tell us when WWW and Viola will support non-text
documents?  I would very much like to be able to return
pictures including Postscript.  I know this has been discussed
in the past.

One issue is how will the client know what kind of data
is being returned.  It seems there are several possibilities:

1) Make the client figure it out itself by examining the data (e.g.
for "magic numbers").  Simplest, but makes the client do too much
work.

2) Use typed links.  A server which wishes to return non-text data
first returns a constructed document containing anchors where the link
type somehow encodes the data type.  Benefit here is that it allows
the user to choose the kind of data if there is a choice.

3) the HTTP protocol to allow an HTTP server to inform the client of
the kind of data to be returned, maybe even negotiate about it.

4) Extend HTML to allow embedded non-text data, perhaps by using MIME.
Servers will probabaly construct a new document for each query, using
MIME's external reference feature where possible to avoid copying
large data files.

best wishes

From davis@dri.cornell.edu  Fri Oct 16 17:14:43 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13650; Fri, 16 Oct 92 17:14:43 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09819; Fri, 16 Oct 92 17:15:32 +0100
Received: by willow.tc.cornell.edu id AA06356
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 16 Oct 1992 12:14:34 -0400
Date: Fri, 16 Oct 1992 12:14:34 -0400
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199210161614.AA06356@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: document caching
Cc: wei@xcf.berkeley.edu

There is something in WWW and/or Viola that I don't understand.
It seems to me that Viola (or WWW) is keeping a cache of
all documents so as to avoid needing to retrieve the same
thing again.  But this is a problem when I am either
 1) actively editing the documents
 2) the documents are dynamic - e.g. computed by a server.
In the latter case I dont want to see the cached version, I
want to see the most recent version. 

Or at least I want a way to flush Viola's cache.

From emv@garnet.msen.com  Fri Oct 16 17:32:10 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13800; Fri, 16 Oct 92 17:32:10 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11601; Fri, 16 Oct 92 17:32:49 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mfuau-00007mC@garnet.msen.com>; Fri, 16 Oct 92 12:31 WET DST
Message-Id: <m0mfuau-00007mC@garnet.msen.com>
To: Jim Davis <davis@dri.cornell.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: non-text documents 
In-Reply-To: Your message of Fri, 16 Oct 92 12:11:46.
             <199210161611.AA06348@willow.tc.cornell.edu> 
Date: Fri, 16 Oct 92 12:31:53 EDT
From: Edward Vielmetti <emv@msen.com>

WWW already supports gateways to two protocols that support typed
links - both WAIS and gopher are capable without too much twisting to
encode the document format in with the access to the file.  (I don't
know if the current WWW libraries will support these links.)

I'm trying to think of gopher servers that have a lot of images in
them that you can play with but I come up blank...

--Ed

From putz@parc.xerox.com  Fri Oct 16 19:12:41 1992
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14334; Fri, 16 Oct 92 19:12:41 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19264; Fri, 16 Oct 92 19:13:31 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <12225>; Fri, 16 Oct 1992 11:12:30 PDT
Received: by spoggles.parc.xerox.com id <58401>; Fri, 16 Oct 1992 11:12:23 -0700
Date: 	Fri, 16 Oct 1992 11:12:04 PDT
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: document caching
In-Reply-To: <199210161614.AA06356@willow.tc.cornell.edu>
To: Jim Davis <davis@dri.cornell.edu>
Cc: www-talk@nxoc01.cern.ch
Message-Id: <92Oct16.111223pdt.58401@spoggles.parc.xerox.com>

A work-around for Viola is to click on the document title bar (the area immediately above the document text).  this forces a new retrieval.

-- Steve Putz

From connolly@pixel.convex.com  Fri Oct 16 20:29:37 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14807; Fri, 16 Oct 92 20:29:37 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23927; Fri, 16 Oct 92 20:30:12 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA06628; Fri, 16 Oct 92 14:29:27 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA21965; Fri, 16 Oct 92 14:29:24 -0500
Message-Id: <9210161929.AA21965@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Cc: Jim Davis <davis@dri.cornell.edu>
Subject: Re: non-text documents
In-Reply-To: Your message of "Fri, 16 Oct 92 12:11:46 EDT."
             <199210161611.AA06348@willow.tc.cornell.edu> 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="8<"
Date: Fri, 16 Oct 92 14:29:23 CDT
From: Dan Connolly <connolly@pixel.convex.com>


--8<

>Can you tell us when WWW and Viola will support non-text
>documents?  I would very much like to be able to return
>pictures including Postscript.  I know this has been discussed
>in the past.

That discussion in the past never really went anywhere. I'm going
over my suggestions, and I'd like to summarize them here and solicit
support.

If we use the semantics of the MIME body part to define a WWW
document, many of these issues have straightforward solutions, and
there is hope of interoperating with other MIME compliant systems.
For example, I also hope WAIS and gopher will use the MIME typing
system.

This means every document has an associated Content-Type and
Content-Transfer-Encoding. The MIME RFC defines content types for
text, image, audio, video, and application data, and two encapsulation
types message and multipart. Text, GIF, postscript, and several other
commonly used data formats are mentioned in the standard. And there is
a well-defined method for adding formats to MIME.

It does _not_ mean that all 8-bit data has to be base64 encoded. 8bit
is a perfectly valid Content-Transfer-Encoding, if you're using FTP or
WAIS or some other 8-bit-clean transport mechanism. But if you're
using email or HTTP, base64 solves the issue quite neatly.

Nor does it mean that all documents look like RFC-822 messages.
Messages is one _type_ of MIME body part. The text/plain type covers
plain text documents. Image/gif is good for lots of pictures.
Application/postscript covers printer-ready stuff. Unknown data can be
tagged application/octet-stream. And you can use types starting with
"x-" for experimental private types.


WWW should use typed links, either implicitly or explicitly. For example,
client software can infer the type of a link to a USENET news article
to be message/rfc-822. But it should not assume that a link to a file
on an FTP server is text! That link should include the type of the
data so that the client software can process it intelligently. There's
already quite a bit of this going on in the WWW browser code. The MIME
semantics are just a way to formalize it with the possibility of
interoperating with other systems.

For example, if an anchor that points to a postscript format document
should look like:

<A href="http://info.cern.ch/hypertext/foo.ps"
type="application/postscript"> here is a postscript file.</A>

I wrote a proposal to recast the whole syntax of URLs so that the
above sample would look more like:

<A><HTTP host="info.cern.ch" path="hypertext/foo.ps"
         type="application" subtype="postscript">
here is a postscript file.</A>

The ideas is that we've already got some sort of SGML parser: why not
let it do the work of parsing the URL too? We could use SGML features
for certain semantics; we could use the SGML numeric character entity
reference (&#123;) in stead of the %FF quoting scheme, and we could
use attribute default values to infer type, subtype, and other
attributes.

I also think we should have optional identity information in the
links. This allows clients to determine whether two links point to the
same information. For example, someone might extend some FTP an WAIS
servers to return the MD5 signature of documents. Then a client could
conclude (with some very high probability) that

<ftp host="cs.utexas.edu" path="contrib" name="x.tar.Z" md5="abcdef">

and

<wais host="quake.think.com" database="software" path="x-2.1.tar.Z"
  md5="abcdef">

refer to the same release of the package.

Thoughts?

Dan

p.s. I've attached the MIME RFC below. If you've got a MIME mail UA,
it should be able to bring up the text. If not, there's enough info
for you to ftp the thing manually.

--8<
Content-Description: RFC1341 MIME  (Multipurpose Internet Mail Extensions)
Content-Type: message/external-body;
	access-type=anon-ftp;
	site="thumper.bellcore.com";
	dir="pub/nsb";
	name="BodyFormats.txt";
	size=214081

Content-Type: text/plain


--8<--

From joe@athena.mit.edu  Sun Oct 18 13:01:17 1992
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18494; Sun, 18 Oct 92 13:01:17 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA08330; Sun, 18 Oct 92 13:02:11 +0100
Received: from LUBEC.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA01325; Sun, 18 Oct 92 07:59:25 EDT
From: joe@athena.mit.edu
Received: by lubec.MIT.EDU (5.61/4.7) id AA11474; Sun, 18 Oct 92 07:59:19 -0400
Date: Sun, 18 Oct 92 07:59:19 -0400
Message-Id: <9210181159.AA11474@lubec.MIT.EDU>
To: tk-www@athena.mit.edu
Cc: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch,
        tcl-archive@barkley.berkeley.edu
Subject: Announcing tkWWW release 0.4


tkWWW Version 0.4 alpha (joe@athena.mit.edu)
--------------------------------------------

WHAT IS THIS?
-------------
World Wide Web (WWW) is a hypertext project which seeks to build a
world wide network of hypertext links.  There are several different
browsers for this system including a simple tty interface.  For a 
demo of the terminal browsers for WWW, telnet to the following sites:

 telnet info.cern.ch or telnet 128.141.201.74 (SWISS)
 telnet eies2.njit.edu or telnet 128.235.1.43 (USA [NJ])
 telnet vms.huji.ac.il or telnet 128.139.4.3  (ISRAEL)
 telnet info.funet.fi or telnet 128.214.6.100 (FINLAND)

 and login as "www"

Tk is an interpreted toolkit which allows one to build X11 applications
quickly and easily.

tkWWW is a Tk interface to (WWW), which lets you send embedded buttons,
scrollbars, etc in hypertext written for WWW.

The Tk browser has the following advantages.

1. Since the entire user interface is written in an interpreted 
   language, it should be very easy to make modifications and extensions
   to the system.

2. More important, it is possible to imbed Tk code into hypertext
   documents.  Start up the intro demo files to see the use of this.

WHERE IS THIS?
--------------
tkWWW 0.4 can be anon ftp'ed from
   export.lcs.mit.edu:/contrib/tkWWW-0.4.tar.Z
   barkley.berkeley.edu:/tcl/extensions/tkWWW-0.4.tar.Z
   info.cern.ch:/pub/WWW/src/tkWWW-0.4.tar.Z

IMPROVEMENTS SINCE 0.3
----------------------
MUCH easier installation procedure 
  (if you gave up trying to install 0.3, you might try again with this)
Better default color scheme
Keyboard traversals
History mechanism
Does the right thing DVI and graphics files
Bug fixes

MAILING LIST
------------
There is a mailing list devoted to discussions about tkWWW at 
 
   tk-www@athena.mit.edu

To get on this list, send e-mail to

   tk-www-request@athena.mit.edu

INSTALLATION
------------
The installation procedure has been simplified greatly from version
0.3.  To install this version, you will need only the libraries for 
tk 2.3 which can be anon ftp'ed from sprite.berkeley.edu

1. Edit the file TkWWW/tkWWW.imake and TkWWW/Tcl/config.tcl

2. Type the following commands in the directory TkWWW

    xmkmf
    make world
    make install

3. Run tkWWW and enjoy

WARNING
-------
With tkWWW, you can send imbedded tk commands to the interpreter.
There are lots of security implications of this.  I've tried to get
rid of the most obvious security loopholes but doubtless many remain.
Use at your own risk.


From connolly@pixel.convex.com  Thu Oct 22 02:11:16 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07854; Thu, 22 Oct 92 02:11:16 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28764; Thu, 22 Oct 92 02:11:01 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA07818; Wed, 21 Oct 92 20:09:55 -0500
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA02869; Wed, 21 Oct 92 20:09:36 -0500
Message-Id: <9210220109.AA02869@pixel.convex.com>
To: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch
Cc: nsb@bellcore.com
Subject: misconceptions about MIME [long]
Summary: MIME body != MIME message, MIME is for 8bit systems too
Content-Type: multipart/mixed; boundary="cut"
Date: Wed, 21 Oct 92 20:09:36 CDT
From: Dan Connolly <connolly@pixel.convex.com>

--cut

I wrote an article a while back called "MIME for global hypertext." It
was about a world where all the information tools on the internet
interoperated, with MIME as the substrate. Since then, I've got a few
words of support, but none from the important people. It seems that
many people have taken a cursory look at MIME and dismissed it as only
relevant to email.


	BODY PARTS AND MESSAGES

There are two misconceptions about MIME that show up frequently in
response to my suggestions. The first is the confusion between a MIME
body part and MIME message.

A MIME body part is just a sequence of bytes with an associated
content-type and content-transfer-encoding -- much like a C variable
is just a piece of memory with an associated type. The default MIME
content-type is text/plain, i.e. a sequence of lines of text.

So all the text files out there in the world already fit the role of a
MIME body part. They don't need any headers, encodings, or anything.
In fact, all the non text files qualify as MIME body parts too, if we
associate them with the application/octet-stream content-type and the
binary content-transfer-encoding.

A MIME message is actually a special case of the body part concept.
Along with the text/plain, image/gif, audio/basic,
application/postscript etc. types, there's a message/rfc-822 type.
That's where the headers and stuff come in.

There's also a multipart/mixed type that encapsulates several body
parts into one. It has some syntax that a lot of folks aren't crazy
about, but it's just _one_type_ of body part.


	EIGHT BIT DATA, ENCODINGS, AND TRANSPORT

The other area of confusion concerns eight bit data. MIME provides
mechanisms for transport of eight bit data across mail transport
agents that only grok limited character sets and line lengths. These
mechanisms obviously increase the size of messages.

But when used with 8-bit-clean transport mechanisms, the encodings are
not necessary, and MIME adds no cost to data transport. From the RFC:

	As of the publication of this document, there are no
	standardized Internet transports for which it is legitimate
        to include unencoded 8-bit or binary data in mail bodies.
        Thus there are no circumstances in which the "8bit" or "binary"
        Content-Transfer-Encoding is actually legal on the Internet.
        However, in the event that 8-bit or binary mail transport
        becomes a reality in Internet mail, or when this document
                                            ^^^^^^^^^^^^^^^^^^^^^
        is used in conjunction with any other 8-bit or binary-capable
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        transport mechanism, 8-bit or binary messages should be labeled
        ^^^^^^^^^^^^^^^^^^^
        as such using this mechanism.

That is, the MIME standard suggests that 8-bit data be labelled as
such, so that gateways between 8-bit and 7-bit systems can recognize
and encode such data.

For example: a WAIS<->email gatway might retrieve a GIF image from a
WAIS server. If the WAIS server stated that the data is type image/gif
and binary encoded, the gateway could base64 encode the data and send
it on its way through SMTP. On the other hand, if the server labelled
the data 7bit text/plain, the gateway could pass it along without
encoding.


	GOPHER SUPPORT FOR MIME

Gopher defines several types of "objects." The basic types are text
files and directories. Other types include various archive formats,
telnet sessions, CSO servers, raw data files, and a few experimental
types.

One of the experimental types is 'M' for MIME messages, that is body
parts of type message/rfc-822. I suppose that much of the opposition
to using the MIME body part to model the Gopher object comes from
folks who think that they'd have to put all their data into
message/rfc-822 format.

But I didn't suggest we use the MIME message/rfc-822 format for all
Gopher objects: just use _some_ MIME format for all gopher objects.
The fact is, their data is already in a MIME format: text/plain. And
the experimental 'g' (GIF) type is already a MIME type: image/gif.

The only Gopher objects that don't fit the MIME system are the ones
that are not data streams at all: telnet sessions, CSO servers, etc. I
don't know how (or if) they fit into the MIME model.

There are some Gopher objects that fit the MIME model but are not part
of the MIME standard (yet). For example, the directory listing that
gopher servers send back could be called application/x-gopher for now,
and eventually application/gopher (when it's spec'd out and registered
with the IANA.)

The gopher protocol can be enhanced one time to support the myriad of
multimedia data formats by including a content-type field in gopher
listings.

The Gopher+ protocol has even more in common with MIME. In Gopher+,
each gopher object has a bunch of ancillary information such as the
maintainer, size, format, etc. A Gopher+ object and its ATTRIBUTES
looks an awful lot like a MIME body part and it's encapsulating
message. It seems a waste to define two competing standards for the
same mechanisms.


	WAIS SUPPORT FOR MIME

A WAIS document looks like a MIME body part too: a sequence of bytes
with a type. The canonical WAIS type is TEXT. And like the type 'M'
support in gopher, somebody hacked in support for a MIME type in WAIS.

Again, I suggest that the MIME typing system be used in stead of,
rather than inside, the WAIS typing system. That is, modify the
Document-id Structure Definition so that

:type <string>

is obsoleted by 

:content-type <string> ;; as defined by RFC-1341

The only two supported types are TEXT and SRC, whic translate neatly
to text/plain and application/x-wais-src.


	WWW SUPPORT FOR MIME

There was a question on www-talk about non-text data in WWW documents.
It seems clear that using MIME body parts to model WWW documents is a
natural step.

The notion of a WWW address should be expanded to what I would call a
reference, which is an address, a content-type, and any identification
information (so that clients can test whether two references point to
the same document.)

The WWW client currently infers the content-type from the address. For
the file: scheme, an .html extension implies HTML format -- other wise
text is assumed. Documents from HTTP servers are HTML, which slams
plain text inside SGML if necessary. Documents from Gopher servers are
either plain text or gopher listings. I don't know what WWW clients do
with WAIS documents that aren't text.


	FROM GLOBAL HYPERTEXT TO GLOBAL HYPERMEDIA

The Internet currently serves as the backbone for a global hypertext.
FTP and email provided a good start, and the gopher, WWW, or WAIS
clients and servers make wide area information browsing simple. These
systems even interoperate, with email servers talking to FTP servers,
WWW clients talking to gopher servers, on and on.

This currently works quite well for text.  But what should WWW clients
do as Gopher and WAIS servers begin to serve up pictures, sounds,
movies, spreadsheet templates, postscript files, etc.? It would be a
shame for each to adopt its own multimedia typing system.

If they all adopt the MIME typing system (and as many other features
from MIME as are appropriate), we can step from global hypertext to
global hypermedia that much easier.


	READ IT YOURSELF

Attached is the text of the MIME RFC. Enjoy.

--cut
Content-Description: RFC1341 MIME  (Multipurpose Internet Mail Extensions)
Content-Type: message/external-body;
        access-type=anon-ftp;
        site="thumper.bellcore.com";
        dir="pub/nsb";
        name="BodyFormats.txt";
        size=214081

Content-Type: text/plain

--cut--

From nsb@thumper.bellcore.com  Thu Oct 22 14:25:25 1992
Return-Path: <nsb@thumper.bellcore.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01397; Thu, 22 Oct 92 14:25:25 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09775; Thu, 22 Oct 92 14:36:57 +0100
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA07296> for www-talk@nxoc01.cern.ch; Thu, 22 Oct 92 09:36:05 EDT
Received: by greenbush.bellcore.com (4.1/4.7)
	id <AA17504> for nsb@bellcore.com; Thu, 22 Oct 92 09:36:03 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
          via MS.5.6.greenbush.galaxy.sun4_41;
          Thu, 22 Oct 1992 09:35:59 -0400 (EDT)
Message-Id: <cetesz_0M2Yt53sZli@thumper.bellcore.com>
Date: Thu, 22 Oct 1992 09:35:59 -0400 (EDT)
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch, Dan Connolly <connolly@pixel.convex.com>
Subject: Re: misconceptions about MIME [long]
Cc: nsb@bellcore.com
In-Reply-To: <9210220109.AA02869@pixel.convex.com>
References: <9210220109.AA02869@pixel.convex.com>

Dan's comments are right on the money.  As an example of how you can
treat non-mail-oriented data as being in MIME format, I've recently
written a script that makes it trivial to set up a MIME-smart mailserver
daemon for, say, everything in your anonymous ftp directory.  This
script -- which will be part of the next metamail release -- accepts
mail requests that give path names relative to the anonymous ftp root,
e.g. "pub/nsb/BodyFormats.txt" and sends the results back as MIME-format
mail.  The neat thing is that the files themselves don't need to be in
MIME format.  The files are assumed to be plain text unless there is a
".ct" file (e.g. "pub/nsb/BodyFormats.txt.ct") in which case that file
is assumed to contain the Content-type information.  Thus if you have a
gif image in file "foo", you can put the text "image/gif" in the file
"foo.ct" and the mailserver will be ready to send the GIF image as
MIME-format mail.  The script is smart enough, using the metamail tools,
to deal with any necessary encoding for mail transport, even though the
raw data is unencoded.

The point is that, as Dan says, the data doesn't need to be explicitly
in MIME format.  MIME body parts are just (possibly encoded) data in
reasonably standard formats.  If you don't enclose it in a mail-ish
thing with a content-type header field, you need some other
"out-of-band" way of providing the type information, but this can be
done in many ways, e.g. the ".ct" files my mailserver uses.  Viewed this
way, all that MIME is really comes down to three things:

1.  A mechanism for encoding arbitrary data for mail transport.  This is
orthogonal to the other parts and can be largely ignored in non-mail
applications.

2.  A mechanism for combining multiple objects in a "multipart" format
defined by MIME.  This doesn't need to be used by non-mail applications,
but a common way of doing this has obvious value.  Why shouldn't
multi-media objects be shared across email, wais, gopher, and www?

3.  A naming convention and a set of standard names for describing data
types such as "image/gif" and "audio/basic".  The common naming
conventions are perhaps the most valuable aspect of MIME for non-mail
applications, as it is pretty obviously silly to give slightly different
names to the same things in different systems.

Anyway, as a principle author of MIME I know I'm not in a great position
to appear to be objective, but I really don't see any good reasons not
to use MIME in applicaitons such as gopher, wais, or www.  -- Nathaniel

From NED@sigurd.innosoft.com  Fri Oct 23 09:48:45 1992
Return-Path: <NED@sigurd.innosoft.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08243; Fri, 23 Oct 92 09:48:45 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12187; Fri, 23 Oct 92 06:40:47 +0100
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF #1339 ) id
 <01GQ9KR9KTOA9D4EDD@SIGURD.INNOSOFT.COM>; Thu, 22 Oct 1992 22:39:35 PDT
Date: 22 Oct 1992 22:39:33 -0700 (PDT)
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: misconceptions about MIME [long]
To: nsb@thumper.bellcore.com
Cc: nsb@thumper.bellcore.com, masinter@parc.xerox.com,
        gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
        connolly@pixel.convex.com, NED@sigurd.innosoft.com,
        www-talk@nxoc01.cern.ch
Message-Id: <01GQ9KR9LCZ09D4EDD@SIGURD.INNOSOFT.COM>
X-Vms-To: IN%"nsb@thumper.bellcore.com"
X-Vms-Cc: 
 IN%"nsb@thumper.bellcore.com",IN%"masinter@parc.xerox.com",IN%"gopher@boombox.micro.umn.edu",
 IN%"wais-talk@quake.think.com",IN%"connolly@pixel.convex.com",IN%NED,IN%"www-talk@nxoc01.cern.ch"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Nathaniel was kind enough to forward your message to me.

> I recall being flamed rather severely by Ned Freed when I suggested
> that MIME was inadequate because the specification of format-types
> such as 'postscript' or 'gif' didn't specify enough about format
> versions, external resources used, etc.

The flaming, if you wish to call it that, was caused by what I saw as a
repeated failure on your part to read the words I was writing. I certainly did
not flame you because of this idea. It isn't a bad idea on the surface; it only
falls apart upon close examination.

>  Many of his arguments were based on the practical difficulties of
> requiring any kind of additional standardization for document format
> versions in a distributed mail application.

My position regarding PostScript is based on three facts:

(1) Mechanisms already exist for imbedding all this information inside
    PostScript objects. This format is readily understandable and easy to
    process.

(2) Generation of this information if it isn't already in a given object isn't
    just hard, it is totally and completely impossible. It is trivial to
    demonstrate that this is equivalent to the halting problem. The notion
    that something "close" the correct could be generated with a little work is
    highly suspect, as are the advantages of producing external labelling that's
    guaranteed to be inaccurate in some cases.

(3) When the external information <> internal information you have a silly
    state. A guiding principle of the working group was to avoid silly
    states whenever possible.

Modulo the notion in (2) these are all facts and not opinions. Based on these
facts I think external format labelling of PostScript is an extremely bad idea.

I am much less familiar with GIF and I have relied on other folks who are
more expert than I to deal with GIF issues.

> Now that MIME is out as a proposal for mail, I still believe that
> these problems should be addressed before MIME is appropriate for
> database, archival and retrieval applications.

As far as PostScript goes I think I have made my position clear. It has not
changed in any way since we last communicated. However, my position on
PostScript does not necessarily apply to other formats. Each format is a
separate beast and must be handled in a manner that matches its nature. Just
because I am opposed to external labelling of PostScript doesn't mean external
labelling of something else is inappropriate. It usually boils down to
examination of three issues:

(1) Is internal labelling feasible? If feasible do applications actually use it?

(2) How hard is it to derive external label information? There are basically
    three possibilities: it is either something you just have to know (like
    the character set), it is always part of the object (like WordPerfect
    version numbers), or it can be produced from analysis of the input.

(3) Is there potential for conflict between internal and external labelling?

The interactions between these things is complex; I have never derived an
explicit cause-and-effect path from these to whether or not an external
label should be used.

> In addition, the current mechanism in MIME for external references suffers the
> same problem that other references mechanisms that are based on
> hostname/pathname have: files move, change in place, host names come and go
> over the years.

I certainly agree that this is a problem. I would love to see it solved, and I
would welcome the introduction of additional parameters to solve it.

However, I don't see any way to solve it without introducing at least one
additional level of indirection. This means some kind of directory service
would have to be deployed. Now, this may be a good idea, in fact it may be a
terrific idea, but it is somewhat beyond MIME's purview to define a directory
service for locating objects.

In other words, I believe the solution to this problem would at a minimum
involve the introduction of some kind of directory service (which could be
accessed via MIME messages but in practice would probably require a direct
protocol connection) and the definition of a new sort of external reference
with parameters appropriate for reaching this service. The difficult parts of
this are the methods you use in the directory to keep existing pointers valid
and the definition of the directory access protocol itself. The extensions to
MIME are the trivial part.

I would welcome further discussion on how we should work towards solving
these problems.

> Both these problems are not trival to solve, but I don't think they
> are unsolvable.

They are extremely difficult problems to solve. However, the first step towards
their solution is to focus on where the problems really are, and I don't think
that's MIME.

				Ned

From alberti@boombox.micro.umn.edu  Fri Oct 23 10:42:29 1992
Return-Path: <alberti@boombox.micro.umn.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08359; Fri, 23 Oct 92 10:42:29 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14351; Thu, 22 Oct 92 21:09:51 +0100
Received: from boombox.micro.umn.edu by mail.unet.umn.edu (5.65c/)
	id AA21084; Thu, 22 Oct 1992 15:08:56 -0500
Received: from eagles.micro.umn.edu by boombox.micro.umn.edu; Thu, 22 Oct 92 15:25:16 CDT
From: "Bob Alberti" <alberti@boombox.micro.umn.edu>
Date: Thu, 22 Oct 92 14:25:39 CST
Message-Id: <51941.alberti@boombox.micro.umn.edu>
X-Popmail-Charset: English
To: nsb@thumper.bellcore.com
Cc: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch, connolly@pixel.convex.com, ned@innosoft.com
Subject: Re: misconceptions about MIME [long]

     Could this argument be taken to a Newsgroup or restricted to a MIME 
mailing list?  Does everyone need to follow it (possibly multiple times) in 
their mailboxes?  Thanks.
-----------------------------------------------------------
Bob Alberti                                       Albatross
U of MN CIS "Team Gopher"                    Metropolis BBS
alberti@boombox.micro.umn.edu                (612) 721-7052                   
Contents: 30% header, 30% quote, 10% content, 30% signature

From emv@garnet.msen.com  Fri Oct 23 10:47:43 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09703; Fri, 23 Oct 92 10:47:43 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA08416; Thu, 22 Oct 92 20:06:37 +0100
Received: from garnet.msen.com by mcsun.EU.net with SMTP
	id AA27631 (5.65b/CWI-2.182); Thu, 22 Oct 1992 20:05:51 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mi7no-00007jC@garnet.msen.com>; Thu, 22 Oct 92 15:02 WET DST
Message-Id: <m0mi7no-00007jC@garnet.msen.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: nsb@thumper.bellcore.com, gopher@boombox.micro.umn.edu,
        wais-talk@quake.think.com, www-talk@nxoc01.cern.ch,
        connolly@pixel.convex.com, nsb@bellcore.com
Subject: Re: misconceptions about MIME [long] 
In-Reply-To: Your message of Thu, 22 Oct 92 11:30:46.
             <92Oct22.113048pdt.101795@poplar.parc.xerox.com> 
Date: Thu, 22 Oct 92 15:02:21 EDT
From: Edward Vielmetti <emv@msen.com>

documents are going to move around on the nets, indefinitely, so long
as they are all "free".  As soon as you give people the opportunity to
sell things (to exchange money in exchange for goods) you will be
quite sure that people will construct document identifiers that do not
move around.

The Sears catalog numbers don't change from week to week cause Sears
has proper incentives for making them work.

--Ed

From nsb@thumper.bellcore.com  Fri Oct 23 10:52:42 1992
Return-Path: <nsb@thumper.bellcore.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10984; Fri, 23 Oct 92 10:52:42 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09586; Thu, 22 Oct 92 20:24:09 +0100
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA14510> for www-talk@nxoc01.cern.ch; Thu, 22 Oct 92 15:23:11 EDT
Received: by greenbush.bellcore.com (4.1/4.7)
	id <AA18177> for ned@innosoft.com; Thu, 22 Oct 92 15:23:10 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
          via MS.5.6.greenbush.galaxy.sun4_41;
          Thu, 22 Oct 1992 15:23:05 -0400 (EDT)
Message-Id: <0etjyNa0M2Yt56y3N_@thumper.bellcore.com>
Date: Thu, 22 Oct 1992 15:23:05 -0400 (EDT)
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: misconceptions about MIME [long]
Cc: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch, connolly@pixel.convex.com,
        Ned Freed <ned@innosoft.com>
In-Reply-To: <92Oct22.113048pdt.101795@poplar.parc.xerox.com>
References: <92Oct22.113048pdt.101795@poplar.parc.xerox.com>

I think Ned (who I just added to the growing distribution list on this
exchange!)'s argument was that formats such as Postscript and Gif have
developed or are developing ways of specifying such things IN-band, that
is, in the actual data stream itself rather than in an out-of-band
location such as the MIME content-type header.  Insofar as this is true,
I think it makes much more sense NOT to further complicate matters by
introducing a way to specify these matters out-of-band.  In other words,
including information in a place like the MIME Content-type header
should only be done if there's no way for including the information in
part of the actual data, that is, the MIME body part.  I think that's
the essential philosophy behind that choice, at any rate.  -- Nathaniel


From masinter@parc.xerox.com  Fri Oct 23 10:57:03 1992
Return-Path: <masinter@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12107; Fri, 23 Oct 92 10:57:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28839; Thu, 22 Oct 92 19:32:16 +0100
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11774>; Thu, 22 Oct 1992 11:31:04 PDT
Received: by poplar.parc.xerox.com id <101795>; Thu, 22 Oct 1992 11:30:48 -0700
To: nsb@thumper.bellcore.com
Cc: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch, connolly@pixel.convex.com, nsb@bellcore.com
In-Reply-To: Nathaniel Borenstein's message of Thu, 22 Oct 1992 06:35:59 -0700 <cetesz_0M2Yt53sZli@thumper.bellcore.com>
Subject: Re: misconceptions about MIME [long]
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <92Oct22.113048pdt.101795@poplar.parc.xerox.com>
Date: 	Thu, 22 Oct 1992 11:30:46 PDT

I recall being flamed rather severely by Ned Freed when I suggested
that MIME was inadequate because the specification of format-types
such as 'postscript' or 'gif' didn't specify enough about format
versions, external resources used, etc.

Many of his arguments were based on the practical difficulties of
requiring any kind of additional standardization for document format
versions in a distributed mail application.

Now that MIME is out as a proposal for mail, I still believe that
these problems should be addressed before MIME is appropriate for
database, archival and retrieval applications. In addition, the
current mechanism in MIME for external references suffers the same
problem that other references mechanisms that are based on
hostname/pathname have: files move, change in place, host names come
and go over the years.

Both these problems are not trival to solve, but I don't think they
are unsolvable.

From rik@daneel.rdt.monash.edu.au  Fri Oct 23 11:42:40 1992
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11463; Fri, 23 Oct 92 11:42:40 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24446; Fri, 23 Oct 92 11:54:08 +0100
Received: from daneel.rdt.monash.edu.au by mcsun.EU.net with SMTP
	id AA11276 (5.65b/CWI-2.182); Fri, 23 Oct 1992 11:52:37 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA03886; Fri, 23 Oct 92 20:51:07 +1000
Message-Id: <9210231051.AA03886@daneel.rdt.monash.edu.au>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Man pages server code, anyone? 
In-Reply-To: Your message of "28 Sep 92 13:40:33 +0100."
             <9209281240.AA04048@ nxoc01.cern.ch > 
Date: Fri, 23 Oct 92 20:51:06 -1000
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

Almost a month ago, Tim wrote:
> I know I heard of someone with a filter for unix man page to HTML,
> but I can't find it.  Does anyone on this list write one?

OK, I finally have a reasonably nice-looking man converter.  It does
the following things:

* puts section headings in <H2> </H2>'s.
* formats paragraphs with <P>.
* does some special characters.
* hypertext links for references to other manual pages.
* some <HP?> highlighting.

Current problems:

* it's not lightning fast.
* doesn't handle tbl correctly yet.
* it would be nice to put some things in a <DL> type list.
* many of the special characters missing.
* it does some strange spacing sometimes.

The filter is in a number of parts.  The first part is written in perl,
and parses the man page names and gets a list of filenames, which it
pipes to groff.  I have built a special groff filter in perl for the
second part.  This filter takes the groff device-independent intermediate
output, and converts it to HTML.

The code's not too bad, but could do with a bit of cleaning-up,
particularly the tbl handling.  You can play with the filter by connecting
to:

  http://www.vifp.monash.edu.au:5000/MANPAGE

where MANPAGE can just be a name, like 'cat', or it can be a name and
section, like 'cos(3m)'.

Please tell me if you notice anything strange, and I will attempt to
fix it.  I'll give the code to people if they really want it, but as I said
before, I hope to clean it up a little before I release it more
generally.  To run the code, you need groff and perl and you need to be
able to install new drivers for groff (I think there's an option for
groff to look in a different directory for drivers).

This is part of our local help/documentation system, which will
eventually be complete, changing documentation for our computer
systems.  I essentially wanted to be able to direct people to the man
pages when necessary, and I thought it pointless to have man pages if
you couldn't just click on the "See Also"'s  :-)

Have fun, and let me know what you think.

rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au         || Systems Programmer
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH) || and Administrator
Faculty of Computing and Information Technology,   || Vic. Institute of
Caulfield Campus, Monash University, Australia     || Forensic Pathology

From dagenais@wotan.vlsi.polymtl.ca  Mon Oct 26 14:52:14 1992
Return-Path: <dagenais@wotan.vlsi.polymtl.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00422; Mon, 26 Oct 92 14:52:14 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12963; Mon, 26 Oct 92 15:04:03 +0100
Received: from vlsi.polymtl.ca by charles.cdec.polymtl.ca (AIX 3.1/UCB 5.61/4.04)
          id AA04560; Mon, 26 Oct 92 10:03:21 -0500
Received: from  pollux.vlsi.polymtl.ca (pollux.vlsi.polymtl.ca) by wotan.vlsi.polymtl.ca (4.1/SMI-4.1)
	id AA27730; Mon, 26 Oct 92 08:58:49 EST
Date: Mon, 26 Oct 92 08:58:49 EST
From: dagenais@vlsi.polymtl.ca (Michel Dagenais)
Message-Id: <9210261358.AA27730@wotan.vlsi.polymtl.ca>
Received: by  pollux.vlsi.polymtl.ca (4.1/SMI-4.0)
	id AA04079; Mon, 26 Oct 92 09:09:10 EST
To: rik@daneel.rdt.monash.edu.au
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Rik Harris's message of Fri, 23 Oct 92 20:51:06 -1000 <9210231051.AA03886@daneel.rdt.monash.edu.au>
Subject: Man pages server code, anyone? 

> > I know I heard of someone with a filter for unix man page to HTML,
> > but I can't find it.  Does anyone on this list write one?
>
> OK, I finally have a reasonably nice-looking man converter.  It does
> the following things:

How about GNU info files. I would love to integrate these into
the user information database along with the man pages.

From evas@cs.few.eur.nl  Mon Oct 26 15:13:28 1992
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00563; Mon, 26 Oct 92 15:13:28 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15032; Mon, 26 Oct 92 15:25:19 +0100
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA04309; Mon, 26 Oct 92 15:24:29 +0100
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA22167; Mon, 26 Oct 92 15:24:24 +0100
Date: Mon, 26 Oct 92 15:24:24 +0100
Message-Id: <9210261424.AA22167@slc01.cs.few.eur.nl>
To: dagenais@vlsi.polymtl.ca
Subject: Re: Man pages server code, anyone?
Cc: www-talk@nxoc01.cern.ch


> How about GNU info files. I would love to integrate these into
> the user information database along with the man pages.

I've done this a while ago; check ftp.cs.few.eur.nl, directory pub/www.
There is a patch for the 4.0 HTTP daemon and two filters that are
called from the daemon to convert GNU info (info2html) and formatted
man pages (man2html) to HTML format. The syntax of the httpd 
configuration file has been extended with a 'convert' line, for
example:
	convert	info	/usr/local/lib/WWW/bin/info2html

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands

From evas@cs.few.eur.nl  Mon Oct 26 15:18:31 1992
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00600; Mon, 26 Oct 92 15:18:31 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15456; Mon, 26 Oct 92 15:30:18 +0100
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA04720; Mon, 26 Oct 92 15:29:24 +0100
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA22177; Mon, 26 Oct 92 15:29:20 +0100
Date: Mon, 26 Oct 92 15:29:20 +0100
Message-Id: <9210261429.AA22177@slc01.cs.few.eur.nl>
To: www-talk@nxoc01.cern.ch
Subject: Re: Man pages server code, anyone?


> How about GNU info files. I would love to integrate these into
> the user information database along with the man pages.

I've done this a while ago; check ftp.cs.few.eur.nl, directory pub/www.
There is a patch for the 4.0 HTTP daemon and two filters that are
called from the daemon to convert GNU info (info2html) and formatted
man pages (man2html) to HTML format. The syntax of the httpd 
configuration file has been extended with a 'convert' line, for
example:
	convert	info	/usr/local/lib/WWW/bin/info2html

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands

From masinter@parc.xerox.com  Tue Oct 27 23:27:48 1992
Return-Path: <masinter@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08676; Tue, 27 Oct 92 23:27:48 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AB24654; Tue, 27 Oct 92 23:39:48 +0100
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11859>; Tue, 27 Oct 1992 14:38:36 PST
Received: by poplar.parc.xerox.com id <101795>; Tue, 27 Oct 1992 14:38:29 -0800
To: NED@sigurd.innosoft.com
Cc: nsb@thumper.bellcore.com, wais-talk@quake.think.com,
        connolly@pixel.convex.com, www-talk@nxoc01.cern.ch
In-Reply-To: Ned Freed's message of Thu, 22 Oct 1992 22:39:33 -0700 <01GQ9KR9LCZ09D4EDD@SIGURD.INNOSOFT.COM>
Subject: Re: misconceptions about MIME [long]
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <92Oct27.143829pst.101795@poplar.parc.xerox.com>
Date: 	Tue, 27 Oct 1992 14:38:18 PST

I no longer know what forum to address this to, I suppose we've been
asked to remove the discussion from 'gopher@boombox.micro.umn.edu'.

The arguments that in-band designation of document format is better
than out-of-band information may apply in the electronic mail
scenarios, where there is a single sender, multiple recipients, and
the recipient has no control over what the sender might send.

Instead, imagine, if you would, another scenario, of a WAIS or Web or
anonymous FTP archive, which wishes to make available the latest
version of the MIME specification. Let us suppose, in addition, that
the publishing service has three different representations of the
document, one marked "MIME rich-text", one marked "postscript", and
one NetFax.  Furthermore, let us suppose (as has been proposed) that
the document types are marked by their MIME Content-type header
designation.

If I wish to retrieve the document, say to view it, I might want to
choose the available representation that is most appropriate for my
purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
from an anonymous FTP archive, only to discover that it is in the
newly announced Postscript level 4 format, or to try to edit it only
to discover that it is in the (upwardly compatible but not parsable by
my client) version 44 of Rich Text. In each case, the appropriateness
of alternate sources and representations of a document would depend on
information that is currently only available in-band.

I believe that MIME was developed in the context of electronic mail,
but that the usage patterns in space and time of archives, database
services and the like require more careful attention (a) to
out-of-band information about format versions, so that you might know,
before you retrieve a representation, whether you have the capability
of coping with it, and (b) some restriction on those formats which
might otherwise be uncontrollable.

Finally, as much as I've tried to resist, I'll characterize your
description of my response as 'repeated failure on your part to read
the words I was writing' as 'inflammatory hogwash'.

From connolly@pixel.convex.com  Tue Oct 27 23:52:34 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08791; Tue, 27 Oct 92 23:52:34 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25865; Wed, 28 Oct 92 00:04:34 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA23359; Tue, 27 Oct 92 17:03:46 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA18485; Tue, 27 Oct 92 17:03:41 -0600
Message-Id: <9210272303.AA18485@pixel.convex.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: NED@sigurd.innosoft.com, nsb@thumper.bellcore.com,
        wais-talk@quake.think.com, www-talk@nxoc01.cern.ch
Subject: Re: misconceptions about MIME [long] 
In-Reply-To: Your message of "Tue, 27 Oct 92 14:38:18 PST."
             <92Oct27.143829pst.101795@poplar.parc.xerox.com> 
Date: Tue, 27 Oct 92 17:03:40 CST
From: Dan Connolly <connolly@pixel.convex.com>


>If I wish to retrieve the document, say to view it, I might want to
>choose the available representation that is most appropriate for my
>purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
>from an anonymous FTP archive, only to discover that it is in the
>newly announced Postscript level 4 format, or to try to edit it only
>to discover that it is in the (upwardly compatible but not parsable by
>my client) version 44 of Rich Text. In each case, the appropriateness
>of alternate sources and representations of a document would depend on
>information that is currently only available in-band.

What methodology do you propose to prevent this situation? It looks
like a very hard problem indeed. But MIME makes a good stab at
standardizing practices that are going on now. I think we can prevent
further divergence in the CSCW and global hypermedia communities
by adopting MIME now.

In short: I think MIME will not completely solve the problem you
stated, but it _will_ do more good than harm.


>I believe that MIME was developed in the context of electronic mail,
>but that the usage patterns in space and time of archives, database
>services and the like require more careful attention (a) to
>out-of-band information about format versions, so that you might know,
>before you retrieve a representation, whether you have the capability
>of coping with it, and (b) some restriction on those formats which
>might otherwise be uncontrollable.

The function you describe in (a) above is commonly known as the
halting problem. No can do. Formats mentioned in (b) are called
turing machines: postscript programs, excel macros, etc. And life
gets only a little easier if you get rid of turing machines.

If I understand you correctly, every document must be annotated
with all of the resources it requires. For example:

* TIFF image. 400x760. 16 colors (pantone #416, #450, #23, ...)
zbar compression. 10k compressed. 160k uncompressed.

* postscript document. A4 page size. Peak virtual memory usage: 2.7mb
on a LaswerWriter IINT. Fonts: courier (4-18pt), times, New Century Schoolbook.

* xwd image. 24 bit direct color image. Requires patch #18 on
the RS/6000 X server.

I think MIME starts to look like a _very_ reasonable level of
standardization given the possible spectrum.

Dan


From masinter@parc.xerox.com  Wed Oct 28 00:32:46 1992
Return-Path: <masinter@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09020; Wed, 28 Oct 92 00:32:46 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29051; Wed, 28 Oct 92 00:44:46 +0100
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11823>; Tue, 27 Oct 1992 15:43:40 PST
Received: by poplar.parc.xerox.com id <101795>; Tue, 27 Oct 1992 15:43:37 -0800
To: connolly@pixel.convex.com
Cc: NED@sigurd.innosoft.com, nsb@thumper.bellcore.com,
        wais-talk@quake.think.com, www-talk@nxoc01.cern.ch
In-Reply-To: Dan Connolly's message of Tue, 27 Oct 1992 15:03:40 -0800 <9210272303.AA18485@pixel.convex.com>
Subject: Re: misconceptions about MIME [long] 
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <92Oct27.154337pst.101795@poplar.parc.xerox.com>
Date: 	Tue, 27 Oct 1992 15:43:32 PST

> What methodology do you propose to prevent this situation?

* TIFF images are frequently restricted by the TIFF class (Class F,
  B, and NetFax) by which recipients. Rather than merely identifying
  the archive as 'tiff' it seems feasible to be more specific.

* If you register a format name, then the name should be linked to a
  well known, published, dated version of the specification of those
  formats, and not to any possible future currently-unspecified even
  if upwardly-compatible extension.  That is, if you insist that the
  format be called 'postscript', then it should be restricted to 
  'postscript' as known at the time of the definition of the standard.
  Perhaps the situation with postscript is hopeless, but it isn't with
  either 'rich text' or 'gif' or a number of 'audio' representations.

Part of the problem is that the very weakness of 'postscript' as an
interchange format is overly influencing your position. It may well be
that carousel will dominate postscript as a printable representation
exactly because Adobe finally is addressing some of the interchange
issues.




From connolly@pixel.convex.com  Wed Oct 28 00:42:47 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09062; Wed, 28 Oct 92 00:42:47 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00481; Wed, 28 Oct 92 00:54:47 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA26114; Tue, 27 Oct 92 17:53:57 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23418; Tue, 27 Oct 92 17:53:56 -0600
Message-Id: <9210272353.AA23418@pixel.convex.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: NED@sigurd.innosoft.com, nsb@thumper.bellcore.com,
        wais-talk@quake.think.com, www-talk@nxoc01.cern.ch
Subject: Re: misconceptions about MIME [long] 
In-Reply-To: Your message of "Tue, 27 Oct 92 15:43:32 PST."
             <92Oct27.154337pst.101795@poplar.parc.xerox.com> 
Date: Tue, 27 Oct 92 17:53:55 CST
From: Dan Connolly <connolly@pixel.convex.com>


>> What methodology do you propose to prevent this situation?
>
>* If you register a format name, then the name should be linked to a
>  well known, published, dated version of the specification of those
>  formats...

You mean like this? from RFC1341:

            7.4.2     The Application/PostScript subtype

            A  Content-Type  of  "application/postscript"  indicates   a
            PostScript    program.    The   language   is   defined   in
            [POSTSCRIPT].

            7.5  The Image Content-Type

            A Content-Type of "image" indicates that the bodycontains an
            image.   The subtype names the specific image format.  These
            names are case insensitive.  Two initial subtypes are "jpeg"
            for the JPEG format, JFIF encoding, and "gif" for GIF format
            [GIF].

...
            [POSTSCRIPT]  Adobe  Systems,  Inc.,   PostScript   Language
            Reference Manual,  Addison-Wesley, 1985.

            [GIF] Graphics Interchange Format (Version 89a), Compuserve,
            Inc., Columbus, Ohio, 1990.

It's tough to keep folks from sticking postscript level-2 stuff in
under the name of application/postscript, but you can't blame
the MIME standard for being ambiguous in any way.

Dan


From dckavan@srv.pacbell.com  Wed Oct 28 00:50:21 1992
Return-Path: <dckavan@srv.pacbell.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09086; Wed, 28 Oct 92 00:50:21 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00621; Wed, 28 Oct 92 01:02:21 +0100
Received: from srv.PacBell.COM (mother.srv.PacBell.COM) by ns.PacBell.COM (4.1/PacBell-10/01/92)
	id AA25793; Tue, 27 Oct 92 16:01:20 PST
Received: from hillary.srv.PacBell.COM by srv.PacBell.COM (4.1/SMI-4.0)
	id AA10342; Tue, 27 Oct 92 16:01:49 PST
Received: by hillary.srv.PacBell.COM (AIX 3.1/UCB 5.61/4.03)
          id AA05614; Tue, 27 Oct 92 16:01:55 -0800
From: dckavan@srv.pacbell.com (Dennis Kavanaugh)
Message-Id: <9210271601.ZM7404@hillary.srv.PacBell.COM>
Date: Tue, 27 Oct 1992 16:01:50 -0800
In-Reply-To: Larry Masinter <masinter@parc.xerox.com>
        "Re: misconceptions about MIME [long]" (Oct 27,  2:38pm)
References: <92Oct27.143829pst.101795@poplar.parc.xerox.com>
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: Larry Masinter <masinter@parc.xerox.com>, NED@sigurd.innosoft.com
Subject: Re: misconceptions about MIME [long]
Cc: nsb@thumper.bellcore.com, wais-talk@quake.think.com,
        connolly@pixel.convex.com, www-talk@nxoc01.cern.ch

This conversation is just a trifle intimidating, but here goes...

I believe some good points are being made here, but not all which can be
associated with a single 'technology', i.e. MIME or WAIS. I believe this is
the natural product of trying to get 'mail' to be all things to all
applications.

Mail as a transport  for information versus mail as the characteristic of
information is what I believe to be partly to blame. When I receive mail (the
characteristic stuff), I may have little control over the content-type, and
therefore may have to take what I get. On the other hand, when I am using mail
(the transport stuff) to request information, I ought to be able to provide
some insight into what I can handle on the receiving end. It would be nice to
be able to tell the world what I would like (e.g. EPS, MIME or ASCII, please)
before I know whether I will ever get mail from them, but this seems excessive
using current technologies.

So as not to wear out my welcome, let me finish by saying that I believe there
are solutions, but they will not be singular; there will be several pieces
that inter-relate such that, when used together, provide what is needed. It
will be much easier to deal with the issues separately, with an understanding
of the inrer-relationship(s), than try and deal with them as one.

As for 'inflammatory hogwash', isn't that how they get pink pigs?




-- 
Dennis Kavanaugh
Senior Systems Analyst
Corporate Office Systems and PB/1

From ottavj@pegase.inria.fr  Wed Oct 28 08:34:52 1992
Return-Path: <ottavj@pegase.inria.fr>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10938; Wed, 28 Oct 92 08:34:52 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12856; Wed, 28 Oct 92 08:46:48 +0100
Received: by pegase.inria.fr
	(5.65c/IDA-1.2.8) id AA11955; Wed, 28 Oct 1992 08:46:54 +0100
Date: Wed, 28 Oct 1992 08:46:54 +0100
From: Luc Ottavj <Luc.Ottavj@sophia.inria.fr>
Message-Id: <199210280746.AA11955@pegase.inria.fr>
To: NED@sigurd.innosoft.com, masinter@parc.xerox.com
Subject: Re: misconceptions about MIME [long]
Cc: connolly@pixel.convex.com, nsb@thumper.bellcore.com,
        wais-talk@quake.think.com, www-talk@nxoc01.cern.ch

>If I wish to retrieve the document, say to view it, I might want to
>choose the available representation that is most appropriate for my
>purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
>from an anonymous FTP archive, only to discover that it is in the
>newly announced Postscript level 4 format, or to try to edit it only
>to discover that it is in the (upwardly compatible but not parsable by
>my client) version 44 of Rich Text. In each case, the appropriateness
>of alternate sources and representations of a document would depend on
>information that is currently only available in-band.

i think you can avoid this if you make your MIME document descriptor
in the following way.
1- an ascii part containing an abstract for the document and
   describing all the document representations (size, real format...)
2- for each representation an external-body ftp part

then the mime document itself is very short and after you read
the ascii part you can decide to transfer( or not )
only the representation that you want


Luc Ottavj                          | Email : ottavj@pegase.inria.fr  
INRIA U.R. de Sophia Antipolis      | Phone : (33) 93 65 77 21       
 2004, Route des Lucioles BP 93     | Telex :      97 00 50 F        
 06902 Sophia Antipolis CEDEX France| Fax   : (33) 93 65 76 02       


From nsb@thumper.bellcore.com  Wed Oct 28 15:31:16 1992
Return-Path: <nsb@thumper.bellcore.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12242; Wed, 28 Oct 92 15:31:16 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA17813; Wed, 28 Oct 92 15:43:12 +0100
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA10855> for www-talk@nxoc01.cern.ch; Wed, 28 Oct 92 09:42:22 EST
Received: by greenbush.bellcore.com (4.1/4.7)
	id <AA24028> for www-talk@nxoc01.cern.ch; Wed, 28 Oct 92 09:42:21 EST
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
          via MS.5.6.greenbush.galaxy.sun4_41;
          Wed, 28 Oct 1992 09:42:16 -0500 (EST)
Message-Id: <MeveP8m0M2YtJRnHtQ@thumper.bellcore.com>
Date: Wed, 28 Oct 1992 09:42:16 -0500 (EST)
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: NED@sigurd.innosoft.com, masinter@parc.xerox.com,
        Luc Ottavj <Luc.Ottavj@sophia.inria.fr>
Subject: Re: misconceptions about MIME [long]
Cc: connolly@pixel.convex.com, wais-talk@quake.think.com,
        www-talk@nxoc01.cern.ch, Larry Masinter <masinter@parc.xerox.com>
In-Reply-To: <199210280746.AA11955@pegase.inria.fr>
References: <199210280746.AA11955@pegase.inria.fr>

I think there's something that people are missing in this discussion
that is basic to the MIME philosophy, so here comes my two cents:

MIME is a standard with a very different philosophy from many other
standards (ODA, etc.).  It has been said, not entirely incorrectly, that
MIME isn't a format standard at all, but rather a standard for labeling
and safely encoding data whose format is described by other standards. 
(Indeed, I think a major reason that text/richtext is the most
controversial content-type is that it almost is the ONLY MIME type of
which this is not true.)  The basic idea of putting the minimum possible
information in the header field is a natural outgrowth of this
philosophy, hence the argument that if the information is in the body,
it should not be duplicated in the headers.  

Larry Masinter has pointed out -- quite correctly -- that there are
situations in which this is undesirable.  I find his anonymous ftp
example quite compelling:  I would prefer not to ftp a 50 megabyte file
only to find out that it is the wrong kind of postscript.  I don't
think, however, that requiring a "full" description of the detailed
format information is necessarily the right solution, largely because
defining "full" for any given format is so problematic, and runs the
danger of being inconsistent with the internal information.

Another part of the MIME philosophy is openness and extensibility.  This
openness, I believe, points the way to a more appropriate resolution of
the problem.  It is worth noting that the MIME standard does not close
the book on additional parameters in the content-type line.  That is,
MIME says that a PostScript body part should be labelled as

Content-type: application/postscript

It also says, I believe, that unrecognized parameters should be ignored.
 This means that a MIME-conformant implementation will treat the above
content-type and the following one as equivalent:

Content-type: application/postscript; foo=bar; FavoriteCheese=muenster

Not a very useful example, I'll admit.  But this opens the door for
communities to experiment with what additional parameters might be
useful.  If the wais, gopher, or www communities decided to use MIME as
the base data representation standard, they could easily specify a few
additional parameters for situations of concern to those communities. 
Indeed, as has been pointed out, if the transport system is other than
mail, there are likely to be some diffferent concerns.  (Larry's
anonymous ftp problem, for example, is arguably central to wais and
relatively peripheral to email.)   So it might simply prove to be more
important to the wais community to have the Postscript Level labeled in
the header data than it was to the mail community.  No big deal.  The
consensus in the mail community (at least as reflected on the ietf-822
mailing list, which devised MIME) was that such a parameter was not
particularly necessary or desirable for email use.  The WAIS community
might reach a diametrically opposite conclusion, and can accordingly
extend MIME to include a few extra parameters, content-types, etc.  The
most useful of these, I conjecture, will eventually find their way back
into the email world.  This kind of evolution is precisely the reason I
always felt so strongly that MIME needed a path for graceful evolution,
including the IANA process for registering new content-types, character
sets, and parameters.

So the bottom line for me is that Larry's concerns have definite merit,
but I think that they can easily be accomodated as minor extensions to
MIME.  My suggested path for making those extensions is to first try to
reach a consensus on what extensions are needed for the wais/www/gopher
communities, and then register those extensions with IANA.  If any of
them prove to be problematic in the sense that they need to be
universally implemented -- as opposed to only being implemented among
cooperating software -- the documents defining them can be submitted to
the IAB standardization process.  However, I suspect that official
standard status will not be necessary in most cases.

I hope that sheds some light on muddy waters...   -- Nathaniel

From timbl@www3.cern.ch  Wed Oct 28 16:30:50 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12487; Wed, 28 Oct 92 16:30:50 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25533; Wed, 28 Oct 92 16:42:44 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00868; Wed, 28 Oct 92 16:40:32 +0100
Date: Wed, 28 Oct 92 16:40:32 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210281540.AA00868@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: dckavan@srv.pacbell.com (Dennis Kavanaugh)
Subject: Re: misconceptions about MIME [long]
Cc: Larry Masinter <masinter@parc.xerox.com>, NED@sigurd.innosoft.com,
        nsb@thumper.bellcore.com, wais-talk@quake.think.com,
        connolly@pixel.convex.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



It seems that while Larry makes the point that level 2 postscript
(etc etc etc) should not be confused with MIME's "postscript", he
has not (recently? yet? at all?) objected to the basic MIME labelling method,
simply to an oversimplification of the format designations. These will
have to be exanded with time, anyway.

Would it be reasonable of us to take Dan's cue and change HTTP2 so that
the returned message is a MIME format?  Would MIME in return (a) add
text/SGML/HTML as a MIME format  (who registers DTD names?) and also
use an IETF standard URL a the external reference format?

	Tim



__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From nsb@thumper.bellcore.com  Wed Oct 28 16:46:29 1992
Return-Path: <nsb@thumper.bellcore.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12688; Wed, 28 Oct 92 16:46:29 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA27735; Wed, 28 Oct 92 16:58:08 +0100
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA21897> for timbl@nxoc01.cern.ch; Wed, 28 Oct 92 10:57:25 EST
Received: by greenbush.bellcore.com (4.1/4.7)
	id <AA24188> for www-talk@nxoc01.cern.ch; Wed, 28 Oct 92 10:57:24 EST
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
          via MS.5.6.greenbush.galaxy.sun4_41;
          Wed, 28 Oct 1992 10:57:20 -0500 (EST)
Message-Id: <UevfVUK0M2YtBRnQ1m@thumper.bellcore.com>
Date: Wed, 28 Oct 1992 10:57:20 -0500 (EST)
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: dckavan@srv.pacbell.com (Dennis Kavanaugh), timbl@nxoc01.cern.ch
Subject: Re: misconceptions about MIME [long]
Cc: Larry Masinter <masinter@parc.xerox.com>, NED@sigurd.innosoft.com,
        wais-talk@quake.think.com, connolly@pixel.convex.com,
        www-talk@nxoc01.cern.ch
In-Reply-To: <9210281540.AA00868@www3.cern.ch>
References: <9210281540.AA00868@www3.cern.ch>

Excerpts from mail: 28-Oct-92 Re: misconceptions about MI.. Tim
Berners-Lee@www3.cer (894)

> Would MIME in return (a) add
> text/SGML/HTML as a MIME format  (who registers DTD names?) and also
> use an IETF standard URL a the external reference format?

I'm not an expert on any of these formats, but would point out that
syntactically MIME content-types are only a two level hierarchy, but you
could name it something like "text/sgml-html".  Also, if the format
isn't really human-readable, you probably don't want to put it under
"text", but are better off with "application/sgml-html" or something
like that.

Registration is with IANA, the Internet Assigned Numbers (Names?)
Authority.  -- Nathaniel

From connolly@pixel.convex.com  Wed Oct 28 17:46:30 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13165; Wed, 28 Oct 92 17:46:30 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03611; Wed, 28 Oct 92 17:58:29 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA05996; Wed, 28 Oct 92 10:57:42 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06593; Wed, 28 Oct 92 10:57:39 -0600
Message-Id: <9210281657.AA06593@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: misconceptions about MIME [long] 
In-Reply-To: Your message of "Wed, 28 Oct 92 16:40:32 +0100."
             <9210281540.AA00868@www3.cern.ch> 
Date: Wed, 28 Oct 92 10:57:38 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Would it be reasonable of us to take Dan's cue and change HTTP2 so that
>the returned message is a MIME format?

You mean use MIME content types for HTTP2 format negociation: exactly!

>  Would MIME in return (a) add
>text/SGML/HTML as a MIME format 

Just write a spec for it and register it with the IANA.

> (who registers DTD names?

The ISO grants public text identifiers for DTDs.

> and also
>use an IETF standard URL a the external reference format?

I'm not sure I understand this part. Sure you can have a format
called text/html, and sure you can put URLs in it, but that
doesn't mean URLs have to become part of the MIME standard.

Dan


From timbl@www3.cern.ch  Thu Oct 29 16:29:59 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19500; Thu, 29 Oct 92 16:29:59 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00414; Thu, 29 Oct 92 16:41:15 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06151; Thu, 29 Oct 92 16:38:18 +0100
Date: Thu, 29 Oct 92 16:38:18 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210291538.AA06151@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: misconceptions about MIME [long] 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>Would it be reasonable of us to take Dan's cue and change HTTP2 so that
>  >the returned message is a MIME format?
>  

>  You mean use MIME content types for HTTP2 format negociation: exactly!


	Sounds reasonable to me in the interest of reasonableness.

>  > and also
>  >use an IETF standard URL a the external reference format?
>  

>  I'm not sure I understand this part. Sure you can have a format
>  called text/html, and sure you can put URLs in it, but that
>  doesn't mean URLs have to become part of the MIME standard.
>  


I mean that there is a clash between the URL/URI work and the MIME
external context format.  For example there are two ways of writing
a reference to an FTP archive. It would be neat to amalgamate them.
I  personally think the MIME format is too longwinded (look at the
ref on the end of your earlier message -- that could have been 1 line).

Of couse a generic URL could be made another specific MIME external
reference format, as FTP is now, which would provide a transistion.

---- by the way...

Data formats:
It is true that a generic system ought to be able to represent the
complexities of reality. But it is also true that if one makes
arbitrary choices and only accomodates those, then reality may in the
end toe the line.  MIME registration will give a lot of weight to
a particular set of paramaters for a data format, and so the
use of arbitrary deviants from the registered formats would tend to
die out.

To a certain extent only, of course. There will always be people
who use weird formats, but then noone will be able to
hear anything of them anyway... ;-)

	Tim



From connolly@pixel.convex.com  Thu Oct 29 17:52:05 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20051; Thu, 29 Oct 92 17:52:05 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09262; Thu, 29 Oct 92 18:03:29 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA27583; Thu, 29 Oct 92 11:02:35 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA16901; Thu, 29 Oct 92 11:02:32 -0600
Message-Id: <9210291702.AA16901@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: misconceptions about MIME [long] 
In-Reply-To: Your message of "Thu, 29 Oct 92 16:38:18 +0100."
             <9210291538.AA06151@www3.cern.ch> 
Date: Thu, 29 Oct 92 11:02:32 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I mean that there is a clash between the URL/URI work and the MIME
>external context format.  For example there are two ways of writing
>a reference to an FTP archive. It would be neat to amalgamate them.
>I  personally think the MIME format is too longwinded (look at the
>ref on the end of your earlier message -- that could have been 1 line).

I don't see that there's a clash. There's a certain redundancy, but
that's nothing new.

If you're using MIME encapsulation techniques to attach an ftp file
to a body part, you use the message/external-body mechanism. But
if you're writing HTML, you put a URL in an anchor.

It might be nice if WWW clients could parse MIME multipart and
message types, but it seems reasonable to just pass them on to
metamail or some such MIME user agent.

On the other hand, a MIME user agent need not grok HTML -- it just
passes it along to the WWW client.

Am I missing something?

Dan


From timbl@www3.cern.ch  Thu Oct 29 18:05:11 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20132; Thu, 29 Oct 92 18:05:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10518; Thu, 29 Oct 92 18:17:13 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06330; Thu, 29 Oct 92 18:15:07 +0100
Date: Thu, 29 Oct 92 18:15:07 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210291715.AA06330@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Presidential Campain information
Cc: "Phillip M. Hallam-Baker" <HALLAM@zws007.desy.de>
Reply-To: timbl@nxoc01.cern.ch

> From: "Phillip M. Hallam-Baker" <HALLAM@zws007.desy.de>

>	I have just got a note from the Clinton/Gore campaign asking
> me to produce a W3 server for them. I have put it up here for the time
> being and while I was at it pulled together a whole bunch of
> stuff from Perot, opinion polls etc. Nothing from the Bush campaign yet
> but will try. After the election will do a british politics 

> page as well but at the mo will cater to the major interest.

These as well as indexes of speeches by Clinton and Bush are now
linked from

  http://info.cern.ch/hypertext/Products/WAIS/Sources/Political.html

which is a link from the subject page.  I only pass this around while
it is timely.  I don't make any comment on the context!

	Tim BL

From timbl@www3.cern.ch  Thu Oct 29 18:09:08 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20168; Thu, 29 Oct 92 18:09:08 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11063; Thu, 29 Oct 92 18:20:44 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06343; Thu, 29 Oct 92 18:18:25 +0100
Date: Thu, 29 Oct 92 18:18:25 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210291718.AA06343@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: misconceptions about MIME [long] 
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Date: Thu, 29 Oct 92 11:02:32 CST
> From: Dan Connolly <connolly@pixel.convex.com>
...
> There's a certain redundancy, but that's nothing new.
...
> Am I missing something?

	Alas, no!

Tim

From NED@sigurd.innosoft.com  Thu Oct 29 18:43:29 1992
Return-Path: <NED@sigurd.innosoft.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20444; Thu, 29 Oct 92 18:43:29 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14159; Thu, 29 Oct 92 18:55:30 +0100
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF #1339 ) id
 <01GQIM2YW0LC91VWYH@SIGURD.INNOSOFT.COM>; Thu, 29 Oct 1992 09:53:10 PDT
Date: 29 Oct 1992 09:53:10 -0700 (PDT)
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: misconceptions about MIME [long]
To: masinter@parc.xerox.com
Cc: nsb@thumper.bellcore.com, wais-talk@quake.think.com,
        connolly@pixel.convex.com, www-talk@nxoc01.cern.ch,
        ned@sigurd.innosoft.com
Message-Id: <01GQIM2YWA8I91VWYH@SIGURD.INNOSOFT.COM>
X-Vms-To: IN%"masinter@parc.xerox.com"
X-Vms-Cc: 
 IN%"nsb@thumper.bellcore.com, wais-talk@quake.think.com,connolly@pixel.convex.com,
 www-talk@nxoc01.cern.ch, ned@sigurd.innosoft.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> The arguments that in-band designation of document format is better
> than out-of-band information may apply in the electronic mail
> scenarios, where there is a single sender, multiple recipients, and
> the recipient has no control over what the sender might send.

The argument is identical for most file servers, which have even less control
over the specifics of what files they offer for retrieval. File servers usually
rely on contributed material and only rarely have anything resembling precise
control over the material they offer.

> Instead, imagine, if you would, another scenario, of a WAIS or Web or
> anonymous FTP archive, which wishes to make available the latest
> version of the MIME specification. Let us suppose, in addition, that
> the publishing service has three different representations of the
> document, one marked "MIME rich-text", one marked "postscript", and
> one NetFax.  Furthermore, let us suppose (as has been proposed) that
> the document types are marked by their MIME Content-type header
> designation.

Nothing wrong with this.

> If I wish to retrieve the document, say to view it, I might want to
> choose the available representation that is most appropriate for my
> purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
> from an anonymous FTP archive, only to discover that it is in the
> newly announced Postscript level 4 format, or to try to edit it only
> to discover that it is in the (upwardly compatible but not parsable by
> my client) version 44 of Rich Text. In each case, the appropriateness
> of alternate sources and representations of a document would depend on
> information that is currently only available in-band.

Even if this happens (I have strong doubts that it will since documents made
available for public retrieval tend to converge rapidly to lowest-common
denominator usage) you have failed to propose an alternative that solves this
usefully.

> I believe that MIME was developed in the context of electronic mail,
> but that the usage patterns in space and time of archives, database
> services and the like require more careful attention (a) to
> out-of-band information about format versions, so that you might know,
> before you retrieve a representation, whether you have the capability
> of coping with it, and (b) some restriction on those formats which
> might otherwise be uncontrollable.

And I disagree. You still have failed to explain how to overcome any of my
objections to this approach.

> Finally, as much as I've tried to resist, I'll characterize your
> description of my response as 'repeated failure on your part to read
> the words I was writing' as 'inflammatory hogwash'.

Well, you're doing it again. You have failed to explain you intend to overcome
any of the obstacles I've pointed out, precisely as if you have not bothered to
read any of my previous response. Since one of them is the halting problem in
disguise your method of overcoming it (assuming you have one) will be the
computing news of the century.

I have no intention of answering any further mail from you until you come
to grips with the objections I have laid out for about the tenth time.

Finally, let me point out that I speak as one of the maintainers of one of the
largest archive of TeX material available anywhere. This material has been
available via MIME-compliant mail server (and of course FTP) for over six
months now. This archive contains hundreds of PostScript documents as well
as all sorts of other stuff. The problems you seem to think are endemic to
this sort of services have yet to materialize.

				Ned

From davis@dri.cornell.edu  Thu Oct 29 19:57:52 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20826; Thu, 29 Oct 92 19:57:52 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19462; Thu, 29 Oct 92 20:09:57 +0100
Received: by willow.tc.cornell.edu id AA17963
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 29 Oct 1992 14:09:05 -0500
Date: Thu, 29 Oct 1992 14:09:05 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199210291909.AA17963@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch, wais-talk@quake.think.com,
        nsb@thumper.bellcore.com
Subject: In-band v.s outband labeling. (was: Misconceptions about MIME [long])


I wish that people would take a less inflammatory tone in
the mail, and try to assume that even if some parties may
be wrong, they are at least possessing good will and a desire
to find solutions that work for all users.

Larry says he has a problem.  As I understand it, his problem 
is that moving data is expensive, so he wants to have more information
available at the client  before retrieving the data.  Why would anyone
object to this?

Does it help to consider that someday, maybe soon, much network data will
be sold for a fee.  Would you object to customers wanting information
about data before paying the price?

If we agree this is a real problem, then we face the problem
of finding a solution that is practical, efficient, compatible,
and so on.

Now, as N Freed points out, no method exists to automatically
compute in the general case the resource requirements of  e.g. PostScript,
that has little bearing.  For one thing, there are many data types
which are not turing complete programs (e.g. GIF files).  For another,
the person who produced the PostScript in the first place probably
knows the measurements.  After all, if I created a .PS file and put
it on the net, I probably displayed it at least once, so I know well
enough that it does halt.  (unless I am malicious.)  And finally,
even if the creator does not tell you, you can still compute it, once,
and then store the results in the file archive, or Wed, or whatever.
 
The fact that a full, general and automatic solution is impossible
does it lessen the value of partial solutions.

So the proposed solution is to have more explicit labeling.  What's
wrong with that?  If you dont use it, it costs nothing.
If you do use it, it makes life easier for people.
 
You can argue that many people are too lazy to provide this information,
and I agree  But  not everyone is lazy.  there will also be people motivated
to expend the trouble to label the data, yes, even to go to the
extent of computing how much main memory you will need to uncompress
and so on.  Why will they be motivated?  Because those  who do will have larger audiences, and that is already a motivation.  And when money starts to
enter the picture, the motivation for market share will be stronger.

There will be a consumer's union and an underwriters laboratory for
information space.  The question is where to put the information, 
the "meta data" if you will.

Best wishes

From emv@garnet.msen.com  Fri Oct 30 06:20:03 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23573; Fri, 30 Oct 92 06:20:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22271; Fri, 30 Oct 92 06:32:08 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mkowZ-00008WC@garnet.msen.com>; Fri, 30 Oct 92 00:30 WET
Message-Id: <m0mkowZ-00008WC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: port to bsdi / TOUPPER problem
Date: Fri, 30 Oct 92 00:30:33 EST
From: Edward Vielmetti <emv@msen.com>

Hi.  I am porting WWW to BSDI.  So far mostly so good, here are some
notes.

There are some stray dependencies in the Line Mode makefiles that point
hard coded paths at /tmp for making stuff.  /tmp here is tiny, so I
put the stuff in $(HOME)/tmp, but that didn't quite do the job.

It took some amount of fiddling to get everything to build in the
right place, I hacked at it until it all compiled ok but will have
to go back and see what exactly it was that I did...

HTFile.c didn't compile until I commented out one of the two times 
that "tcp.h" was included - the compiler complained about a duplicate
definition of "struct stat".

After all that it compiles fine and seems to work, and 'www -source'
prints out what looks like real genuine HTML sources.  However, it
appears that there's some critical place where TOUPPER is not working
right, since the lower-case <a href=foo:bar>foobar</a> tags don't
get recognized, and the upper-case <TITLE>foobar</TITLE> tags do.  
This kind of ruins the hypertext effect :)

thanks,

--Ed

From emv@garnet.msen.com  Fri Oct 30 07:02:36 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23636; Fri, 30 Oct 92 07:02:36 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24456; Fri, 30 Oct 92 07:14:39 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mkpcL-00008XC@garnet.msen.com>; Fri, 30 Oct 92 01:13 WET
Message-Id: <m0mkpcL-00008XC@garnet.msen.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: port to bsdi / TOUPPER problem 
In-Reply-To: Your message of Fri, 30 Oct 92 00:30:33.
             <m0mkowZ-00008WC@garnet.msen.com> 
Date: Fri, 30 Oct 92 01:13:42 EST
From: Edward Vielmetti <emv@msen.com>

problem fixed, let me tell you how i did it for a suggested change 
to the library arrangement.

1st, i moved the TOUPPER / TOLOWER code out of tcp.h into HTUtils.h.

2nd, I took out the ifdefs and made it always check whether something
is lowercase before uppercasing it and vice versa.

this seems to have fixed the immediate problems, and should be more
portable to boot.

i think there's a declaration in SGML.c that could be removed too.

--Ed

From timbl@www3.cern.ch  Fri Oct 30 11:51:33 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24395; Fri, 30 Oct 92 11:51:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22086; Fri, 30 Oct 92 12:03:35 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06754; Fri, 30 Oct 92 12:01:16 +0100
Date: Fri, 30 Oct 92 12:01:16 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210301101.AA06754@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Edward Vielmetti <emv@msen.com>
Subject: port to bsdi / TOUPPER problem
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Hi.  I am porting WWW to BSDI.  So far mostly so good, here are some
>  notes.

Duuhh. What's BSDI?  {:-O

>  There are some stray dependencies in the Line Mode makefiles that point
>  hard coded paths at /tmp for making stuff.  /tmp here is tiny, so I
>  put the stuff in $(HOME)/tmp, but that didn't quite do the job.

It is a question of changing the ONJ macro to point to somewhere where
there is space. It used to be the source directory, but some people
want to build separately from a read-only source mount. So we put the OBJ
macros in.

>  It took some amount of fiddling to get everything to build in the
>  right place, I hacked at it until it all compiled ok but will have
>  to go back and see what exactly it was that I did...

If you could mail me back the diffs I'll try to get them into
the next version.

>  HTFile.c didn't compile until I commented out one of the two times 

>  that "tcp.h" was included - the compiler complained about a duplicate
>  definition of "struct stat".

Ooops.. sorry, fixed.  I think you mean that <stat.h> was included
explicitly once and once implcitly via  "tcp.h".
  

>  After all that it compiles fine and seems to work, and 'www -source'
>  prints out what looks like real genuine HTML sources.  However, it
>  appears that there's some critical place where TOUPPER is not working
>  right, since the lower-case <a href=foo:bar>foobar</a> tags don't
>  get recognized, and the upper-case <TITLE>foobar</TITLE> tags do.  

>  This kind of ruins the hypertext effect :)

That is official BSD for you: toupper() doesn't work unless the isalpha()
is true. You need to turn on the macros at the bottom of tcp.h
for your platform.  What is the system-specific predefined cpp macro
which we can #ifdef on? So far we have:

	#if defined(pyr) || defined(mips)
	  /* Pyramid and Mips can't uppercase non-alpha */
	#define TOLOWER(c) (isupper(c) ? tolower(c) : (c))
	#define TOUPPER(c) (islower(c) ? toupper(c) : (c))
	#else
	#define TOLOWER(c) tolower(c)
	#define TOUPPER(c) toupper(c)
	#endif /* pyr || mips */


Thanks for the comments....

	Tim

From timbl@www3.cern.ch  Fri Oct 30 12:26:56 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24481; Fri, 30 Oct 92 12:26:56 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26866; Fri, 30 Oct 92 12:38:58 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06790; Fri, 30 Oct 92 12:36:48 +0100
Date: Fri, 30 Oct 92 12:36:48 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210301136.AA06790@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: port to bsdi / TOUPPER problem 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  problem fixed, let me tell you how i did it for a suggested change 

>  to the library arrangement.
>  

>  1st, i moved the TOUPPER / TOLOWER code out of tcp.h into HTUtils.h.
>  

>  2nd, I took out the ifdefs and made it always check whether something
>  is lowercase before uppercasing it and vice versa.
>  

>  this seems to have fixed the immediate problems, and should be more
>  portable to boot.
>  

>  i think there's a declaration in SGML.c that could be removed too.
>  


All done ... I'll test it with the next release.  Thanks!

	Tim BL
  


From timbl@www3.cern.ch  Fri Oct 30 17:48:25 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26075; Fri, 30 Oct 92 17:48:25 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04780; Fri, 30 Oct 92 18:00:26 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA07021; Fri, 30 Oct 92 17:58:08 +0100
Date: Fri, 30 Oct 92 17:58:08 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9210301658.AA07021@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: nir@cc.mcgill.ca, wg-isus@rare.nl, uri@bunyip.com, www-talk@nxoc01.cern.ch
Subject: URLs - new document;      URL mail server
Reply-To: timbl@nxoc01.cern.ch


A new URL definition document is available at locations

	ftp://info.cern.ch/pub/ietf/url3.txt
	ftp://info.cern.ch/pub/ietf/url3.ps

The document has a few changes which were mentioned at the Boston
BOF -- please send anything I've forgotten to me ASAP for inclusion
befoer the Washington.

(Note old WWW clients require "file:" prefix instead of "ftp:" prefix
for FTP archive documents, but latest library allows either during transition  
period).
			----------

Documents may be retrieved by URL: by sending mail to 

listserv@info.cern.ch with a line containing the command SEND
followed by the URL of the document. If the document is in hypertext, the URLs  
of linked documents are listed on the end of the reply. If in doubt send  
message HELP to same address.

The software for the mail robot is available in ftp://info.cern.ch/pub/www/src

I won't be in DC but will expect a talk session to be set up with the  
meeting...   :-)


	Tim Berners-Lee

From masinter@parc.xerox.com  Sat Oct 31 00:44:11 1992
Return-Path: <masinter@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28270; Sat, 31 Oct 92 00:44:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14947; Sat, 31 Oct 92 00:56:18 +0100
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11807>; Fri, 30 Oct 1992 15:55:23 PST
Received: by poplar.parc.xerox.com id <101795>; Fri, 30 Oct 1992 15:55:08 -0800
To: NED@sigurd.innosoft.com, nsb@thumper.bellcore.com,
        wais-talk@quake.think.com, connolly@pixel.convex.com,
        www-talk@nxoc01.cern.ch, ned@sigurd.innosoft.com
In-Reply-To: Ned Freed's message of Thu, 29 Oct 1992 08:53:10 -0800 <01GQIM2YWA8I91VWYH@SIGURD.INNOSOFT.COM>
Subject: Re: misconceptions about MIME [long]
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <92Oct30.155508pst.101795@poplar.parc.xerox.com>
Date: 	Fri, 30 Oct 1992 15:54:56 PST

>> The arguments that in-band designation of document format is better
>> than out-of-band information may apply in the electronic mail
>> scenarios, where there is a single sender, multiple recipients, and
>> the recipient has no control over what the sender might send.

>The argument is identical for most file servers, which have even less control
>over the specifics of what files they offer for retrieval. File servers usually
>rely on contributed material and only rarely have anything resembling precise
>control over the material they offer.

But we are not discussing 'file servers' in general, but something
more specific and presumably over which we have more control: use of
MIME content identifiers to identify content-type in World-Wide-Web
and WAIS servers. Even in the case of file servers, while you might
not have control over the material offered, you do have control over
the description of that material as to which version of a purported
standard format the material might be in, and even, in some cases,
which profile of that standard might apply.

>> If I wish to retrieve the document, say to view it, I might want to
>> choose the available representation that is most appropriate for my
>> purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
>> from an anonymous FTP archive, only to discover that it is in the
>> newly announced Postscript level 4 format, or to try to edit it only
>> to discover that it is in the (upwardly compatible but not parsable by
>> my client) version 44 of Rich Text. In each case, the appropriateness
>> of alternate sources and representations of a document would depend on
>> information that is currently only available in-band.

>Even if this happens (I have strong doubts that it will since documents made
>available for public retrieval tend to converge rapidly to lowest-common
>denominator usage) you have failed to propose an alternative that solves this
>usefully.

Documents made available for public retrieval do not cannot 'tend to
converge rapidly to lowest-common denominator usage', because *old
documents do not go away*! If there is diversity today in the
available formats for RFCs, tech reports and PhD theses, that
diversity can only get worse! It is foolish to think that the
diversity will diminish any time in the near future; certainly the
number of 'conference proceedings on CD-rom' is increasing, as people
want to share Mathematica documents, various forms of hypertext, audio
content and the like.

As for a proposal that 'solves this usefully', I have a fairly mild
proposal that, while it does not solve all of the problems in
interoperability, does reduce the amount of uncertainty:

I propose (once again) that instead of saying 'application/postscript'
it say, at a minimum, 'application/postscript 1985' vs
'application/postscript 1994' or whatever you would like to designate
as a way to uniquely identify which edition of the Postscript
reference manual you are talking about; instead of being identified as
'image/tiff' the files be identified as 'image/tiff 5.0 Class F' vs
'image/tiff 7.0 class QXB'.

> Finally, let me point out that I speak as one of the maintainers of one of the
> largest archive of TeX material available anywhere. This material has been
> available via MIME-compliant mail server (and of course FTP) for over six
> months now. This archive contains hundreds of PostScript documents as well
> as all sorts of other stuff. The problems you seem to think are endemic to
> this sort of services have yet to materialize.

I think you need to take a longer-term and broader perspective than a
six-month experience with a single representation of document.


We've been developing a document archive service that can cope with 20
years of collected electronic documents. We have not only Postscript 1
and 2, but also several versions of Interpress, and Press format, two
versions of DVI, revisable formats of 20 years of editor development
-- several versions of tex, latex, framemaker, microsoft word, tioga,
globalview, viewpoint, bravo, bravox, tedit, troff, interleaf,
wordperfect, etc, and images in multiple variations of RES, AIS, TIFF,
sun raster, pcx, macpaint, ad nauseum.

In trying to deal with a documents over the longer term, it has become
apparent that merely marking documents with a simple 'format' tag like
'interpress' or 'postscript' or 'tiff' isn't adequate for most
purposes. Standards evolve over as short as a 5 year period; even the
method of internal tagging standard versions changes, and certainly,
it is impossible to rely on in-band version information for all
formats. 

I have more to say about the problem of 'external references' but I'll
save that for another message.

It would be nice to have a calm discussion about possible solutions to
these problems & hope you will forgo future sarcasm.

Thanks,

Larry

From emv@garnet.msen.com  Sun Nov  1 03:23:23 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01639; Sun, 1 Nov 92 03:23:23 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10179; Sun, 1 Nov 92 03:35:31 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mlV92-00008eC@garnet.msen.com>; Sat, 31 Oct 92 21:34 WET
Message-Id: <m0mlV92-00008eC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: saving documents, losing links
Date: Sat, 31 Oct 92 21:34:14 EST
From: Edward Vielmetti <emv@msen.com>

it should, at least i think it should, be possible once you have come
across a piece of the web that you're interested in to save it off
to the side (in source form) so that you can look at it again or
add it to your own hoard of stuff.

i went to the 'jargon' section of the web, as served by
iicm.tu-graz.ac.at, to look something up.  (I wanted to see whether
the hacker's dictionary had a definition for 'firmware', since
there's a harangue going on about it in comp.infosystems.  i located
a nice entry on '-ware' which looked pretty interesting and went
to save that to a file (using the command 'source >
$HOME/archives/ware.html' from the line mode browser).

to my slight surprise and dismay, when I went to visit the document
again (using the command 'www ~/archives/ware.html') all of the cross
reference links were just gone.  looking around a little bit I think
that a simple sed command like
	sed -e 's/HREF=A/HREF=http://iicm.tu-graz.ac.at:80\/A/g'
or thereabouts would put things right.

should making a copy of a piece of the web simply be a verbatim
copy of the source, or should it try to make relative links absolute?

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB

From emv@garnet.msen.com  Sun Nov  1 03:51:38 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01692; Sun, 1 Nov 92 03:51:38 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11429; Sun, 1 Nov 92 04:03:48 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mlVaj-00008bC@garnet.msen.com>; Sat, 31 Oct 92 22:02 WET
Message-Id: <m0mlVaj-00008bC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: question and answer, style guide?
Date: Sat, 31 Oct 92 22:02:51 EST
From: Edward Vielmetti <emv@msen.com>

Can someone suggest a good style for a 'frequently asked questions,
with answers' document?  I'm using 
	<ul>
	<li>
	<li>
	...
	</ul>
but it's not clear that just putting paragraph marks in is going to do
the trick.

I think I'd like to distinguish the questions from the answers by
indenting, at least in the 24x80 dumb terminal that I'm working with,
but I also want to make sure that things look ok under X.

thanks,

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From joe@athena.mit.edu  Sun Nov  1 05:41:40 1992
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01973; Sun, 1 Nov 92 05:41:40 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19781; Sun, 1 Nov 92 05:53:50 +0100
Received: from MAJOR.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA07360; Sat, 31 Oct 92 18:09:51 EST
Received: by major (5.57/4.7) id AA19876; Sat, 31 Oct 92 18:09:45 -0500
Message-Id: <9210312309.AA19876@major>
To: www-talk@nxoc01.cern.ch
Cc: mory@athena.mit.edu, vonneidt@athena.mit.edu
Subject: Usenet University - New Network Academy (Help needed)
Date: Sat, 31 Oct 92 18:09:43 EST
From: Joseph Wang <joe@athena.mit.edu>

Hello.  I've involved in starting the Usenet University - New Network
Academy initiative.  The purpose of this initiative is to develop a
electronic "University" over internet.  The first phase of this
consists of two parts:

1. Developing a community of consultants who are willing to answer questions
   over Email, and

2. Developing a central repository of freely redistributable hypertext
   information

I'd like to use WWW as a basis for this hypertext library.  My problem
is finding a machine to run a WWW server on.  I was wondering if
anyone in netland who is already running a WWW server, can lend me an
account and some disk space to start this hypertext library.


From timbl@www3.cern.ch  Sun Nov  1 16:56:50 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02791; Sun, 1 Nov 92 16:56:50 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13733; Sun, 1 Nov 92 17:08:55 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00294; Sun, 1 Nov 92 17:06:08 +0100
Date: Sun, 1 Nov 92 17:06:08 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211011606.AA00294@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: question and answer, style guide?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Can someone suggest a good style for a 'frequently asked questions,
> with answers' document?  


The W3 FAQ have a <UL>...</UL> list of questions which are linked to
a page each of which has a H1 summary heading,
and an H@ "Question" thena a few paragraphs of question and an H2
with a heading appropriate for the answer and n paragraphs of
answer.

If you want to put all the FAQ on one document (will this scale?)
then I would suggest making the questions H2 level headings, and
the text ordinary text. H2 headings are normally bold and bug and  
left-justified on X dipslays.

The advantage with using headings for the questions instead of
DT glossary parts is that that you are free to use glossaries,lists and
examples within the answer.

> I think I'd like to distinguish the questions from the answers by
> indenting, at least in the 24x80 dumb terminal that I'm working with,
> but I also want to make sure that things look ok under X.

Sounds like somone ought to be buying you a workstation for Christmas :-)
But I realize that users tend not to use/have X, even now.

	Tim BL

From raisch@cthulhu.control.com  Mon Nov  2 17:16:41 1992
Return-Path: <raisch@cthulhu.control.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06933; Mon, 2 Nov 92 17:16:41 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA20261; Mon, 2 Nov 92 17:28:50 +0100
Received: by control.com (4.1/Spike-2.0)
	id AA21422; Mon, 2 Nov 92 11:26:43 EST
Date: Mon, 2 Nov 1992 11:15:18 -0500 (EST)
From: Robert Raisch <raisch@cthulhu.control.com>
Subject: Re: question and answer, style guide?
To: www-talk@nxoc01.cern.ch
In-Reply-To: <9211011606.AA00294@www3.cern.ch>
Message-Id: <Pine.3.03.9211021115.E272-b100000@cthulhu.control.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 1 Nov 1992, Tim Berners-Lee wrote:

> Sounds like somone ought to be buying you a workstation for Christmas :-)
> But I realize that users tend not to use/have X, even now.
> 

Even now?  Tim, this has been a sore spot with me for quite some years
now, so you'll have to excuse this mild flame.

The assumption that many of the interesting technologies on the Internet
make is that *everyone* has a mega-pel, multi-mip workstation on their
desk.  This is simply not the case.  The vast majority of users on the
Internet have dialin or tty based accounts, and I do not see this trend
changing in the forseeable future.  Any tool which assumes *anything*
about the hardware resources of the user is (IMHO) a bad thing. 

Don't get me wrong, WWW is a marvelous tool, and with the various X-based
client implementations, it is a truely useful and intuitive approach to
the presentation of information.  But I would suggest that X-based
solutions are as useful as a Lamborgini Countach for everyday city driving.

*PLEASE* continue to develop WWW with a keen awareness of the requirements
of the Everyman(person)!

	</rr>
--
Everything is deeply intertwingled.  -Nelson



From NED@sigurd.innosoft.com  Mon Nov  2 21:27:43 1992
Return-Path: <NED@sigurd.innosoft.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08449; Mon, 2 Nov 92 21:27:43 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05198; Mon, 2 Nov 92 21:39:38 +0100
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF #1339 ) id
 <01GQOCYWZG4W91W1GH@SIGURD.INNOSOFT.COM>; Mon, 2 Nov 1992 12:37:31 PDT
Date: 02 Nov 1992 12:37:29 -0700 (PDT)
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: misconceptions about MIME [long]
To: masinter@parc.xerox.com
Cc: NED@sigurd.innosoft.com, nsb@thumper.bellcore.com,
        wais-talk@quake.think.com, connolly@pixel.convex.com,
        www-talk@nxoc01.cern.ch
Message-Id: <01GQOCYX092Q91W1GH@SIGURD.INNOSOFT.COM>
X-Vms-To: IN%"masinter@parc.xerox.com"
X-Vms-Cc: 
 IN%"NED@SIGURD.INNOSOFT.COM, nsb@thumper.bellcore.com,wais-talk@quake.think.com,
 connolly@pixel.convex.com, www-talk@nxoc01.cern.ch"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> But we are not discussing 'file servers' in general, but something
> more specific and presumably over which we have more control: use of
> MIME content identifiers to identify content-type in World-Wide-Web
> and WAIS servers. Even in the case of file servers, while you might
> not have control over the material offered, you do have control over
> the description of that material as to which version of a purported
> standard format the material might be in, and even, in some cases,
> which profile of that standard might apply.

I remain extremely skeptical that you can exercise this level of control. I
suspect that if you achieve any control whatsoever it will probably be arranged
along axes that you haven't yet considered. (The most obvious one would be
knowing package that produced the document as well as the version of its
PostScript driver.) I think that if you try to arrange a particular sort of
labelling now you will only find that things don't match up to it.

If in fact you do end up with some degree of control over version-specific
usage it will _then_ be the time to add some additional parameters containing
this information.

>> If I wish to retrieve the document, say to view it, I might want to
>> choose the available representation that is most appropriate for my
>> purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
>> from an anonymous FTP archive, only to discover that it is in the
>> newly announced Postscript level 4 format, or to try to edit it only
>> to discover that it is in the (upwardly compatible but not parsable by
>> my client) version 44 of Rich Text. In each case, the appropriateness
>> of alternate sources and representations of a document would depend on
>> information that is currently only available in-band.

>Even if this happens (I have strong doubts that it will since documents made
>available for public retrieval tend to converge rapidly to lowest-common
>denominator usage) you have failed to propose an alternative that solves this
>usefully.

> Documents made available for public retrieval do not cannot 'tend to
> converge rapidly to lowest-common denominator usage', because *old
> documents do not go away*!

Nonsense. Documents (old or new) get revised when they fail to meet the needs
of lowest-common denominator usage. Let's suppose I put up a document that uses
a bunch of level 2 PostScript extensions. Let's further suppose that I emblazon
it with dozens of labels indicating that this is the case. But all the
labelling in the world will not make this document print on an old LaserWriter.

Regardless of labelling people will want to print the document. Maybe they will
retrieve it and maybe they will not. I seriously doubt that most people will
know what all this version stuff means (try asking the average user of a laser
printer what version of PostScript is supports), so in most cases the labelling
will be wasted effort. But regardless of whether they retrieve the document and
it fails to print or they heed the labels, people will then complain.

As the author of the document I will be "encouraged" to provide a version that
will work properly on the huge installed base of level 1 (or lower) printers. I
then have three choices: (1) Build two documents, one at each level, (2) Build
one document at the lower level, or (3) Build one document that works at either
level. (1) is not useful since it means maintaining two copies of a document in
almost the same format. (2) is totally reasonable, but the PostScript standards
strongly recommend (3) and give numerous examples of how to make (3) happen.

I would therefore claim that the world will rapidly move to using (3), and
makes most sorts of labelling entirely pointless.

> If there is diversity today in the
> available formats for RFCs, tech reports and PhD theses, that
> diversity can only get worse! It is foolish to think that the
> diversity will diminish any time in the near future; certainly the
> number of 'conference proceedings on CD-rom' is increasing, as people
> want to share Mathematica documents, various forms of hypertext, audio
> content and the like.

This supposed diversity is almost entirely illusory. In the early days of
PostScript this was perhaps true, but things have now been worked out to a
point where there's a large consensus behind what is acceptable PostScript
usage and what is not.

In addition, the norms of acceptable PostScript usage are actually somewhat
more restrictive than what appears in the specifications. This is largely due
to the bugs that were present in early PostScript interpreters (problems with
character set vector information come to mind here). This has resulted in a
peculiar mix of feature use and non-use. Fortunately, there are relatively few
glitches of this sort, and this has led to a situation where the problems are
fairly well understood by the driver-writers in the PostScript community.
Nevertheless, I would be the first to support an RFC that describes in some
detail what sorts of PostScript usage are acceptable and what are not.
(I'm more than willing to contribute to such a document; I just don't have
time to write the whole thing myself.)

As part of my daily work I help maintain a portion of our product line that
includes a full PostScript interpreter. As a result I deal with PostScript
problems on a daily basis. And while there are still a couple of notorious
offenders out there, most modern PostScript problems end up either being file
corruption issues or missing header files -- things of this sort. In other
words, the MIME encodings go a long way towards solving most real-world
problems printing PostScript, and driver changes can solve most of the
remaining problems.

> As for a proposal that 'solves this usefully', I have a fairly mild
> proposal that, while it does not solve all of the problems in
> interoperability, does reduce the amount of uncertainty:

> I propose (once again) that instead of saying 'application/postscript'
> it say, at a minimum, 'application/postscript 1985' vs
> 'application/postscript 1994' or whatever you would like to designate
> as a way to uniquely identify which edition of the Postscript
> reference manual you are talking about; instead of being identified as
> 'image/tiff' the files be identified as 'image/tiff 5.0 Class F' vs
> 'image/tiff 7.0 class QXB'.

All my objections still apply (you have yet to respond to a single one of my
earlier points on this matter). I remain totally and completely convinced that
this just causes numerous problems and solves absolutely nothing.

I will spare everyone the repitition of the numerous problems it causes -- they
can get all that out of my earlier mail.

> > Finally, let me point out that I speak as one of the maintainers of one of the
> > largest archive of TeX material available anywhere. This material has been
> > available via MIME-compliant mail server (and of course FTP) for over six
> > months now. This archive contains hundreds of PostScript documents as well
> > as all sorts of other stuff. The problems you seem to think are endemic to
> > this sort of services have yet to materialize.

> I think you need to take a longer-term and broader perspective than a
> six-month experience with a single representation of document.

The archive has been online for about five years. (I just checked and there are
three FTP connections going right now -- fairly light usage for midday.) Mail
service has been available for three years or so. MIME compliance in the mail
service was introduced six months ago. Some of my contribution to the
development of MIME came from the experiences of setting up and maintaining
this archive.

> We've been developing a document archive service that can cope with 20
> years of collected electronic documents. We have not only Postscript 1
> and 2, but also several versions of Interpress, and Press format, two
> versions of DVI, revisable formats of 20 years of editor development
> -- several versions of tex, latex, framemaker, microsoft word, tioga,
> globalview, viewpoint, bravo, bravox, tedit, troff, interleaf,
> wordperfect, etc, and images in multiple variations of RES, AIS, TIFF,
> sun raster, pcx, macpaint, ad nauseum.

Have you deployed it yet? Do you have any operational experience at all?

> In trying to deal with a documents over the longer term, it has become
> apparent that merely marking documents with a simple 'format' tag like
> 'interpress' or 'postscript' or 'tiff' isn't adequate for most
> purposes. Standards evolve over as short as a 5 year period; even the
> method of internal tagging standard versions changes, and certainly,
> it is impossible to rely on in-band version information for all
> formats. 

As I have stated on numerous occasions, my arguments and comments on this
matter are intended _only_ to apply to PostScript. I am fully aware that many
formats do not include version information and this must be provided
externally. There are also formats which provide internal versioning
information but that information is known to be inconsistent. I remain totally
in favor of providing this information externally as needed. But as usual you
persist in trying to apply my comments in a larger context where we both know
they are not valid.

PostScript is a special case -- a very very special case. It is a complete
programming language for starters. This makes it impossible to do anything
resembling a complete analysis of feature utilization. PostScript also is
fairly unique in that it has a comprehensive and extensible internal mechanism
for describing itself.

> I have more to say about the problem of 'external references' but I'll
> save that for another message.

Fine.

> It would be nice to have a calm discussion about possible solutions to
> these problems & hope you will forgo future sarcasm.

I'm going against my better judgement and replying to you despite the fact that
you still have not responded with how you propose to solve any of the issues I
have raised in earlier messages. Rest assured, however, that this is my last
word on the subject until you begin to come to grips with the serious problems
your proposal will cause us all.

				Ned

From emv@garnet.msen.com  Mon Nov  2 22:03:26 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08690; Mon, 2 Nov 92 22:03:26 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06338; Mon, 2 Nov 92 22:15:29 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mm95v-00007uC@garnet.msen.com>; Mon, 2 Nov 92 16:13 WET
Message-Id: <m0mm95v-00007uC@garnet.msen.com>
To: Robert Raisch <raisch@cthulhu.control.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: question and answer, style guide? 
In-Reply-To: Your message of Mon, 02 Nov 92 11:15:18.
             <Pine.3.03.9211021115.E272-b100000@cthulhu.control.com> 
Date: Mon, 02 Nov 92 16:13:40 EST
From: Edward Vielmetti <emv@msen.com>

  > Sounds like somone ought to be buying you a workstation for Christmas :-)
  > But I realize that users tend not to use/have X, even now.
  
  The vast majority of users on the
  Internet have dialin or tty based accounts, and I do not see this trend
  changing in the forseeable future.  Any tool which assumes *anything*
  about the hardware resources of the user is (IMHO) a bad thing. 
  
Then we should be all be designing things that are delivered on paper,
because the vast majority of potential users of the internet in the
next few years are not going to have any network at all or any
hardware at all on which to display user or tutorial or reference
documentation.

W3 is actually as good a first step as any in this direction.  Since
the markup is (at least one step toward) SGML, it is possible to
create documents that are usable within W3 that actually look nice on
paper.  That's a big step forward.  I am not sure yet whether you can
design something that's optimally designed for a 24x80 ascii screen
and also for paper (probably not) but at least it'll be usable in both
contexts.

------

You all should take a look at news:comp.text.sgml, in particular
news:92307.124934U35395@uicvm.uic.edu, which is a trip report by
Charles Sperberg-McQueen on the SGML '92 conference.  Here is an
enlightening perspective on the various roles that tool-builders play
in the publication efforts (are you a scribe, rubricator, or
illuminator?)

       Moving to his main theme, Goldfarb proclaimed the death of the
    "document", which he said may in fact never have been anything more than
    a makeshift to enable the use of computer technology.  The future of
    SGML lies in its use to link both within and between documents.  The
    future of SGML, that is, is HyTime.  He showed medieval pages (from the
    Winchester Bible) and discussed the division of labor among scribes,
    rubricators, illuminators, and applicators of gold leaf, which
    corresponds closely to the division of labor, in presenting a hypermedia
    document today, among the text displayer, the graphics presentation
    software, and other specialized modules.  Hypertext schemes today differ
    from the methods of the past only in incorporating time-based
    information.  The data structure must be highly optimized to make
    possible real-time presentation of time-based data, but logically
    speaking, all that is required are mechanisms for establishing
    (specifying) synchrony among events.  SGML provides a firm basis for
    representing the abstract information structures needed.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From Paul.Bayton@durham.ac.uk  Tue Nov  3 12:32:27 1992
Return-Path: <Paul.Bayton@durham.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11461; Tue, 3 Nov 92 12:32:27 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29853; Tue, 3 Nov 92 12:44:36 +0100
Received: from ben.uknet.ac.uk by chsun.chuug.ch (5.65c8/1.34)
	id AA04515; Tue, 3 Nov 1992 12:43:08 +0100
Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) 
          id <sg.12291-0@ben.uknet.ac.uk>; Tue, 3 Nov 1992 11:42:40 +0000
Received: from durham.ac.uk by eros.uknet.ac.uk via JANET with NIFTP (PP) 
          id <2143-0@eros.uknet.ac.uk>; Tue, 3 Nov 1992 11:42:32 +0000
Received: from vega.dur.ac.uk by dur.ac.uk; Tue, 3 Nov 92 11:42:11 GMT
From: Paul Bayton <Paul.Bayton@durham.ac.uk>
Received: from finzi.dur.ac.uk by vega.dur.ac.uk; Tue, 3 Nov 92 11:42:16 GMT
Message-Id: <1197.9211031142@finzi.dur.ac.uk>
Subject: help
To: www-talk@nxoc01.cern.ch
Date: Tue, 3 Nov 92 11:42:46 GMT
Mailer: Elm [revision: 70.30]


From timbl@www3.cern.ch  Tue Nov  3 13:21:12 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11622; Tue, 3 Nov 92 13:21:12 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03412; Tue, 3 Nov 92 13:33:08 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01398; Tue, 3 Nov 92 13:30:15 +0100
Date: Tue, 3 Nov 92 13:30:15 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211031230.AA01398@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: question and answer, style guide? 
Cc: Robert Raisch <raisch@cthulhu.control.com>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>  I am not sure yet whether you can
> design something that's optimally designed for a 24x80 ascii screen
> and also for paper (probably not) but at least it'll be usable in both
> contexts.


Do you feel that

 (a) you need more variety of tags, or that
 (b) the 24x80 representation of the existing tags is suboptimal, or that
 (c) the task is impossible by its nature -- you must rewritethe document.

If (a), we should take that into account for HTML extentions.
If (b), you can change the DefaultStyles.c built-in style sheet
If (c), I agree. In principle. But In practice we need to comprompize.

	Tim

From timbl@www3.cern.ch  Tue Nov  3 13:53:10 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11772; Tue, 3 Nov 92 13:53:10 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05996; Tue, 3 Nov 92 14:05:12 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01434; Tue, 3 Nov 92 14:02:15 +0100
Date: Tue, 3 Nov 92 14:02:15 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211031302.AA01434@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Robert Raisch <raisch@cthulhu.control.com>
Subject: Re: question and answer, style guide?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>  *PLEASE* continue to develop WWW with a keen awareness of the requirements
> of the Everyman(person)!

Strangely enough, I am under management pressure here to support X first,
while I know that the largest proportion of users even in High-Energy Physics
labs use terminals (or emulators running on their workstaions).

However when I think of someone whose organisative output is as large as Ed's
not having the most powerful tools to do what he does, I would encourage
Ed himself to get a NeXT and/or X and all the smart tools he can find so
we can all benefit from his productivity.

Rest assured,  the line mode www is always the first to be updated with the
new library and ported around, its support is better than any other W3 product.

Tim BL


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From dagenais@wotan.vlsi.polymtl.ca  Tue Nov  3 15:15:03 1992
Return-Path: <dagenais@wotan.vlsi.polymtl.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12231; Tue, 3 Nov 92 15:15:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14220; Tue, 3 Nov 92 15:27:04 +0100
Received: from vlsi.polymtl.ca by charles.cdec.polymtl.ca (AIX 3.1/UCB 5.61/4.04)
          id AA05708; Tue, 3 Nov 92 10:26:16 -0500
Received: from  pollux.vlsi.polymtl.ca (pollux.vlsi.polymtl.ca) by wotan.vlsi.polymtl.ca (4.1/SMI-4.1)
	id AA05725; Tue, 3 Nov 92 09:21:30 EST
Date: Tue, 3 Nov 92 09:21:30 EST
From: dagenais@vlsi.polymtl.ca (Michel Dagenais)
Message-Id: <9211031421.AA05725@wotan.vlsi.polymtl.ca>
Received: by  pollux.vlsi.polymtl.ca (4.1/SMI-4.0)
	id AA10204; Tue, 3 Nov 92 09:32:17 EST
To: www-talk@nxoc01.cern.ch
In-Reply-To: Tim Berners-Lee's message of Tue, 3 Nov 92 13:30:15 +0100 <9211031230.AA01398@www3.cern.ch>
Subject: question and answer, style guide? 

> Do you feel that
>
> (a) you need more variety of tags, or that
> (b) the 24x80 representation of the existing tags is suboptimal, or that
> (c) the task is impossible by its nature -- you must rewritethe document.

I have been talking to a number of people in the area recently
who want to setup gopher or www information servers for their
users to access both local and external information. In most
cases their first intention is to go for Gopher, because it is
"simpler". When digging more the issue it appears that they just
tried both ASCII clients (gopher and www line-mode) and the
gopher ASCII client is much nicer being based on curses.

Thus, i think that the problem is not with SGML/HTML but simply
with LineMode.

From anthony@yoyo.cc.monash.edu.au  Tue Nov  3 15:37:40 1992
Return-Path: <anthony@yoyo.cc.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12477; Tue, 3 Nov 92 15:37:40 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16113; Tue, 3 Nov 92 15:49:52 +0100
Received: from localhost by yoyo.cc.monash.edu.au (5.65a/1.34)
	id AA03638; Wed, 4 Nov 92 01:48:34 +1100
Message-Id: <9211031448.AA03638@yoyo.cc.monash.edu.au>
To: dagenais@vlsi.polymtl.ca (Michel Dagenais)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: question and answer, style guide? 
In-Reply-To: Your message of "Tue, 03 Nov 92 09:21:30 EST."
             <9211031421.AA05725@wotan.vlsi.polymtl.ca> 
Date: Wed, 04 Nov 92 01:48:34 +1100
From: Anthony Baxter <anthony@yoyo.cc.monash.edu.au>
X-Mts: smtp



In message <9211031421.AA05725@wotan.vlsi.polymtl.ca> you write:
> I have been talking to a number of people in the area recently
> who want to setup gopher or www information servers for their
> users to access both local and external information. In most
> cases their first intention is to go for Gopher, because it is
> "simpler". When digging more the issue it appears that they just
> tried both ASCII clients (gopher and www line-mode) and the
> gopher ASCII client is much nicer being based on curses.
> 
> Thus, i think that the problem is not with SGML/HTML but simply
> with LineMode.

I remember seeing a (development) version of a screenmode client that was
quite nice. I cant find a reference to where it was now, does anyone know
what happened to it? Is it still under development?

I agree, though - a nice curses-type client would be a real bonus.

Anthony
Anthony

From emv@garnet.msen.com  Tue Nov  3 16:35:22 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12841; Tue, 3 Nov 92 16:35:22 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21205; Tue, 3 Nov 92 16:47:07 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mmQSG-00007hC@garnet.msen.com>; Tue, 3 Nov 92 10:45 WET
Date: Tue, 3 Nov 1992 10:37:06 -0500 (EST)
From: Edward Vielmetti <emv@garnet.msen.com>
Subject: Re: question and answer, style guide? 
To: Tim Berners-Lee <timbl@www3.cern.ch>
Cc: Robert Raisch <raisch@cthulhu.control.com>, www-talk@nxoc01.cern.ch
In-Reply-To: <9211031230.AA01398@www3.cern.ch>
Message-Id: <Pine.3.05.9211031003.A20803-b100000@garnet.msen.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

(c) is arguable from a design point of view.  however, since we're dealing
with structured text, it should be possible to structure a document (with
some labor) so that it looks useful in both contexts.

as to (b), the only useful definition of a tag that I have is how it shows
up on the screen.

my biggest argument is for (a).  or more precisely, for tags that are less
of a strict descriptive markup and more of a functional or structural
markup, so that I could mark things up as <question> ... </question> and
<answer> ... </answer> and then go later and define what those mean as far
as on screen presentation.  ideally this might lead to full support for
SGML and DTDs and all of those heavy-weight but powerful constructs.

the real answer might be "edit in a real SGML environment, then edit the
tags so they work with HTML browsers".  in that case what I'm really
asking for is design for a frequently asked questions DTD, and I'm
(currently) sorely lacking the tools needed to experiment my way to an answer.



On Tue, 3 Nov 1992, Tim Berners-Lee wrote:

>  (a) you need more variety of tags, or that
>  (b) the 24x80 representation of the existing tags is suboptimal, or that
>  (c) the task is impossible by its nature -- you must rewritethe document.




From emv@garnet.msen.com  Tue Nov  3 16:42:55 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12880; Tue, 3 Nov 92 16:42:55 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22480; Tue, 3 Nov 92 16:55:08 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mmQaE-00007hC@garnet.msen.com>; Tue, 3 Nov 92 10:54 WET
Date: Tue, 3 Nov 1992 10:50:41 -0500 (EST)
From: Edward Vielmetti <emv@garnet.msen.com>
Subject: Re: question and answer, style guide? 
To: Anthony Baxter <anthony@yoyo.cc.monash.edu.au>
Cc: Michel Dagenais <dagenais@vlsi.polymtl.ca>, www-talk@nxoc01.cern.ch
In-Reply-To: <9211031448.AA03638@yoyo.cc.monash.edu.au>
Message-Id: <Pine.3.05.9211031040.B20803-a100000@garnet.msen.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

there's a nice screen mode browser running. if you follow
	gopher://gopher.msen.com:70/
and go to 'Lots of interesting things', 'Special internet services', it's
in Scott Yanoff's list of things.  Or try
	ftp://rtfm.mit.edu/pub/usenet/alt.internet.services/
which should have a copy to.

i think it's at njit.edu somewhere, but if you chase either of these
pointers you'll find it

--Ed
	
On Wed, 4 Nov 1992, Anthony Baxter wrote:
> 
> I remember seeing a (development) version of a screenmode client that was
> quite nice. I cant find a reference to where it was now, does anyone know
> what happened to it? Is it still under development?
> 



From emv@garnet.msen.com  Tue Nov  3 16:50:32 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12932; Tue, 3 Nov 92 16:50:32 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23115; Tue, 3 Nov 92 17:02:46 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mmQhc-00007mC@garnet.msen.com>; Tue, 3 Nov 92 11:01 WET
Message-Id: <m0mmQhc-00007mC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: lamont view servers
Date: Tue, 03 Nov 92 11:01:46 EST
From: Edward Vielmetti <emv@msen.com>

Here's a pointer to some useful code for doing network-based queries
of large numerical datasets.  I would think this would be quite interesting
to the general crowd.

The license agreement, at least last time I read it, made it very difficult
for me sitting at a .com site to play with this stuff.  I will assume for
the sake of argument that anyone anywhere can run a dumb ascii client
against these things to see what they are without needing any licensing.

There is a real gap in the gopher / wais / world wide web paradigm of
network tools that none of them deal well at all with numbers.  If you
have an Oracle db full of stuff that you want to publish, this looks like 
quite a reasonable approach.

--Ed

------- Forwarded Message

	id AA11023; Tue, 3 Nov 92 09:50:44 EST
Date: Tue, 3 Nov 92 09:50:44 EST
From: menke@lamont.ldgo.columbia.edu (bill menke)
Message-Id: <9211031450.AA11023@lamont.ldgo.columbia.edu>
To: emv@msen.com
Subject: Re:  current list of view servers, project overview, etc
Status: RO
X-Status: 

The XGB manual is available by anonymous ftp to lamont.ldgo.columbia.edu
files
	pub/gb_instv3.1.part1.ps.Z and pub/gb_instv3.1.part2.ps.Z

The currect list of view servers is the view view_servers on chaos.ldgo.columbia.edu
and also the file
	pub/view_servers.asc.Z

The XGB system itself is also available by anonymous ftp, as described by
the EOS article.

No mailing lists are available.

View servers are now available for sybase, unify, db_vista and oracle
commercial database managers, plus two binary DBM's that I wrote, plus
ascii files.

The new version of XGB also supports raster servers, that is 'image'
as contrasted to 'parametric' data.  Three raster servers are available,
supporting three different image formats.

Columbia U. is willing to discuss licensing of XGB for commercial purposes.

Good Luck. Menke.

------- End of Forwarded Message


From timbl@www3.cern.ch  Tue Nov  3 17:23:08 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13161; Tue, 3 Nov 92 17:23:08 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26357; Tue, 3 Nov 92 17:35:12 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01616; Tue, 3 Nov 92 17:32:13 +0100
Date: Tue, 3 Nov 92 17:32:13 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211031632.AA01616@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Edward Vielmetti <emv@garnet.msen.com>
Subject: curses browser 
Cc: Anthony Baxter <anthony@yoyo.cc.monash.edu.au>,
        Michel Dagenais <dagenais@vlsi.polymtl.ca>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


On Wed, 4 Nov 1992, Anthony Baxter wrote:
> 

> I remember seeing a (development) version of a screenmode client that was
> quite nice. I cant find a reference to where it was now, does anyone know
> what happened to it? Is it still under development?
> 


telnet eies2.njit.edu	 (or   telnet 128.235.1.43)   Log in as www. A  
full-screen browser in New Jersey Institute of Technology.  USA.
Jim Whitescarever wrote it, and will release it subject to our getting the
W3 distribution terms sorted out, I think.

The curses browser is in the list of W3 prodcuts now, I shall put a pointer to  
the test site.

From raisch@cthulhu.control.com  Tue Nov  3 18:32:41 1992
Return-Path: <raisch@cthulhu.control.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13567; Tue, 3 Nov 92 18:32:41 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01614; Tue, 3 Nov 92 18:44:49 +0100
Received: by control.com (4.1/Spike-2.0)
	id AA04629; Tue, 3 Nov 92 12:42:31 EST
Date: Tue, 3 Nov 1992 12:32:24 -0500 (EST)
From: Robert Raisch <raisch@cthulhu.control.com>
Subject: Re: question and answer, style guide? 
To: Tim Berners-Lee <timbl@www3.cern.ch>
Cc: Edward Vielmetti <emv@msen.com>, www-talk@nxoc01.cern.ch
In-Reply-To: <9211031230.AA01398@www3.cern.ch>
Message-Id: <Pine.3.03.9211031222.O272-b100000@cthulhu.control.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 3 Nov 1992, Tim Berners-Lee wrote:

> >  I am not sure yet whether you can
> > design something that's optimally designed for a 24x80 ascii screen
> > and also for paper (probably not) but at least it'll be usable in both
> > contexts.
> 
> 
> Do you feel that
> 
>  (a) you need more variety of tags, or that
>  (b) the 24x80 representation of the existing tags is suboptimal, or that
>  (c) the task is impossible by its nature -- you must rewritethe document.
> 
> If (a), we should take that into account for HTML extentions.
> If (b), you can change the DefaultStyles.c built-in style sheet
> If (c), I agree. In principle. But In practice we need to comprompize.
> 
> 	Tim

The main goal of SGML and one which I believe it meets reasonably well is
the seperation of display issues from content issues.

Presentation issues can only be guessed at, never known.

Only by decoupling the presentation of information from it's organisation
can we hope to develop useful tools. (IMHO)

A simple example might be the rendering of a list.  How would you do it?

A "LIST" is nothing more than a collection of items.  There should be no
inherent assumptions as to how it might be rendered.

I could conceive of a block of text containing the first element, and an
indication that there were more elements available (via some user
interaction).

Or even the complete collapse of the list into just an indication of it's
existance, (a "jump").

The point should be (IMHO) that the rendering decision should ALWAYS be
left to the client.  Any rendering-centric portions of HGML should be
replaced by more general constructs.

Perhaps what we need is a WG to design the next generation of HGML?  Is
there such a beast already?

		</rr>
 --
I hate 3 things: Ignorance, Poverty, and Moving.  Well, maybe not in that order.



From connolly@pixel.convex.com  Tue Nov  3 18:37:03 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13584; Tue, 3 Nov 92 18:37:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01837; Tue, 3 Nov 92 18:49:17 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA26534; Tue, 3 Nov 92 11:48:26 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA17059; Tue, 3 Nov 92 11:48:23 -0600
Message-Id: <9211031748.AA17059@pixel.convex.com>
To: Edward Vielmetti <emv@garnet.msen.com>
Cc: Tim Berners-Lee <timbl@www3.cern.ch>,
        Robert Raisch <raisch@cthulhu.control.com>, www-talk@nxoc01.cern.ch
Subject: Re: question and answer, style guide? 
In-Reply-To: Your message of "Tue, 03 Nov 92 10:37:06 EST."
             <Pine.3.05.9211031003.A20803-b100000@garnet.msen.com> 
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="8<"
Date: Tue, 03 Nov 92 11:48:23 CST
From: Dan Connolly <connolly@pixel.convex.com>


--8<

>the real answer might be "edit in a real SGML environment, then edit the
>tags so they work with HTML browsers".  in that case what I'm really
>asking for is design for a frequently asked questions DTD, and I'm
>(currently) sorely lacking the tools needed to experiment my way to an answer.

I suggest the ICA toolset for experimenting your way to an answer.

That's how I came up with the HTML dtd -- or that's where I started.

You can point-and-click your way to a rough grammar, and then tell
it to write an SGML DTD. Then you can look at the DTD and get an
idea of what's going on. Then you hack a little, and voila!

Dan

--8<
Content-Description: archie query for "ICA-.*.tar.Z"
Content-Type: multipart/alternative; boundary="cut-here"

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z";
	SITE="slembe.ifi.uio.no";
	DIRECTORY="/pub/SGML/ICA";
	SIZE=1144389;
	PERMISSION=read-write

Content-Type: application/octet-stream;
	conversions=x-compress;
	type=tar;
	name="ICA-1.5.tar.Z"
X-Last-Modified: 19920720220500Z (1992 Jul 20 22:05:00 GMT)

<FTP host="slembe.ifi.uio.no" dir="/pub/SGML/ICA" name="ICA-1.5.tar.Z"
	 type="application" subtype="octet-stream" bytes="1144389">

slembe.ifi.uio.no:/pub/SGML/ICA/ICA-1.5.tar.Z
file://slembe.ifi.uio.no/pub/SGML/ICA/ICA-1.5.tar.Z
-rw-r--r--  1 ftp 1144389 1992 Jul 20 22:05:00 GMT ICA-1.5.tar.Z

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z";
	SITE="saqqara.cis.ohio-state.edu";
	DIRECTORY="/chameleon";
	SIZE=1144389;
	PERMISSION=read-write

Content-Type: application/octet-stream;
	conversions=x-compress;
	type=tar;
	name="ICA-1.5.tar.Z"
X-Last-Modified: 19920612084600Z (1992 Jun 12 08:46:00 GMT)

<FTP host="saqqara.cis.ohio-state.edu" dir="/chameleon" name="ICA-1.5.tar.Z"
	 type="application" subtype="octet-stream" bytes="1144389">

saqqara.cis.ohio-state.edu:/chameleon/ICA-1.5.tar.Z
file://saqqara.cis.ohio-state.edu/chameleon/ICA-1.5.tar.Z
-rw-r--r--  1 ftp 1144389 1992 Jun 12 08:46:00 GMT ICA-1.5.tar.Z

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z";
	SITE="rs3.hrz.th-darmstadt.de";
	DIRECTORY="/pub/text/sgml/ICA";
	SIZE=1144389;
	PERMISSION=read-write

Content-Type: application/octet-stream;
	conversions=x-compress;
	type=tar;
	name="ICA-1.5.tar.Z"
X-Last-Modified: 19920612144600Z (1992 Jun 12 14:46:00 GMT)

<FTP host="rs3.hrz.th-darmstadt.de" dir="/pub/text/sgml/ICA" name="ICA-1.5.tar.Z"
	 type="application" subtype="octet-stream" bytes="1144389">

rs3.hrz.th-darmstadt.de:/pub/text/sgml/ICA/ICA-1.5.tar.Z
file://rs3.hrz.th-darmstadt.de/pub/text/sgml/ICA/ICA-1.5.tar.Z
-rw-rw-r--  1 ftp 1144389 1992 Jun 12 14:46:00 GMT ICA-1.5.tar.Z

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z";
	SITE="ifi.uio.no";
	DIRECTORY="/pub/SGML/ICA";
	SIZE=1144389;
	PERMISSION=read-write

Content-Type: application/octet-stream;
	conversions=x-compress;
	type=tar;
	name="ICA-1.5.tar.Z"
X-Last-Modified: 19920720220500Z (1992 Jul 20 22:05:00 GMT)

<FTP host="ifi.uio.no" dir="/pub/SGML/ICA" name="ICA-1.5.tar.Z"
	 type="application" subtype="octet-stream" bytes="1144389">

ifi.uio.no:/pub/SGML/ICA/ICA-1.5.tar.Z
file://ifi.uio.no/pub/SGML/ICA/ICA-1.5.tar.Z
-rw-r--r--  1 ftp 1144389 1992 Jul 20 22:05:00 GMT ICA-1.5.tar.Z

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z";
	SITE="archive.cis.ohio-state.edu";
	DIRECTORY="/pub/chameleon";
	SIZE=1144389;
	PERMISSION=read-write

Content-Type: application/octet-stream;
	conversions=x-compress;
	type=tar;
	name="ICA-1.5.tar.Z"
X-Last-Modified: 19920612124600Z (1992 Jun 12 12:46:00 GMT)

<FTP host="archive.cis.ohio-state.edu" dir="/pub/chameleon" name="ICA-1.5.tar.Z"
	 type="application" subtype="octet-stream" bytes="1144389">

archive.cis.ohio-state.edu:/pub/chameleon/ICA-1.5.tar.Z
file://archive.cis.ohio-state.edu/pub/chameleon/ICA-1.5.tar.Z
-rw-r--r--  1 ftp 1144389 1992 Jun 12 12:46:00 GMT ICA-1.5.tar.Z

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z-split";
	SITE="NIC.SURA.NET";
	DIRECTORY="ARCHIE/HOST/ftp.uu.net/pub/text-processing/ICA";
	MODE=DIR;
	SIZE=512;
	PERMISSION=read-write

Content-Type: text/plain
X-Last-Modified: 19920806144700Z (1992 Aug 06 14:47:00 GMT)

<FTP host="NIC.SURA.NET" dir="ARCHIE/HOST/ftp.uu.net/pub/text-processing/ICA" name="ICA-1.5.tar.Z-split"
	 type="text" subtype="plain" bytes="512">

NIC.SURA.NET:ARCHIE/HOST/ftp.uu.net/pub/text-processing/ICA/ICA-1.5.tar.Z-split
file://NIC.SURA.NETARCHIE/HOST/ftp.uu.net/pub/text-processing/ICA/ICA-1.5.tar.Z-split
drwxr-xr-x  1 ftp 512 1992 Aug 06 14:47:00 GMT ICA-1.5.tar.Z-split

--cut-here
Content-Type: message/external-body;
	ACCESS-TYPE=ANON-FTP;
	NAME="ICA-1.5.tar.Z-split";
	SITE="NIC.SURA.NET";
	DIRECTORY="ARCHIE/HOST/unix.hensa.ac.uk/pub/uunet/pub/text-processing/ICA";
	MODE=DIR;
	SIZE=512;
	PERMISSION=read-write

Content-Type: text/plain
X-Last-Modified: 19920813072600Z (1992 Aug 13 07:26:00 GMT)

<FTP host="NIC.SURA.NET" dir="ARCHIE/HOST/unix.hensa.ac.uk/pub/uunet/pub/text-processing/ICA" name="ICA-1.5.tar.Z-split"
	 type="text" subtype="plain" bytes="512">

NIC.SURA.NET:ARCHIE/HOST/unix.hensa.ac.uk/pub/uunet/pub/text-processing/ICA/ICA-1.5.tar.Z-split
file://NIC.SURA.NETARCHIE/HOST/unix.hensa.ac.uk/pub/uunet/pub/text-processing/ICA/ICA-1.5.tar.Z-split
drwxr-xr-x  1 ftp 512 1992 Aug 13 07:26:00 GMT ICA-1.5.tar.Z-split

--cut-here--
--8<--


From timbl@www3.cern.ch  Wed Nov  4 15:34:17 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17858; Wed, 4 Nov 92 15:34:17 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09938; Wed, 4 Nov 92 15:45:48 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02170; Wed, 4 Nov 92 15:42:31 +0100
Date: Wed, 4 Nov 92 15:42:31 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211041442.AA02170@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Robert Raisch <raisch@cthulhu.control.com>
Subject: HTML
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> The point should be (IMHO) that the rendering decision should ALWAYS be
> left to the client.  Any rendering-centric portions of HGML should be
> replaced by more general constructs.

Absolutely. Pei's latest Viola allows ffor example a LISTING section to
be viewed as an embedded scrollable region.  There is nothing rendering-centric
in HTML.

> Perhaps what we need is a WG to design the next generation of HGML?  Is
> there such a beast already?

Those who have been interested in it have aired their views on this list.
Theer haven't been many concrete suggestions for different elements
(except for a fixed width format which allows embedded anchors).

Dan has done a lot of work cleaning it up.
I would like to see separate header and body sections,
so that document-wide info like the title, author, can be found easily
before the body. Of course, if one uses MIME, ther is the
mail header with From: and Subject: fields.
which could be used fro the header, i.e. take teh header out of the
HTML.

From davis@dri.cornell.edu  Wed Nov  4 22:37:10 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20453; Wed, 4 Nov 92 22:37:10 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA10754; Wed, 4 Nov 92 22:49:28 +0100
Received: by willow.tc.cornell.edu id AA01760
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 4 Nov 1992 16:48:34 -0500
Date: Wed, 4 Nov 1992 16:48:34 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199211042148.AA01760@willow.tc.cornell.edu>
To: wei@xcf.berkeley.edu, www-talk@nxoc01.cern.ch
Subject: improved printing of WWW files

If you can't quite manage to live without hardcopy, you may
wish sometimes to print WWW files.  I have written a couple
of scripts to do this.  They are particularly useful with
Pei Wei's excellent Viola WWW browser.

A tar archive is available for anonymous FTP:

dri.cornell.edu/pub/davis/print-www.tar

It contains:

README
print-www
print-www.l
html-to-latex
html2latex.sed (modified version of original CERN version)

The hardest part was writing the perl script to obtain documents
via http protocol - turns out you cant just run pipes through telnet.

The conversion from HTML to LaTex is not really robust yet - 
this  is doubly hard since there is no guarentee that the HTML
is legal.  But at least it works for my test cases.  No doubt
it will be improved in time.

best wishes


From timbl@www3.cern.ch  Thu Nov  5 09:46:07 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22865; Thu, 5 Nov 92 09:46:07 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13262; Thu, 5 Nov 92 09:58:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02508; Thu, 5 Nov 92 09:55:34 +0100
Date: Thu, 5 Nov 92 09:55:34 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211050855.AA02508@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Format conversion with NeXTStep 3.0
Reply-To: timbl@nxoc01.cern.ch

Here's an excerpt from the NeXT Nugget news digest, talking about
aspects of NeXTStep 3.0 which developers ought to take into account.
(I don't think WonderFormat is a MIME type ;-)



- Filter services
A Filter service is a new 3.0 type of Service which has no menu item
but supports the ability to convert a piece of data from one type to
another.  Every application can take advantage of filter services
when opening files (via +typesFilterableTo: if it can open a standard
type, like RTF) and when importing data via copy/paste or dragging
(via +imagePasteboardTypes).

Other applications can provide filter services:  for example, if you
have some code which converts your document format [the WonderFormat]
to RTFD, then you should provide this functionality as a filter
service.  Another application which understands RTFD but not
WonderFormat can still import WonderFormat documents and the filter
service will do the work of the conversion.  The other advantage of
providing a filter to ascii is that your documents then become
indexable by Digital Librarian.  See the 3.0 Appkit Release Notes and
the Pasteboard spec sheet for more information on:
+typesFilterableTo:, +newByFilteringFile:, +newByFilteringData:,
+newByFilteringTypesInPasteboard:.


From timbl@www3.cern.ch  Thu Nov  5 11:43:16 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23489; Thu, 5 Nov 92 11:43:16 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24644; Thu, 5 Nov 92 11:55:31 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02662; Thu, 5 Nov 92 11:52:33 +0100
Date: Thu, 5 Nov 92 11:52:33 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211051052.AA02662@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Jim Davis <davis@dri.cornell.edu>
Subject: Re: improved printing of WWW files
Cc: wei@xcf.berkeley.edu, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>  Date: Wed, 4 Nov 1992 16:48:34 -0500
>  From: Jim Davis <davis@dri.cornell.edu>
>  

>  If you can't quite manage to live without hardcopy, you may
>  wish sometimes to print WWW files.  I have written a couple
>  of scripts to do this.  They are particularly useful with
>  Pei Wei's excellent Viola WWW browser.
>  

>  A tar archive is available for anonymous FTP:
>  

>  dri.cornell.edu/pub/davis/print-www.tar

Also now available as info.cern.ch/pub/www/src/print-www.tar

> ...  

>  The hardest part was writing the perl script to obtain documents
>  via http protocol - turns out you cant just run pipes through telnet.
>
Why not use "www -source" ?

You say, in print-www, that:

# It is intended to
# be used from the Viola WWW browser but might he useful
# elsewhere too

Of course it's great from the line mode browser too, in which you can say

	source | print-www

or just
        setenv WWW_PRINT_COMMAND "print-www '%s' | lpr"

beforehand, and say PRINT in www.
 

Thanks for a cleaning up the .sed file, and doing the thing properly.


From bajan@mocha.cc.mcgill.ca  Mon Nov  9 10:43:44 1992
Return-Path: <bajan@mocha.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00359; Mon, 9 Nov 92 10:43:44 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16084; Sat, 7 Nov 92 19:34:54 +0100
Received: from mocha.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21181  (mail destined for www-talk@nxoc01.cern.ch) on Sat, 7 Nov 92 13:34:01 -0500
Received: by mocha.cc.mcgill.ca (4.1/SMI-4.1)
	id AA19022; Sat, 7 Nov 92 13:33:53 EST
Message-Id: <9211071833.AA19022@mocha.cc.mcgill.ca>
From: bajan@bunyip.com (Alan Emtage)
Date: Sat, 7 Nov 1992 13:33:53 -0500
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: uri@bunyip.com
Subject: URI agenda for Washington
Cc: nir@cc.mcgill.ca, iafa@cc.mcgill.ca, iiir@merit.edu, jkrey@isi.edu,
        rdhobby@ucdavis.edu, wg-isus@rare.nl, www-talk@nxoc01.cern.ch

This is a draft agenda for the newly created joint User Services/Applications
IETF WG on Uniform Resource Identifiers to meet in Washington week after
next. Please send any additions along for inclusion.

Attendees are reminded that this work will be performed in conjunction
with existing and newly created working groups (NIR, IIIR) and will
ultimately be placed on the Standards Track. 

Please recirculate this agenda to groups having an interest in this
discussion.

Personal observation: this should be an "interesting" session :-) 

--------------------------------------------------------
	IETF WG Uniform Resource Identifiers

Co-chairs: Peter Deutsch (peterd@bunyip.com)
	   Alan Emtage (bajan@bunyip.com)

1) Review of current charter making any changes deemed necessary for the
   final version.

2) Review and discussion of Tim Berners-Lee's (timbl@nxoc01.cern.ch)
   document on Uniform Resource Locators. [Note: Tim's announcement for
   this document is included at the end of this message].

3) Discussion of other components of a full URI.
	- The concept of what a URI looks like has been greatly expanded
	  past URI = URL + USRN with recent discussions. 
	- What components make up a URI
	- A lot of work is being done in the Library community and the
	  last thing we need is another standards conflagration. What
	  lines of communication should be established ?
	- Which parts can be tackled now, which should be put off until
	  later? What kind of timetable are we looking at ?
	- Can bodies be assigned to draw up the additional architecture?
	  Who ?

4) Other business

------------
-Alan



Document Availability:

-----------
Date: Fri, 30 Oct 92 17:58:08 +0100
From: Tim Berners-Lee <timbl@nxoc01.cern.ch>
To: nir@cc.mcgill.ca, wg-isus@rare.nl, uri@bunyip.com, www-talk@nxoc01.cern.ch
Subject: URLs - new document;      URL mail server


A new URL definition document is available at locations

	ftp://info.cern.ch/pub/ietf/url3.txt
	ftp://info.cern.ch/pub/ietf/url3.ps

The document has a few changes which were mentioned at the Boston
BOF -- please send anything I've forgotten to me ASAP for inclusion
befoer the Washington.

(Note old WWW clients require "file:" prefix instead of "ftp:" prefix
for FTP archive documents, but latest library allows either during transition  
period).
			----------

Documents may be retrieved by URL: by sending mail to 

listserv@info.cern.ch with a line containing the command SEND
followed by the URL of the document. If the document is in hypertext, the URLs  
of linked documents are listed on the end of the reply. If in doubt send  
message HELP to same address.

The software for the mail robot is available in ftp://info.cern.ch/pub/www/src

The software for the mail robot is available in ftp://info.cern.ch/pub/www/src

I won't be in DC but will expect a talk session to be set up with the  
meeting...   :-)


	Tim Berners-Lee


From davis@dri.cornell.edu  Mon Nov  9 20:56:04 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03652; Mon, 9 Nov 92 20:56:04 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02122; Mon, 9 Nov 92 21:08:46 +0100
Received: by willow.tc.cornell.edu id AA09687
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Mon, 9 Nov 1992 15:08:24 -0500
Date: Mon, 9 Nov 1992 15:08:24 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199211092008.AA09687@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: can an HTTP server determine identity of client?

It is clear that the HTTP protocol per se provides no means
for the server to determine the identity of the user on
the client machine, or even the name of the client machine.
But (I ask in all ignorance of Unix) is there another way
for the server to get this information, perhaps by making
calls to a lower level of the TCP/IP protocol?

I would like to make an HTTP server that provided differing
levels of access to those within and without Cornell.
I regret this must be so because some of the databases
we have here can not be released outside Cornell.

From rik@daneel.rdt.monash.edu.au  Mon Nov  9 23:30:34 1992
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04483; Mon, 9 Nov 92 23:30:34 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09845; Mon, 9 Nov 92 23:43:11 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA22309; Tue, 10 Nov 92 08:42:22 +1000
Message-Id: <9211092242.AA22309@daneel.rdt.monash.edu.au>
To: www-talk@nxoc01.cern.ch
Subject: Re: can an HTTP server determine identity of client? 
In-Reply-To: Your message of "09 Nov 92 15:08:24 EST."
             <199211092008.AA09687@willow.tc.cornell.edu> 
Date: Tue, 10 Nov 92 09:42:21 -1000
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

> It is clear that the HTTP protocol per se provides no means
> for the server to determine the identity of the user on
> the client machine, or even the name of the client machine.
> But (I ask in all ignorance of Unix) is there another way
> for the server to get this information, perhaps by making
> calls to a lower level of the TCP/IP protocol?
> 
> I would like to make an HTTP server that provided differing
> levels of access to those within and without Cornell.
> I regret this must be so because some of the databases
> we have here can not be released outside Cornell.

I am doing this at the moment at my site.  I have allocated two ports
to http, and allow access to one port from everywhere, and access to
the other only from within my organisation.  The access control is
done with the package log_tcp.  You can get log_tcp to return a
message saying "This is for internal use only", or something like that
on the restricted port.

You can have links back and forward across the two ports, without any
trouble, but only the internal hosts can access the restricted port.

Let me know if you want specific information about configuration
files, etc.

rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au         || Systems Programmer
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH) || and Administrator
Faculty of Computing and Information Technology,   || Vic. Institute of
Caulfield Campus, Monash University, Australia     || Forensic Pathology

From timbl@www3.cern.ch  Tue Nov 10 14:50:14 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15449; Tue, 10 Nov 92 14:50:14 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04946; Tue, 10 Nov 92 15:02:55 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00461; Tue, 10 Nov 92 14:59:06 +0100
Date: Tue, 10 Nov 92 14:59:06 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211101359.AA00461@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: can an HTTP server determine identity of client?
Reply-To: timbl@nxoc01.cern.ch


Jim,

The server can't access the user name but it can and does know the
host internet address.  This is available in a global string

 extern char * HTClientHost;

if I remember rightly. Any routine in the server can access this.
It's used for logging by the basic daemon with the -l option for example.

The string is a number like "128.141.201.74".  If Cornell has a limited
number of domains then the program could check this string against
a number of templates. Otherwise, you could check the hostname
by doing a gethostbyaddr or whatever call to the nameserver.
There is a trap here in that, although the routine will return fast
for local addresses, it can take a long time for remote addresses.
As you are forced to do the lookup before delivering the data, this
will delay every request.  You could of course keep your own cache
of machine names. But sticking at the number level might be the most
practical way.

The new protocol will have hooks to determine allow the client to specify
a user name, mail address, etc, but of course the internet address
is more reliable than anything inserted by the client.

We have a philosophy that the same doc id should always return the same
document, or an error, no matter who asks. This preserves the usefulness
of quoting the document id. This means that you shouldn't just miss out
links from a document when the person is not allowed to follow them.
It is better to have a note, heading, etc to distinguish private from
public things, and then let an attempt to retrieve private things return
an error.

	Tim





From timbl@www3.cern.ch  Tue Nov 10 16:33:46 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16599; Tue, 10 Nov 92 16:33:46 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA17370; Tue, 10 Nov 92 16:46:27 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00530; Tue, 10 Nov 92 16:42:26 +0100
Date: Tue, 10 Nov 92 16:42:26 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211101542.AA00530@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Strategy for merging NIR applications
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

At the end are some condensed thoughts about directions for merging  
applications.

|  Date: Tue, 03 Nov 92 14:08:54 CST
|  From: Dan Connolly <connolly@pixel.convex.com>
|  

|  >> Dan:
|  >>     Should WAIS clients grok URLs? I don't see any need.  Similarly for
|  >>     gopher clients.
|  > Tim:
|  >	If you want to keep the WAIS and Gopher worlds totally distinct,
|  >	then no.  But who wants to have all these separate clients around?
|  >	Noone: that is the big user puzzlement with NIR now -- why so
|  >	many systems when they all do the same thing? The first step
|  >	toward merging existing systems, *AND* allowing for future systems
|  >	smarter than the ones we have thought of now, is the URL.
|  Dan:
|  Well, you took the bait, but you didn't run with it very far.
|  "The first step towards merging..." -- so you _do_ have a deployment
|  strategy in mind. You just didn't put it in the RFC.

(Can you punt bait?)

The RFC is to define one piece of the whole. It is most important to
keep the peices distinct, or the whole thing will be too rigid. I suppose we  
could propose "All the world should use W3 and we should all discuss what W3  
should be like next" but that would never fly. We see that URLs are essential  
to allow communication between applications and different environments and for  
the introduction of new namespaces.

|  I'd like to see more motivation in the form of a strategy or at
|  least a vision for how this whole thing comes together. I'm trying
|  to piece it together myself, but I'm not having much luck.

That may be because the bits aren't available.  Like a global solid reliable
directory system, for example, and a global payment mechanism or two, and  
athentication systems to support it.  These just aren't globally deployed yet  
so we will have to wait for them and then plug them in.  What we do have is the  
internet, TCP/IP and DNS and we have to put hooks for everything else.

|  For example, I really don't see why different protocols should
|  share addressing schemes, or why the sheme:path syntax should
|  go any further than the WWW project.

It is the scheme:path syntax which allows the bridge. It need not be used
in closed applications, but in open applications it is needed. W3 will be able
to incrementally move to new name spaces. If other apps don't, too bad.
But I think they do.

|  >	Yes. Certainly a useful aspect of URLs. But not the only.
|  >	What about the URL pasteboard type? To allow "cut reference"
|  >	and "paste link" to work between applications?
|  

|  I've been trying to work out a design for this, and URLs don't seem
|  to help much. If you copy a WAIS URL and paste it into another
|  client, that client has to grok WAIS protocol in order to use it.

Or have access to any WAIS engine. There are 100 ways of keeping a
register for a user for what applications can handle what kinds of
namespace.  This will probably be something which is more difficult
to standardize on, as NeXT and Windows and Motif etc will all have different  
schemes for registering application capabilities, and different  
inter-application messaging techniques.

There is some analogy between capabilities to deal with UDIs and capabilities  
to deal with data formats here ... Mark Litwack (are you there, Mark?)
had a scheme in which the two merged.

|  Or it has to use a gateway. If it uses a gateway, it has to translate
|  the WAIS name into something suitable to that gateway, which is
|  something you said you didn't think was practical.

I don't think the client has to translate anything necessarily.
The http protocol allows one to send over a URL including the
prefix, which need not be http:.  For a protocol which does not deal
in generic URLs, some translation would be necessary.

|  Anyway, if you're
|  going to define a gateway system, then define a gateway system, not
|  just an addressing syntax.

The gateway system is a time differential of the set of protocols used.
It will always change to reflect the movements between protocols. I agree
that the HTTP protocol could perhaps have something in the spec to point out  
that the full UDI may be sent to a gateway.

|  I'm trying to figure out how URLs complete the picture, but I don't
|  see it.
|  


There will be a few things in the picture. URLs are the most important next  
step now, a timely requeirement for commonality. That's all. They will not  
solve all the problems.

You want a merging strategy. Suppose it is as follows, off the top of my head.

			  MERGING STRATEGY

The metastrategy fro developing strategies is to first, make a model of
a superset of the functionality of the various systems, then design protocols  
to implement them, then make applications which use both old and new. Beware  
that merging all the applications onto one is only one as seen from the user,  
hopefully there would be separately developed products on there with messaging  
between them. 


	Merging WWW and WAIS and Z39.50:

A new HTTP2 protocol is defined, back-compatible with the current one.
It involves sending a request which is a particular format. There are MIME-like  
formats defined for a simple document request, a basic WAIS-like query, and if  
necessary other Z39.50 queries. This means establishing a mapping between the  
Z39.50 parameters and an ASCII internet-mail-like format. We make the set of  
query types as open as the set of document format types and encoding methods,  
and allow for a registery of names like IANA.  The formats acceptable to the  
client are sent with the request [as mail header lines or in the body?].
The query types acceptable to a server are returned by the server when a  
queryable object is referenced.

We look at the parameters necessary for this process and add them to the WAIS  
protocol, so that Z39.50++ becomes a binary (and therefore perhaps more  
efficient) version of HTTP2. The binary and telnet-style versions run  
side-by-side, with fairly simple table-driven interfaces. The telnet version  
will be useful becasue of all those perl servers which will be eth leading  
edge.

	Merging with SQL:

This model will engulf query/retrieve systems, including e.g. SQL queries,
and allow for upgrade for new ideas of remote operations. In fact, the
query type will generalize to a typed set of input parameters for a arbitrary  
operation [method] on a remote object with the given URL, and so in principle  
can access a globally distributed OODB. In order to get a more manipulable  
version of the results of an SQL query or arbitrary OO operation, we will  
probably need a data tagging system [maybe ASN/1 based?] for structured  
[alpha]numeric data such as SQL handles, but this is just another data format,  
not our problem now. The question of converting data formats on parts of  
multipart messages [structures] will be addressed, nothing uinsurmountable. We  
would obviously like to see a mapping from any OOP's identifier space into URL  
space.

	Merging with Mail and News:

Now look at what we have. The presentation part of the W3 client is just the  
presentation part of MIME, with an added hypertext data class. MIME really  
should have picked HTML instead of text/richtext, but that we can add.
Now we address the intruiging area of the merging of mail, news, and NIR.
The same application must obviously be able to handle all of these, and they  
should all look the same to the user. That is, if you link an article to a list  
of articles, post it to a newsgroup, or mail it to a mailbox, the operation  
(adding message to list of messages) is beasically the same, and should be sen  
as such. Note that MIME has to be augmented with the addition of query type  
registration, there needs to be a format for the summarizing of capabilities  
(mailcap information) in with requests. The mailcap information needs some  
extension. A spinoff is that the HTTP protocol should run over mail too, which  
though excruciatingly slow is neat as a lot of people still use mail servers  
;-).  This occured to me when implementing
the W3 server.

The mechanisms underneath are currently many and varied in order to be optimal  
in the extreme cases of personal messaging, news broadcasting, and archive  
serving. However, as cache coherency protocols are added to HTTP, the functions  
like "give me a list of what is new in the following domain" will approach NNTP  
functions.  Within time it will become a decision made on the fly by the system  
as to whether a document [message, article] is held, sent, or broadcast. So I  
expect the protocols to converge.  An important issue here will be  
charactization of basic operations on sets [maillistarchives, newsgroups,  
directories].  The engines which speak the new combined protocol will have to  
speak the old ones too for back-compatibilty for a few years. This is
a smooth trasnsition strategy. We're not talking about vast librares, just  
supporting SMTP and NNTP and HTTP for a while (they are very similar) as well  
as a superset protocol.

	Stargazing

What else do we want to merge in?  Name servers of course are just HTTP2
servers which return "forward" results. File systems, I expect, too, will veer  
in the general direction. Alex-like systems will map the retrieval subset onto  
the subset. Maybe soft links could generalise to URLs. Maybe some smart  
manufacturers will allow a soft link to be a URL.  If not, file suffix which  
indicates a query or just .MIME would be enough to indicate that the document  
contains type information and could be a pointer or a query. However, there is  
basic functionality which the file sysyem does not support (That is, anything  
other than open, read write and close: no arbitrary methods here) so we will  
never map everything to fopen(). But by that time we'l all be using our  
favorite OO systems anyway. The exciting part will be to see whether the GUI  
builders will get to the point that the whole OO application can by built  
graphically, bridging the gap between the app builders and real programs (Can  
you imagine progamming in perl with a mouse? in Eiffel?)

	Tim
	

__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From emv@garnet.msen.com  Tue Nov 10 21:01:29 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18114; Tue, 10 Nov 92 21:01:29 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12927; Tue, 10 Nov 92 21:14:13 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mp1xh-00009MC@garnet.msen.com>; Tue, 10 Nov 92 15:13 WET
Message-Id: <m0mp1xh-00009MC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: proposed registration of type 'text/html' for MIME
Date: Tue, 10 Nov 92 15:13:07 EST
From: Edward Vielmetti <emv@msen.com>

Here's the form for registering 'text/html' partly filled in, from RFC
1341.

I don't think this needs a ton of work, just to fill in a few of the
references.  As we get some operations experience with it (and some
applications support!) I could imagine putting more frobs on it.  Not
yet tho.

To: IANA@isi.edu
Subject:  Registration of new MIME content-type/subtype

MIME type name: 
	text
MIME subtype name: 
	html
Required parameters: 
	none
Optional parameters: 
	left open for future study.  

	Any additional parameters should match up with existing HTML
	constructs, so that e.g. the parameter
		title="Making links in the web"
	would be functionally equivalent to an HTML preamble of
		<title>Making links in the web</title>
Encoding considerations:
	HTML text may contain ISO Latin-1 characters or other 8 bit
	values; if so the text should be wrapped with one of the
	standard MIME 8 bit encodings.
Security considerations:
	HTML documents may contain embedded information used to 
	instruct browsers and viewers to execute queries on remote
	databases.  Some HTML browsers have included support for
	embedded command languages.  Such facilities should be used
	with care.
Published specification:
	"The HTTP Protocol as Implemented in W3", avaiable for
	anonymous ftp from ftp://info.cern.ch/pub/doc/www/http.txt.  
	Describes the HTTP interactive access protocol and the tags used
	in HTML documents.

	"The WWW Book", from
	ftp://info.cern.ch/pub/doc/the_www_book.txt.

	"Universal Document Identifiers on the Network", OSI-DS-XXX,
	from XXX.

Person & email address to contact for further information:
	(Tim, you want to be named on this?)

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From connolly@pixel.convex.com  Wed Nov 11 00:26:23 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18947; Wed, 11 Nov 92 00:26:23 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29092; Wed, 11 Nov 92 00:39:08 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA25723; Tue, 10 Nov 92 17:38:21 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA02403; Tue, 10 Nov 92 17:38:20 -0600
Message-Id: <9211102338.AA02403@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed registration of type 'text/html' for MIME 
In-Reply-To: Your message of "Tue, 10 Nov 92 15:13:07 EST."
             <m0mp1xh-00009MC@garnet.msen.com> 
Date: Tue, 10 Nov 92 17:38:19 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Here's the form for registering 'text/html' partly filled in, from RFC
>1341.

I strongly suggest we bring the definition of HTML into conformance
with the SGML standard before we register it with the IANA.

>Published specification:
>	"The HTTP Protocol as Implemented in W3", avaiable for
>	anonymous ftp from ftp://info.cern.ch/pub/doc/www/http.txt.  
>	Describes the HTTP interactive access protocol and the tags used
>	in HTML documents.

This is the HTTP document, not the HTML document:

     This document defines the Hypertext Transfer protocol (HTTP) as
     currently implemented by the WorldWideWeb initaitive software.

The HTML document is: http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
an old version of which is contained in http.txt.

In any case, both documents mention some relationship between HTML and
SGML which is not formally defined:

   The hypertext mark-up language is an SGML format. This defines the
   basic syntax used. The particular language, the set of tags and the
   rules about their use, and their significance is not part of the
   SGML standard. There being no standard on this, we have adopted a
   set which seems sensible. We call them HTML -- hypertext markup
   language. HTML is not an alternative to SGML, it is a particular
   format within the SGML rules (an SGML "DTD").

The standard is very clear on this kind of thing. [I just got myself a
copy, so I can quote it:]

	4.103 (document) type declaration: A markup declaration that
	contains the formal specification of a document type
	definition.

	4.104 document type delcaration subset: The element, entity,
	and short reference sets occuring within the declaration
	subset of a document type declaration.

	4.105 document (type) definition: Rules, determined by an
	application, that apply SGML to the markup of documents of a
	particular type. A document type definition includes a formal
	specification, expressed in a document type declaration, of
	the element types, element relationships, and attributes, and
	references that can be represented by markup. It thereby
	defines the vocabulary of the markup for which SGML defines
	the syntax.

So it seems that the HTML DTD is missing the "formal specification."
I have written a document type declaration subset that matches HTML as
currently defined and implemented, with a few exceptions (most
importantly, the PLAINTEXT tag). See
http://info.cern.ch/hypertext/WWW/MarkUp/HTML.dtd

Most existing HTML documents need only small modifications to bring
them into conformance (quote attribute values, add the <!DOCTYPE ...>
prologue). And the existing WWW browser parses conforming documents
just fine.

     Currently HTML documents are transmitted without the normal SGML framing
     tags, but if these are included parsers will ignore them.

I don't know what "the normal SGML framing tags" are. An SGML document
has three parts: the SGML declaration, the prologue, and the instance.
It is common in SGML applications to use an implied SGML declaration
and include the prologue by reference (kinda like an #include
directive in C.) but without these "framing tags," it's just not an
SGML document.

Besides, it's very little work to add the line:

<!DOCTYPE HTML SYSTEM>

at the beginning of HTML documents.

More non-conforming stuff in Markup.html:

Plaintext

   This tag indicates that all following text is to be taken litterally, up to
   the end of the file.  Plain text is designed to be represented in the same
   way as example XMP text, with fixed width character and significant line
   breaks. Format:
   

                <PLAINTEXT>

   This tag allows the rest of a file to be read efficiently without parsing.
   Its presence is an optimisation. There is no closing tag.

This should be moved outside the definition of HTML. It should just be
part of the HTTP protocol: if the server starts the response with
<PLAINTEXT>, what you're getting is plain text, not SGML.

Another problem:

Example sections

       The text may contain any ISO Latin printable characters, including the
          tag opener, so long as it does not contain the closing tag in full.

This doesn't fit in SGML. The ETAGO delimiter ("</") ends a CDATA
section.

A clarification:

Paragraph

   This tag indicates a new paragraph. The exact representation of this
   (indentation,  leading, etc) is not defined here, and may be a function of
   other tags, style sheets etc. The format is simply
   

        <P>

   (In SGML terms, paragraph elements are transmitted in minimised form).

The implementation suggests that the <P> tag marks an empty element, a
paragraph separator, rather than allowing minimization in the form of
an omitted end tag, </P>.



We could even go so far as to call WWW an SGML application:

	 4.279 SGML Application: Rules that apply SGML to a text
	 processing application. An SGML application includes a formal
	 specification of the markup constructs used in the
	 application, expressed in SGML. It can also include a
	 non-SGML definition of semantics, application conventions,
	 and/or processing.

	 Note 2 The formal specification of an SGML application
	 constitutes the common portions of the documents processed by
	 th application. These common protions are frequently made
	 available as public text.

In other words, ftp://info.cern.ch/pub/doc/the_www_book.txt would
serve as the "non-SGML definition." [by the way: I could only find
postscript and LaTeX versions of the book: no txt file.] The "common
portion" is html.dtd (we could obtain a public text identifier for
it...).

If we want to do this (define an SGML application) section 15.5
requires this statement to be plastered all over the place:

	 An SGML Application Conforming to International Standard
	 ISO 8879 -- Standard Generalized Markup Language

If we're gonna use SGML, why not do it right?
 
Dan




From emv@garnet.msen.com  Wed Nov 11 00:46:36 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19016; Wed, 11 Nov 92 00:46:36 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29681; Wed, 11 Nov 92 00:59:18 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mp5Tc-00009TC@garnet.msen.com>; Tue, 10 Nov 92 18:58 WET
Message-Id: <m0mp5Tc-00009TC@garnet.msen.com>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed registration of type 'text/html' for MIME 
In-Reply-To: Your message of Tue, 10 Nov 92 17:38:19.
             <9211102338.AA02403@pixel.convex.com> 
Date: Tue, 10 Nov 92 18:58:17 EST
From: Edward Vielmetti <emv@msen.com>

Thanks for the message, Dan.  A few points.

I am not comfortable referencing documents (in an IETF message) that
are available only via the system in which I'm trying to document.
I.e. for the purpose of conveying to the IETF what all we're up to
it would be best to have files in the anonymous FTP area and rendered
in ASCII.  

Calling HTML an "SGML application" is not a bad long term plan.  I
fear there's some risk in ease of implementation from
	Content-type: text/sgml; dtd="(string that identifies html.dtd)"
compared to
	Content-type: text/html
and as such I'd prefer to not haul in all of the SGML standard in the
description of the system, not right up front at least.  Better to
spec something that you can deliver and play with rather than stretch
things out to their limits.  

Dan, if 
	http://info.cern.ch/hypertext/WWW/MarkUp/HTML.dtd
is in fact something that should get a "public text identifier" (some
kind of ISBN number?) then we should do it.  That would be a very
useful document to reference in the comments section.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From connolly@pixel.convex.com  Wed Nov 11 01:38:10 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19113; Wed, 11 Nov 92 01:38:10 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07932; Wed, 11 Nov 92 01:50:53 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA28223; Tue, 10 Nov 92 18:50:03 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA13695; Tue, 10 Nov 92 18:50:01 -0600
Message-Id: <9211110050.AA13695@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed registration of type 'text/html' for MIME 
In-Reply-To: Your message of "Tue, 10 Nov 92 18:58:17 EST."
             <m0mp5Tc-00009TC@garnet.msen.com> 
Date: Tue, 10 Nov 92 18:50:01 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Thanks for the message, Dan.  A few points.
>
>I am not comfortable referencing documents (in an IETF message) that
>are available only via the system in which I'm trying to document.
>I.e. for the purpose of conveying to the IETF what all we're up to
>it would be best to have files in the anonymous FTP area and rendered
>in ASCII.  

Point taken. But we can certainly come up with an ASCII version of
http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html . There's no
need to use the HTTP document.

And the HTML DTD is a plain ASCII document as is. I'm not sure
if it's available via ftp, but certainly that's not an insurmountable
obstacle.

>Calling HTML an "SGML application" is not a bad long term plan.  I
>fear there's some risk in ease of implementation from
>	Content-type: text/sgml; dtd="(string that identifies html.dtd)"
>compared to
>	Content-type: text/html
>and as such I'd prefer to not haul in all of the SGML standard in the
>description of the system, not right up front at least.  Better to
>spec something that you can deliver and play with rather than stretch
>things out to their limits.  

Uuugh! Do I have to write a "Misconceptions about SGML" essay? I
never said anything about content-type: text/sgml. I did talk
about hauling the SGML standard in, but that only requires the few
changes I pointed out. There's no need to implement a whole SGML parser.

But I'd say ISO 8879 + html.dtd is a better spec for the syntax of
HTML than any english description we can come up with in the near term.
And the existing WWW code works just fine on conforming documents. [It
also groks non-conforming documents, but I don't see any crime in that.]

After all, I think this is the intent of the designers of HTML:

	HTML is not an alternative to SGML, it is a particular
	format within the SGML rules (an SGML "DTD"). [http.txt]


And, if we start to enforce SGML compliance, we may be able to do things
like using SGML editors, translators, browsers, etc. If we don't enforce
compliance, we might as well not use SGML at all!

>Dan, if 
>	http://info.cern.ch/hypertext/WWW/MarkUp/HTML.dtd
>is in fact something that should get a "public text identifier" (some
>kind of ISBN number?) then we should do it.  That would be a very
>useful document to reference in the comments section.

From what I can tell, there are three kinds of public text identifiers:
ISO ids, registered owner ids, and unregistered owner ids. The first
kind refer to ISO documents. The second category is for documents by
ISO members, I guess. And as far as I can tell, the third category
is anybody's game (kinda like x- identifiers.)

They look like this:

-//unregistered owner//class name//lang

The class is DTD. The lang is probably EN (english). The owner and
name are pretty much up for grabs. Usually the country is included
in the owner, even for unregistered owners.

So here's a stab:

-//USA-IANA//DTD HTML//EN

or, in context:

<!DOCTYPE HTML PUBLIC "-//USA-IANA//DTD HTML//EN">

But perhaps CERN, rather than IANA should be the owner.

Dan


From connolly@pixel.convex.com  Wed Nov 11 02:11:20 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19202; Wed, 11 Nov 92 02:11:20 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16024; Wed, 11 Nov 92 02:24:04 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA29526; Tue, 10 Nov 92 19:23:14 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA14979; Tue, 10 Nov 92 19:23:13 -0600
Message-Id: <9211110123.AA14979@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: indexes as links rather than documents
Date: Tue, 10 Nov 92 19:23:12 CST
From: Dan Connolly <connolly@pixel.convex.com>

I keep running across interesting bits of evidence that tell me that
indexes should be a type of link rather than a type of document.

In the current WWW model, an index is a document with an <ISINDEX>
tag. The browser displays the document, recognizes the <ISINDEX> tag,
and provides a search/find/keyword command. The user invokes the
search command and supplies the seed words. The browser conducts the
search transaction and displays the results. Then the user chooses
from the results.

In the model I prefer (which is used by gopher currently), and index
is an anchor with an INDEX attribute. The user selects the anchor, and
the browser prompts for seed words. The user supplies the seed words,
and the browser conducts the transaction as above.

In the WWW model, I run into lots of documents that just say "this is
a searchable index." Some index documents have instructions and
summaries of contents, but most are generated by gateways.

The WWW model actually fits inside the gopher model: where you would
use a document with an <ISINDEX> tag, use a document with an INDEX
anchor.

But the gopher model is more versatile. You can have one document
point to multiple indexes. You can have one set of instructions for
lots of indexes.

For example:

	WAIS based information

Click here[1] for instructions.

	directory of servers	search[2] describe[3]
	RFC's			search[4] describe[5]
	README's		search[6] describe[7]

which might look like:

<!DOCTYPE HTML SYSTEM>
<TITLE>WAIS based information</TITLE>
<a HREF="wais_help.html">Click here</a> for instructions.
<p>
<dl>
<dt>directory of servers
<dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
<a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>

...

It's easy enough to support the current model for backwards
compatibility, but I think the concept of an index as a type
of link makes more sense than indexes as a type of document.

Thoughts?

Dan



From emv@garnet.msen.com  Wed Nov 11 04:53:32 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19707; Wed, 11 Nov 92 04:53:32 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA27201; Wed, 11 Nov 92 05:06:15 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mp9KZ-00009JC@garnet.msen.com>; Tue, 10 Nov 92 23:05 WET
Message-Id: <m0mp9KZ-00009JC@garnet.msen.com>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch, wais-talk@quake.think.com
Subject: Re: indexes as links rather than documents 
In-Reply-To: Your message of Tue, 10 Nov 92 19:23:12.
             <9211110123.AA14979@pixel.convex.com> 
Date: Tue, 10 Nov 92 23:05:12 EST
From: Edward Vielmetti <emv@msen.com>

  I keep running across interesting bits of evidence that tell me that
  indexes should be a type of link rather than a type of document.

  <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
  <a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
  
Careful, representing WAIS servers is tricky.  In the gopher world,
the wais .src files are totally hidden from the client, and the links
look just like any other index

Name=Search journalism periodicals
Type=7
Port=70
Path=waissrc:/.wais/journalism.periodicals.src
Host=dewey.lib.ncsu.edu

Whereas in the W3 world the equivalent information would be like

Type=wais
Port=3041
Host=julian.uwo.ca
Path=journalism.periodicals

(e.g) href=wais://julian.uwo.ca:3041/journalism.periodicals?

Which is "better"?  Well, you win and you lose.  The Gopher approach
binds the gateway tightly to the WAIS server, so there's really no way
to see where the service "really" is, and in particular no way to make
sure that a query to a local service doesn't rebound off some machine
a long ways away.  The WWW approach (currently) rebounds everything
off of Switzerland - is anyone else running a WWW_to_WAIS gateway? -
but it leaves open the option to invoke a local WAIS engine.

What happens if (say) the journalism folks at the University of
Western Ontario decide to move their server?  Presumably they update
the directory of servers entry; those sites with gopher-based links
pick up a copy of the new .src file, and other servers with links
don't have to do anything special to make an update.  But those with
WWW links embedded somewhere in their document need to update them
(bad).

I've thought there might be some use to have the common construct
	search the directory of servers for "journalism", then
	search all the sources you get back from that for "watergate"
all nailed down into one reference link and one operation.  I do that
kind of search all the time and it's just not fair that it takes
multiple steps.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB



From connolly@pixel.convex.com  Wed Nov 11 05:00:58 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19738; Wed, 11 Nov 92 05:00:58 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28940; Wed, 11 Nov 92 05:13:41 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA06889; Tue, 10 Nov 92 22:12:51 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA18354; Tue, 10 Nov 92 22:12:50 -0600
Message-Id: <9211110412.AA18354@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: www-talk@nxoc01.cern.ch, wais-talk@quake.think.com
Subject: Re: indexes as links rather than documents 
In-Reply-To: Your message of "Tue, 10 Nov 92 23:05:12 EST."
             <m0mp9KZ-00009JC@garnet.msen.com> 
Date: Tue, 10 Nov 92 22:12:50 CST
From: Dan Connolly <connolly@pixel.convex.com>


>  I keep running across interesting bits of evidence that tell me that
>  indexes should be a type of link rather than a type of document.
>  
>Careful, representing WAIS servers is tricky.  In the gopher world,
>the wais .src files are totally hidden from the client, and the links
>look just like any other index

I can see how this is relavent to the syntax of WWW addresses for
WAIS indexes, but I don't see how it relates to my argument that
indexes should be links rather than nodes (i.e. being an index should
be an attribute of an anchor element, not of a document).

I didn't mean to suggest any changes in the WWW addressing scheme.
If my examples don't fit the current syntax, just pretend they do.

Dan


From timbl@www3.cern.ch  Wed Nov 11 17:32:44 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01291; Wed, 11 Nov 92 17:32:44 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03644; Wed, 11 Nov 92 17:45:30 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03391; Wed, 11 Nov 92 17:41:37 +0100
Date: Wed, 11 Nov 92 17:41:37 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211111641.AA03391@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Apologies for down time
Reply-To: timbl@nxoc01.cern.ch



info.cern.ch has been unreachable for large parts of several days  
recently (or, if reachable, it has been unusable). This is because it  
has too much reliance on an ULTRIC file server which has had DEC  
engineers running round trying to find hardware problems. I hope the  
problemis fixed now, but we will take steps to make info less dependent  
on it in the future.

	Tim


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From timbl@www3.cern.ch  Thu Nov 12 17:10:25 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06590; Thu, 12 Nov 92 17:10:25 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06372; Thu, 12 Nov 92 17:23:13 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03876; Thu, 12 Nov 92 17:19:16 +0100
Date: Thu, 12 Nov 92 17:19:16 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211121619.AA03876@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Edward Vielmetti <emv@msen.com>
Subject: Re: proposed registration of type 'text/html' for MIME
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Here's the form for registering 'text/html' partly filled in, from RFC
> 1341.

> I don't think this needs a ton of work, just to fill in a few of the
> references.  As we get some operations experience with it (and some
> applications support!) I could imagine putting more frobs on it.  Not
> yet tho.

OK, good idea. Here is a 2nd draft.  I have changed:

We restrict it to 7 bit, any 8 bit use is cheating and causes unpredictable  
things to happen. SGML provides for funny character encoding like &eacute; and  
things. We could also make the base character set a parameter (for the Fins).

Should we put a limit on line length? Do we need one to prevent an
encoding system from being mandatory for all HTML documents?

I have put a ref to the HTML spec rather than the HTTP spec. I'll
upgrade that to include the DTD and make it more RFCish (70 characters wide and  
stuff ;-)

_______________________________________________________
To: IANA@isi.edu
Subject:  Registration of new MIME content-type/subtype text/html

MIME type name: 

	text
MIME subtype name: 

	html
Required parameters: 

	none
Optional parameters: 

	left open for future study.  


	Any additional parameters should match up with existing HTML
	constructs, so that e.g. the parameter
		title="Making links in the web"
	would be functionally equivalent to an HTML preamble of
		<title>Making links in the web</title>
Encoding considerations:

	HTML text should be restricted to ASCII printable characters
	unless an extended character set is specfified in an
	optioinal parameter (subject for future study). There is no
	limit on line length.

Security considerations:

	HTML documents may contain embedded information used to 

	instruct browsers and viewers to execute queries on remote
	databases.  Some HTML browsers have included support for
	embedded command languages.  Such facilities should be used
	with care.

Published specification:

	"Hypertext Markup Language", Tim Berners-Lee, CERN, 1992. 

	available as http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
	or as by anonymous FTP from ftp://info.cern.ch/pub/doc/www/html.txt

  See also:
	
	"The HTTP Protocol as Implemented in W3", avaiable for
	anonymous ftp from ftp://info.cern.ch/pub/doc/www/http.txt.  

	Describes the HTTP interactive access protocol and the tags used
	in HTML documents.
	
	"The WWW Book", from
	ftp://info.cern.ch/pub/doc/the_www_book.txt.

	"Universal Document Identifiers on the Network", OSI-DS-XXX,
	available by anonymous FTP from
	ftp://info.cern.ch/info.cern.ch/pub/www/doc/url3.{txt,ps}.

Person & email address to contact for further information:

	Tim Berners-Lee, CERN, 1211 Geneva 23, Switzerland
	timbl@info.cern.ch


From timbl@www3.cern.ch  Thu Nov 12 18:39:38 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07238; Thu, 12 Nov 92 18:39:38 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14070; Thu, 12 Nov 92 18:52:26 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00296; Thu, 12 Nov 92 18:48:05 +0100
Date: Thu, 12 Nov 92 18:48:05 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211121748.AA00296@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: indexes as links rather than documents
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Tue, 10 Nov 92 19:23:12 CST
> From: Dan Connolly <connolly@pixel.convex.com>
> 

> I keep running across interesting bits of evidence that tell me that
> indexes should be a type of link rather than a type of document.
> 

> <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
> <a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
> 


Dan,

If you found that most index documents are empty, then that was probably
because you were in gopherspace -- in waisspace they all have descriptions.

[[even though as Ed points out the description lives in one place and the index  
in another so it is dificult to know which address to use! On that point,
ed, I chose to refer to the index as that is what actually MUST be available,
when the source file is not essential, it is just icing on the cake]].

How about above instead of

> <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>

using

> <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>

This expresses that the type of relationship between the documents is
that when you follow the link you should search the seocnd index. 


An important addition is just a document-wide
<LINK HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>
empty element which makes a document searchable, directing seraches
to a given index. Similarly  RELATIONSHIP=GLOSSARY would
allow double-clicked words to be looked up in a remote glossary.

This would solve the problem with WAIS source files, in that their hypertext
representation would have such a link to the index, so the source file itself
appears searchable. There are lots of places where this would be neat.

We have been over this a little before.  Perhaps we should allow either
option, as it is so checken-and-egg as a problem.

The argument for the W3 model is that often the user will want to search
or not search a single index, and he doesn't want two operations: one to
select the fact that he wants to search (click) and one to search
(typetypetyepe return).  He just wants one.   After all,
if he clicks on a gopher index link, what does he get? a serach panel.
And what is the difference between that and a serachable document?
Only speed of display. If the serachable document can come up as fast as
a search panel, then there is no contest. If not, there is.

In the long term the search will become (if my philosophising of
the oher day comes true) an instance of a class of search query, for which
an editor will exist if the client supports it. So searches with
toggle buttons and radio buttons and stuff will be possible,
and a gopher serach and W3 search will be subclasses.

I feel that we are talking about optimising speed when the net is slow
here. In general, I don't want to talk about a dictionary (search[1].
describe[2]) I want to talk about a dictionary[3]. The former seems kinda
messy. It just saves time given a slow network now...

Tim


From davis@dri.cornell.edu  Thu Nov 12 21:28:42 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08307; Thu, 12 Nov 92 21:28:42 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06769; Thu, 12 Nov 92 21:41:34 +0100
Received: by willow.tc.cornell.edu id AA13231
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 12 Nov 1992 15:40:14 -0500
Date: Thu, 12 Nov 1992 15:40:14 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199211122040.AA13231@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: indexes as links rather than documents


As I understand it, the distinction between an indexed document
and an ordinary one is that an indexed document is really
an abstract document.   Once you provide the index terms,
then it is concrete document.  So a Dictionary is abstract
until I send it a keyword, then I get back a real document,
the definition for the word.

In the case of the dictionary, of course, one could argue
that the Dictionary as a whole is also a concrete document,
since it would be possible to just read it cover to cover.
On the other hand, this makes less sense if the abstract
document is performing some kind of computation on the
search words, for example, running finger, or even adding
something to a database.  Then there is no meaningful document
without the index.

If that's the right way to think, then it makes sense to put
the semantics into the link, because it's more extensible.
In the case of the index, the user is prompted for keywords,
because that's the input to the computation.  But 
there are many kinds of abstract documents, and many possible
computations to yield concrete documents, and for many of
these there will be other kinds of input requirements.
It seems inelegant to support these by having the abstact
document indicate its input requirements by returning a
document with a special purpose tag (eg <ISINDEX>), since
this will mean that every new kind of input will require a new
tag in HTML.

Maybe this can be addressed in HTML2, by some process of negotiation
between server (abstract document) and user/client.  e.g the document
sends something back saying "I will give you a page of text but
first send me at least one line of ascii".  If this is the
right approach, then we need a means of describing data types and prompts.
The negotiation might take several exchanges, or it might be done
by having the server return a small program, something like a decision
tree, to prompt the user for all meaningful values required for
the input.

While I am on the topic, though, the protocol should be designed
such that software agents on the client side can obtain documents
without having to negotiate, if they have all the desired inputs
ready to hand.  I don't want my user agent to have to parse X
windows protocols in order to answer on by behalf.

Best wishes

From connolly@pixel.convex.com  Thu Nov 12 21:29:04 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08313; Thu, 12 Nov 92 21:29:04 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06777; Thu, 12 Nov 92 21:41:53 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA18074; Thu, 12 Nov 92 14:40:47 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23043; Thu, 12 Nov 92 14:41:03 -0600
Message-Id: <9211122041.AA23043@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: indexes as links rather than documents 
In-Reply-To: Your message of "Thu, 12 Nov 92 18:48:05 +0100."
             <9211121748.AA00296@www3.cern.ch> 
Date: Thu, 12 Nov 92 14:41:02 CST
From: Dan Connolly <connolly@pixel.convex.com>


>How about above instead of
>
>> <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
>
>using
>
>> <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>

Sure... I don't have any strong opinions about the syntax, except that
RELATIONSHIP is longer than 8 characters, and that will be an issue
with some SGML parsers.

This opens up the discussion of link semantics from a while ago. Some
folks suggested a TYPE or ACTION or RELATIONSHIP attribute on anchors:

SEE	(the default) see HREF, i.e. this anchor refers to HREF
INCLUDE	include HREF at this point in the document (for quoting)
REPLACE	replace the anchor text with HREF (another quoting mechanism)
AUGMENT	display HREF along with this document (for figures, etc.)
SEARCH	search HREF and display the results

You could have zillions of options here: DEFINE (HREF defines this anchor),
UPDATE (HREF is a new version of this document), TRANSLATE (HREF is
some converted form of this document). But I suggest we call the attribute
ACTION, and only create a new one when there is a user-interface impact.
So the ACTION attribute is a hint from the author on how to display
the document. That way, all the DEFINE, UPDATE, TRANSLATE, etc fall under
SEE above.

>The argument for the W3 model is that often the user will want to search
>or not search a single index, and he doesn't want two operations: one to
>select the fact that he wants to search (click) and one to search
>(typetypetyepe return).  He just wants one.

But in practice, it's the same: if I quote a wais source from this
mail message, you'll have to 1) traverse the link to the index,
and 2) search the index.


>   After all,
>if he clicks on a gopher index link, what does he get? a serach panel.
>And what is the difference between that and a serachable document?
>Only speed of display. If the serachable document can come up as fast as
>a search panel, then there is no contest. If not, there is.
>
>In the long term the search will become (if my philosophising of
>the oher day comes true) an instance of a class of search query, for which
>an editor will exist if the client supports it. So searches with
>toggle buttons and radio buttons and stuff will be possible,
>and a gopher serach and W3 search will be subclasses.

[Ever seen Dynatext? It supports query dialogs of this sort...]

Ah... this is a perspective that I hadn't thought of: that the
gopher search panel is analagous to the WWW index "cover page."

I was thinking of a model where in stead of a link from document X
to index Y and then another to search results document Z, the link goes
from X to Z, and searching the index is part of traversing the link.

It makes sense to me to have the links mirror protocol transactions.
In other words, if we have a two step protocol:

client: "I want to do a search."
server: "OK... here's the query form."
client: "Here's the filled-out query form."
server: "OK... here are the results."

Then the WWW model of "searchable documents" (query forms) makes sense.

But currently, we just have one step protocols:

client: "I want to do a search. Here's what I'm interested in..."
server: "OK... here are the results..."

So as long as the client can do all the preparation for the query
without help from the server, we should not penalize users with an
extra network round trip.

I don't think the network will ever be a non-issue.

>An important addition is just a document-wide
><LINK HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>
>empty element which makes a document searchable, directing seraches
>to a given index. Similarly  RELATIONSHIP=GLOSSARY would
>allow double-clicked words to be looked up in a remote glossary.
>
>This would solve the problem with WAIS source files, in that their hypertext
>representation would have such a link to the index, so the source file itself
>appears searchable. There are lots of places where this would be neat.

Sure... we need to treat <ISINDEX> as shorthand for
<A NAME="k" HREF=_this_document_ ACTION=SEARCH></a>

As for making it global to the document, you could just treat the
first SEARCH anchor as the default index to search. In the linemode
browser, you could type "k words" to search the default index,
or "7 k words" to search the index assocated with anchor 7. In a GUI
browser, you could have a search text area, and a search button. The
search button would be inactive unless there are SEARCH anchors. Then
it would default to the first one, and clicking any other SEARCH anchor
would just "steer" the search button towards that index.

Dan


From connolly@pixel.convex.com  Thu Nov 12 22:07:39 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08527; Thu, 12 Nov 92 22:07:39 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA08315; Thu, 12 Nov 92 22:20:26 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA20012; Thu, 12 Nov 92 15:19:27 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA26490; Thu, 12 Nov 92 15:19:31 -0600
Message-Id: <9211122119.AA26490@pixel.convex.com>
To: Jim Davis <davis@dri.cornell.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: indexes as links rather than documents 
In-Reply-To: Your message of "Thu, 12 Nov 92 15:40:14 EST."
             <199211122040.AA13231@willow.tc.cornell.edu> 
Date: Thu, 12 Nov 92 15:19:30 CST
From: Dan Connolly <connolly@pixel.convex.com>


>As I understand it, the distinction between an indexed document
>and an ordinary one is that an indexed document is really
>an abstract document.   Once you provide the index terms,
>then it is concrete document.  So a Dictionary is abstract
>until I send it a keyword, then I get back a real document,
>the definition for the word.

The most useful definition of a document I've seen is "a unit
of retreival." Since you can't retrieve the index -- only
summaries of the index, query results from the index, etc. --
the index isn't a document by that definition.

>In the case of the dictionary, of course, one could argue
>that the Dictionary as a whole is also a concrete document,
>since it would be possible to just read it cover to cover.

If we had a protocol to do this, yes...

>Maybe this can be addressed in HTML2, by some process of negotiation
>between server (abstract document) and user/client.  e.g the document
>sends something back saying "I will give you a page of text but
>first send me at least one line of ascii".  If this is the
>right approach, then we need a means of describing data types and prompts.
>The negotiation might take several exchanges, or it might be done
>by having the server return a small program, something like a decision
>tree, to prompt the user for all meaningful values required for
>the input.

Clarification: this shouldn't impact HTML significantly. It should
impact HTTP, the protocol. Whether the forms description/query
language should become part of HTML isn't clear. I'd say: no, it
should be a separate beast.

Tim mentioned the same scenario, with servers sending out forms,
clients with "forms editors" and complex queries.

The closest thing I've seen to an implementation of this is the
Dynatext browser. There's some sort of query dialog description
language: I think it's an SGML language. So you describe the dialog
with an SGML document. The browser displays toggle buttons, text
fields etc. The user fills in the fields, clicks OK, and the
query results come up in the table of contents window.

Dan


From davis@dri.cornell.edu  Thu Nov 12 22:21:01 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08571; Thu, 12 Nov 92 22:21:01 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09081; Thu, 12 Nov 92 22:33:51 +0100
Received: by willow.tc.cornell.edu id AA13270
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 12 Nov 1992 16:32:34 -0500
Date: Thu, 12 Nov 1992 16:32:34 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199211122132.AA13270@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: indexes as links rather than documents

I wrote:
> Maybe this can be addressed in HTML2, by some process of negotiation
> between server (abstract document) and user/client.  
 
Where I should have written HTTP2, since I am talking about
the protocol, not the markup.  Thanks to Dan Connolly for pointing 
this out.
 

From emv@garnet.msen.com  Fri Nov 13 00:33:01 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09090; Fri, 13 Nov 92 00:33:01 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14407; Fri, 13 Nov 92 00:45:48 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mpoDX-00009QC@garnet.msen.com>; Thu, 12 Nov 92 18:44 WET
Message-Id: <m0mpoDX-00009QC@garnet.msen.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed registration of type 'text/html' for MIME 
In-Reply-To: Your message of Thu, 12 Nov 92 17:19:16.
             <9211121619.AA03876@www3.cern.ch> 
Date: Thu, 12 Nov 92 18:44:40 EST
From: Edward Vielmetti <emv@msen.com>

re line length -

html per se has no limit, right?  i think we can punt on that question
and not even mention it, and just let the ordinary MIME things happen
if someone really wants to send a document as a single line 10000
characters long.  (the encoding/decoding should be transparent, or at
least not visible to the user once the document hits the browser)

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From KHOADLEY@ib.rl.ac.uk  Fri Nov 13 11:00:39 1992
Return-Path: <KHOADLEY@ib.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11459; Fri, 13 Nov 92 11:00:39 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15858; Fri, 13 Nov 92 11:13:28 +0100
Received: from CERNVM.cern.ch by CERNVM.CERN.CH (IBM VM SMTP V2R2)
   with BSMTP id 4460; Fri, 13 Nov 92 11:13:41 SET
Received: from UKACRL.BITNET by CERNVM.cern.ch (Mailer R2.08) with BSMTP id
 1219; Fri, 13 Nov 92 11:13:41 SET
Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 3430; Fri,
 13 Nov 92 10:12:24 GMT
Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 7759; Fri, 13
 Nov 92 10:09:29 GMT
Via:        UK.AC.RL.IB; 13 NOV 92 10:09:13 GMT
Message-Id: <"13 Nov 92 09:42:56 GMT KHOADLEY"@UK.AC.RL.IB>
Date:       Fri, 13 Nov 92 09:42:56 GMT
From: "KHOADLEY" (KHOADLEY at UKACRL)        <KHOADLEY@ib.rl.ac.uk>
To: www-talk@nxoc01.cern.ch
Subject:    ISINDEX on documents


Somewhat off the current thread, but anyway ...

There seems little reason to me for the ISINDEX tag. Searching consists of
two components: the client constructing a list of queries designed to
retrieve the relevant information, and the server receving and processing
those queries. Once you start to consider a single user initiated search
generated multiple queries there seems to be little point in tieing searches
down to particular tagged documents.
(of course once a search generates multiple queries it can receive multiple
replies. AS these replies could come from different servers it becomes the
responsibility of the client end to aggregate the replies into something
useful to return to the user: a selection panel for instance).

I'd like to see the ISINDEX tag dropped: the client is free to construct
whatever queries they wish, using the existing HTTP query mechanism.

Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite
used for purposes other than searching, eg. for "smart" documents or
to calculate square roots ! (an example familiar to those at the HEPix
meeting ...). However using a tag that appears to have been intended for
search purpose for something different is confusing to the end user: ie
the page asks for the value you wish to square root, whilst the client
prompts you for a string to search for ....

Perhaps the following could be useful:
           <INPUT VAR=x>Please enter your name</INPUT>
           <DONEINPUT>
ie a series of input fields with associated labels, and a button to say
you have finished and now send the query. This opens the possibility
of forms based pages generating smart documents. How you send the input is
a different matter; maybe:
    http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk

From timbl@www3.cern.ch  Fri Nov 13 16:56:56 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14421; Fri, 13 Nov 92 16:56:56 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15413; Fri, 13 Nov 92 17:09:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01410; Fri, 13 Nov 92 17:04:45 +0100
Date: Fri, 13 Nov 92 17:04:45 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211131604.AA01410@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: OO WWW:  Re: indexes as links rather than documents 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Date: Thu, 12 Nov 92 14:41:02 CST
> From: Dan Connolly <connolly@pixel.convex.com>
> 

> 

> >How about ...using
> >
> >> <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>
> 

> Sure... I don't have any strong opinions about the syntax, except that
> RELATIONSHIP is longer than 8 characters, and that will be an issue
> with some SGML parsers.

Of course. We could call it REL.  (That's what you get with IBM-derived  
products ;-)

> This opens up the discussion of link semantics from a while ago. Some
> folks suggested a TYPE or ACTION or RELATIONSHIP attribute on anchors:
> 

> SEE	(the default) see HREF, i.e. this anchor refers to HREF
> INCLUDE	include HREF at this point in the document (for quoting)
> REPLACE	replace the anchor text with HREF (another quoting mechanism)
> AUGMENT	display HREF along with this document (for figures, etc.)
> SEARCH	search HREF and display the results
>
> You could have zillions of options here: DEFINE (HREF defines this anchor),
> UPDATE (HREF is a new version of this document), TRANSLATE (HREF is
> some converted form of this document). But I suggest we call the attribute
> ACTION, and only create a new one when there is a user-interface impact.
> So the ACTION attribute is a hint from the author on how to display
> the document. That way, all the DEFINE, UPDATE, TRANSLATE, etc fall under
> SEE above.

There seem to be two classes of attribute we are talking about here.
Some attributes express a relationship between the documents (or
relationships between objects described by the documents). These are
relationships like

	A	is a previous version of	B
	A	describes the author of		B
	
etc.  These add semantics to the web, allow interesting navigational
functions.

Other attributes are directions to the client app., to so something:

  When you display A, also display B
  When you display A, embed B
  When you print A, also print B
  When you follow this link, embed B
  When you follow this link, search B
  

Let's bear in mind the idea of moving toward arbitrary objects.
The OO paradigm (the current one, not the only possible one)
has objects which each have a class, which has a set of
methods, each of which has a set of parameters, each of which
has a class. Ok?

Suppose documents are objects. We have two methods now,

	render()  	returning HTML
	search(text)    returning HTML

each taking the object ID as an implicit parameter. That's OK.
These are neat functions. Suppose we generalize.

First generalization: the render():HTML is only one of many functions
which the object supports. The format negotiation says
"I want render()* where * is preferably ....".

In this context the <ISINDEX> tag means "The class of this object
supports search(text):HTML method".  The SEARCHME link
looks more like some advance notice type information [[yuk -- I hate
having info in two places... links can get out of date -- but never mind]]

	"The object references supports search()"
	
plus also the client advice 


  "When you follow this link, search B"

I would separate these two things, personally myself. the first is useful
for deciding on the icon to display, without the second which coud
independently be any of the other client hints mentioned above.

In this light, it would seem there are some obvious extentions!
Let's skip the debate about whether you want the client advice attribute
to make an automatic search (OK, let's put it in, no harm in it)
and focus on the type declaration. Whether it is declariung stuff
about the document itself or a related document is a trivial difference,
the difference between the LINK and the A tags, in fact.

So lets generalize ISINDEX. We have a choice. We can declare the class
(or any superclass) of an object. Or we can declare a method. In fact,
in the multiple inheritance view, these are very similar as you can
imagine a class which only supports one method, and then construct
classes out of inheritance only from those classes. So declaring a
class (set of methods) is more general than declaring a method.

An immediate application of this will be declaring things like
Z39.50 objects which support various search methods with all kinds
of different input parameters.  But one wouldn't of couse stop there....

Classes, like representations, would have to be registered. Either registered
or defined in a suitable language by a document. Ha! we know how to handle  
that.. we don't even have to worry about the class description language
because we can apply format negotiation to that.  In fact, registreation
of a class with IANA would involve storing the class description in a document  
was in a well-defined place, and of which everyone would take copies.
I mean like maybe even at compile time for classic classes.
(I would expect that a convention for getting an icon graphic from
the same directory as the class description would be kinda nice.)

So a document start with information about itself

    <!doctype HTML USDN=x.500:/ch/cern/cn/92/tbl
	URL=http://info.cern.ch/tbl/mydoc.html>
	URL=ftp://info.cern.ch/pub/www/doc/mydoc.html>

    <type USDN=x.500:/internet/iana/www/textindex
	URL=http://www.iana.net/class/www/textindex.asn1
	ACTION=textsearch>

    Hi this is an index of all the widgets in the wdgetbox.

We need one (1) language to start with for defining the classes.
ASN/1 or a SGML version of ASN/1? So long as it can include
inheritance from other classes using a hypertext reference.

We still require all documents to be renderable, which just means
that all objects support render() returning either HTML or
ascii.


> >The argument for the W3 model is that often the user will want to search
> >or not search a single index, and he doesn't want two operations: one to
> >select the fact that he wants to search (click) and one to search
> >(typetypetyepe return).  He just wants one.
> 

> But in practice, it's the same: if I quote a wais source from this
> mail message, you'll have to 1) traverse the link to the index,
> and 2) search the index.

Like with the chicken and the egg, it depends when you start counting the
clicks.

> 




> It makes sense to me to have the links mirror protocol transactions.
> In other words, if we have a two step protocol:
> 

> client: "I want to do a search."
> server: "OK... here's the query form."
> client: "Here's the filled-out query form."
> server: "OK... here are the results."

Isn't that slower? In fact what happens is the user thinks like
that, but the client, knowing that a search is possible, happens
to put up the search panel.  Could we in fact use a 

"when you display A, display B too" link, here?


>... 

> I don't think the network will ever be a non-issue.
> 

I agree. Speed of light, for one thing.


> Sure... we need to treat <ISINDEX> as shorthand for
> <A NAME="k" HREF=_this_document_ ACTION=SEARCH></a>
> 

> As for making it global to the document, you could just treat the
> first SEARCH anchor as the default index to search.

I would prefer to use a document-wide LINK element
in the header as a document-wide analogue of the A element
but that's a detail.

	Tim
	


From timbl@www3.cern.ch  Mon Nov 16 15:09:49 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25427; Mon, 16 Nov 92 15:09:49 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22703; Mon, 16 Nov 92 15:22:41 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02518; Mon, 16 Nov 92 15:18:18 +0100
Date: Mon, 16 Nov 92 15:18:18 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211161418.AA02518@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "KHOADLEY" (KHOADLEY at UKACRL) <KHOADLEY@ib.rl.ac.uk>
Subject: Re: ISINDEX on documents
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date:       Fri, 13 Nov 92 09:42:56 GMT
>  From: "KHOADLEY" (KHOADLEY at UKACRL)        <KHOADLEY@ib.rl.ac.uk>
...
>  There seems little reason to me for the ISINDEX tag. Searching consists of
>  two components: the client constructing a list of queries designed to
>  retrieve the relevant information, and the server receving and processing
>  those queries. Once you start to consider a single user initiated search
>  generated multiple queries there seems to be little point in tieing searches
>  down to particular tagged documents.
>  (of course once a search generates multiple queries it can receive multiple
>  replies. AS these replies could come from different servers it becomes the
>  responsibility of the client end to aggregate the replies into something
>  useful to return to the user: a selection panel for instance).

Every seach needs to search SOMETHING.  Like it has to search a particular  
database or index.  Some servers support thousands of "virtual" indexes. How  
can you express this in a search? The answer is that indexes are names just  
like documents. we then have a convention that if you try to retrieve an index  
as a document, you get back a description of it. This latter is something  
missing for example from WAIS where you have to look up the SOURCE file for a  
database in a totally differents server which may be out of sync (and, being  
centralized, doesn't scale).

If you regard a query as something which is just thrown at the server, then you  
can't allow a ruch enough world of virtual search servers. This was a problem  
with the gopher protocol which causes the Gopher guys to make a  
non-back-compatible sudden change in the protocol spec to introduce an index  
name. 


>  I'd like to see the ISINDEX tag dropped: the client is free to construct
>  whatever queries they wish, using the existing HTTP query mechanism.
>  

>  Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite
>  used for purposes other than searching, eg. for "smart" documents or
>  to calculate square roots ! (an example familiar to those at the HEPix
>  meeting ...). However using a tag that appears to have been intended for
>  search purpose for something different is confusing to the end user: ie
>  the page asks for the value you wish to square root, whilst the client
>  prompts you for a string to search for ....
>  

>  Perhaps the following could be useful:
>             <INPUT VAR=x>Please enter your name</INPUT>
>             <DONEINPUT>
>  ie a series of input fields with associated labels, and a button to say
>  you have finished and now send the query. This opens the possibility
>  of forms based pages generating smart documents. How you send the input is
>  a different matter; maybe:
>      http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

This is the tip of the iceberg.  I think the onlywy to do it generally is (see  
my previous message) to have typed queries, and generic editors for them.
The case above would become something like
<ISINDEX TYPE="iana:/www/classes/query/personalinfo">
The type would also be retrievable like a document, and if you had a generic
query language language, you would get back a description of the query language  
supported. A generic client could use that to generate the form to be filled in  
by a user.

>  Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk
>  


Tim Berners-Lee

From marca@wintermute.ncsa.uiuc.edu  Tue Nov 17 03:08:03 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29396; Tue, 17 Nov 92 03:08:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02217; Tue, 17 Nov 92 03:21:00 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA01883
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 16 Nov 92 20:20:12 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03160; Mon, 16 Nov 92 20:21:23 -0800
Date: Mon, 16 Nov 92 20:21:23 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211170421.AA03160@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: html & emacs

Anyone written code to construct HTML files in Emacs?  I'm hacking
something up; let me know if you're interested....

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From connolly@pixel.convex.com  Tue Nov 17 03:21:23 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29448; Tue, 17 Nov 92 03:21:23 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05521; Tue, 17 Nov 92 03:34:19 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA08673; Mon, 16 Nov 92 20:33:15 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA17244; Mon, 16 Nov 92 20:33:08 -0600
Message-Id: <9211170233.AA17244@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: html & emacs 
In-Reply-To: Your message of "Mon, 16 Nov 92 20:21:23 PST."
             <9211170421.AA03160@wintermute.ncsa.uiuc.edu> 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cut-here"
Date: Mon, 16 Nov 92 20:33:08 CST
From: Dan Connolly <connolly@pixel.convex.com>


--cut-here

>Anyone written code to construct HTML files in Emacs?  I'm hacking
>something up; let me know if you're interested....

I use sgml-mode to verify HTML documents and WWW to see how
they format. So every once in a while I do C-c C-v to call
the sgml parser and verify the document, and I use compile
mode to run www and "preview" the document.

If you come up with something more WYSIWIG, I'd like to
see it.

Dan

--cut-here
Content-Description: SGML mode by James Clark (jjc@jclark.com)
Content-Type: application/octet-stream; type="elisp"

;; SGML mode.
;; Copyright (C) 1992 James Clark (jjc@jclark.com)
;; Parts derived from blink-matching-open in simple.el, which is
;; Copyright (C) 1985, 1986, 1987 Free Software Foundation, Inc.

;; This file is not yet part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 1, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to
;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.

;; Some suggestions for your .emacs file:
;;
;; (autoload 'sgml-mode "sgml-mode" "SGML mode" t)
;;
;; (setq auto-mode-alist
;;       (append (list (cons "\\.sgm$" 'sgml-mode)
;;                     (cons "\\.sgml$"  'sgml-mode)
;;                     (cons "\\.dtd$" 'sgml-mode))
;;               auto-mode-alist))

(provide 'sgml-mode)
(require 'compile)

;;; sgmls is a free SGML parser available from
;;; ftp.uu.net:pub/text-processing/sgml
;;; Its error messages can be parsed by next-error.
;;; The -s option suppresses output.

(defconst sgml-validate-command
  "sgmls -s"
  "*The command to validate an SGML document.
The file name of current buffer file name will be appended to this,
separated by a space.")

(defvar sgml-saved-validate-command nil
  "The command last used to validate in this buffer.")

(defvar sgml-mode-map nil "Keymap for SGML mode")

(if sgml-mode-map
    ()
  (setq sgml-mode-map (make-sparse-keymap))
  (define-key sgml-mode-map ">" 'sgml-close-angle)
  (define-key sgml-mode-map "/" 'sgml-slash)
  (define-key sgml-mode-map "\C-c\C-v" 'sgml-validate))

(defun sgml-mode ()
  "Major mode for editing SGML.
Makes > display the matching <.  Makes / display matching /.
Use \\[sgml-validate] to validate your document with an SGML parser."
  (interactive)
  (kill-all-local-variables)
  (setq local-abbrev-table text-mode-abbrev-table)
  (use-local-map sgml-mode-map)
  (setq mode-name "SGML")
  (setq major-mode 'sgml-mode)
  (make-local-variable 'paragraph-start)
  ;; A start or end tag by itself on a line separates a paragraph.
  ;; This is desirable because SGML discards a newline that appears
  ;; immediately after a start tag or immediately before an end tag.
  (setq paragraph-start
	"^[ \t\n]\\|\
\\(</?\\([A-Za-z]\\([-.A-Za-z0-9= \t\n]\\|\"[^\"]*\"\\|'[^']*'\\)*\\)?>$\\)")
  (make-local-variable 'paragraph-separate)
  (setq paragraph-separate
	"^[ \t\n]*$\\|\
^</?\\([A-Za-z]\\([-.A-Za-z0-9= \t\n]\\|\"[^\"]*\"\\|'[^']*'\\)*\\)?>$")
  (make-local-variable 'sgml-saved-validate-command)
  (set-syntax-table text-mode-syntax-table)
  (make-local-variable 'comment-start)
  (setq comment-start "<!-- ")
  (make-local-variable 'comment-end)
  (setq comment-end " -->")
  (make-local-variable 'comment-indent-hook)
  (setq comment-indent-hook 'sgml-comment-indent)
  (make-local-variable 'comment-start-skip)
  ;; This will allow existing comments within declarations to be
  ;; recognized.
  (setq comment-start-skip "--[ \t]*")
  (run-hooks 'text-mode-hook 'sgml-mode-hook))

(defun sgml-comment-indent ()
  (if (and (looking-at "--")
	   (not (and (eq (char-after (1- (point))) ?!)
		     (eq (char-after (- (point) 2)) ?<))))
      (progn
	(skip-chars-backward " \t")
	(max comment-column (1+ (current-column))))
    0))

(defconst sgml-start-tag-regex
  "<[A-Za-z]\\([-.A-Za-z0-9= \n\t]\\|\"[^\"]*\"\\|'[^']*'\\)*"
  "Regular expression that matches a non-empty start tag.
Any terminating > or / is not matched.")

(defvar sgml-mode-markup-syntax-table nil
  "Syntax table used for scanning SGML markup.")

(if sgml-mode-markup-syntax-table
    ()
  (setq sgml-mode-markup-syntax-table (make-syntax-table))
  (modify-syntax-entry ?< "(>" sgml-mode-markup-syntax-table)
  (modify-syntax-entry ?> ")<" sgml-mode-markup-syntax-table)
  (modify-syntax-entry ?- "_ 1234" sgml-mode-markup-syntax-table)
  (modify-syntax-entry ?\' "\"" sgml-mode-markup-syntax-table))

(defconst sgml-angle-distance 4000
  "*If non-nil, is the maximum distance to search for matching <
when > is inserted.")

(defun sgml-close-angle (arg)
  "Insert > and display matching <."
  (interactive "p")
  (insert-char ?> arg)
  (if (> arg 0)
      (let ((oldpos (point))
	    (blinkpos))
	(save-excursion
	  (save-restriction
	    (if sgml-angle-distance
		(narrow-to-region (max (point-min)
				       (- (point) sgml-angle-distance))
				  oldpos))
	    ;; See if it's the end of a marked section.
	    (and (> (- (point) (point-min)) 3)
		 (eq (char-after (- (point) 2)) ?\])
		 (eq (char-after (- (point) 3)) ?\])
		 (re-search-backward "<!\\[\\(-?[A-Za-z0-9. \t\n&;]\\|\
--\\([^-]\\|-[^-]\\)*--\\)*\\["
				     (point-min)
				     t)
		 (let ((msspos (point)))
		   (if (and (search-forward "]]>" oldpos t)
			    (eq (point) oldpos))
		       (setq blinkpos msspos))))
	    ;; This handles cases where the > ends one of the following:
	    ;; markup declaration starting with <! (possibly including a
	    ;; declaration subset); start tag; end tag; SGML declaration.
	    (if blinkpos
		()
	      (goto-char oldpos)
	      (condition-case ()
		  (let ((oldtable (syntax-table))
			(parse-sexp-ignore-comments t))
		    (unwind-protect
			(progn
			  (set-syntax-table sgml-mode-markup-syntax-table)
			  (setq blinkpos (scan-sexps oldpos -1)))
		      (set-syntax-table oldtable)))
		(error nil))
	      (and blinkpos
		   (goto-char blinkpos)
		   (or
		    ;; Check that it's a valid delimiter in context.
		    (not (looking-at
			  "<\\(\\?\\|/?[A-Za-z>]\\|!\\([[A-Za-z]\\|--\\)\\)"))
		    ;; Check that it's not a net-enabling start tag
		    ;; nor an unclosed start-tag.
		    (looking-at (concat sgml-start-tag-regex "[/<]"))
		    ;; Nor an unclosed end-tag.
		    (looking-at "</[A-Za-z][-.A-Za-z0-9]*[ \t]*<"))
		   (setq blinkpos nil)))
	    (if blinkpos
		()
	      ;; See if it's the end of a processing instruction.
	      (goto-char oldpos)
	      (if (search-backward "<?" (point-min) t)
		  (let ((pipos (point)))
		    (if (and (search-forward ">" oldpos t)
			     (eq (point) oldpos))
			(setq blinkpos pipos))))))
	  (if blinkpos
	      (progn
		(goto-char blinkpos)
		(if (pos-visible-in-window-p)
		    (sit-for 1)
		  (message "Matches %s"
			   (buffer-substring blinkpos
					     (progn (end-of-line)
						    (point)))))))))))

;;; I doubt that null end tags are used much for large elements,
;;; so use a small distance here.
(defconst sgml-slash-distance 1000
  "*If non-nil, is the maximum distance to search for matching /
when / is inserted.")

(defun sgml-slash (arg)
  "Insert / and display any previous matching /.
Two /s are treated as matching if the first / ends a net-enabling
start tag, and the second / is the corresponding null end tag."
  (interactive "p")
  (insert-char ?/ arg)
  (if (> arg 0)
      (let ((oldpos (point))
	    (blinkpos)
	    (level 0))
	(save-excursion
	  (save-restriction
	    (if sgml-slash-distance
		(narrow-to-region (max (point-min)
				       (- (point) sgml-slash-distance))
				  oldpos))
	    (if (and (re-search-backward sgml-start-tag-regex (point-min) t)
		     (eq (match-end 0) (1- oldpos)))
		()
	      (goto-char (1- oldpos))
	      (while (and (not blinkpos)
			  (search-backward "/" (point-min) t))
		(let ((tagend (save-excursion
				(if (re-search-backward sgml-start-tag-regex
							(point-min) t)
				    (match-end 0)
				  nil))))
		  (if (eq tagend (point))
		      (if (eq level 0)
			  (setq blinkpos (point))
			(setq level (1- level)))
		    (setq level (1+ level)))))))
	  (if blinkpos
	      (progn
		(goto-char blinkpos)
		(if (pos-visible-in-window-p)
		    (sit-for 1)
		  (message "Matches %s"
			   (buffer-substring (progn
					       (beginning-of-line)
					       (point))
					     (1+ blinkpos))))))))))

(defun sgml-validate (command)
  "Validate an SGML document.
Runs COMMAND, a shell command, in a separate process asynchronously
with output going to the buffer *compilation*.
You can then use the command \\[next-error] to find the next error message
and move to the line in the SGML document that caused it."
  (interactive
   (list (read-string "Validate command: "
		      (or sgml-saved-validate-command
			  (concat sgml-validate-command
				  " "
				  (let ((name (buffer-file-name)))
				    (and name
					 (file-name-nondirectory name))))))))
  (setq sgml-saved-validate-command command)
  (compile1 command "No more errors"))

--cut-here
Content-Type: message/external-body;
        ACCESS-TYPE=ANON-FTP;
        NAME="sgmls-0.8.tar";
        SITE="ifi.uio.no";
        DIRECTORY="/pub/SGML/SGMLS";
        SIZE=1116160;
        PERMISSION=read-write

Content-Type: application/octet-stream;
        type=tar;
        name="sgmls-0.8.tar"
X-Last-Modified: 19920514010000Z (1992 May 14 01:00:00 GMT)

ifi.uio.no:/pub/SGML/SGMLS/sgmls-0.8.tar
file://ifi.uio.no/pub/SGML/SGMLS/sgmls-0.8.tar
-r--r--r--  1 ftp 1116160 1992 May 14 01:00:00 GMT sgmls-0.8.tar


--cut-here--


From TONYJ@scs.slac.stanford.edu  Tue Nov 17 03:51:09 1992
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29544; Tue, 17 Nov 92 03:51:09 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13116; Tue, 17 Nov 92 04:04:08 +0100
Date: Mon, 16 Nov 1992 19:03 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: MidasWWW - Motif based WWW browser now available.
To: www-talk@nxoc01.cern.ch
Message-Id: <6A3AA851802028DA@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ

The first public release of MidasWWW - A Motif/X based WWW browser -  is now 
available. This browser has been in use at SLAC for a couple of months. It 
features:

  1) Multifont hypertext display
  2) Extensive online HELP
  3) Source code viewer
  4) Motif Style Guide compatibilty
  5) Runs under UNIX and VMS

Future versions will hopefully also support graphics and allow editing of 
HTML text. If you try it please let me know what you think :-)

It is currently available from 

freehep.scri.fsu.edu (in freehep/networking_news_email/midaswww as 
midaswww_1.0.tar.Z)

or as a VMS backup file from

SLACVX::DISK$SLD_FAC0:[EXPORT]MIDASWWW_1_0.BCK

Installation instructions are in the README file included.

Tony Johnson (Tony_Johnson@slac.stanford.edu)

From K.Hoadley@directory.rl.ac.uk  Tue Nov 17 09:26:33 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00830; Tue, 17 Nov 92 09:26:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29801; Tue, 17 Nov 92 09:39:30 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <07636-0@directory.rl.ac.uk>; Tue, 17 Nov 1992 08:28:08 +0000
Date: Mon, 16 Nov 1992 15:13:24 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Sender: K.Hoadley@directory.rl.ac.uk
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: RE: ISINDEX on documents
To: timbl@www3.cern.ch
Cc: www-talk@nxoc01.cern.ch
Message-Id: <Ximap.721989487.7590.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

From Tim Berners-Lee
>Every seach needs to search SOMETHING.  Like it has to search a particular

Of course. But searches are based upon the document the user was reading
when they initiated the search. Dropping the ISINDEX tag simply allows
searchs STARTING at any document - ie. all documents have the ISINDEX tag.

Perhaps what I dislike is that ISINDEX is a boolean - either you have it
or you don't. Instead what I (think !) I want is:
    To the end user everything is searchable.
    Simple user agents can defer as much as possible to the server:
        ie I just pass a search string to the server and let it sort
        everything out.
    Sophisticated user agents can check a documents class to determine
    what sort of searching makes sense, then can frame a "sensible"
    set of queries.
--> ie no specific ISINDEX tagging. Instead merely tag with the class,
and give the user agent freedom to decide whether or not it wishes to use
the information it can derive from the class.

What I think I am going to implement (within the current WWW framework) is
an extension to the httpd configuration file that maps documents names
to search method.ie as well as
      map /* /usr/local/lib/WWW/*
I have:
      search /* wais <some parameters>
so that searches initiated from a particular document or zone of the
document space can be searched by a particular method. This gives me
the ability for do such things as sectional indices and multiple
search methods within a single server.

>> Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite

>This is the tip of the iceberg.I think the onlywy to do it generally is (see
>my previous message) to have typed queries, and generic editors for them.
>The case above would become something like
><ISINDEX TYPE="iana:/www/classes/query/personalinfo">
>The type would also be retrievable like a document, and if you had a generic
>query language language, you would get back a description of the query language
>supported. 
I agree this is the tip of the iceberg.
The point I was trying to make is that smart documents are conceptually
very different from searchable documents, and thus there should be a way 
of implementing smart docs without overloading ISINDEX.
I'm not sure about keeping this in document class. How useful is a class
that only has one instance ? (assuming that forms are generally one offs)
I'm inclined to prefer an in-line representation: just as I can currently
mark a point where text should be highlighted within a document, so I 
should be able to mark a point where text should be inputted.

Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk

From timbl@www3.cern.ch  Tue Nov 17 09:36:22 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00930; Tue, 17 Nov 92 09:36:22 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00645; Tue, 17 Nov 92 09:49:11 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02857; Tue, 17 Nov 92 09:44:20 +0100
Date: Tue, 17 Nov 92 09:44:20 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211170844.AA02857@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: 3D graphics?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Mon, 16 Nov 92 13:21:52 -0800
>  From: marca@ncsa.uiuc.edu (Marc Andreessen)
>  

>  Hi, I've been browsing through www and associated libraries and
>  clients... seems to be very impressive.  Do you know of any 3D clients
>  (e.g. Silicon Graphics-based) under development anywhere yet?
>  

>  Marc

Can't say I do, but I mail this to the list in case someone is working on it  
quietly.  


When we get this famous format negotiation out then you will be able to launch  
other applications from the WWW client to handle strange new things.

>  

>  --
>  Marc Andreessen
>  Software Development Group
>  National Center for Supercomputing Applications
>  marca@ncsa.uiuc.edu
>  



From timbl@www3.cern.ch  Tue Nov 17 09:43:04 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01023; Tue, 17 Nov 92 09:43:04 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01696; Tue, 17 Nov 92 09:54:57 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02864; Tue, 17 Nov 92 09:49:25 +0100
Date: Tue, 17 Nov 92 09:49:25 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211170849.AA02864@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: html & emacs
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date: Mon, 16 Nov 92 20:21:23 -0800
>  From: marca@ncsa.uiuc.edu (Marc Andreessen)
>  

>  

>  Anyone written code to construct HTML files in Emacs?  I'm hacking
>  something up; let me know if you're interested....

	There has been a lot of enquiries for an emacs HTML editor,
	but I don't know anyone has done it.
	I am sure anything you do will be really appreciated.
	Whenever you have something, (and basic documentation on it),
	mail it to the list and I'll put it in the archive.
	
	BTW -- There is a server with Gnu TexInfo material
	converted into hypertext at http://ftp.cwi.nl/pub/www/default.html
	
	Tim
	
>  Marc
>  

>  --
>  Marc Andreessen
>  Software Development Group
>  National Center for Supercomputing Applications
>  marca@ncsa.uiuc.edu
>  



From connolly@pixel.convex.com  Tue Nov 17 15:41:00 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02789; Tue, 17 Nov 92 15:41:00 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA04380; Tue, 17 Nov 92 15:54:00 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA07993; Tue, 17 Nov 92 08:53:09 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA07331; Tue, 17 Nov 92 08:53:07 -0600
Message-Id: <9211171453.AA07331@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: www-talk@nxoc01.cern.ch
Subject: SGML Cop backs off
        [was Re: proposed registration of type 'text/html' for MIME ]
In-Reply-To: Your message of "Tue, 10 Nov 92 15:13:07 EST."
             <m0mp1xh-00009MC@garnet.msen.com>
Date: Tue, 17 Nov 92 08:53:07 CST
From: Dan Connolly <connolly@pixel.convex.com>

I've reconsidered my position on the "framing tags" in HTML after
a more careful consideration of the SGML standard, and after
receiving the O'Reilly/HaL DocBook materials and the MidasWWW
browser.
 
To refresh your memory...
 
>     Currently HTML documents are transmitted without the normal SGML framing
>     tags, but if these are included parsers will ignore them.
>
>I don't know what "the normal SGML framing tags" are. An SGML document
>has three parts: the SGML declaration, the prologue, and the instance.
>It is common in SGML applications to use an implied SGML declaration
>and include the prologue by reference (kinda like an #include
>directive in C.) but without these "framing tags," it's just not an
>SGML document.
 
The SGML standard is big on the distinction between Entities and
everything else; that is, the physical breakup of an SGML document
into storage units such as files, directories, MIME body parts,
collectively "entities" is pretty much arbitrary (you can't break
<TITLE> between <TI and TLE>,, but other than that,
it's pretty much fair game.)
 
So it appears that it's not necessary or even wise to model the HTML
data format as an SGML document entity, but rather an SGML text
entity.  That is, the way to validate/parse an HTML document is not to
sick the parser on the text/html body part itself, but on a document
consisting of two entities: the HTML DTD entity, and the text/html
body part.
 
If we were talking about a text/c-program content type, what I
was suggesting would be like putting the line:
 
#include <stdlib.h>
 
at the top of every text/c-program body part. What I'm suggesting
now is like assuming every text/c-program gets stdlib.h prepended
before compiling.
 
This makes an assumption that text/html data has this HTML DTD
entity in front of it all the time, but that assumption has always
been there.
 
Besides, forcing text/html parser to grok SGML document entities
creates some sticky issues -- we'd have to limit the prologue
to the simple <!DOCTYPE HTML SYSTEM>, and that's not really legal.
You're supposed to be able to do things like:
 
<!DOCTYPE HTML SYSTEM [
<!ENTITY smiley ":-)"> <!-- add my own "macro" -->
]>
<HTML><TITLE>The history of the smiley: &smiley;</TITLE>
...
 
If we adopt this change of perspective, we should make it clear
in the HTML specification that for the purposes of SGML, a text/html
body part is not an SGML document entity, but an SGML text
entity. The html.dtd entity and the text/html body part text entity
comprise an SGML document. I need to update html.dtd, fix-html.pl,
and the www_and_frame materials to reflect this change of
perspective.
 
By the way: this change makes it more staightforward to use an
SGML declaration other than the default, e.g. to increase NAMELEN
to allow tags larger than 8 characters. Should we do that while
we're at it?
 
Dan
 
p.s. Check out the MidasWWW browser. It's long overdue in the WWW
project, but it's worth the wait!

From mcclanah@dlgeo.cr.usgs.gov  Tue Nov 17 17:32:59 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03557; Tue, 17 Nov 92 17:32:59 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16646; Tue, 17 Nov 92 17:45:50 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA22181; Tue, 17 Nov 92 10:42:50 CST
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA05696; Tue, 17 Nov 1992 10:45:38 -0600
Date: Tue, 17 Nov 1992 10:45:38 -0600
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9211171645.AA05696@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: Midas


I just downloaded Midas, compiled it and have played with it all
morning.  It is really nice and is a definite step forward in
the WWW world.  I appreciated it partly because it is done in Motif,
which is what our project is using and it will be a lot easier
to possibly integrate something already written in motif into our
project.

Keep up the good work Tony.

Pat McClanahan

From putz@parc.xerox.com  Tue Nov 17 21:01:51 1992
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05007; Tue, 17 Nov 92 21:01:51 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07223; Tue, 17 Nov 92 21:14:54 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <12249>; Tue, 17 Nov 1992 12:13:34 PST
Received: by spoggles.parc.xerox.com id <58401>; Tue, 17 Nov 1992 12:13:23 -0800
Date: 	Tue, 17 Nov 1992 12:13:13 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: RE: ISINDEX on documents
In-Reply-To: <Ximap.721989487.7590.khoadley@danton>
To: K.Hoadley@directory.rl.ac.uk
Cc: www-talk@nxoc01.cern.ch
Message-Id: <92Nov17.121323pst.58401@spoggles.parc.xerox.com>

I like the idea of your suggested INPUT tag.  It seems like a logical extension of the current protocol, and I can think of many uses for it, including form-based queries and maybe even a server-based Hypertext editor running on a very simple generic client.

Steve Putz
Xerox PARC

From marca@wintermute.ncsa.uiuc.edu  Wed Nov 18 02:11:38 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06574; Wed, 18 Nov 92 02:11:38 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29817; Wed, 18 Nov 92 02:24:36 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05259
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 17 Nov 92 19:23:48 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05780; Tue, 17 Nov 92 19:24:59 -0800
Date: Tue, 17 Nov 92 19:24:59 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211180324.AA05780@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: html-mode.el

OK, here's a first pass at an html-mode for Emacs.  Comments, bug
reports, and enhancements are welcome; the latest version will always
be on ftp.ncsa.uiuc.edu in /outgoing/marca as html-mode.el.

(Somebody already sent me an smgl-mode.el, so I expect I'll add
features from that pretty quickly.)

Enjoy,

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


;;; --------------------------------------------------------------------------
;;; HTML mode, based on text mode.
;;; Copyright (C) 1985 Free Software Foundation, Inc.
;;; Copyright (C) 1992 National Center for Supercomputing Applications.
;;; NCSA modifications by Marc Andreessen (marca@ncsa.uiuc.edu).
;;;
;;; This program is free software; you can redistribute it and/or
;;; modify it under the terms of the GNU General Public License as
;;; published by the Free Software Foundation; either version 1, or
;;; (at your option) any later version.
;;;
;;; This program is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;; General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Emacs; see the file COPYING.  If not, write to the
;;; Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
;;;
;;; -------------------------------- CONTENTS --------------------------------
;;;
;;; html-mode: Major mode for editing HTML hypertext documents.
;;; $Revision: 1.11 $
;;; $Date: 1992/11/18 03:20:43 $
;;;
;;; Canonical list of features:
;;;   See below.
;;;
;;; ------------------------------ INSTRUCTIONS ------------------------------
;;;
;;; Load html-mode.el before editing HTML documents.  html-mode will
;;; detect the ``.html'' suffix and activate itself appropriately.
;;;
;;; You are assumed to be at least somewhat familiar with HTML format.
;;; If you aren't, read about it first (see below).
;;;
;;; Here are key sequences and corresponding commands (in order of
;;; their key sequences):
;;;
;;; C-c a         html-add-address
;;;   Open an address element.
;;;
;;; C-c d         html-add-definition-list
;;;   Open a definition list.  The initial entry is created for you.
;;;   To create subsequent entries, use 'C-c e'.
;;;
;;; C-c e         html-add-definition-entry
;;;   Add a new definition entry in a definition list.  You are
;;;   assumed to be inside a definition list (specifically, at the end
;;;   of another definition entry).
;;;
;;; C-c h         html-add-header
;;;   Add a header.  You are prompted for size (1 is biggest, 2 is
;;;   next biggest) and header contents.
;;;
;;; C-c i         html-add-list-or-menu-item
;;;   Add a new list or menu item in a list or menu.  You are assumed
;;;   to be inside a list or menu (specifically, at the end of another
;;;   item).
;;;
;;; C-c l         html-add-normal-link
;;;   Add a link.  You will be prompted for the link (any string;
;;;   e.g., http://foo.bar/argh/blagh).  The cursor will be left where
;;;   you can type the text that will represent the link in the
;;;   document.
;;;
;;; C-c m         html-add-menu
;;;   Open a menu.  The initial item is created for you.  To create
;;;   additional items, use 'C-c i'.
;;;
;;; C-c p         html-add-paragraph-separator
;;;   Use this command at the end of each paragraph.
;;;
;;; C-c s         html-add-list
;;;   Open a list.  The initial item is created for you.  To create
;;;   additional items, use 'C-c i'.
;;;
;;; C-c t         html-add-title
;;;   Add a title to the document.  You will be prompted for the
;;;   contents of the title.  If a title already exists at the very
;;;   top of the document, the existing contents will be replaced.
;;;
;;; C-c x         html-add-plaintext
;;;   Add plaintext.  The cursor will be positioned where you can type
;;;   plaintext (or insert another file, or whatever).
;;;
;;; < > &
;;;   These are overridden to output &lt;, &gt;, and &amp;
;;;   respectively.  The real characters <, >, and & can be entered
;;;   into the text either by prepending 'C-c' to the character or by
;;;   using the Emacs quoted-insert (C-q) command.
;;;
;;; C-c <, C-c >, C-c &
;;;   See '< > &' above.
;;;
;;; ---------------------------- ADDITIONAL NOTES ----------------------------
;;;
;;; If you are running Epoch or Lucid Emacs, highlighting will be used
;;; to deemphasize HTML message elements as they are created.  You can
;;; turn this off; see the source code.
;;;
;;; -------------------------------- GOTCHAS ---------------------------------
;;;
;;; HTML documents can be tricky.  html-mode is not smart enough to
;;; enforce correctness or sanity, so you have to do that yourself.
;;;
;;; In particular, html-mode is smart enough to generate unique
;;; numeric NAME id's for all links that were (1) created via an
;;; html-mode command or (2) present in the file when it was loaded.
;;; Any other links (e.g. links added via Emacs cut and paste) may
;;; have ID's that conflict with ID's html-mode generates.  You must
;;; watch for this and fix it when appropriate; otherwise, your
;;; hypertext document will not work correctly.
;;;
;;; ------------------------- WHAT HTML-MODE IS NOT --------------------------
;;;
;;; html-mode is not a mode for *browsing* HTML documents.  In
;;; particular, html-mode provides no hypertext capabilities.  There
;;; is a clear need for an HTML browser; if you write one, let me
;;; know.
;;;
;;; ------------------------------ WHAT HTML IS ------------------------------
;;;
;;; HTML (HyperText Markup Language) is a format for hypertext
;;; documents.  For more information on HTML, telnet to info.cern.ch.
;;;
;;; --------------------------------------------------------------------------
;;; LCD Archive Entry:
;;; html-mode|Marc Andreessen|marca@ncsa.uiuc.edu|
;;; Major mode for editing HTML hypertext files.|
;;; $Date: 1992/11/18 03:20:43 $|$Revision: 1.11 $|~/modes/html-mode.el.Z|
;;; --------------------------------------------------------------------------

(provide 'html-mode)

;;; ------------------------------- variables --------------------------------

(defvar html-use-highlighting t
  "*Flag to use highlighting for HTML directives in Epoch or Lucid Emacs; 
if non-NIL, highlighting will be used.")

(defvar html-deemphasize-color "grey80"
  "*Color for de-highlighting HTML directives in Epoch or Lucid Emacs.")

(defvar html-emphasize-color "yellow"
  "*Color for highlighting HTML something-or-others in Epoch or Lucid Emacs.")

;;; --------------------------------- setup ----------------------------------

(defvar html-mode-syntax-table nil
  "Syntax table used while in html mode.")

(defvar html-mode-abbrev-table nil
  "Abbrev table used while in html mode.")
(define-abbrev-table 'html-mode-abbrev-table ())

(if html-mode-syntax-table
    ()
  (setq html-mode-syntax-table (make-syntax-table))
  (modify-syntax-entry ?\" ".   " html-mode-syntax-table)
  (modify-syntax-entry ?\\ ".   " html-mode-syntax-table)
  (modify-syntax-entry ?' "w   " html-mode-syntax-table))

(defvar html-mode-map nil "")
(if html-mode-map
    ()
  (setq html-mode-map (make-sparse-keymap))
  (define-key html-mode-map "\t" 'tab-to-tab-stop)
  (define-key html-mode-map "\C-ca" 'html-add-address)
  (define-key html-mode-map "\C-cd" 'html-add-definition-list)
  (define-key html-mode-map "\C-ce" 'html-add-definition-entry)
  (define-key html-mode-map "\C-ch" 'html-add-header)
  (define-key html-mode-map "\C-ci" 'html-add-list-or-menu-item)
  (define-key html-mode-map "\C-cl" 'html-add-normal-link)
  (define-key html-mode-map "\C-cm" 'html-add-menu)
  (define-key html-mode-map "\C-cp" 'html-add-paragraph-separator)
  (define-key html-mode-map "\C-cs" 'html-add-list)
  (define-key html-mode-map "\C-ct" 'html-add-title)
  (define-key html-mode-map "\C-cx" 'html-add-plaintext)
  (define-key html-mode-map "<" 'html-less-than)
  (define-key html-mode-map ">" 'html-greater-than)
  (define-key html-mode-map "&" 'html-ampersand)
  (define-key html-mode-map "\C-c<" 'html-real-less-than)
  (define-key html-mode-map "\C-c>" 'html-real-greater-than)
  (define-key html-mode-map "\C-c&" 'html-real-ampersand)
)

;;; --------------------------- buffer-local vars ----------------------------

(defvar html-link-counter-default 0)
(defvar html-link-counter nil)
(make-variable-buffer-local 'html-link-counter)
(setq-default html-link-counter html-link-counter-default)

;;; ------------------------------ highlighting ------------------------------

(defvar html-running-lemacs (string-match "Lucid" emacs-version)
  "Non-nil if running Lucid Emacs.")

(defvar html-running-epoch (boundp 'epoch::version)
  "Non-nil if running Epoch.")

(if (and html-running-epoch html-use-highlighting)
    (progn
      (defvar html-deemphasize-style (make-style))
      (set-style-foreground html-deemphasize-style html-deemphasize-color)
      (defvar html-emphasize-style (make-style))
      (set-style-foreground html-emphasize-style html-emphasize-color)))

(if (and html-running-lemacs html-use-highlighting)
    (progn
      (defvar html-deemphasize-style (make-face 'html-deemphasize-face))
      (set-face-foreground html-deemphasize-style html-deemphasize-color)
      (defvar html-emphasize-style (make-face 'html-emphasize-face))
      (set-face-foreground html-emphasize-style html-emphasize-color)))

(if html-use-highlighting
    (progn
      (if html-running-lemacs
          (defun html-add-zone (start end style)
            "Add a Lucid Emacs extent from START to END with STYLE."
            (let ((extent (make-extent start end)))
              (set-extent-face extent style)
              (set-extent-data extent 'html-mode))))
      (if html-running-epoch
          (defun html-add-zone (start end style)
            "Add an Epoch zone from START to END with STYLE."
            (let ((zone (add-zone start end style)))
              (epoch::set-zone-data zone 'html-mode))))))

(defun html-maybe-deemphasize-region (start end)
  "Maybe deemphasize a region of text.  Region is from START to END."
  (and (or html-running-epoch html-running-lemacs)
       html-use-highlighting
       (html-add-zone start end html-deemphasize-style)))

;;; ----------------------------- link commands ------------------------------

(defun html-add-link (link-object)
  "Add a link."
  (let ((start (point)))
    (setq html-link-counter (1+ html-link-counter))
    (insert "<A NAME=" (format "%d" html-link-counter) 
            " HREF=" link-object ">")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "</A>")
    (push-mark)
    (forward-char -4)
    (html-maybe-deemphasize-region (1+ (point)) (+ (point) 4))))

(defun html-add-normal-link (link)
  "Make a link.  There is no completion of any kind yet."
  (interactive "sLink to: ")
  (html-add-link link))

;;; --------------------------- document elements ----------------------------

(defun html-add-title (title)
  "Add or modify a title."
  (interactive "sTitle: ")
  (save-excursion
    (goto-char (point-min))
    (if (and (looking-at "<TITLE>")
             (save-excursion
               (forward-char 7)
               (re-search-forward "[^<]*" 
                                  (save-excursion (end-of-line) (point)) 
                                  t)))
        ;; Plop the new title in its place.
        (replace-match title t)
      (insert "<TITLE>")
      (html-maybe-deemphasize-region (point-min) (1- (point)))
      (insert title)
      (insert "</TITLE>")
      (html-maybe-deemphasize-region (- (point) 7) (point))
      (insert "\n"))))

(defun html-add-header (size header)
  "Add a header."
  (interactive "sSize (1 or 2): \nsHeader: ")
  (let ((start (point)))
    (insert "<H" size ">")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert header)
    (setq start (point))
    (insert "</H" size ">\n")
    (html-maybe-deemphasize-region (1+ start) (1- (point)))))

(defun html-add-paragraph-separator ()
  "Add a paragraph separator."
  (interactive)
  (let ((start (point)))
    (insert "  <P>\n\n")
    (html-maybe-deemphasize-region (+ start 2) (- (point) 2))))

(defun html-add-definition-list ()
  "Add a definition list."
  (interactive)
  (let ((start (point)))
    (insert "<DL>\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "<DT> ")
    ;; Point goes right there.
    (save-excursion
      (insert "\n<DD> \n")
      (setq start (point))
      (insert "</DL>\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; Mark goes after list -- this doesn't work.
      (push-mark))))

(defun html-add-definition-entry ()
  "Add a definition entry.  Assume we're at the end of a previous
entry."
  (interactive)
  (let ((start (point)))
    (insert "\n<DT> ")
    (save-excursion
      (insert "\n<DD> "))))

(defun html-add-plaintext ()
  "Add plaintext."
  (interactive)
  (let ((start (point)))
    (insert "<XMP>\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (save-excursion
      (insert "\n")
      (setq start (point))
      (insert "</XMP>\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; This doesn't work.
      (push-mark))))

(defun html-add-list-internal (type)
  (let ((start (point)))
    (insert "<" type ">\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "<LI> ")
    ;; Point goes right there.
    (save-excursion
      (insert "\n")
      (setq start (point))
      (insert "</" type ">\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; Mark goes after list -- this doesn't work.
      (push-mark))))

(defun html-add-list ()
  "Add a list."
  (interactive)
  (html-add-list-internal "UL"))

;; Is this correct?  Viola doesn't seem to do anything with it.
(defun html-add-menu ()
  "Add a menu."
  (interactive)
  (html-add-list-internal "MENU"))

(defun html-add-list-or-menu-item ()
  "Add a list or menu item.  Assume we're at the end of the
last item."
  (interactive)
  (let ((start (point)))
    (insert "\n<LI> ")))

(defun html-add-address ()
  "Add an address."
  (interactive)
  (let ((start (point)))
    (insert "<ADDRESS> ")
    (html-maybe-deemphasize-region start (1- (point)))
    (save-excursion
      (setq start (point))
      (insert "  </ADDRESS>\n")
      (html-maybe-deemphasize-region (+ start 2) (1- (point)))
      ;; Obviously this doesn't work here, so I don't
      ;; see why you're being an idiot and still doing it
      ;; like this....
      (push-mark))))

(defun html-less-than ()
  (interactive)
  (insert "&lt;"))

(defun html-greater-than ()
  (interactive)
  (insert "&gt;"))

(defun html-ampersand ()
  (interactive)
  (insert "&amp;"))

(defun html-real-less-than ()
  (interactive)
  (insert "<"))

(defun html-real-greater-than ()
  (interactive)
  (insert ">"))

(defun html-real-ampersand ()
  (interactive)
  (insert "&"))

;;; ------------------------------- html-mode --------------------------------

(defun html-mode ()
  "Major mode for editing HTML hypertext documents.  Special commands:\\{html-mode-map}
Turning on html-mode calls the value of the variable html-mode-hook,
if that value is non-nil."
  (interactive)
  (kill-all-local-variables)
  (use-local-map html-mode-map)
  (setq mode-name "Html")
  (setq major-mode 'html-mode)
  (setq local-abbrev-table html-mode-abbrev-table)
  (set-syntax-table html-mode-syntax-table)
  (run-hooks 'html-mode-hook))

;;; ------------------------------- our hooks --------------------------------

(defun html-find-file-hook ()
  "Hook called from find-file-hooks.  Set html-link-counter to 
the highest link value in the document (the next link created will
be one greater than that) to insure unique (numeric) link ID's."
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "<A NAME=" (point-max) t)
      (let ((subst (buffer-substring (match-end 0)
                                     (save-excursion
                                       (re-search-forward " " (point-max) t)
                                       (match-beginning 0)))))
        (and subst
             (> (string-to-int subst) html-link-counter)
             (setq html-link-counter (string-to-int subst)))))))

;;; ------------------------------- hook setup -------------------------------

;; Author: Daniel LaLiberte (liberte@cs.uiuc.edu).
(defun html-postpend-unique-hook (hook-var hook-function)
  "Postpend HOOK-VAR with HOOK-FUNCTION, if it is not already an element.
hook-var's value may be a single function or a list of functions."
  (if (boundp hook-var)
      (let ((value (symbol-value hook-var)))
        (if (and (listp value) (not (eq (car value) 'lambda)))
            (and (not (memq hook-function value))
                 (set hook-var (append value (list hook-function))))
          (and (not (eq hook-function value))
               (set hook-var (append value (list hook-function))))))
    (set hook-var (list hook-function))))

(postpend-unique-hook 'find-file-hooks 'html-find-file-hook)

;;; ------------------------------ final setup -------------------------------

(or (assoc "\\.html$" auto-mode-alist)
    (setq auto-mode-alist (cons '("\\.html$" . html-mode) auto-mode-alist)))


From marca@wintermute.ncsa.uiuc.edu  Wed Nov 18 02:16:30 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06596; Wed, 18 Nov 92 02:16:30 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00960; Wed, 18 Nov 92 02:29:29 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05417
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Tue, 17 Nov 92 19:28:42 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05841; Tue, 17 Nov 92 19:29:52 -0800
Date: Tue, 17 Nov 92 19:29:52 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211180329.AA05841@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), www-talk@nxoc01.cern.ch
Subject: 3D graphics?
In-Reply-To: <9211170844.AA02857@www3.cern.ch>
References: <9211170844.AA02857@www3.cern.ch>

Tim Berners-Lee writes:
> When we get this famous format negotiation out then you will be able
> to launch other applications from the WWW client to handle strange
> new things.

A couple more questions, since I'm starting the game late...

(1) Has anyone done work wrt adding real data (in whatever format) to
    www?

(2) Is there a consensus on supporting MIME in HTML and vice versa?
    If not, what are the objections and what are the alternatives?

Thanks,

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Wed Nov 18 04:39:33 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07014; Wed, 18 Nov 92 04:39:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01470; Wed, 18 Nov 92 04:52:37 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA10236
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 17 Nov 92 21:51:49 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA06110; Tue, 17 Nov 92 21:52:57 -0800
Date: Tue, 17 Nov 92 21:52:57 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211180552.AA06110@wintermute.ncsa.uiuc.edu>
To: salil@eitech.com (Salil Deshpande)
Cc: www-talk@nxoc01.cern.ch
Subject: Stupid typo #1 in html-mode.el
In-Reply-To: <9211180220.AA09908@eitech.com>
References: <9211180220.AA09908@eitech.com>

Salil Deshpande writes:
> Someone probably told you this already, but
> 
>    (postpend-unique-hook 'find-file-hooks 'html-find-file-hook)
> 
> should be
> 
>    (html-postpend-unique-hook 'find-file-hooks 'html-find-file-hook)

WHOOOOOOOOOOOOOPS!

Thanks,

Marc


From connolly@pixel.convex.com  Wed Nov 18 07:56:06 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07559; Wed, 18 Nov 92 07:56:06 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03449; Wed, 18 Nov 92 08:09:10 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09379; Wed, 18 Nov 92 00:09:40 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA13640; Tue, 17 Nov 92 22:20:45 -0600
Message-Id: <9211180420.AA13640@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: www_and_frame release 0.2
Date: Tue, 17 Nov 92 22:20:45 CST
From: Dan Connolly <connolly@pixel.convex.com>

I just uploaded www_and_frame-0.2.tar.Z to info.cern.ch in
pub/incoming.

Changes:

* HTML files are now treated as text entities and thus don't
require the <!DOCTYPE HTML SYSTEM> "framing tags."

* Quotes and other Frame characters are converted to something
sane

* Named anchors convert nicely.

In general, it's possible to grab the source of a web document,
save it in an .html file, fire up framemaker, edit it, save it
back out, and browse it with www again. (be careful with relative
anchors...)

It's also possible to develop a whole local web of Frame documents
and then save them as HTML and put them on a server (you have to
stick to the HTML tags... can't use just any old frame files). It makes
a nice compliment to the MidasWWW browser.

Have fun!

Dan


From connolly@pixel.convex.com  Wed Nov 18 08:58:59 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07730; Wed, 18 Nov 92 08:58:59 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07574; Wed, 18 Nov 92 09:11:58 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09383; Wed, 18 Nov 92 00:09:44 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA10572; Tue, 17 Nov 92 20:14:31 -0600
Message-Id: <9211180214.AA10572@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: 3D graphics? 
In-Reply-To: Your message of "Tue, 17 Nov 92 19:29:52 PST."
             <9211180329.AA05841@wintermute.ncsa.uiuc.edu> 
Date: Tue, 17 Nov 92 20:14:31 CST
From: Dan Connolly <connolly@pixel.convex.com>


>(1) Has anyone done work wrt adding real data (in whatever format) to
>    www?

No, but I think there's some stuff on gopher and WAIS servers that
you might be able to get at.

>(2) Is there a consensus on supporting MIME in HTML and vice versa?

There's a growing consensus.

The strategy isn't to shoehorn MIME inside HTML, though we are
shoehorning HTML inside MIME, i.e. there will soon be a text/html
MIME content type.

The strategy is to treat the current data format as a special case of
the more general MIME body part scheme.  Currently, www clients expect
text/html or text/plain body parts, and it uses things like filename
suffixes to tell the difference. If you point www at

ftp://ftp.ora.com/pub/davenport/Xhelp/Xhelp_Sept_11.ps

It will gladly fill your screen with unintelligible postscript code.

The strategy is that WWW clients will be able to negotiate various
formats with servers, and the client will know what format the
data is in before it comes over the wire. The other MIME types
will be alternatives to text/html, not enclosures within it.

For protocols like FTP, we need to have type information in
the links, like:

<a HREF="ftp://info.cern.ch/pub/www/NextBrowser.tiff"
	type="image/x-tiff">The NeXT browser in action</a>

the the client would know better than to try to display the
contents of the tiff file in a text window. The easiest thing
to do is to pass it off to

% metamail -b -c "image/x-tiff" /tmp/www_ftp.4322

and let metamail to the rest.

For WAIS, the type information is in the protocol. For gopher, it
mostly is. For HTTP, the client and the server are supposed to
negotiate the format based on compute resources required for the
conversion, network transmission time, distortion/loss of data,
etc.

That's my two cents, anyway.

Dan


From K.Hoadley@directory.rl.ac.uk  Wed Nov 18 13:28:18 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08640; Wed, 18 Nov 92 13:28:18 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28165; Wed, 18 Nov 92 12:08:54 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <09533-0@directory.rl.ac.uk>; Wed, 18 Nov 1992 10:56:46 +0000
Date: Wed, 18 Nov 1992 10:04:15 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: Smart server or smart client ?
To: www-talk@nxoc01.cern.ch
In-Reply-To: Putz.parc@xerox.com's message of Tue, 17 Nov 1992 12:13:13 PST: <92Nov17.121323pst.58401@spoggles.parc.xerox.com>
Message-Id: <Ximap.722084834.9952.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Steve Putz wrote:
>I like the idea of your suggested INPUT tag.  It seems like a logical
>extension of the current protocol, and I can think of many uses for it,
>including form-based queries and maybe even a server-based Hypertext editor
                                               =============================
>running on a very simple generic client.
>
>Steve Putz
>Xerox PARC
>
>
This raises the question of smart servers vs smart clients.

How much does the client need to know about format conversion ? The client
knows what formats it understands (maybe extensible through a system like
a MIME mailcap), but does it need to know about how to convert between
different formats ? Adding format conversion into the clients will make
them much more complicated, which is usually not a good thing (witness
the success of POP over IMAP in the PC mail market: POP is simple minded,
easy to implement and as a result widespread; IMAP is a rather nice protocol,
fairly powerful, but more difficult to implement (though not THAT difficult).
RESULT: though IMAP is technically far superior to POP, POP is winning
the war.)

Thus I think it would be a good idea to keep the clients simple, shunt
the complexity where possible into the server (it doesnt matter much if
ther are only one or two server implementations; it matters a great deal
however if the clients are only limited to certain Unix boxes).

I think we can learn from the way the DNS works. The are two types of DNS
queries: iterative and recursive. With an iterative query, the client
(resolver) sends a query to one server. From the result it may be referred
to another server, which it then queries and so on until it reaches a 
conclusion. With a recursive query, the resolver (a stub resolver) sends
the initial query (with the RR bit set) to a local server, which then does
all the work. The protocol remains the same in both cases, the actual
procedure of lookup remains the same, they differ only in whether the local
resolver does all the work or simply punts it to a local server.

The best way to support small machines such as PCs, Macs, Amigas etc
within the WWW would seem to me to support the concept of a stub client
that merely throws everything at the server and leaves it to sort out the
mess. When the stub client connects to the server it informs the server
what formats it understands (lists out its wwwcap ?). Compatibility with
existing clients can be maintained in that if a client doesn't inform the
server of the formats it knows, we can asssume a minimum (HTML + plain
text ?).

This can be extended further... consider a site running a firewall,
limiting access to the outside to a few selected hosts (poor misguided
people !). If I'm sitting on a PC and I'm reading a document with a link
to another document outside my site, that link is useless to me because
I cant access the outside world. On the other hand a central site server
might have external access, thus if I can punt the query to the server
and say "you go fetch this for me" everything is hunkydory. The underlying
protocol doesn't change, all that happens is that I can ask any server
to get me the answer, rather than just the right one.

Again look at the DNS. The great advantage of stub resolver is that they
lead to a centralised cache at the local server. If we punt www queries
to a local server we get the same: the ability to build a cache of the
information regularly used by the locals (I'm writing from a research lab
with a heavy slant towards high energy physics - thus there is likely
to a slant in the documents that users around here want; cacheing this
working set would be a big win.)
(For this cacheing to work well we'd need to associate a time to live
with each document - again like the DNS).
It should be possible to cache format conversions as well.

Anyway, these are just some ideas, maybe useful maybe not.

Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk



From davis@dri.cornell.edu  Wed Nov 18 14:06:19 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08881; Wed, 18 Nov 92 14:06:19 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05803; Wed, 18 Nov 92 14:18:38 +0100
Received: by willow.tc.cornell.edu id AA19290
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 18 Nov 1992 08:17:00 -0500
Date: Wed, 18 Nov 1992 08:17:00 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199211181317.AA19290@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: a Gateway to the U Mich Geography server


Here is a quickly hacked up Gateway from WWW to the University
of Michigan Geography server.  It expects one argument, a 
WWW doc id.  It ignores the "pathname", extracts the search words,
then passes those to the server.  It does NOT parse the data
returned by the server (that is an improvment yet to be done)
but you can understand the output.

To use this, you would need to have an HTTP server running
someplace where you can attach this gateway.  I can provide
the very simple HTTP server I use here, but this subject
is already documented in the WWW online documentation.

Best wishes

#!/usr/local/bin/perl
# Gateway from WWW to the Geography server at U Michigan
# Copyright 1992 Xerox.  All rights reserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# Jim Davis, Nov 17 1992

# To do:
# 1) Parse the returned info so as to display more neatly.
#    (See documentation at end of file its format.)
# 2) Handle case where multiple places match supplied name
# 3) Handle case where no place matches supplied name.

# This expects one argument, a document ID.  The search keywords
# are sent to the Geography server, the "pathname" is ignored.
# e.g. /geography/ignored/whocares?ithaca,ny => ithaca,ny
# As an extra bonus feature, if the first arg has no question marks
# then the entire arg line is passed to the server.  This is
# convenient when you call this from the shell rather than from WWW.

if ($#ARGV == -1) {
 die "Usage: geography-gateway [WWW-DOCUMENT-ID | location]\
An example WWW document id is /geography?washington,dc
If calling from shell, omit the /geography? part.\nStopped";}

$usage =  "<ISINDEX>\n\
<TITLE>Geography Server</TITLE>\n\
<h2>Type geographic name in Index.</h2>\n\
";

# for debugging
# print "<LISTING>\n";
# print "ARGV =  $#ARGV\n";
# for ($i = 0; $i < $#ARGV+1; $i++) {
#   print "Arg $i is $ARGV[$i]\n";}
# print "</LISTING>";
# exit;


@parts=split('/', $ARGV[0]);  # separate pathname from keywords.
$last = $parts[$#parts];      # the last path component has keys
$i=index($last,"?");          # are there any keywords in there?
if ($i == -1)
   {@keywords = @ARGV;}          # none, probably called from shell
 else
   {@keywords=split('\?', substr($last,$i));
    $parts[$#parts] = substr($last,0,$i);}


# if no keywords, tell user how to type them.

if ($#keywords == -1) {
  print $usage;
  exit;
  };


# debugging
# print "<LISTING>\n
# parts are @parts\n
# keywords are @keywords\n
# </LISTING>\n";
# exit;

# otherwise contact the server

$host = "martini.eecs.umich.edu";
$port = 3000;

$sockaddr = 'S n a4 x8';         # packing format

$hostname = `hostname`;          # where I am calling from
chop($hostname);                 # get rid of trailing CR
($name, $aliases, $type, $len, $myaddr) = gethostbyname($hostname);
$here = pack($sockaddr, 2, 0, $myaddr);

($name, $aliases, $type, $len, $destaddr) = gethostbyname($host);

#print ("Name = ", $name ," " addr = ", $destaddr, "\n");
if ($destaddr eq "") {die "No such host: $host. Stopped";}

$there= pack($sockaddr, 2, $port, $destaddr);

($name, $aliases, $protocol) = getprotobyname('tcp');
socket($S, 2, 1, $protocol) || die "socket: $!";
bind ($S, $here) || die "bind: $!";
connect ($S, $there) || die "connect: $!";


select($S);
$| = 1;           # force output
print (@keywords ,"\n");
print "quit\n";
select(STDOUT);
print "<LISTING>\n";
while (<$S>) { print;}
print "</LISTING>\n";
select($S);
exit;

# This is the format of info returned by the geo server.
# in case you decide you want to parse it.

# 0 <city name>
# 1 <county FIPS code> <county name>
# 2 <state/province abbreviation> <state/province name>
# 3 <nation abbreviation> <nation name>
# A <telephone area code>
# E <elevation in feet above mean sea level>
# F <feature code> <feature name>
# L <latitude DD MM SS X> <longitude DDD MM SS X>
# P <1980 census population>
# R <remark>
# T <time zone>
# Z <postal ("ZIP") code>

# Example
# 0 Ithaca
# 1 36109 Tompkins
# 2 NY New York
# 3 US United States
# R county seat
# F 45 Populated place
# L 42 26 26 N  76 29 49 W
# P 28732
# E 814
# Z 14850 14851 14852 14853 14882
# 
# .

From libert@citi.umich.edu  Wed Nov 18 20:46:02 1992
Return-Path: <libert@citi.umich.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10527; Wed, 18 Nov 92 20:46:02 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26525; Wed, 18 Nov 92 20:58:35 +0100
Received: from citi.umich.edu by mcsun.EU.net with SMTP
	id AA18211 (5.65b/CWI-2.187); Wed, 18 Nov 1992 20:58:20 +0100
Message-Id: <9211181958.AA18211@mcsun.EU.net>
From: Tom Libert <libert@citi.umich.edu>
To: davis@dri.cornell.edu
Cc: www-talk@nxoc01.cern.ch
Date: Wed, 18 Nov 92 14:57:21 EST
Subject: Re: a Gateway to the U Mich Geography server

Saw your recent posting regarding a gateway between WWW and my Geographic
Name Server.  Nice!  Something on my TODO list (well down,
unfortunately).  I want to let you know that some significant
enhancements are underway, and the server protocol will very likely be
changing within the next few months.  I'll be providing significantly
more data, and will provide global coverage.  I'll try to stay in
touch with you regarding these changes.  In any case, feel free to
contact me directly if you have any questions or suggestions about
the service.

Tom Libert
Center for Information Technology Integration
University of Michigan

From marca@wintermute.ncsa.uiuc.edu  Thu Nov 19 01:04:10 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11871; Thu, 19 Nov 92 01:04:10 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA03808; Thu, 19 Nov 92 01:16:39 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA04329
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 18 Nov 92 18:16:22 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA08693; Wed, 18 Nov 92 18:17:33 -0800
Date: Wed, 18 Nov 92 18:17:33 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211190217.AA08693@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: hangs/multiple servers

More questions.....

I've noticed occasionally that trying to contact an http server that
seems to be down (at least with ViolaWWW & MidasWWW) will result in
hangs (or very very long pauses).  Shouldn't a 30-second timeout or
something similar be in effect at all times?

Also, is there any way to specify backup servers?  Does anyone else
think this would be useful?

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From rik@daneel.rdt.monash.edu.au  Thu Nov 19 01:28:45 1992
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12004; Thu, 19 Nov 92 01:28:45 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA08822; Thu, 19 Nov 92 01:41:09 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA26900; Thu, 19 Nov 92 10:40:43 +1000
Message-Id: <9211190040.AA26900@daneel.rdt.monash.edu.au>
To: www-talk@nxoc01.cern.ch
Subject: Re: hangs/multiple servers 
In-Reply-To: Your message of "18 Nov 92 18:17:33 PST."
             <9211190217.AA08693@wintermute.ncsa.uiuc.edu> 
Date: Thu, 19 Nov 92 11:40:42 -1000
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

Marc Andreessen wrote:

> Also, is there any way to specify backup servers?  Does anyone else
> think this would be useful?

After the problems with info.cern.ch, I'd say yes, it would be useful.
The main problems I see:

a) If the backup is done in the document, the HTML format would need
to change. I'll leave this issue to others.

b) Keeping the data up-to-date, and consistent could be difficult.  For
example, all documents must be relatively addressed to be able to move
them between systems.  This is not always possible, for example, if
different ``schemes'' are used, or if different ports are used on the
same machine, then I believe the whole machine name needs to be
respecified.  This problem could be partially solved by doing a
``search-and-replace'' on all addresses as the document is moved.

One possible way to implement backups is to have the client do it (makes
the client too clever?).  The client could have a list of hosts, and for
each one, have a list of backup servers, to try if the main server is
down.  The problem with this is that the list is much more difficult
to maintain, if everyone needs a copy, and only the clients that have
implemented this would benefit.

Just some random thoughts,
rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au         || Systems Programmer
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH) || and Administrator
Faculty of Computing and Information Technology,   || Vic. Institute of
Caulfield Campus, Monash University, Australia     || Forensic Pathology

From TONYJ@scs.slac.stanford.edu  Thu Nov 19 03:39:27 1992
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12609; Thu, 19 Nov 92 03:39:27 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07965; Thu, 19 Nov 92 03:51:55 +0100
Date: Wed, 18 Nov 1992 18:51 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: hangs/multiple servers
To: marca@ncsa.uiuc.edu
Cc: www-talk@nxoc01.cern.ch
Message-Id: <FAE954AE90203760@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"marca@ncsa.uiuc.edu"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

>I've noticed occasionally that trying to contact an http server that
>seems to be down (at least with ViolaWWW & MidasWWW) will result in
>hangs (or very very long pauses).  Shouldn't a 30-second timeout or
>something similar be in effect at all times?

The way I would like MidasWWW to work is that it would try to connect for about 
2 seconds, after which a dialog box would pop up looking something like:

                  ------------------------------------
                  |    Connecting to XXX.XXX.XXX...  |
                  |                                  |
                  |            -----------           | 
                  |            | Abort!  |           |
                  ------------------------------------

Where you click on abort if you get tired of waiting.

Only problem is that I don't know how to achieve this, since the Unix "connect"
routine I use to connect to the remote server is synchronous. If anyone has
an example of a portable way to asnychronously connect over TCPIP I would be
happy to incoportate it. (In fact I don't even know how to set the timeout
period). 

>Also, is there any way to specify backup servers?  Does anyone else
>think this would be useful?

Yes this would be very useful, especially for the "master indexes" such as 
"academic information" at CERN. Probably not so easy to provide though...

Tony

From marca@wintermute.ncsa.uiuc.edu  Thu Nov 19 04:29:11 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12795; Thu, 19 Nov 92 04:29:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA20231; Thu, 19 Nov 92 04:41:41 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11904
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 18 Nov 92 21:41:25 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA09366; Wed, 18 Nov 92 21:42:37 -0800
Date: Wed, 18 Nov 92 21:42:37 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211190542.AA09366@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: html-mode.el update

Following is the latest html-mode -- a few bugs have been fixed, and
some new features added.  If you use this, send me a note; if you have
ideas on how it could specifically be made to be smarter and more
helpful, let me know; if you don't think I should be mailing this to
everyone on www-talk, let me know that too (there was quite a bit of
initial interest in an html mode, so that's why I'm mailing it out
now).

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu

;;; --------------------------------------------------------------------------
;;; HTML mode, based on text mode.
;;; Copyright (C) 1985 Free Software Foundation, Inc.
;;; Copyright (C) 1992 National Center for Supercomputing Applications.
;;; NCSA modifications by Marc Andreessen (marca@ncsa.uiuc.edu).
;;;
;;; This program is free software; you can redistribute it and/or
;;; modify it under the terms of the GNU General Public License as
;;; published by the Free Software Foundation; either version 1, or
;;; (at your option) any later version.
;;;
;;; This program is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;; General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Emacs; see the file COPYING.  If not, write to the
;;; Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
;;;
;;; -------------------------------- CONTENTS --------------------------------
;;;
;;; html-mode: Major mode for editing HTML hypertext documents.
;;; $Revision: 1.18 $
;;; $Date: 1992/11/19 05:39:25 $
;;;
;;; Canonical list of features:
;;;   See below.
;;;
;;; ------------------------------ INSTRUCTIONS ------------------------------
;;;
;;; Load html-mode.el before editing HTML documents.  html-mode will
;;; detect the ``.html'' suffix and activate itself appropriately.
;;;
;;; You are assumed to be at least somewhat familiar with HTML format.
;;; If you aren't, read about it first (see below).
;;;
;;; Here are key sequences and corresponding commands:
;;;
;;; NORMAL COMMANDS:
;;;
;;; C-c a         html-add-address
;;;   Open an address element.
;;;
;;; C-c d         html-add-definition-list
;;;   Open a definition list.  The initial entry is created for you.
;;;   To create subsequent entries, use 'C-c e'.
;;;
;;; C-c e         html-add-definition-entry
;;;   Add a new definition entry in a definition list.  You are
;;;   assumed to be inside a definition list (specifically, at the end
;;;   of another definition entry).
;;;
;;; C-c h         html-add-header
;;;   Add a header.  You are prompted for size (1 is biggest, 2 is
;;;   next biggest) and header contents.
;;;
;;; C-c i         html-add-list-or-menu-item
;;;   Add a new list or menu item in a list or menu.  You are assumed
;;;   to be inside a list or menu (specifically, at the end of another
;;;   item).
;;;
;;; C-c l         html-add-normal-link
;;;   Add a link.  You will be prompted for the link (any string;
;;;   e.g., http://foo.bar/argh/blagh).  The cursor will be left where
;;;   you can type the text that will represent the link in the
;;;   document.
;;;
;;; C-c m         html-add-menu
;;;   Open a menu.  The initial item is created for you.  To create
;;;   additional items, use 'C-c i'.
;;;
;;; C-c p         html-add-paragraph-separator
;;;   Use this command at the end of each paragraph.
;;;
;;; C-c s         html-add-list
;;;   Open a list.  The initial item is created for you.  To create
;;;   additional items, use 'C-c i'.
;;;
;;; C-c t         html-add-title
;;;   Add a title to the document.  You will be prompted for the
;;;   contents of the title.  If a title already exists at the very
;;;   top of the document, the existing contents will be replaced.
;;;
;;; C-c x         html-add-plaintext
;;;   Add plaintext.  The cursor will be positioned where you can type
;;;   plaintext (or insert another file, or whatever).
;;;
;;; COMMANDS THAT OPERATE ON THE CURRENT REGION:
;;;
;;; C-c C-r l     html-add-normal-link-to-region
;;;   Add a link that will be represented by the current region.  You
;;;   will be prompted for the link (any string, as with
;;;   html-add-normal-link).
;;;
;;; C-c C-r r     html-add-reference-to-region
;;;   Add a reference (a link that does not reference anything) that
;;;   will be represented by the current region.  You will be prompted
;;;   for the name of the link; if you just press RET, a numeric name
;;;   will be created for you.
;;;
;;; SPECIAL COMMANDS:
;;;
;;; <, >, &
;;;   These are overridden to output &lt;, &gt;, and &amp;
;;;   respectively.  The real characters <, >, and & can be entered
;;;   into the text either by prepending 'C-c' to the character or by
;;;   using the Emacs quoted-insert (C-q) command.
;;;
;;; C-c <, C-c >, C-c &
;;;   See '< > &' above.
;;;
;;; NOTE: The key bindings above are what I find to be useful and easy
;;; to remember.  If you have ideas on how to make them easier to
;;; handle for yourself or other people, please let me know.
;;; (Ideally, these commands all go in menus; to that end, someday
;;; soon I'll add a Lucid Emacs menu to html-mode.)
;;;
;;; ---------------------------- ADDITIONAL NOTES ----------------------------
;;;
;;; If you are running Epoch or Lucid Emacs, highlighting will be used
;;; to deemphasize HTML message elements as they are created.  You can
;;; turn this off; see the source code.
;;;
;;; To reorder all of the link NAME fields in your message (in order
;;; of their occurrence in the text), use:
;;;
;;; html-reorder-numeric-names
;;;   Reorder the NAME fields for links in the current buffer.  The
;;;   new ordering starts at 1 and increases monotonically through the
;;;   buffer.  If optional arg REORDER-NON-NUMERIC is non-nil, then
;;;   non-numeric NAME's will also be numbered, else they won't.
;;;
;;; -------------------------------- GOTCHAS ---------------------------------
;;;
;;; HTML documents can be tricky.  html-mode is not smart enough to
;;; enforce correctness or sanity, so you have to do that yourself.
;;;
;;; In particular, html-mode is smart enough to generate unique
;;; numeric NAME id's for all links that were (1) created via an
;;; html-mode command or (2) present in the file when it was loaded.
;;; Any other links (e.g. links added via Emacs cut and paste) may
;;; have ID's that conflict with ID's html-mode generates.  You must
;;; watch for this and fix it when appropriate; otherwise, your
;;; hypertext document will not work correctly.
;;;
;;; html-reorder-numeric-names can be used to reset all of the NAME
;;; id's in a document to an ordered sequence; this will also give
;;; html-mode a chance to look over the document and figure out what
;;; new links should be named to be unique.
;;;
;;; ------------------------- WHAT HTML-MODE IS NOT --------------------------
;;;
;;; html-mode is not a mode for *browsing* HTML documents.  In
;;; particular, html-mode provides no hypertext capabilities.  There
;;; is a clear need for an HTML browser; if you write one, let me
;;; know.
;;;
;;; ------------------------------ WHAT HTML IS ------------------------------
;;;
;;; HTML (HyperText Markup Language) is a format for hypertext
;;; documents.  For more information on HTML, telnet to info.cern.ch.
;;;
;;; --------------------------------------------------------------------------
;;; LCD Archive Entry:
;;; html-mode|Marc Andreessen|marca@ncsa.uiuc.edu|
;;; Major mode for editing HTML hypertext files.|
;;; $Date: 1992/11/19 05:39:25 $|$Revision: 1.18 $|~/modes/html-mode.el.Z|
;;; --------------------------------------------------------------------------

;; TODO:
;; sgml-mode stuff.

(provide 'html-mode)

;;; ------------------------------- variables --------------------------------

(defvar html-use-highlighting t
  "*Flag to use highlighting for HTML directives in Epoch or Lucid Emacs; 
if non-NIL, highlighting will be used.")

(defvar html-deemphasize-color "grey80"
  "*Color for de-highlighting HTML directives in Epoch or Lucid Emacs.")

(defvar html-emphasize-color "yellow"
  "*Color for highlighting HTML something-or-others in Epoch or Lucid Emacs.")

;;; --------------------------------- setup ----------------------------------

(defvar html-mode-syntax-table nil
  "Syntax table used while in html mode.")

(defvar html-mode-abbrev-table nil
  "Abbrev table used while in html mode.")
(define-abbrev-table 'html-mode-abbrev-table ())

(if html-mode-syntax-table
    ()
  (setq html-mode-syntax-table (make-syntax-table))
  (modify-syntax-entry ?\" ".   " html-mode-syntax-table)
  (modify-syntax-entry ?\\ ".   " html-mode-syntax-table)
  (modify-syntax-entry ?' "w   " html-mode-syntax-table))

(defvar html-mode-map nil "")
(if html-mode-map
    ()
  (setq html-mode-map (make-sparse-keymap))
  (define-key html-mode-map "\t" 'tab-to-tab-stop)
  (define-key html-mode-map "\C-ca" 'html-add-address)
  (define-key html-mode-map "\C-cd" 'html-add-definition-list)
  (define-key html-mode-map "\C-ce" 'html-add-definition-entry)
  (define-key html-mode-map "\C-ch" 'html-add-header)
  (define-key html-mode-map "\C-ci" 'html-add-list-or-menu-item)
  (define-key html-mode-map "\C-cl" 'html-add-normal-link)
  (define-key html-mode-map "\C-cm" 'html-add-menu)
  (define-key html-mode-map "\C-cp" 'html-add-paragraph-separator)
  (define-key html-mode-map "\C-cs" 'html-add-list)
  (define-key html-mode-map "\C-ct" 'html-add-title)
  (define-key html-mode-map "\C-cx" 'html-add-plaintext)
  (define-key html-mode-map "<" 'html-less-than)
  (define-key html-mode-map ">" 'html-greater-than)
  (define-key html-mode-map "&" 'html-ampersand)
  (define-key html-mode-map "\C-c<" 'html-real-less-than)
  (define-key html-mode-map "\C-c>" 'html-real-greater-than)
  (define-key html-mode-map "\C-c&" 'html-real-ampersand)
  (define-key html-mode-map "\C-c\C-rl" 'html-add-normal-link-to-region)
  (define-key html-mode-map "\C-c\C-rr" 'html-add-reference-to-region)
)

;;; --------------------------- buffer-local vars ----------------------------

(defvar html-link-counter-default 0)
(defvar html-link-counter nil)
(make-variable-buffer-local 'html-link-counter)
(setq-default html-link-counter html-link-counter-default)

;;; ------------------------------ highlighting ------------------------------

(defvar html-running-lemacs (string-match "Lucid" emacs-version)
  "Non-nil if running Lucid Emacs.")

(defvar html-running-epoch (boundp 'epoch::version)
  "Non-nil if running Epoch.")

(if (and html-running-epoch html-use-highlighting)
    (progn
      (defvar html-deemphasize-style (make-style))
      (set-style-foreground html-deemphasize-style html-deemphasize-color)
      (defvar html-emphasize-style (make-style))
      (set-style-foreground html-emphasize-style html-emphasize-color)))

(if (and html-running-lemacs html-use-highlighting)
    (progn
      (defvar html-deemphasize-style (make-face 'html-deemphasize-face))
      (set-face-foreground html-deemphasize-style html-deemphasize-color)
      (defvar html-emphasize-style (make-face 'html-emphasize-face))
      (set-face-foreground html-emphasize-style html-emphasize-color)))

(if html-use-highlighting
    (progn
      (if html-running-lemacs
          (defun html-add-zone (start end style)
            "Add a Lucid Emacs extent from START to END with STYLE."
            (let ((extent (make-extent start end)))
              (set-extent-face extent style)
              (set-extent-data extent 'html-mode))))
      (if html-running-epoch
          (defun html-add-zone (start end style)
            "Add an Epoch zone from START to END with STYLE."
            (let ((zone (add-zone start end style)))
              (epoch::set-zone-data zone 'html-mode))))))

(defun html-maybe-deemphasize-region (start end)
  "Maybe deemphasize a region of text.  Region is from START to END."
  (and (or html-running-epoch html-running-lemacs)
       html-use-highlighting
       (html-add-zone start end html-deemphasize-style)))

;;; ----------------------------- link commands ------------------------------

(defun html-add-link (link-object)
  "Add a link."
  (let ((start (point)))
    (setq html-link-counter (1+ html-link-counter))
    (insert "<A NAME=" (format "%d" html-link-counter) 
            " HREF=" link-object ">")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "</A>")
    (push-mark)
    (forward-char -4)
    (html-maybe-deemphasize-region (1+ (point)) (+ (point) 4))))

(defun html-add-normal-link (link)
  "Make a link.  There is no completion of any kind yet."
  (interactive "sLink to: ")
  (html-add-link link))

(defun html-add-normal-link-to-region (link start end)
  "Make a link that applies to the current region.  Again,
no completion."
  (interactive "sLink to: \nr")
  (save-excursion
    (goto-char end)
    (save-excursion
      (goto-char start)
      (setq html-link-counter (1+ html-link-counter))
      (insert "<A NAME=" (format "%d" html-link-counter)
              " HREF=" link ">")
      (html-maybe-deemphasize-region start (1- (point))))
    (insert "</A>")
    (html-maybe-deemphasize-region (- (point) 3) (point))))

(defun html-add-reference-to-region (name start end)
  "Add a reference point (a link with no reference of its own) to
the current region."
  (interactive "sName (or RET for numeric): \nr")
  (and (string= name "")
       (progn
         (setq html-link-counter (1+ html-link-counter))
         (setq name (format "%d" html-link-counter))))
  (save-excursion
    (goto-char end)
    (save-excursion
      (goto-char start)
      (insert "<A NAME=" name ">")
      (html-maybe-deemphasize-region start (1- (point))))
    (insert "</A>")
    (html-maybe-deemphasize-region (- (point) 3) (point))))

;;; --------------------------- document elements ----------------------------

(defun html-add-title (title)
  "Add or modify a title."
  (interactive "sTitle: ")
  (save-excursion
    (goto-char (point-min))
    (if (and (looking-at "<TITLE>")
             (save-excursion
               (forward-char 7)
               (re-search-forward "[^<]*" 
                                  (save-excursion (end-of-line) (point)) 
                                  t)))
        ;; Plop the new title in its place.
        (replace-match title t)
      (insert "<TITLE>")
      (html-maybe-deemphasize-region (point-min) (1- (point)))
      (insert title)
      (insert "</TITLE>")
      (html-maybe-deemphasize-region (- (point) 7) (point))
      (insert "\n"))))

(defun html-add-header (size header)
  "Add a header."
  (interactive "sSize (1 or 2): \nsHeader: ")
  (let ((start (point)))
    (insert "<H" size ">")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert header)
    (setq start (point))
    (insert "</H" size ">\n")
    (html-maybe-deemphasize-region (1+ start) (1- (point)))))

(defun html-add-paragraph-separator ()
  "Add a paragraph separator."
  (interactive)
  (let ((start (point)))
    (insert "  <P>\n\n")
    (html-maybe-deemphasize-region (+ start 2) (- (point) 2))))

(defun html-add-definition-list ()
  "Add a definition list."
  (interactive)
  (let ((start (point)))
    (insert "<DL>\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "<DT> ")
    ;; Point goes right there.
    (save-excursion
      (insert "\n<DD> \n")
      (setq start (point))
      (insert "</DL>\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; Mark goes after list -- this doesn't work.
      (push-mark))))

(defun html-add-definition-entry ()
  "Add a definition entry.  Assume we're at the end of a previous
entry."
  (interactive)
  (let ((start (point)))
    (insert "\n<DT> ")
    (save-excursion
      (insert "\n<DD> "))))

(defun html-add-plaintext ()
  "Add plaintext."
  (interactive)
  (let ((start (point)))
    (insert "<XMP>\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (save-excursion
      (insert "\n")
      (setq start (point))
      (insert "</XMP>\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; This doesn't work.
      (push-mark))))

(defun html-add-list-internal (type)
  (let ((start (point)))
    (insert "<" type ">\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "<LI> ")
    ;; Point goes right there.
    (save-excursion
      (insert "\n")
      (setq start (point))
      (insert "</" type ">\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; Mark goes after list -- this doesn't work.
      (push-mark))))

(defun html-add-list ()
  "Add a list."
  (interactive)
  (html-add-list-internal "UL"))

;; Is this correct?  Viola doesn't seem to do anything with it.
(defun html-add-menu ()
  "Add a menu."
  (interactive)
  (html-add-list-internal "MENU"))

(defun html-add-list-or-menu-item ()
  "Add a list or menu item.  Assume we're at the end of the
last item."
  (interactive)
  (let ((start (point)))
    (insert "\n<LI> ")))

(defun html-add-address ()
  "Add an address."
  (interactive)
  (let ((start (point)))
    (insert "<ADDRESS> ")
    (html-maybe-deemphasize-region start (1- (point)))
    (save-excursion
      (setq start (point))
      (insert "  </ADDRESS>\n")
      (html-maybe-deemphasize-region (+ start 2) (1- (point)))
      ;; Obviously this doesn't work here, so I don't
      ;; see why you're being an idiot and still doing it
      ;; like this....
      (push-mark))))

(defun html-less-than ()
  (interactive)
  (insert "&lt;"))

(defun html-greater-than ()
  (interactive)
  (insert "&gt;"))

(defun html-ampersand ()
  (interactive)
  (insert "&amp;"))

(defun html-real-less-than ()
  (interactive)
  (insert "<"))

(defun html-real-greater-than ()
  (interactive)
  (insert ">"))

(defun html-real-ampersand ()
  (interactive)
  (insert "&"))

;;; ----------------------- html-reorder-numeric-names -----------------------

(defun replace-string-in-buffer (start end newstring)
  (save-excursion
    (goto-char start)
    (delete-char (1+ (- end start)))
    (insert newstring)))

(defun html-reorder-numeric-names (&optional reorder-non-numeric)
  "Reorder the NAME fields for links in the current buffer.  The
new ordering starts at 1 and increases monotonically through the buffer.
If optional arg REORDER-NON-NUMERIC is non-nil, then non-numeric NAME's
will also be numbered, else they won't.

Beware that doing this will possibly mess up references to specific
links within this document (e.g., HREF=#12) or by other documents.
This command is mainly intended for use during the initial creation
stage of a document, especially when this creation involves cutting
and pasting from other documents (which it shouldn't, since this is
hypertext :-)."
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (setq html-link-counter 0)
    (while (re-search-forward "<A[ \t\n]+NAME=" (point-max) t)
      (let* ((start (match-end 0))
             (end (save-excursion
                    (re-search-forward "[ \t\n>]" 
                                       (point-max) 
                                       t)
                    (match-beginning 0)))
             (subst (buffer-substring start end)))
        (and subst
             ;; Proceed only if we reorder non-numeric links or
             ;; this is in fact numeric (i.e. > 0).
             (or reorder-non-numeric (> (string-to-int subst) 0))
             (progn
               (setq html-link-counter (1+ html-link-counter))
               (replace-string-in-buffer start (1- end)
                (format "%d" html-link-counter))))))))

;;; ------------------------------- html-mode --------------------------------

(defun html-mode ()
  "Major mode for editing HTML hypertext documents.  Special commands:\\{html-mode-map}
Turning on html-mode calls the value of the variable html-mode-hook,
if that value is non-nil.

More extensive documentation is available in the file 'html-mode.el'.
The latest (possibly unstable) version of this file will always be available
on anonymous FTP server ftp.ncsa.uiuc.edu in /outgoing/marca."
  (interactive)
  (kill-all-local-variables)
  (use-local-map html-mode-map)
  (setq mode-name "Html")
  (setq major-mode 'html-mode)
  (setq local-abbrev-table html-mode-abbrev-table)
  (set-syntax-table html-mode-syntax-table)
  (run-hooks 'html-mode-hook))

;;; ------------------------------- our hooks --------------------------------

(defun html-find-file-hook ()
  "Hook called from find-file-hooks.  Set html-link-counter to 
the highest link value in the document (the next link created will
be one greater than that) to insure unique (numeric) link ID's."
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "<A[ \t\n]+NAME=" (point-max) t)
      (let* ((start (match-end 0))
             (end (save-excursion
                    (re-search-forward "[ \t\n>]"
                                       (point-max)
                                       t)
                    (match-beginning 0)))
             (subst (buffer-substring start end)))
        (and subst
             ;; Safe to do compare, since string-to-int passed a non-number
             ;; returns 0.
             (> (string-to-int subst) html-link-counter)
             (setq html-link-counter (string-to-int subst)))))))

;;; ------------------------------- hook setup -------------------------------

;; Author: Daniel LaLiberte (liberte@cs.uiuc.edu).
(defun html-postpend-unique-hook (hook-var hook-function)
  "Postpend HOOK-VAR with HOOK-FUNCTION, if it is not already an element.
hook-var's value may be a single function or a list of functions."
  (if (boundp hook-var)
      (let ((value (symbol-value hook-var)))
        (if (and (listp value) (not (eq (car value) 'lambda)))
            (and (not (memq hook-function value))
                 (set hook-var (append value (list hook-function))))
          (and (not (eq hook-function value))
               (set hook-var (append value (list hook-function))))))
    (set hook-var (list hook-function))))

(html-postpend-unique-hook 'find-file-hooks 'html-find-file-hook)

;;; ------------------------------ final setup -------------------------------

(or (assoc "\\.html$" auto-mode-alist)
    (setq auto-mode-alist (cons '("\\.html$" . html-mode) auto-mode-alist)))


From connolly@pixel.convex.com  Thu Nov 19 05:43:14 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12924; Thu, 19 Nov 92 05:43:14 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA07607; Thu, 19 Nov 92 05:55:47 +0100
Received: from convex.convex.com by mcsun.EU.net with SMTP
	id AA16779 (5.65b/CWI-2.187); Thu, 19 Nov 1992 05:55:31 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA26388; Wed, 18 Nov 92 22:54:12 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA08886; Wed, 18 Nov 92 22:54:11 -0600
Message-Id: <9211190454.AA08886@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: html-mode.el update 
In-Reply-To: Your message of "Wed, 18 Nov 92 21:42:37 PST."
             <9211190542.AA09366@wintermute.ncsa.uiuc.edu> 
Date: Wed, 18 Nov 92 22:54:10 CST
From: Dan Connolly <connolly@pixel.convex.com>


Here's a patch to add a function to fix all the existing
HREFs in an HTML file so they'll have quotes around them.

Dan

*** /mnt/connolly/foo	Wed Nov 18 22:51:50 1992
--- html-mode.el	Wed Nov 18 22:50:32 1992
***************
*** 517,522 ****
--- 517,543 ----
                 (setq html-link-counter (1+ html-link-counter))
                 (replace-string-in-buffer start (1- end)
                  (format "%d" html-link-counter))))))))
+ 
+ (defun html-quote-hrefs ()
+   "Insert quotes around all HREF attribute value literals.
+ 
+ This remedies the problem with old html files that can't be
+ processed by SGML parsers. That is, changes
+ <A HREF=foo> to <A HREF="foo">.
+ 
+ By Dan Connolly, so don't yell at Mark if it breaks."
+   (interactive)
+   (save-excursion
+     (goto-char (point-min))
+     (setq html-link-counter 0)
+     (while (re-search-forward "<[aA][ \t\n]+\\([nN][aA][mM][eE]=[a-zA-Z0-9]+[ \t\n]+\\)?[hH][rR][eE][fF]=" (point-max) t)
+       (cond ((null (looking-at "\""))
+ 	     (insert "\"")
+ 	     (re-search-forward "[ \t\n>]" (point-max) t)
+ 	     (forward-char -1)
+ 	     (insert "\"")
+ 	     ))
+       ) ) )
  
  ;;; ------------------------------- html-mode --------------------------------
  

From K.Hoadley@directory.rl.ac.uk  Thu Nov 19 10:32:43 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13352; Thu, 19 Nov 92 10:32:43 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19628; Thu, 19 Nov 92 10:45:12 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <01457-0@directory.rl.ac.uk>; Thu, 19 Nov 1992 09:34:25 +0000
Date: Thu, 19 Nov 1992 09:38:35 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Sender: K.Hoadley@directory.rl.ac.uk
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: Re: hangs/multiple servers
To: www-talk@nxoc01.cern.ch
Message-Id: <Ximap.722166319.4084.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

The simple way to provide multiple servers would be to register the
server name in the DNS with multiple A (address) records pointing to
different machines. Then the clients could be mod'ed could try the second
or third ... addresses if they couldn't get through to the first.

How you keep info upto date accross multiple servers is a different matter,
need some form of replication a la DNS zone transfers (or Quipu's extensions
to X.500 ) ... Mind you, replication within www is a harder issue: a server
might be sitting in front of datasets too large to sensibly duplicate.

Kevin Hoadley, Rutherford Appleton Laboratory

From connolly@pixel.convex.com  Thu Nov 19 11:25:10 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13575; Thu, 19 Nov 92 11:25:10 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22828; Thu, 19 Nov 92 11:37:43 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA01932; Thu, 19 Nov 92 04:37:25 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA16353; Thu, 19 Nov 92 04:37:23 -0600
Message-Id: <9211191037.AA16353@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML DTD issues
Date: Thu, 19 Nov 92 04:37:23 CST
From: Dan Connolly <connolly@pixel.convex.com>


The thrust to register HTML with the authorities has
spurred me to look over the DTD again. I've found
some problems.

1. Currently the NAME attribute of an anchor is declared
as CDATA, i.e. just about anything. There's an SGML thingy
called an ID. SGML parsers enforce uniqueness among the IDs
of a document. Seems like that's what we want for ID names.

But an SGML ID has to start with a letter. So all the
HTML files that use numbers as anchor names will break.

2. I introduced two tag names when I drafted the DTD:
	HTML contains the whole document. I defined it
so you can omit both the start and the end tags, so it's
inferred by SGML parsers. I don't think I can avoid some
top-level tag.
	DOCUMENT contains most of the "body" -- all the
headings and paragraphs. I did this to avoid something
called mixed content, which causes complications.
I could rename this element as BODY, and introduce a
omitable HEADING tag to surround the TITLE, NEXTID,
and ISINDEX tags.

3. I stuck anchors in as an inclusion, meaning they
could be used just about anywhere. I thought stuff
like
<a name=foo><h1>Foo</h1></a>
was legal, but neither linemode nor the midas browser
groks.

I'm editing the DTD to restrict the usage of anchors
to only contain text strings.

4. The OL tag is disappearing. It's no longer documented
in the web, and it's not supported by MidasWWW. Should
I delete it from the DTD?

5. What about <HP1> thru <HP5>... should we include them?
I'd prefer <em>, <tt>, <cite>, ala TeX. Or we could
go with the O'Reilly/Hal DocBook tags:
<Emphasis>, <OopsChar>, <wordasword>,<CiteBook>,<Subscript>,
<Superscript>.

6. Any more thoughts on the BaseAddress tag?

7. The HTML tags documentation says Listing sections can contain
any ISO Latin 1 characters. The SGML standard mentions ISO 646,
i.e. ascii, as the default, but the sgmls parser, the linemode
browser, and MidasWWW all seem to grok Latin1 just fine.

Dan

From timbl@www3.cern.ch  Thu Nov 19 11:41:22 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13635; Thu, 19 Nov 92 11:41:22 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23735; Thu, 19 Nov 92 11:53:54 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00225; Thu, 19 Nov 92 11:49:33 +0100
Date: Thu, 19 Nov 92 11:49:33 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191049.AA00225@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Tom Libert <libert@citi.umich.edu>
Subject: Re: a Gateway to the U Mich Geography server
Cc: davis@dri.cornell.edu, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



From the network point of view, there is one logical place to run this
gateway, and that it at umich, preferably on the same machine as the base  
server.

Perhaps you two could come to some arrangement?  We'd all be glad of it!

By the way, there are lots of neat ways I could think of to display the  
results, like

<h1>what you searched for</h1>

<H2>West bend</H2>
<dl>
<dt>Poulation<dd>14354
<dt>coordinates<dd>State: New York(NY). ZIP Codes: 10000, Areas codes: 508 607
</dl>
Remarkably the only produceer of daimonds and pipes in the state.


but I'll leave that to someone in the US!

	Tim BL
	

From timbl@www3.cern.ch  Thu Nov 19 12:06:46 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13717; Thu, 19 Nov 92 12:06:46 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25218; Thu, 19 Nov 92 12:19:16 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00242; Thu, 19 Nov 92 12:14:52 +0100
Date: Thu, 19 Nov 92 12:14:52 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191114.AA00242@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: hangs/multiple servers
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Also, is there any way to specify backup servers?  Does anyone else
> think this would be useful?

Yes... it certainly would.
 

 First of all, the final solution seems to be to use a globally distributed  
replicated name server for documents or servers. Like x500 which isn't here  
yet. The name service would return multiple pointers. The client could chose
 intelligently which to try first.  But we don't have that infrastructure yet.
 

In the mean time, the question is where to put the information.
In teh new HTTP protocol there are a number of objects which can be
returned ateth protocol level (rather than the data level) which include
error objects and forwards. A forward can contain multiple pointers.
 However, it doesn't help reliability much because the server which hold the  
forwarding info will be just as unreliable! 

 

So one considers putting the multiple URLs (addresses) into the link in the
document.  This smells too, because the positions of servers for different
parts of the abstract document space will be constantly evolving, and so the
links will be soon out of date, and that is grim for documents which may last  
20 years...

The next solution Rik just mentioned:
>  One possible way to implement backups is to have the client do it (makes
>  the client too clever?).  The client could have a list of hosts, and for
>  each one, have a list of backup servers, to try if the main server is
>  down.  The problem with this is that the list is much more difficult
>  to maintain, if everyone needs a copy, and only the clients that have
>  implemented this would benefit.

But it is a simple stopgap.  The way I would see doing it
in practice would be to call the name translation rule module (HTRules.c)
from the client as currently from the daemon httpd. The rules would
be extended to include a "try" operator, like "map" but
allowing continues processing of the rule file if the access failed.

This would be useful in the server too... for example to pick up date from some
remote mounted disk which is the original, but if that fails to use a cached  
copy updated last night.

Tim


From K.Hoadley@directory.rl.ac.uk  Thu Nov 19 14:04:35 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14133; Thu, 19 Nov 92 14:04:35 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00767; Thu, 19 Nov 92 14:17:01 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <01684-0@directory.rl.ac.uk>; Thu, 19 Nov 1992 13:06:04 +0000
Date: Thu, 19 Nov 1992 13:14:33 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Sender: K.Hoadley@directory.rl.ac.uk
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: Comments in HTML ?
To: www-talk@nxoc01.cern.ch
Message-Id: <Ximap.722179021.2781.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Is there any way to include comments in html documents ? In sgml ?

Does any of the existing WWW code support comments ?

Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk

From timbl@www3.cern.ch  Thu Nov 19 14:24:24 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14176; Thu, 19 Nov 92 14:24:24 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01997; Thu, 19 Nov 92 14:36:40 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00503; Thu, 19 Nov 92 14:32:11 +0100
Date: Thu, 19 Nov 92 14:32:11 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191332.AA00503@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: HTML DTD issues
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Dan,

Your work on the SGML side (as all your work) is much apreciated!

>  Date: Thu, 19 Nov 92 04:37:23 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>  

>  

>  The thrust to register HTML with the authorities has
>  spurred me to look over the DTD again. I've found some
>  problems.
>  

>  1. Currently the NAME attribute of an anchor is declared
>  as CDATA, i.e. just about anything. There's an SGML thingy
>  called an ID. SGML parsers enforce uniqueness among the
>  IDs of a document. Seems like that's what we want for ID
>  names.
>  

>  But an SGML ID has to start with a letter. So all the
>  HTML files that use numbers as anchor names will break.

The enforcement of uniqueness is useful, and it is what we want.
It is unfortunate that the very same constraint lead to the use of numbers!
This is a hangup of the NeXT editor (which i still use, as
until somone makes a more convenient editor!) but we oughtn't to
worry about it.  A future editor could generate Z[0-9]* names.
We could even specify that Z[0-9]* are related to a NEXTID attribute
somewhere for the generation of time-unique IDs.

The only neat thing about CDATA is that it would allow a gateway
to put in something which as come from the data. For example,
a glossary generator might generate anchors for each term
whose name equals the term, and then generate index entries
pointing to that.

What do you think?

>  2. I introduced two tag names when I drafted the DTD:
>  	HTML contains the whole document. I defined it
>  so you can omit both the start and the end tags, so it's
>  inferred by SGML parsers. I don't think I can avoid some
>  top-level tag.
>  	DOCUMENT contains most of the "body" -- all the
>  headings and paragraphs. I did this to avoid something
>  called mixed content, which causes complications.  I
>  could rename this element as BODY, and introduce a
>  omitable HEADING tag to surround the TITLE, NEXTID, and
>  ISINDEX tags.

I like the latter idea.  Header and Body fit in well with mail
nomenclature, wherase "document" is normally the whole thing
retrieved.

>  3. I stuck anchors in as an inclusion, meaning they could
>  be used just about anywhere. I thought stuff like <a
>  name=foo><h1>Foo</h1></a> was legal, but neither linemode
>  nor the midas browser groks.

The line mdoe doesn't?  It should.  Only titles I wanted to insist were
plain ascii text....
Turns out to be a bug in HTML.c -- fixed for next release.

>  I'm editing the DTD to restrict the usage of anchors to
>  only contain text strings.

I don't like that.... I think that especially as we introduce
highlighting, anchors will want to be general areas of text, so
long as they are nested properly. (An "SGML attitude" restriction
which Frank Kappe objected to I recall).

>  4. The OL tag is disappearing. It's no longer documented
>  in the web, and it's not supported by MidasWWW. Should
>  I delete it from the DTD?

You say its useful?  If you havce implemented it, and noone else
objects, then we could put it back in. In principle, with hypertext, you don't  
have to number tyhings, you can refer to them with a link. However, you
can imagine the abstract difference between an ordered list and 

a sack of objects being important.  [For example, a list of
instructions is ordered].  I'll put it into the HTML2 list of features.
I suggest everyone  implement OL as UL in programs which, like the line mode  
browser, can't differentiate.


>  5. What about <HP1> thru <HP5>... should we include them?
>  I'd prefer <em>, <tt>, <cite>, ala TeX. Or we could go
>  with the O'Reilly/Hal DocBook tags:  <Emphasis>,
>  <OopsChar>, <wordasword>,<CiteBook>,<Subscript>,
>  <Superscript>.

I agree that numbering them is on the verge of useless.  The trouble is,
you never have enough. Why CiteBook but not CiteProgram? etc etc.
The docbook names are on the long side, aren't they? Not very important
I suppose.

>  6. Any more thoughts on the BaseAddress tag?

Yes. It should be in. I think.  I've mentioned in  
http://info.cern.ch/hypertext/WWW/MarkUp/Future.html

>  7. The HTML tags documentation says Listing sections can
>  contain any ISO Latin 1 characters. The SGML standard
>  mentions ISO 646, i.e. ascii, as the default, but the
>  sgmls parser, the linemode browser, and MidasWWW all seem
>  to grok Latin1 just fine.

I suggest we limit it to ASCII unless something outside the
document says otherwise, while strongly recommending that
8-bit character sets should be handled by the apps.  I have
seen some funnies when two clients both handle 8-bit characters,
but not the same ones.

Does the SGML standard say how to specify the character set for
the text?

>  Dan
>  

	Tim

From timbl@www3.cern.ch  Thu Nov 19 15:12:58 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14461; Thu, 19 Nov 92 15:12:58 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA05057; Thu, 19 Nov 92 15:25:02 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00523; Thu, 19 Nov 92 15:20:14 +0100
Date: Thu, 19 Nov 92 15:20:14 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191420.AA00523@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Annotation in WWW
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



Marc,

You ask a good question.  Currently, all we do with existing WWW software is as  
you describe: you need write access to annote it. See

www http://info.cern.ch/hypertext/WWW/DesignIssues/LinkToLiving.html 

   and
www http://info.cern.ch/hypertext/WWW/DesignIssues/Multiuser.html

for discussions in this area.  We would like to include facilities in the
new protocol to allow front-end update.

One observation I have made is that many nodes are basically lists, and the  
option to add a link to the list could be a simple and safer operation than  
allowing full write acess.

The function would be annotate(docid1, docid2) which would, in the simplest  
hypertext case, add a bit of text to the end of doc1 consisting of the title
of doc2, linked to doc2 itself. This function would give allow a "reply"  
feature when used on a mail message. For a newsgroup, it would equate to  
"post". obviously it would be up to a server how it would impelement it (ity  
could maintain alphabestical order for example, it could store the links in a  
separate databse, it could formatthem anyway) -- the requirement would only be  
that at the end, a link from doc1 to doc2 existed.

I'd be interested in CSCW people getting involved with the web. Certain servers
could for example mention their ability to support concurrent editing of  
documents for clients which support that. 


Tim

From emv@garnet.msen.com  Thu Nov 19 16:13:11 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14828; Thu, 19 Nov 92 16:13:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA09275; Thu, 19 Nov 92 16:25:34 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0msDke-00009rC@garnet.msen.com>; Thu, 19 Nov 92 10:24 WET
Date: Thu, 19 Nov 1992 10:22:26 -0500 (EST)
From: Edward Vielmetti <emv@garnet.msen.com>
Subject: Re: HTML DTD issues
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9211191037.AA16353@pixel.convex.com>
Message-Id: <Pine.3.05.9211191025.A15799-a100000@garnet.msen.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

To the extent that we can steal ideas from the DocBook DTD I think we
should!  Talk about getting leverage from existing industry efforts - if
the long run future of WWW is to make it possile to interactively build
books whose chapters live on different sites and that have all of the WWW
hypertext links, we'll have a wonderful outcome.

--Ed

On Thu, 19 Nov 1992, Dan Connolly wrote:

> 5. What about <HP1> thru <HP5>... should we include them?
> I'd prefer <em>, <tt>, <cite>, ala TeX. Or we could
> go with the O'Reilly/Hal DocBook tags:
> <Emphasis>, <OopsChar>, <wordasword>,<CiteBook>,<Subscript>,
> <Superscript>.




From timbl@www3.cern.ch  Thu Nov 19 18:04:43 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15654; Thu, 19 Nov 92 18:04:43 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16234; Thu, 19 Nov 92 18:17:17 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00333; Thu, 19 Nov 92 18:13:01 +0100
Date: Thu, 19 Nov 92 18:13:01 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191713.AA00333@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Visiting CERN to work with the World-Wide Web
Reply-To: timbl@nxoc01.cern.ch


Here at CERN there is not a lot of manpower for developing WWW, and there is a  
lot of pressure for us to work specifically to get local groups' information  
systems up.  However, we need lots of help in keeping the project on course  
...such activities as

  - designing/developing/installing new tools,
  - checking out/incorporating related products on the net,
  - keeping in touch with users and other support groups worldwide
  - maintaining metatools to make the above easier

Now it turns out that there are a number of ways for visitors to come to CERN,  
and we have a limited budget for this.  The exact mechanism used would depend  
on the case, so anyone seriously interested in helping the web along with some  
hard work for 6-12 months should say and we'll look into it. Some factors:

We would obviously be looking for a capable person, preferably with fluent C  
and unix, and probably with experience with web-related software and lots of  
enthusiasm. So I am circulating this only to the www-talk list for now.

This would be an excellent way for a group to gain experience in the web,  
sending out to work here for a year.  We would of course arrange the visit in  
coordination and agreement with the visitor's current employers.

In some ways it is easier to take people from CERN member states (Europe),
and/or from High-Energy physics institutes, but visitors frequently come from  
elsewhere.

The amount of subsistence CERN can pay varies depending on lots of things. If a  
person's institute can pay all of or a fraction of their salary, then that  
tends to influence the finance division favourably!

(Geneva, Switzerland, has lakes and mountains and an international community.  
There is Alpine skiing an hour away and hill walking 20 minutes away. But these  
things are material :-)

Think about it, and mail me if interested.

	Tim BL
	





From timbl@www3.cern.ch  Thu Nov 19 18:19:51 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15741; Thu, 19 Nov 92 18:19:51 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16982; Thu, 19 Nov 92 18:32:12 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00350; Thu, 19 Nov 92 18:27:46 +0100
Date: Thu, 19 Nov 92 18:27:46 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191727.AA00350@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: K.Hoadley@directory.rl.ac.uk
Subject: Re: Comments in HTML ?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



Begin forwarded message:

> Date: Thu, 19 Nov 1992 13:14:33 +0000 (GMT)
> From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>


> Is there any way to include comments in html documents ? In sgml ?

In SGML, yes there is a -- comment start and a -- comment end.
Someone corerct me if I am wrong but I understand that once within
a tag one can use these ... right? Or does it apply to DTDs only?

A comment which is insertable as hidden text is useful too --
and I had forgotten to mention it in the HTML futures list.
I'll put it in.  A previous net consensus was for <comment>...</comment>.

> Does any of the existing WWW code support comments ?

As it happens, the current library supports them, so the line mdoe
browser and anything else based on the library does. But it has
been left out of the doc and so will probably me missing from other browers.

> Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk

Tim BL



__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155


sers

From timbl@www3.cern.ch  Thu Nov 19 18:21:11 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15756; Thu, 19 Nov 92 18:21:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA17070; Thu, 19 Nov 92 18:33:32 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00355; Thu, 19 Nov 92 18:29:03 +0100
Date: Thu, 19 Nov 92 18:29:03 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211191729.AA00355@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: K.Hoadley@directory.rl.ac.uk
Subject: Re: hangs/multiple servers
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Date: Thu, 19 Nov 1992 09:38:35 +0000 (GMT)
> From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>

>  The simple way to provide multiple servers would be to
>  register the server name in the DNS with multiple A
>  (address) records pointing to different machines. Then
>  the clients could be mod'ed could try the second or third
>  ... addresses if they couldn't get through to the first.

Ok, This seems a bery good idea, if that is the functionality which DNS  
supports.
<practical>
Let's try it.... Anyone care to mod HTTP.c? It's not obvious from
the gethostbyname that one is allowed to refer to different
machines:
          struct    hostent {
               char *h_name;  /* official name of host */
               char **h_aliases;   /* alias list */
               int  h_addrtype;    /* host address type */
               int  h_length; /* length of address */
               char **h_addr_list; /* list of addresses from name server */
          };

That look like a list of aliases for one machine, rather than a
list of machines for one alias! But maybe the reverse will work.
So all machines support char **h_addr_list rather than the older
h_addr?   We can probably differentiate using #ifdef h_addr
which is set to a macro if there IS a list.  I assume you need then
separate entries for the virtual duplicate node and the actual
real nodes, so that you can speak to them sepately. Is this normal
and OK?
</practical>

>  How you keep info upto date accross multiple servers is
>  a different matter, need some form of replication a la
>  DNS zone transfers (or Quipu's extensions to X.500 ) ...
>  Mind you, replication within www is a harder issue: a
>  server might be sitting in front of datasets too large
>  to sensibly duplicate.
>  

>  Kevin Hoadley, Rutherford Appleton Laboratory
>  


From connolly@pixel.convex.com  Thu Nov 19 19:37:53 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16376; Thu, 19 Nov 92 19:37:53 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19997; Thu, 19 Nov 92 19:50:23 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA21503; Thu, 19 Nov 92 12:50:00 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA13833; Thu, 19 Nov 92 12:49:58 -0600
Message-Id: <9211191849.AA13833@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Freezing the HTML spec Re: Comments in HTML ? 
In-Reply-To: Your message of "Thu, 19 Nov 92 18:27:46 +0100."
             <9211191727.AA00350@www3.cern.ch> 
Date: Thu, 19 Nov 92 12:49:51 CST
From: Dan Connolly <connolly@pixel.convex.com>


What is the plan for registering HTML with the IETF? The HTML
spec seems to be somewhat in flux. Tim talks a lot about
"HTML futures." There are currently a lot of open issues.
Eventually we have to "shoot the engineers and ship it,"
that is freeze the spec and hand it to the IETF.

I suggest the following steps:

1. Establish a charter for the HTML spec to guide us in
resolving issues -- a sort of requirements spec. Here's
my working list:

	* Establish a well-defined relationship between
	HTML and SGML. Don't include anything in the HTML
	spec that conflicts with the SGML spec.

	* Use the LineMode browser as a reference implementation.
	Try not to include features that www doesn't grok.

	* Support common structural markup: headers, lists, etc.

	* Support W3 addressing syntax.

	* Support links from ranges of text to other documents
	and anchors in other documents.

	* Keep the structure somewhat flat for interchange with
	PC style word processors and other style-per-paragraph
	oriented processors.

2. Establish an HTML spec document, some informative appendixes,
and some examples/test cases. I suggest:

spec: ftp://info.cern.ch/pub/www/doc/html.txt
	from http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
	and its neighbors "Text.html" "Tags.html" "Entities.html"
	and "HTML.dtd"

infomative appendices: "HTMLConstraints.html" "Future.html"

examples: "../Test/test.html"

3. Revise the spec so that it's internally consistent. Right
now, there are some glitches. And the current method of
sending suggestions to Tim and hoping he finds time to make
the edits is no good. Hmmm... we definitely need a CSCW
strategy for group-editing of documents.

4. Register the spec with the IANA or IETF or whatever.

Meanwhile, I think it's pretty important to fix the NeXT editor
and all the files on info.cern.ch. Folks are using that as a
reference, and perpetuating HTML that conflicts with the SGML
standard.

Back to the question at hand...


>Begin forwarded message:
>
>> Date: Thu, 19 Nov 1992 13:14:33 +0000 (GMT)
>> From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
>
>
>> Is there any way to include comments in html documents ? In sgml ?
>
>In SGML, yes there is a -- comment start and a -- comment end.
>Someone corerct me if I am wrong but I understand that once within
>a tag one can use these ... right? Or does it apply to DTDs only?

The <!-- blah blah blah --> construct is only recognized in
the DTD. There's a thing called a processing instruction that
looks like <? blah blah blah> which is recognized in the
instance. The Linemode browser seems to grok.

I think we should mention this construct in the standard, since
we're technically not allowed to disallow it or process it incorrectly.

There's another thing called a marked section that looks like
<![status [ stuff ]]> where status is one of...

IGNORE means ignore this stuff, except recognize nested marked sections.
INCLUDE treat stuff normally
CDATA 	treat stuff as data. Recognize only ]]>
RCDATA 	treat stuff as data. Recognize entity reference (&foo;) and ]]>
TEMP	(why is this in the SGML standard?)

The <![CDATA [ ... ]]> should probably be supported for plaintext
sections somehow, but I can't figure out a scheme that harmonizes
with the linemode implementation.

There's also some character classes MSICHAR, MSOCHAR, MSSCHAR
for markup suppression. Markup between MSICHAR and MSOCHAR is
ignored, and the next character after MSSCHAR is treated as
data rather than markup. Unfortunately, these classes don't
have any members in the reference concrete syntax, and they're
probably not supported by many parsers.

SGML is a mess!

>> Does any of the existing WWW code support comments ?
>
>As it happens, the current library supports them, so the line mdoe
>browser and anything else based on the library does. But it has
>been left out of the doc and so will probably me missing from other browers.
>

Try the <? foo > construct.

Dan


From marca@wintermute.ncsa.uiuc.edu  Thu Nov 19 20:16:52 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16601; Thu, 19 Nov 92 20:16:52 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA20948; Thu, 19 Nov 92 20:29:19 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA08050
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 19 Nov 92 13:29:02 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:timbl@nxoc01.cern.ch id AA10669; Thu, 19 Nov 92 13:30:11 -0800
Date: Thu, 19 Nov 92 13:30:11 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211192130.AA10669@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Freezing the HTML spec Re: Comments in HTML ? 
In-Reply-To: <9211191849.AA13833@pixel.convex.com>
References: <9211191727.AA00350@www3.cern.ch>
	<9211191849.AA13833@pixel.convex.com>

Dan Connolly writes:
> Hmmm... we definitely need a CSCW strategy for group-editing of
> documents.

I'm pulling this outta my rear end, but how about:

(1) Enabling & security mechanism: The HTTP server, in addition to
    specifying which directories/files in the filesystem can be
    obtained by an outside client, also specifies which
    directories/files can be annotated.

(2) Annotation mechanism: HTTP gets a mechanism by which a remote
    browser can add a link to the currently viewed document.  The user
    would be allowed to specify the representation (label) for the
    link and the HREF field of the link; if the HTTP server permits
    (see 1), the link will be added to the end of the current
    document.  This would be the only form of annotation allowed (no
    adding text to an existing document, etc.)

(3) Annotation location in the web: The presumption is that the user
    adding the annotation can place the annotation (as a document) on
    her local machine and make it accessible via http (or, I suppose,
    ftp).

Benefits:

(a) Fairly easy to implement and fairly seamless to integrate into
    existing structure.
(b) Lightweight in terms of additions to existing documents; since
    only a link can be added, security and document integrity is
    preserved for everyone involved.

Drawbacks:

(a) Anyone who wishes to annotate a document must be running HTTP or
    have some other way of making his annotation available as a
    document from his machine to the web -- possibly too much grunge
    work for real ``users'' as opposed to hackers.

But it would be a start....

Marc


From marca@wintermute.ncsa.uiuc.edu  Thu Nov 19 20:45:16 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16783; Thu, 19 Nov 92 20:45:16 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21652; Thu, 19 Nov 92 20:57:50 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09475
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 19 Nov 92 13:53:26 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:rik@daneel.rdt.monash.edu.au id AA10782; Thu, 19 Nov 92 13:54:21 -0800
Date: Thu, 19 Nov 92 13:54:21 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211192154.AA10782@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: rik@daneel.rdt.monash.edu.au
Subject: [rik@daneel.rdt.monash.edu.au: Re: hangs/multiple servers ]
In-Reply-To: <9211192142.AA10729@wintermute.ncsa.uiuc.edu>
References: <9211192142.AA10729@wintermute.ncsa.uiuc.edu>

> One possible way to implement backups is to have the client do it
> (makes the client too clever?).  The client could have a list of
> hosts, and for each one, have a list of backup servers, to try if
> the main server is down.  The problem with this is that the list is
> much more difficult to maintain, if everyone needs a copy, and only
> the clients that have implemented this would benefit.

I think this is a good idea -- the really important capability it
enables is this: if I (I == ``real user using WWW mechanisms for real
work'') set up an HTTP server that people at my site will need to get
to at all times, then with this mechanism I could *at the very least*
tell my WWW clients about alternate servers that I also set up.

A big advantage is that nothing major (i.e., HTTP or HTML) would have
to be changed.

As for the problems: (1) it is true that to be useful in the general
sense a master list would have to be maintained, but each local site
would only have to pull down a new one every few months -- these
things aren't going to change that often (expansion is more likely),
and (2) is a problem with any change of anything at this point, which
is why I think a very lightweight change (like this) would be best.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From connolly@pixel.convex.com  Thu Nov 19 22:24:03 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17427; Thu, 19 Nov 92 22:24:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24297; Thu, 19 Nov 92 22:36:36 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA29321; Thu, 19 Nov 92 15:36:19 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA09136; Thu, 19 Nov 92 15:36:17 -0600
Message-Id: <9211192136.AA09136@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Freezing the HTML spec Re: Comments in HTML ? 
In-Reply-To: Your message of "Thu, 19 Nov 92 13:30:11 PST."
             <9211192130.AA10669@wintermute.ncsa.uiuc.edu> 
Date: Thu, 19 Nov 92 15:36:16 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Dan Connolly writes:
>> Hmmm... we definitely need a CSCW strategy for group-editing of
>> documents.
>
>I'm pulling this outta my rear end, but how about:
>
>(a) Anyone who wishes to annotate a document must be running HTTP or
>    have some other way of making his annotation available as a
>    document from his machine to the web -- possibly too much grunge
>    work for real ``users'' as opposed to hackers.

Ding! The light goes on: Let's use USENET news! Scenario:

1. I'm reading http://info.cern.ch/hypertext/WWW/MarkUp.html.

2. I see something I want to change, so I save the HTML to
a file.

3. I edit the file, trimming it down and adding my comments.

4. I enclose the file in a news article using the MIME text/x-html
content type and the quoted-printable content transfer encoding.

5. I post the article to comp.infosystems or alt.infosystems.www.

6. I make a URL out of the message-id of the article, and I
send
LINK /hypertext/WWW/MarkUp.html
<A HREF="news:<message-id>">Comments by connolly@convex.com</a>
.

to the HTTP server at info.cern.ch.

7. We add MIME style message/rfc-822 parsing to the browser. See below.

8. I'm browsing the annotated http://info.cern.ch/hypertext/WWW/MarkUp.html
and I click on "Comments by connolly@convex.com". The browser contacts
its NNTP server and grabs message-id.

9. It extracts the body, and displays the result as HTML.


Ding! Another light goes on. Here's how to handle MIME body parts:

We need a function:

void
HText_AppendBodyPart(HText* target, int (*getch)(void*), void* stream,
	int type, int subtype, char* params);
/*
 * PRE:
 * target -- hypertext object "in append mode"
 * getch -- get one character from stream object
 * stream -- opaque stream object
 * type -- one of the 7 mime primary types: MIME_TEXT, MIME_MESSAGE, etc.
 * subtype -- plain, html, postscript, gif, basic, multipart, etc.
 * params -- "name=val; name=val;..." parameters
 *
 * POST:
 * body part on stream has been consumed and appended to or linked
 * to target.
 */

text/html -- append as SGML text entity
text/* -- append as plain text
	to the SGML parser, it's an external entity text/plain NOTATION
multipart/* -- find boundary on stream
	create a new stream object out of getch, stream,
	and params that returns eof at the boundary
	call HText_AppendBodyPart recursively
message/rfc-822 -- parse headers, display headers as
	 <DL><DT>Subject<DD>foo...</DL>
	append body part recursively
message/external-body -- create a URL out of params. Parse
	message headers. Display as
	<H2><A href="URL" type="type/subtype params">description</a><H2>
*/* -- save to local file foo. display as
	<H2><a HREF="file:foo" TYPE="type/subtype params">description</a></H2>
	where description is the content-description, if available, or
	"a body part of type image/gif" otherwise.

Then we can add a separate command that takes a link, opens it, and
pipes it through metamail.

Hmmm... I gotta go code this up!

Dan


From marca@wintermute.ncsa.uiuc.edu  Thu Nov 19 22:40:03 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17603; Thu, 19 Nov 92 22:40:03 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24645; Thu, 19 Nov 92 22:52:35 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA25390
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 19 Nov 92 15:51:57 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11287; Thu, 19 Nov 92 15:53:01 -0800
Date: Thu, 19 Nov 92 15:53:01 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211192353.AA11287@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), www-talk@nxoc01.cern.ch
Subject: Re: Freezing the HTML spec Re: Comments in HTML ? 
In-Reply-To: <9211192136.AA09136@pixel.convex.com>
References: <9211192130.AA10669@wintermute.ncsa.uiuc.edu>
	<9211192136.AA09136@pixel.convex.com>

Dan Connolly writes:
> 8. I'm browsing the annotated http://info.cern.ch/hypertext/WWW/MarkUp.html
> and I click on "Comments by connolly@convex.com". The browser contacts
> its NNTP server and grabs message-id.

But NNTP servers expire articles too quickly.

(Also, I just mutated metamail to handle x-html, like this:

in mailcap:

text/x-html; /usr/bin/X11/xterm -fn "*lucidatypewriter*medium*-14-*" -e /usr/local/bin/dowwwfile %s

in /usr/local/bin/dowwwfile:

#!/bin/sh
PATH=$PATH:/usr/local/bin
export PATH
cp $1 $1.html
WWW_HOME="file:$1.html"
export WWW_HOME
/usr/local/bin/www

It's a hack, but it's functional...)

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From K.Hoadley@directory.rl.ac.uk  Fri Nov 20 11:03:36 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00559; Fri, 20 Nov 92 11:03:36 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23066; Fri, 20 Nov 92 11:16:18 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <02476-0@directory.rl.ac.uk>; Fri, 20 Nov 1992 10:05:26 +0000
Date: Fri, 20 Nov 1992 09:55:41 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: Re: hangs/multiple servers
To: timbl@ch.cern.ch
Cc: K.Hoadley%UK.ac.RL.DIRECTORY@ac.uk, www-talk@ch.cern.ch
In-Reply-To: Tim Berners-Lee's message of Thu, 19 Nov 92 18:29:03 +0100: <9211191729.AA00355@www3.cern.ch>
Message-Id: <Ximap.722254606.1308.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

From: Tim Berners-Lee
> 
>Ok, This seems a bery good idea, if that is the functionality which DNS
>supports.
><practical>
>Let's try it.... Anyone care to mod HTTP.c? It's not obvious from
>the gethostbyname that one is allowed to refer to different
>machines:
>          struct    hostent {
>               char *h_name;  /* official name of host */
>               char **h_aliases;   /* alias list */
>               int  h_addrtype;    /* host address type */
>               int  h_length; /* length of address */
>               char **h_addr_list; /* list of addresses from name server */
>          };
> 
>That look like a list of aliases for one machine, rather than a
>list of machines for one alias! But maybe the reverse will work.

It is both; a list of alias names for a host, and a list of addresses
that correspond to the canonical name ...

>So all machines support char **h_addr_list rather than the older
>h_addr?   We can probably differentiate using #ifdef h_addr

Probably not, unfortunately

>which is set to a macro if there IS a list.  I assume you need then
>separate entries for the virtual duplicate node and the actual
>real nodes, so that you can speak to them sepately. Is this normal
>and OK?
Yes, you need seperate entires for the pseudo host and the real hosts
that are actually providing the service. This looks like the following:

www-server.foobar.domain.           A        1.2.3.4
                                    A        1.2.5.6
                                    A        1.2.7.8
aeschylus.foobar.domain.            A        1.2.3.4
euripides.foobar.domain.            A        1.2.5.6
sophocles.foobar.domain.            A        1.2.7.8

ie. the virtual hosts www-server appears to be multi-homed, but each
"home" is on a different real machine.

>Is this normal and OK

Well, it's technically acceptable, but it is hardly a normal requirement
in the first place.

There is one possible gotcha here: some machines verify DNS lookups
by checking the forward lookup against the reverse. In this case such
a check would fail, as the reverse is likely return either aeschylus,
euripides or sophocles (this depends on what you put in the relevant
in-addr.arpa domain, whcih is how reverse lookups work). I hope that
this checking is done by apps calling gethostbyaddr after each
gethostbyname, rather than being being built in gethostbyname

Adding support for multiple addresses into the clients is useful
anyway... if only to support real multihomed machines

Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk


From W.vanLeeuwen@nikhef.nl  Fri Nov 20 11:18:32 1992
Return-Path: <W.vanLeeuwen@nikhef.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00735; Fri, 20 Nov 92 11:18:32 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24662; Fri, 20 Nov 92 11:31:12 +0100
Received: by nikhefh.nikhef.nl; Fri, 20 Nov 92 11:30:56 +0100
Message-Id: <9211201030.AA00859@nikhefh.nikhef.nl>
Date: Fri, 20 Nov 92 11:30:56 +0100
From: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)
Organisation: Nikhef-H (National Institute for Nuclear and High-Energy Physics)
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 5925013, +31 2995 2499 (home)
Telex: 10262 hef nl
Telefax: +31 20 5925155
To: www-talk@nxoc01.cern.ch
Subject: Hostname of www server
Cc: a03@nikhef.nl

It is becoming common practice to create aliases for hostnames which
reflect the service they provide.

Examples:
ftp	anonymous ftp server
news	news server

See the output of the host command:

[nikhefh] ##[1] host ftp
ftp.nikhef.nl       	CNAME	nikhefh.nikhef.nl
nikhefh.nikhef.nl   	A	192.16.199.1
[nikhefh] ##[2] host news
news.nikhef.nl      	CNAME	nikhefh.nikhef.nl
nikhefh.nikhef.nl   	A	192.16.199.1
[nikhefh] ##[3] host www
www.nikhef.nl       	CNAME	nic.nikhef.nl
nic.nikhef.nl       	A	192.16.199.49
[nikhefh] ##[4] host news.cern.ch
news.cern.ch        	CNAME	dxcern.cern.ch
dxcern.cern.ch      	A	128.141.201.96
[nikhefh] ##[5] host news.desy.de
news.desy.de        	CNAME	dscomsa.desy.de
dscomsa.desy.de     	A	131.169.1.165

We propose to use the alias www.organisation.country for machines running
the www server.
This makes the replacement of machines invisible for the users.

Best regards,

Willem van Leeuwen

From timbl@www3.cern.ch  Fri Nov 20 12:05:45 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00944; Fri, 20 Nov 92 12:05:45 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28870; Fri, 20 Nov 92 12:18:27 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00258; Fri, 20 Nov 92 12:13:59 +0100
Date: Fri, 20 Nov 92 12:13:59 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211201113.AA00258@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: Freezing the HTML spec Re: Comments in HTML ? 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Dan, I agree with all your points. I have a few comments below.

> Date: Thu, 19 Nov 92 12:49:51 CST
> From: Dan Connolly <connolly@pixel.convex.com>
> 

...
> 	* Use the LineMode browser as a reference implementation.
> 	Try not to include features that www doesn't grok.

If there is a bug in the current W3 library, then we can fix that,
rather than work our way around tortuously. Like the problem
with elements not being allowed within anchors -- that had just never
been tested and happened to have a bug.
 


> 3. Revise the spec so that it's internally consistent. Right
> now, there are some glitches. And the current method of
> sending suggestions to Tim and hoping he finds time to make
> the edits is no good. Hmmm... we definitely need a CSCW
> strategy for group-editing of documents.

Don't we just!
If you can serve up a current version, then could you be editor?

> 4. Register the spec with the IANA or IETF or whatever.
> 

> Meanwhile, I think it's pretty important to fix the NeXT editor
> and all the files on info.cern.ch. Folks are using that as a
> reference, and perpetuating HTML that conflicts with the SGML
> standard.

Fixing the NeXTStep editor is the problem.
 > 

> SGML is a mess!
>

I agree. It is a political decsion to use it.  We should try to avoid
using weird constructs, though, so that HTML is as clean as possible
notwithstanding the SGML mess.
 

> >> Does any of the existing WWW code support comments ?
> >
> >As it happens, the current library supports them, so the line mdoe
> >browser and anything else based on the library does. But it has
> >been left out of the doc and so will probably me missing from other browers.
> >
> 

> Try the <? foo > construct.

The SGML systems at CERN use <? > for low-level commands, which I think
is what they were intended for, like embedded TeX or script commands.
Puttimng arbitrary comments in as processor instructions might cause
unpredicatble effects.  <comment>...</comment> is an easy thing to define,
use, doesn't use any features which some parsers don't have, and
is also rather self-explanarory.

> Dan
> 

> 

	Tim


From timbl@www3.cern.ch  Fri Nov 20 12:18:50 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00989; Fri, 20 Nov 92 12:18:50 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00495; Fri, 20 Nov 92 12:31:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00271; Fri, 20 Nov 92 12:26:47 +0100
Date: Fri, 20 Nov 92 12:26:47 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211201126.AA00271@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Annotation 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> 

> From: marca@ncsa.uiuc.edu (Marc Andreessen)
> 

(Annotation mechanism described)

> Drawbacks:
> 

> (a) Anyone who wishes to annotate a document must be running HTTP or
>     have some other way of making his annotation available as a
>     document from his machine to the web -- possibly too much grunge
>     work for real ``users'' as opposed to hackers.
> 


"Real users" are going to have to be able to publish easily anyway.
That means that future clients must have push-buttons for publishing.
The client will check whether there is a httpd running which gives
access to the document the guy has written. It it has, it allows
him to annotate other things with it. It also makes the background
a different colour depending on how public it is, maybe. Give people a secure  
feeling they know what is public and what ain't.

As there are 1001 ways of configuing a server now, this will mean that
we will have to define a way in which we recommend it is done by all but
the hacker group.  For example, we allow any user to create a ~/Public
directory (sorry, "folder") and copy or link in anything to be published.
The document name would be mapped from //machine/author/xxx to
~author/Public/xxx for example.

The client would check whether there was an httpd running which gave
access to the document, and if not would offer to run a simple
installation script if the guy has root access.  The httpd daemon code
would come bundled with the client, as well as the configuration file.

A start would be a server installation script.

	Tim

From connolly@pixel.convex.com  Fri Nov 20 21:48:36 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04035; Fri, 20 Nov 92 21:48:36 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA11241; Fri, 20 Nov 92 22:01:18 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA14497; Fri, 20 Nov 92 15:00:58 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA02019; Fri, 20 Nov 92 15:00:53 -0600
Message-Id: <9211202100.AA02019@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: K.Hoadley@directory.rl.ac.uk, www-talk@nxoc01.cern.ch
Subject: Re: Comments in HTML ? 
In-Reply-To: Your message of "Thu, 19 Nov 92 18:27:46 +0100."
             <9211191727.AA00350@www3.cern.ch> 
Date: Fri, 20 Nov 92 15:00:52 CST
From: Dan Connolly <connolly@pixel.convex.com>


I was wrong: <!-- comment foo --> _is_ recognized in the
instance, or so the standard and sgmls say.

I'm trying to put together a lex style specification of
the lexical elements of HTML. It will almost certainly
conflict with current usage.

But I think the reason current usage is broken is that
the SGML standard is so obtuse.

I believe if I write up a lex specification of exactly
what characters mean what and when, and it's only a
couple pages of lex code, the folks will implement
it faithfully.

As is is now, everybody just writes their own ad-hoc
finite state machine. That's too error prone.

Dan


From marca@wintermute.ncsa.uiuc.edu  Sat Nov 21 03:21:50 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05428; Sat, 21 Nov 92 03:21:50 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA14191; Sat, 21 Nov 92 03:34:37 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26940
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 20 Nov 92 20:34:22 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14749; Fri, 20 Nov 92 20:35:33 -0800
Date: Fri, 20 Nov 92 20:35:33 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211210435.AA14749@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: html-mode.el update 
In-Reply-To: <9211190454.AA08886@pixel.convex.com>
References: <9211190454.AA08886@pixel.convex.com>
	<9211190542.AA09366@wintermute.ncsa.uiuc.edu>

Dan Connolly writes:
> Here's a patch to add a function to fix all the existing HREFs in an
> HTML file so they'll have quotes around them. [...]

Quotes around HREF filenames break Midaswww at the moment.  Tony, is
it possible to fix that really quickly?  (Assuming there's a consensus
that HREF's should be quoted; the existing HTML I've seen doesn't do
this...)

This is important for other reasons too, which will be more obvious
with my next message :-).

Marc


From connolly@pixel.convex.com  Sat Nov 21 03:30:16 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05483; Sat, 21 Nov 92 03:30:16 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA16108; Sat, 21 Nov 92 03:42:59 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA25438; Fri, 20 Nov 92 20:42:41 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA12291; Fri, 20 Nov 92 20:42:40 -0600
Message-Id: <9211210242.AA12291@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: html-mode.el update 
In-Reply-To: Your message of "Fri, 20 Nov 92 20:35:33 PST."
             <9211210435.AA14749@wintermute.ncsa.uiuc.edu> 
Date: Fri, 20 Nov 92 20:42:40 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Quotes around HREF filenames break Midaswww at the moment.  Tony, is
>it possible to fix that really quickly?

The Midaswww SGML parser is pretty far off the beaten path. It shouldn't
be hard to fix (maybe I'll do it this weekend).

>  (Assuming there's a consensus
>that HREF's should be quoted; the existing HTML I've seen doesn't do
>this...)

That doesn't make it right! I'm trying to stamp out all this noisy
HTML, but I'm not having much luck.

The SGML standard is pretty clear on this stuff. I think we should
go with it.

Dan


From marca@wintermute.ncsa.uiuc.edu  Sat Nov 21 03:47:18 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05520; Sat, 21 Nov 92 03:47:18 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA19436; Sat, 21 Nov 92 04:00:01 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA27904
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 20 Nov 92 20:59:43 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14826; Fri, 20 Nov 92 21:00:54 -0800
Date: Fri, 20 Nov 92 21:00:54 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211210500.AA14826@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Annotation & asynch collaboration

I've patched httpd to allow remote annotations (an enabling mechanism
for asynchronous collaboration).  My httpd accepts the following
command:

ANNOTATE /file/to/annotate?/file/of/annotation?Text describing annotation.

The result of this command is that /file/to/annotate gets a single line
appended to it; this line is exactly:

<A HREF=/file/of/annotation>Text describing annotation.</A> <P>\n

Notice:

(1) '?' is used as the divider between ``keywords'', as it is with GET
    (for searches).  I'm content with overloading '?' (since it's
    already known to be safe, since it's not supposed to be part of a
    document ID), but other people might not be.  (If not '?', what?)
(2) /file/of/annotation can be any file with any access type, but is
    normally assumed to be a file residing on the annotator's local
    system and under her control.
(3) The new link can be arbitrarily named; it may be a good idea to
    have clients that implement annotation automatically prepend the
    annotator's full name to this field before sending it to httpd,
    but httpd shouldn't have to worry about this.

The security mechanism for this is as follows:

(1) A file to be annotated must ``pass'' the rules normally, and also:
(2) A new rule ``open'' is defined; it serves the same role (and has
    the same syntax) as ``pass'' except it determines whether a file
    can be annotated; and also:
(3) Since httpd is (or should be) normally run as 'nobody', the file
    must be writeable by 'nobody'.

This implementation does not cover informing the client whether or not
a file is ``open'' until an annotation is attempted.  That capability
should probably be addressed separately (??).

I'm sending the httpd patches to Tim tonight; unless there are
problems[1] with this approach, I'd love to see it implemented, and
I'll even set up the first annotatable web site...

Marc

[1] Dan will immediately notice that quotes aren't put around the HREF
field above.  At the moment, I'm going to run without them (since, for
one thing, I need to demo this with Midaswww on Monday), but the
official implementation should do the quotes.


From connolly@pixel.convex.com  Sat Nov 21 03:57:33 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05547; Sat, 21 Nov 92 03:57:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA21282; Sat, 21 Nov 92 04:10:18 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA25744; Fri, 20 Nov 92 21:10:01 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA13411; Fri, 20 Nov 92 21:09:59 -0600
Message-Id: <9211210309.AA13411@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Annotation & asynch collaboration 
In-Reply-To: Your message of "Fri, 20 Nov 92 21:00:54 PST."
             <9211210500.AA14826@wintermute.ncsa.uiuc.edu> 
Date: Fri, 20 Nov 92 21:09:59 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I've patched httpd to allow remote annotations (an enabling mechanism
>for asynchronous collaboration).  My httpd accepts the following
>command:
>
>ANNOTATE /file/to/annotate?/file/of/annotation?Text describing annotation.

I'd suggest

APPEND /file/to/annotate
<a HREF="file/of/annotation">Text describing annotation</a>
.

The server could impose limits on the length of the annotation,
and it should somehow validate the syntax, I suppose.

Dan

From marca@wintermute.ncsa.uiuc.edu  Sat Nov 21 04:04:57 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05567; Sat, 21 Nov 92 04:04:57 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA22777; Sat, 21 Nov 92 04:17:42 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28422
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 20 Nov 92 21:17:25 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14876; Fri, 20 Nov 92 21:18:36 -0800
Date: Fri, 20 Nov 92 21:18:36 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211210518.AA14876@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), www-talk@nxoc01.cern.ch
Subject: Re: Annotation & asynch collaboration 
In-Reply-To: <9211210309.AA13411@pixel.convex.com>
References: <9211210309.AA13411@pixel.convex.com>
	<9211210500.AA14826@wintermute.ncsa.uiuc.edu>

Dan Connolly writes:
> >ANNOTATE /file/to/annotate?/file/of/annotation?Text describing annotation.
> 
> I'd suggest
> 
> APPEND /file/to/annotate
> <a HREF="file/of/annotation">Text describing annotation</a>
> .
> 
> The server could impose limits on the length of the annotation,
> and it should somehow validate the syntax, I suppose.

The point behind *not* doing general appends is that they aren't a
good idea since document integrity is breached (a link is immediately
obvious as just that and will cause little confusion [especially if
clients always prepend a fullname], but if arbitrary text can be added
to a document, you'll never know what's going on).  To be practical, I
know *I'm* not going to run an httpd server that allows anyone to
append any text they want to my documents.

And if general appends aren't going to be allowed (through server
validation of the <A...> syntax or whatever), then why not just let
the server construct the link append itself?

Marc


From connolly@pixel.convex.com  Sat Nov 21 04:11:37 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05603; Sat, 21 Nov 92 04:11:37 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24130; Sat, 21 Nov 92 04:24:23 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA26412; Fri, 20 Nov 92 21:24:04 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA13547; Fri, 20 Nov 92 21:24:03 -0600
Message-Id: <9211210324.AA13547@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Annotation & asynch collaboration 
In-Reply-To: Your message of "Fri, 20 Nov 92 21:18:36 PST."
             <9211210518.AA14876@wintermute.ncsa.uiuc.edu> 
Date: Fri, 20 Nov 92 21:24:02 CST
From: Dan Connolly <connolly@pixel.convex.com>


>(a link is immediately
>obvious as just that and will cause little confusion [especially if
>clients always prepend a fullname], but if arbitrary text can be added
>to a document, you'll never know what's going on).

I get it... It's just a way of saying "Mr. Fred has something to
say in response to this. Click here to see what."

It doesn't allow Mr. Fred to actually say anything right there.

You're right. Besides: I think we'd need more structure in our
markup to do arbirary annotations. For example, it would be nice
to be able to do:

<longquote FROM="http://somewhere/something">
<h3>blah blah</h3>
<dl>....</dl>
</longquote>

Dan


From marca@wintermute.ncsa.uiuc.edu  Sat Nov 21 04:16:22 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05620; Sat, 21 Nov 92 04:16:22 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24833; Sat, 21 Nov 92 04:29:06 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28749
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 20 Nov 92 21:28:49 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14941; Fri, 20 Nov 92 21:30:00 -0800
Date: Fri, 20 Nov 92 21:30:00 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211210530.AA14941@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), www-talk@nxoc01.cern.ch
Subject: Re: Annotation & asynch collaboration 
In-Reply-To: <9211210324.AA13547@pixel.convex.com>
References: <9211210324.AA13547@pixel.convex.com>
	<9211210518.AA14876@wintermute.ncsa.uiuc.edu>

Dan Connolly writes:
> Besides: I think we'd need more structure in our markup to do
> arbirary annotations. For example, it would be nice to be able to
> do:
> 
> <longquote FROM="http://somewhere/something">
> <h3>blah blah</h3>
> <dl>....</dl>
> </longquote>

You're right....... it would be nice.  Maybe as a specialized solution
on isolated systems (or maybe the httpd authentication system should
be expanded to break down by domain or machine).  Hmmmm...

Marc


From connolly@pixel.convex.com  Sat Nov 21 06:03:10 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05950; Sat, 21 Nov 92 06:03:10 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA17366; Sat, 21 Nov 92 06:15:53 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA00842; Fri, 20 Nov 92 23:14:38 -0600
Received: by pixel.convex.com (5.64/1.28)
	id AA15421; Fri, 20 Nov 92 23:14:35 -0600
Date: Fri, 20 Nov 92 23:14:35 -0600
From: connolly@pixel.convex.com (Dan Connolly)
Message-Id: <9211210514.AA15421@pixel.convex.com>
Mime-Version: 1.0
To: www-talk@nxoc01.cern.ch
Subject: HTML spec part 1
Cc: connolly@pixel.convex.com
Content-Type: multipart/mixed;
	boundary="PART.BOUNDARY.25512.15400.pixel.722322875.1"

> THIS IS A MESSAGE IN 'MIME' FORMAT.  Your mail reader does not support MIME.
> Some parts of this will be readable as plain text.
> To see the rest, you will need to upgrade your mail reader.

--PART.BOUNDARY.25512.15400.pixel.722322875.1
Content-type: text/plain
Content-Transfer-Encoding: quoted-printable

<TITLE>HyperText Mark-up Language</TITLE>
<H1>Text and Markup</H1>
This is an explanation of SGML syntax as it applies to HTML. It is design=
ed to take section 7, "Element Structure" and reduce it fromthe abstract =
system that is SGML to a concrete languag, HTML.<P>
<H2><A NAME=3D"Tags">Tags</A>
</H2>
The characters in an SGML document are organized into a heirarchy of elem=
ents by the use of tags. An HTML tag has the form<P>
<DL><DT>start tag<DD>"&lt;" name s+ attribute* s* ">"<DT>end tag<DD>"&lt;=
/" name s* ">"<DT>name<DD>letter (letter | digit){0,7}<DT>For example,</D=
L>
<XMP><Title>Here's the title of the Document</title></XMP>
<XMP><h1 >A Heading</h1></XMP>
<XMP><a NAME=3Dfoo>This text is the content of an A element.</a></XMP>
<XMP><A HREF=3D"http://info.cern.ch/hypertext/WWW/TheProject.html"></XMP>=

<XMP>This text is a link to the WWW documentation. </a></XMP>
Element names are not case sensitive. They are restricted to eight charac=
ters or less.<P>
<H4>Open Issue: Length of Names</H4>
If we use the default SGML declaration, names are restricted to eight cha=
racters. Some SGML parsers don't support other SGML declarations.<P>
But most do, these days most SGML applications use a declaration with a l=
arger value of NAMELEN.<P>
The length of an attribute value literal is similarly limited to 240 char=
acters. This might be a problem with long URLs. I think we should change =
it.<P>
<H2>Attributes</H2>
Some elements have associated attributes. The start tag specifies the val=
ues of the attributes for an element.<P>
<DL><DT>attribute<DD>name s* "=3D" s* (token|literal)<DT>token<DD>(letter=
|digit){1,8}<DT>letter<DD>[a-zA-Z]<DT>digit<DD>[0-9]<DT>literal<DD>'"' [^=
"]{0,240} '"' | "'" [^']{0,240} "'"</DL>
Each attribute of each element has a declared type. <P>
<H4>Open Issue: Anchor Names: NMTOKEN or ID?</H4>
The names of anchors within an HTML document should be unique. We can use=
 the SGML ID mechanism to specify this.<P>
But SGML IDs are names; that is, they start with a letter. Many HTML prod=
ucers use numbers for anchor names.<P>
<H4>Open Issue: Interpretation of Literals</H4>
Section 7.9.3 of the SGML standard states<P>
<UL><LI>An attribute value literal is interpreted as an attribute value b=
y replacing references within it, ignoring Ee and RS, and replacing RE or=
 SEPCHAR with SPACE.</UL>
For the SGML-impared, Ee is Entity End (like EOF); RS is '\n'; RE is '\r'=
; SEPCHAR is '\t' and SPACE is ' '.<P>
Since to date there are no HTML attributes containing newlines or spaces,=
 that is not much of an issue.<P>
But replacement of literals is. For one thing, this creates an interactio=
n between the syntax of URLs and SGML syntax. We could resolve this issue=
 by removing '&amp;' from <A HREF=3D"http://info.cern.ch/hypertext/WWW/Ad=
dressing/BNF.html#xalpha">the URL syntax</A>
=2E<P>
<H4>Historical Note</H4>
The NeXT implementation of the WWW browser, responsible for the creation =
of much of the existing HTML, does not surround attribute literals with q=
uotes. These productions describe the syntax produced by the NeXT:<P>
<DL><DT>NXattribute<DD>name "=3D" NXliteral<DT>NXliteral<DD> [^ >]+</DL>
<H2>Normal Text: #PCDATA</H2>
The symbol #PCDATA stands for parsed character data, the normal text char=
acters in an SGML document.<P>
The text consists of a stream of lines.The division into lines has no sig=
nificance apart from indicating a word end.<P>
The following character sequences are recognized as markup in #PCDATA:<P>=

<DL><DT>&lt;[a-zA-Z]<DD>"&lt;" serves as the Start Tag Open delimiter whe=
n followed by a letter. It is used to introduct <A HREF=3D"#Tags">tags</A=
>
 that start elements.<DT>&lt;/[a-zA-Z]<DD>"&lt;/" serves as the End Tag O=
pen delimiter when followed by a letter. It is used to introduce tags tha=
t terminate elements.<DT>&lt;!(--)([A-Za-z])([)<DD>"&lt;!" serves as the =
Markup Declaration Open delimiter when followed by a letter or "--" or "[=
". It has several uses in SGML. The only purpose it serves in HTML is to =
introduce comments.<DT>&amp;[a-zA-z]<DD>"&amp;" serves as the Entity Refe=
rence Open delimiterwhen followed by a letter. It is used to introduce en=
tities, or "macros." <DT>&amp;#[0-9A-Za-z]<DD>"&amp;#" followed by a lett=
er or a digit is the Character Reference Open delimiter. SGML idioms incl=
ude things like "&amp;#168;" and "&amp;#SPACE;". It is not used in HTML.<=
DT>]]><DD>"]]" when followed by ">" is Marked Section Close. While marked=
 sections are not used by SGML, this sequence of characters is recognized=
 and reported as an error by conforming SGML parsers.</DL>
<H4>Note to HTML Producers</H4>
Note that conforming SGML parsers will treat "&amp;", "&lt;", "&lt;/", an=
d "&lt;!" as normal text characters when they are not followed by a lette=
r. HTML producers are discouraged from taking advantage of this feature.<=
P>
All occurrences of the characters '&amp;' and '&lt;' should be represente=
d by <A HREF=3D"#Entities">entities</A>
=2E The marked section close delimiter can be avoided if all occurrences =
of '>' are represented by entities.<P>
 While the division of the stream of characters into lines is arbitrary, =
the recommended line length is 72 characters in order to allow the text t=
o be passed through systems which can only handle text with a limited lin=
e length.<P>
<H2>Literal Text: #RCDATA</H2>
The symbol #RCDATA stands for replaceable character data, the text withou=
t tags in an SGML document. It is used in HTML for sections where line br=
eaks and character widths are significant.<P>
Only the entity reference and end tag open delimiters are recognized in #=
RCDATA.<P>
Replaceable character data should be displayed in a fixed width font, so =
that any formatting done by character spacing on successive lines will be=
 maintained.<P>
The ASCII Horizontal Tab (HT) character should be interpreted as the smal=
lest positive nonzero number of spaces which will leave the number of cha=
racters so far on the line as a multiple of 8. Its use is not recommended=
 however.<P>
<H4>Historical Note</H4>
The original definition of literal text is not representable in SGML. Fro=
m <A HREF=3D"http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html">Tags use=
d in HTML</A>
:<P>
<UL><LI>The text may contain any ISO Latin printable characters, includin=
g the tag opener, so long as it does not contain the closing tag in full.=
 </UL>
But in section 7.6 of the SGML standard:<P>
<UL><LI>The content of an element declared to be character data or replac=
eable character data is terminated only by an etago delimiter-in-context =
(which need not open a valid end-tag) ... .</UL>
This definition is a compromise: it allows most markup to be ignored, but=
 where the string "&lt;/" is needed, it can be represented as "&amp;lt;/"=
=2E We will probaly end up with some systems that display "&amp;lt;/" rat=
her than "&lt;/".<P>
<H2><A NAME=3D"Entities">Entities</A>
</H2>
In order to include characters that would otherwise be treated as markup,=
 SGML entity references refer to arbitrary sequences of characters. An HT=
ML entity reference has the form:<P>
<DL><DT>entity reference<DD>"&amp;" name ";"<DT>Entity names are case sen=
sitive.</DL>
<H4>Open Issue: Character Set</H4>
The default SGML declaration specifies ISO 646-1983 as the character set.=
 I believe it's straight forward to specify ISO Latin 1 in the SGML decla=
ration for HTML, but it's not clear that this is a good idea.<P>
The SGML standard includes a set of entities for ISO Latin 1 characters a=
s public text. For example, &amp;OElig is the OE ligature. If we include =
these entities in the HTML DTD, we could support Latin 1 characters while=
 maintaining a 7 bit language. This would require a table of the entity n=
ames in WWW clients.<P>


--PART.BOUNDARY.25512.15400.pixel.722322875.1
Content-type: text/plain

/*
Copyright (c) 1991 Bell Communications Research, Inc. (Bellcore)

Permission to use, copy, modify, and distribute this material 
for any purpose and without fee is hereby granted, provided 
that the above copyright notice and this permission notice 
appear in all copies, and that the name of Bellcore not be 
used in advertising or publicity pertaining to this 
material without the specific, prior written permission 
of an authorized representative of Bellcore.  BELLCORE 
MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY 
OF THIS MATERIAL FOR ANY PURPOSE.  IT IS PROVIDED "AS IS", 
WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
*/
#include <stdio.h>

#define BASE64 1
#define QP 2 /* quoted-printable */

main(argc, argv)
int argc;
char **argv;
{
    int encode = 1, which = BASE64, i;
    FILE *fp = stdin;

    for (i=1; i<argc; ++i) {
        if (argv[i][0] == '-') {
            switch (argv[i][1]) {
                case 'u':
                    encode = 0;
                    break;
                case 'q':
                    which = QP;
                    break;
                case 'b':
                    which = BASE64;
                    break;
		default:
                    fprintf(stderr,
                       "Usage: mmencode [-u] [-q] [-b] [file name]\n");
                    exit(-1);
            }
        } else {
            fp = fopen(argv[i], "r");
            if (!fp) {
                perror(argv[i]);
                exit(-1);
            }
        }
    }
    if (which == BASE64) {
        if (encode) to64(fp, stdout); else from64(fp, stdout, NULL, 0);
    } else {
        if (encode) toqp(fp, stdout); else fromqp(fp, stdout, NULL, 0);
    }
    return(0);
}


--PART.BOUNDARY.25512.15400.pixel.722322875.1
Content-type: text/plain

/*
Copyright (c) 1991 Bell Communications Research, Inc. (Bellcore)

Permission to use, copy, modify, and distribute this material 
for any purpose and without fee is hereby granted, provided 
that the above copyright notice and this permission notice 
appear in all copies, and that the name of Bellcore not be 
used in advertising or publicity pertaining to this 
material without the specific, prior written permission 
of an authorized representative of Bellcore.  BELLCORE 
MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY 
OF THIS MATERIAL FOR ANY PURPOSE.  IT IS PROVIDED "AS IS", 
WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
*/
#include <stdio.h>
#include <ctype.h>
#include <config.h>

extern char *index();
static char basis_64[] =
   "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";

static char index_64[128] = {
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,62, -1,-1,-1,63,
    52,53,54,55, 56,57,58,59, 60,61,-1,-1, -1,-1,-1,-1,
    -1, 0, 1, 2,  3, 4, 5, 6,  7, 8, 9,10, 11,12,13,14,
    15,16,17,18, 19,20,21,22, 23,24,25,-1, -1,-1,-1,-1,
    -1,26,27,28, 29,30,31,32, 33,34,35,36, 37,38,39,40,
    41,42,43,44, 45,46,47,48, 49,50,51,-1, -1,-1,-1,-1
};

#define char64(c)  (((c) < 0 || (c) > 127) ? -1 : index_64[(c)])

/*
char64(c)
char c;
{
    char *s = (char *) index(basis_64, c);
    if (s) return(s-basis_64);
    return(-1);
}
*/

to64(infile, outfile) 
FILE *infile, *outfile;
{
    int c1, c2, c3, ct=0;
    while ((c1 = getc(infile)) != EOF) {
        c2 = getc(infile);
        if (c2 == EOF) {
            output64chunk(c1, 0, 0, 2, outfile);
        } else {
            c3 = getc(infile);
            if (c3 == EOF) {
                output64chunk(c1, c2, 0, 1, outfile);
            } else {
                output64chunk(c1, c2, c3, 0, outfile);
            }
        }
        ct += 4;
        if (ct > 71) {
            putc('\n', outfile);
            ct = 0;
        }
    }
    if (ct) putc('\n', outfile);
    fflush(outfile);
}

output64chunk(c1, c2, c3, pads, outfile)
FILE *outfile;
{
    putc(basis_64[c1>>2], outfile);
    putc(basis_64[((c1 & 0x3)<< 4) | ((c2 & 0xF0) >> 4)], outfile);
    if (pads == 2) {
        putc('=', outfile);
        putc('=', outfile);
    } else if (pads) {
        putc(basis_64[((c2 & 0xF) << 2) | ((c3 & 0xC0) >>6)], outfile);
        putc('=', outfile);
    } else {
        putc(basis_64[((c2 & 0xF) << 2) | ((c3 & 0xC0) >>6)], outfile);
        putc(basis_64[c3 & 0x3F], outfile);
    }
}

PendingBoundary(s, Boundaries, BoundaryCt)
char *s;
char **Boundaries;
int *BoundaryCt;
{
    int i;

    for (i=0; i < *BoundaryCt; ++i) {
        if (!strncmp(s, Boundaries[i], strlen(Boundaries[i]))) {
            char Buf[2000];
            strcpy(Buf, Boundaries[i]);
            strcat(Buf, "--\n");
            if (!strcmp(Buf, s)) *BoundaryCt = i;
            return(1);
        }
    }
    return(0);
}

from64(infile, outfile, boundaries, boundaryct) 
FILE *infile, *outfile;
char **boundaries;
int *boundaryct;
{
    int c1, c2, c3, c4;
    int newline = 1, DataDone = 0;

    while ((c1 = getc(infile)) != EOF) {
        if (isspace(c1)) {
            if (c1 == '\n') {
                newline = 1;
            } else {
                newline = 0;
            }
            continue;
        }
        if (newline && boundaries && c1 == '-') {
            char Buf[200];
            /* a dash is NOT base 64, so all bets are off if NOT a boundary */
            ungetc(c1, infile);
            fgets(Buf, sizeof(Buf), infile);
            if (boundaries
                 && (Buf[0] == '-')
                 && (Buf[1] == '-')
                 && PendingBoundary(Buf, boundaries, boundaryct)) {
                return;
            }
            fprintf(stderr, "Ignoring unrecognized boundary line: %s\n", Buf);
            continue;
        }
        if (DataDone) continue;
        newline = 0;
        do {
            c2 = getc(infile);
        } while (c2 != EOF && isspace(c2));
        do {
            c3 = getc(infile);
        } while (c3 != EOF && isspace(c3));
        do {
            c4 = getc(infile);
        } while (c4 != EOF && isspace(c4));
        if (c2 == EOF || c3 == EOF || c4 == EOF) {
            fprintf(stderr, "Premature EOF!\n");
            return;
        }
        if (c1 == '=' || c2 == '=') {
            DataDone=1;
            continue;
        }
        c1 = char64(c1);
        c2 = char64(c2);
        putc(((c1<<2) | ((c2&0x30)>>4)), outfile);
        if (c3 == '=') {
            DataDone = 1;
        } else {
            c3 = char64(c3);
            putc((((c2&0XF) << 4) | ((c3&0x3C) >> 2)), outfile);
            if (c4 == '=') {
                DataDone = 1;
            } else {
                c4 = char64(c4);
                putc((((c3&0x03) <<6) | c4), outfile);
            }
        }
    }
}

static char basis_hex[] = "0123456789ABCDEF";
static char index_hex[128] = {
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
     0, 1, 2, 3,  4, 5, 6, 7,  8, 9,-1,-1, -1,-1,-1,-1,
    -1,10,11,12, 13,14,15,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,10,11,12, 13,14,15,-1, -1,-1,-1,-1, -1,-1,-1,-1,
    -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1
};

#define hexchar(c)  (((c) < 0 || (c) > 127) ? -1 : index_hex[(c)])

/*
hexchar(c)
char c;
{
    char *s;
    if (islower(c)) c = toupper(c);
    s = (char *) index(basis_hex, c);
    if (s) return(s-basis_hex);
    return(-1);
}
*/

toqp(infile, outfile) 
FILE *infile, *outfile;
{
    int c, ct=0, prevc=255;
    while ((c = getc(infile)) != EOF) {
        if ((c < 32 && (c != '\n' && c != '\t'))
             || (c == '=')
             || (c >= 127)
             /* Following line is to avoid single periods alone on lines,
               which messes up some dumb smtp implementations, sigh... */
             || (ct == 0 && c == '.')) {
            putc('=', outfile);
            putc(basis_hex[c>>4], outfile);
            putc(basis_hex[c&0xF], outfile);
            ct += 3;
            prevc = 'A'; /* close enough */
        } else if (c == '\n') {
            if (prevc == ' ' || prevc == '\t') {
                putc('=', outfile); /* soft & hard lines */
                putc(c, outfile);
            }
            putc(c, outfile);
            ct = 0;
            prevc = c;
        } else {
            putc(c, outfile);
            ++ct;
            prevc = c;
        }
        if (ct > 72) {
            putc('=', outfile);
            putc('\n', outfile);
            ct = 0;
            prevc = '\n';
        }
    }
    if (ct) {
        putc('=', outfile);
        putc('\n', outfile);
    }
}

fromqp(infile, outfile, boundaries, boundaryct) 
FILE *infile, *outfile;
char **boundaries;
int *boundaryct;
{
    int c1, c2, sawnewline = 1;

    while ((c1 = getc(infile)) != EOF) {
        if (sawnewline && boundaries && (c1 == '-')) {
            char Buf[200], *s;

            ungetc(c1, infile);
            fgets(Buf, sizeof(Buf), infile);
            if (boundaries
                 && (Buf[0] == '-')
                 && (Buf[1] == '-')
                 && PendingBoundary(Buf, boundaries, boundaryct)) {
                return;
            }
            /* Not a boundary, now we must treat THIS line as q-p, sigh */
            for (s=Buf; *s; ++s) {
                if (*s == '=') {
                    if (!*++s) break;
                    if (*s == '\n') {
                        /* ignore it */
                        sawnewline = 1;
                    } else {
                        c1 = hexchar(*s);
                        if (!*++s) break;
                        c2 = hexchar(*s);
                        putc(c1<<4 | c2, outfile);
                    }
                } else {
                    putc(*s, outfile);
                }
            }
        } else {
            sawnewline = (c1 == '\n') ? 1 : 0;
            if (c1 == '=') {
                c1 = getc(infile);
                if (c1 == '\n') {
                    /* ignore it */
                    sawnewline = 1;
                } else {
                    c2 = getc(infile);
                    c1 = hexchar(c1);
                    c2 = hexchar(c2);
                    putc(c1<<4 | c2, outfile);
                    if (c2 == '\n') sawnewline = 1;
                }
            } else {
                putc(c1, outfile);
            }
        }
    }
}

--PART.BOUNDARY.25512.15400.pixel.722322875.1--

From connolly@pixel.convex.com  Sat Nov 21 06:05:14 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05964; Sat, 21 Nov 92 06:05:14 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA17642; Sat, 21 Nov 92 06:17:56 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA00995; Fri, 20 Nov 92 23:17:38 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA15508; Fri, 20 Nov 92 23:17:37 -0600
Message-Id: <9211210517.AA15508@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: about HTML spec part 1
Date: Fri, 20 Nov 92 23:17:36 CST
From: Dan Connolly <connolly@pixel.convex.com>

In case you're at a loss to read it... take a look toward the end.
I included the source for mmencode, which can be used to decode
the first part.

Dan

From jim@wilbur.njit.edu  Sat Nov 21 23:21:34 1992
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08913; Sat, 21 Nov 92 23:21:34 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24987; Sat, 21 Nov 92 23:34:17 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA16031; Sat, 21 Nov 92 17:33:39 -0500
Message-Id: <9211212233.AA16031@njitgw.njit.edu>
Received: by wilbur.njit.edu; Sat, 21 Nov 92 17:32:08 est
Date: Sat, 21 Nov 92 17:32:08 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: www-talk@nxoc01.cern.ch
Subject: ScreenMode binaries, man page reader, experimental server

The ScreenMode w3 interface is available via anonymous ftp from 
wilbur.njit.edu in dist/w3.  The Sun and Dec versions are a bit out
of date, so plan to get a new one soon,  only the HP version is up
to date.  This is still a prerelease version.

We have an experimental server for our CWIS plus a special gateway
server.  The ScreenMode interface can still be access via telnet to
eies2.njit.edu with the login www.  You can try the manual page reader
their, or via http://eies2:1234/man.  We make extensive use of the <PRE>
tag for preformatted text.  Much of our hypertext, including the manual
pages, will not be formatted properly unless you use one of our readers,
or another reader modifies to support <PRE>.

The preformatted tag, PRE, unlike <PLAINTEXT>, allows anchors etc. to be 
inserted in text that is already formatted.  It greatly simplifies the
task of importing text from independant applications will anchors
everywhere you want them.  In addition, we have a set of macros for
MS-word which allow editing HTML in WYSIWYG fashion, but this also
requires support of the preformatted tag in HTML.

Al Leurck (al@eies2.njit.edu) developed the PRE tag and MS-word macros
here in the ScreenMode interface and we are adding it to the tkWWW X
interface.

We plan to impliment group hypertext using a mail server to suppliment
the HPPT access protocol.  Readers can contribute anchors to a text via
mail to www at the server machine.  Our browsers will support this
transparently.  Later we hope to participate in a broader effort to
include SGML tags to support forms, for truely interactive hypertext.

From marca@wintermute.ncsa.uiuc.edu  Sun Nov 22 00:26:53 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09029; Sun, 22 Nov 92 00:26:53 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA27459; Sun, 22 Nov 92 00:39:42 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11990
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 21 Nov 92 17:39:27 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA17535; Sat, 21 Nov 92 17:40:39 -0800
Date: Sat, 21 Nov 92 17:40:39 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211220140.AA17535@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: ScreenMode binaries, man page reader, experimental server
In-Reply-To: <9211212233.AA16031@njitgw.njit.edu>
References: <9211212233.AA16031@njitgw.njit.edu>

Jim Whitescarver writes:
> The preformatted tag, PRE, unlike <PLAINTEXT>, allows anchors etc. to be 
> inserted in text that is already formatted.  It greatly simplifies the
> task of importing text from independant applications will anchors
> everywhere you want them.

This looks like a really good idea... is it too late to add it to the
(almost frozen?) HTML spec?

Marc


From K.Hoadley@directory.rl.ac.uk  Mon Nov 23 10:43:45 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13349; Mon, 23 Nov 92 10:43:45 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28753; Mon, 23 Nov 92 10:56:09 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <03870-0@directory.rl.ac.uk>; Mon, 23 Nov 1992 09:44:57 +0000
Date: Mon, 23 Nov 1992 09:41:58 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: Re: hangs/multiple servers
To: timbl@ch.cern.ch
Cc: K.Hoadley%UK.ac.RL.DIRECTORY@ac.uk, www-talk@ch.cern.ch
In-Reply-To: Tim Berners-Lee's message of Fri, 20 Nov 92 18:29:06 +0100: <9211201729.AA00822@www3.cern.ch>
Message-Id: <Ximap.722512657.5851.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Tim Berners-Lee said:
>But it seems feasable.  Maybe we can try it out with some non top-level
>domain
>and when it works register a www.net or maybe just a .www.  :-)

Trying it out is no problem; there are plenty of friendly DNS admins around
(including me ...). In the longer term it would have to be www.net rather
than just .www.
 
>Now, as you point out, we need some mirroring software.  (Ed, you know
>of any?)

Mirroring is a difficult problem, eg should the secondaries poll the
primary to pick up new copies, or should the primary push changes out
to the secondaries ? Should you tranfser entire copies of a server's data
(needed when bringing up a new secondary) or should you just transfer
deltas ? 

For mirroring to work well it needs to be part of the protocol. Maybe
something for HTTP3 .... ?
 
>Rather than just retry another IP address on error on the first, which would
>be slow because of the long tcp timeout, a better method would be, the first
>time a client encounters a given server with >1 IP address, to ping 
>all of them
>wait for any reply packet and take the winner, then connect to that. Solves
>the traffic reduction and the reliability in one swell foop.

One way to do this is to create a number of sockets, one per address,
mark them all as non-blocking, connect() to each of the addresses and 
then select(), ie. send out parallel connection requests and take the first
(even if all connections get established before we process the select(),
that is only three packets per connection).

This method solves the problem of finding the nearest server, and also
the problem of asynch connects mentioned earlier re: midas: just set a
suitable timeout on the select call.

Kevin

From dsr@hplb.hpl.hp.com  Mon Nov 23 11:41:11 1992
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13554; Mon, 23 Nov 92 11:41:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA06973; Mon, 23 Nov 92 11:53:34 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 23 Nov 92 10:51:36 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12224; Mon, 23 Nov 92 10:51:29 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9211231051.AA12224@manuel.hpl.hp.com>
Subject: Different forms of Annotations
To: timbl@nxoc01.cern.ch
Date: Mon, 23 Nov 92 10:51:26 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.25]

It seems to me that there are several flavours of useful annotations:

News style "responses"     (similar to Dan Connolly's suggestion)
======================

Here people can post responses to documents. This could be restricted to
a special class of discussion documents or it could be completely open
mechanism allowing responses to any document.

You would read the original document and then compose a response (as an
ordinary html document). The response is then notified to the server owning
the original document. The notification is either a copy of the response
document or a http-like reference to it.

When people next read the original document, the browser shows that a response
has been posted. This is read by clicking the "view next response" button
which could be part of the browser's user interface or a link in the document.

If the server had write permission it could modify the original document to
include a link to the list of responses. By using a hidden link, i.e. a
different tag than <A>, the browser could indicate that the document had
one or more responses, without regard to where they are placed in the
documents text itself.

In my opinion, a better approach is for the server to keep a directory of
which documents have responses, and to add the information dynamically when
sending the original document (caching could be used to avoid the directory
look-up penalty for popular documents). The response info could be sent as
part of the document or via additional parameters.

This mechanism works even when the server doesn't have write access, and can
take advantage of broadcast protocols like news. Dan's suggestion is fine in
the short term, but I think we need to think about this in more depth,
without restricting ourselves to using only the current protocol
infrastructure. I am particularly enamoured by ANSA's trading mechanism as a
means of managing the caching of documents and responses, but haven't the time
to elaborate on this right now.

One thing we should consider ASAP is to include details of document creation
or last  modification date/time. This is essential for purging/refreshing
cache information. I also think it would be a good idea to include the
requestors identity in the request formats sent to servers, going beyond the
internet address info. This would be really helpful for supporting
closed-readership groups.

Direct Annotations (Post Its)
=============================

These are notes which appear in place when you read the original document,
although in some cases you might need to click on a postIt button to see the
actual note which then appears as a pop-up (pale yellow?) window. These may
be penned handwritten comments, or short voice annotations. I can easily
imagine people wanting to using conventional proof-reading marks.

The annotations are attached to anchors within documents - either
pre-existing anchors or via pattern matching. In either approach problems may
occur when the original document is modified. A heuristic pattern maching
approach would be reasonably insensitive to insertions and small changes in
the region of attachment - you don't need an absolute match!

This flavour of annotations can be managed in a simlar way to the previous
style. 

General Revision Histories
==========================

A third flavour of annotions, is to keep a revision history of changes to
documents. A check-out/check-in mechanism can be used to avoid the need for a
branching structure caused by people independently modifying the same version.


Dave Raggett,

HP Labs, Bristol, UK   (dsr@hplb.hpl.hp.com) +44 272 228046

From dsr@hplb.hpl.hp.com  Mon Nov 23 12:13:05 1992
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13670; Mon, 23 Nov 92 12:13:05 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA12855; Mon, 23 Nov 92 12:25:50 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 23 Nov 92 11:23:55 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12237; Mon, 23 Nov 92 11:23:48 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9211231123.AA12237@manuel.hpl.hp.com>
Subject: Supporting the Book metaphor
To: timbl@nxoc01.cern.ch
Date: Mon, 23 Nov 92 11:23:46 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.25]

It seems to me that the Web in its current state is missing out on ideas
from reseach into hypertext systems. Currently there is only a simple link
mechanism taking you to other documents, and a crude keyword search mechanism.
I would like to suggest some extensions which would greatly enrich the
capabilities of the web:

Pictures
========

We want to have documents with pictures in them, that appear and are
formatted as part of the document. A reasonable way of doing this would
be to include references in html documents to objects which should be
displayed as part of the document, but which aren't part of html itself.
It seems sensible to support a variety of formats: TIFF, GIFF, DIBs
Fax group III/IV, CGM etc. The idea of embedded objects which return their
size and can display themselves at a given location seems appropriate.

The client doesn't know in advance about these embedded objects, it therefore
makes sense for the server to be able to append them to the requested html
document so as to avoid a further network loop delay for retrieving them.
If you are interested, we can discuss ideas for how to modify the http
protocol to support this.

The Book Metaphor
=================

Books are very familiar to all of us, and come with a conceptual apparatus
including:

    o   title
    o   author
    o   publication date
    o   copyright
    o   contents
    o   chapters
    o   sections
    o   pages
    o   index
    o   glossary

It would be great to extend html to support these. My suggestion is to have
special documents which group these elements together. These documents are in
sgml and include the above information, either directly or by reference.

The browser recognises the type of these documents and uses them to provide a
browsing context. Thus you can show a button bar with buttons for showing the
contents, the index, the glossary and <<, >> controls for moving sequentially
between pages or chapters. I have lots of ideas for handling glossaries and
indexes and will elaborate in a subsequent note.

While it is possible to add special references from documents to the index,
and next/previous document, it is preferable to hold these separately. You can
then use the same document without modifications in a whole variety of books,
magazines etc. This approach is much richer than simple lists of chapters.

To implement this we only need to agree on the sgml dtd and document type!
I will try to get down to this, but am rather busy right now.


Dave Raggett

HP Labs, Bristol, UK.   (dsr@hplb.hpl.hp.com)  +44 272 228046

From connolly@pixel.convex.com  Mon Nov 23 14:03:52 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14171; Mon, 23 Nov 92 14:03:52 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA00377; Mon, 23 Nov 92 14:16:40 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA20526; Mon, 23 Nov 92 07:16:03 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA15699; Mon, 23 Nov 92 07:16:21 -0600
Message-Id: <9211231316.AA15699@pixel.convex.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: Supporting the Book metaphor 
In-Reply-To: Your message of "Mon, 23 Nov 92 11:23:46 GMT."
             <9211231123.AA12237@manuel.hpl.hp.com> 
Date: Mon, 23 Nov 92 07:16:20 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Pictures
>========

Answer: MIME. I coded a prototype replacement for
HTParseFormat that groks several mime formats, including
text/plain, text/x-html, message/rfc-822, message/external-body,
and multipart/mixed. We just need to add plug-and-play modules
for other MIME types like image/gif, image/x-tiff, etc.

More on that after I get some sleep and write it up...

>The Book Metaphor
>=================
>
Answer: The DocBook DTD from O'Reilly and HaL.

It's an SGML DTD, but it's not as simple as HTML. We need
to get serious about supporting SGML.

I've spent the whole last week with my nose in the SGML
standard. I think I've got a handle on it now.

I've written some code to do the low-level reading of
SGML. It's reentrant, doesn't use malloc(), and
completely conforms to the SGML standard (except for
marked sections and wierd newline conventions).

I even added a couple work-arounds for the problems with
existing HTML data.

And -- I integrated it into the MidasWWW browser. Works great.
I hope to sync up with the author soon.

I'm looking at integrating this SGML_read library into the
linemode browser, but the linemode code isn't reentrant,
and that makes life hard.

What other HTML parsing engines do we have out there?

Tim: you said something about the NeXT editor being hard
to fix. Why is that? It looks like there are three lines
in HTParse.h that write the HREF=foo attributes. I'll send
you patches if you like (though I can't test them -- no NeXT!)

Dan


From bobw@csg.uwaterloo.ca  Mon Nov 23 16:01:33 1992
Return-Path: <bobw@csg.uwaterloo.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14899; Mon, 23 Nov 92 16:01:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA13421; Mon, 23 Nov 92 16:13:26 +0100
Received: by csg.uwaterloo.ca
	id <AA20554>; Mon, 23 Nov 92 10:11:57 -0500
From: Bob Wildfong <bobw@csg.uwaterloo.ca>
Message-Id: <9211231511.AA20554@csg.uwaterloo.ca>
Subject: Embedded graphics (was Re: Book metaphor)
To: dsr@hplb.hpl.hp.com (Dave_Raggett)
Date: Mon, 23 Nov 92 10:11:56 EST
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9211231123.AA12237@manuel.hpl.hp.com>; from "Dave_Raggett" at Nov 23, 92 11:23 am
X-Mailer: ELM [version 2.3 PL11]

> 
> Pictures
> ========

> It seems sensible to support a variety of formats: TIFF, GIFF, DIBs
> Fax group III/IV, CGM etc. The idea of embedded objects which return their
> size and can display themselves at a given location seems appropriate.
> 
> The client doesn't know in advance about these embedded objects, it therefore
> makes sense for the server to be able to append them to the requested html
> document so as to avoid a further network loop delay for retrieving them.
> 
> Dave Raggett
> 
> HP Labs, Bristol, UK.   (dsr@hplb.hpl.hp.com)  +44 272 228046


I've been through this line of thought in a hypertext/electronic book project.
Yes, it's more efficient to include the graphics in the HTML data stream, but
only if you just have one version (format) for each graphic.

We found it best in the long run to provide our embedded graphics in several
formats, and allow the client to choose the format most appropriate for its
output device (e.g. 8-bit vs 24-bit colour, Postscript if the device supports
it, WMF if the client is running the Microsoft Windows version of the viewer
program, etc).

The server sends a list of available formats and the client requests the
graphic file that it prefers.  This permits the best available graphic quality
on each of several possible output devices, but imposes an extra network delay.
Still, graphic files tend to be pretty big, so the extra delay is only a few
% of the file's download time.

 
Bob Wildfong                                       bobw@csg.uwaterloo.ca
Waterloo, Ontario                                  bobw@csg.waterloo.edu
#include <stddisclaimer.h>


From dsr@hplb.hpl.hp.com  Mon Nov 23 16:19:32 1992
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14981; Mon, 23 Nov 92 16:19:32 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA15236; Mon, 23 Nov 92 16:31:44 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 23 Nov 92 15:29:20 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA13659; Mon, 23 Nov 92 15:29:13 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9211231529.AA13659@manuel.hpl.hp.com>
Subject: Pictures & HTML
To: bobw@csg.uwaterloo.ca
Date: Mon, 23 Nov 92 15:29:11 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.25]

>> The client doesn't know in advance about these embedded objects, it
>> therefore makes sense for the server to be able to append them to the
>> requested html document so as to avoid a further network loop delay for
>> retrieving them.

> I've been through this line of thought in a hypertext/electronic book
> project. Yes, it's more efficient to include the graphics in the HTML data
> stream, but only if you just have one version (format) for each graphic.

I wasn't suggesting including the graphics as part of the HTML data stream,
but rather appending it as a separate object with its own distinct format, as
appropriate to its particular type.

> We found it best in the long run to provide our embedded graphics in several
> formats, and allow the client to choose the format most appropriate for its
> output device (e.g. 8-bit vs 24-bit colour, Postscript if the device
> supports it, WMF if the client is running the Microsoft Windows version of
> the viewer program, etc).

This seems to be where the negotiation idea comes in. The client can tell
the server in advance (or as part of the request) what its capabilities are.
Given this the server can work out the most appropriate format to send.

If the picture is really big, or the server has to do some time consuming
format conversion (or perhaps ask some agent to do this on its behalf),
then I believe that the server should quickly reply with a short message to
that effect so that the user has some idea of what is happening and how long
to expect to wait.

By the way, you may be interested to know that in Britain, universities are
being connected this spring to a new fiber optic network intended to allow
academics to read electronic journals on-line with video clips, 3-D animations
and simulations. It will be possible for distant researchers to work on the
same data or paper simultaneously and see each other's changes.

I will try to find out more.


Best wishes,

Dave Raggett

From K.Hoadley@directory.rl.ac.uk  Mon Nov 23 16:48:31 1992
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15135; Mon, 23 Nov 92 16:48:31 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA18315; Mon, 23 Nov 92 17:00:26 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <04336-0@directory.rl.ac.uk>; Mon, 23 Nov 1992 15:48:30 +0000
Date: Mon, 23 Nov 1992 15:50:25 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Sender: K.Hoadley@directory.rl.ac.uk
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: SuperJANET (was: Pictures and HTML)
To: drs@hplb.hpl.hp.com
Cc: www-talk@nxoc01.cern.ch
Message-Id: <Ximap.722534476.5288.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dave Raggett wrote:
>By the way, you may be interested to know that in Britain, universities are
>being connected this spring to a new fiber optic network intended to allow
>academics to read electronic journals on-line with video clips, 3-D
>animations
>and simulations. It will be possible for distant researchers to work on the
>same data or paper simultaneously and see each other's changes.

Dave is referring to SuperJANET, the planned upgrade to the existing JANET
network. This was intended to be a high speed network for multi-service use,
not just a data network but also a multimedia network for applications such
as video conferencing, distance learning and medical imaging.

As a result of the tendering process to pick the supplier for the 
underlying fibre infrastructure these goals have had to be altered slightly.
What we are actually getting is a very nice data network (34 Mb/s) plus
a fairly small number of sites with dedicated bandwidth for the multimedia
services.

Anyone interested in more details please contact me, as I'm secretary of
the group building the data network.

Kevin Hoadley, Rutherford Appleton Laboratory, K.Hoadley@directory.rl.ac.uk

From timbl@www3.cern.ch  Mon Nov 23 17:51:15 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15600; Mon, 23 Nov 92 17:51:15 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA24989; Mon, 23 Nov 92 18:01:34 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02537; Mon, 23 Nov 92 17:55:32 +0100
Date: Mon, 23 Nov 92 17:55:32 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211231655.AA02537@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Bob Wildfong <bobw@csg.uwaterloo.ca>
Subject: Re: Embedded graphics (was Re: Book metaphor)
Cc: dsr@hplb.hpl.hp.com (Dave_Raggett), www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  The server sends a list of available formats and the client requests the
>  graphic file that it prefers.  This permits the best available graphic  
quality
>  on each of several possible output devices, but imposes an extra network  
delay.
>  Still, graphic files tend to be pretty big, so the extra delay is only a few
>  % of the file's download time.
>  


We wanted to keep the whole thing down to one round trip.  So, intead of the  
server sending over availble formats, the client sends over the set of
formats it supports, with some preference weighting. The server makes the  
decision. See some W3 design notes and  
http://info.cern.ch/hypertext/WWW/Protocols/HTTP.html
for some waffle about it.  It should all be in HTTP2.

I suggest a link type (attribute?) "MOVETHISTOO" which like "PRSESENTTHISTOO"  
causes the linked document to be sent over whenevr the base document is moved.
Thisc, ombined with the "EMBED_THIS" attribute will give the effect of a  
multipart document, while allowing the format conversion to act intdependently  
on each part.

	Tim
	
(PS: Anyone got a NeXTMail/MIME gateway?)

	

From TONYJ@scs.slac.stanford.edu  Tue Nov 24 03:54:05 1992
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18357; Tue, 24 Nov 92 03:54:05 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01489; Tue, 24 Nov 92 04:06:56 +0100
Date: Mon, 23 Nov 1992 19:06 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: ScreenMode binaries, man page reader, experimental server
To: www-talk@nxoc01.cern.ch
Message-Id: <EAD9AE448020353A@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ

Jim Whitescarver writes....

>We have an experimental server for our CWIS plus a special gateway
>server.  The ScreenMode interface can still be access via telnet to
>eies2.njit.edu with the login www.  You can try the manual page reader
>their, or via http://eies2:1234/man.  We make extensive use of the <PRE>
>tag for preformatted text.  Much of our hypertext, including the manual
>pages, will not be formatted properly unless you use one of our readers,
>or another reader modifies to support <PRE>.

If you are using the MidasWWW browser you can add support for the <pre> (and </pre>) tag 
just by adding the following lines to the Midaswww.ad file
 
midaswww*WWWHyper*pre.font:	-*-courier-medium-r-normal-*-17-*-*-*-*-*-iso8859-*
midaswww*WWWHyper*pre.breakBefore:	SGMLBREAK_ALWAYS
midaswww*WWWHyper*pre.breakAfter:	SGMLBREAK_ALWAYS
midaswww*WWWHyper*pre.tagList:	SGMLAnchorText: a SGMLMarkerText: p
midaswww*WWWHyper*pre.defaultClass:	SGMLPlainText
midaswww*WWWHyper*pre*p.breakBefore:	SGMLBREAK_NEVER

and replacing the line beginning midaswww*WWWHyper*default.tagList: with

midaswww*WWWHyper*default.tagList:	SGMLMarkerText: p isindex nextid 
SGMLCompositeText: address dl h1 h2 h3 h4 h5 h6 dir menu pre SGMLListText: ul SGMLText: 
comment title SGMLPlainText: xmp listing plaintext SGMLAnchorText: a

(this should be all one line even though it is probably wrapped in the message you are 
reading.) 

The "pre-formatted" man pages look good (try http://eies2.njit.edu:1234/man/cat for an 
example).

Tony


From timbl@www3.cern.ch  Tue Nov 24 11:11:47 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19592; Tue, 24 Nov 92 11:11:47 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA25846; Tue, 24 Nov 92 11:24:29 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03320; Tue, 24 Nov 92 11:19:44 +0100
Date: Tue, 24 Nov 92 11:19:44 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211241019.AA03320@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: jim@wilbur.njit.edu (Jim Whitescarver)
Subject: Re: ScreenMode binaries, man page reader, experimental server
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date: Sat, 21 Nov 92 17:32:08 est
>  From: jim@wilbur.njit.edu (Jim Whitescarver)

>  Much of our hypertext, including the manual
>  pages, will not be formatted properly unless you use one of our readers,
>  or another reader modifies to support <PRE>.
>  

>  The preformatted tag, PRE, unlike <PLAINTEXT>, allows anchors etc. to be 

>  inserted in text that is already formatted.  It greatly simplifies the
>  task of importing text from independant applications will anchors
>  everywhere you want them.  In addition, we have a set of macros for
>  MS-word which allow editing HTML in WYSIWYG fashion, but this also
>  requires support of the preformatted tag in HTML.
>  

>  Al Leurck (al@eies2.njit.edu) developed the PRE tag and MS-word macros
>  here in the ScreenMode interface and we are adding it to the tkWWW X
>  interface.

The <PRE> tag is important, and much better SGML than the XMP tag.
I suggest that editors (including the NeXTStep editor, which I propose
to fix) which read <XMP> should save <PRE>.  I have only one
misgiving abou the format as is, and that is that newlines are
significant.

When you allow anchors and other tags to be put into the text, the
lines can become very long, and most applications will want to keep them
limited for mailing, viewing, etc.  As the PRE files you have
currently include <P> tags for blank lines, why not put a <p>
at the end of every line? This would make the processing of <PRE>
almost identical to the default text processing, except for the font.

I also wonder whether FIXED might be more apt than PRE.

If we can agree on this element we could rush it into Dan's DTD for MIME
and fix all outstanding browers?

Any comments?

	Tim BL


	

From rik@daneel.rdt.monash.edu.au  Tue Nov 24 11:42:33 1992
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19687; Tue, 24 Nov 92 11:42:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA29345; Tue, 24 Nov 92 11:55:18 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA28990; Tue, 24 Nov 92 21:54:37 +1100
Message-Id: <9211241054.AA28990@daneel.rdt.monash.edu.au>
To: www-talk@nxoc01.cern.ch
Subject: Re: The <PRE> tag
In-Reply-To: Your message of "24 Nov 92 11:19:44 +0100."
             <9211241019.AA03320@www3.cern.ch> 
Date: Tue, 24 Nov 92 21:54:37 -1000
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

timbl wrote:
> 
> >  From: jim@wilbur.njit.edu (Jim Whitescarver)
> 
> >  The preformatted tag, PRE, unlike <PLAINTEXT>, allows anchors etc. to be 
> >  inserted in text that is already formatted.  It greatly simplifies the
> >  task of importing text from independant applications will anchors
> >  everywhere you want them.  In addition, we have a set of macros for
> >  MS-word which allow editing HTML in WYSIWYG fashion, but this also
> >  requires support of the preformatted tag in HTML.
> >  
> The <PRE> tag is important, and much better SGML than the XMP tag.
> I suggest that editors (including the NeXTStep editor, which I propose
> to fix) which read <XMP> should save <PRE>.  I have only one
> misgiving abou the format as is, and that is that newlines are
> significant.
> 
> When you allow anchors and other tags to be put into the text, the
> lines can become very long, and most applications will want to keep them
> limited for mailing, viewing, etc.  As the PRE files you have
> currently include <P> tags for blank lines, why not put a <p>
> at the end of every line? This would make the processing of <PRE>
> almost identical to the default text processing, except for the font.
> 
> I also wonder whether FIXED might be more apt than PRE.
> 
> Any comments?

I think the <PRE> tag is a great idea, too.  The problem with not
having newlines significant is that it makes it difficult to do
indenting, etc.  One of the reasons the <PRE> tag is nice is that you
can take text (eg, manual entries) and not worry about formatting:

eg

OPTIONS

  -b   this option performs the blah command.  And if this line is
       reasonably long, I can demonstrate what I'm talking about.

  -f   this option performs the foo command.  Another annoying prob-
       lem is hyphenation.


This sort of thing caused me quite a lot of bother in the first
version of my manual page formatter.  If the newline is not
significant, then does it put lots of spaces between the 'is' and the
'reasonably', or does it join them with a space?  Also, if the new
break was to be between 'can' and 'demonstrate' (for example), how
would the browser know where to start the new line ('demonstrate').

The only misgiving I have about it is that you are formatting text for
a set width, something avoided in the past, but I think the value of
having good-looking formatted text outweighs this.

rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH)  (both soon changing)
Faculty of Computing and Information Technology,
Caulfield Campus, Monash University, Australia (soon moving to Clayton)

From timbl@www3.cern.ch  Tue Nov 24 12:02:44 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19775; Tue, 24 Nov 92 12:02:44 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA01198; Tue, 24 Nov 92 12:15:33 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03386; Tue, 24 Nov 92 12:10:56 +0100
Date: Tue, 24 Nov 92 12:10:56 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211241110.AA03386@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Rik Harris <rik@daneel.rdt.monash.edu.au>
Subject: Re: The <PRE> tag
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date: Tue, 24 Nov 92 21:54:37 -1000
>  From: Rik Harris <rik@daneel.rdt.monash.edu.au>

>  I think the <PRE> tag is a great idea, too.  The problem with not
>  having newlines significant is that it makes it difficult to do
>  indenting, etc.  One of the reasons the <PRE> tag is nice is that you
>  can take text (eg, manual entries) and not worry about formatting:
>  

>  eg
>  

>  OPTIONS
>  

>    -b   this option performs the blah command.  And if this line is
>         reasonably long, I can demonstrate what I'm talking about.
>  

>    -f   this option performs the foo command.  Another annoying prob-
>         lem is hyphenation.


I was sugesting that you should format the above like

  OPTIONS<p>
<p>
    -b   this option performs the blah command.  And if this line is<p>
         reasonably long, I can demonstrate what I'm talking about.<p>
<p>  

    -f   this option performs the foo command.  Another annoying prob-<p>
         lem is hyphenation.<p>

That is, you explicitly put in the line end, but all white space is significant  
on the line.. It means that lines like

	See also csh, cc, blah, fred and junk.

which would have to be a SINGLE LINE

See also  <a name=csh href=csh.html>csh</a>, <a name=cc href=cc.html>cc</a>, <a  
name=blah2 href=http://sdf.adf.uasdf.edu/fred/doc/junk/blah.html>blah</a>, <a  
name=fred href=fred.html>fred</a> and <a name=junk href=junk.html>csh</a>.

instead could out as for example

See also  

 <a name=csh href=csh.html>csh</a>, 

 <a name=cc href=cc.html>cc</a>, 

 <a name=blah2 href=http://sdf.adf.uasdf.edu/fred/doc/junk/blah.html>blah</a>,
 <a name=fred href=fred.html>fred</a> and <a name=junk href=junk.html>csh</a>.
<p>

which is mailable.  If you look atthe NJIT manual pages HTML, there is a  
mixture of significant line feeds and explicit <p> elements for blank lines:

  OPTIONS
<p>
    -b   this option performs the blah command.  And if this line is
         reasonably long, I can demonstrate what I'm talking about.
<p>  

    -f   this option performs the foo command.  Another annoying prob-
         lem is hyphenation.
<p>

I propose we settle for one or the other.  I wonder whether there is
anything in SGML to suggest which.

	Tim


	

From connolly@pixel.convex.com  Tue Nov 24 16:51:21 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21007; Tue, 24 Nov 92 16:51:21 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA28119; Tue, 24 Nov 92 17:03:46 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA04554; Tue, 24 Nov 92 10:03:25 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA07624; Tue, 24 Nov 92 10:03:21 -0600
Message-Id: <9211241603.AA07624@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: Rik Harris <rik@daneel.rdt.monash.edu.au>, www-talk@nxoc01.cern.ch
Subject: Re: The <PRE> tag 
Summary: Yeah, what Tim said.
In-Reply-To: Your message of "Tue, 24 Nov 92 12:10:56 +0100."
             <9211241110.AA03386@www3.cern.ch> 
Date: Tue, 24 Nov 92 10:03:21 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>  Date: Tue, 24 Nov 92 21:54:37 -1000
>>  From: Rik Harris <rik@daneel.rdt.monash.edu.au>
>
>>  I think the <PRE> tag is a great idea, too.  The problem with not
>>  having newlines significant is that it makes it difficult to do
>>  indenting, etc.  One of the reasons the <PRE> tag is nice is that you
>>  can take text (eg, manual entries) and not worry about formatting:
>
>I was sugesting that you should format the above like
>
>  OPTIONS<p>
><p>
>    -b   this option performs the blah command.  And if this line is<p>
>         reasonably long, I can demonstrate what I'm talking about.<p>
><p>  
>
>    -f   this option performs the foo command.  Another annoying prob-<p>
>         lem is hyphenation.<p>
>
>That is, you explicitly put in the line end, but all white space is significan
t  
>on the line.. It means that lines like
>
>	See also csh, cc, blah, fred and junk.
>
>which would have to be a SINGLE LINE
>See also  <a name=csh href=csh.html>csh</a>, <a name=cc href=cc.html>cc</a>, <a  
>name=blah2 href=http://sdf.adf.uasdf.edu/fred/doc/junk/blah.html>blah</a>, <a 
>name=fred href=fred.html>fred</a> and <a name=junk href=junk.html>csh</a>.
>
>instead could out as for example
>
>See also  
>
> <a name=csh href=csh.html>csh</a>, 
>
> <a name=cc href=cc.html>cc</a>, 
>
> <a name=blah2 href=http://sdf.adf.uasdf.edu/fred/doc/junk/blah.html>blah</a>,
> <a name=fred href=fred.html>fred</a> and <a name=junk href=junk.html>csh</a>.
><p>
>
>which is mailable.  If you look atthe NJIT manual pages HTML, there is a  
>mixture of significant line feeds and explicit <p> elements for blank lines:
>
>  OPTIONS
><p>
>    -b   this option performs the blah command.  And if this line is
>         reasonably long, I can demonstrate what I'm talking about.
><p>  
>
>    -f   this option performs the foo command.  Another annoying prob-
>         lem is hyphenation.
><p>
>
>I propose we settle for one or the other.  I wonder whether there is
>anything in SGML to suggest which.

In fact, there is. Well, not actally in SGML, but in the "application
conventions" that I have used to map SGML onto WWW.

All elements in HTML have either mixed content, RCDATA, or CDATA.
Mixed content is a mixture of <tags>, &entity; references,
and #PCDATA. RCDATA is just &entities; and data. CDATA is just data.

[SGML actually has a couple other content modes: ANY and
element content, but I didn't use those.]

CDATA is only used for the TITLE. RCDATA is used for XMP and LISTING
(entity references _are_ recognized in RCDATA sections, so you
can inlclude the _full_ end tag like this: &lt;/XMP>. But the
string </ followed by a letter _ends_ the section, whether the
letter starts the XMP tag or not.)

The convention is that in PCDATA sections, newlines serve only
to delimit words, whereas in RCDATA, newlines are significant.

We can't use RCDATA for the PRE or FIXED tag, cuz the <a> tag
won't be recognized in RCDATA. So I'd suggest you ignore
newlines inside the PRE element, and use <p> to delimit lines.
And since we're not using the exact semantics of PRE, I like
the idea of using the name FIXED in stead.  In SGML:

<!ELEMENT FIXED - - (#PCDATA|A|P)*>

The fact that the MidasWWW browser can support the semantics
of PRE is due to its non-standard parsing, where it treats
illegal tags as data, rather than ignoring them. SGML says
they'r not data, whatever they are, and the HTML doc in
the web says to ignore them.

I'm integrating my low-level SGML reading routines into
MidasWWW now, and with the author's consent, the non-standard
behaviour will soon go away. [The MidasWWW 1.0 browser doesn't
do &lt; or &amp; either -- that too will change.]

I've got it running, but there are a couple integration bugs I haven't
yet tracked down.

I've also got something of a validation suite for HTML, so that
implementors can easily see if they've gotten it right. And the
suite goes from easy to hard, so they can see how much of it
they got right, and if they don't want to fix it, they can at least
document how much it's broken.

Dan


From connolly@pixel.convex.com  Tue Nov 24 17:27:07 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21258; Tue, 24 Nov 92 17:27:07 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA02525; Tue, 24 Nov 92 17:39:49 +0100
Received: from convex.convex.com by mcsun.EU.net with SMTP
	id AA03227 (5.65b/CWI-2.189); Tue, 24 Nov 1992 17:39:31 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA06055; Tue, 24 Nov 92 10:38:14 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA09205; Tue, 24 Nov 92 10:38:13 -0600
Message-Id: <9211241638.AA09205@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: more on PRE tag
Date: Tue, 24 Nov 92 10:38:12 CST
From: Dan Connolly <connolly@pixel.convex.com>

I take back what I said about the PRE tag.

I'm going to have to think about it a little more.

Newlines are pretty tricky business in SGML. I don't think
it's wise to have an element where they're just ignored.

I'll have to think about it some more.

Dan

From fine@cis.ohio-state.edu  Tue Nov 24 20:44:33 1992
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22409; Tue, 24 Nov 92 20:44:33 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA23201; Tue, 24 Nov 92 20:57:29 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA15795; Tue, 24 Nov 92 14:57:10 -0500
Date: Tue, 24 Nov 92 14:57:10 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9211241957.AA15795@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Questions and comments
X-Mailer: Perl Mail System v1.1

I'm new to this list, so forgive me if I hit things already dealt with.

I'm implementing yet another browser (text mode, written in perl).
It's actually basically done.  I have implemented the following tags:

TITLE, A, NEXTID (currently ignored), ISINDEX (ignored), PLAINTEXT,
PRE, LISTING, XMP, P, H1-H6, HP1-HP6 (ignored), DL, UL, MENU, and DIR.

also, I have done PRE and OL. But along the way I've seen several other
things in several different places.  For instance the following seem to
be defined in viola:
  COMMENT, XMPA, S, ST, VOBJ, XMPA
I've also seen references to DOCUMENT, KEYWORDS, DOCTYPE, and perhaps others.

Which brings me to my main question:
Is there a definitive list somewhere of everything that's been proposed.

Other stuff:
I'm not sure what the difference is supposed to be between an OL and
a UL.  Should the browser actually sort the list items for a OL?

As far as the <PRE> discussion, I'm not sure I understand what the problem
is with interpreting new lines.  The visual line length won't change for
having added anchors.

Also, I was under the impression that PRE was like PLAINTEXT, meaning their
is no ending tag, just end of file.  I hope I've misunderstood, if you
are proposing to replace XMP with PRE.  Another problem with this replacement
is the quoting problem.  With XMP, you don't need to worry about whether
or not your arbitrary text contains something which looks like an HTML
tag.  This is an important feature, and one which should be kept IMHO.

            tom

From jim@wilbur.njit.edu  Wed Nov 25 18:31:08 1992
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28163; Wed, 25 Nov 92 18:31:08 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03834; Wed, 25 Nov 1992 18:43:48 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA29142; Wed, 25 Nov 92 12:43:22 -0500
Message-Id: <9211251743.AA29142@njitgw.njit.edu>
Received: by wilbur.njit.edu; Wed, 25 Nov 92 12:41:49 est
Date: Wed, 25 Nov 92 12:41:49 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: timbl@nxoc01.cern.ch
Subject: Re: The <PRE> tag
Cc: www-talk@nxoc01.cern.ch

We are not stuck on the <PRE> tag, only the functionality.  If <p> at
the end gave us single spaced output, that would be acceptable though a
bit more work.  I've been unable to duplicate the effect using existing
tags.  Whatever name, (I'd prefer <PREFORMATTED>), the standard should
include an end tag </PRE>.  We don't support an end tag, but should.  I
attampted to translate ms documents to html, with some success, but,
equations (neqn) and tables (tbl), were close to impossible.  I'd like
to use preformatted for those sections alone, and not the whole document
(http://eies2.njit.edu/rakesh/paper.html).

The idea of new lines being significant is only repungnant in the case
of generating new hypertext.  The express purpose of <PRE> is to make
use of externally formated text where new lines ARE significant.

I used the <p> tags within <PRE> text in order to marginally support
browsers that do not understand <PRE>.  I'll be glad to provide a
version of manual pages without the <p>,  http://eies2.njit.edu:1234/man-p.
The long term value of mixing <p> within <PRE> is dubious at best.

The MidasWWW update for <PRE> looked nice and simple.  I look forward
to trying it!

Let's get a <PRE> capability into the standard so we can put anchors everywhere!

jim

From marca@wintermute.ncsa.uiuc.edu  Thu Nov 26 01:18:39 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29770; Thu, 26 Nov 92 01:18:39 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29790; Thu, 26 Nov 1992 01:31:25 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26337
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 25 Nov 92 18:31:22 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA00309; Wed, 25 Nov 92 18:32:35 -0800
Date: Wed, 25 Nov 92 18:32:35 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211260232.AA00309@wintermute.ncsa.uiuc.edu>
To: Thomas A. Fine <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Questions and comments
In-Reply-To: <9211241957.AA15795@soccer.cis.ohio-state.edu>
References: <9211241957.AA15795@soccer.cis.ohio-state.edu>

Thomas A. Fine writes:
> As far as the <PRE> discussion, I'm not sure I understand what the
> problem is with interpreting new lines.  The visual line length
> won't change for having added anchors.

This is true.  As far as I can tell, the only real objection that's
been raised specifically to the increased real line length is that
long lines aren't safe to mail.  This problem can easily be
circumvented by using MIME & metamail (plug plug, although I have
nothing to do with it -- I'm just interested in seeing MIME used in
WWW).

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From fine@cis.ohio-state.edu  Thu Nov 26 01:31:09 1992
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29782; Thu, 26 Nov 92 01:31:09 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05489; Thu, 26 Nov 1992 01:43:55 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA26082; Wed, 25 Nov 92 19:43:50 -0500
Date: Wed, 25 Nov 92 19:43:50 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9211260043.AA26082@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Questions and comments
X-Mailer: Perl Mail System v1.1

>Thomas A. Fine writes:
>> As far as the <PRE> discussion, I'm not sure I understand what the
>> problem is with interpreting new lines.  The visual line length
>> won't change for having added anchors.
>
>This is true.  As far as I can tell, the only real objection that's
>been raised specifically to the increased real line length is that
>long lines aren't safe to mail.  This problem can easily be
>circumvented by using MIME & metamail (plug plug, although I have
>nothing to do with it -- I'm just interested in seeing MIME used in
>WWW).

If that's the case then I'd have to say that it's ridiculous to try
to fix mail (or any other transport mechanism) by mucking up HTML with
crud.  Anyway, threre are already various programs that will let you
break lines for use with mail.  Http shouldn't care at all about lines.

Yes, MIME would be good.  But would you make WWW pass around MIME
documents only, with HTML being one of the Content-Types, or would
you have http handle several different doc types, including both
MIME and HTML?

       tom

From marca@wintermute.ncsa.uiuc.edu  Thu Nov 26 01:40:09 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29796; Thu, 26 Nov 92 01:40:09 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10409; Thu, 26 Nov 1992 01:52:54 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA27071
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 25 Nov 92 18:52:51 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA00390; Wed, 25 Nov 92 18:54:03 -0800
Date: Wed, 25 Nov 92 18:54:03 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9211260254.AA00390@wintermute.ncsa.uiuc.edu>
To: Thomas A. Fine <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Questions and comments
In-Reply-To: <9211260043.AA26082@soccer.cis.ohio-state.edu>
References: <9211260043.AA26082@soccer.cis.ohio-state.edu>

Thomas A. Fine writes:
> Yes, MIME would be good.  But would you make WWW pass around MIME
> documents only, with HTML being one of the Content-Types, or would
> you have http handle several different doc types, including both
> MIME and HTML?

What I'd like to see, based on what I know now, is 'text/html' become
a MIME content type and the WWW code retrofitted to handle MIME
documents as a base type.  Then essentially a raw HTML document would
become the degenerate case for WWW (implicitly text/html).

It is important that other datatypes can be inlined in a document,
which is what MIME allows (as opposed to just allowing ordinary links
to GIF files, or something similar).

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From fine@cis.ohio-state.edu  Thu Nov 26 02:39:54 1992
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00122; Thu, 26 Nov 92 02:39:54 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29656; Thu, 26 Nov 1992 02:52:40 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA26512; Wed, 25 Nov 92 20:52:37 -0500
Date: Wed, 25 Nov 92 20:52:37 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9211260152.AA26512@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Another tty-based browser (Beta)
X-Mailer: Perl Mail System v1.1


I just put my tty-based browser up for ftp.  This is a Beta release (I
guess I'll find out just how beta it is :-).  It's written in perl, so
you may also need to pick up perl.

You can get the browser via ftp from archive.cis.ohio-state.edu, in
pub/w3browser/w3browser-0.1.shar.

It's a shar file, so unpack with
sh w3browser-0.1.shar

and it will create files in your current directory.

I've included my own version of termcap.pl (normally a standard perl
distribution file, I think), because I found a bug in ours.  I'll
check after thanksgiving to see if there's a more recent version with
an official bug fix.

Use, enjoy, comment, and flame.

	tom



From timbl@www3.cern.ch  Thu Nov 26 09:36:28 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01204; Thu, 26 Nov 92 09:36:28 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11529; Thu, 26 Nov 1992 09:49:15 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01192; Thu, 26 Nov 92 09:44:42 +0100
Date: Thu, 26 Nov 92 09:44:42 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211260844.AA01192@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: re: Questions and comments
Reply-To: timbl@nxoc01.cern.ch



> Date: Wed, 25 Nov 92 19:43:50 -0500
> From: Thomas A. Fine <fine@cis.ohio-state.edu>


>  Yes, MIME would be good.  But would you make WWW pass
>  around MIME documents only, with HTML being one of the
>  Content-Types,

Yes, this way.  I am no great fan of the MIME wrappers
(they are so mail-oriented and human-readable!) but
I am so strongly in favor of merging related technlogies that
I feel MIME should do that, just as SGML should do the
mark-up.  So in HTTP2, a document will be returned as
a MIME message. That is one reason for getting
text/html registerd as a MIME format now.

>  or would you have http handle several
>  different doc types, including both MIME and HTML?

That's too many wheels within wheels.

>       tom

Tim



From timbl@www3.cern.ch  Thu Nov 26 10:24:23 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01394; Thu, 26 Nov 92 10:24:23 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20075; Thu, 26 Nov 1992 10:37:10 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01230; Thu, 26 Nov 92 10:32:36 +0100
Date: Thu, 26 Nov 92 10:32:36 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9211260932.AA01230@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: jim@wilbur.njit.edu (Jim Whitescarver)
Subject: Re: The <PRE> tag
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Wed, 25 Nov 92 12:41:49 est
>  From: jim@wilbur.njit.edu (Jim Whitescarver)

>  We are not stuck on the <PRE> tag, only the functionality.  If <p> at
>  the end gave us single spaced output, that would be acceptable though a
>  bit more work.  I've been unable to duplicate the effect using existing
>  tags.  Whatever name, (I'd prefer <PREFORMATTED>),

PREFORMATTED is too long for default SGML element length.
I feel FIXED is more descriptive of what the tag means -- in that the character  
spacing is fixed.  I feel the tag should describe the interpretation to be but  
onto the data, not just its origin. In fact, FIXED would be used in cases where  
XMP and LISTING are used now. It is trivial to convert.  I so no great use for
XMP and LISTING except for back-compatibility.

	WIDTH
	
I would like an attribute WIDTH=nn to specify the width of display.
This can allow the viewer to select a font which will fit. It will also
allow something 40 chars wide to be indented rather than having to 

start at the LH margin (and typically be filled out with tabs so that it
doesn't look silly) like in a quoted command.  I would put an implementor's
comment in that widths of 40, 80 and 132 are likely and handling those well
would be a good move. Any oethr widths can be rounded up of course.
In a style-oriented editor, that gives 3 styles: command, example,listing.


>  the standard should
>  include an end tag </PRE>.  We don't support an end tag, but should.

Definitely!

> I
>  attampted to translate ms documents to html, with some success, but,
>  equations (neqn) and tables (tbl), were close to impossible.  I'd like
>  to use preformatted for those sections alone, and not the whole document
>  (http://eies2.njit.edu/rakesh/paper.html).

	I get "Document address invalid or access not authorised" for
	that one ... have you sepelt it right?

	NEW LINE

Whether lines are ended with newline or <p> is in fact a question of  
practicality.

>  The idea of new lines being significant is only repungnant in the case
>  of generating new hypertext.  The express purpose of <PRE> is to make
>  use of externally formated text where new lines ARE significant.

Hold on. Let's get our ideas straight. We want FIXED to allow us
to inlcude preformatted text.  We can never, however, just paste preformatted
text into a <PRE> section because we will have to change the < and & characters
to entities.  At the same time as we add those it's easy to add a <p> at the  
end of every line.

It isn't just mail which has problems with newlines. There are horrible
mainframe systems which have trouble with things which don't fit into card or  
lineprinter images, and even VMS complains when a line buffer overflows. There  
are probably a lot of finite line buffers in the world. When you imagine  
(pathalogical case) putting an anchor on each of 80 characters, we can end up  
with of the order of 1kB per line. When it totally resonable for you and me but  
I bet someone will hate it.

But then of course we can always break lines before any tag closer > so it  
doesn't matter anyway, right?

Dan's aygument remains that by SGML convention (only?) newlines are significant  
only in "RCDATA" (replacable character data) in which one cannot have anchors.  
If you need anchors, you need PCDATA (parsable CDATA) in which newlines are
by convention not signifiant.

>  I used the <p> tags within <PRE> text in order to marginally support
>  browsers that do not understand <PRE>.  I'll be glad to provide a
>  version of manual pages without the <p>,  http://eies2.njit.edu:1234/man-p.
>  The long term value of mixing <p> within <PRE> is dubious at best.

I absoltely agree that we don't mix <p> with significant newlines!
My attempts to interpret your man pages lead to a lot of white
space, as \n<p>\n was interpreted as 3 newlines!

Let's not bother marginally supporting any browsers. All the parser authors are  
in this discussion, we can get it right and define it. We can then all
retrofit it in time for the MIME text/html definition. OK?

I would like to see a /man/fixed with either <p> throughout or no <p>.

	<FIXED>
	Every line ends with &lt;p><p>
	<p>
	Blank or not<p>
	</FIXED>


>  The MidasWWW update for <PRE> looked nice and simple.  I look forward
>  to trying it!
>  

>  Let's get a <PRE> capability into the standard so we can put anchors  
everywhere!

Absoltely.  We just need discussion or votes on 3 issues:

  Tag name:		<FIXED>		<PRE>		(other)

  Newlines:		\n		<p>

  WIDTH=nn		yes		no


>  

>  jim
>  

	Tim

From connolly@pixel.convex.com  Mon Nov 30 13:14:41 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01112; Mon, 30 Nov 92 13:14:41 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17248; Sun, 29 Nov 1992 21:34:49 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA20685; Sun, 29 Nov 92 14:34:41 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA22237; Sun, 29 Nov 92 14:34:40 -0600
Message-Id: <9211292034.AA22237@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Questions and comments 
In-Reply-To: Your message of "Tue, 24 Nov 92 14:57:10 EST."
             <9211241957.AA15795@soccer.cis.ohio-state.edu> 
Date: Sun, 29 Nov 92 14:34:39 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I'm new to this list, so forgive me if I hit things already dealt with.

Actually, your questions are quite timely.

>I'm implementing yet another browser (text mode, written in perl).
>It's actually basically done.  I have implemented the following tags:
>
>TITLE, A, NEXTID (currently ignored), ISINDEX (ignored), PLAINTEXT,
>PRE, LISTING, XMP, P, H1-H6, HP1-HP6 (ignored), DL, UL, MENU, and DIR.
>
>also, I have done PRE and OL. But along the way I've seen several other
>things in several different places.  For instance the following seem to
>be defined in viola:
>  COMMENT, XMPA, S, ST, VOBJ, XMPA
>I've also seen references to DOCUMENT, KEYWORDS, DOCTYPE, and perhaps others.
>
>Which brings me to my main question:
>Is there a definitive list somewhere of everything that's been proposed.

The current specification is

http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html

I hope to replace that with a more rigorous specification soon.
I hope to use the same spec to register text/html with the IANA for
MIME purposes.

>Other stuff:
>I'm not sure what the difference is supposed to be between an OL and
>a UL.  Should the browser actually sort the list items for a OL?

An OL was never a sorted list. It's just a numbered list, as opposed
to a bulleted list. It's for stuff where the order of the items in
the list is significant; e.g. step 1: do this. step 2: do that...

>Also, I was under the impression that PRE was like PLAINTEXT, meaning their
>is no ending tag, just end of file.  I hope I've misunderstood, if you
>are proposing to replace XMP with PRE.  Another problem with this replacement
>is the quoting problem.  With XMP, you don't need to worry about whether
>or not your arbitrary text contains something which looks like an HTML
>tag.  This is an important feature, and one which should be kept IMHO.

Well, you have to throw out SGML conformance if you want the current
PLAINTEXT semantics. Even the XMP semantics are no good. In SGML, the
string "</" is recognized as markup iff it's followed by a name start
character (a letter). The above HTML documentation says </ is only
markup if it's followed by XMP, i.e. "</XMP>" is the _only_ string
that ends an XMP section. This is not expressible in SGML.

I'm defining HTML in terms of SGML. Period. I'm punting on Plaintext. The
idea is that plaintext data is not part of the HTML data format. Plaintext
is governed by the MIME text/plain data format. Any HTTP servers
that return some HTML followed by <PLAINTEXT> followed by more data
are thought to return two MIME entities: a text/html entity, terminated
by the <PLAINTEXT> tag, and a text/plain entity.

As for the <PRE> tag, I think I'm going to call it FIXED, and go with
a <p> tag at the end of every line.

Details as they develop...

Dan


From connolly@pixel.convex.com  Mon Nov 30 14:11:26 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01542; Mon, 30 Nov 92 14:11:26 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27420; Sun, 29 Nov 1992 22:23:28 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA21660; Sun, 29 Nov 92 15:23:25 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23851; Sun, 29 Nov 92 15:23:23 -0600
Message-Id: <9211292123.AA23851@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Questions and comments 
In-Reply-To: Your message of "Wed, 25 Nov 92 19:43:50 EST."
             <9211260043.AA26082@soccer.cis.ohio-state.edu> 
Date: Sun, 29 Nov 92 15:23:23 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>been raised specifically to the increased real line length is that
>>long lines aren't safe to mail.  This problem can easily be
>>circumvented by using MIME & metamail (plug plug, although I have
>>nothing to do with it -- I'm just interested in seeing MIME used in
>>WWW).
>
>If that's the case then I'd have to say that it's ridiculous to try
>to fix mail (or any other transport mechanism) by mucking up HTML with
>crud.  Anyway, threre are already various programs that will let you
>break lines for use with mail.  Http shouldn't care at all about lines.

Amen, brother. Line length certainly should not be part
of the HTML spec.

As for HTTP, the 80 character line length was, is, and always will
be, merely a suggestion. HTTP implementations that assume 80 character
lines are broken. But I'm sure they're out there.

>Yes, MIME would be good.  But would you make WWW pass around MIME
>documents only, with HTML being one of the Content-Types, or would
>you have http handle several different doc types, including both
>MIME and HTML?

My strategy on integrating MIME is this:

Currently, a WWW or gopher client sends "gimme foo" and expects the
server to send foo back. The client _must know_ the data format of foo
in order to convey it to the user.

A gopher client knows foo's format from the first character of the
MenuItem where it got foo in the first place (it assumes gopher format
when foo is the empty string.)

A WWW client assumes foo's format is HTML, until it sees <PLAINTEXT>,
where it switches to plain text format.

Now if we just use the name text/plain for gopher type 0, application/gopher
for gopher type 1, text/html for the WWW data stream, and text/plain
for the stuff after the <PLAINTEXT> tag, we begin to see how MIME
fits into the picture.

I'd like to see the gopher protocol extended to include the actual MIME
content-type in the Menu, like this:

0#About This Gopher#about.txt#some.internet.host#70#text/plain
1#Departmental Publications#publications#some.internet.host#70#application/gopher

Now with text/plain and application/gopher, the MIME content-type
is redundant, and not so important. But consider:

9#My picture#connolly.gif#some.internet.host#70#image/gif
9#Pronunciation of my name#connolly.snd#some.internet.host#70#audio/basic

So in stead of registering zillions of special characters for new
gopher types (i, w, M, etc.) we just add a field to the Menu item,
and use type 9 for everything besides menus and text files.

The same holds for WWW references. They should include the data
type, with text/html as the default. So I should be able to
reference the above picture and sound in WWW:

<A HREF="gopher://some.internet.host:70/9connolly.gif"
	CONTENT-TYPE="image/gif">

<A HREF="gopher://some.internet.host:70/9connolly.snd"
	CONTENT-TYPE="audio/basic">

This is especially important for protocols that have no implicit data
type, like FTP.  I could reference a DVI on an FTP server, and have my
WWW client launch xdvi ala metamail:

<A HREF="ftp://export.lcs.mit.edu/contrib/foo.dvi"
	content-type="application/x-dvi">

Now the WWW gang has always talked about format negotiation.
This is where the client gives the server several options
for the data format, and the server chooses between them.
So what's the data type of the returned information?
We need a type that's a "union" of all the data types, right?

Now we see the need for the MIME message/rfc822 content type.
Consider the following scenario:

CLIENT: GET foo HTTP-Version-2 Content-Types:
	1000 text/html
	900 application/postscript
	200 text/plain
	400 application/x-dvi
	100 text/x-latex
	.

SERVER: 0200 Message follows:
From: author@his.host
Message-ID: <lasting-name-for-this-document>
Subject: ... fullfills role of HTML <TITLE> element ...
Mime-Version: 1.0
Content-Type: application/postscript
Content-Transfer-Encoding: binary

%!PS-Adobe-2.0
...


The next possibility to consider is multimedia documents, e.g.
one document that contains plain text, HTML text, gif images,
sounds, etc.

That's where the MIME multipart/mixed content type comes
in. If the client is prepared to receive multipart messages,
this is gravy.

Get it?

Dan


From connolly@pixel.convex.com  Mon Nov 30 14:14:14 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01580; Mon, 30 Nov 92 14:14:14 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18736; Mon, 30 Nov 1992 14:27:07 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09143; Mon, 30 Nov 92 07:27:03 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA05269; Mon, 30 Nov 92 07:27:02 -0600
Message-Id: <9211301327.AA05269@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: An HTML specification and Implementors' Guide
Date: Mon, 30 Nov 92 07:27:01 CST
From: Dan Connolly <connolly@pixel.convex.com>


I just uploaded

html_spec-0.3.tar.Z

to info.cern.ch in pub/incoming.

It's hypertext including

* MarkUp.html -- the root node
* Text.html -- an introduction to SGML syntax
* html.dtd -- the spec expressed in HTML
* several example files that form a validation suite
* libHTML.tar -- some code that implements the low-level
		SGML reading state machine (with a test driver)

Tim: please link this into the web somehow.

Implementors: please grab the whole thing and validate
your implementation against it.

Tony: I've got some patches for the MidasWWW browser.
I'm not quite done cleaning them up.

Linemode fans: I haven't started messing with linemode
yet.

Issues Closed Pending Review:

Long Names

I included an SGML declaration that increases NAMELEN to 34,
and LITLEN to 1024. I got these numbers from the DocBook DTD.


SGML IDs for Anchor Names

The NAME attribute of the A element is an ID. It must start
with a name, and it must be unique among all the IDs in
the document. [Note that there is no way to validate the #anchor
part of the HREF attribute. I'm working on that...]


Multimedia Links

I included a content-type attribute for links so that you can tell the
browser what type of data you're pointing to, and it can decide what to
do with it (at a minimum, use this attribute and pass the data to
metamail). I added a content-description attribute in case you want the
reader to be able to get some information about the data without
transfering it, but now I'm not sure it's a good idea. The description
should go in the content of the A element.


Formatted Text with Anchors

I took the semantics of the PRE tag, added the WIDTH attribute, and
called it TYPEWRITER (inspired by the nroff man page). It's parsed like
most other elements, but displayed like XMP or LISTING or PLAINTEXT.

Newline handling isn't a parsing issue -- it's a display issue. I think
it will be more straightforward to define newlines in TYPEWRITER
content to be significant. That way, once the data is parsed, XMP
and TYPEWRITER work just the same. Lines may get real long. That's
life. If you want to mail it, use MIME or uuencode or something.

XMP and LISTING elements are CDATA: they have no markup in their
content. There's no way to put </TITLE> inside an XMP element.

PLAINTEXT is an empty element that signals the end of a text/html
entity and begins a text/plain entity.


Ordered Lists

I included them in the DTD. Any objections?


ISO Latin 1 Characters:

I included a reference to "ISO 8879:1986//ENTITIES Added Latin 1//EN"
in the HTML DTD. This defines entities for all ISO latin 1 characters.
Clients will need a table of the names and local translations.


Open Issues:

Highlighting: Who's tags should we use? LaTeX seems to be an adequate
markup system for lots of folks. Its tags are
	em | it | bf | sf | sl | tt

The DocBook folks use only semantic tags: they don't have bold or italic
tags. The MIME richtext stuff has only typographic tags: no <emphasis>
or <booktitle> or any such thing.

Dan

From jim@wilbur.njit.edu  Mon Nov 30 17:59:41 1992
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03312; Mon, 30 Nov 92 17:59:41 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16636; Fri, 27 Nov 1992 21:55:37 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA12117; Fri, 27 Nov 92 15:55:15 -0500
Message-Id: <9211272055.AA12117@njitgw.njit.edu>
Received: by wilbur.njit.edu; Fri, 27 Nov 92 15:53:44 est
Date: Fri, 27 Nov 92 15:53:44 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: www-talk@nxoc01.cern.ch
Subject: interactive hypermedia
Cc: al@eies2.njit.edu, murray@eies2.njit.edu, reddy@eies2.njit.edu

At NJIT we are going beyond the scope of the WWW.  We will support HTML
for access, plus extensions for interactive group hypermedia.  Some issues
involve the larger WWW community others may be better suited for another
forum.  Although nothing is cast in stone, we must impliment these capabilities
now, before the standards arrive.  We seek to maximize our WWW compliance.
This is a summary of our current direction for your comments.

We will NOT obey the pricipal that the same reference always accesses the
same hypertext object.  We plan a <VAR> tag to indicate variable data in
the text.  Text within the <VAR> to </VAR> should not be cached.  It would
be helpful if other clients supported this convention.  Initially, we will
not cache the entire document is it contains one or more <VAR>, later we
want to be able to request only the <VAR> fields for the document and
merge them with a cached version with minimal communication.  VAR should
have a TIMEOUT parameter ultimately.

We will add an <INPUT> tag, with parameters for length, type, and default.
We will allow inputs to be sent using the format of search keywords over
http.  It would be helpful if other browsers allow serches on documents
containing the <INPUT> tag.  The length suggests how much space to leave
for the input, not a maximum necesarily.  Text through </INPUT>  may be
the prompt. A name parameter will allow addressing inputs like anchors.
An input is, afterall, like an achor for keyboard data.  In addition to
query (search) for input data, we will also require a submit, as http
has no PUT operation, we will use mail (as with comments, see below).

We eventually want an <INCLUDE> tag with an HREF parameter.  This will allow
breaking documents into smaller pieces that can be maintained independantly.

A fallback mechanism will be required.  I don't know if that issue has 
been settled.  We will need a rules file capability for the client back 
end and support for fallback entries in our rules file.  We should consider
restructuring our rules mechanism to better support caching of documents.

We look forward to the dust settling in the multi-media mechanisms for the
web.  In the mean time, and in addition, we plan to support file name
conventions to determine the type of the document when it is otherwise
unspecified.  Innitially we will support .html, .man, .mm, .ms, .jpeg, .gif,
.au, .tar and the .Z suffix. Support for .mime might also be quite nice
dispite the recursion.  We have not resolved all the issues of supporting
this over an http link or dividing the responsibilities between the
client back end and the server.  We may innitially restrict this to
local and ftp file addresses.

We have tenativly selected tcl as our machine independant procedure
language to define group activities accociated with the WEB "group
memory".  Though we prefer Smalltalk, tcl provides a sufficient meta
language capability across Unix, pc's and mac's in the public domain.
The wish (tk) extensions to tcl for Xwindows and tkWWW are an added
plus.  I'd like feedback from others on the use of tcl.

I've been planning an interactive service via http://eies2.njit.edu/
(or telnet://www@eies2.njit.edu/), but lacked time to make it releasable.
I promise to get around to it soon.  Comments are sent to www@eies2.njit.edu
as mail with the HREF as the subject and the text of the comment after
a blank line in the message body.  If the comment does not begin with
an HTML markup, <FIXED> will be assumed, <> quoted (i.e. \<\>), and anchors
added for imbedded HREFS.   (Yes, we do plan to support MIME eventually).
Hopefully the service will be up soon enough for your comments.
Check http://eies2.njit.edu/interactive.

jim

From jim@wilbur.njit.edu  Mon Nov 30 18:00:06 1992
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03338; Mon, 30 Nov 92 18:00:06 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09734; Fri, 27 Nov 1992 17:44:02 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA09646; Fri, 27 Nov 92 11:43:39 -0500
Message-Id: <9211271643.AA09646@njitgw.njit.edu>
Received: by wilbur.njit.edu; Fri, 27 Nov 92 11:42:09 est
Date: Fri, 27 Nov 92 11:42:09 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: timbl@nxoc01.cern.ch
Subject: Re: The <PRE> tag
Cc: www-talk@nxoc01.cern.ch

I vote for <FIXED>, significant newlines (\n), and WIDTH=nn with 80 default.

The standard should explicitly discourage the use of <FIXED>, because of
the new line significance.  Its use should be researved for cases where
conversion to full html is impractical.

http://eies2.njit.edu:1234/man-p/manpage give no <p>s within <PRE>

I released the shell source for my experimental server in
ftp://wilbur.njit.edu/www/unix/htfiled.sh, it has man, man-p, and a local
directory browser-- in case anyone wants to play with it.

I fixed the reference http://eies2.njit.edu/rakesh/paper.html, but I need
to regererate it to get back equations and format the tables.  If anyone
has a converter for ms and mm documents it would save me some trouble.

jim

From weber@eitech.com  Mon Nov 30 18:00:12 1992
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03341; Mon, 30 Nov 92 18:00:12 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00620; Fri, 27 Nov 1992 19:48:03 +0100
Received: from kyle.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA13149; Fri, 27 Nov 92 10:46:33 PST
Date: Fri, 27 Nov 92 10:46:33 PST
From: weber@eitech.com (Jay C. Weber)
Message-Id: <9211271846.AA13149@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: an idea for integrating WWW and MIME
Cc: notemail-designers@eitech.com

I've been reading this list second hand for a while (could someone put me
on the list, please?), and I have an idea that bears on a number of recent
messages regarding WWW and MIME.  In summary, the idea is to add a new WWW
document access type that refers to sibling parts of a MIME multipart, and
in so doing

  o integrates the MIME typing mechanism into WWW  (as Dan has championed)
    while making a MIME reader do the work (e.g., without requiring that an
    html parser parse content-types, nor that it know what how to handle
    those types);

  o provides a bundling mechanism (as Dave has requested) so the various
    media pieces are part of a single "compound document";

  o suggests a variation where the media pieces are physically part of the
    document layout (instead of being a button push away and a separate
    window (as I think Dave also requested);

  o allows for recursive embedding to create larger structures (like Dave's
    "books");

  o supports typing on either end of the link;

  o relates the WWW (remote) document names to MIME message/external-body
    types.

Right, so enough hype.  These compound documents are MIME multipart objects
like the following:

  Content-type: multipart/x-presentation; boundary=foo

  --foo
  Content-type: text/html

  You know, <a HREF=part:id1> the world </a> is a funny place.

  --foo
  Content-ID: id1
  Content-type: image/gif
  Content-description: an image of a globe
  Content-transfer-description: base64

  JKLAHFKHKJHL53645NBDL3W45Y5KYKN...

  --foo

A multipart/x-presentation is like a multipart/mixed (and will be treated
as such in simple MIME readers), except that the first part defines the
layout of the presentation.  The interesting case for this crowd is when
that part is an html document with references to the remaining parts.  In
the above example, I've implemented a reference through a new document
access type called "part", which looks for a sibling in the multipart with
content-id "id1".  De-referencing that HREF cranks up the MIME reader
(e.g., metamail) on that part.

Using this bundling mechanism, multiple media types can appear in a single
document (the granularity of the web should be defined on conceptual
grounds, not media boundaries!).  But the referenced parts can be of type
text/x-html, providing a bundling mechanism for portions of the web --
which at least partly addresses Daves request for book structures.  Note
that the bundled parts can even be of type multipart/x-presentation, so one
can recursively intermix media and web bundling.

One can also imaging an alternative to anchors ("frames"?) where the
referenced object gets physically embedded in the layout of the text
(someone must have done this in SGML by now).  Format-wise this would be
almost identical to my example above, and you could mix the two.

Note that the typing information is not in the anchor, it's in the
referenced part.  Of course, you could allow typing in the anchor and have
it default or override the typing in the part, but it seems to me that in
general you want the typing at the destination. (I've probably touched on a
controversial point.)  This is more important in my next point.

So I mentioned a relation between document naming in WWW and
message/external-body types in MIME.  Suppose that instead of including the
GIF image in the above example, I had the following:

  --foo
  Content-ID: id1
  Content-type: message/external-body; access-type=anon-ftp;
     site=eitech.com; directory=/pub; file=globe.gif
  Content-description: pointer to picture of globe

  Content-type: image/gif
  
  --foo--

When the reference to id1 is dereferenced, the MIME reader would fetch the
file from the remote site.  (The second content-type acts as a default for
the file type, which can be overridden by typing information in the
destination.) Thus the "part" document access type, through MIME
interactions, can do remote references; one could view the anchor

  <a HREF=anon-ftp://eitech.com/pub/globe.gif TYPE=image/gif>

as a shorthand for anchor referencing the external-body (do WWW addresses
have an anon-ftp access type?  MIME external-body and WWW access type sets
are overlapping; they could be sync'ed).

I've gone way past the length limit for optimal readership :-), but I hope
many of you (especially Dave and Dan) have gotten all the way through.
Comments?

Jay
---------------------------------------------------------------------
Jay C. Weber					weber@eitech.com
Enterprise Integration Technologies		weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100			(415)617-8002
Palo Alto, CA 94301

From TONYJ@scs.slac.stanford.edu  Tue Dec  1 03:46:20 1992
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06036; Tue, 1 Dec 92 03:46:20 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25410; Tue, 1 Dec 1992 03:59:26 +0100
Date: Mon, 30 Nov 1992 18:59 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: quotes around tags and escape sequences
To: www-talk@nxoc01.cern.ch
Message-Id: <69FDBB0140801933@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.cern.ch"
X-Vms-Cc: TONYJ

Three questions, 

  1) If we now expect quotes around tags, are we still meant to understand % as
     an escape character within tags?

  2) Which of the following do I need to support, and which is the "approved"      
     method of accessing gopher?

         href="gopher://gopher.micro.umn.edu:70/00/Some Stuff"
     or
         href="gopher://gopher.micro.umn.edu:70/00/Some%20Stuff"
     or 
         href=gopher://gopher.micro.umn.edu:70/00/Some%20Stuff

  3) Is the % meant to act as an escape character in search strings? ie

         href="http://slacvm.slac.stanford.edu/FIND/PARTICLE?PI%nn"

     meant to find entries for PI+ ? (where nn is the ascii code for +).

Just wondering....Tony 

From jdanner@leland.stanford.edu  Tue Dec  1 04:14:48 1992
Return-Path: <jdanner@leland.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06134; Tue, 1 Dec 92 04:14:48 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25917; Tue, 1 Dec 1992 04:27:53 +0100
Received: from elaine22.Stanford.EDU by sunlight.Stanford.EDU (4.1/AIR-1.0)
	id AA23105; Mon, 30 Nov 92 19:27:50 PST
Date: Mon, 30 Nov 92 19:27:50 PST
From: jdanner@leland.stanford.edu
Message-Id: <9212010327.AA23105@sunlight.Stanford.EDU>
To: www-talk@nxoc01.cern.ch
Subject: MIME vs. HyTime

I claim no expertise on HyTime, but I believe the intent
is to allow multimedia data in an SGML DTD.  Given Dan's
current efforts to make HTML a true DTD, it seems like
HyTime tags might be an easier addition than incorporating
HTML as a MIME datatype.  Has anyone looked at HyTime vs.
MIME?  I guess I'm wondering about this for the mail world
as well, since there is already a great deal of commercial
interest in SGML-ifying all documents.

John Danner
Oracle Multimedia


From connolly@pixel.convex.com  Tue Dec  1 04:29:53 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06221; Tue, 1 Dec 92 04:29:53 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26213; Tue, 1 Dec 1992 04:42:58 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12672; Mon, 30 Nov 92 21:42:49 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06729; Mon, 30 Nov 92 21:42:48 -0600
Message-Id: <9212010342.AA06729@pixel.convex.com>
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: quotes around tags and escape sequences 
In-Reply-To: Your message of "Mon, 30 Nov 92 18:59:00 PDT."
             <69FDBB0140801933@SCS.SLAC.STANFORD.EDU> 
Date: Mon, 30 Nov 92 21:42:47 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Three questions, 
>
>  1) If we now expect quotes around tags, are we still meant to understand % as
>     an escape character within tags?

In short, I think so.

These dang things get parsed twice: once by the SGML parser, and once
by the URL parser.

After the HREF=, the SGML parser is looking for an attribute value,
which may be a token or a literal. The syntax of a URL conflicts with
the syntax of a token, so you've got to use a literal, i.e. you've
got to put quotes around it.

To compute the value of the HREF attribute, the SGML parser grabs
everything between ""s (or ''s, actually. In fact, it expands
&entity; references too!).

Then you hand the value of the HREF attribute to the URL parser.
It better be a legal URL at this point. I don't know if the URL
parsing code can handle spaces in a URL or not. If not, they've
got to be represented by the %nn construct.

NOTE: There's an SGML construct: &#SPACE; or &#123; designed for the same
purpose. We might want to remove the quoting mechanism from the
URL spec, and say that you use whatever quoting mechanisms the
enclosing data format requires.


>  2) Which of the following do I need to support, and which is the "approved"      
>     method of accessing gopher?
>
>         href="gopher://gopher.micro.umn.edu:70/00/Some Stuff"

This is legal SGML -- dunno if it's a legal URL.

>         href="gopher://gopher.micro.umn.edu:70/00/Some%20Stuff"

This is probably your best bet for the current linemode code.

>         href=gopher://gopher.micro.umn.edu:70/00/Some%20Stuff

SGML parsers won't grok this.

For starters, you've got kind of a bad design for handling SGML
attributes: you parse them twice: once to stick them in the param
resource, and once to take them out of the param resource and stick
them in the href and name resources.

Rather than a param resource, the parsing code should build an XtArglist
with the attribute names and values. Then it can just call XtSetValues
when it's done parsing the start tag. This would be a minor modification
to my current version of the MidasWWW code using my HTML parsing library.

>  3) Is the % meant to act as an escape character in search strings? ie
>
>         href="http://slacvm.slac.stanford.edu/FIND/PARTICLE?PI%nn"
>
>     meant to find entries for PI+ ? (where nn is the ascii code for +).

Yeah... I've got a bunch of questions like this one. My understanding
is that everything after the scheme: is defined by the individual scheme.
It's not safe to just replace %nn by the corresponding ASCII character
in all URLs. The %nn quoting mechanism is specific to the gopher scheme.
(It might be used by other schemes too, but it's not a universal mechanism.)

I've got some design ideas for the WWW library that I think would obviate
the need for implemntors like Tony to even mess with this stuff.

Details as the develop...

Tony: I'll send you my HTML parsing work separately.

Dan


From connolly@pixel.convex.com  Tue Dec  1 04:49:29 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06359; Tue, 1 Dec 92 04:49:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26534; Tue, 1 Dec 1992 05:02:34 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12833; Mon, 30 Nov 92 22:02:30 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06943; Mon, 30 Nov 92 22:02:29 -0600
Message-Id: <9212010402.AA06943@pixel.convex.com>
To: jdanner@leland.stanford.edu
Cc: www-talk@nxoc01.cern.ch
Subject: Re: MIME vs. HyTime 
In-Reply-To: Your message of "Mon, 30 Nov 92 19:27:50 PST."
             <9212010327.AA23105@sunlight.Stanford.EDU> 
Date: Mon, 30 Nov 92 22:02:29 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I claim no expertise on HyTime, but I believe the intent
>is to allow multimedia data in an SGML DTD.

Good point. I don't know as much about HyTime as I should
either. All I know is that it's complex and obscure enough
that I don't have a working knowledge of it after two
years of sniffing around the internet.

>  Given Dan's
>current efforts to make HTML a true DTD, it seems like
>HyTime tags might be an easier addition than incorporating
>HTML as a MIME datatype.

I'm almost sure that's not true. Incorporating HTML as
a MIME datatype is as easy as sending an email message
to the IETF. Now the interesting stuff: incorporating
the nifty features of MIME into WWW is anther story.
But I still think it's several orders of magnitude
easier than implementing a HyTime engine.

>  Has anyone looked at HyTime vs.
>MIME?

The relavence of HyTime to WWW isn't so much in the
realm of data formats (where MIME is key), as in
hyperlink semantics and addressing schemes.

HyTime architectural forms have immense expressive
power, but I gather they're pretty heavy to implement.
They do stuff like:

<LINK target=loc1>click here to see a film</LINK>

<FILM HyTime=FCS ID=loc1>REEL 100<START>100.23sec<STOP>134.56sec</FILM>

I don't have a firm grasp of how it all works, but most of
the link mechanisms involve cooking up some element that
describes referent data, and then using the id of that
element elsewhere in the document.

It would mean turning
<A HREF="http://info.cern.ch/hypertext/WWW/TheProject.html>Click here.</a>

into

<A HREF=loc2>Click Here.</a>

<RESOURCE ID=loc2><SCHEME>http<HOST>info.cern.ch<PATH>
	<ROOT>hypertext<COMPONENT>WWW<COMPONENT>TheProject.html</RESOURCE>

or something like that.

>  I guess I'm wondering about this for the mail world
>as well, since there is already a great deal of commercial
>interest in SGML-ifying all documents.

The purpose of SGML is interchange. It's a pretty painful
investment unless you want to exchange documents among
diverse systems at the source level. The WWW project
is paying the price, and I think it's working well.

So far, WWW is just for text, where SGML is sufficiently
epressive. SGML has hooks for the kind of multimedia
that WWW is about. HyTime is overkill for graphics and simple sounds,
IMHO.

If WWW ever involves complex multimedia documents, especially
documents where timing and event ordering is significant,
we might want to take another look at HyTime.

Dan


From emv@garnet.msen.com  Tue Dec  1 05:24:39 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06659; Tue, 1 Dec 92 05:24:39 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27104; Tue, 1 Dec 1992 05:37:44 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mwPMf-0000A7C@garnet.msen.com>; Mon, 30 Nov 92 23:37 WET
Message-Id: <m0mwPMf-0000A7C@garnet.msen.com>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>,
        www-talk@nxoc01.cern.ch
Subject: Re: quotes around tags and escape sequences 
In-Reply-To: Your message of Mon, 30 Nov 92 21:42:47.
             <9212010342.AA06729@pixel.convex.com> 
Date: Mon, 30 Nov 92 23:37:23 EST
From: Edward Vielmetti <emv@msen.com>

if we're double-quoting the
	
         href="gopher://gopher.micro.umn.edu:70/00/Some Stuff"

so there's no question where the beginning of the reference is and
where the end of the reference is, then I should think there's no
problem.

Really, though, the gopher reference is (in gopherspeak)

Name=An arbitrary, but meaningful name
Host=gopher.micro.umn.edu
Port=70
Type=0
Path=Some Stuff

And the "href=" is just a way to squash it down to a single string.
It could just as well be a set of attributes and not a single one.
E.g.

<a gopherhost="gopher.micro.umn.edu" 
   gopherport="70" 
   gopherpath="/Some Stuff" 
   gophertype="0">
An arbitrary, but meaningful, name</a>

expresses the meaning of what's going on in a way that's far closer to
how SGML might do it as far as I have been able to make out...Dan is
that actually legal SGML?

This being a general flaw of URL, really - the idea was to make short
strings that are printable, but as access methods get more complex a
set of attribute=value pairs may make things quite a bit easier, 
for parsing and quoting as well as mapping from one access class
(gopher links to telnet sites) to another (www native support for telnet).

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From connolly@pixel.convex.com  Tue Dec  1 07:22:38 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07119; Tue, 1 Dec 92 07:22:38 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28928; Tue, 1 Dec 1992 07:35:43 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA15228; Tue, 1 Dec 92 00:35:25 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23999; Tue, 1 Dec 92 00:35:22 -0600
Message-Id: <9212010635.AA23999@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>,
        www-talk@nxoc01.cern.ch
Subject: Global HyperLinks was: quotes around tags and escape sequences 
In-Reply-To: Your message of "Mon, 30 Nov 92 23:37:23 EST."
             <m0mwPMf-0000A7C@garnet.msen.com> 
Date: Tue, 01 Dec 92 00:35:22 CST
From: Dan Connolly <connolly@pixel.convex.com>


OK, now you're asking for it. I've been mulling this
stuff over in my head for a couple weeks, and I've got some
pretty good ideas as to how it all fits together.

My model of global hypermedia includes the following terms:

Entity -- SGML and MIME use this term. WAIS calls it a document.
	Gopher calls it an item or a textfile or something.
	WWW used to call it a document, and now calls it
	a resource.

	The meaning is the same in all of them: a unit
	of retrieval [from the URL document].

Content-Type -- MIME coined this term. SGML calls it a NOTATION.
		WAIS used to call it :type, but they'll call
		it :content-type if they follow up on what they
		told me. Most gopher types fall under this scheme
		(telnet, cso, and other types that don't use gopher
		protocol don't fit)

Reference -- This is the WWW anchor, the Gopher Menu item, the WAIS
	:document-id structure, The MIME message/external-body. It is
	enough information to 1) decide whether to retrieve the entity,
	2) perform the retrieval transaction, and 3) process the entity
	once you've got it.

>Really, though, the gopher reference is (in gopherspeak)
>
>Name=An arbitrary, but meaningful name
>Host=gopher.micro.umn.edu
>Port=70
>Type=0
>Path=Some Stuff

NOTE: Some Stuff is terminated by a newline, and may not contain tabs.

>And the "href=" is just a way to squash it down to a single string.
>It could just as well be a set of attributes and not a single one.
>E.g.
>
><a gopherhost="gopher.micro.umn.edu" 
>   gopherport="70" 
>   gopherpath="/Some Stuff" 
>   gophertype="0">
>An arbitrary, but meaningful, name</a>

NOTE: for type 7 items, you need gophersearch="terms" too.

>expresses the meaning of what's going on in a way that's far closer to
>how SGML might do it as far as I have been able to make out...Dan is
>that actually legal SGML?

Sure, that's legal. I suggested that URLs be expressed in SGML a long
time ago. Tim said it was overkill, and I'm starting to agree.

Let's take a closer look at references:

1) What features allow users and clients to decide to retrieve an entity:

WWW	context and content of the anchor (Is it relevant?)

MIME	content-id (do I have this entity cached already?)
	content-description (relevant?)
	content-type (can I process it once I've got it?)
	SIZE (is it too big to bother?)

WAIS	:score (relavent to my query?)
	:headline (relevant?)
	:doc-id (in cache?)
	 original/distributor-server,database,local-id particularly useful
	:number-of-lines, :number-of-bytes (too big?)
	:type, :content-type (can I process it?)
	:date (how old is it?)

Gopher	name (is it interesting?)
	type (can I process it?)

2) What features allow the client to make the transfer?

WWW	URL -- protocol, host, port, path, type, size, search terms
	handles local files, HTTP, gopher, WAIS connections.
	includes search terms for fulltext indexes.
	scheme mechanism allows gateways to new protocols

MIME	access-type, etc.: handles ftp, anon-ftp, local-file
	Ghost body allows arbitrary extra data.

Gopher	host, port, path, search words

WAIS	source (host, port, database), doc-id, search terms,
	relavent documents (these are the novel feature. Quite handy)

3) What features allow the client to process the entity?
(Keep in mind that these are features of the reference -- this
is information we have _before_ we transfer the entity).

WWW	processing is tied to the protocol. Content-Type
	of local files is inferred from file extensions.

	Entities from HTTP connections are assumed to
	be text/x-html.

	Gopher entites are typed: 0=text/plain, 1=application/x-gopher,
	w=text/x-html.

	WAIS entites are typed: TEXT=text/plain, WSRC=application/x-wais.

MIME	content-type mechanism is quite expressive. Any content-type
	can be encapsulated in a message/rfc822 entity. Multiple
	entities can be encapsulated in a multipart/mixed entity.

Gopher	gopher type tells you what to do with the data.
	text/plain, application/x-gopher are universally supported.
	other types are supported by pilot projects.

WAIS	:type tells what to do. text/plain and application/x-wsrc are
	supported. Other types are supported by pilot projects.


Now let's see how we should change the WWW reference mechanism.

Here's what we've got currently:

<!ELEMENT A	- -  (#PCDATA)>
<!ATTLIST A
	NAME ID #IMPLIED
	HREF CDATA #IMPLIED
	TYPE CDATA #IMPLIED
	>

What's the TYPE used for? It's not a data type. There's some
code in LineMode to handle it, but I'm not sure what it does.

The NAME identifies the anchor as the target of some other anchor.
We should have NAME (or ID) attributes on pretty much all elements,
for example:

<DL>
<DT ID=term>term<DD>definition
</DL>

The HREF attribute is enough information to retrieve and Entity.
Good. But it's got thie #anchor stuck on the end. That should
be a separate attribute. It should be an IDREF, so that we
can validate that it references an existing ID with an SGML
parser.

"But," you say, "what if it references an ID outside the current document?"

I suggest we treat a group of nodes that reference each other not
as separate documents, but as entities of one big document. That
way, an author can validate the internal links in his/her web.

I suggest two new elements: XREF, for intra-document links (i.e.
links within the local web), and SEE for inter-document links
(i.e. links that go outside the local web).

<!ELEMENT XREF - - (#PCDATA)
 -- This element is for links within an HTML document. (a document
    is a collection of entities, or a web of nodes).
 -->
<!ATTLIST XREF
	CONTEXT CDATA #IMPLIED -- entity containing the XREF is implied --
	-- SGML purists would make this attribute an ENTITY reference,
	   and put the URL in the SYSTEM identifier in the prologue.
	   For expediency, we put the URL right in the attribute.
	--
	ORIGIN CDATA #IMPLIED
	-- another URL, used as an identifier, rather than a locator.
	   Ala the WAIS original-server,database,local-id triple.
	--
	REF IDREF #REQUIRED  -- ID of referent element --
	>

<!ELEMENT SEE - - (#PCDATA)
 -- This element is for links from an HTML document to any entity
    in the global web. The location and content-type of the entity
    are sufficient to resolve the reference.

    The other attributes could be specified in the text of the
    SEE content, but by making them attributes, the client software
    can process them, for example, to display a table of references
    sorted by date.
 -->
<!ATTLIST SEE
	LOCATION CDATA #REQUIRED -- URL of referent entity --
	CONTENT-TYPE CDATA #REQUIRED -- MIME Content-Type for the entity --
	CHUNK CDATA #IMPLIED
	-- This is the analogue of the #anchor mechanism.
	   If CONTEXT is an SGML entity, this would be an ID,
	   though it won't be validated.
	   However, if CONTEXT is a text file, this could be a line number.
	   The meaning is defined by the content-type.
	--
	ORIGIN CDATA #IMPLIED
	FROM CDATA #IMPLIED -- email address or name of author/provider --
	DATE NUMBER #IMPLIED -- in ISO format: YYYYMMDDHHMMSSZ --
	BYTES NUMBER #IMPLIED -- useful in many cases --
	MD5 CDATA #IMPLIED -- data signature --
	>

What do you think?

Dan


From timbl@www3.cern.ch  Tue Dec  1 16:33:03 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00861; Tue, 1 Dec 92 16:33:03 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21551; Tue, 1 Dec 1992 16:46:11 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01877; Tue, 1 Dec 92 16:41:19 +0100
Date: Tue, 1 Dec 92 16:41:19 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212011541.AA01877@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: jim@wilbur.njit.edu (Jim Whitescarver)
Subject: Re: The <PRE> tag
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


Perhaps we should have all three.

<FIXED>		newlines not significant 	anchors		PCDATA

<PRE>		newlines significant		no anchors	RCDATA

<XMP>		newlines significant		no anchors	CDATA

I understand that these are the only SGML-conformant combinations.  Is this too  
much of a mess?

Tony, can you make a similar patch for <fixed> as above for Midas?

I have put Dan's new spec (which contains <typewriter> -- what's going on,  
Dan?!) in the web at  
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/MarkUp.html with a link from  
the current spec.  The DTD was not in the tar file, so Dan's previous one is  
linked in. This includes all Dan's test HTML.

I would like to include <HEADER> and <BODY> tags too.

	Tim

From timbl@www3.cern.ch  Tue Dec  1 16:44:31 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00977; Tue, 1 Dec 92 16:44:31 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26953; Tue, 1 Dec 1992 16:57:39 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01907; Tue, 1 Dec 92 16:52:50 +0100
Date: Tue, 1 Dec 92 16:52:50 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212011552.AA01907@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Lets keep the web together
Reply-To: timbl@nxoc01.cern.ch


- CERN distributes a WWW protocol/parser library.
- Tony Johnson is extending the MidasWWW code the other protocols.
- Dave Ragget is writing a completely new browser.
- Jim WhiteScarver is "going beyond the scope of WWW".
- So are lots of others.
- Dan Connolly is writing a definitive HTML engine for the new spec,
- Dan was also making a parallel version of Midas.
- At CERN, somone (else) is making a modified viola,
- Pei Wei works on a new Viola with completely new parts.

This is all great, except for two things: consistency and support.

Getting the protocol code and parsing code right and tracking bugs and external  
changes will be some work, I feel that it is important that we do end up with  
common code.

I know what it is like to have to maintain code on lots of platforms.
You have to write the code specially. There are W3 code style guidelines in the  
web which say what we found out to be necessary.  It's a pain. Noone is going  
to support 8 parsers on 12 platforms.

I am therefore a little worried about the proliferation of implementations.
(I know, I'm rather pleased about it too! :-) I would like to see one or maybe  
two definitive libraries around (two, so to test the first one for  
self-consistent bugs), but not four. I feel that if there are too many, then  
there will be cases of little things which work on one but not on the others,  
because there is not enough support effort for each. And we want to keep the  
quality high, in terms of reliability, conformance, and portability.
The smarts are all very well. So could I encourage everyone with a bit of  
motherhood and apple pie.

If you are thinking of a smart extra to EITHER HTTP or HTML then please define  
it and discuss it here on www-talk.  Don't try just to get it out before the  
next guy. He is probably doing it too, a different way, and theese are all  
exciting ideas which benefit from being hacked around on the net.

When the idea has come out, we can put it into a tentative "future" spec
for comment and everyone can work from it.

There is more than plenty of work for everyone out there!  With all this drive  
we are going to accomplish some incredible things over then next few months.
We don't need to be over-competitive, and we need to try to get things right  
first time.

Jim's comment system is neat, and I'd like to adopt it here too.

Tim

From marca@wintermute.ncsa.uiuc.edu  Tue Dec  1 18:11:11 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01523; Tue, 1 Dec 92 18:11:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18677; Tue, 1 Dec 1992 18:24:18 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24870
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 1 Dec 92 11:24:14 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA22449; Tue, 1 Dec 92 11:25:27 -0800
Date: Tue, 1 Dec 92 11:25:27 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212011925.AA22449@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: NCSA http server

I'm running an experimental HTTP server at NCSA -- it's entirely a
prototype and none of the information on it should be taken to be
official or serious or any way that might get me in trouble.

        http://hoohoo.ncsa.uiuc.edu:80/

It's a hacked server and it will become more hacked in the future; if
you find it doesn't work, send me a nice mail message because I may
not realize that I broke something.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From connolly@pixel.convex.com  Tue Dec  1 18:28:35 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01687; Tue, 1 Dec 92 18:28:35 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23023; Tue, 1 Dec 1992 18:41:41 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA13710; Tue, 1 Dec 92 11:41:38 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA22962; Tue, 1 Dec 92 11:41:34 -0600
Message-Id: <9212011741.AA22962@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: jim@wilbur.njit.edu (Jim Whitescarver), www-talk@nxoc01.cern.ch
Subject: Re: The <PRE> tag 
In-Reply-To: Your message of "Tue, 01 Dec 92 16:41:19 +0100."
             <9212011541.AA01877@www3.cern.ch> 
Date: Tue, 01 Dec 92 11:41:34 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Perhaps we should have all three.

>I understand that these are the only SGML-conformant combinations.  Is
>this too much of a mess?

I think so. The processing should be broken into two parts: SGML parsing,
and application processing. The significance of newlines is an application
issue: the SGML parser never throws out newlines in data (it does throw
out newlines between tags and in some other places that I don't fully
understand).

These are the choices for SGML parsing:

	CDATA		all characters treated as data.
			Terminated by </A where A is any letter.
	RCDATA		characters and entities only. &entity; recognized.
			Terminated by </A as above
	mixed content	tags and #PCDATA.
			Tags, entity references, comments, etc. recognized.
			The pattern of tags and data is regulated
			by the element declaration.
	element content	tags only. Pattern of tags is regulated.
	ANY		like mixed content, but tags aren't regulated

CDATA is simplest to process, but you can't do things like

	char* any_string;
	printf("<XMP>%s</XMP>", any_string);

because any_string might contain </A, and you're screwed.

RCDATA is capable of the above construct, but at a cost:

	char* any_string;
	char* rcdata = HTML_replace_specials(any_string);
	printf("<XMP>%s</XMP>", rcdata);
	free(rcdata);

where HTML_replace_specials changes '<' to &lt; (to prevent </A), '>' to &gt;
(to prevent ]]>, the marked-section close delimiter. Ugh!), and
'&' to &amp; (to prevent &xxx from being mistaken for an entity reference).

But if you're going to go to that trouble, you might as well
use mixed content. That's why I changed my mind about using RCDATA
for XMP and LISTING elements.

My current DTD only uses element content (for the HTML document element*),
CDATA (for XMP and LISTING) and mixed content (for everything else).

As to your suggestions...

><XMP>		newlines significant		no anchors	CDATA

This is already supported, except that most implementations don't
quite parse CDATA correctly. The "newlines significant" isn't a
parsing issue. It's an issue of how the application processes character
data. Let's call this mode of application processing where the
characters are written to the screen as-is, rather than
typeset into paragraphs TYPEWRITER mode. We'll call the default TYPESET mode.

><PRE>		newlines significant		no anchors	RCDATA

The only implementation of the PRE tag that I know of looks more like:

<PRE>		newlines significant		anchors		PCDATA

It's actually pretty clean: you use
mixed content SGML parsing, and TYPEWRITER application processing.
So I changed the name to TYPEWRITER, for no good reason, really.

The newlines significant/no anchors/RCDATA is what I suggested for
XMP and LISTING, so they could contain any string. But since current
implementations don't process entities in these elements, it's
not worth it.

><FIXED>		newlines not significant 	anchors		PCDATA

This introduces a third application mode besides RAW and TYPESET:
it's kinda like RAW, but you toss the newlines, and start a newline
at every <P> tag. I don't like it.

>Tony, can you make a similar patch for <fixed> as above for Midas?

You could, but it doesn't fit neatly into the current architecture.
Tony wrote one widget to do TYPESET processing (SGMLCompoundText)
and one to do TYPEWRITER processing (SGMLPlainText). The FIXED
widget calls for a new widget, or a modification of SGMLPlainText
to ignore newlines in some cases. (You can't just use the SGMLCompoundText
with a fixed-width font, because it compresses whitespace.)

>I have put Dan's new spec (which contains <typewriter> -- what's going on,  
>Dan?!) in the web at  
>http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/MarkUp.html with a link from
>the current spec.

Thanks.

>  The DTD was not in the tar file, so Dan's previous one is  
>linked in. This includes all Dan's test HTML.

Ack! I think the DTD is pretty important. I'll get the new
one there ASAP. I highly suggest that _all_ data providers grab the DTD
and the sgmls parser and try validating samples of the data they're
serving up. It's the quickest and surest way to check for compliance.
I need to write a section for data providers in the spec.

>I would like to include <HEADER> and <BODY> tags too.

* I wrestled with this at great length to come up with a DTD
lends _some_ structure to HTML wihthout clashing badly with
existing data.

The document element declaration is:
<!ELEMENT HTML O O  ((TITLE? & NEXTID? & ISINDEX?), BODY)>

The O O means the HTML start and end tags can be omitted.
They'll be inferred by the parser. Since there's no #PCDATA
in the content model, it has element content, so that
whitespace between tags is thrown out.

The TITLE, NEXTID, and ISINDEX can come in any order, and
they can are optional, but they can appear at most once,
and they have to be before the BODY.

I made the <BODY> tags minimizable so current
HTML is legal. I couldn't seem to work in a HEADER
element the same way.

Dan


From connolly@pixel.convex.com  Tue Dec  1 18:51:52 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01941; Tue, 1 Dec 92 18:51:52 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27242; Tue, 1 Dec 1992 19:04:56 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA14593; Tue, 1 Dec 92 12:04:53 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA24775; Tue, 1 Dec 92 12:04:52 -0600
Message-Id: <9212011804.AA24775@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Lets keep the web together 
In-Reply-To: Your message of "Tue, 01 Dec 92 16:52:50 +0100."
             <9212011552.AA01907@www3.cern.ch> 
Date: Tue, 01 Dec 92 12:04:51 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Getting the protocol code and parsing code right and tracking bugs and external
>changes will be some work, I feel that it is important that we do end up with 
>common code.
>
>I know what it is like to have to maintain code on lots of platforms.
>You have to write the code specially. There are W3 code style guidelines in the
>web which say what we found out to be necessary.  It's a pain. Noone is going
>to support 8 parsers on 12 platforms.
>
>I am therefore a little worried about the proliferation of implementations.
>(I know, I'm rather pleased about it too! :-) I would like to see one or maybe
>two definitive libraries around (two, so to test the first one for  
>self-consistent bugs), but not four. I feel that if there are too many, then  
>there will be cases of little things which work on one but not on the others, 
>because there is not enough support effort for each. And we want to keep the  
>quality high, in terms of reliability, conformance, and portability.

Well said. With this in mind, I'd like to take issue with the state
of libWWW:

You can't use any of the parts without using the whole
thing: you can't use the parser unless you use the HText
data structures, including the HTMainText global variable!

The Gopher processing is intertwingled with everything else too.
There should be a GopherOpen() routine, for establishing
a gopher connection and handling seletors and searches, and a GopherMenu()
routine, that handles application/x-gopher entities just
like text/plain and text/x-html entities are currently handled.

Similarly, there should be an FTPOpen, LocalFileOpen, HTTPOpen,
etc routines with an easy way to plug in a WAISOpen routine
when somebody gets around to it.

I should be able to add MIMEMessage(), MIMEMultipart(), PostScript(),
etc. format handling routines alongside the text/html and text/plain
routines.

There is *no reason* for the NOARGS, ARGS1, ARGS2, etc. macros.
You just use the PARAMS() macro in the header, and use K&R style
in the .c file. The only place where this doesn't work is
with varargs foo.

There are #ifdefs for VAX, unix, and ThinkC all over the place.
I'm sure these could be localized.

This is why Tony Johnson started from scratch, and why other
implementors will do the same.

>If you are thinking of a smart extra to EITHER HTTP or HTML then please define
>it and discuss it here on www-talk.  Don't try just to get it out before the  
>next guy. He is probably doing it too, a different way, and theese are all  
>exciting ideas which benefit from being hacked around on the net.
>
>When the idea has come out, we can put it into a tentative "future" spec
>for comment and everyone can work from it.

Again, we see the need for a CSCW platform.

I think that if we archived the www-talk mailing list, and built
an HTTP server that would serve the articles up with hypertext
links between folloups etc, it would be a good start.

If I code up a server in perl that can do this, will somebody
provide disk space and network access?

Dan


From marca@wintermute.ncsa.uiuc.edu  Tue Dec  1 19:01:25 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01993; Tue, 1 Dec 92 19:01:25 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29024; Tue, 1 Dec 1992 19:14:31 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28320
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 1 Dec 92 12:14:29 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:timbl@nxoc01.cern.ch id AA22660; Tue, 1 Dec 92 12:15:42 -0800
Date: Tue, 1 Dec 92 12:15:42 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212012015.AA22660@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: Lets keep the web together 
In-Reply-To: <9212011804.AA24775@pixel.convex.com>
References: <9212011552.AA01907@www3.cern.ch>
	<9212011804.AA24775@pixel.convex.com>

Dan Connolly writes:
> You can't use any of the parts without using the whole thing: you
> can't use the parser unless you use the HText data structures,
> including the HTMainText global variable! [...]

I have to agree with this as a negative assessment.  Trying to figure
out how to deal with the library hasn't been very much fun.

> Again, we see the need for a CSCW platform.

Well, for what it's worth, the server running on
hoohoo.ncsa.uiuc.edu:80 will accept the ANNOTATE command as proposed
in a previous message of mine, and I can send the patches to enable
this (as well as modify the linemode browser and library to provide
annotation functionality) to anyone who wants them.  A more complex
system is certainly desirable, though.

> I think that if we archived the www-talk mailing list, and built an
> HTTP server that would serve the articles up with hypertext links
> between folloups etc, it would be a good start.
> 
> If I code up a server in perl that can do this, will somebody
> provide disk space and network access?

I would, but it already exists:

        http://eies2.njit.edu:80/wmail.html

Dan, if you want to do a mailing list archive also, contact me and
we'll set it up...

Marc


From raisch@cthulhu.control.com  Tue Dec  1 19:49:40 1992
Return-Path: <raisch@cthulhu.control.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02300; Tue, 1 Dec 92 19:49:40 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05835; Tue, 1 Dec 1992 20:02:46 +0100
Received: by control.com (4.1/Spike-2.0)
	id AA01217; Tue, 1 Dec 92 14:00:41 EST
Date: Tue, 1 Dec 1992 13:54:43 -0500 (EST)
From: Robert Raisch <raisch@cthulhu.control.com>
Subject: Re: Lets keep the web together 
To: Dan Connolly <connolly@pixel.convex.com>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
In-Reply-To: <9212011804.AA24775@pixel.convex.com>
Message-Id: <Pine.3.03.9212011343.K24748-b100000@cthulhu.control.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 1 Dec 1992, Dan Connolly wrote:

> Well said. With this in mind, I'd like to take issue with the state
> of libWWW:
> 
> You can't use any of the parts without using the whole
> thing: you can't use the parser unless you use the HText
> data structures, including the HTMainText global variable!
> 
> The Gopher processing is intertwingled with everything else too.
> There should be a GopherOpen() routine, for establishing
> a gopher connection and handling seletors and searches, and a GopherMenu()
> routine, that handles application/x-gopher entities just
> like text/plain and text/x-html entities are currently handled.

	ABSOLUTELY!

	I do not wish to denigrate two marvelous tools and the
considerable effort which went into them, but from a software support and
development environment, both approaches leave MUCH to be desired. 

	I believe that it is high time we took a very hard look at the
future of WWW and gopher, and retooled them to fulfill the role that they
seem to be headed towards.

	We are talking about tools which represent the future of the
Global Internet.  They should be developed with a keen awareness of
modularity, useability, portability and supportability.

	I'd be willing to participate in such an effort, but lack the time
to coordinate it.

> I should be able to add MIMEMessage(), MIMEMultipart(), PostScript(),
> etc. format handling routines alongside the text/html and text/plain
> routines.

	Oh bliss! Oh joy!  Would that it were so.  <sigh>

-- </rr>
As a matter of conscience, I will no longer support any business in Colorado.



From emv@garnet.msen.com  Tue Dec  1 20:50:13 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02821; Tue, 1 Dec 92 20:50:13 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14217; Tue, 1 Dec 1992 21:03:20 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mwdoU-0000AOC@garnet.msen.com>; Tue, 1 Dec 92 15:03 WET
Message-Id: <m0mwdoU-0000AOC@garnet.msen.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: NCSA http server 
In-Reply-To: Your message of Tue, 01 Dec 92 11:25:27.
             <9212011925.AA22449@wintermute.ncsa.uiuc.edu> 
Date: Tue, 01 Dec 92 15:03:04 EST
From: Edward Vielmetti <emv@msen.com>

i like the "back to top" stuff at the bottom of the 'x collage' menus!
didn't feel like i was getting lost there at all.

--Ed

From marca@wintermute.ncsa.uiuc.edu  Tue Dec  1 23:18:53 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03658; Tue, 1 Dec 92 23:18:53 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05693; Tue, 1 Dec 1992 23:32:01 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16039
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 1 Dec 92 16:31:59 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA23439; Tue, 1 Dec 92 16:33:13 -0800
Date: Tue, 1 Dec 92 16:33:13 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212020033.AA23439@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: question on databases

This is a slightly incongruous forum for this question, but then
again, not really, since if I get an answer then we can release some
interesting networked information system software that otherwise
wouldn't be made available.... so:

Is there a free relational database that understands SQL that is
available on the net?

Thanks,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From fine@cis.ohio-state.edu  Wed Dec  2 01:44:09 1992
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04342; Wed, 2 Dec 92 01:44:09 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22811; Wed, 2 Dec 1992 01:57:17 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA18034; Tue, 1 Dec 92 19:57:14 -0500
Date: Tue, 1 Dec 92 19:57:14 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9212020057.AA18034@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Ideas for the future
X-Mailer: Perl Mail System v1.1


Idea 1.  HTML  (Just a nice feature)
------------------------------------

I'd like to be able to PUT files onto remote sites.

The idea is, that documents might be maintained by people at different
sites.  As it is, they have to coordinate updates through email, and it's
generally a pain.  What you'd want is to just connect, get the docuement,
edit it, and put it back.  (Ideally, you'd have an editor built into your
browser to do this, but that's another problem.)

(BTW, Is the only proposed new HTTP stuff in
 http://info.cern.ch/hypertext/WWW/Protocols/HTTP.html ?  I couldn't find
 anything mentioning either disconnection or end of document in that proposal)

PUT docuement
  If you don't have permission -> Permission Denied
  If the file already exists, and you don't have a lock -> Document not locked
  Otherwise, the server would return READY, the client would send the
    data, unlock the file (if locked), and disconnect.

LOCK document
  If you don't have permission -> Permission Denied
  If the file doesn't exist -> No such document
  If the file is already locked -> Document already locked
  Otherwise the server marks the document as locked, and returns a copy to you.

If you want to keep the server stateless, then you can't store lock
information.  This means you have to do the LOCK and the PUT in the same
connection.  This has the advantage that you can't possibly have stale
locks - if the connection dies, the lock is automatically deleted.  But
you can no longer rely on a disconnect to mean end of document.  You'd
have to make another addition to the protocol - the response from the server
would have to include the size of the document about to be transmitted.
The other disadvantage to this is that editing may take a while -

On the other hand, if you are willing to make the server stateful, then
you could still rely on disconnect to mark end of document, in the case of
PUT the disconnect would come from the client.  Of course, with a stateful
server, you'd have to expire the locks after a couple of days, in case some
bozo forgot that he started to edit something.

Note that this will also gunk up your config file with access control stuff,
especially if you want to selectively control write access.

This could potentially be useful for setting up free areas where anyone
can document anything they like - we hope to set an area up like this here
for local use, just to see if anything develops from it (but we still need
a good editor).

Also, this might make a useful way to discuss things like this - rather than
responding to my article, you could just add anchors to it in appropriate
places that point to your response(s).

Idea 2.  HTML/HTTP  (something I think is needed)
-------------------------------------------------

When you get lots of good documentation into WWW, there's going to need
to be some guarentee of access to that information.  The best way to
do that is with multiple servers.  From an HTTP standpoint, that only
requires another attribute (or list of attributes if > 2 sites) be added
for fallbacks:

<A NAME=id1 HREF=//info.cern.ch/hypertext/ImportantDocument
     FALLBACK=//www.cis.ohio-state.edu/hypertext/ImportantDocument> ... </A>

or you could add numbered HREFS, or call them IREF, JREF, etc. :-), doesn't
matter. (Or can you even have multiple attributes with the same identifier?)

I see this being used in two different ways.  In the first, a single site
would run servers on more than one machine, in case one goes down.  The
physical data would all be on the same disk(s), but mounted on both machines.
In the second, different sites would provide mirroring of information,
for instance, Ohio State would GET all of cerns documents and store them
locally, and cern would include references to ohio state.

This looks like it might complicate things if we have implemented LOCK
in the protocol.  In the second case, no problem.  Cern is the master,
Ohio State just picks things up from cern.  In the first case, we can
solve the problem similarly - configure one server to allow editing, and
one to be read only.  Then if the main server goes down, you have no
editing capability but you can still view the data.

Lastly, a good idea even if you don't implement multiple servers:  ping the
site before you connect.

Idea 3.  Documents
------------------

Once we get things more settled, a good showcase for this system, and
one that would really sell "The Net" on it, would be to convert all of
the newsgroup FAQs to html documentation.  This wouldn't exactly be a
trivial task (perhaps we could recruit some FAQ maintainers to help)
but it would be of enormous value.  We could start on it now, and have
it ready together with the software.

      tom


From connolly@pixel.convex.com  Wed Dec  2 03:09:11 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05557; Wed, 2 Dec 92 03:09:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03629; Wed, 2 Dec 1992 03:22:20 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09445; Tue, 1 Dec 92 20:22:17 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA20569; Tue, 1 Dec 92 20:22:15 -0600
Message-Id: <9212020222.AA20569@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML providers: please grab sgmls and the DTD
Date: Tue, 01 Dec 92 20:22:15 CST
From: Dan Connolly <connolly@pixel.convex.com>

Tim,

I noticed you've been diddling with the HTML files
on info.cern.ch -- quoted your attributes, dotted
your i's and crossed your t's, so to speak.

But the files still don't fit into SGML.

Please: grab the sgmls-0.8.tar ... wait! there's a 1.0!
on ifi.uio.no in /pub/SGML/SGMLS. I have experience
with the sgmls-0.8.tar.Z -- I know it builds and runs
like a champ. I'll have to check the 1.0 version out.

Then check a few of your files by doing

% sgmls -s html.dtd yourfile.html

If you get errors, either fix your software or
diddle with the DTD until you get something that
works. Even if the official HTML dtd is never
modified to match your data, you'll have _some_
SGML DTD that specifies what you produce.

A word of warning: there's a rule-of-thumb everybody
ought to follow in writing DTD's: only used mixed
content for repeatable-or groups. That is, if you've
got an element that can contain a mixture of PCDATA
and elements, don't impose any special order on
the elements.

For example: I wanted to do this:

<!ELEMENT HTML - - ((TITLE? & ISINDEX?), (H1|H2|DL|OL|XMP|#PCDATA)+)>

But then the HTML element would have mixed content (see
the TITLE, H1, elements along with #PCDATA). The problem
is that if you write:

<TITLE>foo</title>
<ISINDEX>
<h1>a header</h1>
some data...

The newline after </title> is treated as PCDATA, which is not
allowed before ISINDEX. The options you're left with are:

1. Watch out where you put newlines (we hate this.)

2. Use a repeatable-or group, like this:
<!ELEMENT HTML - - (TITLE | ISINDEX | H1|H2|DL|OL|XMP|#PCDATA)*>
Then all your structure is gone (TITLES are allowed anywhere...).

3. Only use element content (move the #PCDATA out
	of the HTML element) like this:
<!ELEMENT HTML - - ((TITLE? & ISINDEX?), BODY>
<!ELEMENT BODY - - (H1|H2|DL|OL|XMP|#PCDATA)+)>
This is what I did.

[Notice that these tags are minimizable,
so that existing HTML documents that don't have them are
still legal. This was perhaps a bad idea. For example, I
had to hack the BODY model group badly to get the desired
effect.]

I've wrestled quite a bit with the header/body thing, and
I can't seem to come up with a DTD that 1) makes most existing
HTML legal, and 2) imposes _any_ structure on the thing.

I'm just about to give up on the structure business. Do any
implementations have problems with <TITLE> elements in
the middle of the document? If not, I can just change the
DTD so that HTML is just "tag soup" -- anything goes anywhere.

Another idea is to move the TITLE and other header
info outside the HTML format and MIME messages for
HTTP transport, so that

<TITLE>the title</TITLE>
<h1>the header</h1>
... the text...

becomes

Subject: the title
Content-type: text/x-html

<h1>the header</h1>

The header information would be part of the protocol, and
not part of the HTML data. Local files would get their
header information from the filesystem. WAIS documents
would get their header information from the :document
structure.

Anyway... get the sgmls parser and validate the data
you provide! I'd like to have more folks than just
me bumping up against the SGML issues.

Dan


From connolly@pixel.convex.com  Wed Dec  2 03:18:35 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05780; Wed, 2 Dec 92 03:18:35 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05355; Wed, 2 Dec 1992 03:31:44 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09612; Tue, 1 Dec 92 20:31:41 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA20968; Tue, 1 Dec 92 20:31:39 -0600
Message-Id: <9212020231.AA20968@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Ideas for the future 
In-Reply-To: Your message of "Tue, 01 Dec 92 19:57:14 EST."
             <9212020057.AA18034@soccer.cis.ohio-state.edu> 
Date: Tue, 01 Dec 92 20:31:39 CST
From: Dan Connolly <connolly@pixel.convex.com>


Has anybody else noticed how much HTTP is starting to
look like NNTP? I think NNTP does most of what we need,
especially when restricted to nntpd's xfer mode -- then
it's stateless.

* it's a distributed database
* with MIME, it's multimedia
* it works.
* it's telnet-based, and easy to mess with.

Wouldn't it be nice to be able to send NEWNEWS commands
to a hypertext server?

Just a thought...

By the way... see RFC977 (ftp://nnsc.nsf.net/rfc/rfc977.txt)
for the whole story.

Dan


From marca@wintermute.ncsa.uiuc.edu  Wed Dec  2 03:21:52 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05835; Wed, 2 Dec 92 03:21:52 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05433; Wed, 2 Dec 1992 03:35:01 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA27675
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 1 Dec 92 20:34:59 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA24215; Tue, 1 Dec 92 20:36:09 -0800
Date: Tue, 1 Dec 92 20:36:09 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212020436.AA24215@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: HTML providers: please grab sgmls and the DTD
In-Reply-To: <9212020222.AA20569@pixel.convex.com>
References: <9212020222.AA20569@pixel.convex.com>

Dan Connolly writes:
> I noticed you've been diddling with the HTML files
> on info.cern.ch -- quoted your attributes, dotted
> your i's and crossed your t's, so to speak.
> 
> But the files still don't fit into SGML.

Can you expand on this a little more?  Specifically what is he doing
that isn't good?

Marc


From connolly@pixel.convex.com  Wed Dec  2 03:29:19 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05970; Wed, 2 Dec 92 03:29:19 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06962; Wed, 2 Dec 1992 03:42:28 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09725; Tue, 1 Dec 92 20:42:25 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA21137; Tue, 1 Dec 92 20:42:24 -0600
Message-Id: <9212020242.AA21137@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML providers: please grab sgmls and the DTD 
In-Reply-To: Your message of "Tue, 01 Dec 92 20:36:09 PST."
             <9212020436.AA24215@wintermute.ncsa.uiuc.edu> 
Date: Tue, 01 Dec 92 20:42:24 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Dan Connolly writes:
>> I noticed you've been diddling with the HTML files
>> on info.cern.ch -- quoted your attributes, dotted
>> your i's and crossed your t's, so to speak.
>> 
>> But the files still don't fit into SGML.
>
>Can you expand on this a little more?  Specifically what is he doing
>that isn't good?

I misspoke: the files he's generating are now to
the point where they can be described by some DTD,
just not the one I suggested.

Mostly he's added <HEADER> and <BODY> tags and quoted
his HREFs.

But, for example, he's still putting numbers in the
NAME attribute of anchors. I wanted to use SGML
ids, which are guaranteed to be distinct per
anchor (modulo case of letters). But they
must start with a letter.

You can change the DTD so that the NAME attribute
is a NUMBER or NMTOKEN, but then you lose the distinctness
guarantee (or you change it from an SGML construct
to an application convention.)

And adding the HEADER and BODY elements to the DTD
the way he's used them makes most of the HTML out there broken.

Dan


From TONYJ@scs.slac.stanford.edu  Wed Dec  2 05:46:25 1992
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06496; Wed, 2 Dec 92 05:46:25 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25822; Wed, 2 Dec 1992 05:59:34 +0100
Date: Tue, 1 Dec 1992 20:59 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Bug fix for MidasWWW-1.0
To: www-talk@nxoc01.cern.ch
Message-Id: <43F19679F0801933@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ

Since many of the CERN HTML documents (in particular the CERN home page) were 
changed recently to include " "'s around the document references and since version 
1.0 of midas did not support this, many of the links from the CERN home pages no 
longer work with midaswww. The sympom is a message of the form:

Error:

  Gateway was unable to connect to: "http://info.cern.ch/" 

The fix involves changing one small routine in the midaswww-1.0 distribution, 
SGMLAnchorText.c ... The fixed routine is now available as a plain text file via 
anonymous ftp from   FreeHEP.Scri.Fsu.Edu as    

/freehep/networking_email_news/midaswww/midaswww-1.0-fix001-SGMLAnchorText.c


As many people have pointed out, there are many more bugs in version 1.0 of 
midaswww. I am working to fix them all and expect to have a new release in the next 
month. Thanks to everyone who has been sending bug reports (and even more thanks to 
those who have sent fixes!).

Tony

From timbl@www3.cern.ch  Wed Dec  2 19:03:57 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10672; Wed, 2 Dec 92 19:03:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23770; Wed, 2 Dec 1992 19:17:06 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02549; Wed, 2 Dec 92 19:12:17 +0100
Date: Wed, 2 Dec 92 19:12:17 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212021812.AA02549@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Mailing list server
Reply-To: timbl@nxoc01.cern.ch


I certainly have a www-talk archive kept by the mailing list
distributer, so I have the disk space already used up.
I'm very happy to serve it on the web.

I'd be interested in the scripts Jim used to serve up the HTML.

These are a useful tool.  Perhaps the scripts and basic instructions
should be in the web -- lots of people could use them.
(I would unsubscribe to several lists if they were on the web :-)

Do the scripts scale to infinity with an idnex, or should we include the  
month-year in the http address of an archived mail message?

(Jim, escaping:    < becomes &lt; and & becomes &amp;  )

Tim


From timbl@www3.cern.ch  Wed Dec  2 19:30:00 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10867; Wed, 2 Dec 92 19:30:00 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29752; Wed, 2 Dec 1992 19:43:10 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02566; Wed, 2 Dec 92 19:38:18 +0100
Date: Wed, 2 Dec 92 19:38:18 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212021838.AA02566@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Port numbers: Clarification
Cc: F.Zwarts@kvi.nl, timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Tue, 1 Dec 1992 18:28 PDT
>  From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>

>  >>  b) There is some confusion about what port to use by default. MidasWWW  
uses port
>  >>     80 by default, although some older versions of the LineMode browser  
used port
>  >>     2784. You can change the default by putting a line...
>  >>
>  >>     midaswww*defaultHTTPPort: 2784
>  >>
>  >>     into the midaswww.ad file, although this is not really recommended.

It is NOT RECOMMENDED. 

ALL BROWSERS SHOULD DEFAULT TO PORT 80 IN ALL CASES IRRESPECTIVE OF THE 

CONTEXT OF THE REFERENCE. Some of the doc was out of date on this point,
I hope I have fixed it all now.

Given the
>  >>     above confusion it is probably a good idea to always put the port  
number in
>  >>     explicitly in your links.

That is true, as some old browsers will still be around, unless the server
supports both port numbers.

Anyone who has an old browser which defaults
to port 2784 should upgrade it.

(By the way, the WWW library will, if the port number is 80 and no connection
is made, try 2784 just in case, but this will be phased out).

If you have a server which does not run on port 80 and there is any link
to it without an explicit port number, tell the author of the link
(if me, me).


>  my parser in fact does not use the defaultHTTPPort, it actually inherits the  
port number 

>  from the source document,

That is not the way it is supposed to work.
>  I will try to fix this, but I still think it would be a good idea for Tim to  
add explicit 

>  port numbers.

Tell me where.
>  

>  Tony
>  

	Tim
	

From weber@eitech.com  Thu Dec  3 02:26:07 1992
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13332; Thu, 3 Dec 92 02:26:07 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29919; Thu, 3 Dec 1992 02:39:17 +0100
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA20266; Wed, 2 Dec 92 17:37:52 PST
Date: Wed, 2 Dec 92 17:37:52 PST
From: weber@eitech.com (Jay C. Weber)
Message-Id: <9212030137.AA20266@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: HyTime?
Content-Type: text/plain; charset=us-ascii


Can someone provide a reference to find out more on HyTime?

Thanks, Jay
---------------------------------------------------------------------
Jay C. Weber					weber@eitech.com
Enterprise Integration Technologies		weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100			(415)617-8002
Palo Alto, CA 94301

From connolly@pixel.convex.com  Thu Dec  3 02:57:33 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13472; Thu, 3 Dec 92 02:57:33 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02926; Thu, 3 Dec 1992 03:10:44 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA02270; Wed, 2 Dec 92 20:10:39 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA10364; Wed, 2 Dec 92 20:10:38 -0600
Message-Id: <9212030210.AA10364@pixel.convex.com>
To: weber@eitech.com (Jay C. Weber)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HyTime? 
In-Reply-To: Your message of "Wed, 02 Dec 92 17:37:52 PST."
             <9212030137.AA20266@eitech.com> 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cut-here"
Date: Wed, 02 Dec 92 20:10:37 CST
From: Dan Connolly <connolly@pixel.convex.com>


--cut-here

>Can someone provide a reference to find out more on HyTime?

Try comp.text.sgml or the FTP archive at ftp.ifi.uio.no
I'ts not much, but it's something.

comp.text.sgml is archived via a WAIS server too:

--cut-here
Content-Type: application/x-wais-source

(:source
:version  3
:ip-name "ifi.uio.no"
:tcp-port 210
:database-name "SGML"
   :cost 0 
   :cost-unit :free 
   :maintainer "anders@ifi.uio.no"
:description "Server created with WAIS release 8 b4.1 on May  7 16:28:27 1992
 by anders@ifi.uio.no
Standard Generalized Markup Language information
")

--cut-here--


From davis@dri.cornell.edu  Thu Dec  3 03:47:02 1992
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13655; Thu, 3 Dec 92 03:47:02 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08441; Thu, 3 Dec 1992 04:00:13 +0100
Received: by willow.tc.cornell.edu id AA05903
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 2 Dec 1992 22:00:14 -0500
Date: Wed, 2 Dec 1992 22:00:14 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199212030300.AA05903@willow.tc.cornell.edu>
To: weber@eitech.com
Subject: Re: HyTime?
Cc: www-talk@nxoc01.cern.ch

Stephen R Newcomb et al
The HyTime Hypermedia/Time-based Document Structuring Language
CACM vol 34 number 11 Nov 1991 67-83

From what I can tell, HyTime began as a language for describing music
in the mid 80s, as a generalization of MIDI.  HyTIme retains much of
this musical influence in the choice of metaphors.  HyTime devotes
much effort to schedulinging in space and time the appearance of
events (which might be musical notes, might be documents

HyTime documents are available by FTP from mailer.cs.fsu.edu in pub/sgml
(Old info, not sure if still true)

From marca@wintermute.ncsa.uiuc.edu  Thu Dec  3 03:50:14 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13674; Thu, 3 Dec 92 03:50:14 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08551; Thu, 3 Dec 1992 04:03:25 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA13721
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 2 Dec 92 21:03:22 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA27055; Wed, 2 Dec 92 21:04:35 -0800
Date: Wed, 2 Dec 92 21:04:35 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212030504.AA27055@wintermute.ncsa.uiuc.edu>
To: weber@eitech.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HyTime?
In-Reply-To: <199212030300.AA05903@willow.tc.cornell.edu>
References: <199212030300.AA05903@willow.tc.cornell.edu>

Jim Davis writes:
> Stephen R Newcomb et al
> The HyTime Hypermedia/Time-based Document Structuring Language
> CACM vol 34 number 11 Nov 1991 67-83

This article is available via WAIS in (I think) cacm.src.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From mcclanah@dlgeo.cr.usgs.gov  Thu Dec  3 20:57:08 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22526; Thu, 3 Dec 92 20:57:08 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18290; Thu, 3 Dec 1992 21:10:20 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA15202; Thu, 3 Dec 92 14:06:55 CST
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA22852; Thu, 3 Dec 1992 14:11:23 -0600
Date: Thu, 3 Dec 1992 14:11:23 -0600
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9212032011.AA22852@dlgeo.cr.usgs.gov>
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>,
        www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: Re: Bug fix for MidasWWW-1.0


Okay I found you other message, ftp'd it and recompiled - everything
(well relatively speaking) is okay now.

Thanks again.
Pat

From connolly@pixel.convex.com  Fri Dec  4 19:58:25 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28440; Fri, 4 Dec 92 19:58:25 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19150; Fri, 4 Dec 1992 20:11:39 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA02028; Fri, 4 Dec 92 13:11:34 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23347; Fri, 4 Dec 92 13:11:32 -0600
Message-Id: <9212041911.AA23347@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: The spec evolves...
Date: Fri, 04 Dec 92 13:11:32 CST
From: Dan Connolly <connolly@pixel.convex.com>


I just uploaded to ftp://info.cern.ch/pub/incoming:

libHTML-921202.tar.Z -- HTML parsing library with demo
	program. (includes current DTD)

html_spec-921202.tar.Z -- HTML.html and related files,
	moving toward a spec.


I've made some significant changes to the DTD.

1. I put SHORTTAG NO in the SGML declaraion. This
means a) _all_ attributes have to be quoted (numbers,
names, ids, CDATA -- everything), but b) it makes
parsing cleaner: minimization isn't allowed. The NET
feature is disabled (that's for doing

	<bold/foo bar/   in stead of
	<bold>foo bar</bold>

tricky to parse.)

2. I figured out a way to support HEAD/BODY tags
without breaking things. We lose some structure, but
we gain some too. And this time I stuck by the
mixed content rule-of-thumb.

3. I got rid of the TYPE attribute on anchor tags.
What's that thing for anyway. Does anybody use it?

4. I changed TYPEWRITER to PRE. My new motto is:
just describe it; don't prescribe it.

4. I added a TEXT attribute to anchor tags. The idea
is that all <A HREF=...> point to MIME text/* objects. The
TEXT parameter tells you the subtype, so you don't have
to zen it from the filename (or so you can override the
filename.) For example:

	<A HREF="TheProject.html" TEXT=PLAIN>This is
		a link to that file treated as a plain text
		file.</A>

	<A HREF="abcdef" TEXT=HTML>abcdef is an HTML entity,
	even though it doesn't have and extension.</A>

It's a little prescriptive, but those semantics are
mostly implemented already.

5. I changed anchor names from SGML Id's to NMTOKENS, so you
can use numbers or whatever you want. Since we don't have any
IDREFs pointing to them, there's no reason to use ID's.
In other words, I've moved this feature into the realm of
application conventions rather than SGML features.

6. I changed XMP and LISTING back to RCDATA. I was messing with
the MidasWWW browser, and I couln't figure out how, when I'm
dumping the SGML out of the data structures into a file, to
tell whether I should change '<'s to "&lt;" or not. If we avoid
CDATA, we can use entities everywhere, and processing is simpler.
How's that sound?

Now some ideas to kick around...

* Somebody mentioned a <VAR>...</VAR> tag for stuff that shouldn't be
cached. I'm thinking it should be a node-wide empty tag, like
ISINDEX. Maybe <VOLATILE> is a good word.

Then I think to myself, why not make it an attribute on the HEAD
element:

<!ATTLIST HEAD     STATUS (OK, ERROR, VOLATILE) OK>


More later...

Dan


From emv@garnet.msen.com  Fri Dec  4 23:33:30 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29626; Fri, 4 Dec 92 23:33:30 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04256; Fri, 4 Dec 1992 23:46:41 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mxlnB-00009qC@garnet.msen.com>; Fri, 4 Dec 92 17:46 WET
Message-Id: <m0mxlnB-00009qC@garnet.msen.com>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: Your message of Fri, 04 Dec 92 13:11:32.
             <9212041911.AA23347@pixel.convex.com> 
Date: Fri, 04 Dec 92 17:46:23 EST
From: Edward Vielmetti <emv@msen.com>

  4. I added a TEXT attribute to anchor tags. The idea
  is that all <A HREF=...> point to MIME text/* objects. The
  TEXT parameter tells you the subtype, so you don't have
  to zen it from the filename (or so you can override the
  filename.) For example:
  
  	<A HREF="TheProject.html" TEXT=PLAIN>This is
  		a link to that file treated as a plain text
  		file.</A>

Is there an SGML reason (apart from a W3 reason) not to also recommend
that we do a
   <A HREF="ftp://wuarchive.wustl.edu:/graphics/gif/f/fishies"
      CONTENTTYPE="image/gif"> 
   This is a link to a picture of some fishies.</A>
where the CONTENTTYPE matches the MIME/IANA registry of same?  This
would be a simple enough way to stick in links to graphics.  

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB





From emv@garnet.msen.com  Fri Dec  4 23:34:28 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29643; Fri, 4 Dec 92 23:34:28 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04293; Fri, 4 Dec 1992 23:47:43 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0mxlo0-00009qC@garnet.msen.com>; Fri, 4 Dec 92 17:47 WET
Message-Id: <m0mxlo0-00009qC@garnet.msen.com>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: Your message of Fri, 04 Dec 92 13:11:32.
             <9212041911.AA23347@pixel.convex.com> 
Date: Fri, 04 Dec 92 17:47:14 EST
From: Edward Vielmetti <emv@msen.com>

Dan, I'd suggest posting some of these idea to "comp.text.sgml", if
only to let that part of the world in on what we're all up to.  Plenty
of DTD experts there to catch you on any quibbles...

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From marca@wintermute.ncsa.uiuc.edu  Sat Dec  5 00:44:38 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00147; Sat, 5 Dec 92 00:44:38 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09862; Sat, 5 Dec 1992 00:57:52 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA10492
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 4 Dec 92 17:57:51 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA01046; Fri, 4 Dec 92 17:59:05 -0800
Date: Fri, 4 Dec 92 17:59:05 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212050159.AA01046@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu
Subject: last-modified document info?

Would it be a good, bad, or indifferent idea to allow clients to take
advantage of last-modified dates for documents when such information
exists and the document server can provide it?  Specifically, should
httpd be able to provide this information somehow, and/or should
last-modified become an optional field in the header of an HTML
document?

Just random thoughts, based on the assumption that it sure would be
nice to be able to tell that document A was last modified in 1973...

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From connolly@pixel.convex.com  Sat Dec  5 00:54:42 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00192; Sat, 5 Dec 92 00:54:42 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10889; Sat, 5 Dec 1992 01:07:56 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA17605; Fri, 4 Dec 92 18:07:51 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23595; Fri, 4 Dec 92 18:07:49 -0600
Message-Id: <9212050007.AA23595@pixel.convex.com>
To: Edward Vielmetti <emv@msen.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: Your message of "Fri, 04 Dec 92 17:46:23 EST."
             <m0mxlnB-00009qC@garnet.msen.com> 
Date: Fri, 04 Dec 92 18:07:49 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Is there an SGML reason (apart from a W3 reason) not to also recommend
>that we do a
>   <A HREF="ftp://wuarchive.wustl.edu:/graphics/gif/f/fishies"
>      CONTENTTYPE="image/gif"> 
>   This is a link to a picture of some fishies.</A>
>where the CONTENTTYPE matches the MIME/IANA registry of same?  This
>would be a simple enough way to stick in links to graphics.  

There's no SGML reason. The reason I didn't generalize to arbitrary
MIME entities is that the A tag has never had those semantics, and
it would be problematic to introduce them now.

Imagine what would happen if you fed that sample to the current linemode
browser: it would gladly ftp to wuarchive and barf gif data on
your screen.

This is not so much of a problem as long as the referent entity
is some subtype of text/* -- that's the reason for the two-level
hierarchy of mime types in the first place.

I'm trying to keep up with all sorts of HTML ideas.  Some things can be
added to html.dtd without significant changes to W3 code (like adding a
BLOCKQUOTE tag for a new paragraph style). But for things that will
require changes to the architecture, I'm developing a separate DTD from
the descriptive html.dtd.

First, I'm suggesting a change in terminology. The representation
of a node, which used to be called a document, and is sometimes
now called a resource (e.g. Universal Resource Locator), should
be called an Entity. This coincides with the SGML and MIME
usage of the term for "a unit of retreival."

Then the term "document" is not used for a unit of retrieval.
The WAIS protocol, for example, allows you to retrieve individual
"chunks" -- paragraphs, lines, etc. The term "entity" is well
suited to these chunks.

In stead, a "document" is a collection of entities that share
some context. This context is what the client uses to translate
relative URL's into absolute URLs. So the document that a node
belongs to consists of all the nodes you can reach from that node
by following only local links (i.e. a maximally-connected subgraph
of the web).

This allows the author to differentiate between links between
nodes of the corpus s/he's writing and links outside to
other works.

From my new DTD...

<!-- I think the A tag is overloaded. I'd like to deprecate
     it in favor of the XREF and SEE elements.
  --> 

<!ELEMENT XREF - - (#PCDATA)
 -- This element is for links within an HTML document. (a document
    is a collection of entities, or a web of nodes that share context).
 -->

<!ATTLIST XREF
        CONTEXT CDATA #IMPLIED -- defaults to the entity containing the XREF --
        -- SGML purists would make this attribute an ENTITY reference,
           and put the URL in the SYSTEM identifier in the prologue.
           For expediency, we put the URL right in the attribute.
        --
        ORIGIN CDATA #IMPLIED
        -- another URL, used as an identifier, rather than a locator.
           Ala the WAIS original-server,database,local-id triple.
        --
        REF IDREF #REQUIRED  -- ID of referent element --
        >

<!ELEMENT SEE - - (#PCDATA)
 -- This element is for links from an HTML document to any entity
    in the global web. The address and content-type of the entity
    are sufficient to resolve the reference.

    The other attributes could be specified in the text of the
    SEE content, but by making them attributes, the client software
    can process them, for example, to display a table of references
    sorted by date.
 -->
<!ATTLIST SEE
        ADDRESS CDATA #REQUIRED -- URL of referent entity --
        CONTENT-TYPE CDATA #REQUIRED -- MIME Content-Type for the entity --
        TARGET CDATA #IMPLIED
        -- This is the analogue of the #anchor mechanism.
           If CONTEXT is an SGML entity, this could be an ID,
           though it won't be validated.
           However, if CONTEXT is a text file, this could be a line number
	   to scroll to.
           The meaning depends on the content-type.
        --
        ORIGIN CDATA #IMPLIED
        -- another URL, used as an identifier, rather than a locator.
           Ala the WAIS original-server,database,local-id triple.
        --
        FROM CDATA #IMPLIED -- email address or name of author/provider --
        DATE NUMBER #IMPLIED -- in ISO format: YYYYMMDDHHMMSSZ --
        BYTES NUMBER #IMPLIED -- useful in many cases --
        MD5 CDATA #IMPLIED -- data signature --
        >

Comments are solicited...


Dan


From connolly@pixel.convex.com  Sat Dec  5 08:10:29 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01782; Sat, 5 Dec 92 08:10:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13073; Sat, 5 Dec 1992 08:23:44 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA03122; Sat, 5 Dec 92 01:23:11 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA03414; Sat, 5 Dec 92 01:23:07 -0600
Message-Id: <9212050723.AA03414@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: multimedia projects survey...
Date: Sat, 05 Dec 92 01:23:07 CST
From: Dan Connolly <connolly@pixel.convex.com>


Tim: you wanna reply to this?

------- Forwarded Message

Xref: convex comp.compression:5352 comp.protocols.iso:3234 comp.mail.multi-media:933 comp.multimedia:4515
Path: convex!convex!cs.utexas.edu!wupost!uunet!mcsun!uknet!edcastle!cja
From: cja@castle.ed.ac.uk (C Adie)
Newsgroups: comp.compression,comp.protocols.iso,comp.mail.multi-media,comp.multimedia
Subject: Networked multimedia
Summary: Survey of multimedia networking
Keywords: multimedia, networks
Message-Id: <29035@castle.ed.ac.uk>
Date: 3 Dec 92 12:41:56 GMT
Organization: Edinburgh University
Lines: 254


I have been requested by RARE to carry out a survey on NETWORKED MULTIMEDIA,
and I'm writing to ask for your help.

RARE (Reseaux Associes pour la Recherche Europeenne) is the organisation
which looks after the networking needs of Europe's researchers, and it
has recently formed a Working Group on multimedia networking.  The
survey has been instigated by that group, and will be used to guide its
further work.

The survey covers RESEARCH projects, published STANDARDS, and PRODUCTS
available in the field of networked multimedia.  Obviously, this could
be a huge task.  It can only be managable if we get good cooperation and
input from people on the net.  What we'd like is some information about
things we've missed, and about things which we know exist but have
insufficient information on.

                                 RESEARCH
                                 ========
This part of the survey is a listing of current research projects involving
networked multimedia.  We don't know enough, and have no-one to ask, about
the following projects:

PROJECT         INSTITUTION
- -------         -----------
ISA		? (Esprit)
MUSE		CECI, MIT, USA
CIO		U of Ulm, Germany
TINA (Telecommunications Networking Information Architecture)
ACME		UC Berkeley, USA
Cruiser		Bellcore, USA

We're also looking for other research projects which we have missed. 
I'm sure there are several more CEC-funded research projects which we
need to find out about.  We already know (or know who to ask) about the
following projects:

MNI		Lancaster University, GB
OSI95		Lancaster University, GB
CAR		UCL, GB
MICE		UCL, GB
DARPA teleconferencing
PACT		UCL, GB
ACT		UCL, GB
PREPARE		UCL, GB
Multi-G		SICS, Sweden
Zenith		Lancaster University, GB; Kent University, GB
EVAN		HW University, GB
MM over Janet	UCL, GB
MADE		BT
Palantir	Kent University, GB
EuroBridge	RWTH Aachen, Germany
Berkom II	DEC, Germany

                                 STANDARDS
                                 =========
This part of the survey covers standards (de facto and industry
standards as well as standards-bodies standards) which are concerned
with networked multimedia and with compound document exchange.  We don't
know enough about the following standards:

STANDARD        DESCRIPTION
- --------        -----------
JBIG		Binary image encoding form
T.101 - T.106	unknown

We're also looking for other relevant standards which we have missed. 
We already know enough (or know who to ask) about the following
standards:

RTP		Real-time Transport Protocol for audio & video over IP
MIME		Multimedia mail standard on the Internet
ST2		High speed protocol to run alongside IP for multimedia
Bento		Platform-independant compound document format from Apple
HyTime		SGML-based standard for hypermedia documents
MHEG		ASN.1-based standard for hypermedia documents
MPEG		Video & audio compression, synchronization
JPEG		Compression algorithm for continuous-tone colour stills
ODA		Office Document Architecture
G.711		64kbps 8kHz 8-bit PCM audio encoding
G.721		32kbps ADPCM audio encoding
G.722		64kbps SB-ADPCM audio encoding
H.242		Point-to-point conferencing codec standard
H.243		Multipoint video codec standard
H.261		px64kbps video encoding
H.320		Umbrella for compression, data rates, audio encoding
T.80 - T.83	Still image compression techniques for communications
T.170 - T.176	Multimedia/hypermedia objects, functions and protocols
T.121 - T.124	Network-independent audio-conferencing protocols
X.400		Multimedia mail
QuickTime Movie Format 	Apple Macintosh sequenced information file format
MIDI		Musical Instrument Digital Interface
Carousel	Platform-independant compound document format from Adobe

                                 PRODUCTS
                                 ========
This part of the survey covers products which are concerned with
networked multimedia, including desktop conferencing.  "Products" covers
commercial offerings, freeware developed in academia, and also
freely-available research tools such as vat.  We need further
information on the following products:

SUPPLIER                PRODUCT
- --------                -------
Specom Technologies Corp Picfon	
Bitfield		BVCS			
Tandberg Telecom	VC7000		
Memtec			VS-1000			
TechnoTeacher		HyMinder		
IIS Technologies	MacMica		
Group Technologies	Aspects		

We're also looking for other relevant products which we have missed.  We
already know enough (or know who to ask) about the following products:

IBM			Person to Person/2	
Xanadu			?			
The Electronic Studio	ES.F2F		
Stanford University	Maestro		
Starlight		Media Server		
CLI			Cameo PVS		
CoSA			PACo			
Bellcore		MetaMail		
Microsoft		Mail			
LBL			vat			
INRIA			ivs			
Xerox/PARC		nv			

If you can provide information about any of these, or if you know of
things we have missed, please mail me.

We plan to produce a draft survey report before the end of December. 
When complete, the survey will be made freely available over anonymous
ftp. 

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom

- ------------------------------------------------------------------------------

If you do provide information for the survey, it would really be
appreciated if you could use one of these forms:

RESEARCH PROJECTS
=================

Project name:		.............................................

Funding body:		.............................................

Participators:		.............................................
                        (list of participating organisations)

Timescale:		.............................................
                        (project start date and approximate finish date)

Project aims:		.............................................

Description:		.............................................
                        (up to a page of information - or point me at
                         an existing description which I could palagerise)

Standards used:		.............................................
                        (any distributed multimedia standards which are
                         used in the project)

Papers/reports:		.............................................
                        (list of papers, reports etc describing project
                         results)

Contact point:		.............................................
                        (name/email address of a contact person for
                         the project)


STANDARDS
=========

Name of standard:	.............................................
                        (the name by which the standard is colloquially known)

Reference number:	.............................................
                        (assigned by the standards body, if any)

Version:		.............................................
                        (eg "1988" or "II")

Sponsoring body:	.............................................
                        (could be a standards body or [for de facto
                         standards] a company name)

Current status:		.............................................
                        (eg DIS, or whatever)

One-line description:	.............................................

Detailed description:	.............................................
                        (up to a page of information - or point me at
                         an existing description which I could palagerise)

Future development:	.............................................
                        (where the standard is going)

Products:		.............................................
                        (any commercial/free products using the standard)

Further information:	.............................................
                        (references to the standard specification, to
                         user groups, to FTP sites, mailing lists, etc)


PRODUCTS
========

Product name:		...............................................

Current version:	...............................................

Manufacturer:		...............................................
                        (name, address and email address)

Supplier:		...............................................
                        (if different from manufacturer)

Platform:		...............................................
                        (hardware & system software requirements)

Description:		...............................................
                        (up to a page of information - or point me at
                         an existing description which I could palagerise)

Future plans:		...............................................
                        (future intentions for this or similar products)

Availability:		...............................................
                        (eg "available 1Q93", or whatever)

Price:			...............................................
                        (in currency of supplier's country - mention any
                         site licence arrangements)

Standards:		...............................................
                        (distributed multimedia standards [industry standards
                         or ISO/CCITT standards] used by the product)

Further information:	...............................................
                        (user group details, ftp site for product, published
                         reviews, etc)



Thanks for reading down to here!

------- End of Forwarded Message


From CSP1DWD@mvs.oac.ucla.edu  Sat Dec  5 21:00:45 1992
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03649; Sat, 5 Dec 92 21:00:45 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00584; Sat, 5 Dec 1992 21:14:02 +0100
Message-Id: <9212052014.AA00584@dxmint.cern.ch>
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 7472; Sat, 05 Dec 92 21:13:02 SET
Received: from UCLAMVS.BITNET by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 4878; Sat, 05 Dec 92 21:13:01 SET
Date:    Sat, 05 Dec 92 12:13 PST
To: www-talk@nxoc01.cern.ch
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: Reshow command (LineMode) ???

I am playing with the LineMode browser in an IBM/MVS/TSO environment
and have the following problem... the VM and MVS versions add a
clear_screen() call after every prompt to stay away from VM/MVS's
builtin screen pagers, when the response of the browser is an error/
status message the previous hypertext display is lost, it'd be nice
to rig a "reshow" command that would merely regenerate the last
hypertext display... anybody can outline what data structures and
calls I have to manipulate to accomplish this?

-- Denis


From marca@wintermute.ncsa.uiuc.edu  Sun Dec  6 03:51:52 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04910; Sun, 6 Dec 92 03:51:52 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20948; Sun, 6 Dec 1992 04:05:09 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12528
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 5 Dec 92 21:05:07 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03315; Sat, 5 Dec 92 21:06:22 -0800
Date: Sat, 5 Dec 92 21:06:22 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212060506.AA03315@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: info.cern.ch ftp mirror at NCSA

A partial mirror of Web software from info.cern.ch:/pub/www is now at:

        ftp.ncsa.uiuc.edu:/Web

There are also directories 'incoming' and 'beta'; anyone is welcome to
drop off files in 'incoming', send me a note, and I'll put 'em in
'beta'.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Sun Dec  6 06:22:57 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05508; Sun, 6 Dec 92 06:22:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10370; Sun, 6 Dec 1992 06:36:14 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA17586
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 5 Dec 92 23:36:11 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03767; Sat, 5 Dec 92 23:37:25 -0800
Date: Sat, 5 Dec 92 23:37:25 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212060737.AA03767@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: html-mode.el v1.25, and wysiwyg html-mode

Since Midaswww now handles quotes around HREF fields, here is a
revised html-mode.el that does the right thing wrt quotes.

As a side note, I am starting work on a WYSIWYG html-mode that will
use Epoch's zone mechanism (or equivalently Lucid Emacs's extents) to
both remove the need to show html syntax as well as to provide
formatted screen display.  If you have user interface ideas or any
other ideas, please let me know...

Marc

;;; --------------------------------------------------------------------------
;;; HTML mode, based on text mode.
;;; Copyright (C) 1985 Free Software Foundation, Inc.
;;; Copyright (C) 1992 National Center for Supercomputing Applications.
;;; NCSA modifications by Marc Andreessen (marca@ncsa.uiuc.edu).
;;;
;;; This program is free software; you can redistribute it and/or
;;; modify it under the terms of the GNU General Public License as
;;; published by the Free Software Foundation; either version 1, or
;;; (at your option) any later version.
;;;
;;; This program is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;; General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Emacs; see the file COPYING.  If not, write to the
;;; Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
;;;
;;; -------------------------------- CONTENTS --------------------------------
;;;
;;; html-mode: Major mode for editing HTML hypertext documents.
;;; $Revision: 1.25 $
;;; $Date: 1992/12/06 07:31:30 $
;;;
;;; Canonical list of features:
;;;   See below.
;;;
;;; ------------------------------ INSTRUCTIONS ------------------------------
;;;
;;; Put the following code in your .emacs file:
;;;
;;; (autoload 'html-mode "html-mode" "HTML major mode." t)
;;; (or (assoc "\\.html$" auto-mode-alist)
;;;   (setq auto-mode-alist (cons '("\\.html$" . html-mode) 
;;;                               auto-mode-alist)))
;;;
;;; Emacs will detect the ``.html'' suffix and activate html-mode
;;; appropriately.
;;;
;;; You are assumed to be at least somewhat familiar with HTML format.
;;; If you aren't, read about it first (see below).
;;;
;;; Here are key sequences and corresponding commands:
;;;
;;; NORMAL COMMANDS:
;;;
;;; C-c a         html-add-address
;;;   Open an address element.
;;;
;;; C-c d         html-add-definition-list
;;;   Open a definition list.  The initial entry is created for you.
;;;   To create subsequent entries, use 'C-c e'.
;;;
;;; C-c e         html-add-definition-entry
;;;   Add a new definition entry in a definition list.  You are
;;;   assumed to be inside a definition list (specifically, at the end
;;;   of another definition entry).
;;;
;;; C-c h         html-add-header
;;;   Add a header.  You are prompted for size (1 is biggest, 2 is
;;;   next biggest) and header contents.
;;;
;;; C-c i         html-add-list-or-menu-item
;;;   Add a new list or menu item in a list or menu.  You are assumed
;;;   to be inside a list or menu (specifically, at the end of another
;;;   item).
;;;
;;; C-c l         html-add-normal-link
;;;   Add a link.  You will be prompted for the link (any string;
;;;   e.g., http://foo.bar/argh/blagh).  The cursor will be left where
;;;   you can type the text that will represent the link in the
;;;   document.
;;;
;;; C-c m         html-add-menu
;;;   Open a menu.  The initial item is created for you.  To create
;;;   additional items, use 'C-c i'.
;;;
;;; C-c p         html-add-paragraph-separator
;;;   Use this command at the end of each paragraph.
;;;
;;; C-c s         html-add-list
;;;   Open a list.  The initial item is created for you.  To create
;;;   additional items, use 'C-c i'.
;;;
;;; C-c t         html-add-title
;;;   Add a title to the document.  You will be prompted for the
;;;   contents of the title.  If a title already exists at the very
;;;   top of the document, the existing contents will be replaced.
;;;
;;; C-c x         html-add-plaintext
;;;   Add plaintext.  The cursor will be positioned where you can type
;;;   plaintext (or insert another file, or whatever).
;;;
;;; COMMANDS THAT OPERATE ON THE CURRENT REGION:
;;;
;;; C-c C-r l     html-add-normal-link-to-region
;;;   Add a link that will be represented by the current region.  You
;;;   will be prompted for the link (any string, as with
;;;   html-add-normal-link).
;;;
;;; C-c C-r r     html-add-reference-to-region
;;;   Add a reference (a link that does not reference anything) that
;;;   will be represented by the current region.  You will be prompted
;;;   for the name of the link; if you just press RET, a numeric name
;;;   will be created for you.
;;;
;;; SPECIAL COMMANDS:
;;;
;;; <, >, &
;;;   These are overridden to output &lt;, &gt;, and &amp;
;;;   respectively.  The real characters <, >, and & can be entered
;;;   into the text either by prepending 'C-c' to the character or by
;;;   using the Emacs quoted-insert (C-q) command.
;;;
;;; C-c <, C-c >, C-c &
;;;   See '<, >, &' above.
;;;
;;; NOTE: The key bindings above are what I find to be useful and easy
;;; to remember.  If you have ideas on how to make them easier to
;;; handle for yourself or other people, please let me know.
;;; (Ideally, these commands all go in menus; to that end, someday
;;; soon I'll add a Lucid Emacs menu to html-mode.)
;;;
;;; ---------------------------- ADDITIONAL NOTES ----------------------------
;;;
;;; If you are running Epoch or Lucid Emacs, highlighting will be used
;;; to deemphasize HTML message elements as they are created.  You can
;;; turn this off; see the variable 'html-use-highlighting'.
;;;
;;; To reorder all of the link NAME fields in your message (in order
;;; of their occurrence in the text), use:
;;;
;;; html-reorder-numeric-names
;;;   Reorder the NAME fields for links in the current buffer.  The
;;;   new ordering starts at 1 and increases monotonically through the
;;;   buffer.  If optional arg REORDER-NON-NUMERIC is non-nil, then
;;;   non-numeric NAME's will also be numbered, else they won't.
;;;
;;; In most current HTML documents, HREF arguments are not quoted.
;;; They really should be, so HTML can be fully SGML-compliant.  Since
;;; most browsers now understand quoted HREF's, html-mode will
;;; automatically quote all new HREF's, as well as automatically
;;; convert existing HREF's to quotified format.
;;;
;;; html-quote-hrefs                 (variable, default t)
;;;   If this is non-nil, new HREF arguments will be quoted.
;;;
;;; html-quotify-hrefs-on-find       (variable, default t)
;;;   If this is non-nil, all HREF arguments will be quotified
;;;   automatically when a HTML document is loaded into Emacs
;;;   (actually when html-mode is entered).
;;;
;;; html-quotify-hrefs
;;;   This command will quotify all HREF arguments in the current
;;;   document.
;;;
;;; -------------------------------- GOTCHAS ---------------------------------
;;;
;;; HTML documents can be tricky.  html-mode is not smart enough to
;;; enforce correctness or sanity, so you have to do that yourself.
;;;
;;; In particular, html-mode is smart enough to generate unique
;;; numeric NAME id's for all links that were (1) created via an
;;; html-mode command or (2) present in the file when it was loaded.
;;; Any other links (e.g. links added via Emacs cut and paste) may
;;; have ID's that conflict with ID's html-mode generates.  You must
;;; watch for this and fix it when appropriate; otherwise, your
;;; hypertext document will not work correctly.
;;;
;;; html-reorder-numeric-names can be used to reset all of the NAME
;;; id's in a document to an ordered sequence; this will also give
;;; html-mode a chance to look over the document and figure out what
;;; new links should be named to be unique.
;;;
;;; ------------------------- WHAT HTML-MODE IS NOT --------------------------
;;;
;;; html-mode is not a mode for *browsing* HTML documents.  In
;;; particular, html-mode provides no hypertext capabilities.  There
;;; is a clear need for an HTML browser; if you write one, let me
;;; know.
;;;
;;; ------------------------------ WHAT HTML IS ------------------------------
;;;
;;; HTML (HyperText Markup Language) is a format for hypertext
;;; documents.  For more information on HTML, telnet to info.cern.ch.
;;;
;;; ---------------------------- ACKNOWLEDGEMENTS ----------------------------
;;;
;;; Some code herein provided by:
;;;   Dan Connolly <connolly@pixel.convex.com>
;;;
;;; --------------------------------------------------------------------------
;;; LCD Archive Entry:
;;; html-mode|Marc Andreessen|marca@ncsa.uiuc.edu|
;;; Major mode for editing HTML hypertext files.|
;;; $Date: 1992/12/06 07:31:30 $|$Revision: 1.25 $|~/modes/html-mode.el.Z|
;;; --------------------------------------------------------------------------

(provide 'html-mode)

;;; ------------------------------- variables --------------------------------

(defvar html-quote-hrefs t
  "*New HREF fields will be quoted if this is non-nil; else they won't be.")

(defvar html-quotify-hrefs-on-find t
  "*If non-nil, all HREF's in a file will be automatically quotified when
the file is loaded.  This is useful for converting old HTML documents
to the new SGML-compatible syntax, which mandates quoted HREF's.")

(defvar html-use-highlighting t
  "*Flag to use highlighting for HTML directives in Epoch or Lucid Emacs; 
if non-NIL, highlighting will be used.")

(defvar html-deemphasize-color "grey80"
  "*Color for de-highlighting HTML directives in Epoch or Lucid Emacs.")

(defvar html-emphasize-color "yellow"
  "*Color for highlighting HTML something-or-others in Epoch or Lucid Emacs.")

;;; --------------------------------- setup ----------------------------------

(defvar html-mode-syntax-table nil
  "Syntax table used while in html mode.")

(defvar html-mode-abbrev-table nil
  "Abbrev table used while in html mode.")
(define-abbrev-table 'html-mode-abbrev-table ())

(if html-mode-syntax-table
    ()
  (setq html-mode-syntax-table (make-syntax-table))
  (modify-syntax-entry ?\" ".   " html-mode-syntax-table)
  (modify-syntax-entry ?\\ ".   " html-mode-syntax-table)
  (modify-syntax-entry ?' "w   " html-mode-syntax-table))

(defvar html-mode-map nil "")
(if html-mode-map
    ()
  (setq html-mode-map (make-sparse-keymap))
  (define-key html-mode-map "\t" 'tab-to-tab-stop)
  (define-key html-mode-map "\C-ca" 'html-add-address)
  (define-key html-mode-map "\C-cd" 'html-add-definition-list)
  (define-key html-mode-map "\C-ce" 'html-add-definition-entry)
  (define-key html-mode-map "\C-ch" 'html-add-header)
  (define-key html-mode-map "\C-ci" 'html-add-list-or-menu-item)
  (define-key html-mode-map "\C-cl" 'html-add-normal-link)
  (define-key html-mode-map "\C-cm" 'html-add-menu)
  (define-key html-mode-map "\C-cp" 'html-add-paragraph-separator)
  (define-key html-mode-map "\C-cs" 'html-add-list)
  (define-key html-mode-map "\C-ct" 'html-add-title)
  (define-key html-mode-map "\C-cx" 'html-add-plaintext)
  (define-key html-mode-map "<" 'html-less-than)
  (define-key html-mode-map ">" 'html-greater-than)
  (define-key html-mode-map "&" 'html-ampersand)
  (define-key html-mode-map "\C-c<" 'html-real-less-than)
  (define-key html-mode-map "\C-c>" 'html-real-greater-than)
  (define-key html-mode-map "\C-c&" 'html-real-ampersand)
  (define-key html-mode-map "\C-c\C-rl" 'html-add-normal-link-to-region)
  (define-key html-mode-map "\C-c\C-rr" 'html-add-reference-to-region)
)

;;; --------------------------- buffer-local vars ----------------------------

(defvar html-link-counter-default 0)
(defvar html-link-counter nil)
(make-variable-buffer-local 'html-link-counter)
(setq-default html-link-counter html-link-counter-default)

;;; ------------------------------ highlighting ------------------------------

(defvar html-running-lemacs (string-match "Lucid" emacs-version)
  "Non-nil if running Lucid Emacs.")

(defvar html-running-epoch (boundp 'epoch::version)
  "Non-nil if running Epoch.")

(if (and html-running-epoch html-use-highlighting)
    (progn
      (defvar html-deemphasize-style (make-style))
      (set-style-foreground html-deemphasize-style html-deemphasize-color)
      (defvar html-emphasize-style (make-style))
      (set-style-foreground html-emphasize-style html-emphasize-color)))

(if (and html-running-lemacs html-use-highlighting)
    (progn
      (defvar html-deemphasize-style (make-face 'html-deemphasize-face))
      (set-face-foreground html-deemphasize-style html-deemphasize-color)
      (defvar html-emphasize-style (make-face 'html-emphasize-face))
      (set-face-foreground html-emphasize-style html-emphasize-color)))

(if html-use-highlighting
    (progn
      (if html-running-lemacs
          (defun html-add-zone (start end style)
            "Add a Lucid Emacs extent from START to END with STYLE."
            (let ((extent (make-extent start end)))
              (set-extent-face extent style)
              (set-extent-data extent 'html-mode))))
      (if html-running-epoch
          (defun html-add-zone (start end style)
            "Add an Epoch zone from START to END with STYLE."
            (let ((zone (add-zone start end style)))
              (epoch::set-zone-data zone 'html-mode))))))

(defun html-maybe-deemphasize-region (start end)
  "Maybe deemphasize a region of text.  Region is from START to END."
  (and (or html-running-epoch html-running-lemacs)
       html-use-highlighting
       (html-add-zone start end html-deemphasize-style)))

;;; ----------------------------- link commands ------------------------------

(defun html-add-link (link-object)
  "Add a link."
  (let ((start (point)))
    (setq html-link-counter (1+ html-link-counter))
    (if html-quote-hrefs
        (insert "<A NAME=" (format "%d" html-link-counter) 
                " HREF=\"" link-object "\">")
      (insert "<A NAME=" (format "%d" html-link-counter) 
              " HREF=" link-object ">"))
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "</A>")
    (push-mark)
    (forward-char -4)
    (html-maybe-deemphasize-region (1+ (point)) (+ (point) 4))))

(defun html-add-normal-link (link)
  "Make a link.  There is no completion of any kind yet."
  (interactive "sLink to: ")
  (html-add-link link))

(defun html-add-normal-link-to-region (link start end)
  "Make a link that applies to the current region.  Again,
no completion."
  (interactive "sLink to: \nr")
  (save-excursion
    (goto-char end)
    (save-excursion
      (goto-char start)
      (setq html-link-counter (1+ html-link-counter))
      (if html-quote-hrefs
          (insert "<A NAME=" (format "%d" html-link-counter)
                  " HREF=\"" link "\">")
        (insert "<A NAME=" (format "%d" html-link-counter)
                " HREF=" link ">"))
      (html-maybe-deemphasize-region start (1- (point))))
    (insert "</A>")
    (html-maybe-deemphasize-region (- (point) 3) (point))))

(defun html-add-reference-to-region (name start end)
  "Add a reference point (a link with no reference of its own) to
the current region."
  (interactive "sName (or RET for numeric): \nr")
  (and (string= name "")
       (progn
         (setq html-link-counter (1+ html-link-counter))
         (setq name (format "%d" html-link-counter))))
  (save-excursion
    (goto-char end)
    (save-excursion
      (goto-char start)
      (insert "<A NAME=" name ">")
      (html-maybe-deemphasize-region start (1- (point))))
    (insert "</A>")
    (html-maybe-deemphasize-region (- (point) 3) (point))))

;;; --------------------------- document elements ----------------------------

(defun html-add-title (title)
  "Add or modify a title."
  (interactive "sTitle: ")
  (save-excursion
    (goto-char (point-min))
    (if (and (looking-at "<TITLE>")
             (save-excursion
               (forward-char 7)
               (re-search-forward "[^<]*" 
                                  (save-excursion (end-of-line) (point)) 
                                  t)))
        ;; Plop the new title in its place.
        (replace-match title t)
      (insert "<TITLE>")
      (html-maybe-deemphasize-region (point-min) (1- (point)))
      (insert title)
      (insert "</TITLE>")
      (html-maybe-deemphasize-region (- (point) 7) (point))
      (insert "\n"))))

(defun html-add-header (size header)
  "Add a header."
  (interactive "sSize (1 or 2): \nsHeader: ")
  (let ((start (point)))
    (insert "<H" size ">")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert header)
    (setq start (point))
    (insert "</H" size ">\n")
    (html-maybe-deemphasize-region (1+ start) (1- (point)))))

(defun html-add-paragraph-separator ()
  "Add a paragraph separator."
  (interactive)
  (let ((start (point)))
    (insert "  <P>\n\n")
    (html-maybe-deemphasize-region (+ start 2) (- (point) 2))))

(defun html-add-definition-list ()
  "Add a definition list."
  (interactive)
  (let ((start (point)))
    (insert "<DL>\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "<DT> ")
    ;; Point goes right there.
    (save-excursion
      (insert "\n<DD> \n")
      (setq start (point))
      (insert "</DL>\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; Mark goes after list -- this doesn't work.
      (push-mark))))

(defun html-add-definition-entry ()
  "Add a definition entry.  Assume we're at the end of a previous
entry."
  (interactive)
  (let ((start (point)))
    (insert "\n<DT> ")
    (save-excursion
      (insert "\n<DD> "))))

(defun html-add-plaintext ()
  "Add plaintext."
  (interactive)
  (let ((start (point)))
    (insert "<XMP>\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (save-excursion
      (insert "\n")
      (setq start (point))
      (insert "</XMP>\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; This doesn't work.
      (push-mark))))

(defun html-add-list-internal (type)
  (let ((start (point)))
    (insert "<" type ">\n")
    (html-maybe-deemphasize-region start (1- (point)))
    (insert "<LI> ")
    ;; Point goes right there.
    (save-excursion
      (insert "\n")
      (setq start (point))
      (insert "</" type ">\n")
      (html-maybe-deemphasize-region start (1- (point)))
      ;; Mark goes after list -- this doesn't work.
      (push-mark))))

(defun html-add-list ()
  "Add a list."
  (interactive)
  (html-add-list-internal "UL"))

;; Is this correct?  Viola doesn't seem to do anything with it.
(defun html-add-menu ()
  "Add a menu."
  (interactive)
  (html-add-list-internal "MENU"))

(defun html-add-list-or-menu-item ()
  "Add a list or menu item.  Assume we're at the end of the
last item."
  (interactive)
  (let ((start (point)))
    (insert "\n<LI> ")))

(defun html-add-address ()
  "Add an address."
  (interactive)
  (let ((start (point)))
    (insert "<ADDRESS> ")
    (html-maybe-deemphasize-region start (1- (point)))
    (save-excursion
      (setq start (point))
      (insert "  </ADDRESS>\n")
      (html-maybe-deemphasize-region (+ start 2) (1- (point)))
      ;; Obviously this doesn't work here, so I don't
      ;; see why you're being an idiot and still doing it
      ;; like this....
      (push-mark))))

(defun html-less-than ()
  (interactive)
  (insert "&lt;"))

(defun html-greater-than ()
  (interactive)
  (insert "&gt;"))

(defun html-ampersand ()
  (interactive)
  (insert "&amp;"))

(defun html-real-less-than ()
  (interactive)
  (insert "<"))

(defun html-real-greater-than ()
  (interactive)
  (insert ">"))

(defun html-real-ampersand ()
  (interactive)
  (insert "&"))

;;; ----------------------- html-reorder-numeric-names -----------------------

(defun replace-string-in-buffer (start end newstring)
  (save-excursion
    (goto-char start)
    (delete-char (1+ (- end start)))
    (insert newstring)))

(defun html-reorder-numeric-names (&optional reorder-non-numeric)
  "Reorder the NAME fields for links in the current buffer.  The
new ordering starts at 1 and increases monotonically through the buffer.
If optional arg REORDER-NON-NUMERIC is non-nil, then non-numeric NAME's
will also be numbered, else they won't.

Beware that doing this will possibly mess up references to specific
links within this document (e.g., HREF=\"#12\") or by other documents.
This command is mainly intended for use during the initial creation
stage of a document, especially when this creation involves cutting
and pasting from other documents (which it shouldn't, since this is
hypertext :-)."
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (setq html-link-counter 0)
    (while (re-search-forward "<A[ \t\n]+NAME=" (point-max) t)
      (let* ((start (match-end 0))
             (end (save-excursion
                    (re-search-forward "[ \t\n>]" 
                                       (point-max) 
                                       t)
                    (match-beginning 0)))
             (subst (buffer-substring start end)))
        (and subst
             ;; Proceed only if we reorder non-numeric links or
             ;; this is in fact numeric (i.e. > 0).
             (or reorder-non-numeric (> (string-to-int subst) 0))
             (progn
               (setq html-link-counter (1+ html-link-counter))
               (replace-string-in-buffer start (1- end)
                (format "%d" html-link-counter))))))))

;;; --------------------------- html-quotify-hrefs ---------------------------

(defun html-quotify-hrefs ()
  "Insert quotes around all HREF attribute value literals.

This remedies the problem with old HTML files that can't be processed
by SGML parsers. That is, changes <A HREF=foo> to <A HREF=\"foo\">."
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (while 
        (re-search-forward
         "<[aA][ \t\n]+\\([nN][aA][mM][eE]=[a-zA-Z0-9]+[ \t\n]+\\)?[hH][rR][eE][fF]="
         (point-max)
         t)
      (cond
       ((null (looking-at "\""))
        (insert "\"")
        (re-search-forward "[ \t\n>]" (point-max) t)
        (forward-char -1)
        (insert "\""))))))

;;; ------------------------------- html-mode --------------------------------

(defun html-mode ()
  "Major mode for editing HTML hypertext documents.  Special commands:\\{html-mode-map}
Turning on html-mode calls the value of the variable html-mode-hook,
if that value is non-nil.

More extensive documentation is available in the file 'html-mode.el'.
The latest (possibly unstable) version of this file will always be available
on anonymous FTP server ftp.ncsa.uiuc.edu in /outgoing/marca."
  (interactive)
  (kill-all-local-variables)
  (use-local-map html-mode-map)
  (setq mode-name "HTML")
  (setq major-mode 'html-mode)
  (setq local-abbrev-table html-mode-abbrev-table)
  (set-syntax-table html-mode-syntax-table)
  (run-hooks 'html-mode-hook))

;;; ------------------------------- our hooks --------------------------------

(defun html-html-mode-hook ()
  "Hook called from html-mode-hooks.  Set html-link-counter to 
the highest link value in the document (the next link created will
be one greater than that) to insure unique (numeric) link ID's.
Also run htlm-quotify-hrefs if html-quotify-hrefs-on-find is non-nil."
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "<A[ \t\n]+NAME=" (point-max) t)
      (let* ((start (match-end 0))
             (end (save-excursion
                    (re-search-forward "[ \t\n>]"
                                       (point-max)
                                       t)
                    (match-beginning 0)))
             (subst (buffer-substring start end)))
        (and subst
             ;; Safe to do compare, since string-to-int passed a non-number
             ;; returns 0.
             (> (string-to-int subst) html-link-counter)
             (setq html-link-counter (string-to-int subst))))))
  ;; Quotify existing HREF's if html-quotify-hrefs-on-find is non-nil.
  (and html-quotify-hrefs-on-find (html-quotify-hrefs)))

;;; ------------------------------- hook setup -------------------------------

;; Author: Daniel LaLiberte (liberte@cs.uiuc.edu).
(defun html-postpend-unique-hook (hook-var hook-function)
  "Postpend HOOK-VAR with HOOK-FUNCTION, if it is not already an element.
hook-var's value may be a single function or a list of functions."
  (if (boundp hook-var)
      (let ((value (symbol-value hook-var)))
        (if (and (listp value) (not (eq (car value) 'lambda)))
            (and (not (memq hook-function value))
                 (set hook-var (append value (list hook-function))))
          (and (not (eq hook-function value))
               (set hook-var (append value (list hook-function))))))
    (set hook-var (list hook-function))))

(html-postpend-unique-hook 'html-mode-hook 'html-html-mode-hook)

;;; ------------------------------ final setup -------------------------------

(or (assoc "\\.html$" auto-mode-alist)
    (setq auto-mode-alist (cons '("\\.html$" . html-mode) auto-mode-alist)))


From guido@cwi.nl  Mon Dec  7 00:54:41 1992
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08914; Mon, 7 Dec 92 00:54:41 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24122; Mon, 7 Dec 1992 01:07:59 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA06397 (5.65b/3.2/CWI-Amsterdam); Mon, 7 Dec 1992 01:07:56 +0100
Received: by voorn.cwi.nl with SMTP
	id AA16719 (5.65b/3.2/CWI-Amsterdam); Mon, 7 Dec 1992 01:07:53 +0100
Message-Id: <9212070007.AA16719.guido@voorn.cwi.nl>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: Your message of "Fri, 04 Dec 1992 13:11:32 MET."
             <9212041911.AA23347@pixel.convex.com> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Mon, 07 Dec 1992 01:07:52 +0100
Sender: Guido.van.Rossum@cwi.nl

I just subscribed to www-talk, and haven't been able to read all the
previous exchanges, so please forgive me if this is inappropriate...

>3. I got rid of the TYPE attribute on anchor tags.
>What's that thing for anyway. Does anybody use it?

Yes, I have the following (experimental) use for it.

I have written a program that translates texinfo (the GNU Emacs
documentation format, which can be typeset using a special set of TeX
macros as well as converted to a form of hypertext called Emacs INFO
files) to HTML.  Texinfo files contain the usual cross references
between nodes as well as some more structured links that shape the set
of nodes into a tree.  Typical trees ("documents" in your proposed new
terminology -- I like it!) can contain hundreds of nodes.  My
translator adds types to structured links that indicate whether it is
a link to a child, a left or right sibling, a parent, or the root of
the tree.  This type is then used by a special WWW browser that I
wrote to support tree browsing operations (which are actually
compatible with the operations of the Emacs INFO browser).  I think
this is useful, and better than second-guessing the tree structure
from where the links lead to.

BTW, the results of my conversions (applied to several standard Emacs
manuals as well as to documentation for Python, the language I'm using
to write all my software in) can be viewed in the web rooted at

	http://voorn.cwi.nl:2784/default.html

I have added all sorts of other tags and attributes that don't exist
officially but which my own browser supports (e.g. font changes).
Later I'll try to catch up with the current proposals for HTML and
use that instead.  I might also suggest other changes from which my
texinfo conversion might benefit.

Cheers,

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"Are all your pets called Eric?"

From connolly@pixel.convex.com  Mon Dec  7 04:41:51 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09727; Mon, 7 Dec 92 04:41:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25599; Mon, 7 Dec 1992 04:55:10 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA28015; Sun, 6 Dec 92 21:55:06 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA05717; Sun, 6 Dec 92 21:55:04 -0600
Message-Id: <9212070355.AA05717@pixel.convex.com>
To: Guido.van.Rossum@cwi.nl
Cc: www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: Your message of "Mon, 07 Dec 92 01:07:52 +0100."
             <9212070007.AA16719.guido@voorn.cwi.nl> 
Date: Sun, 06 Dec 92 21:55:04 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I just subscribed to www-talk, and haven't been able to read all the
>previous exchanges, so please forgive me if this is inappropriate...

On the contrary... this is great stuff!!!

>>3. I got rid of the TYPE attribute on anchor tags.
>>What's that thing for anyway. Does anybody use it?
>
>Yes, I have the following (experimental) use for it.
>
>I have written a program that translates texinfo (the GNU Emacs
>documentation format, which can be typeset using a special set of TeX
>macros as well as converted to a form of hypertext called Emacs INFO
>files) to HTML.

Yea! TeXinfo is a Good Thing, and I think it's highly appropriate
that W3 support it as an authoring environment. The beauty of TeXinfo
is that it's _not_ a programming language like TeX or troff. That
makes it possible to develop correct translators. (Otherwise you
run into the halting problem... it's everywhere!)

I studied the TeXinfo documentation for a couple hours before I
released the last version of the HTML spec. The major feature
of TeXinfo lacking in HTML is character-level formatting (font
changes.)

There were a few TeXinfo commands (@ctrl for one) that don't
fit the HTML mold. So I looked at the LaTeX options: em, tt, bd, sl, sf
and the DocBook options, and nroff, and decided I didn't have
time to choose the right set.

[I'm also keeping MS Word (RTF) and FrameMaker (MIF) in mind.]

>... My
>translator adds types to structured links that indicate whether it is
>a link to a child, a left or right sibling, a parent, or the root of
>the tree.  This type is then used by a special WWW browser that I
>wrote to support tree browsing operations (which are actually
>compatible with the operations of the Emacs INFO browser).  I think
>this is useful, and better than second-guessing the tree structure
>from where the links lead to.

Very true. I think the A tag is _highly_ overloaded. One click on
an anchor might take you anywhere from the next sentence to
somewhere in New Zealand. I suggested the XREF and SEE elements
to distinguish between intradocument and interdocument references.

I agree that a "relationship" attribute to the XREF element would
be useful.

But I'm not sure it should go in the HTML spec. I think the spec
currently does a pretty good job of describing the current usage
of HTML. Your use of TYPE is local to your site. It could just
go in the category of "tolerated error."

Meanwhile, I think it's time to redesign HTML. I've been reading
up on HyTime, and I think it's a Good Thing after all. I think
we should make the Universal Resource Locator a HyTime architectural
form. In general, we should use HyTime as a way to guide the
architecture of W3, so that it may grow to interoperate with
for example, the Draft Advisory Standard on Hypertext (DASH)
from the Davenport group.


>BTW, the results of my conversions (applied to several standard Emacs
>manuals as well as to documentation for Python, the language I'm using
>to write all my software in)

Python -- I read a bunch of stuff about that a while ago. I wonder
if the Midas language used by the Midaswww browser could be subsumed
by Python. Aside from the pascalish syntax, I think Python is just
what we need: an object oriented language for distributed applications.
I've been hoping GNU smalltalk would mature, but maybe I should
look at Python again. Tony: have you heard of it?

Hmm... as I study the documentation, I see it's got all sorts
of good stuff: exceptions, packages, regexp processing...
Maybe I should abandon XLisp (that's what I've been writing
translators in) for Python.

>I have added all sorts of other tags and attributes that don't exist
>officially but which my own browser supports (e.g. font changes).
>Later I'll try to catch up with the current proposals for HTML and
>use that instead.  I might also suggest other changes from which my
>texinfo conversion might benefit.

I highly suggest you grab the sgmls parser and diddle with the DTD
until you find something that matches the output of your conversion.
You'll have to struggle a little while you learn about SGML, but
that's the whole point. I think you'll catch on fast.

Dan

From marca@wintermute.ncsa.uiuc.edu  Mon Dec  7 05:26:51 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09884; Mon, 7 Dec 92 05:26:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14847; Mon, 7 Dec 1992 05:40:10 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09009
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 6 Dec 92 22:40:00 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Guido.van.Rossum@cwi.nl id AA05810; Sun, 6 Dec 92 22:41:10 -0800
Date: Sun, 6 Dec 92 22:41:10 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212070641.AA05810@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: Guido.van.Rossum@cwi.nl, www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: <9212070355.AA05717@pixel.convex.com>
References: <9212070007.AA16719.guido@voorn.cwi.nl>
	<9212070355.AA05717@pixel.convex.com>

Dan Connolly writes:
> Very true. I think the A tag is _highly_ overloaded. One click on an
> anchor might take you anywhere from the next sentence to somewhere
> in New Zealand. 

This is part of the beauty of HTML and the Web, and should not be
abandoned lightly -- complete user-oriented transparency lifts the
concept of information up from its physical grounding
(network/machine/directory/file) and removes the need to think of it
as anything *but* information.  Who cares where it comes from, so long
as it's there?

Granted, better navigation mechanisms are needed to keep track of
position and orientation in this kind of environment, but that's
always been the case in hypertext -- not a new problem, but one
becoming even more ripe for active research.  Why not just consider
location transparency to be a challenge?

> Meanwhile, I think it's time to redesign HTML. 

I emphatically disagree.  With all due respect (and a lot is due) to
your efforts with formalizing HTML, it's high time to shoot the
engineers and stabilize the product.  Widespread success of the
current implementation will be the single best reason for further
redesign, which can take place well down the road in the form of HTML
version 2, after lots of real-life experiences with the current system
can be catalogued and analyzed -- something currently lacking.  In the
meantime, HTML and the Web need to work on becoming entrenched and
widely and generally used, or God help us, we're all gonna be using
Gopher five years from now.

> Python -- I read a bunch of stuff about that a while ago. I wonder
> if the Midas language used by the Midaswww browser could be subsumed
> by Python. Aside from the pascalish syntax, I think Python is just
> what we need: an object oriented language for distributed applications.
> I've been hoping GNU smalltalk would mature, but maybe I should
> look at Python again. Tony: have you heard of it?

These object-oriented toolkits and interpreters and interface builders
and so on are all wonderful, but keep in mind that (1) sustained use
of interpreters impacts performance; (2) sustained use of any of them
impacts long-term viability of systems based on them, particularly
when it comes time to start embedding HTML browsing in other tools;
and (3) look at the proliferation of different systems already in use
and removing all hope of abstracting more than a very small amount of
common code (Viola, tk/tcl, Midas, VUIT, NeXT interface builder,
etc.).  Doesn't it make more sense to just use portable C (or,
possibly, C++) and allow others to benefit from and build upon your
labors without forcing yet another toolkit/language/interpreter on
them, and more often than not forcing them to reinvent the wheel?

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From connolly@pixel.convex.com  Mon Dec  7 07:04:29 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10054; Mon, 7 Dec 92 07:04:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24383; Mon, 7 Dec 1992 07:17:47 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA04353; Mon, 7 Dec 92 00:17:40 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA12781; Mon, 7 Dec 92 00:17:37 -0600
Message-Id: <9212070617.AA12781@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: Guido.van.Rossum@cwi.nl, www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: Your message of "Sun, 06 Dec 92 22:41:10 PST."
             <9212070641.AA05810@wintermute.ncsa.uiuc.edu> 
Date: Mon, 07 Dec 92 00:17:37 CST
From: Dan Connolly <connolly@pixel.convex.com>


Look out folks -- we're getting into religious issues here.
I think Marc's made a lot of good points, but be warned:
I've spent a lot of time thinking about this stuff, and
I might state my opinions a little forcefully. :-)

>Dan Connolly writes:
>> Very true. I think the A tag is _highly_ overloaded. One click on an
>> anchor might take you anywhere from the next sentence to somewhere
>> in New Zealand. 
>
>This is part of the beauty of HTML and the Web, and should not be
>abandoned lightly -- complete user-oriented transparency lifts the
>concept of information up from its physical grounding
>(network/machine/directory/file) and removes the need to think of it
>as anything *but* information.  Who cares where it comes from, so long
>as it's there?

Good point. I didn't mean that we should make the physical distance
to the link destination known to the user. But I think users would
benefit from knowledge about the logical distance -- i.e. is
it part of the same node, part of the same document, or in some
other work completely? Is it more specific or more general
than this node?

[By the way Guido: if the information is used by the server to locate
the information, rather than by the client to label the reference,
you should put it in the HREF somewhere.]

>> Meanwhile, I think it's time to redesign HTML. 
>
>I emphatically disagree.  With all due respect (and a lot is due) to
>your efforts with formalizing HTML, it's high time to shoot the
>engineers and stabilize the product.

My communication skills are really failing me lately. This is exactly
what I meant to say: I'm happy with the HTML DTD: it describes
the way HTML is used, fairly completely and exactly. But HTML
leaves a lot to be desired that cannot be fixed in an upwards
compatible way.

>  Widespread success of the
>current implementation will be the single best reason for further
>redesign, which can take place well down the road in the form of HTML
>version 2, after lots of real-life experiences with the current system
>can be catalogued and analyzed -- something currently lacking.  In the
>meantime, HTML and the Web need to work on becoming entrenched and
>widely and generally used, or God help us, we're all gonna be using
>Gopher five years from now.

I see nothing wrong with gopher. It's just NFS without the kernel
hacks, and with fulltext searching wedged in. Gopher+ is a
mess. No two ways about it.

But HTTP is nearly identical to Gopher. In some ways, gopher is
cleaner than W3: the gopher "path" is opaque. Clients never
parse it (except some wierd clients that use the file extension).
An HTTP client parses the path, so there's a syntax imposed
on it -- have you looked at the massive hacks in the W3
browser to support VMS paths?

I think we need to seriously rethink relative addresses.

And a Gopher reference (the information the client has _before_
it traverses a link) includes the type of the information.
A W3 reference does not, and so the client must assume HTML.
(unless it's an FTP address, in which case it sneaks a peek
at the file extension. Yuk! Or unless it's a Gopher address,
where the data format interpretation is hacked into the
routine that opens the connection. Yuk!)

This is the problem: suppose I put a pointer to
<A HREF="wais://wais.host/stuff.gif">a GIF image </A>
in an HTML document and serve it up. Clients have
no way of knowing any better than to grab the data
an barf it on the screen.

And adding <A Content-Type="image/gif" HREF="wais:...>
won't help: the content-type will be ignored by most
browsers.

Hmm... perhaps there's a way out after all.
I could, on the other hand, put

<See HREF="wais://wais.host/stuff.gif" Content-Type="image/gif">
a new kind of link</See>

in the document, and only browsers that know about SEE
elements would even attempt to get the data. And they'd
know better than to treat it as text.

So perhaps it's not the HTML data format that's doomed,
but the <A> element. I guess the lesson is: you can't
teach an old element new tricks.


About python...

>These object-oriented toolkits and interpreters and interface builders
>and so on are all wonderful, but keep in mind that

> (1) sustained use
>of interpreters impacts performance; 

Counterpoint: when the design is complete, performance-critical code
can always be written in C and added as a module. In the mean time, the
benefits of rapid-prototyping outweigh the performance penalties.

>(2) sustained use of any of them
>impacts long-term viability of systems based on them, particularly
>when it comes time to start embedding HTML browsing in other tools;
>and 

I'm not sure I understand what you mean here.
I don't mean to base the W3 architecture on Python -- only some
implementations.

>(3) look at the proliferation of different systems already in use
>and removing all hope of abstracting more than a very small amount of
>common code (Viola, tk/tcl, Midas, VUIT, NeXT interface builder,
>etc.).

Viola and tk/tcl: These try to do what's already been done in
the Xaw and Motif toolkits, and they don't do it as well. (I suppose
this is your point...)

Midas: This is a specially designed language highly suited to
it's purpose. Only the highest level of code in the Midaswww
browser is written in Midas. All the rest is reusable. Tony
did a heck of a job.

VUIT: how did this get in there?

NeXT: I'd drop X/Xt/Xaw for NextStep in a second if it
was an option. NextStep isn't free, so it hasn't proliferated
like X. That's pretty much the end of the story. If I could
limit my user base to NeXT boxes, I'd like to!

>  Doesn't it make more sense to just use portable C (or,
>possibly, C++) and allow others to benefit from and build upon your
>labors without forcing yet another toolkit/language/interpreter on
>them, and more often than not forcing them to reinvent the wheel?

The key is reusable software. You've hit that on the head.
I think python can be a good platform, but I'm having
trouble supporting my point. Maybe I need to think some more...

Certainly I expect core algorithms to be coded in portable
C. That was the purpose of libHTML. But I hate dealing
with dynamic memory allocation. When you're building big
applications in C, you spend all your time getting this
right.

I think the right combination of C and an object-oriented
high level language is the way to go. Folks _love_ Tk
and tcl. But it lacks an object system, recursive list
data structures, symbols, and other essentials.

I like languages that are tailored to special applications.
In my mind, the less code you have to use to solve a problem,
the better.

Dan


From marca@wintermute.ncsa.uiuc.edu  Mon Dec  7 08:22:49 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10206; Mon, 7 Dec 92 08:22:49 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01237; Mon, 7 Dec 1992 08:36:08 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18698
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 7 Dec 92 01:36:03 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Guido.van.Rossum@cwi.nl id AA06202; Mon, 7 Dec 92 01:37:12 -0800
Date: Mon, 7 Dec 92 01:37:12 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212070937.AA06202@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: Guido.van.Rossum@cwi.nl, marca@ncsa.uiuc.edu (Marc Andreessen),
        www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-Reply-To: <9212070617.AA12781@pixel.convex.com>
References: <9212070617.AA12781@pixel.convex.com>
	<9212070641.AA05810@wintermute.ncsa.uiuc.edu>

Dan Connolly writes:
> Good point. I didn't mean that we should make the physical distance
> to the link destination known to the user. But I think users would
> benefit from knowledge about the logical distance -- i.e. is
> it part of the same node, part of the same document, or in some
> other work completely? Is it more specific or more general
> than this node?

Maybe a compromise: if linking to a point in the same document, color
the anchor orange; if linking to a point on the same server, color it
red; if linking to somewhere else entirely, color it violet.  Or a
variation on that theme.  This wouldn't require changing HTML and
wouldn't be too obtrusive to those of us who like transparency.

> [Discussion on what to do with links to GIF files.]  So perhaps it's
> not the HTML data format that's doomed, but the <A> element. I guess
> the lesson is: you can't teach an old element new tricks.

I think looking at the file extension will solve 95% of the cases
(that's what extensions are for, after all).  The remaining 5% could
be addressed by Content-Type.  The browsers should be brought up to
speed.  That's one approach -- just getting multimedia out the door
and merged into the current HTML spec calls for the simplest solution
possible, at the moment.

> Counterpoint: when the design is complete, performance-critical code
> can always be written in C and added as a module. In the mean time,
> the benefits of rapid-prototyping outweigh the performance
> penalties.

Yeah but, yeah but, once something is written with rapid prototyping
in mind and turns out to work, odds are it's going to be *the*
implementation, as its implementor goes on to bigger and better
things.

> I don't mean to base the W3 architecture on Python -- only some
> implementations.

Right.  Those implementations then will be (no offense to the Python
folks intended, but here it comes...) chained to Python, which will
put an instant damper on their general usefulness -- they're never
gonna be merged into anything else and thus made more useful, unless
that something else uses Python also, which (as is the case with all
the rest of these systems) is just plain doubtful.

> Viola and tk/tcl: These try to do what's already been done in
> the Xaw and Motif toolkits, and they don't do it as well. (I suppose
> this is your point...)

Yup.

> Midas: This is a specially designed language highly suited to it's
> purpose. Only the highest level of code in the Midaswww browser is
> written in Midas. All the rest is reusable. Tony did a heck of a
> job.

I agree with the latter point, but not the former.  There's very
little reusable code in Midaswww.  I spent quite a bit of time trying
to rip the SGML widget out and use it separately, and it's just not
possible with the current Midaswww architecture.

> VUIT: how did this get in there?

It (or something similar) is being used to generate UIL code for
Midaswww, which counts as another toolkit in my book, since I can't
effectively edit it by hand -- despite the fact I know Motif a lot
better than I'd like to, very little of my existing knowledge carries
over.

> NeXT: I'd drop X/Xt/Xaw for NextStep in a second if it was an
> option. NextStep isn't free, so it hasn't proliferated like X.
> That's pretty much the end of the story.

Agreed on all counts.  Again, my point.

I'm not arguing *against* special toolkits and builders in the
abstract -- I think they're great, for the lone programmer.  But it's
just plain a fact that there's nothing standardized about them;
they're not available on most systems; they're not going to make code
reusability practically possible, and their use causes too much
reinventing of the wheel.

Cheers,
Marc


From marca@wintermute.ncsa.uiuc.edu  Mon Dec  7 08:32:11 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10227; Mon, 7 Dec 92 08:32:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01685; Mon, 7 Dec 1992 08:45:31 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA19081
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 7 Dec 92 01:45:29 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA06230; Mon, 7 Dec 92 01:46:44 -0800
Date: Mon, 7 Dec 92 01:46:44 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212070946.AA06230@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: C++?

What if I went away and came back in four or six months with a
completely object-oriented C++ implementation of the base WWW code?
I.e., classes for Document, Anchor, et al, with enough hooks to
support a hell of a lot of browsers.  Would it be used?  (It is
possible that this could happen next year, so let me know what you
think.)

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From evas@cs.few.eur.nl  Mon Dec  7 09:26:56 1992
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10366; Mon, 7 Dec 92 09:26:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03141; Mon, 7 Dec 1992 09:40:08 +0100
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA03095; Mon, 7 Dec 92 09:40:01 +0100
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA02199; Mon, 7 Dec 92 09:39:54 +0100
Date: Mon, 7 Dec 92 09:39:54 +0100
Message-Id: <9212070839.AA02199@slc01.cs.few.eur.nl>
To: marca@ncsa.uiuc.edu
Subject: Re: C++?
Cc: www-talk@nxoc01.cern.ch

> What if I went away and came back in four or six months with a
> completely object-oriented C++ implementation of the base WWW code?
> I.e., classes for Document, Anchor, et al, with enough hooks to
> support a hell of a lot of browsers.  Would it be used?  (It is
> possible that this could happen next year, so let me know what you
> think.)

I would love it; I've been working on a PC browser using Borland C++
and Turbo Vision (a user interface toolkit) and a C++ library would
make life a lot easier.

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands

From connolly@pixel.convex.com  Mon Dec  7 10:39:13 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10688; Mon, 7 Dec 92 10:39:13 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10618; Mon, 7 Dec 1992 10:52:31 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12644; Mon, 7 Dec 92 03:07:04 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA00523; Mon, 7 Dec 92 03:07:01 -0600
Message-Id: <9212070907.AA00523@pixel.convex.com>
To: Eelco van Asperen <evas@cs.few.eur.nl>
Cc: marca@ncsa.uiuc.edu, www-talk@nxoc01.cern.ch
Subject: Re: C++? 
In-Reply-To: Your message of "Mon, 07 Dec 92 09:39:54 +0100."
             <9212070839.AA02199@slc01.cs.few.eur.nl> 
Date: Mon, 07 Dec 92 03:07:01 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I would love it; I've been working on a PC browser using Borland C++
>and Turbo Vision (a user interface toolkit) and a C++ library would
>make life a lot easier.

I second the motion. I like C++. With gcc2, it's fairly ubiquitous.
I think it makes for more productive programming.

Now... we'll have to do some thinking about class design.

I looked over the HText, HT_Anchor, etc. stuff a while ago.
The design is sound, I think. It would convert quite nicely
to C++.

My biggest problem with the HText class is that it throws
away a lot of the information in the SGML markup.

I wonder if a function that would just parse the whole
document and return some nifty structure would be useful.
No W3 processing in this routine: just SGML stuff. We
might look into using the sgmls materials as a library.
Or we might write our own. I'm getting the hang of
writing SGML parsing stuff. Once you get past the yucky
lexical details, it's not bad.

Then you could traverse the structure, find the anchors,
and, build a formatted text, etc. out of it.

Dan


From timbl@www3.cern.ch  Mon Dec  7 12:57:18 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11186; Mon, 7 Dec 92 12:57:18 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19984; Mon, 7 Dec 1992 13:10:38 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01755; Mon, 7 Dec 92 13:05:17 +0100
Date: Mon, 7 Dec 92 13:05:17 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212071205.AA01755@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: HTTP protocol upgrade
Reply-To: timbl@nxoc01.cern.ch



I propose that the actual form of the upgraged HTTP protocol is as follows.  
details are in http://info.cern.c/hypertext/WWW/Protocols/HTTP/HTTP2.html.
This follows on from the work which Carl Barker did over the summer, but makes  
it easier to merge with mail-based applications, and includes  
MIME-compatibility

The client currently sends a request

	GET  <url>

and that must be recognized by new servers. We extend this in two ways, firstly
to make GEt a specific example of a method to be applied to the object denoted
by the url, and secondly to add on the same line a third field (ignored by  
existing servers) whcih gives the protocol number being used.

New servers will check out the verstion number and read more data which  
follows, allowing such extensions as

	GET /junk/mydoc  HTRQ/1.0
	From: Tim Berners-Lee <timbl@info.cern.ch>
	Accept: text/plain, text/html, image/GIF(0.0,.5)
	Accept-Encoding: X-Compress, base64, X-tar, X-Nextmail
	
with reponse

	HTTP-Version: 1.0
	Response: OK
	MIME-Content-type: image/GIF
	Allow: GET, PUT, TEXTSEARCH
	Public: GET, TEXTSEARCH

etc etc.  The spec hasn't been completely extended to contain all the  
authorization features yet, but comments on the general direction are welcoime  
at this stage.

	Tim

From connolly@pixel.convex.com  Tue Dec  8 05:09:12 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16185; Tue, 8 Dec 92 05:09:12 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13888; Tue, 8 Dec 1992 05:22:33 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA14167; Mon, 7 Dec 92 22:22:28 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA28362; Mon, 7 Dec 92 22:22:26 -0600
Message-Id: <9212080422.AA28362@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTTP2: base it on NNTP?
Date: Mon, 07 Dec 92 22:22:26 CST
From: Dan Connolly <connolly@pixel.convex.com>


The functionality of the HTTP2 has a lot in common
with NNTP:

Commands:

HTTP		NNTP

GET u		BODY
GET u v		ARTICLE
HEAD		HEAD
PUT		POST or IHAVE

These are novel to HTTP:

CHECKOUT
CHECKIN
TEXTSEARCH u v

Status messages:

HTTP		NNTP

OK		2xx - command ok
ERROR		4xx - command correct, but could not be completed
		5xx - command unimplemented or incorrect
REDIRECTION
FORWARD

	etc.

The main technical difference between the protocols is that
NNTP involves a few more round-trips here and there: the server
starts the dialogue with a "200 - server ready" message.

The HTTP client just assumes it's ready if it accepted the connection.
This save half a round-trip, but it's doesn't allow servers to
say things like "502 - This server only available from 6pm to 8am".

Also, the NNTP IHAVE and POST commands involve more round-trips:

   S:      (listens at TCP port 119)
   C:      (requests connection on TCP port 119)
   S:      201 Foobar NNTP server ready (no posting)
   C:      IHAVE <4106@ucbvax.ARPA>
   S:      335 News to me!  <CRLF.CRLF> to end.
   C:      (sends article)
   C:      .
   S:      235 Article transferred successfully.  Thanks.

But lots of stuff like error handling, status codes, and the
like have been laid out.

I think it would be very useful to include the NNTP NEWNEWS
command in W3. (client sends NEWNEWS <date> and server responds
with a list of articles newer than <date>)

The NNTP commands HEAD, BODY, ARTICLE, etc. take a number or
a message-id as an argument. We could extend the syntax to
include URL's as quoted strings.

Then we'd add a few commands for format negotiation, locking,
and so on. I think it's a nice clean framework to work in.


Dan


From connolly@pixel.convex.com  Tue Dec  8 05:37:05 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16289; Tue, 8 Dec 92 05:37:05 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18701; Tue, 8 Dec 1992 05:50:26 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA15166; Mon, 7 Dec 92 22:50:24 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA28633; Mon, 7 Dec 92 22:50:22 -0600
Message-Id: <9212080450.AA28633@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: comments on the HTTP2 spec
Date: Mon, 07 Dec 92 22:50:22 CST
From: Dan Connolly <connolly@pixel.convex.com>


Problem: user A does CHECKOUT doc1
	user B does CHECKIN doc1
Result: everybody loses.
Solution: server gives A a "magic cookie" generated at the time
	of the checkout. B doesn't have the cookie, so he
	can't do a checkin.

Problem: "The response may be straight HTML ... or may
		start with
	HTTP-Version: ..."
	That looks like perfectly legal HTML to me. How
	do you tell the difference?
Solution: GET command is only for old servers. It always
	returns HTML. For new servers, use DOCUMENT command
	(or go to NNTP and use ARTICLE).
	(or just don't put "the response may by HTML" in the spec.
	 put it in the section on tolerated errors)

Problem: how does a server know where the end of PUT data is?
	(it can't just wait 'till the connection closes, cuz
	it has to send back a status response)
Solution: restrict PUT to 7bit or 8bit encodings, or
	introduce a Bytes: header for straight binary.

Issue: Syntax of Accept: line clashes with existing parameter syntax.
	The MIME content-type header looks like:

	Content-Type: text/plain; charset=us-ascii

	We can get rid of the parameters (though in some cases
	they're required... hmmm...), but let's use the same
	syntax to stick other stuff in there so in stead of

	Accept: text/plain, 1, 0, 0

	use

	Accept: text/plain; penalty=0; size=0.23; degradation=0.5

Clearly the ideas have been thought out a lot more than the syntactic
details. 

On the other hand, the syntactic details of NNTP are a done deal.
I think we could save some time debugging the implementation by
going with NNTP. They've dealt with stuff like a string to identify
a version of a piece of software, and all sorts of other stuff
that's "TBD" in the HTTP2 spec.

We could cut to the chase and get right to the novel features of
HTTP2, with some confidence that the syntactic details are handled.

By the way... I think this NNTP++ protocol should be used in stead
of Gopher+ too.

Dan


From connolly@pixel.convex.com  Tue Dec  8 05:48:29 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16361; Tue, 8 Dec 92 05:48:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19971; Tue, 8 Dec 1992 06:01:50 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA15540; Mon, 7 Dec 92 23:01:47 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA29598; Mon, 7 Dec 92 23:01:46 -0600
Message-Id: <9212080501.AA29598@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML: hypertext or hypermedia?
Date: Mon, 07 Dec 92 23:01:46 CST
From: Dan Connolly <connolly@pixel.convex.com>

Some folks have expressed an interest in putting graphics
and such _inside_ an HTML document.

Other folks just want references from the SGML to
external data. (even if it's presented as if it
were part of the flow of text).

I'm leaning toward the latter scenario. Inside
the HTML stream, you get SGML character stuff. No
graphics -- not even base64 encoded stuff.

The graphics stuff goes in another node. (or you
_could_ use the MIME multipart mechanism to glue
them together, but I don't see that as a very popular
choice. Even if you did that, it would not impact
the HTML spec.)

Dan

From fine@cis.ohio-state.edu  Tue Dec  8 05:58:53 1992
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16415; Tue, 8 Dec 92 05:58:53 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22028; Tue, 8 Dec 1992 06:12:14 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA07095; Tue, 8 Dec 92 00:12:10 -0500
Date: Tue, 8 Dec 92 00:12:10 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9212080512.AA07095@soccer.cis.ohio-state.edu>
To: connolly@pixel.convex.com, www-talk@nxoc01.cern.ch
Subject: Re: HTML: hypertext or hypermedia?
X-Mailer: Perl Mail System v1.1

>Some folks have expressed an interest in putting graphics
>and such _inside_ an HTML document.
>
>Other folks just want references from the SGML to
>external data. (even if it's presented as if it
>were part of the flow of text).
>
>I'm leaning toward the latter scenario. Inside
>the HTML stream, you get SGML character stuff. No
>graphics -- not even base64 encoded stuff.
>
>The graphics stuff goes in another node. (or you
>_could_ use the MIME multipart mechanism to glue
>them together, but I don't see that as a very popular
>choice. Even if you did that, it would not impact
>the HTML spec.)

Makes sense to me, assuming the answers to the next two questions are
(or could be in the future) both yes.  Does display postscript have
hypertext capabilities (yet :-), and is display postscript a recognized
MIME content type?

	   tom

From marca@wintermute.ncsa.uiuc.edu  Tue Dec  8 06:13:10 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16460; Tue, 8 Dec 92 06:13:10 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24454; Tue, 8 Dec 1992 06:26:30 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14990
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 7 Dec 92 23:26:29 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA09109; Mon, 7 Dec 92 23:27:43 -0800
Date: Mon, 7 Dec 92 23:27:43 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212080727.AA09109@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: HTML: hypertext or hypermedia?
In-Reply-To: <9212080501.AA29598@pixel.convex.com>
References: <9212080501.AA29598@pixel.convex.com>

Dan Connolly writes:
> Some folks have expressed an interest in putting graphics and such
> _inside_ an HTML document.
>
> Other folks just want references from the SGML to external data.
> (even if it's presented as if it were part of the flow of text).

The presentation as part of the flow of the document is virtually
essential -- otherwise it's only a halfway solution.

> (or you _could_ use the MIME multipart mechanism to glue them
> together, but I don't see that as a very popular choice. Even if you
> did that, it would not impact the HTML spec.)

I see this as the best possible choice, at this point in time.  While
not an ideal solution, it has the twin benefits of (as you say) using
entirely existing mechanisms and providing substantial functionality.
(And yes, I really do talk like that -- in fact, I used to work at
IBM.)

Allowing this would not preclude future Web-based hypermedia
mechanisms -- in fact, it would encourage them, as we become more
familiar with the limitations of HTML and MIME.

Blah blah blah... anyhow, we're going to go ahead and take this
approach, so we'll see how it turns out :-).

Marc


From marca@wintermute.ncsa.uiuc.edu Mon Dec  7 13:05:53 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11216; Mon, 7 Dec 92 13:05:52 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20351; Mon, 7 Dec 1992 13:19:12 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA27403
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Mon, 7 Dec 92 06:19:11 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:timbl@nxoc01.cern.ch id AA06784; Mon, 7 Dec 92 06:20:25 -0800
Date: Mon, 7 Dec 92 06:20:25 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212071420.AA06784@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch
Subject: Re: last-modified document info?
In-Reply-To: <9212071208.AA01765@www3.cern.ch>
References: <9212071208.AA01765@www3.cern.ch>

Tim Berners-Lee writes:
> I think this too is something for HTTP rather than HTML, as it
> applies also to GIF pictures and postscript. Good point.

Seems to me your new HTTP protocol would support this, maybe?  Date
could just be one of the return values.  However, it would be nice to
be able to determine the last-modified date for a document remotely
without actually having to fetch the whole document (pardon me if I'm
missing something since I haven't read your new HTTP stuff yet).

Timestamps would be a great enabling mechanism for computer-assisted
browsing of the Web.

Marc


From CSP1DWD@mvs.oac.ucla.edu  Tue Dec  8 19:29:51 1992
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21597; Tue, 8 Dec 92 19:29:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21351; Tue, 8 Dec 1992 19:43:14 +0100
Message-Id: <9212081843.AA21351@dxmint.cern.ch>
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 4781; Tue, 08 Dec 92 19:42:09 SET
Received: from UCLAMVS.BITNET by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 7012; Tue, 08 Dec 92 19:42:08 SET
Date:    Tue, 08 Dec 92 10:42 PST
To: www-talk@nxoc01.cern.ch
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: Gopher Wais queries

They are not working using the LineMode browser... I tried the
info.cern reference client but doing a wais query thru a gopher
server invaribly elicits a server error... anybody that has looked/
fixed this problem please post the necessary changes.

-- Denis


From CSP1DWD@mvs.oac.ucla.edu  Tue Dec  8 20:29:29 1992
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21947; Tue, 8 Dec 92 20:29:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07398; Tue, 8 Dec 1992 20:42:53 +0100
Message-Id: <9212081942.AA07398@dxmint.cern.ch>
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 4936; Tue, 08 Dec 92 20:41:47 SET
Received: from UCLAMVS.BITNET by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 7549; Tue, 08 Dec 92 20:41:47 SET
Date:    Tue, 08 Dec 92 11:42 PST
To: www-talk@nxoc01.cern.ch
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: Re: Gopher Wais queries

Ok, here's the problem... gopher/index/wais paths include ":" chars
in the path names, the ":" is escaped by HTGOPHER on input, but on
output it is not restored for the case of GOPHER_INDEX type, the
escaped ":" (%3a or %7a for ebcdic systems) sent to the WAIS server
generates the server error...

I am circumventing the problem by including ":" in the table of
accepted chars but maybe someone can explain to me why this business
of escaping chars exists, then I can develop a better fix.

-- Denis


From connolly@pixel.convex.com  Wed Dec  9 00:47:21 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23321; Wed, 9 Dec 92 00:47:21 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23635; Wed, 9 Dec 1992 01:00:44 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA08306; Tue, 8 Dec 92 18:00:41 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA00605; Tue, 8 Dec 92 18:00:39 -0600
Message-Id: <9212090000.AA00605@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML: use SGML keyboarding features?
Date: Tue, 08 Dec 92 18:00:38 CST
From: Dan Connolly <connolly@pixel.convex.com>

SGML has several features to make keyboarding easier.

As I was adding phrase-level elements (from TeXinfo:
em, strong, code, file, cite, etc.) it occurs
to me that it might be somewhat tedious to
key this stuff in:

	See <cite>A Discipline of Programming</cite> for good ideas.

	Type <kbd>go </kbd><var>address</var><key>RETURN</key> to
	go to any node by its address.

SGML has a feature called SHORTTAG that lets you do:

	I <em/really/ think we should...

and stuff like that. It also lets you omit the quotes around
attribute values, as long as they only contain name characters
(letters, digits, period, hyphen).

Do we want to support these in HTML?

I'd say: no.

But it would be nice to have a program that reads HTML with this
kind of markup and writes the more primitive kind.

This tool is usually said to normalize a document. Perhaps
I could hack the sgmls parser to do this kind of thing.
Shouldn't be too hard.

So we would end up with a "compiler" that just spit the
source back out, all cleaned up.

Just an idea...

Dan


From marca@wintermute.ncsa.uiuc.edu  Wed Dec  9 07:33:03 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24418; Wed, 9 Dec 92 07:33:03 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05835; Wed, 9 Dec 1992 07:46:26 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA06309
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 9 Dec 92 00:46:24 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA12378; Wed, 9 Dec 92 00:47:35 -0800
Date: Wed, 9 Dec 92 00:47:35 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212090847.AA12378@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from Lou Montulli

FYI...

Marc

------- Start of forwarded message -------
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: RE: Text based hypertext engine for UNIX (SCO)
Date: Tue, 8 Dec 92 11:43:04 CST

> 
>    Try looking at Lynx, developed at the University of Kansas.
>    It has a superior curses interface to WWW for curser addressable
>    terminals and can link together your existing resourses is ways
>    WWW can't.  You can telnet to KUfacts.cc.ukans.edu and login as
>    'kufacts' for a demo of the system.  It is available for 
>    anonymous ftp from kuhub.cc.ukans.edu in the lynx directory
>    as lynx.tar-Z.  It curently runs on almost any UNIX system with
>    a curses package.        
> 
> Fascinating... it looks really nice.  In what ways can it ``link
> together your existing resourses'' that WWW can't?
> 
> Marc

Lynx can rexec programs running on remote hosts, can start inetd applications
on remote hosts and perform transparent rlogins.  For instance, say you
have a library database system that is already in place.  You simply
add a link such as <!RLOGIN@library.host.edu -user=libcat> and Lynx
would log the user into library.host.edu as user libcat to use the library
system.  In our system you can see an example of an rexeced program
by selecting "Organizations Events and Activities" and then selecting
"Events at KU".  A database program is evoked on our stat1 system, 
(you can see this by typing a '=' before evoking events) the program
querys the user, and the database and then returns data to Lynx.

Lynx can also perform telnet and tn3270 functions, but everyone has those
so why bother talking about them.  Although one nice feature about Lynx
is that it can read the hytelnet database, check out hytelnet under
the Internet Toolbox menu.

:Lou
- -- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *      Lou  MONTULLI @ Ukanvax.bitnet                Nothing difficult,  *
  *                      Kuhub.cc.ukans.edu               is ever easy!    *
  *  UNIX,               Ukanaix.cc.ukans.edu       ACS Computing Services *
  *   have more fun!     Ukanvm.cc.ukans.edu           Lawrence, KS 66044  *
  **************************************************************************
------- End of forwarded message -------


From timbl@www3.cern.ch  Wed Dec  9 08:19:36 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24505; Wed, 9 Dec 92 08:19:36 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11726; Wed, 9 Dec 1992 08:33:00 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00892; Wed, 9 Dec 92 08:26:45 +0100
Date: Wed, 9 Dec 92 08:26:45 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212090726.AA00892@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: WWW Library bug fix release
Cc: Denis DeLaRoca (310) 825-4580 <CSP1DWD@mvs.oac.ucla.edu>
Reply-To: timbl@nxoc01.cern.ch

There have been a few bug fixes in the WWWLibrary.  (This product is needed for  
the line mode and Viola browers.)  Bug fixes between 1.0b and 1.0c are as  
follows:

- Fixed bug in FTP handling  (FTP file retrieve put control connection in bad  
state)

- Fixed bug in Gopher handling on non-ASCII platforms.

- Fixed bug in Gopher search of index whose name contained characters (such as  
blanks) escaped with %.

- Fixed bug in NEWS handling: failed on non-ASCII platforms.

I have released a version 1.0c which is in ftp://ifo.cern.ch/pub/www/src as  
usual.  For differences between earlier versions consult
 http://info.cern.ch/hypertext/WWW/Library/Features.html .


	Tim BL


From timbl@www3.cern.ch  Wed Dec  9 09:52:14 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24968; Wed, 9 Dec 92 09:52:14 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02577; Wed, 9 Dec 1992 10:05:38 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01014; Wed, 9 Dec 92 09:59:19 +0100
Date: Wed, 9 Dec 92 09:59:19 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212090859.AA01014@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: HTML: use SGML keyboarding features?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



We should insist that anything shipped on the net and described
as conforming HTML is normalized a la DTD.

That doesn't stop parsers being tolerant of unnormalized stuff.
These keyboarding aids are just a poor man's HTML editor. Others will use  
editor macros etc.   SGML is not going to survive by pretending to be a  
keyborad entry format.  (They also look horrible to me but then so do a number  
of aspects of SGML... )

Tim
 

From timbl@www3.cern.ch  Wed Dec  9 10:22:07 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25069; Wed, 9 Dec 92 10:22:07 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07558; Wed, 9 Dec 1992 10:34:14 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01030; Wed, 9 Dec 92 10:26:54 +0100
Date: Wed, 9 Dec 92 10:26:54 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212090926.AA01030@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Lynx
Cc: www-talk@nxoc01.cern.ch, montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Reply-To: timbl@nxoc01.cern.ch

Lynx looks very nice -- but is it WWW?  From the comments about the syntax
it doesn't seem to be HTML.  It has Gopher access built in, but there is no  
access from KUfacts.cc.ukans.edu to the web.

These guys have done some good work on hooking into existing services.
The emphasis seems to be on building in extra bits and peices (rexec, hytelnet,  
etc) into the browser rather than making gateways.  In the long run I think  
this approach will get too heavy on browsers. For hytelnet, for example, a
gateway is more efficient than building stuff very specific to one information  
providing application into the browsers.

The screen management is neat. I wonder whether we could persuade them to make  
it W3 compatible?  (And their data with it?)  The user interface is quick and  
simple.  I missed "home" and "back", "next" and "previous" commands of the www  
line mode interface: one has always to go through the history page. But that  
keeps it simpler. I was glad I had more than 24 lines 9and the program  
recognised the fact) when the history list started to grow.

(Anyone want to make an W3 gateway for hytelnet?)

I am sure they could parse HTML with very little effort, and join the WWW club.
The existing text at KUfacts would all fit into the <PRE> format I think.
Their <!RLOGIN@library.host.edu -user=libcat> would be www's
<a href=rlogin://libcat@library.host.edu> I assume.   (This is not very general  
of course as not all systems support rlogin).

	Tim BL

Begin forwarded message:

Date: Wed, 9 Dec 92 00:47:35 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from Lou Montulli

FYI...

Marc

------- Start of forwarded message -------
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: RE: Text based hypertext engine for UNIX (SCO)
Date: Tue, 8 Dec 92 11:43:04 CST

> 

>    Try looking at Lynx, developed at the University of Kansas.
>    It has a superior curses interface to WWW for curser addressable
>    terminals and can link together your existing resourses is ways
>    WWW can't.  You can telnet to KUfacts.cc.ukans.edu and login as
>    'kufacts' for a demo of the system.  It is available for 

>    anonymous ftp from kuhub.cc.ukans.edu in the lynx directory
>    as lynx.tar-Z.  It curently runs on almost any UNIX system with
>    a curses package.        

> 

> Fascinating... it looks really nice.  In what ways can it ``link
> together your existing resourses'' that WWW can't?
> 

> Marc

Lynx can rexec programs running on remote hosts, can start inetd applications
on remote hosts and perform transparent rlogins.  For instance, say you
have a library database system that is already in place.  You simply
add a link such as <!RLOGIN@library.host.edu -user=libcat> and Lynx
would log the user into library.host.edu as user libcat to use the library
system.  In our system you can see an example of an rexeced program
by selecting "Organizations Events and Activities" and then selecting
"Events at KU".  A database program is evoked on our stat1 system, 

(you can see this by typing a '=' before evoking events) the program
querys the user, and the database and then returns data to Lynx.

Lynx can also perform telnet and tn3270 functions, but everyone has those
so why bother talking about them.  Although one nice feature about Lynx
is that it can read the hytelnet database, check out hytelnet under
the Internet Toolbox menu.

:Lou
- -- 

  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *      Lou  MONTULLI @ Ukanvax.bitnet                Nothing difficult,  *
  *                      Kuhub.cc.ukans.edu               is ever easy!    *
  *  UNIX,               Ukanaix.cc.ukans.edu       ACS Computing Services *
  *   have more fun!     Ukanvm.cc.ukans.edu           Lawrence, KS 66044  *
  **************************************************************************
------- End of forwarded message -------



From mcclanah@dlgeo.cr.usgs.gov  Wed Dec  9 18:33:25 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28450; Wed, 9 Dec 92 18:33:25 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15463; Wed, 9 Dec 1992 18:46:49 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA25384; Wed, 9 Dec 92 11:42:56 CST
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA02043; Wed, 9 Dec 1992 11:47:44 -0600
Date: Wed, 9 Dec 1992 11:47:44 -0600
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9212091747.AA02043@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: W3 and Oracle


At CERN there is a doc that refers to some stuff that Tim and another
person did that was the beginnings of a server to an Oracle database.
Has anyone messed around with it at all.  How would one write a document
to specify the query for the HTOracle server to use?  Any help is appreciated.

Thanks 
Pat

From mcclanah@dlgeo.cr.usgs.gov  Wed Dec  9 20:17:52 1992
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29300; Wed, 9 Dec 92 20:17:52 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28264; Wed, 9 Dec 1992 20:31:17 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA26614; Wed, 9 Dec 92 13:27:23 CST
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA02091; Wed, 9 Dec 1992 13:32:13 -0600
Date: Wed, 9 Dec 1992 13:32:13 -0600
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9212091932.AA02091@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch

From mail Wed Dec  9 12:19 CST 1992
Received: from wupost.wustl.edu by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA02066; Wed, 9 Dec 1992 12:19:45 -0600
Received: by wupost.wustl.edu id AA11566
  (5.65c+/IDA-1.4.4 for <mcclanah@dlgeo.cr.usgs.gov>); Wed, 9 Dec 1992 12:17:20 -0600
Date: Wed, 9 Dec 1992 12:17:20 -0600
From: Mail Delivery Subsystem <MAILER-DAEMON@wupost.wustl.edu>
Message-Id: <199212091817.AA11566@wupost.wustl.edu>
To: mcclanah@dlgeo.cr.usgs.gov
Cc: Postmaster@wupost.wustl.edu
Subject: Returned mail: Service unavailable
Content-Type: text
Content-Length: 2744
Status: R

   ----- Transcript of session follows -----
While talking to malgudi.oar.net:
>>> DATA
<<< 554 <bullwinkle!steved>... Service unavailable
554 <bullwinkle!steved@wupost.wustl.edu>... Service unavailable

   ----- Unsent message follows -----
Received: from RUTGERS.EDU by wupost.wustl.edu with SMTP id AA11564
  (5.65c+/IDA-1.4.4 for <bullwinkle!steved@wupost.wustl.edu>); Wed, 9 Dec 1992 12:17:20 -0600
Received: from saqqara.cis.ohio-state.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA23618; Wed, 9 Dec 92 13:17:12 EST
Received: by saqqara.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA25426; Wed, 9 Dec 92 13:17:07 -0500
Received: from malgudi.oar.net by saqqara.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA25257; Wed, 9 Dec 92 13:08:36 -0500
Received: from wupost.wustl.edu  for mcclanah@dlgeo.cr.usgs.gov
	by ns.oar.net (5.65c+KVa/920824.1144) id AA16572; Wed, 9 Dec 1992 13:08:33 -0500
Received: from RUTGERS.EDU by wupost.wustl.edu with SMTP id AA11149
  (5.65c+/IDA-1.4.4 for <bullwinkle!steved@wupost.wustl.edu>); Wed, 9 Dec 1992 12:07:15 -0600
Received: from saqqara.cis.ohio-state.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA21956; Wed, 9 Dec 92 13:07:09 EST
Received: by saqqara.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA25240; Wed, 9 Dec 92 13:07:04 -0500
Received: from malgudi.oar.net by saqqara.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA25208; Wed, 9 Dec 92 13:04:22 -0500
Received: from wupost.wustl.edu  for mcclanah@dlgeo.cr.usgs.gov
	by ns.oar.net (5.65c+KVa/920824.1144) id AA16294; Wed, 9 Dec 1992 13:04:18 -0500
Received: from dxmint.cern.ch by wupost.wustl.edu with SMTP id AA10883
  (5.65c+/IDA-1.4.4 for <steved%bullwinkle.uucp@wupost.wustl.edu>); Wed, 9 Dec 1992 12:02:49 -0600
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15495; Wed, 9 Dec 1992 18:47:10 +0100
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28450; Wed, 9 Dec 92 18:33:25 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15463; Wed, 9 Dec 1992 18:46:49 +0100
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA25384; Wed, 9 Dec 92 11:42:56 CST
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA02043; Wed, 9 Dec 1992 11:47:44 -0600
Date: Wed, 9 Dec 1992 11:47:44 -0600
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9212091747.AA02043@dlgeo.cr.usgs.gov>
To: www-talk@nxoc01.cern.ch
Cc: mcclanah@dlgeo.cr.usgs.gov
Subject: W3 and Oracle


At CERN there is a doc that refers to some stuff that Tim and another
person did that was the beginnings of a server to an Oracle database.
Has anyone messed around with it at all.  How would one write a document
to specify the query for the HTOracle server to use?  Any help is appreciated.

Thanks 
Pat


From montulli@ukanaix.cc.ukans.edu  Wed Dec  9 20:52:07 1992
Return-Path: <montulli@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29545; Wed, 9 Dec 92 20:52:07 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01984; Wed, 9 Dec 1992 21:05:31 +0100
Received: by ukanaix.cc.ukans.edu (AIX 3.1/UCB 5.61/4.03)
          id AA24547; Wed, 9 Dec 92 14:03:50 -0600
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Message-Id: <9212092003.AA24547@ukanaix.cc.ukans.edu>
Subject: Re: Lynx
To: timbl@nxoc01.cern.ch
Date: Wed, 9 Dec 92 14:03:47 CST
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9212090926.AA01030@www3.cern.ch>; from "Tim Berners-Lee" at Dec 9, 92 10:26 am
X-Mailer: ELM [version 2.3 PL2]

> 
> Lynx looks very nice -- but is it WWW?  From the comments about the syntax
> it doesn't seem to be HTML.  It has Gopher access built in, but there is no  
> access from KUfacts.cc.ukans.edu to the web.

No it is not WWW, but you are right that it should not be difficult to
add html compatibility.  Maybe I'm wrong but it seems that the majority
of the resources that I see available are in Gopher format.  Our 
concentration has been more towards the user interface than the protocal.
A fatal flaw perhaps?  Adding html will correct those problems because
obviously a great deal of though has gone into its implementation.
If we had know about WWW before beginning work on this project, chances
are we would have used WWW and just rewritten the curses client to look
halfway reasonable.
> 
> These guys have done some good work on hooking into existing services.
>The emphasis seems to be on building in extra bits and peices(rexec, hytelnet, 
> etc) into the browser rather than making gateways.  In the long run I think  
> this approach will get too heavy on browsers. For hytelnet, for example, a
> gateway is more efficient than building stuff very specific to one information  
Hytelnet compatability was not added as an after thought.  The markup 
language began compatible with hytelnet and evolved from there.  Our 
focus in designing the language was to make it easily understood by
non-programmers and I think we have achieved that, but this limits
its functionality, again we are back to needing html.

>providing application into the browsers.
> 
>The screen management is neat. I wonder whether we could persuade them to make  
>it W3 compatible?  (And their data with it?)  The user interface is quick and  
>simple. I missed "home" and "back", "next" and "previous" commands of the www  

If you wish to retreat from a document you simply have to push the left arrow.
The user controls were adopted from hytelnet, very simple and user freindly.
Right arrow - follow a link
Left arrow  - retreat form a link
up arrow    - next link
down arrow  - previous link

>line mode interface: one has always to go through the history page. But that  
> keeps it simpler. I was glad I had more than 24 lines 9and the program  
> recognised the fact) when the history list started to grow.
> 
> (Anyone want to make an W3 gateway for hytelnet?)

Will this gateway re-write the links inside hytelnet documents to match
html?

> 
> I am sure they could parse HTML with very little effort, and join the WWW club.
> The existing text at KUfacts would all fit into the <PRE> format I think.
> Their <!RLOGIN@library.host.edu -user=libcat> would be www's
> <a href=rlogin://libcat@library.host.edu> I assume.(This is not very general  
> of course as not all systems support rlogin).

Rlogin code can be included in the client for systems without native Rlogin.
This is a very useful feature, is it unreasonable to include the code?

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *      Lou  MONTULLI @ Ukanvax.bitnet                Nothing difficult,  *
  *                      Kuhub.cc.ukans.edu               is ever easy!    *
  *  UNIX,               Ukanaix.cc.ukans.edu       ACS Computing Services *
  *   have more fun!     Ukanvm.cc.ukans.edu           Lawrence, KS 66044  *
  **************************************************************************

From connolly@pixel.convex.com  Thu Dec 10 04:02:16 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01609; Thu, 10 Dec 92 04:02:16 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09242; Thu, 10 Dec 1992 04:15:41 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA08563; Wed, 9 Dec 92 21:15:38 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA14084; Wed, 9 Dec 92 21:15:36 -0600
Message-Id: <9212100315.AA14084@pixel.convex.com>
Newsgroups: comp.infosystems.gopher
Subject: Re: Gopher+ Considered Harmful
To: www-talk@nxoc01.cern.ch
References: <75220@apple.apple.COM>
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Wed, 09 Dec 92 21:15:36 CST
From: Dan Connolly <connolly@pixel.convex.com>

In article <75220@apple.apple.COM> dell@Apple.COM (Thomas E. Dell) writes:
[ an excellent assesment of Gopher and Gopher+ prototocls ...]

>Proposal:
> 
>  Draft a protocol modeled after ideas present in SMTP, NNTP, and
>  FTP, with a few commands to support existing functionality.

The World-Wide Web project is also taking on the next major
revision of their protocol. I have suggested to them that NNTP
makes a good basis, and they were agreeable.

I sincerely hope that Gopher+ and HTTP2 (HyperText Transfer
Protocol, version 2) merge into an NNTP-style protocol.

I suggest we even make it NNTP compatible, except that it
would be stateless: the server processes one transaction and
then terminates the connection. And in addtion to requesting
articles by number or by ID, we would add the ability to
request them by path, a quoted string.

For exmaple:

   S:      (listens at TCP port XXX)
   C:      (requests connection on TCP port XXX)
   S:      203 wombat NNTP++ server ready
   C:      BODY "foo/bar/xxx.z"
   S:      222 "foo/bar/xxx.z" article retrieved. body text follows
           (body text here)
	   .
   S:      400 service discontinued

We would use the MIME standard for multimedia. We could allow
binary content-transfer-encoding on 8-bit clean connections, and
thus avoid the bandwidth needed to encode raw data.

   S:      (listens at TCP port XXX)
   C:      (requests connection on TCP port XXX)
   S:      203 wombat NNTP++ server ready
   C:      ARTICLE "foo/bar/xxx.z"
   S:      224 "foo/bar/xxx.z" All of article follows
   S:      (transmits article in RFC822 format, with a raw binary body:)
	    (... other headers)
	    Mime-Version: 1.0
	    Content-Type: image/gif
	    Content-Transfer-Encoding: binary
	    Content-Octets: 1274

	    (1274 bytes of raw data here)

   S:      400 service discontinued

Seems like a good idea to me. What does anybody else think?

Dan


From timbl@www3.cern.ch  Thu Dec 10 08:13:57 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02326; Thu, 10 Dec 92 08:13:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01164; Thu, 10 Dec 1992 08:27:23 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01572; Thu, 10 Dec 92 08:21:06 +0100
Date: Thu, 10 Dec 92 08:21:06 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212100721.AA01572@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Subject: Re: Lynx
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
>  Date: Wed, 9 Dec 92 14:03:47 CST
>  > 

>  > 

>  > (Anyone want to make an W3 gateway for hytelnet?)
>  

>  Will this gateway re-write the links inside hytelnet documents to match
>  html?

That is the idea.  It can probably do it on the fly at every request, so
that if you want to keep your source in hytelnet format, then you can
do that. A special W3 server just converts it as it puts it onto the net
with each client query.

>  

>  Rlogin code can be included in the client for systems without native Rlogin.
>  This is a very useful feature, is it unreasonable to include the code?

Not at all, that's a good point.  Pointers to the best portable source?

>  :lou

Tim

From guido@cwi.nl  Thu Dec 10 10:42:02 1992
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02898; Thu, 10 Dec 92 10:42:02 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03135; Thu, 10 Dec 1992 10:55:27 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA03712 (5.65b/3.2/CWI-Amsterdam); Thu, 10 Dec 1992 10:55:25 +0100
Received: by voorn.cwi.nl with SMTP
	id AA26659 (5.65b/3.2/CWI-Amsterdam); Thu, 10 Dec 1992 10:55:25 +0100
Message-Id: <9212100955.AA26659.guido@voorn.cwi.nl>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Gopher+ Considered Harmful 
In-Reply-To: Your message of "Wed, 09 Dec 1992 21:15:36 MET."
             <9212100315.AA14084@pixel.convex.com> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Thu, 10 Dec 1992 10:55:24 +0100
Sender: Guido.van.Rossum@cwi.nl

I once explained the current HTTP protocol to a local network guru and
he expressed concern that basing a protocol like this on TCP/IP is a
great waste of network resources, since you are using a
session-oriented protocol for what is essentially one remote procedure
call.  My question "then what would you recommend instead" provoked no
useful answer (what is needed is *reliable* datagrams, but these are
not implemented as an IP protocol; UDP requires too much coding for
time-out, retransmission and fragmentation).  Yet, he convinced me
that a light-weight protocol like this should minimize the number of
round-trips.

I have the feeling that the current trend of basing the new protocol
on NNTP violates that requirement.  I like the idea of borrowing
response and data formats from the FTP/SMTP/NNTP family of protocols,
with suitable extensions for 8-bit data paths.  However I don't like
it if compatibility with NNTP forces us to have an extra round trip
just so that the server can give its welcome message.

Also, I don't like the fact that you must parse the RFC822/MIME header
to find out how many bytes are to be expected.  This seems to be
mixing two levels of protocols: MIME assumes that the end of the
message is already known, and the MIME headers then tell you what to
do with it.

As I see it, there are two possible ways of using MIME in HTTP+.  We
can either support MIME as the *only* data format (implementing any
extensions we need as new MIME content types or subtypes or additional
headers), or we we support MIME as one of the possible data formats.

In both cases we need a way to indicate how much data follows; if all
we ever send is MIME, all that is needed is a header indicating the
byte count, otherwise a type identifier is needed as well.

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"The plumage don't enter into it.  He's stone dead!"

From news@news2.cis.umn.edu  Thu Dec 10 16:46:32 1992
Return-Path: <news@news2.cis.umn.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05090; Thu, 10 Dec 92 16:46:32 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23276; Thu, 10 Dec 1992 16:59:59 +0100
Received: by news2.cis.umn.edu (5.65c/)
	id AA21674; Thu, 10 Dec 1992 09:59:54 -0600
To: gopher-archive@mudhoney.micro.umn.edu
Newsgroups: comp.infosystems.gopher
Path: umn.edu!The-Star.honeywell.com!src.honeywell.com!uwm.edu!caen!uunet!europa.asd.contel.com!howland.reston.ans.net!news.ans.net!ans.net!news
From: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: Gopher+ Considered Harmful
Sender: news@ans.net (News Administrator)
Message-Id: <9212100315.AA14084@pixel.convex.com.ans-relay.ans-relay>
Date: Thu, 10 Dec 1992 03:15:36 GMT
Distribution: local-relay
To: www-talk@nxoc01.cern.ch
References: <75220@apple.apple.COM>
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Lines: 56

In article <75220@apple.apple.COM> dell@Apple.COM (Thomas E. Dell) writes:
[ an excellent assesment of Gopher and Gopher+ prototocls ...]

>Proposal:
> 
>  Draft a protocol modeled after ideas present in SMTP, NNTP, and
>  FTP, with a few commands to support existing functionality.

The World-Wide Web project is also taking on the next major
revision of their protocol. I have suggested to them that NNTP
makes a good basis, and they were agreeable.

I sincerely hope that Gopher+ and HTTP2 (HyperText Transfer
Protocol, version 2) merge into an NNTP-style protocol.

I suggest we even make it NNTP compatible, except that it
would be stateless: the server processes one transaction and
then terminates the connection. And in addtion to requesting
articles by number or by ID, we would add the ability to
request them by path, a quoted string.

For exmaple:

   S:      (listens at TCP port XXX)
   C:      (requests connection on TCP port XXX)
   S:      203 wombat NNTP++ server ready
   C:      BODY "foo/bar/xxx.z"
   S:      222 "foo/bar/xxx.z" article retrieved. body text follows
           (body text here)
	   .
   S:      400 service discontinued

We would use the MIME standard for multimedia. We could allow
binary content-transfer-encoding on 8-bit clean connections, and
thus avoid the bandwidth needed to encode raw data.

   S:      (listens at TCP port XXX)
   C:      (requests connection on TCP port XXX)
   S:      203 wombat NNTP++ server ready
   C:      ARTICLE "foo/bar/xxx.z"
   S:      224 "foo/bar/xxx.z" All of article follows
   S:      (transmits article in RFC822 format, with a raw binary body:)
	    (... other headers)
	    Mime-Version: 1.0
	    Content-Type: image/gif
	    Content-Transfer-Encoding: binary
	    Content-Octets: 1274

	    (1274 bytes of raw data here)

   S:      400 service discontinued

Seems like a good idea to me. What does anybody else think?

Dan


From connolly@pixel.convex.com  Thu Dec 10 17:52:06 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05767; Thu, 10 Dec 92 17:52:06 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02503; Thu, 10 Dec 1992 18:05:32 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA13092; Thu, 10 Dec 92 11:05:26 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA23223; Thu, 10 Dec 92 11:05:24 -0600
Message-Id: <9212101705.AA23223@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: <, >, and & characters in HTML
Date: Thu, 10 Dec 92 11:05:24 CST
From: Dan Connolly <connolly@pixel.convex.com>


I'm trying to write libHTML so that applications
can just deal with C style character strings, and
the library does all the SGML details.

The use of &lt; and &amp; to represent < and & never
seemed to fit cleanly into the SGML view of things.
So I posted to comp.text.sgml.

I think I'm a lot clearer on the matter now. The
&lt; and &gt; entities are meant to be used in typesetting
mathematics, where a less-than symbol is not necessarily
the same thing as a '<' character.

There's a mechanism for referencing characters in the
document character set in such a way that they will
not be treated as markup: numeric character references.

I'd like to get rid of the &lt;, &gt;, and &amp; entities
from the HTML DTD. Granted, there will be a transition
period while providers adjust, but I think it will make
the spec cleaner.

Anyway, here's what the experts had to say...

[edited...]

Newsgroups: comp.text.sgml
From: Erik Naggum <SGML@ifi.uio.no>
Reply-To: Erik Naggum <enag@ifi.uio.no>
Message-ID: <19921210.008@erik.naggum.no>
Date: 10 Dec 1992 07:36:57 +0100
References: <1992Dec10.020628.4884@news.eng.convex.com>
Subject: Re: hiding <, >, and &
Lines: 111

[Dan Connolly]
:
|   There is a lot of need for a routine represents an arbitrary string
|   of characters as SGML data -- a routine that hides <tags> etc. from
|   the parser.

The simplest would be to use character references for the characters
that you need to quote.  See 9.5 Character Reference, [357:10-13].

...

The way I see it, this is a completely failsafe technique.

|   [It does bring up the question of representing " and ' characters in
|   attribute value literals. Hmm.. another situation I think I'll
|   just avoid.]

What's wrong with "'", '"', "&#34;", and '&#39;'?

...

</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
                            ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<enag@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis



From connolly@pixel.convex.com  Thu Dec 10 18:51:45 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06362; Thu, 10 Dec 92 18:51:45 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09487; Thu, 10 Dec 1992 19:05:10 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA15908; Thu, 10 Dec 92 12:05:04 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA05022; Thu, 10 Dec 92 12:05:02 -0600
Message-Id: <9212101805.AA05022@pixel.convex.com>
To: Guido.van.Rossum@cwi.nl
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Gopher+ Considered Harmful 
In-Reply-To: Your message of "Thu, 10 Dec 92 10:55:24 +0100."
             <9212100955.AA26659.guido@voorn.cwi.nl> 
Date: Thu, 10 Dec 92 12:05:02 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I once explained the current HTTP protocol to a local network guru and
>he expressed concern that basing a protocol like this on TCP/IP is a
>great waste of network resources, since you are using a
>session-oriented protocol for what is essentially one remote procedure
>call.

Do the WAIS folks know about this? I wonder what they'd say...

>  My question "then what would you recommend instead" provoked no
>useful answer (what is needed is *reliable* datagrams, but these are
>not implemented as an IP protocol; UDP requires too much coding for
>time-out, retransmission and fragmentation).  Yet, he convinced me
>that a light-weight protocol like this should minimize the number of
>round-trips.

I agree.

>I have the feeling that the current trend of basing the new protocol
>on NNTP violates that requirement.  I like the idea of borrowing
>response and data formats from the FTP/SMTP/NNTP family of protocols,
>with suitable extensions for 8-bit data paths.  However I don't like
>it if compatibility with NNTP forces us to have an extra round trip
>just so that the server can give its welcome message.

The idea was to use the existing usenet distributed database. But
I guess we should just use plain old NNTP for that.

>Also, I don't like the fact that you must parse the RFC822/MIME header
>to find out how many bytes are to be expected.  This seems to be
>mixing two levels of protocols: MIME assumes that the end of the
>message is already known, and the MIME headers then tell you what to
>do with it.

I certainly didn't think it out very carefully, did I?

>As I see it, there are two possible ways of using MIME in HTTP+.  We
>can either support MIME as the *only* data format (implementing any
>extensions we need as new MIME content types or subtypes or additional
>headers), or we we support MIME as one of the possible data formats.

A terminology note here: there is no one "MIME data format." There's
the ubiquitous message/rfc822 format that you can stick anything
inside using MIME techniques. But the basic unit of information
in the MIME spec is an _entity_ -- just an arbitrary stream of bytes.

The question is, when you're sending an entity from one
place to another, how do you know where the end is?

From the MIME point of view, an NNTP client and server have
an implicit agreement that the entity going across the
wire has a content-transfer-encoding of 7bit.

This allows them to use the dot-on-a-line-by-iteself technique to
terminate the entitiy.

They also share assumptions about the content-type as
a separate issue. The client assumes the response to an
ARTICLE command is a message/rfc822 entity, while the
response to a BODY command is text/plain.

So we'll start by throwing out the 7bit restriction and
assuming binary content transfer encoding. Then we need
a new way to terminate entities. It would be nice to
just stick the bytecount in the status message, and then
blast the entity across.

But HTTP includes a format negociation such that the client
doesn't know the content-type of the returned data
until it comes back. The easy way around that is to _enclose_
all entities in message/rfc822 entities, using the
Content-Type header.

So the server would have to 
1) compute the headers to enclose the entity in a message
2) compute the length of the new entity (headers + body)
3) send a status message with that bytecount, and finally
4) send the headers and the body entity.

Note that in step 2, everybody has to be consistent about
the fact that newlines count as _2_ characters: CR and LF.

The the client has to

1) read the status message and extract the bytecount
2) slurp up that many bytes
3) find the blank line that separates the header from the body
4) parse the content-type out of the headers
5) process the body based on the bytecount

That's why I ended up mixing the two levels of protocol
(message/rfc822 headers and HTTP+ status messages.) It would
be easier for the server to:

1) send a status message indicating binary transport (but no bytecount)
2) print the enclosing headers as they're computed
3) print one more header that has the bytecount of the body
4) print a blank line separating the header from the body
5) blast bytecount octets of data over the wire

The the client just does:

1) read and parse nice 7bit headers, one at a time.
2) when you get to a blank line, you know the bytecount and
   the content-type of the message.
3) slurp up bytecount bytes of data
4) process it according to content-type.

It is somewhat intertwingled, but I still kinda like it.

Dan


From guido@cwi.nl  Fri Dec 11 11:34:37 1992
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10484; Fri, 11 Dec 92 11:34:37 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07105; Fri, 11 Dec 1992 11:47:58 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA17698 (5.65b/3.2/CWI-Amsterdam); Fri, 11 Dec 1992 11:47:55 +0100
Received: by voorn.cwi.nl with SMTP
	id AA29250 (5.65b/3.2/CWI-Amsterdam); Fri, 11 Dec 1992 11:47:54 +0100
Message-Id: <9212111047.AA29250.guido@voorn.cwi.nl>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Gopher+ Considered Harmful 
In-Reply-To: Your message of "Thu, 10 Dec 1992 12:05:02 MET."
             <9212101805.AA05022@pixel.convex.com> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Fri, 11 Dec 1992 11:47:53 +0100
Sender: Guido.van.Rossum@cwi.nl

I wrote:
>>As I see it, there are two possible ways of using MIME in HTTP+.  We
>>can either support MIME as the *only* data format (implementing any
>>extensions we need as new MIME content types or subtypes or additional
>>headers), or we we support MIME as one of the possible data formats.

Dan's reply:
>A terminology note here: there is no one "MIME data format." There's
>the ubiquitous message/rfc822 format that you can stick anything
>inside using MIME techniques. But the basic unit of information
>in the MIME spec is an _entity_ -- just an arbitrary stream of bytes.

OK, when I said MIME data format I meant MIME message format, and was
referring to the outer level only (and note that MIME *implies*
RFC822).  I certainly did not refer to a particular content-type, not
even to message/rfc822.  The only thing that isn't well-specified when
one talks about "a file in MIME format" is whether line breaks are
given as CRLF or as LF (or as something else).

>The question is, when you're sending an entity from one
>place to another, how do you know where the end is?

This is a matter for the transport agent, not for MIME -- by the time
you call in the MIME agent to handle the data you must *already* know
where the end is.  For entities contained in other entities (e.g. the
content-type family multipart/*) there is a way defined in MIME to
find the end of the inner entities, but this is not true for the
outermost entity.

>From the MIME point of view, an NNTP client and server have
>an implicit agreement that the entity going across the
>wire has a content-transfer-encoding of 7bit.
>
>This allows them to use the dot-on-a-line-by-iteself technique to
>terminate the entitiy.

MIME and NNTP should never need to talk to each other.  MIME is a UA
level format, NNTP is a message transfer agent protocol.  NNTP can use
the dot-on-a-line-by-itself convention not because it is a 7-bit
protocol (which it isn't -- although other message transfer protocols
like SMTP are) but because it is a line-based protocol.  MIME is also
mostly a line-based format, even if the content-transfer-encoding is
8bit -- it is only in binary mode that we get in trouble (since
conversion from one kind of line terminator to another is dangerous
for binary data).

>They also share assumptions about the content-type as
>a separate issue. The client assumes the response to an
>ARTICLE command is a message/rfc822 entity, while the
>response to a BODY command is text/plain.

That's a nice way of putting it.

>[Long description of why you want to put the byte count in the MIME
>headers omitted]
>
>It is somewhat intertwingled, but I still kinda like it.

And I still don't.  I have the feeling that it would be much easier to
adapt HTTP to other (non-TCP) transport protocols if the size of an
entity is given separately rather than computed from the entity itself
(after all this nonsense is only necessary because TCP doesn't have a
way to distinguish EOF from a broken connection).  As I understand it
your main objection is that under my proposal you will have to
construct the necessary headers in a buffer first.  I don't believe
that this is that much of a hassle in today's computers -- it
shouldn't be more than a couple of kilobytes even in extreme cases,
which is peanuts even for a standard PC.

An issue on which I don't have a strong opinion is whether we should
represent line separators as CRLF in the header -- anyone else?

Cheers,

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"The lawnmower.  Surely such a gadget could not have been generated
independently in two separate areas."

From pflynn@curia.ucc.ie  Fri Dec 11 12:00:17 1992
Return-Path: <pflynn@curia.ucc.ie>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10616; Fri, 11 Dec 92 12:00:17 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10639; Fri, 11 Dec 1992 12:13:44 +0100
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 4289; Fri, 11 Dec 92 12:12:34 SET
Received: from IRUCCIBM.BITNET by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 5864; Fri, 11 Dec 92 12:12:33 SET
Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id
 4669; Fri, 11 Dec 92 11:13:28 IST
Received: from curia.ucc.ie by IRUCCVAX.UCC.IE (PMDF #12095) id
 <01GS6QMPB9N40005NB@IRUCCVAX.UCC.IE>; Fri, 11 Dec 1992 10:50 GMT
Received: by curia.ucc.ie (4.1/SMI-4.1) id AA03471; Fri, 11 Dec 92 10:48:13 GMT
Date: Fri, 11 Dec 92 10:48:13 GMT
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Getting the httpd daemon running
To: www-interest@nxoc01.cern.ch
Cc: www-bug@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Message-Id: <9212111048.AA03471@curia.ucc.ie>
X-Envelope-To: www-bug@nxoc01.cern.ch, www-interest@nxoc01.cern.ch,
 www-talk@nxoc01.cern.ch

I've hit an uncomfortable problem. httpd won't start up from my inetd.conf.
Here is /etc/services:

www             80/tcp          http            # WorldWideWeb server

and here is inetd.conf:

# WorldWideWeb service: add -l logfile if logging needed
www             stream  tcp     nowait  nobody  /usr/etc/httpd  httpd -l /tlh/br
   owse/WWW/httpd.log -v

(that's all one line starting www and ending -v). And here's the result:

curia# kill -HUP 136
curia# Dec 11 10:45:02 curia inetd[136]: www/tcp: unknown service

I'm clearly doing something silly but I cannot for the life of me see *what*.

///Peter

From marca@wintermute.ncsa.uiuc.edu  Fri Dec 11 12:01:46 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10622; Fri, 11 Dec 92 12:01:46 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10787; Fri, 11 Dec 1992 12:15:13 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12386
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 11 Dec 92 05:15:11 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA19300; Fri, 11 Dec 92 05:16:22 -0800
Date: Fri, 11 Dec 92 05:16:22 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212111316.AA19300@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: one-to-many links

Is there any good reason not to just a single anchor to point to
multiple links just by including more than one HREF field in an
anchor?

Curious minds want to know...

Marc


From pflynn@curia.ucc.ie  Fri Dec 11 13:10:00 1992
Return-Path: <pflynn@curia.ucc.ie>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10889; Fri, 11 Dec 92 13:10:00 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20017; Fri, 11 Dec 1992 13:23:28 +0100
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 4500; Fri, 11 Dec 92 13:22:18 SET
Received: from IRUCCIBM.BITNET by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 6320; Fri, 11 Dec 92 13:22:17 SET
Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id
 4719; Fri, 11 Dec 92 11:46:05 IST
Received: from curia.ucc.ie by IRUCCVAX.UCC.IE (PMDF #12095) id
 <01GS6RQG341S0004D3@IRUCCVAX.UCC.IE>; Fri, 11 Dec 1992 11:22 GMT
Received: by curia.ucc.ie (4.1/SMI-4.1) id AA03533; Fri, 11 Dec 92 11:20:15 GMT
Date: Fri, 11 Dec 92 11:20:15 GMT
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re:  Getting the httpd daemon running
To: marca@ncsa.uiuc.edu
Cc: www-bug@nxoc01.cern.ch, www-interest@nxoc01.cern.ch,
        www-talk@nxoc01.cern.ch
Message-Id: <9212111120.AA03533@curia.ucc.ie>
X-Envelope-To: marca@ncsa.uiuc.edu, www-bug@nxoc01.cern.ch,
 www-interest@nxoc01.cern.ch, www-talk@nxoc01.cern.ch


>What platform are you on?

Sorry, a Sun (4.1.1)

BUT...I found it...the lines of etc/services have to be in numeric order
of the socket. Now *that*'s not in the docs!!!

///Peter

From timbl@www3.cern.ch  Fri Dec 11 15:10:57 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11752; Fri, 11 Dec 92 15:10:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07313; Fri, 11 Dec 1992 15:24:24 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02698; Fri, 11 Dec 92 15:18:01 +0100
Date: Fri, 11 Dec 92 15:18:01 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212111418.AA02698@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Guido.van.Rossum@cwi.nl
Subject: Re: Gopher+ Considered Harmful 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  And I still don't.  I have the feeling that it would be much easier to
>  adapt HTTP to other (non-TCP) transport protocols if the size of an
>  entity is given separately rather than computed from the entity itself
>  (after all this nonsense is only necessary because TCP doesn't have a
>  way to distinguish EOF from a broken connection).  As I understand it
>  your main objection is that under my proposal you will have to
>  construct the necessary headers in a buffer first.  I don't believe
>  that this is that much of a hassle in today's computers -- it
>  shouldn't be more than a couple of kilobytes even in extreme cases,
>  which is peanuts even for a standard PC.

It is not the space to buffer the stuff in the average case which is a problem.

There are extreme cases: Long documents which spew out of format converters
piped into other format converters.  These things wouyld blow the memory of a  
server which we never like to do.

There is the cumulative effect of response times.  Curerntly, almost all the W3  
code is pipelines, so the reponse (click mouse to first character on screen) is  
a function of the round trip delays and any real retrieval time. The moment you  
put a buffer in to count bytes, you have to wait for the first until the last  
is available. In the (frequent) case of many stages being involved in a  
pipeline the response time does not in fact increase much, you just get a lot  
of CPU from processors on the pipe line.  Once you buffer it up, you are using  
CPU from one processor at a time.   You can't start displaying it until you've  
parsed it and you can't parse it until you've read it and you can't read it  
until the server has counted it and he can't even start to count it until all  
the real work has been finished.

You will notice the difference immediately. 


Piping things until EOF is so much faster.  Can TCP really not tell the  
difference between a remote connection close, and a broken connection? :-((
(APIs apart)

>  An issue on which I don't have a strong opinion is whether we should
>  represent line separators as CRLF in the header -- anyone else?
>  


If you are going to be telnet-style, then CRLF it has to be.
My comment in the proposed spec

	http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTTP2.html
	
was "...In particular, lines should be regarded as terminated by the Line Feed,  
and the preceeding Carriage Return character ignored." under a note on  
"tolerance".

Tim

From guido@cwi.nl  Fri Dec 11 16:06:26 1992
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12408; Fri, 11 Dec 92 16:06:26 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16140; Fri, 11 Dec 1992 16:19:54 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA14739 (5.65b/3.2/CWI-Amsterdam); Fri, 11 Dec 1992 16:19:47 +0100
Received: by voorn.cwi.nl with SMTP
	id AA00320 (5.65b/3.2/CWI-Amsterdam); Fri, 11 Dec 1992 16:19:45 +0100
Message-Id: <9212111519.AA00320.guido@voorn.cwi.nl>
To: www-talk@nxoc01.cern.ch
Subject: Re: Gopher+ Considered Harmful 
In-Reply-To: Your message of "Fri, 11 Dec 1992 15:18:01 MET."
             <9212111418.AA02698@www3.cern.ch> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Fri, 11 Dec 1992 16:19:45 +0100
Sender: Guido.van.Rossum@cwi.nl

Tim writes:

>It is not the space to buffer the stuff in the average case which is a problem
>
>There are extreme cases: Long documents which spew out of format converters
>piped into other format converters.  These things wouyld blow the memory of a
>server which we never like to do.
>
>There is the cumulative effect of response times. Curerntly, almost all the W3
>code is pipelines, so the reponse (click mouse to first character on screen)
>is a function of the round trip delays and any real retrieval time. The moment
>you put a buffer in to count bytes, you have to wait for the first until the
>last is available. In the (frequent) case of many stages being involved in a
>pipeline the response time does not in fact increase much, you just get a lot
>of CPU from processors on the pipe line.  Once you buffer it up, you are using
>CPU from one processor at a time.   You can't start displaying it until you've
>parsed it and you can't parse it until you've read it and you can't read it
>until the server has counted it and he can't even start to count it until all
>the real work has been finished.
>
>You will notice the difference immediately.

Yes, I see.  This means there is a problem whether you put a byte
count in the header or in an "envelope" sent before the header, so
Dan's solution is just as wrong as mine. :-(

>Piping things until EOF is so much faster.  Can TCP really not tell the
>difference between a remote connection close, and a broken connection? :-((
>(APIs apart)

I tried to find out a definitive answer but it is hard to figure out.
At the kernel level there is definitely a difference between a
shutdown by the remote side and a network failure, but at least on
UNIX both situations are passed to the client as an EOF.

One solution would be to add a standard string after the document,
e.g. CR LF "*%*%*%END-OF-DOCUMENT%*%*%*" CR LF, so that the client can
assume it has received the whole file if it sees this at the end of
the file.  The client cannot assume that the data *ends* when it sees
this (it is not another form of dot-on-a-line-by-itself), since it may
occur within the data as well, but it will know that it didn't get the
whole data if it doesn't end with this.

A better version would be to if the server could calculate a simple
checksum or "signature" (e.g. MD5) of the data and append this to the
end of the data.

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"I'm sorry but I'm not allowed to argue unless you pay."

From timbl@www3.cern.ch  Fri Dec 11 16:39:29 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12746; Fri, 11 Dec 92 16:39:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21536; Fri, 11 Dec 1992 16:52:58 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02813; Fri, 11 Dec 92 16:46:40 +0100
Date: Fri, 11 Dec 92 16:46:40 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212111546.AA02813@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Subject: Hytelnet server; WWW library version 1.1        (was: Lynx)
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


A conversion program from hytelnet format to HTML is
on the web. The overview is on
http://info.cern.ch/hypertext/WWW/HytelnetGate/Overview.html
All that loverly data was too good to miss!

It uses the <PRE> format a lot, so you need the WWWLibarry version 1.1
or later in your browser (or the display looks a mess).

You could use the htn2html program recursively to convert a whole bunch of
hytelnet-style files into html. You would then have the option of
editing them to put pointers to other things than telnet sites and files
on the same system, and you could introduce some fancier formatting.

Alternatively, you cn just run a server which converts on the fly as
we now do on http://info.cern.ch:8002/w3start.txt

Tim

From connolly@pixel.convex.com  Fri Dec 11 20:00:14 1992
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14684; Fri, 11 Dec 92 20:00:14 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11927; Fri, 11 Dec 1992 20:13:43 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA13220; Fri, 11 Dec 92 13:13:37 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA25973; Fri, 11 Dec 92 13:13:34 -0600
Message-Id: <9212111913.AA25973@pixel.convex.com>
To: Guido.van.Rossum@cwi.nl
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Gopher+ Considered Harmful 
In-Reply-To: Your message of "Fri, 11 Dec 92 11:47:53 +0100."
             <9212111047.AA29250.guido@voorn.cwi.nl> 
Date: Fri, 11 Dec 92 13:13:28 CST
From: Dan Connolly <connolly@pixel.convex.com>


>
>OK, when I said MIME data format I meant MIME message format, and was
>referring to the outer level only (and note that MIME *implies*
>RFC822).

Ding! No, but thanks for playing. A mime entity IS NOT NECESSARILY
A MESSAGE! I've tried to explain this a zillion times! You can
describe regular raw gif files with MIME content types. You
can for example do

% metamail -b -c "image/gif" foo.gif

where foo.gif is just a plain old gif file -- no headers, no
nothing.

From CSP1DWD@mvs.oac.ucla.edu  Sat Dec 12 08:16:24 1992
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17752; Sat, 12 Dec 92 08:16:24 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02157; Sat, 12 Dec 1992 08:29:55 +0100
Message-Id: <9212120729.AA02157@dxmint.cern.ch>
Received: from CEARN.cern.ch by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 6865; Sat, 12 Dec 92 08:28:12 SET
Received: from UCLAMVS.BITNET by CEARN.cern.ch (Mailer R2.07B) with BSMTP id
 3503; Sat, 12 Dec 92 08:28:12 SET
Date:    Fri, 11 Dec 92 23:28 PST
To: timbl@nxoc01.cern.ch
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: WWW library version 1.1
Cc: www-talk@nxoc01.cern.ch

I have gone ahead and fetched library v1.1 and linkedited it with
a LineMode browser v1.3b and am observing problems with the navigating
commands Back and HOme, when doing Back you end up with prompts that
feature no links to select even though the display shows active links,
HOme also appears to get lost...

I've noticed that your LineMode browser is now at version 1.4 but
it hasn't been posted yet on info.cern.ch, could this possible explain
the problems that I am observing?

-- Denis


From romig@cis.ohio-state.edu  Mon Dec 14 09:03:57 1992
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00198; Mon, 14 Dec 92 09:03:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16655; Sun, 13 Dec 1992 09:33:49 +0100
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13526; Sun, 13 Dec 92 03:33:47 -0500
Date: Sun, 13 Dec 92 03:33:47 -0500
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9212130833.AA13526@brachiosaur.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Questions about WAIS, WAISGate

I'm trying to set up a W3/wais server for the Internet RFCs and
related docs.  I created a server script in Perl that takes requests,
looks up the RFCs in our ftp archive, and returns an HTML doc with
links to things that look like other RFC names.  So far, so good, this
works great.

I also wanted to be able to search for stuff with a waisserver, so I
indexed them (they're in /n/archive/2/ftp/pub/rfc or something like
that).  WAIS lookups work fine.  

I also set up a waisgate server.  Lookups work ok, but here's the
problem: the doc IDs are created such that requests for the docs get
passed to waisgate and from there to the waisserver.  Of course,
that's the way things should work.  But that means that they aren't
retrieved from the special rfc server that I created.

I could get around this by converting the RFC texts to html, storing
them somewhere, and indexing that, but I'd rather avoid copying
everything and all that.

What I'd like to do (and will, unless someone has a better answer) is
to have waisgate read a config file that might look something like
this: 

    rfc /n/archive/2/ftp/pub/rfc/*.Z http://rfcserver:port/rfc/*.html

so that document ids from database rfc that match the pattern are
seen, they are translated to the form on the right instead of the
usual wais->www ids.  That way I could have waisgate redirect specific
doc lookups to a special server, and not have to copy the databases.

Is there a better way to do this (short of copying the source files,
preformatting them and leaving them there)?  

--- Steve

From timbl@www3.cern.ch  Mon Dec 14 14:10:55 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01968; Mon, 14 Dec 92 14:10:55 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14308; Mon, 14 Dec 1992 14:24:42 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03936; Mon, 14 Dec 92 14:18:22 +0100
Date: Mon, 14 Dec 92 14:18:22 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212141318.AA03936@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: WWWLibrary_1.1
Cc: wei@xcf.berkely.edu
Reply-To: timbl@nxoc01.cern.ch



The new 1.1 library understands the <PRE> element.

It also allows SGML numeric (only) character references
such as &#60; for ASCII character 60 in the source text.  This is a  
precautionary measure in view of Dan's comments which seem reasonable to me
but would require a LONG time for new browers to come around if they were
to be adopted.

I have made SGMl.c reentrant although HTML.c still isn't.
I agree with some of the comments about cleaning up.

Dan's comments that anyone using the library is encumbered with the
HText structure is not quite accurate -- one is encumbered with
the name of the struct but not its contents which are hidden in whatever  
implements it. pointers to undefined structures seem to be the only clean  
method of infomation hiding in modular C.

The styles I agree should go out and will when I get round to it.
If you think your definitive parser will fit into the library, Dan, I'll
consider putting it in the distribution.

Did I mention that Dan's new SGML spec is on the web linked from the old spec?

On that spec (which is getting cleaner each time),

-  Could you put an empty <LINK ...> element into the set of things allowed
in the header, please? Attributes as <A> but no content. Value of TYPE
attributes to be subject to registration, with the usual X- escape.

The architecure of the browsers is input-driven rather than output-driven.
Control passes from the Access module to the Protocol module which decides  
ithas to build an object, and calls the parser with the data as parameter which  
calls the object it is building.  We had it originally the other way up, that  
the object called theprotocol module toget some data, but that was not so  
flexible as the protocol module had in fact to be able to decide which objects  
to build.


	Tim

From marca@wintermute.ncsa.uiuc.edu  Mon Dec 14 18:17:40 1992
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03506; Mon, 14 Dec 92 18:17:40 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00470; Mon, 14 Dec 1992 18:31:26 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA21988
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 14 Dec 92 11:31:25 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA28776; Mon, 14 Dec 92 11:32:40 -0800
Date: Mon, 14 Dec 92 11:32:40 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9212141932.AA28776@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: two ideas....

At some point we're going to want to implement two somewhat
specialized types of nodes:

(1) To support the effect of having one-to-many links, we'll want to
    have a special kind of document that consists entirely of a list
    of anchors (pointing to the many links) that will be referenced by
    the initial anchor.  This document should pop up as a small
    transient dialog box to provide the effect of the one-to-many
    menu.

(2) To support the type of glossary used with, e.g., the Microsoft
    Windows help system (wherein clicking on a glossary reference
    gives one a transient dialog box containing only the glossary
    entry one is accessing), it should be possible to have a small
    amount of text displayed in a dialog box auxiliary to the current
    document instead of as a full document.

The commonality here is that some documents should only appear in
dialog boxes (when the browser supports it) as opposed to appearing
and being dealt with as full-fledged regular documents.

The advantages in implementing this kind of thing are (1) WWW becomes
a little more like some other current systems (notably Intermedia,
with the effectively one-to-many links), boosting its ability to take
over the functions that other systems have provided up until now, and
(2) navigational disorientation is lessened when minor references
(e.g., to glossary entries or menus of anchors) are instantiated
onscreen as minor GUI elements.

So how about allowing a tag (say, <transient>) to be included in the
header of an HTML document to specify this property?

Marc

ps Specifically for the glossary system, I'm thinking of having a
regular glossary document with all the entries in a list and then
having a special server shell script strip (say that three times fast)
out a given entry when it's needed, adding the <transient> flag while
constructing a document for the entry on the fly.


From jim@wilbur.njit.edu  Mon Dec 14 21:53:42 1992
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05127; Mon, 14 Dec 92 21:53:42 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28190; Mon, 14 Dec 1992 22:07:28 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA12654; Mon, 14 Dec 92 16:07:01 -0500
Message-Id: <9212142107.AA12654@njitgw.njit.edu>
Received: by wilbur.njit.edu; Mon, 14 Dec 92 16:05:31 est
Date: Mon, 14 Dec 92 16:05:31 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: marca@wintermute.ncsa.uiuc.edu, www-talk@nxoc01.cern.ch
Subject: Re:  two ideas....

At lunch today... we were discussing almost the same thing-- multi-links,
and menu like intermediate documents.

My thought was to have the browser specially handle documents that begin
with a <DL>, e.i. list objects.  I had considered a special file extension
but that would be too ugly.  The html list object could then be presented
in menu fashion.

jim

From timbl@www3.cern.ch  Tue Dec 15 12:39:29 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08810; Tue, 15 Dec 92 12:39:29 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06938; Tue, 15 Dec 1992 12:53:18 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00506; Tue, 15 Dec 92 12:46:28 +0100
Date: Tue, 15 Dec 92 12:46:28 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212151146.AA00506@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: two ideas....
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Mon, 14 Dec 92 11:32:40 -0800
>  From: marca@ncsa.uiuc.edu (Marc Andreessen)

> [...]
>  

>  The commonality here is that some documents should only appear in
>  dialog boxes (when the browser supports it) as opposed to appearing
>  and being dealt with as full-fledged regular documents.

The NeXTStep browser gets a similar look progressively, by
resizing the window to exactly surround the document if it will fit on a  
screen, and then by  eliminating both the scroll bar and the "resive bar'  
(NeXTStep window decoration) if the document is also not editable.

>  The advantages in implementing this kind of thing are (1) WWW becomes
>  a little more like some other current systems (notably Intermedia,
>  with the effectively one-to-many links), boosting its ability to take
>  over the functions that other systems have provided up until now, and
>  (2) navigational disorientation is lessened when minor references
>  (e.g., to glossary entries or menus of anchors) are instantiated
>  onscreen as minor GUI elements.

Another possibility is to allow for a 'collection" object which is separate
from a document and  more constrained, would have a simple on-screen
representation, would map to gopher menus, newsgroups, lists, etc.

>  So how about allowing a tag (say, <transient>) to be included in the
>  header of an HTML document to specify this property?
>  

>  Marc

I worry that you will find that there is a continuous gradient between the  
transient and the non-transient, with many stages in between.
 

>  ps Specifically for the glossary system, I'm thinking of having a
>  regular glossary document with all the entries in a list and then
>  having a special server shell script strip (say that three times fast)
>  out a given entry when it's needed, adding the <transient> flag while
>  constructing a document for the entry on the fly.
>  


this is what Mike Sendall's STING gloassary is.   (See link from CERN page).

Tim


From jfgroff@munchkin.next.com  Tue Dec 15 15:49:38 1992
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09711; Tue, 15 Dec 92 15:49:38 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11243; Tue, 15 Dec 1992 16:03:20 +0100
Received: from eleanor by munchkin.NeXT.COM (NX5.67c/NX3.0M-IS (Mailhost-Relay $Revision: 1.8 $ $State: Exp $))
	id AA12181; Tue, 15 Dec 92 16:03:08 +0100
Received: by eleanor.next.com (NX5.67c/NeXT-2.1 (Client-Relay $Revision: 1.6 $ $State: Exp $))
	id AA10809; Tue, 15 Dec 92 16:03:05 +0100
Return-Path: <jfgroff>
Received: by prospero (NX5.67c/NeXT-1.0/Oei-0.9f)
	id AA02789; Tue, 15 Dec 92 00:20:45 +0100
Date: Tue, 15 Dec 92 00:20:45 +0100
From: jfgroff@munchkin.next.com (Jean-Francois Groff)
Message-Id: <9212142320.AA02789@prospero>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Re: C++? 

Marc proposes:
>> What if I went away and came back in four or six months with a
>> completely object-oriented C++ implementation of the base WWW code?
>> I.e., classes for Document, Anchor, et al, with enough hooks to
>> support a hell of a lot of browsers.

and Dan notes:
> I looked over the HText, HT_Anchor, etc. stuff a while ago.
> The design is sound, I think. It would convert quite nicely
> to C++.

Let me add that HText, HTAnchor etc. were originally designed in Objective-C

From timbl@www3.cern.ch  Thu Dec 17 08:40:57 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25315; Thu, 17 Dec 92 08:40:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09402; Thu, 17 Dec 1992 08:54:48 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01181; Thu, 17 Dec 92 08:47:59 +0100
Date: Thu, 17 Dec 92 08:47:59 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212170747.AA01181@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: comp.infosystems.www
Reply-To: timbl@nxoc01.cern.ch


Any volunteers to propose and call for votes and create a comp.infosystems.www
newsgroup?    There have been many comments that we should have one.

Tim

From montulli@ukanaix.cc.ukans.edu  Fri Dec 18 22:13:59 1992
Return-Path: <montulli@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18907; Fri, 18 Dec 92 22:13:59 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01924; Fri, 18 Dec 1992 22:27:54 +0100
Received: by ukanaix.cc.ukans.edu (AIX 3.1/UCB 5.61/4.03)
          id AA24621; Fri, 18 Dec 92 15:26:26 -0600
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Message-Id: <9212182126.AA24621@ukanaix.cc.ukans.edu>
Subject: Searching
To: www-talk@nxoc01.cern.ch
Date: Fri, 18 Dec 92 15:26:25 CST
X-Mailer: ELM [version 2.3 PL2]


WAIS searching is adequate for many applications but ergonomically 
it has a long way to go.  The currently search methods provided by 
WWW and Gopher are inadequate for many needs.

For an example, assume a hypothetical database for calendar information.
It is designed to allow the user to pick among a finite set of events 
and show them based on a date range.  A CWIS interface to the data
might look like the following.
----------------------------------------------------------------
      Welcome to The University of Kansas Events Server

          Press return at any time to show events.

          Starting search date:  Dec, 18 1992
            Ending search date:  Jan, 18 1993

                          Categories
     * Academic field                   * Museum & gallery
     * Academic year                    * Music
     * Athletic                         * Other cultural
     * Ceremonies & recognitions        * Parties
     * Club & group meetings            * Recreational
     * Conferences & workshops          * Service & charitable
     * Film                             * Special academic matters
     * Holidays, etc                    * Theatre
     * Lecture                          * Training events
     * Local & area                     * University governance & structure

                Categories with a '*' are selected
              'a' to select all, 'n' to select none
              Use '+', '-', or space, to change fields
----------------------------------------------------------------------
The user can select any of the 20 fields as being on or off.
The program will search for records and display those that are within the
date range and are in the selected categories.  How can this be done 
given the current implementation of WWW and others like it? 

This kind of search is much easier for the user than having to 
interact with line oriented input.  It also produces a number of
implementation challenges.

Comments??

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************

From emv@garnet.msen.com  Sat Dec 19 02:04:24 1992
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20163; Sat, 19 Dec 92 02:04:24 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02329; Sat, 19 Dec 1992 02:18:18 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0n2sp4-001ID0C@garnet.msen.com>; Fri, 18 Dec 92 20:17 WET
Message-Id: <m0n2sp4-001ID0C@garnet.msen.com>
To: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Searching 
In-Reply-To: Your message of Fri, 18 Dec 92 15:26:25.
             <9212182126.AA24621@ukanaix.cc.ukans.edu> 
Date: Fri, 18 Dec 92 20:17:25 EST
From: Edward Vielmetti <emv@msen.com>

Lou,

Neither gopher nor world wide web currently have any mechanisms for
dealing with searches or retrievals that cover multiple different
selections.  That's not to say that the servers as they exist right
now aren't ready for it; it's just a matter of building a client
that has a "tag" command and then a "search on all tagged items"
or a "display merged list of all tagged directories". 

Given your design goals though I suspect that the implementation I
would use would be a usenet news feed and news readers with calendar
events posted by newsgroup and with subject lines that sorted appropriately
so the events showed up in order.  E.g.

	Newsgroups: ukans.events.film
	Subject: 92/12/16 It's a Wonderful Life, Parsons Hall, 7:30 pm $2
	From: cinemania@cs.ukans.edu (Cinemania Student Films)

	The classic Frank Capra movie, with a Rocky Horror twist -
	free entry with costume.

Once you have the data in this form you can cross-post to deal
with events that cross organization boundaries, build simple
gopher-to-nntp services that let people browse, and even deliver
selected pieces of information by e-mail so that people don't have
to learn anything more than their current mailer.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From fkappe@fiicmss01.tu-graz.ac.at  Sat Dec 19 11:02:09 1992
Return-Path: <fkappe@fiicmss01.tu-graz.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21472; Sat, 19 Dec 92 11:02:09 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22546; Sat, 19 Dec 1992 11:16:05 +0100
Received: by iicm.tu-graz.ac.at (5.57/Ultrix3.0-C)
	id AA25612; Sat, 19 Dec 92 11:16:11 +0100
Received: by fiicmss01.tu-graz.ac.at (4.1/Ultrix3.0-C)
	id AA04043; Sat, 19 Dec 92 11:19:55 +0100
Date: Sat, 19 Dec 92 11:19:55 +0100
From: fiicmss01!fkappe@dxmint.cern.ch
Message-Id: <9212191019.AA04043@fiicmss01.tu-graz.ac.at>
To: montulli@ukanaix.cc.ukans.edu
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Lou Montulli's message of Fri, 18 Dec 92 15:26:25 CST <9212182126.AA24621@ukanaix.cc.ukans.edu>
Subject: Searching

>>>>> On Fri, 18 Dec 92 15:26:25 CST, montulli@ukanaix.cc.ukans.edu (Lou Montulli) said:

Lou> The user can select any of the 20 fields as being on or off.
Lou> The program will search for records and display those that are within the
Lou> date range and are in the selected categories.  How can this be done 
Lou> given the current implementation of WWW and others like it? 

What you describe is (almost) exactly the way searches are performed in the
Hyper-G system. Unlike WWW or gopher, where the information provider has to
explicitly set up a search server for any collection of data that shall be
searchable, everything inserted into the Hyper-G system can immediately be
searched for. 

Hyper-G Documents are contained in a hierarchy of so-called collections
(somewhat similar to a directory structure as provided by gopher). The user may
'activate' any desired set of collections for search operations. The search will
then return only documents that are found in the active collections (and their
subcollections, recursively). 

If you want to give it a try, rlogin or telnet to 'finfo.tu-graz.ac.at' as user
'info', activate some collections with the 'ac(tivate)' command and perform a
simple search with the 'fi(nd) o(bject)' command. You may see a list of active
collections using the 'sh(ow active colls)' command and deactivate them with
'd(eactivate)'. For the user's convenience, it is sufficient to position the
cursor on a collection and issuing the 'find object' command in order to search
a single collection. To activate the whole document space, you may enter
'p(arents)' to get to the root collection and perform the seacrh from there.

Admittedly, the user interface for searches as it is now is kind of complicated
and for the more experienced users. Suggestions for improvements are welcome.
Keyword searches are currently performed only in the title of the document and
additional keywords. Full text search is currently not available, due to
problems with the WAIS server responsible for this. Also, please apologize the
absence of English manpages for the commands described above. If you are fluent
in German, however, you may switch the system to German saying 'la(nguage)
g(erman)' and have the full documentation available.

Frank

----------------------------------------------------------------------------
Frank M. Kappe                                     fkappe@iicm.tu-graz.ac.at
Institute for Information Processing and Computer Supported New Media (IICM)
                  Graz University of Technology, Austria
Voice: ++43/316/832551-22                               Fax: ++43/316/824394
----------------------------------------------------------------------------

From timbl@www3.cern.ch  Mon Dec 21 10:19:58 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28232; Mon, 21 Dec 92 10:19:58 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25575; Mon, 21 Dec 1992 10:33:58 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00227; Mon, 21 Dec 92 10:26:30 +0100
Date: Mon, 21 Dec 92 10:26:30 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212210926.AA00227@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Subject: Re: Searching
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>  From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
>  Date: Fri, 18 Dec 92 15:26:25 CST

>  WAIS searching is adequate for many applications but ergonomically 

>  it has a long way to go.  The currently search methods provided by 

>  WWW and Gopher are inadequate for many needs.

Lou,

I agree that a forms intreface is something they all lack, and there
have been a number of proposals to make documents into forms.
(The main problem is, we don't have editors yet. When we do, then
there will be plenty of work on forms.)

>  For an example, assume a hypothetical database for calendar information.
>  It is designed to allow the user to pick among a finite set of events 

>  and show them based on a date range.  A CWIS interface to the data
>  might look like the following.

In fact, your example is a good one for showing how flexible
W3 can be! See documentation with examples in 

http://info.cern.ch/hypertext/WWW/Provider/RadioButtons.html

Here's one of an infinite :-) number of ways of doing it.
Let's suppose the categories are called A-Z.  At any time the
user has a certain number of categories selected, and we
represent his screen at the time with the document name

	/Calendar/ABSGLMZ/Setup.html

When he is in this state, his screen shows something like that
below.  This is obviosly just a hypertext document generated by
the server in response to a request for /Calendar/ABSGLMZ/Setup.html.
I have represented link anchors with [brackets] here - think of it
with a point & click interface or a line-mode numeric selection.
  ----------------------------------------------------------------
        Welcome to The University of Kansas Events Server
  

            See [list of all these 569 events]
  

            Starting search date:  Dec, 18 1992
              Ending search date:  Jan, 18 1993
  

 This is a calendar of events in the following categories (select links
 to exclude them from the calendar)

   Academic field    [exclude]     Museum & gallery   [exclude]
   Academic year     [exclude]     Music              [exclude]
   Athletic          [exclude]     Other cultural     [exclude]

 There are 569 events in these categories: See complete [list],
 or type keywords.
 

 Other categories available as as follows (Follow links to include them
 in the calendar)
 

   Ceremonies & recognitions  [include]  Parties		  [include]  

   Club & group meetings      [include]  Recreational		  [include]  

   Conferences & workshops    [include]  Service & charitable     [include]  

   Film                       [include]  Special academic matters [include]  

   Holidays, etc              [include]  Theatre                  [include]  

   Lecture                    [include]  Training events          [include]  

   Local & area               [include]  University governance    [include]

You can also set the [start] and [end] search dates.
___________________________________________________________________________
The user can select any of the 20 fields as being on or off by following
links. It is as though there are 2**20 virtual calendars.  (The user is in fact
naviagting a hypercube here, which is exactly what (s)he does when using radio
buttons anyway. The user intreface is not changed in fact from a panel).
Here I have assumed that the "document" can accept searches, and we say that
any search text given will be taken as keywords. There are links to a few
other nodes:

 /Calendar/ASGLMZ/Setup.html    Identical except category B excluded (etc)
 /Calendar/ABCSGLMZ/Setup.html  Identical except category C included (etc)
 /Calendar/ABSGLMZ/Start.html   Identical except keywrds taken as start date
 /Calendar/ABSGLMZ/End.html     Identical except keywords taken as end date
 /Calendar/ABSGLMZ/List.html    Includes the list of events in categories

(I should have included the search dates in the string like
 /Calendar/921218/930118/ABSGLMZ/*.html but also I would advise in practice
 /Calendar/LastMonth/ABSGLMZ/*.html as a default)
 

>  How can this be done 

>  given the current implementation of WWW and others like it? 


You can see that the program to generate these pages is simpler than the
interactive CWIS program to write.

Another neat thing is that when the user has found the ideal combination,
she can put a bookmark on it, or make a link from her home page or any
other document to it.  With LastMonth as the search date, she can follow
this link to review the calendar any time.

>  :lou

Tim

From montulli@ukanaix.cc.ukans.edu  Tue Dec 22 01:19:27 1992
Return-Path: <montulli@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03792; Tue, 22 Dec 92 01:19:27 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26374; Tue, 22 Dec 1992 01:33:27 +0100
Received: by ukanaix.cc.ukans.edu (AIX 3.1/UCB 5.61/4.03)
          id AA30347; Mon, 21 Dec 92 18:32:00 -0600
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Message-Id: <9212220032.AA30347@ukanaix.cc.ukans.edu>
Subject: Re: Searching
To: timbl@nxoc01.cern.ch
Date: Mon, 21 Dec 92 18:31:59 CST
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9212210926.AA00227@www3.cern.ch>; from "Tim Berners-Lee" at Dec 21, 92 10:26 am
X-Mailer: ELM [version 2.3 PL2]

> 
> >  From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
> >  Date: Fri, 18 Dec 92 15:26:25 CST
> 
> >  WAIS searching is adequate for many applications but ergonomically 
> 
> >  it has a long way to go.  The currently search methods provided by 
> 
> >  WWW and Gopher are inadequate for many needs.
> 
> Lou,
> 
> I agree that a forms intreface is something they all lack, and there
> have been a number of proposals to make documents into forms.
> (The main problem is, we don't have editors yet. When we do, then
> there will be plenty of work on forms.)
> 
> >  For an example, assume a hypothetical database for calendar information.
> >  It is designed to allow the user to pick among a finite set of events 
> 
> >  and show them based on a date range.  A CWIS interface to the data
> >  might look like the following.
> 
> In fact, your example is a good one for showing how flexible
> W3 can be! See documentation with examples in 
> 
> http://info.cern.ch/hypertext/WWW/Provider/RadioButtons.html
> 
> Here's one of an infinite :-) number of ways of doing it.
> Let's suppose the categories are called A-Z.  At any time the
> user has a certain number of categories selected, and we
> represent his screen at the time with the document name
> 
> 	/Calendar/ABSGLMZ/Setup.html
> 
> When he is in this state, his screen shows something like that
> below.  This is obviosly just a hypertext document generated by
> the server in response to a request for /Calendar/ABSGLMZ/Setup.html.
> I have represented link anchors with [brackets] here - think of it
> with a point & click interface or a line-mode numeric selection.
>   ----------------------------------------------------------------
>         Welcome to The University of Kansas Events Server
>   
> 
>             See [list of all these 569 events]
>   
> 
>             Starting search date:  Dec, 18 1992
>               Ending search date:  Jan, 18 1993
>   
> 
>  This is a calendar of events in the following categories (select links
>  to exclude them from the calendar)
> 
>    Academic field    [exclude]     Museum & gallery   [exclude]
>    Academic year     [exclude]     Music              [exclude]
>    Athletic          [exclude]     Other cultural     [exclude]
> 
>  There are 569 events in these categories: See complete [list],
>  or type keywords.
>  
> 
>  Other categories available as as follows (Follow links to include them
>  in the calendar)
>  
> 
>    Ceremonies & recognitions  [include]  Parties		  [include]  
> 
>    Club & group meetings      [include]  Recreational		  [include]  
> 
>    Conferences & workshops    [include]  Service & charitable     [include]  
> 
>    Film                       [include]  Special academic matters [include]  
> 
>    Holidays, etc              [include]  Theatre                  [include]  
> 
>    Lecture                    [include]  Training events          [include]  
> 
>    Local & area               [include]  University governance    [include]
> 
> You can also set the [start] and [end] search dates.
> ___________________________________________________________________________
> The user can select any of the 20 fields as being on or off by following
> links. It is as though there are 2**20 virtual calendars.  (The user is in fact
> naviagting a hypercube here, which is exactly what (s)he does when using radio
> buttons anyway. The user intreface is not changed in fact from a panel).
> Here I have assumed that the "document" can accept searches, and we say that
> any search text given will be taken as keywords. There are links to a few
> other nodes:
> 
>  /Calendar/ASGLMZ/Setup.html    Identical except category B excluded (etc)
>  /Calendar/ABCSGLMZ/Setup.html  Identical except category C included (etc)
>  /Calendar/ABSGLMZ/Start.html   Identical except keywrds taken as start date
>  /Calendar/ABSGLMZ/End.html     Identical except keywords taken as end date
>  /Calendar/ABSGLMZ/List.html    Includes the list of events in categories
> 
> (I should have included the search dates in the string like
>  /Calendar/921218/930118/ABSGLMZ/*.html but also I would advise in practice
>  /Calendar/LastMonth/ABSGLMZ/*.html as a default)
>  
> 
> >  How can this be done 
> 
> >  given the current implementation of WWW and others like it? 
> 
> 
> You can see that the program to generate these pages is simpler than the
> interactive CWIS program to write.
> 
> Another neat thing is that when the user has found the ideal combination,
> she can put a bookmark on it, or make a link from her home page or any
> other document to it.  With LastMonth as the search date, she can follow
> this link to review the calendar any time.
> 
> >  :lou
> 
> Tim
> 
Sorry for the long intro but it is relevent to the message.

This interface is problimatic in that it will be extremly slow to navigate.
To turn on or off the 20 different catagories, the user would have to
navigate 20 different screens of data, waiting for the transfer and the
repaint for each one.  I also think that this program would be as hard or
harder to write than the original, although it does give data that the 
client can display natively.  

I believe this is a case where you will have to give the client a little
more smarts than before.  A template could be designed that intructs the
client on how to query the user in several ways.  The client would make
all the relevent queries itself and then query the server.  This could
look something like this:
-------------------------------------------------------
      Welcome to The University of Kansas Events Server

          Press return at any time to show events.

          Starting search date:  <field_name:s_date  query_type:date>
            Ending search date:  <field_name:e_date  query_type:date>

                          Categories
  <field_name:Acad  query_type:boolean  init_val:on>Academic field
  <field_name:Acad  query_type:boolean  init_val:on>Academic year
  <field_name:Athl  query_type:boolean  init_val:on>Athletic    
  <field_name:Cere  query_type:boolean  init_val:on>Ceremonies & recognitions
  <field_name:Club  query_type:boolean  init_val:on>Club & group meetings   
  <field_name:Conf  query_type:boolean  init_val:on>Conferences & workshops
  <field_name:Film  query_type:boolean  init_val:on>Film                  
  <field_name:Holi  query_type:boolean  init_val:on>Holidays, etc        
  <field_name:Lect  query_type:boolean  init_val:on>Lecture             
  <field_name:Loca  query_type:boolean  init_val:on>Local & area       

----------------------------------------------
The client would replace the links shown with the appropriate objects
such as radio buttons or stars or however the client wished to represent
a boolean type.  The date type would be handled in the same way.

When the user was satisfied with his selections he would activate the 
search and the client would pass back the values of all the fields to
the server.

This represents considerably more effort in the development of the client,
but it makes the development of database servers much, much easier.  I
suspect the one time effort of adding it to a client is much better in
the long run than the effort of adding it to every database server.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************


From timbl@www3.cern.ch  Tue Dec 22 11:44:27 1992
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00331; Tue, 22 Dec 92 11:44:27 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15220; Tue, 22 Dec 1992 11:58:35 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01063; Tue, 22 Dec 92 11:51:09 +0100
Date: Tue, 22 Dec 92 11:51:09 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9212221051.AA01063@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: CERN WWW service over Christmas shutdown
Reply-To: timbl@nxoc01.cern.ch


CERN has its traditional power-saving salary-saving shutdown over Christmas
and the new year.  During this time the WWW server on info.cern.ch should
(I hope!) continue running and still be connected with the outside world.
The basic web overviews by subject etc will therefore be available, as will
be anonymous FTP and telnet services.

The computer center however and the servers in the ECP division will
shut down, so some CERN-related information will be unavailable for all or part  
of the period from today to the 5th January. Please accept our apologies for  
such missing services.

A merry festive season and a productive 1993 to all our readers!

	Tim Berners-Lee

__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web team leader           (NeXTMail is ok)	
CERN, CN Division                     Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155



From dsr@hplb.hpl.hp.com  Tue Jan  5 08:46:24 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00184; Tue, 5 Jan 93 08:46:24 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13550; Mon, 4 Jan 1993 15:11:39 +0100
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA09547 (5.65b/CWI-2.200); Mon, 4 Jan 1993 15:11:31 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 4 Jan 93 14:07:17 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA08999; Mon, 4 Jan 93 14:11:25 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301041411.AA08999@manuel.hpl.hp.com>
Subject: Re: HTTP2 spec
To: timbl@www3.cern.ch
Date: Mon, 4 Jan 93 14:11:19 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.25]

> allowing such extensions as
>
>        GET /junk/mydoc  HTRQ/1.0
>        From: Tim Berners-Lee <timbl@info.cern.ch>
>        Accept: text/plain, text/html, image/GIF(0.0,.5)
>        Accept-Encoding: X-Compress, base64, X-tar, X-Nextmail
>        
> with reponse
>
>        HTTP-Version: 1.0
>        Response: OK
>        MIME-Content-type: image/GIF
>        Allow: GET, PUT, TEXTSEARCH
>        Public: GET, TEXTSEARCH
>
>etc etc.

I hope to give more detailed feedback soon, but an immediate suggestion is
to include a size field giving the number of bytes in the complete message
(or an estimate). This would allow the browser to show a gauge indicating
how much of the message has been received at any time (I want to temporarily
replace the vertical scroll bar by a bas-relief thermometer). The gauge
would only be shown if this size field is present.

This is helpful when getting a large document or when the comms link is
slow, e.g. if you are using a modem link. An additional benefit is in
helping the browser to manage its resources more effectively, e.g.
reduce need for reallocs and when to use a disk buffer rather than a memory
image for very large documents.

A second suggestion to improve the ergonomics of WWW is to let users know
when an expensive operation is being conducted by the server, e.g. document
format conversion, complex database search, or access via a "slow" gateway.
The underlying principle is that users don't mind if performance is slow
provided they know what to expect.

My suggestion is that part of the message header is sent before beginning
the document conversion (or whatever). The remainder and the document body
content is sent later. The part of the header sent earlier on includes a
processing attribute, e.g. "Processing: converting to html ..."

Best wishes for a happy new year,

Dave Raggett, hplabs, England

From dsr@hplb.hpl.hp.com  Tue Jan  5 12:57:06 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02448; Tue, 5 Jan 93 12:57:06 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04314; Tue, 5 Jan 1993 13:12:30 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 5 Jan 93 12:08:59 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA20032; Tue, 5 Jan 93 12:13:11 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301051213.AA20032@manuel.hpl.hp.com>
Subject: HP's SGML hypertext help system
To: www-talk@nxoc01.cern.ch
Date: Tue, 5 Jan 93 12:13:08 GMT
Mailer: Elm [revision: 66.25]

Long description of HP HelpTag SGML format for hyptertext help system
=====================================================================

I have just been shown HP's new hyptext help system for VUE 3 (HP's user
desktop environment for X11, Motif). It uses SGML for the authoring language
and is a very professionally package. The group may be interested in its
scripting language which has a lot of similarities with HTML, although it
isn't a networked application.

Unlike WWW, the HP Help system requires you to compile the source files. It
does this to compile keyword indexes and to provide a more compact format.
The HP Help system's features appear to draw heavily on Microsofts help
system for Windows 3 on the PC.

For full information order the "HP Help System Developer's Guide"
part number B1171-90055 from an HP supplier.

Summary features:

    o   multi font
    o   multi language  (defaults to ISO 8859-1 character set)
    o   resizeable - reformats to match new window size
    o   keyword indexes (see below)
    o   glossaries
    o   hypertext links to anchors in same and other help volumes
    o   figures with captions (tiff, x bitmap, x pixmap, x window dump: xwd)
    o   small inline graphics
    o   optional text flow around figures
    o   control over launching new window or changing view in current window
    o   It doesn't support networked hypertext links.
    o   richer use of SGML than HTML
    o   metainfo section at front of help volume

The keyword index mechanism is similar to that on Windows 3. You choose
search from a menu, and a dialog box appears. The index is an alphabetical
list of important words and phrases along with a list of each occurrence in
the help volume.

The dialog allows you to type the first few letters and see matching
keywords. You can then click on a keyword to see a list of matching topics.
You then click on a topic name to view that topic. This approach allows
you to explore what keywords are available, unlike the W3 and WAIS approach
which leave you in the dark!

Glossary terms are shown with a dashed underline. Clicking on such a term
pops up a small dialog box with an explanation from the glossary. The
glossary itself is defined separately, rather than embedding each
explanation with each term.

Help volumes have the following generic structure:

<helpvolume>

    <metainfo>

    <title> Volume title

    <copyright>
    Copyright topic goes here ...

    <abstract>
    The abstract describing your help system goes here.

        .
        .   There may be other meta information topis.
        .

    <\metainfo>

    <hometopic> Home topic title
                Body of home topic goes here ...

        <s1> Title of First Subtopic goes Here
             Body of first subtopic goes here ...

        <s2> Title of Second Subtopic goes Here
             Body of second subtopic goes here ...

         .
         .
         .

    <glossary>
    The body of the glossary, which contains term definitions, goes here ...

<\helpvolume>


Notes:
=====

    a)  The ETAGO (end tag open) uses "<\" rather than "</"

    b)  frequent use is made of entity declarations
        e.g. <!entity MyPic FILE "picture.tif">

    c)  &< gives "<", &\ gives "\", && gives "&"

    d)  title text is typically terminated by end of line
        rather than an end tag, e.g. <hometopic>

    e)  many tags support an id attribute for defining anchors
         <chapter>, <figure>, (idx>, <image>, <item>, <location>,
         <otherfront>, <p>, <rsect>, <s1> ... <s9>

    f)  many tags support the shorthand <tag|text| for <tag>text<\tag>


The full set of tags is:

    Meta info:

    <metainfo> ... <\metainfo>
    <title>
    <copyright>
    <abstract> ... <\abstract>
    <otherfront>        (other front matter)

    Structure of a help volume:

    <!entity>
    <helpvolume> ... <\helpvolume>
    <hometopic>
    <chapter>
    <s1> ... <s9>       (headings introducing topic in the hierarchy)
    <rsect>             (reference section)
    <rsub>              (reference subsection heading)
    <otherhead>
    <procedure>         (starts a section within a topic)
    <p>                 (paragraph, optionally wrapped around a graphic)

    Inline elements:

    <book> ... <\book>
    <computer> ... <\computer>  (shorthand ``text'')
    <emph> ... <\emph>  (emphasis - shorthand !!text!!)
    <ex> ... <\ex>      (example)
    <vex>               (verbatim example)
    <image> ... <\image> (keep line breaks, no wrapping or justification)
    <term>text<\term>   (occurrence of glossary entry - shorthand ++text++)
    <user>response<\user> (distinguishes user input in example dialog)
    <var>text<\var> (distinguishes user supplied variable, shorthand %%text%%)
    <newline>           (starts a newline within same paragraph)
    <p>                 (paragraph, optionally wrapped around a graphic)
    <quote>text<\quote> (language dependent directional quote marks)
    &....;              (see <!entity>)

    Important information:

    <note> ... <\note>           (can use a standard icon)
    <caution> ... <\caution>     (can use a standard icon)
    <warning> ... <\warning>     (can use a standard icon)
    <emp> ... <\emph>  (emphasis - shorthand !!text!!)

    Lists:

    <list> ... <\list>
    <item>              (for <list>, shorthand *)
    <lablist> ... <\lablist> (labeled list)
    <labheads>          (list headings for lablist)

    Graphics:

    <figure> ... <\figure> (captioned figure)
    <graphic>           (small graphic embedded in text line)

    Glossary and keyword index:

    <glossary>
    <dterm>             (definition of term)
    <term>              (occurrence of glossary entry - shorthand ++text++)
    <idx> ... <\idx>    (defines entry to occur in the keyword index)

    Cross-references and hyperlinks:

    <xref id>            (hyperlink to given anchor point in this volume)
    <link> ... <\link>
    <location> ... <location>   (defines anchor point)
    <term>

    Hidden text:

    <!-- ... -->        (comment)
    <memo> ... <\memo>

    Titles and headings:

    <abbrev>            (used in help dialog in place of long heading)
    <head>
    <otherhead>
    <procedure>

    Override meaning of HelpTag markup:

    <esc> ... <\esc>    (escape from markup recognition)
    <vex>               (verbatim example, no tags are recognised)

From marca@wintermute.ncsa.uiuc.edu  Tue Jan  5 17:44:05 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04738; Tue, 5 Jan 93 17:44:05 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24424; Tue, 5 Jan 1993 17:59:31 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03650
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 5 Jan 93 10:58:57 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA26283; Tue, 5 Jan 93 11:00:21 -0800
Date: Tue, 5 Jan 93 11:00:21 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301051900.AA26283@wintermute.ncsa.uiuc.edu>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTTP2 spec
In-Reply-To: <9301041411.AA08999@manuel.hpl.hp.com>
References: <9301041411.AA08999@manuel.hpl.hp.com>

Dave_Raggett writes:
> I hope to give more detailed feedback soon, but an immediate suggestion is
> to include a size field giving the number of bytes in the complete message
> (or an estimate). This would allow the browser to show a gauge indicating
> how much of the message has been received at any time (I want to temporarily
> replace the vertical scroll bar by a bas-relief thermometer). The gauge
> would only be shown if this size field is present.

I agree; a size field is almost essential -- particularly considering
how big hypermedia documents are going to get.

> My suggestion is that part of the message header is sent before beginning
> the document conversion (or whatever). The remainder and the document body
> content is sent later. The part of the header sent earlier on includes a
> processing attribute, e.g. "Processing: converting to html ..."

Another possibility for increased ergonomics is to provide for the
transfer of the first several paragraphs of a large document prior to
transfer of the rest of the document, so the use has something to look
at while the bulk of the communication is taking place.

Cheers,
Marc


From romig@cis.ohio-state.edu  Wed Jan  6 12:08:57 1993
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10967; Wed, 6 Jan 93 12:08:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02938; Thu, 24 Dec 1992 06:19:58 +0100
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA01852; Thu, 24 Dec 92 00:19:56 -0500
Date: Thu, 24 Dec 92 00:19:56 -0500
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9212240519.AA01852@brachiosaur.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re:  Questions about WAIS, WAISGate

Turns out that using a rule file in waisgate is a Big Win.  I have a
rule file that looks like this:

  map /n/abyss/2/doc/rfc-src/* http://www.cis.ohio-state.edu:82/rfc/*.html
  map /n/dinosaur/0/doc/text/* http://www.cis.ohio-state.edu:80/hypertext/*
  map /n/abyss/2/doc/man-src/* http://www.cis.ohio-state.edu:80/man/*
  map /usr/spool/news/*	     http://www.cis.ohio-state.edu:80/usr/spool/news/*

I changed WAISGate to tear the WAIS docid apart and pass the
distributor local path to HTTranslate.  If it matches, it gets
rewritten.  If rewritten, the address is used as is, else it goes
through the usual waisgate things.  This way I can index things that
are really served through a gateway of some sort (eg, a rfc converter
that we just wrote).

I'll post the stuff next week sometime.  If you're interested, see 
<A HREF="http://www.cis.ohio-state.edu:80/hypertext/information/information.html">. 
There are the usual links to things there, plus hypertext versions of
man pages, RFCs, IENs and FAQ's from news.answers.  Tom's working on
something to parse the FAQ files into something more reasonable.  I'm
working on a gateway for our problem reporting system (so that a
hypertext article about our current status could refer people to
problem reports for more details) and other misc. stuff.  If you have
comments or suggestions, we'd love to hear them!

Does someone have stuff for converting emacs info to html?  I thought
I saw some references to something, but can't find them now.

--- Steve

From guido@cwi.nl  Wed Jan  6 12:17:22 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11009; Wed, 6 Jan 93 12:17:22 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17798; Wed, 6 Jan 1993 12:32:16 +0100
Received: from voorn.cwi.nl by meermin.cwi.nl with SMTP
	id AA19025 (5.65b/3.5/CWI-Amsterdam); Wed, 6 Jan 1993 12:32:13 +0100
Received: by voorn.cwi.nl with SMTP
	id AA28944 (5.65b/3.5/CWI-Amsterdam); Wed, 6 Jan 1993 12:32:12 +0100
Message-Id: <9301061132.AA28944.guido@voorn.cwi.nl>
To: Steve Romig <romig@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Questions about WAIS, WAISGate 
In-Reply-To: Your message of "Thu, 24 Dec 1992 00:19:56 MET."
             <9212240519.AA01852@brachiosaur.cis.ohio-state.edu> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Wed, 06 Jan 1993 12:32:11 +0100
Sender: Guido.van.Rossum@cwi.nl

>Does someone have stuff for converting emacs info to html?  I thought
>I saw some references to something, but can't find them now.

I have stuff for converting *texinfo* to html.  You should be able to
watch the result starting at

	http://voorn.cwi.nl/texinfo/dir.html

Mail me if you want the source (it's written in a less than well-known
language, Python, for which you'll need to get an interpreter first).

Cheers,

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From jim@wilbur.njit.edu  Wed Jan  6 12:26:17 1993
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11099; Wed, 6 Jan 93 12:26:17 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08026; Thu, 24 Dec 1992 17:43:53 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA26427; Thu, 24 Dec 92 11:43:52 -0500
Message-Id: <9212241643.AA26427@njitgw.njit.edu>
Received: by wilbur.njit.edu; Thu, 24 Dec 92 11:41:55 est
Date: Thu, 24 Dec 92 11:41:55 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: montulli@ukanaix.cc.ukans.edu, www-talk@nxoc01.cern.ch
Subject: Re:  Searching

We will use an INPUT tag to do that kind of searching in addition to other
data collection tasks.

It will be equivalent to sayint the first key is the starting date, the 
second is the ending date etc.

From archie-people-request@kona.cc.mcgill.ca Wed Jan  6 14:39:59 1993
Return-Path: <archie-people-request@kona.cc.mcgill.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11838; Wed, 6 Jan 93 14:39:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00749; Wed, 6 Jan 1993 14:54:29 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22830; Wed, 6 Jan 1993 14:54:12 +0100
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09892; Thu, 24 Dec 1992 22:28:50 +0100
Received: by kona.cc.mcgill.ca (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA29096  on Thu, 24 Dec 92 14:39:32 -0500
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA29086  (mail destined for /usr/lib/sendmail -odq -oi -farchie-people-request archie-people-out) on Thu, 24 Dec 92 14:34:19 -0500
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA11483; Thu, 24 Dec 92 14:24:25 EST
Message-Id: <9212241924.AA11483@expresso.cc.mcgill.ca>
In-Reply-To: Alan Emtage's message as of Dec 18,  1:03
From: peterd@bunyip.com (Peter Deutsch)
Date: Thu, 24 Dec 92 19:24:23 GMT-0:02
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: archie-3@bunyip.com, archie-people@bunyip.com, archie-interest@bunyip.com
Subject: Re: Seasons Greetings
Cc: wamapi@bunyip.com, wheelan@java.cc.mcgill.ca


   ----------< Bunyip News (year-end edition) >------------


A warm and non-denominational Season's Greetings to all!

Alan has already sent out our "Bunyip Xmas Card", but I'd
like to add a few words, as well. In particular, I thought
I'd share some news about where we are and where we're
going in the next little while with you who have help so
much in supporting our little enterprise. In all the
excitement of getting a company off the ground it's
sometimes easy to loose sight of where we're heading and
so I'd like to spend a few minutes checkpointing our
progress with those of you who have done so much to get us
where we are today.


New Additions to the Gang...
-----------------------------

Bunyip has definitely taken on a life of its own, with not
one, but two new employees joining the family full time in
the past two months.

Wanda Pierce began working for us full time in October and
will concentrate her initial efforts on product
development for a range of Internet user clients. Alan and
I have worked both back at the McGill School of Computer
Science for nearly five years and during our stay at the
McGill Computing Centre over the past 18 months, so she
_should_ know what she's getting into!  :-)

We have now embarked upon a rather ambitious program to
develop client tools to help ensure better access to
Internet information and Wanda will play a strategic role
in making sure are products in this area do what real
people want them to do. She has a interesting mixed
background in both Computer Science and Fine Arts and has
been tasked with keeping the company's techno-weenies in
line whenever she detects that they are forgetting the
needs of the "real" people using our programs.

We don't want to say too much more about this effort at
this point (basically, because we don't want to promise
vapourware) but hope to have more concrete announcements
about our information clients later in the coming year.

Bill Heelan has also joined the gang full time as of this
week to work on systems programming for a variety of
projects. Again, we have all worked together while at the
School of Computer Science and so he, too has been given
fair warning of what he's in for...

Those who have been following the archie story closely
(and like to read the credits at the end while everyone
else is filing out of the cinema) will recognize Bill as
one of the authors of the original archie implementation.
When we first decided to open Alan's nifty little database
to the world Bill was responsible for the first telnet
archie client program and as his first task for Bunyip has
taken over the final push to get the long-promised new
version of this component out the door.

This particular task has been in my lap for the past
several months but has languished "almost finished" for
some time as I've been swamped with company business (such
as organizing our orderly departure from the university,
negotiating final details with McGill for network access
after we move on in January, locating our new premises,
shopping for furniture, bookkeeping, etc).  I'm very
pleased to have Bill on line for "real work" since I'm
obviously going to devote more and more of my time to such
paper shuffling. The sad part is I can't get any sympathy
out of the rest of the gang for all the dross I help save
them from!

We estimate that we need only a few days of work to get
the last pieces of the client (output formatting and
paging) working and we're now hoping to get an initial
release of this badly needed piece out to the archie sites
at the start of January. This will give archie operators a
telnet client that speaks Prospero to the server (as do
all the freeware archie clients), reducing demand on
resources and giving better control over the load an
archie will put on your system.


Other archie news..
--------------------

So far, all but one of the original operators of archie
have taken on the supported version (and we're still
hoping to make that 100 percent in January!). In addition,
of course, there are a number of new additions to the
family who should be going operational in the new year.
We're obviously far from done developing archie and we'd
especially like to extend a big "Thank You" for this vote
of confidence to our customers in what is obviously still
an embryonic product line.

The current schedule calls for a number of improvements to
archie in the next month, including the long-awaited new
release of the telnet client. This will feature, among
other improvements, the new Prospero interface to reduce
the demand upon system resources plus the changes needed
to provide multiple language support. The Help system has
been completely redone (making it much easier to extend or
modify the Help text) and we've also added a ".archierc"
file to allow sites to better customize their installation.

Of course, as Alan has written earlier, there are also a
number of new additions at the server end, including
support for domain specific searches, plus pathname limits
on searches (allowing the user to specific only files that
match _and_ contain specific strings in the directory
path). This code is implemented in the current release but
is awaiting the final freeze on the Prospero protocol to
allow the clients to use it. Long promised, we're hoping
for good news on this from the Prospero group shortly.

We have also received a commission from one of the local
universities to prepare and operate a French-language
archie here in Montreal for an initial period of five
months. As part of this deal we will be able to license
the French translation to those needing it for an
additional fee.

Although we don't have plans to prepare additional
translations ourselves at this point, the telnet client is
being reworked specifically to make it easier to prepare
and operate foreign-language version for those customers
who wish to implement their own help text. Details will be
made available to those licensees who might be interested
in preparing their own text when the telnet client ships,
and of course we would be happy to investigate the
possibilities for translations of our text, if you'd
prefer.

Future plans also call for multiple database support,
greater browsing capability and a few more gadgets, but
these additional features are being held for the next
release, which will follow once Bill has it ready to roll.
We realize how important it is to get the Prospero client
out the door and don't want to hold up the release for
features which are less in demand at this point. Still,
the hooks are now in place and it is not expected to take
too long to fold them in and get a follow-up release out,
as well. As usual, your suggestions for further
improvements and additions are welcome.


New Services...
---------------

Also planned for January are at least one and hopefully
several new freely-available archie databases built using
the additional data-gathering and client capabilities of
the new release. Pending final approval after the holiday
period we appear to have secured a site here in Montreal
to host this new service and with Bill on board we finally
have the time needed to get this off the ground.

Once we have things up and running we plan to make the
additional data-gathering scripts available to archie
licensees wishing to extend their offerings. As with the
anonFTP database, we will be offering coordination and
communications services as part of our archie system
support. We'll post details of the new databases to the
archie-maint list in (hopefully) late January and those of
you with licenses can then decide if they want to extend
your range of wares. More on this below...


Other Projects...
------------------

As they say "Bunyip does not discuss unannounced projects"
but we have a number of other activities we are involved
in that we'd like to let you know about.


IETF:

Our largest timesink, outside of our efforts on archie of
course, is the volunteer work we do through the IETF. Both
Alan and I have been heavily involved with such efforts in
the past year and plan to continue this work in 1993.

Alan and I co-chaired the "Internet Anonymous FTP
Archives" working group to develop standardized templates
for entering descriptive information into anonFTP
archives. This working group came to completion at the
Washington IETF in October (or was it November? It's all
becoming a blur!) and we will now be coordinating efforts
to get such templates filled out and distributed on the
Internet throughout 1993.

Several volunteer sites have agreed to act as repositories
for such templates so smaller sites need not fill in
templates for the most common or popular packages (and to
help avoid wasteful duplication or misclassification
during the cataloging phase). A mailing list is also being
set up to coordinate donations and otherwise help the work
along.

Alan and I are also working closely with others in the
field of Internet resource discovery and access on a
number of basic research issues. Perhaps the most urgent
of these involve attempts to define and standardize
mechanisms for naming and referencing objects in an
internet environment.

Working with Joyce Reynolds and Russ Hobby (IETF Area
Directors for User Services and Applications,
respectively) Alan and I inaugurated a new working group
at the last session to develop what is currently being
referred to as "Uniform Resource Identifiers", which in
our lexicon include both "Locators" (pointers to
resources) and "Names" (a more nebulous concept, but
conceptually a location-independent identifier of the
information content of an object). Alan will co-chair the
working group with Jim Fullton of CNIDR, while I plan to
take an activist role as an advocate for a particular
mechanism for defining and creating URIs. For example, I
am currently working on a paper with Chris Weider of Merit
which will be our proposal for URNs.

This work is of more than academic interest to us here at
Bunyip since we plan to migrate all our Internet-based
projects towards the use of URIs as soon as they are
standardized. This would allow client programs, for
example, to perform searches in archie and directly pass
off the identifiers returned to compliant systems without
further processing or conversion. We have high hopes for
URIs and their component parts in the next few years as an
integrating force for future Internet tool development and
plan to keep Bunyip at the forefront of such development
work.


The WHOIS++ project:

Another major project of mine at the moment (and hopefully
a future product line for Bunyip) is my participation in
the WHOIS++ effort. This project came about as a result of
a BOF at the Boston IETF in July, in which a number of
people participated in an examination into the reasons for
the lack a practical directory service for the Internet.
X.500, which was supposed to fill this role, has never
taken off and there are still a number of major
impediments to its success.

After this BOF illuminated the problems (which seems as
much political as technical at this point), a small group
of us, including Joan Gargano of UCDavis, Jim Fullton of
CNIDR, Chris Weider of Merit, Simon Spero of UNC-Chapel
Hill and myself set out to architect and deploy a
light-weight and practical directory service that could
address the problems we see holding back x.500.

We believe that so far we've made excellent progress, with
no less than three papers now in draft form that explain
our solution starting down the path through the IETF
towards eventual RFC status. A new working group (the
WHOIS and Network Information Lookup Service Working
Group) has been set up to coordinate this work and had its
first meeting in Washington.

The heart of the new service (currently called "WHOIS++"
in honour of our original modest ambition to develop a
follow-on to the existing NIC WHOIS service) is a flexible
template oriented data model and an architecture that
allows the operator to use any database system desired for
holding the information to be served. The new system has
now moved far beyond its original modest goals, allowing
operators to define and serve _any_ template-like
information they desire.

We obviously hope and expect at least some sites to pick
up, index and serve collections of the newly created IAFA
templates. This will allow serving collections of
information about users, services, software packages and
more to the entire Internet. In addition to more extensive
and useful databases of information about anonFTP, we
foresee a range of other useful collections and a demo
facility for this service is an important part of our
plans for the

A pilot implementation of WHOIS++ is now deployed
at several sites for testing and our plan is to release the
public domain implementation of our work in January or
February.

Here at Bunyip we intend to offer a combination of archie
and a supported version of a WHOIS++ server as a new
addition to our product line, with preferential pricing
for those who already have archie to enable you to offer
distributed directory support at your site if you want it.
Details on this should be available in February or March.

The Buddy Project:

Alan is now working with Carl Malamud and others to set up
a "buddy project", in which individuals and institutions
will be able to act as sponsors or coordinators for
donations and other assistance aimed at newly connected
sites, especially in the developing world.  Alan has
already sent a first collection of donated books and other
materials to Estonia and as one of their first enlisted
volunteers I am currently gathering material to forward to
the University of Swaziland. In the new year.

It is hoped that this work will become a sponsored project
of the Internet Society, with a number of individual
coordinating projects feeding badly needed material where
it will do the most good. In the long run, Carl and Alan
have ambitious plans for organizing donations of
educational material and even hardware directly from
manufacturers, but to me the greatest potential in their
plans is for making available the expertise of individuals
to those who need it most. I expect we'll be hearing much
more about this project in 1993.



The Wrap-Up...


Well, that's a quick survey of the activities of Bunyip
over the past year, along with a few pointers towards
where we hope to see the company go in the new year. Now
we have Wanda and Bill on staff we expect to be able to
offer a much better level of user support to our existing
client base, while continuing the all-important research
and develop into new tools and services that we must
perform to keep alive (and keep up with the demand from
our users for a more useful Internet). I'd be happy to
pass on further information on any of the development
projects we're participating in through the IETF, and
would encourage anyone who is interested to join the
appropriate mailing lists and get involved. Even if you
can't make it to the meetings, you can have a real impact
on development with your comments and suggestions.



Peter's Soapbox
----------------

As for us, we promise to try to extract every possible
drop out of the funding we're receiving through archie
license fees to push out both an improved archie and our
related follow-on products. As I mentioned at the
beginning of this note, we're very grateful for the early
(and tangible!) support our licensees have show us and
will do our best to deliver value for money. Although we
are playing in perhaps one of the most interesting and
complex technological sandboxes available today, we
definitely hope to be perceived as a "people" company,
offering quality products and responding to our customer's
needs. 

As a small start-up it will obviously be hard to always
fulfill expectations but we're going to give it our best
shot. If we're _NOT_ performing up to scratch, please tell
us.  And if we are, as they say "Tell your friends"!

Enough drivel - may you all enjoy a happy holiday season
and a prosperous and successful new year.



			Peter (speaking on behalf of Alan,
			Wanda and Bill, plus Alan's fish
			which are doing better last time we
			checked, now that the filter is
			working properly...)

-- 

From timbl@www3.cern.ch  Wed Jan  6 17:38:48 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13642; Wed, 6 Jan 93 17:38:48 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20147; Wed, 6 Jan 1993 17:53:43 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01883; Wed, 6 Jan 93 17:53:41 +0100
Date: Wed, 6 Jan 93 17:53:41 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301061653.AA01883@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Denis DeLaRoca (310) 825-4580 <CSP1DWD@mvs.oac.ucla.edu>
Subject: Bug fix for WWWLibrary -- crashed with TechInfo gateway.
Cc: www-talk@nxoc01.cern.ch, www-bug@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Happy New year everyone...

Ooops!

The problem is in HTML.c, there should be an UPDATE_STYLE in as first line of  
list_element -- if not, a pargraph mark is written to a nonexistent text  
object. Happens when the very first printable thing is a list element.
Fixed routine is:

PRIVATE void list_element  ARGS3(void *, this, HTTag *,t, HTElement *,e)
{
    UPDATE_STYLE;
    if (e->tag != &tags[DIR_TAG])
	HText_appendParagraph(THIS->text);
    else
        HText_appendCharacter(THIS->text, '\t');	/* Tab @@ nl for UL? */
    THIS->in_word = NO;
}


It'll be fixed in the next release. 1.1a of the library, I suggest you fix this  
in your code now for speed.

	Tim

Begin original message:

Date:    Wed, 06 Jan 93 08:25 PST
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>

Happy new year!

I just tried this TechInfo gateway... after selecting MIT from the
opening menu my WWW client crashes badly (my MVS port), so does the
sun3 version (fat core dump). Could you look into this?

-- Denis



From emv@garnet.msen.com  Wed Jan  6 19:22:45 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14775; Wed, 6 Jan 93 19:22:45 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24413; Wed, 6 Jan 1993 19:37:40 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0n9fdA-001ID4C@garnet.msen.com>; Wed, 6 Jan 93 13:37 WET
Message-Id: <m0n9fdA-001ID4C@garnet.msen.com>
To: Steve Romig <romig@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Questions about WAIS, WAISGate 
In-Reply-To: Your message of Thu, 24 Dec 92 00:19:56.
             <9212240519.AA01852@brachiosaur.cis.ohio-state.edu> 
Date: Wed, 06 Jan 93 13:37:13 EST
From: Edward Vielmetti <emv@msen.com>

nice work steve!

i hacked up a converter for the nearnet trouble tickets and trouble
status reports ("finger ticket-open@nic.near.net", imagine turning each
of those references into a link to a "finger
ticket-nnnn@nic.near.net".)  never finished it (since i don't work
anywhere near nearnet!) but the idea seemed sound.

--Ed

From romig@cis.ohio-state.edu  Wed Jan  6 21:35:10 1993
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16014; Wed, 6 Jan 93 21:35:10 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27493; Wed, 6 Jan 1993 21:50:05 +0100
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA03059; Wed, 6 Jan 93 15:49:53 -0500
Date: Wed, 6 Jan 93 15:49:53 -0500
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9301062049.AA03059@brachiosaur.cis.ohio-state.edu>
To: emv@msen.com
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Edward Vielmetti's message of Wed, 06 Jan 93 13:37:13 EST <m0n9fdA-001ID4C@garnet.msen.com>
Subject: Questions about WAIS, WAISGate 

> nice work steve!

Thanks.  Its been fun, taking off-the-shelf stuff (w3 daemons and
browsers, wais) and writing small conversion scripts.  

>i hacked up a converter for the nearnet trouble tickets and trouble
>status reports ("finger ticket-open@nic.near.net", imagine turning each
>of those references into a link to a "finger
>ticket-nnnn@nic.near.net".)  never finished it (since i don't work
>anywhere near nearnet!) but the idea seemed sound.

We're hoping to do something like that.  I have a gateway to our local
problem report system done, but haven't really made use of it yet.
I'm planning to extract the most severe problem reports from the list
of open problems and use it to generate a system status page.  

--- Steve


From connolly@pixel.convex.com  Thu Jan  7 02:08:55 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18037; Thu, 7 Jan 93 02:08:55 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03482; Thu, 7 Jan 1993 02:23:51 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA28855; Wed, 6 Jan 93 19:23:45 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA09056; Wed, 6 Jan 93 19:23:43 -0600
Message-Id: <9301070123.AA09056@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: new HTML spec, sample implementation
Date: Wed, 06 Jan 93 19:23:43 CST
From: Dan Connolly <connolly@pixel.convex.com>

I just uploaded the following to info.cern.ch:/pub/incoming
libHTML-930106.tar.Z
html_spec-930106.tar.Z

WHERE DO WE GO FROM HERE?

* registering HTML with the IANA

The spec is a hypertext. We need a plain text document
for the IANA. This is complicated by the fact that
much of the spec is "by example," that is, tolerated.html
demonstrates the tolerated techniques much better than
it explains them.

But I think the files HTML.html, Text.html, and html.dtd
make a workable spec. html.dtd has all the information,
HTML.html motivates it, and Text.html gives enough background
to read it.

* bringing implementations into compliance

LineMode -- Tim: I'd like to use SGML_read to do the lexical
stuff in the linemode browser. I haven't thought much about
EBCDIC support, but it shouldn't bee too difficult. I think
SGML_read will fit neatly between HTParseFormat() and
HTGetCharacter().

NeXT browser -- Tim: I'd like to see the stuff on info.cern.ch
use the HEAD/BODY elements and &#60 in stead of &lt. If you
use the NeXT browser to maintain this stuff, or if anybody else
uses the NeXT browser, I'd like to see it brought up to date.

html-mode.el -- Marc: I have kept my copy of html.el up
to date as I have edited the spec. We should sync up.

MidasWWW -- Tony: I have kept my copy of midaswww up
to date as I have worked on the spec. We should sync up too.

Gateways -- Again, I request that anybody who provides
information to the web to keep their server up to date
with this spec. It's the only way to motivate updates
to clients!


Now about that last few changes to the HTML spec...

INLINE ELEMENTS

I added <em>, <samp>, <code>, and several other elements,
inspired by TeXinfo. We need these to support conventional
technical documentation. The list is not exhaustive, but
I think it's pretty good.


NUMERIC CHARACTER REFERENCES

I have learned a few things about SGML and made a few
decisions biased toward simplicity. As a result, I think
the spec is a little smaller and the sample implementation
is a little cleaner.

Most notably, I have introduced numeric character references
to the HTML spec. These were in SGML all along, but I didn't
understand them fully.

This raises the issue of character sets. The character set
in html.dtd is ISO646, i.e. ASCII. Everybody using html.dtd
agrees on the correspondence between the numerals 0-127
and the ASCII characters they represent. So to represent
a '<' character, we'll write "&#60;". This obsoletes
the lt, gt, and amp entities.

On the other hand, I did not include an 8-bit character set.
So the meaning of "&#255" is not defined. The HTML DTD references
"ISO 8879:1986//ENTITIES Added Latin 1//EN" in stead of
"ISO Registration Number 109//CHARSET ECMA-94
Right Part of Latin Alphabet Nr. 3//ESC 2/13 4/3". So We'll write
"&yuml;" for the character that corresponds to position 255
in the ISO-8559 encoding.

In the sample implementation, numeric character references
are invisible to the application: the translation from
"&#60;" to '<' happens inside the SGML_read routine. On
the other hand, entity references like "&yuml;" are
handed back to the application for processing.


Dan


From dsr@hplb.hpl.hp.com  Thu Jan  7 15:00:45 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21384; Thu, 7 Jan 93 15:00:45 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04503; Mon, 4 Jan 1993 14:03:05 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 4 Jan 93 13:00:08 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA08974; Mon, 4 Jan 93 13:04:18 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301041304.AA08974@manuel.hpl.hp.com>
Subject: Re: Searching
To: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Date: Mon, 4 Jan 93 13:04:14 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.25]

> I agree that a forms intreface is something they all lack, and there
> have been a number of proposals to make documents into forms.
> (The main problem is, we don't have editors yet. When we do, then
> there will be plenty of work on forms.)

I too am interested in extending WWW to supports forms, perhaps based on
something like that used in Lotus NOTES. The basic idea is to define classes
of objects such as radio buttons, selection fields, input fields etc.
together with a library of predefined functions (e.g. to check a field
matches a date format) which can be used to build forms. The system is event
driven, and some behaviour is handled purely locally without recourse to the
form's server, for instance applying simple edits to input fields. Other
behaviour involves talking to the server using a simple messaging protocol.

An extreme case is represented by systems such as Hypercard (on MACs) and
Toolbook (PCs). These provide low level objects and scripting language. It
may be more appropriate to consider a higher level approach targetted more
closely at the needs for forms. A major driver for me is a room booking
system which also needs a mechanism for showing minute by minute changes to
the data without the user having to "pull" a fresh copy from the server.

I believe that WWW should be extended to support a richer variety of
documents including forms, equations, pictures and tables. This will take
time of course, but seems the right way to go. How to get there? I am
continuing to work on an HTML editor/browser (portable X11 + Xlib). There
is a lot of dull hard work to do in order to get an effective and reliable
editor.


From fkappe@fiicmss01.tu-graz.ac.at  Thu Jan  7 15:04:41 1993
Return-Path: <fkappe@fiicmss01.tu-graz.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21421; Thu, 7 Jan 93 15:04:41 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18281; Thu, 7 Jan 1993 15:19:38 +0100
Received: by iicm.tu-graz.ac.at (5.57/Ultrix3.0-C)
	id AA29359; Thu, 7 Jan 93 15:19:45 +0100
Received: by fiicmss01.tu-graz.ac.at (4.1/Ultrix3.0-C)
	id AA02351; Thu, 7 Jan 93 15:19:42 +0100
Date: Thu, 7 Jan 93 15:19:42 +0100
From: fiicmss01!fkappe@dxmint.cern.ch
Message-Id: <9301071419.AA02351@fiicmss01.tu-graz.ac.at>
To: www-talk@nxoc01.cern.ch
Subject: ACM SIGGRAPH Online Bibliography Project on W3

  The ACM SIGGRAPH Online Bibliography Project's data files have been con-
verted to Hyper-G format and are made publicly available through Hyper-G (and
thus, are also available using the gopher and WorldWideWeb gateways).
   
  The project's goal is to maintain an up-to-date and as complete as possible
database of computer graphics literature, in a format available to as many
members of the computer graphics community as possible. Available are over
15,000 references from conferences and workshops worldwide and from a variety
of publications, from magazines and journals to books dating back as far as
the late 19th century.

For those who wish to link the service into their WorldWideWeb servers,
link to:

           http://iicm.tu-graz.ac.at:80/CSIGGRAPHbib

If you just want to give it a short try, say:

           www http://iicm.tu-graz.ac.at:80/CSIGGRAPHbib

Greetings,
            Frank

----------------------------------------------------------------------------
Frank M. Kappe                                     fkappe@iicm.tu-graz.ac.at
Institute for Information Processing and Computer Supported New Media (IICM)
                  Graz University of Technology, Austria
Voice: ++43/316/832551-22                               Fax: ++43/316/824394
----------------------------------------------------------------------------


From fine@cis.ohio-state.edu  Thu Jan  7 22:12:56 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24894; Thu, 7 Jan 93 22:12:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07421; Thu, 7 Jan 1993 22:27:54 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA07870; Thu, 7 Jan 93 16:27:50 -0500
Date: Thu, 7 Jan 93 16:27:50 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301072127.AA07870@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: dealing with new-lines
X-Mailer: Perl Mail System v1.1


How should browsers deal with new-lines, and where can html-generators
put in new-lines?

I spent quite a bit of time thinking about what is intuitively the right
way to do it, and I came up with this method.

0. Convert all new-lines inside of tags to spaces.

1. For each tag NOT in
     <PRE> </PRE> <A> </A> <PLAINTEXT>
   remove ALL surrounding new-lines.

2. For each tag in
     <PRE> <PLAINTEXT>
   remove ALL new-lines to left, and one new-line to the right.

3. For each tag in
     </PRE>
   remove ALL new-lines to the right.

4. Convert all remaining new-lines to spaces.

If XMP and LISTING sections are being used, they would be treated the
same as PRE.

Note that this converts new-lines around anchors into spaces UNLESS they
appear immediately at the beginning or end of some other element.

If browsers use this method, it would allow html-generators to put in
new-lines all over the place for readability of HTML, without introducing
lots of annoying extra spaces in the output.  This is what seems like
the most useful thing to do, although I'm not sure it is "correct".

So is it correct?  And are there any obvious flaws?

       tom

From connolly@pixel.convex.com  Fri Jan  8 00:59:21 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25970; Fri, 8 Jan 93 00:59:21 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11465; Fri, 8 Jan 1993 01:14:18 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA29874; Thu, 7 Jan 93 18:13:48 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06638; Thu, 7 Jan 93 18:13:46 -0600
Message-Id: <9301080013.AA06638@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: dealing with new-lines 
In-Reply-To: Your message of "Thu, 07 Jan 93 16:27:50 EST."
             <9301072127.AA07870@soccer.cis.ohio-state.edu> 
Date: Thu, 07 Jan 93 18:13:46 CST
From: Dan Connolly <connolly@pixel.convex.com>


>How should browsers deal with new-lines, and where can html-generators
>put in new-lines?

Darn good question. Your approach appears to have the correct
results, but I'm not sure it's practical for many implementations
(global search-and-replace operations are inconvenient for
sequential processing models), and it certainly isn't a healthy
way to think about SGML documents.

The way to think about SGML documents, IMHO, is this: the sequence
of characters comprising an SGML document are presented to an
SGML parser, which parses the markup from the data and passes
the "results" to the processing application.

[Much of this is covered in
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/921203/Text.html
and what isn't there should be, but bear with me...]

So many of the details of the syntax of SGML are invisible to
the processing application: the fact that <>'s delimit tags
in stead of {}'s for example.

The information delivered to the application by the parser
is called the Element Structure Information Set. It contains
things like tags, attributes, attribute values, and data
characters.

So there are two questions, to my mind:
1. How does the SGML parser treat newlines?
2. How does the WWW processing application treat newlines?

Question 1 is answered by the SGML standard. Question 2
is for us to decide.

SGML defines several types of content, which determine
the kinds of markup that are recognized inside an element.
The simplest is EMPTY, for example:

<!ELEMENT P - O EMPTY>

When you see a P start tag, you know there is no content,
and you assume that a P tag follows, effectively.

The next simplest is CDATA, for example:

<!ELEMENT TITLE - - CDATA>

When you parse the content of a TITLE element, the only
thing you look for is an end tag. Everything else is
reported by the SGML parser as data characters.

Then there is RCDATA, which is just like CDATA, except
for character and entity references.

The most common content type is MIXED, where all kinds
of markup are recognized: tags, entities, as well as data.
For example:

<!ELEMENT ADDRESS - - (#PCDATA|A|P)>

The parser should report start tags, end tags, entities,
and data inside an ADDRESS element.

Then there is ELEMENT content, where only tags are
recognized, for example:

<!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID?)>

The parser will report any data inside a HEAD element
as an error. But [and this is the reason I went through
this whole excercise] whitespace is ignored between
tags in element content. So the text:

<head>
<title>sample</title>
</head>

will be reported to the application by the parser as
a HEAD start tag,
a TITLE start tag,
the data string "sample",
a TITLE close tag,
and a HEAD close tag,
whereas the text:

<address>
<a HREF="#tim">Tim Berners-Lee</a>
</address>

will be reported as
an ADDRESS start tag,
the data string "\n"
an A start tag (with an HREF attribute and value),
the data string "Tim Berners-Lee",
the data string "\n"
an A close tag,
and an ADDRESS close tag.

[There's another content type called ANY, but it's just
like MIXED for our purposes.]

>I spent quite a bit of time thinking about what is intuitively the right
>way to do it, and I came up with this method.
>
>0. Convert all new-lines inside of tags to spaces.

Newlines inside tags are the responsibility of the
SGML parser. I suggest you use the excellent sgmls
parser to test your rules by trial and error, or
consult the standard.

I have done both, and the results of my labors
are available in libHTML. I have also done an elisp
implementation, if anybody's interested.

The one tricky case is newlines inside attribute
value literals, e.g.

<foo bar="12
3">

This one is a little tricky. SGML section 7.9.3 says:

"An attribute value literal is interpreted as an attribute value by
replacing references within it, ignoring Ee and RS, and replacing RE
or SEPCHAR with SPACE."

The reference concrete syntax assigns the conventional unix newline
character, ASCII code 10, to the role of RS. So strictly speaking,
it should be ignored, and the value of the attribute is "123".

On the other hand, the sgmls parser does a little behind-the-scenes
magic on newlines. From the sgmls man page:

     An external entity resides in one or more files.  The entity
     manager component of sgmls maps a sequence of files into an
     entity in three sequential stages:

     1.   each carriage return character is turned into a non-
          SGML character;

     2.   each newline character is turned into a record end
          character, and at the same time a record start charac-
          ter is inserted at the beginning of each line;

     3.   the files are concatenated.

[This sort of thing _does_ still conform to the SGML standard.
You're allowed to do magic while assembling entities]

So using sgmls, the newline in this case would be treated as
RE, and converted to SPACE, i.e. ASCII character 32, by the
parser. So the value of the bar attribute is "12 3".

It's a question of how we construct SGML entities from HTML
data streams.


>1. For each tag NOT in
>     <PRE> </PRE> <A> </A> <PLAINTEXT>
>   remove ALL surrounding new-lines.

First, let's get one thing straight: the PLAINTEXT element as
described by the original HTML documentation is not representable
in SGML. For my purposes, I consider the HTML document to
end at the <PLAINTEXT> tag, and I consider the rest of the
data stream to be an RFC-822 message body or a MIME text/plain body,
and not SGML at all.

Next, let's keep in mind that you can't do things like the following
global substitition,
s/\n+(<(H1|H2|ADDRESS...))>/$2/g;
because it might find things that look like tags but aren't,
for example

<foo bar="
<H1>this is a little cooky, but nontheless legal and possible.">

But even if you're using a proper SGML parser, consider:

<H1>Here we go!
<a href="#xyz">click here</a>
There we went!
</H1>

The parser will return an H1 start tag, and then the
string "Here we go!\n". At this point, your rule doesn't
tell me what to do with the newline. I have to get
the next object before I decide.

Hmm... I guess that's reasonable. But I'd rather just pass all the
data charcters on the the text formatter and let it figure all this out.

Do we want to specify rules for the text formatter? If so, we need to
go beyond just newlines.  I see some data providers writing things
like:

<H1>Here are some things to consider:</H1>
<p>      thing one
<p>      thing two
<p>      thing three

The MidasWWW browser displays this as

Here are some things to consider:
thing one
thing two
thing three

which I think is reasonable. The provider should either use
<H1>Here are some things to consider</H1>
<UL>
<li>thing one
<li>thing two
<li>thing three
</ul>

or at a minimum,

<H1>Here are some things to consider</H1>
<PRE>
     thing one
     thing two
     thing three
</PRE>


>2. For each tag in
>     <PRE> <PLAINTEXT>
>   remove ALL new-lines to left, and one new-line to the right.

Why remove one new-line to the right? Just for HTML source file aesthetics?

>If XMP and LISTING sections are being used, they would be treated the
>same as PRE.
>
>Note that this converts new-lines around anchors into spaces UNLESS they
>appear immediately at the beginning or end of some other element.

There are also some new elements that act like A: EM, CODE, SAMP, etc.

>If browsers use this method, it would allow html-generators to put in
>new-lines all over the place for readability of HTML, without introducing
>lots of annoying extra spaces in the output.  This is what seems like
>the most useful thing to do, although I'm not sure it is "correct".
>
>So is it correct?  And are there any obvious flaws?

We have not specified the rules for typesetting elements other
than XMP, LISTING, and PRE before now, so what you suggest is
as correct as anything else.

I think it's important that we agree on how to typeset the <PRE>
element. [And I think getting rid of the first newline after a <PRE>
tag is a Bad Thing.]

It's not important to me that we agree how to typeset other elements.
I'm inclined to give formatters great leeway with how they treat whitespace.
I wouldn't mind at all if something like

<H1>testing 123</H1>
foo       bar     blech		icky<a>wicky</a>


woo
<p>  abc defghi
jhkl sldjkf sld    	lsdjkf


were typeset as:

	TESTING		123

	foo bar blech ickywicky woo

	abc defghi jhkl sldjkf sld lsdjkf

My point is: don't use whitespace to represent significant
information except in the PRE elemnt. Use the tags that
are defined to have significance.

Dan


From connolly@pixel.convex.com  Fri Jan  8 03:47:42 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26563; Fri, 8 Jan 93 03:47:42 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15823; Fri, 8 Jan 1993 04:02:40 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA07994; Thu, 7 Jan 93 21:02:37 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA11869; Thu, 7 Jan 93 21:02:36 -0600
Message-Id: <9301080302.AA11869@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
Subject: Re: dealing with new-lines 
In-Reply-To: Your message of "Thu, 07 Jan 93 18:13:46 CST."
Date: Thu, 07 Jan 93 21:02:36 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>How should browsers deal with new-lines, and where can html-generators
>>put in new-lines?
>
>Darn good question.
>>
>I have done both, and the results of my labors
>are available in libHTML. I have also done an elisp
>implementation, if anybody's interested.
>
>
>>     <PRE> <PLAINTEXT>
>>   remove ALL new-lines to left, and one new-line to the right.
>
>Why remove one new-line to the right? Just for HTML source file aesthetics?

Turns out this is standard behavior. Boy is this a can of worms.

I just went back over the comp.text.sgml archives to research this
some more, and boy was I wrong.

From what I can tell, a newline is ignored by the SGML parser
if it's right after a start tag or right before an end tag.

For the whole story, see
gopher://ifi.uio.no:70/
00/pub/SGML/comp.text.sgml/by.date/1992/05/02/230201.Naggum

SGML is a mess!

Dan


From timbl@www3.cern.ch  Fri Jan  8 11:54:45 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28289; Fri, 8 Jan 93 11:54:45 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06000; Fri, 8 Jan 1993 12:09:44 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02814; Fri, 8 Jan 93 12:09:41 +0100
Date: Fri, 8 Jan 93 12:09:41 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301081109.AA02814@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: dealing with new-lines 
Cc: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



For what it is worth, the way the CERN implementations are supposed to work is:

	MIXED elements
	
Within a MIXED element,  newlines are treated as word breaks.  The effect of  
this is that if the imaginary output cursor has a non-white character to the  
left of it, then a space is introduced.  This means that any number of newlines  
will only produce one white space character.  [It involves a horrid "are we in  
the middle of a word?" flag.]

Spaces, however, always produce spaces, so multiple spaces will come out as  
multiple spaces.

	XMP
	
Within <XMP> I went all the way and said that from the trailing > of <XMP>
to the beginning <of </XMP> all data was litteral, including newlines.  
Therefore example sections typically are marked up as

<XMP>This is an example line

</XMP>
That was an example.  There are no new lines between the <XMP> and the example  
line because the XMP section causes a paragraph break, and the style for the  
normal paragraph specifies a minimum white space after each paragraph. Beacuse  
each XMP section is like a black box, any white spce inside it would not be  
seen by the white space management logic which overlaps the white spaces  
required around successive paragraphs, and extra white spce would result.

	PRE

By the way, I think we agreed (I gave in) that the <PRE> sections would have
siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which  
gives double spacing on my browsers.  So I tread newlines as newlines in all
the <PRE> element just as XMP.

	SGML generation
	
Off the top of my head I think what happened was in Mixed elements, I generate  
the newlines instead of spaces in PCDATA when the line gets a bit long, and  
also insert them before open tags like <H3> which cause paragraph breaks  
anyway.  As an anchor tag need not cause a word break even, I do NOT insert  
them before an <A>, but rather always output "<A\nNAME=%s" so that the
HREF attribute (generally the line length buster) starts atthe beginning of  a  
line. 


	Tim

 

From timbl@www3.cern.ch  Fri Jan  8 12:00:16 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28312; Fri, 8 Jan 93 12:00:16 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06290; Fri, 8 Jan 1993 12:15:16 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02824; Fri, 8 Jan 93 12:15:12 +0100
Date: Fri, 8 Jan 93 12:15:12 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301081115.AA02824@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: dealing with new-lines 
Cc: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



> SGML is a mess!
>
> Dan

I agree. An appal
ling mess.

Tim



From dsr@hplb.hpl.hp.com  Fri Jan  8 14:32:15 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28917; Fri, 8 Jan 93 14:32:15 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13340; Fri, 8 Jan 1993 14:47:10 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 8 Jan 93 13:44:04 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA09490; Fri, 8 Jan 93 13:48:21 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301081348.AA09490@manuel.hpl.hp.com>
Subject: Customer pull on HTTP2
To: www-talk@nxoc01.cern.ch
Date: Fri, 8 Jan 93 13:48:18 GMT
Cc: dsr@hplb.hpl.hp.com
Mailer: Elm [revision: 66.25]

I am getting really excited about the possibilities for the Web for a variety
of roles. Much us this however depends on getting the right features into
HTTP2. I would very much like comments on the following suggestions.

Authentication
--------------

I think that every HTTP2 request (not just GET) should include the "From"
field, and that it is strongly desirable to include the user's full name,
e.g.

    From: dsr@hplb.hpl.hp.com (David Raggett)

The user's name must be easy to extract regardless of the particular variant
of email addressing scheme.

For some services the server may need to check if the user is authorised for
this service. In many cases the Internet (numeric) address and the information
in the "From:" field will suffice.

Additional security will require a password. I think this should be a header
in its own right. The "POST" command names a document that you wish to post a
response to. That document may not be owned by you so it doesn't seem right to
muddle up the authorisation for the POST command with that documents Udi.

so lets have a new header  "Password:  xyzzy"

A further trick would be to encrypt your password for this server/service
together with the time of day using a scheme agreed by you and the server. The
server then decrypts the value sent with the Password header to extract the
password, and time of day and checks that the time is correct  to within a
margin for network delays.

This only effects the HTTP2 protocol in requiring different error codes to
distinguish the cases:

    a)  your Internet address is not permissible for this service
    b)  your user name is not permissible for this service
    c)  your password is incorrect
    d)  your password is ok, but the time check failed


Basic need for administrators identify and even to mail users.
Frequent need for authentication - not just on GET
encrypt password + time of day to foil copying password

Needless to say the value for the Password header should be composed of
printable 7 bit ascii characters, excluding white space and control chars.


Caching
-------

It will be desirable to avoid overloading servers with popular documents by
supporting a caching scheme at local servers (or even at browsers?). This
implies that document headers should provide sufficient information to make
this practical.

Servers need to be able to work out what documents to trash from their caches.
A simple approach is to compare the date the document was received with the
date it was originally created or last modified. Say it works out that when
you got the document it was already one week old. Then one rough rule of thumb
is to trash it after another week. You can be rather smarter if there is a
valid expiry date included with the document:

    o   the document header should *always* include a "Date:" field giving
        the date it was last written to

    o   the "Expires:" field is optional

    o   the date values should be in a prescribed format to simplify
        machine interpretation (Is this adequately defined by existing RFCs?)

I think that we need to provide an operation in which the server returns a
document only if it is later that a date/time supplied with  the request. If
it is the same (or earlier) the server should return a suitable status code
and an optional "Cost:" header, see below.

This is already provided for:

    GET udi
    SINCE datatime

The meaning of SINCE needs to change as in Tim's original description of HTTP
it means "greater than or equals", whereas I want strictly "greater than".

Note that servers shouln't cache documents with restricted readership since
each server don't know the restrictions to apply. This requires a further
header to identify such documents as being unsuitable for general caching:

    Distribution: restricted | unrestricted

This header is only needed for documents with restricted readership.
An dirty alternative would be to set the expiry date to the same value as
supplied with the "Date:" header.

Copyright & Payments
--------------------

Although the Internet backbone restricts profit making services, many subnets,
such as University campuses, and company subnets such as HP's have no such
problem. Indeed users strongly want access to copyrighted information for
which a payment is due.

My suggestion is that servers are responsible for tracking who accesses what
information, and hence how much they owe. For use within Hewlett Packard for
library services, we anticipate including some extra headers in the request:

    EmployeeNumber: 148689
    LocationCode:   8126        (an account number for cross charging)

This would be stripped off when sending requests to servers outside the HP
subnet. These headers are ignored by servers which conform to strict HTPP2.

I would like the document header to include an optional cost header, e.g.

    Cost: 4.05 US DOLLARS
    Copyright: Reuters Inc.

This would let the users know how much a given document has cost them, as well
as who owns the copyright. The latter heading is needed since you can't always
put it in the document, e.g. think of photographic images.


The "Cost: 4.03 US DOLLARS" field


Copyright and Caching
---------------------

What happens if a copyright protected document is saved in the cache of a
local server? We have got to ensure that the rightful owners get paid for
access even when the document is obtained from a local server's cache.

My idea is that for each access, this server should inform the server on which
the original document resides. This notification can however be deferred to
a time when the network is quiet ...

The notification proceeds using the "GOT" command

    GOT udi
    From: dsr@hplb.hpl.hp.com (David Raggett)
    Server: hplose.hpl.hp.com
    EmployeeNumber: 148689          /* HP specific */
    LocationCode:   8126            /* HP specific */

The From header gives the name of the user who requested the document. The
Server header names the machine with the cache, and other company specific
fields are used for accounting purposes.

Note that this scheme can't be used for documents with restricted readership,
since the server looking after the cache doesn't know who is and who isn't
allowed to read this document.

The protocol ought to allow for multiple GOT statements (and associated
headers in the same message. For this it seems simple enough to require a
terminating blank line.


Naming Parts of a Multipart body
--------------------------------

It would be nice to use the MIME format's capability to send multiple
documents as part of the same message, e.g. an HTML doc with several
pictures. To make this work each separate part needs to include the
Document Udi in its header, so that the browser can check if it has the
document in its local cache (history stack) or whether it needs to make
network request for the picture etc.

    DocumentName: Udi


Effective support for discussion groups
---------------------------------------

My model is that discussion groups each have unique Udi's. Each discussion
group has a sequence of base notes, and each base note is associated with a
sequence of responses. I am unsure of how to deal with cross postings!

Over a period of time the number of base notes can grow arbitrarily, and we
need a way of listing all those within a given time period. This can be
supported using Tim's BEFORE and SINCE modifiers in association with the GET
command. The server is responsible for creating an HTML document corresponding
to the list of base notes (and how many responses there are for each etc.).

In retrieving a base note, you should get an indication of how many responses
there are using the header:

    Responses:  16

You also need a way of retrieving a given response. One way is to ask for the
list of Udi's for all the responses, another is a command to get a particular
response given the Udi for the base note and a sequence number, e.g.

    RESPONSES Udi           /* request the list of response's as an html doc */
    GETRESPONSE 12 Udi      /* get a given response (12th in the list) */


What do people think?


I assume the POST command can be accompanied by an html doc as a body.

Looking forward to your comments,

David Raggett

From timbl@www3.cern.ch  Fri Jan  8 15:59:19 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29537; Fri, 8 Jan 93 15:59:19 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18499; Fri, 8 Jan 1993 16:14:19 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02989; Fri, 8 Jan 93 16:14:15 +0100
Date: Fri, 8 Jan 93 16:14:15 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301081514.AA02989@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: new HTML spec, sample implementation
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Wed, 06 Jan 93 19:23:43 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>  

>  I just uploaded the following to info.cern.ch:/pub/incoming
>  libHTML-930106.tar.Z
>  html_spec-930106.tar.Z

	Transferred to /pub/www/dev
	
	The spec available as:
	http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/930106/HTML.html
	
	The older versions are all availavle as well.. link to a list of them
	from the Markup futures page.
	
	Are the ISO latin 1 characters in  
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/921203/ISOlat1.html
	in order? it would be useful to have their character code there.
	
	I think it is a very wise move to define latin 1 as the base
	character set for HTML.  Non-anglophones in Europe really can't get
	 very far without it.  I remember their urgent please for gopher
	 to go latin1 retrospectively.
	 

	 I feel that it would be friendly to allow EITHER the names OR the
	 numbers for funny characters, including &lt; .
	
>  WHERE DO WE GO FROM HERE?
>  

>  * registering HTML with the IANA
>  

>  The spec is a hypertext. We need a plain text document
>  for the IANA. This is complicated by the fact that
>  much of the spec is "by example," that is, tolerated.html
>  demonstrates the tolerated techniques much better than
>  it explains them.

I agree that this compilicates it.  The explanation is in large part in
files which are likely to be unreadable by many browers!  I would
like to see the whole of the content in "proper" HTML. The most useful way
to put in examples is to make littlefiles Example_nn.html and put soft
links in Example_nn.txt too the same file. This allows people to look simply at  
the source of the example with a browser, and also to try their browser out on  
it as a hypertext document.

We would then generate a paper document out of all the hypertext and the .txt
files, and the document generator won't fall over!

I would also like to see a node on each tag.  I found from user comments that  
the current explanations of HTML or just not good enough. We need some stuff on  
the side of the spec explaining what each tag is actually FOR, with an example  
of each, acessesed from a reference section.  Maybe that can wiat till after  
IANA registration, though.

>  But I think the files HTML.html, Text.html, and html.dtd
>  make a workable spec. html.dtd has all the information,
>  HTML.html motivates it, and Text.html gives enough background
>  to read it.

>  * bringing implementations into compliance
>  

>  LineMode -- Tim: I'd like to use SGML_read to do the lexical
>  stuff in the linemode browser. I haven't thought much about
>  EBCDIC support, but it shouldn't bee too difficult. I think
>  SGML_read will fit neatly between HTParseFormat() and
>  HTGetCharacter().

It sounds as though (1) HTML.c should be turned into a structued hypertext
object built on top of -- in the line mode case only -- the HText.c object.

I feel that the SGML parsing object should create the textobject, because
one SGML file could cause many displayable objects to be created -- in the  
future at least.  Theerfore, it is not enough to pass the SGML object the ID
of an already-created text object. Does that make sense?

Otherwise I think our architecures are converging ... do you want to make
a new WWW/Library and I'll try it out?  I can release it in parallel with
the current one for a while for safety.

>  NeXT browser -- Tim: I'd like to see the stuff on info.cern.ch
>  use the HEAD/BODY elements and &#60 in stead of &lt. If you
>  use the NeXT browser to maintain this stuff, or if anybody else
>  uses the NeXT browser, I'd like to see it brought up to date.

HEAD/BODY elements are in all new text, but not numeric character refs.
I's on the list.
...
>  Now about that last few changes to the HTML spec...
>  

>  INLINE ELEMENTS
>  

>  I added <em>, <samp>, <code>, and several other elements,
>  inspired by TeXinfo. We need these to support conventional
>  technical documentation. The list is not exhaustive, but
>  I think it's pretty good.

The need for a reference section is highlighted by my inability to find these  
in the spec.
  

>  NUMERIC CHARACTER REFERENCES
>  

>  I have learned a few things about SGML and made a few
>  decisions biased toward simplicity. As a result, I think
>  the spec is a little smaller and the sample implementation
>  is a little cleaner.
>  

>  Most notably, I have introduced numeric character references
>  to the HTML spec. These were in SGML all along, but I didn't
>  understand them fully.
>  

>  This raises the issue of character sets. The character set
>  in html.dtd is ISO646, i.e. ASCII. Everybody using html.dtd
>  agrees on the correspondence between the numerals 0-127
>  and the ASCII characters they represent. So to represent
>  a '<' character, we'll write "&#60;". This obsoletes
>  the lt, gt, and amp entities.
>  

>  On the other hand, I did not include an 8-bit character set.
>  So the meaning of "&#255" is not defined. The HTML DTD references
>  "ISO 8879:1986//ENTITIES Added Latin 1//EN" in stead of
>  "ISO Registration Number 109//CHARSET ECMA-94
>  Right Part of Latin Alphabet Nr. 3//ESC 2/13 4/3". So We'll write
>  "&yuml;" for the character that corresponds to position 255
>  in the ISO-8559 encoding.

I would like to see an 8-bit basic character set as I said in some other  
message I think.  (For those Finns  and p{op]e li^e th{t.  :-)

>  In the sample implementation, numeric character references
>  are invisible to the application: the translation from
>  "&#60;" to '<' happens inside the SGML_read routine. On
>  the other hand, entity references like "&yuml;" are
>  handed back to the application for processing.

I would have thought the SGML engine ought to be able to resolve all entities.
The communication between it and the text object would have to be defined in  
terms of a particular character set, and perhaps if there is more than one  
contender the SGML engine could have a compilation option.

That isthe easiest to implement.  It makes the implementation outside SGML the  
least SGML-aware.


>  Dan
>  


Tim

From timbl@www3.cern.ch  Fri Jan  8 16:33:17 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00159; Fri, 8 Jan 93 16:33:17 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21182; Fri, 8 Jan 1993 16:48:17 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03037; Fri, 8 Jan 93 16:48:14 +0100
Date: Fri, 8 Jan 93 16:48:14 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301081548.AA03037@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HTTP2: Authentication
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Dave, I am splitting your message up into bits to keep the threads distinct.

>  From: Dave_Raggett <dsr@hplb.hpl.hp.com>
>  Date: Fri, 8 Jan 93 13:48:18 GMT

>  Authentication
>  --------------
>  

>  I think that every HTTP2 request (not just GET) should include the "From"
>  field, and that it is strongly desirable to include the user's full name,
>  e.g.
>  

>      From: dsr@hplb.hpl.hp.com (David Raggett)
>  

>  The user's name must be easy to extract regardless of the particular variant
>  of email addressing scheme.
>  

>  For some services the server may need to check if the user is authorised for
>  this service. In many cases the Internet (numeric) address and the  
information
>  in the "From:" field will suffice.


I agree that low-level security is all that is needed in many cases.
The IP address is quite good for licensing too.

>  Additional security will require a password. I think this should be a header
>  in its own right. The "POST" command names a document that you wish to post  
a
>  response to. That document may not be owned by you so it doesn't seem right  
to
>  muddle up the authorisation for the POST command with that documents Udi.
>  

>  so lets have a new header  "Password:  xyzzy"


The passord certainly shouldn't be in the udi.

The hairy part is that we must be flexible about privacy shemes here.
We may meet one lot committed to kerberos and another group comitted to  
something else. So we should allow perhaps for a generic 'Authorization:' field
and a number of rather extensive "refused" condidtions including the ones you  
suggest and specifying the sort of authorization required.

rather than put passwords in the clear all the time (a reasonable low level
scheme) the next setp is for the server to send back, along with the refusal, a
random string to be encripted by the user using his key. This prevents anyone
from breaking it unless they can put together the two messages, which is
an extra hurdle.  The random string is related to the IP address the guy  
originally used and will also time out, of course.

>  

>      a)  your Internet address is not permissible for this service
>      b)  your user name is not permissible for this service
>      c)  your password is incorrect
>      d)  your password is ok, but the time check failed
       e)  please send a kerberos ticket
       f)  your kerboeros ticket is no good
       g)  your IP address has just run out of license see body of message

We should look at Privacy Enhanced Mail -- the requiremenst must be similar.  
All these schemes eventually rely on an established net of trusted servers  
which doesn't exist right now, so we are putting in hooks for the future.
  

>  Basic need for administrators identify and even to mail users.

yes. dunno about mail. Privacy issues... in general you can record who read and  
what was read but not who read what.

>  Frequent need for authentication - not just on GET

yes.  Much more for checkin!

>  encrypt password + time of day to foil copying password
>  

>  Needless to say the value for the Password header should be composed of
>  printable 7 bit ascii characters, excluding white space and control chars.

yes.

Tim


From K.Hoadley@directory.rl.ac.uk  Fri Jan  8 17:18:20 1993
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00529; Fri, 8 Jan 93 17:18:20 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24121; Fri, 8 Jan 1993 17:33:19 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <08910-0@directory.rl.ac.uk>; Fri, 8 Jan 1993 16:18:55 +0000
Date: Fri, 8 Jan 1993 14:32:21 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Sender: K.Hoadley@directory.rl.ac.uk
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: Re: Customer pull on HTTP2
To: www-talk@nxoc01.cern.ch
Cc: dsr@hplb.hpl.hp.com
Message-Id: <Ximap.726510755.7590.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dave Raggett raised some interesting issues in his message. In
particular:

> Caching
>-------
>
> It will be desirable to avoid overloading servers with popular documents by
> supporting a caching scheme at local servers (or even at browsers?). This
          As well as caching, replication would be nice. But this is
      only practical if resource identifiers do not contain location
      information (otherwise replication is only possible by making
      all the peer servers to appear to be one machine, as in the
      DNS CNAME suggestion I made some time ago).
          But if resource identifiers do not contain host information
      then you need an external means of determining how to reach
      the resource. This is analagous to routing protocols (an address
      is not a route ...)
          Such a system is probably over ambitious for now. Anyway,
      back to caching ...

> Servers need to be able to work out what documents to trash from
> their caches.
> A simple approach is to compare the date the document was received with the
> date it was originally created or last modified. Say it works out that when
> you got the document it was already one week old. 
> Then one rough rule of thumb
> is to trash it after another week. You can be rather smarter if there is a
> valid expiry date included with the document:

          I think this is silly. I haven't changed a document for
      six months, therefore it is safe to say that it won't be
      changed for the next six months ...
          This also depends on hosts agreeing on the date. To quote
      RFC1128, talking about a 1988 survey of the time/date on
      Internet hosts, "... a few had errors as much as two years"

> I think that we need to provide an operation in which the server returns a
> document only if it is later that a date/time supplied with  the request. 

          This would be useful as part of a replication system,
       as long as both ends exchanged timestamps initially so
       that the dates can be synchronised.

> Note that servers shouln't cache documents with restricted readership since
> each server don't know the restrictions to apply. This requires a further
> header to identify such documents as being unsuitable for general caching:

and also ...

> What happens if a copyright protected document is saved in the cache of a
> local server? We have got to ensure that the rightful owners get paid for
> access even when the document is obtained from a local server's cache.

         It may be stating the obvious, but once you allow a
    user to access you data such that they can save it, there is
    no technical way you can prevent them from publically
    redistributing your data. This is a social/legal problem,
    not a technical one.
         Accepting that nothing can be done to stop deliberate
    abuse of licensed information, there is a need to prevent
    accidental abuse. Probably the simplest way to do this is
    to mark the document as one which should NOT be cached.
          
         Perhaps this leading towards a very simple minded
    caching scheme a la DNS, where information is returned
    together with an indication of its "time to live" (TTL),
    ie how long this can reasonably be cached. Setting a default
    TTL for a server gives an idea of the "volatility" of the
    information contained therein 
         Unless a document is exported with world read access,
    it should always have TTL of 0.
 

Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@directory.rl.ac.uk
               

From timbl@www3.cern.ch  Fri Jan  8 17:27:37 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00654; Fri, 8 Jan 93 17:27:37 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24708; Fri, 8 Jan 1993 17:42:37 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03067; Fri, 8 Jan 93 17:42:32 +0100
Date: Fri, 8 Jan 93 17:42:32 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301081642.AA03067@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: HTTP2: caching and copyright
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

These are comment son the second part of Dave's note.
They refer to the new HTTP spec and a hypertextversion of RFC850  which I made
in order to be able to cross-reference to it (and make it prettier).

>  Caching
>  -------
>  

>  It will be desirable to avoid overloading servers with popular documents by
>  supporting a caching scheme at local servers (or even at browsers?). This
>  implies that document headers should provide sufficient information to make
>  this practical.

Like "Expires:" for example. See
http://info.cern.chhypertext/WWW/Protocols/HTTP/Object_Headers.html

...>  

>      o   the document header should *always* include a "Date:" field giving
>          the date it was last written to

Agreed.  Now why in the spec did I say that Date: was the creation date?
In any event, we need last-modified as well as created dates. I chose
to use the existing Date: field of RFC 850 as the creation date.
I guess the modified date is more available, but if you are tracing things
the creation date is a better thing to file under.  For a mail/news article
of course they are the same.

>      o   the "Expires:" field is optional

agreed.

>      o   the date values should be in a prescribed format to simplify
>          machine interpretation (Is this adequately defined by existing  
RFCs?)

agreed. yes it is, in RFC850: in 

http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z10
  

  (pretty soon we're going to HAVE to have hypertext mail!).
  

>  I think that we need to provide an operation in which the server returns a
>  document only if it is later that a date/time supplied with  the request. If
>  it is the same (or earlier) the server should return a suitable status code
>  and an optional "Cost:" header, see below.

Need to look at NNTP here.  We end up getting very close indeed to it.
I would want the functionalty of this search to map onto the NEWNEWS
very nicely.  A newsgroup is just a hypertext list anyway.

>  Note that servers shouln't cache documents with restricted readership since
>  each server don't know the restrictions to apply. This requires a further
>  header to identify such documents as being unsuitable for general caching:
>  

>      Distribution: restricted | unrestricted

Good point.  Not the the distribution of other messages is in the form of
To: and Cc: and Newsgroup: and in fact Distribution:.  (See  
http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z12)
So you'll need a new fieldname.  If we could only merge the functionality of  
these systems in some cool way, it would be grand.

When looking at protection for more than just GET, I came up with the
	Public: *<method>
	Allow: *<method>
lines documented in the list of object headers I mentioned above.

>  This header is only needed for documents with restricted readership.
>  An dirty alternative would be to set the expiry date to the same value as
>  supplied with the "Date:" header.

Yes but that would not be legally binding.  It could also mean "this document  
is a live status: fetch it as often as you can".

>  Copyright & Payments
>  --------------------
>  

>  Although the Internet backbone restricts profit making services, many  
subnets,
>  such as University campuses, and company subnets such as HP's have no such
>  problem. Indeed users strongly want access to copyrighted information for
>  which a payment is due.
>  

>  My suggestion is that servers are responsible for tracking who accesses what
>  information, and hence how much they owe. For use within Hewlett Packard for
>  library services, we anticipate including some extra headers in the request:
>  

>      EmployeeNumber: 148689
>      LocationCode:   8126        (an account number for cross charging)
>  

>  This would be stripped off when sending requests to servers outside the HP
>  subnet. These headers are ignored by servers which conform to strict HTPP2.
>  

>  I would like the document header to include an optional cost header, e.g.
>  

>      Cost: 4.05 US DOLLARS
>      Copyright: Reuters Inc.

I note here that both the copyright holder and the account for charging are  
items in some address space, and we ought to be as flexible with these address  
spaces as wit the udi.  So I would propose something like

	ChargeTo:  HPInternal:/8126/148689  upto $2.00
	
would be better.  But how does this fit in with authentication?  Once you are
authenticated, your prefered method of paying will be known.  You can't have
charging without authentication!

There is a little problem with sending an "upto $2.00" field as it requires  
honesty of the server not to just charge you $2.00 flat!  This is a real  
problem, as otherwise one needs twice the round trip delays, which we really  
object to, if one prefers the fairer

	C	GET  junk
	S	No way: you pay $2.00 first
	C	GET junk I promise to pay $2.00
	S	*junk


>  This would let the users know how much a given document has cost them, as  
well
>  as who owns the copyright. The latter heading is needed since you can't  
always
>  put it in the document, e.g. think of photographic images.
>  

>  

>  The "Cost: 4.03 US DOLLARS" field
>  

>  

>  Copyright and Caching
>  ---------------------
>

Have you read "Litterary Machines?" That goes into this in a lot of detail,
or at least Xanadu should have done.

>  What happens if a copyright protected document is saved in the cache of a
>  local server? We have got to ensure that the rightful owners get paid for
>  access even when the document is obtained from a local server's cache.
>  

>  My idea is that for each access, this server should inform the server on  
which
>  the original document resides. 


yes -- hence we need three classes, free, forpay, restricted.  I wonder whwther  
these were Brewster's 3 types of flag in his proposed WAIS udi.

>  The protocol ought to allow for multiple GOT statements (and associated
>  headers in the same message. For this it seems simple enough to require a
>  terminating blank line.

Hey, that;s not something you do for one method, it's a change to the whole  
protocol to introduce pipelining.

A simple thing in the first instance is to say that it illegal to cache
a for-pay document unless you have a privat earrangement with the owner
about refunding him.  This could be done using a completely separate billing  
process.


>  Naming Parts of a Multipart body
>  --------------------------------
>  

>  It would be nice to use the MIME format's capability to send multiple
>  documents as part of the same message, e.g. an HTML doc with several
>  pictures. To make this work each separate part needs to include the
>  Document Udi in its header, so that the browser can check if it has the
>  document in its local cache (history stack) or whether it needs to make
>  network request for the picture etc.
>  

>      DocumentName: Udi

Sure.  This is a very useful thing to put in a mail message anyway.
Like

Archived-as:
or
Available:

>  Effective support for discussion groups
>  ---------------------------------------
>  

>  My model is that discussion groups each have unique Udi's. Each discussion
>  group has a sequence of base notes, and each base note is associated with a
>  sequence of responses. I am unsure of how to deal with cross postings!

I agree that the POST method is well defined as a method of the
newsgroup class which takes an article as a parameter. In fact, as you say,
cross-posting makes a mess of this, as it involved many groups in one atomic  
operation.  This is a peculiarity of news which makes it difficult to map onto  
the object model.  Any ideas?

...
>  You also need a way of retrieving a given response. One way is to ask for  
the
>  list of Udi's for all the responses,

Yes.

> another is a command to get a particular
>  response given the Udi for the base note and a sequence number, e.g.

No -- not sufficiently stateless.

>  I assume the POST command can be accompanied by an html doc as a body.

yes

>  Looking forward to your comments,
>  

>  David Raggett

as you see mine got shorter with time...

tim


From mleventh@us.oracle.com  Fri Jan  8 19:17:32 1993
Return-Path: <mleventh@us.oracle.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01614; Fri, 8 Jan 93 19:17:32 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29386; Fri, 8 Jan 1993 19:32:27 +0100
Received:  from hqsun4.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
	id AA21764; Fri, 8 Jan 93 10:32:25 PST
Received:  by hqsun4.us.oracle.com (5.59.10/37.3)
	id AA06229; Fri, 8 Jan 93 10:32:22 PST
Message-Id: <9301081832.AA06229@hqsun4.us.oracle.com>
Date: Fri, 8 Jan 93 10:32:22 PST
From: Michael Leventhal <mleventh@us.oracle.com>
To: www-talk@nxoc01.cern.ch
Subject: SGML newline processing
Cc: mleventh@us.oracle.com


>>From what I can tell, a newline is ignored by the SGML parser
>if it's right after a start tag or right before an end tag.

I haven't been following the discussion closely enough to know
if a suggestion for dealing with the problem will be helpful,
but...

I use the SHORTREF feature to implicitly recognize an EMPTY
<newline> tag wherever I want newlines after a start tag or
right before an end tag to be preserved.  The parser will
generate the implicit tags which my processing engine then
converts back to actual newlines for output display.

Although this seems like a pain I believe the behavior of
the parser is logically correct and the only way to be consistent.

Michael Leventhal
Oracle Corporation


From connolly@pixel.convex.com  Fri Jan  8 19:35:55 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01737; Fri, 8 Jan 93 19:35:55 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29860; Fri, 8 Jan 1993 19:50:54 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA03545; Fri, 8 Jan 93 12:50:50 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA27549; Fri, 8 Jan 93 12:50:49 -0600
Message-Id: <9301081850.AA27549@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
Subject: Re: dealing with new-lines 
In-Reply-To: Your message of "Fri, 08 Jan 93 12:09:41 +0100."
             <9301081109.AA02814@www3.cern.ch> 
Date: Fri, 08 Jan 93 12:50:48 CST
From: Dan Connolly <connolly@pixel.convex.com>


>For what it is worth, the way the CERN implementations are supposed to work is:
>
>This means that any number of newlines  
>will only produce one white space character.  [It involves a horrid "are we in
>the middle of a word?" flag.]

I don't think this flag is "horrid." It's a pretty normal text-formatting
thing to do.

>Spaces, however, always produce spaces, so multiple spaces will come out as  
>multiple spaces.

Is anyone distressed by the situation where some browsers compress
multiple spaces [in typeset paragraphs] into one, and some do not? I'm not.
I'd say "Don't do that" to the fool who put multiple spaces in
his source.

>	XMP
>	
>Within <XMP> I went all the way and said that from the trailing > of <XMP>
>to the beginning <of </XMP> all data was litteral, including newlines.  
>Therefore example sections typically are marked up as
>
><XMP>This is an example line
>
></XMP>
>That was an example.  There are no new lines between the <XMP> and the example
>line because the XMP section causes a paragraph break, and the style for the  
>normal paragraph specifies a minimum white space after each paragraph.

This looks like sound policy to me.

> Beacuse
>each XMP section is like a black box, any white spce inside it would not be  
>seen by the white space management logic which overlaps the white spaces  
>required around successive paragraphs, and extra white spce would result.

Unfortunately, this conflicts with the SGML standard. An SGML parser
will report
<XMP>
foo
</XMP>

as
an XMP start tag
the string "foo" [NOT "\nfoo\n"]
an XMP end tag

And so it is, strictly speaking, illegal to treat the above markup
differently from
<XMP>foo</XMP>

I'm not sure how we should resolve this.

>	PRE
>
>By the way, I think we agreed (I gave in) that the <PRE> sections would have
>siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which
>gives double spacing on my browsers.  So I tread newlines as newlines in all
>the <PRE> element just as XMP.

This is a situation we need to resolve, one way or another. I'm inclined
to decide that <p> elements are allowed in PRE elements, but they have
no significance. They were put there to cause the old linemode browser
to break the line, so they have always been redundant. So Tim's treatment
of newlines in PRE is correct, but his treatment of <P> there is not
[by this new convention.]

Dan


From connolly@pixel.convex.com  Fri Jan  8 20:36:03 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02065; Fri, 8 Jan 93 20:36:03 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01710; Fri, 8 Jan 1993 20:51:03 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA05950; Fri, 8 Jan 93 13:50:57 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06847; Fri, 8 Jan 93 13:50:55 -0600
Message-Id: <9301081950.AA06847@pixel.convex.com>
To: Michael Leventhal <mleventh@us.oracle.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: SGML newline processing 
In-Reply-To: Your message of "Fri, 08 Jan 93 10:32:22 PST."
             <9301081832.AA06229@hqsun4.us.oracle.com> 
Date: Fri, 08 Jan 93 13:50:54 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>>From what I can tell, a newline is ignored by the SGML parser
>>if it's right after a start tag or right before an end tag.
>
>I haven't been following the discussion closely enough to know
>if a suggestion for dealing with the problem will be helpful,
>but...
>
>I use the SHORTREF feature to implicitly recognize an EMPTY
><newline> tag wherever I want newlines after a start tag or
>right before an end tag to be preserved.  The parser will
>generate the implicit tags which my processing engine then
>converts back to actual newlines for output display.
>
>Although this seems like a pain I believe the behavior of
>the parser is logically correct and the only way to be consistent.

Your argument is sound, but we're trying to design a format
that is defined completely in terms of SGML, but parsed by
homebrew code.

So the SGML declaration for HTML turns the SHORTTAG feature
off, saving us some parsing hassles.

If you're using a full-featured SGML parser, you can usually
tweak the DTD to make the stuff parse how you like through
shortrefs and the like. But we're using a bare-bones
SGML parser, so we're just trying to get by without
conflicting with the standard.

Dan


From connolly@pixel.convex.com  Fri Jan  8 20:42:44 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02102; Fri, 8 Jan 93 20:42:44 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01873; Fri, 8 Jan 1993 20:57:42 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA06326; Fri, 8 Jan 93 13:57:34 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA07944; Fri, 8 Jan 93 13:57:33 -0600
Message-Id: <9301081957.AA07944@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: new HTML spec, sample implementation 
In-Reply-To: Your message of "Fri, 08 Jan 93 16:14:15 +0100."
             <9301081514.AA02989@www3.cern.ch> 
Date: Fri, 08 Jan 93 13:57:32 CST
From: Dan Connolly <connolly@pixel.convex.com>


[Tim: could you limit your lines to 72 chars like the
rest of the world? It's a pain to deal with lines that
have been split by wierd MTA's.]

>	The spec available as:
>	http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/930106/HTML.html
>	
>	The older versions are all availavle as well.. link to a list of them
>	from the Markup futures page.

Unfortunately, the most recent version of the spec is the hardest to
find. I'd like most of the pointers to the older versions to be
updated. And I'd like to see the instructions to data providers
brought up to date. Currently, most of the documentation (especially
the exmples) doesn't say to quote HREFs, for example.

>>WHERE DO WE GO FROM HERE?
>>  * registering HTML with the IANA
>>  much of the spec is "by example," that is, tolerated.html
>>  demonstrates the tolerated techniques much better than
>>  it explains them.
>
>I agree that this compilicates it.  The explanation is in large part in
>files which are likely to be unreadable by many browers!

The "explanation" is nothing more than an implementors guide. I
thought that implementors would get more from example HTML code
than any prose I could come up with in a reasonable amount of
time. I agree that much is needed in the way of real documentation.

>We would then generate a paper document out of all the hypertext and the .txt
>files, and the document generator won't fall over!
>
>I would also like to see a node on each tag.  I found from user comments that 
>the current explanations of HTML or just not good enough. We need some stuff on
>the side of the spec explaining what each tag is actually FOR, with an example
>of each, acessesed from a reference section.  Maybe that can wiat till after  
>IANA registration, though.

My point exactly: for the IANA, all we need is a correct spec,
not necessarily an easy to use spec. That's what I meant
by "workable."

I don't have time to do a good job explaining how to use HTML.
I just wanted to explore all the technical issues and clear
them up.

>>  * bringing implementations into compliance
>
>It sounds as though (1) HTML.c should be turned into a structued hypertext
>object built on top of -- in the line mode case only -- the HText.c object.

Agreed.

>I feel that the SGML parsing object should create the textobject, because
>one SGML file could cause many displayable objects to be created -- in the  
>future at least.  Theerfore, it is not enough to pass the SGML object the ID
>of an already-created text object. Does that make sense?

At first it didn't, but upon reading it again, it's exactly what
I had in mind.

>Otherwise I think our architecures are converging ... do you want to make
>a new WWW/Library and I'll try it out?  I can release it in parallel with
>the current one for a while for safety.

If I find time, I'd like to.

>	Are the ISO latin 1 characters in  
>http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/921203/ISOlat1.html
>	in order? it would be useful to have their character code there.

This question seems to confuse two things: the ISOlat1 entity
set, and the ISO Latin 1 character set. The first is mapping
of names to glyphs, and the second is a mapping from the numbers
128-255 to glyphs. I think they're in alphabetical order
by name, but not in order by the ISO Latin 1 character set.

>I would have thought the SGML engine ought to be able to resolve all entities.

The SGML parser is responsible for resolving text entities. There
are also external data entites, which are ultimately resolved by
the application. I was leaning towards treating ISO latin characters
as external data entities, rather than text entities. If we treat
ISOlatin characters as SGML characters, we eliminate the need for entity
references in HTML altogether (we could still support &ouml, &lt etc.
however)

Here is the crux of the matter:

>The communication between it and the text object would have to be defined in  
>terms of a particular character set

And this character set is stated in the SGML declaration at
the top of html.dtd.

If we define HTML in terms of the
full ISO Latin 1 character set, then the parser can deal with
&ouml, and pass it to the text object as a data character, just
like an 'A' character. For X displays using iso8559 fonts, that's
cool.

But on a PC or a Mac, that means the text object will have to
scan all the data it gets and convert the Latin1 encoding to
it's own. Yuck.

>... and perhaps if there is more than one  
>contender the SGML engine could have a compilation option.

Hmmm... One might argue that as long as we support conversion inside
the SGML parser for EBCDIC machines, we might as well support PC and
Mac character sets while we're at it.

My original plan was that the core of wwwlib would support
ASCII only, and application developers would deal with latin
characters by name. Moving Latin-1 characters into the core
complicates it somewhat, and I'm still against that.

Dan


From mleventh@us.oracle.com  Fri Jan  8 21:20:59 1993
Return-Path: <mleventh@us.oracle.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02221; Fri, 8 Jan 93 21:20:59 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03007; Fri, 8 Jan 1993 21:35:57 +0100
Received:  from hqsun4.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
	id AA27399; Fri, 8 Jan 93 12:35:56 PST
Received:  by hqsun4.us.oracle.com (5.59.10/37.3)
	id AA08237; Fri, 8 Jan 93 12:35:54 PST
Message-Id: <9301082035.AA08237@hqsun4.us.oracle.com>
Date: Fri, 8 Jan 93 12:35:54 PST
From: Michael Leventhal <mleventh@us.oracle.com>
To: connolly@pixel.convex.com
Subject: SGML newline processing
Cc: www-talk@nxoc01.cern.ch


>>>>From what I can tell, a newline is ignored by the SGML parser
>>>if it's right after a start tag or right before an end tag.
>>
>>I haven't been following the discussion closely enough to know
>>if a suggestion for dealing with the problem will be helpful,
>>but...
>>
>>I use the SHORTREF feature to implicitly recognize an EMPTY
>><newline> tag wherever I want newlines after a start tag or
>>right before an end tag to be preserved.  The parser will
>>generate the implicit tags which my processing engine then
>>converts back to actual newlines for output display.
>>
>>Although this seems like a pain I believe the behavior of
>>the parser is logically correct and the only way to be consistent.
>
>Your argument is sound, but we're trying to design a format
>that is defined completely in terms of SGML, but parsed by
>homebrew code.
>
>So the SGML declaration for HTML turns the SHORTTAG feature
>off, saving us some parsing hassles.
>
>If you're using a full-featured SGML parser, you can usually
>tweak the DTD to make the stuff parse how you like through
>shortrefs and the like. But we're using a bare-bones
>SGML parser, so we're just trying to get by without
>conflicting with the standard.
>
>Dan

I'm at home with the flu, without my copy of ISO 8879 and I
haven't become one who can quote clause and sub-clause from
memory (yet :-)), but ...

SHORTTAG is an optional feature, but SHORTREF is not, since
it is required in the SGML declaration.  I think, according
to the standard, a system which does not support SHORTREF
is not compliant and therefore not even minimum SGML.

My solution only requires SHORTREF.  I code:

<!ELEMENT	newline	- o		EMPTY>
<!ENTITY	nltag	STARTTAG	"newline">
<!SHORTREF	nlmap	"&#RS;"		nltag>
<!USEMAP	nlmap			(verbatim)>

The use of OMITTAG in the newline element is not
necessary.  This code causes the parser to recognize
record starts as newline tas within verbatim tags.
My processor converts the newline tags back to record
starts.

Michael Leventhal
Oracle Corporation
mleventh@us.oracle.com




From fine@cis.ohio-state.edu  Fri Jan  8 21:23:57 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02265; Fri, 8 Jan 93 21:23:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03129; Fri, 8 Jan 1993 21:38:55 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA14229; Fri, 8 Jan 93 15:38:20 -0500
Date: Fri, 8 Jan 93 15:38:20 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301082038.AA14229@soccer.cis.ohio-state.edu>
To: connolly@pixel.convex.com, @cis.ohio-state.edu@cis.ohio-state.edu
Subject: Re: dealing with new-lines 
Cc: www-talk@nxoc01.cern.ch
X-Mailer: Perl Mail System v1.1


>Darn good question. Your approach appears to have the correct
>results, but I'm not sure it's practical for many implementations
>(global search-and-replace operations are inconvenient for
>sequential processing models), and it certainly isn't a healthy
>way to think about SGML documents.

But most browsers seem to have cacheing anyway, which means they can do
global search/replace.  But you can still do it more or less sequentially.
Just buffer strings of new-lines until you know what follows them, and
then deal with it.  There's no method you can propose which is correct
and doesn't involve storing something somewhere.

>The way to think about SGML documents, IMHO, is this: the sequence
>of characters comprising an SGML document are presented to an
>SGML parser, which parses the markup from the data and passes
>the "results" to the processing application.

This is another alternative I considered.  But I figured that I have to
deal with various parsing things when I read the HTML anyway.  I was
just going to take each chunk of data, (with anchors pre-processed out)
and remove all whitespace at the beginning and end (except for PRE sections
and such).  But if someone put in whitespace, why should I muck with it?
Who knows, they might have even wanted it there.

>>1. For each tag NOT in
>>     <PRE> </PRE> <A> </A> <PLAINTEXT>
>>   remove ALL surrounding new-lines.
>
>First, let's get one thing straight: the PLAINTEXT element as
>described by the original HTML documentation is not representable
>in SGML. For my purposes, I consider the HTML document to
>end at the <PLAINTEXT> tag, and I consider the rest of the
>data stream to be an RFC-822 message body or a MIME text/plain body,
>and not SGML at all.

I hadn't meant otherwise.  But you have to read it in anyway, and since
my method deals with things prior to any other parsing, you treat it
all as one clump.

>Next, let's keep in mind that you can't do things like the following
>global substitition,
>s/\n+(<(H1|H2|ADDRESS...))>/$2/g;
>because it might find things that look like tags but aren't,
>for example
>
><foo bar="
><H1>this is a little cooky, but nontheless legal and possible.">
>
>But even if you're using a proper SGML parser, consider:
>
><H1>Here we go!
><a href="#xyz">click here</a>
>There we went!
></H1>
>
>The parser will return an H1 start tag, and then the
>string "Here we go!\n". At this point, your rule doesn't
>tell me what to do with the newline. I have to get
>the next object before I decide.

Like I said before, You have to do some sort of storage at some point
anyway.

>Hmm... I guess that's reasonable. But I'd rather just pass all the

Like I said before, You have to do some sort of storage at some point
anyway.

>My point is: don't use whitespace to represent significant
>information except in the PRE elemnt. Use the tags that
>are defined to have significance.

I suppose I agree with this more or less, at least from the point of view
of generating my own code.  But we have to make something clear - can
a browser keep all the whitespace if it wants to?  Or in other words,
can an html generator assume collapsing whitespace, or just be aware
that it might happen?

	 tom

From fine@cis.ohio-state.edu  Fri Jan  8 21:37:21 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02377; Fri, 8 Jan 93 21:37:21 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03551; Fri, 8 Jan 1993 21:52:21 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA14305; Fri, 8 Jan 93 15:52:19 -0500
Date: Fri, 8 Jan 93 15:52:19 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301082052.AA14305@soccer.cis.ohio-state.edu>
To: connolly@pixel.convex.com, timbl@nxoc01.cern.ch
Subject: Re: dealing with new-lines 
Cc: www-talk@nxoc01.cern.ch
X-Mailer: Perl Mail System v1.1

>> Beacuse
>>each XMP section is like a black box, any white spce inside it would not be  
>>seen by the white space management logic which overlaps the white spaces  
>>required around successive paragraphs, and extra white spce would result.
>
>Unfortunately, this conflicts with the SGML standard. An SGML parser
>will report
><XMP>
>foo
></XMP>
>
>as
>an XMP start tag
>the string "foo" [NOT "\nfoo\n"]
>an XMP end tag
>
>And so it is, strictly speaking, illegal to treat the above markup
>differently from
><XMP>foo</XMP>
>
>I'm not sure how we should resolve this.

This was almost the exact example I was playing with when I decided to start
this messy discussion.  Also some paragraph examples.  Both of the following
should mean the same:

some text<P>more text

and

some text
<P>
more text

The latter being commonly used.  I realized that unless you could remove
surround new-lines in cases like this, the second paragraph would start
with a space.  Similarly, you might find headings, or other things with
a space at the beginning.

>>	PRE
>>
>>By the way, I think we agreed (I gave in) that the <PRE> sections would have
>>siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which
>>gives double spacing on my browsers.  So I tread newlines as newlines in all
>>the <PRE> element just as XMP.
>
>This is a situation we need to resolve, one way or another. I'm inclined
>to decide that <p> elements are allowed in PRE elements, but they have
>no significance. They were put there to cause the old linemode browser
>to break the line, so they have always been redundant. So Tim's treatment
>of newlines in PRE is correct, but his treatment of <P> there is not
>[by this new convention.]

Note that the method I proposed has the advantage of automatically dealing
with this (sort of).  If the document was converted simply by adding a <P>
to the end of each line, then for such lines, I remove the newline but keep
the <P>.  Then the code that deals with PRE sections can happily honor
both new-lines and <P> tags, thus making it compatible with either style.

	tom

From connolly@pixel.convex.com  Fri Jan  8 21:37:18 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02374; Fri, 8 Jan 93 21:37:18 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03547; Fri, 8 Jan 1993 21:52:17 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09347; Fri, 8 Jan 93 14:52:12 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA17146; Fri, 8 Jan 93 14:52:10 -0600
Message-Id: <9301082052.AA17146@pixel.convex.com>
To: Michael Leventhal <mleventh@us.oracle.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: SGML newline processing 
In-Reply-To: Your message of "Fri, 08 Jan 93 12:35:54 PST."
             <9301082035.AA08237@hqsun4.us.oracle.com> 
Date: Fri, 08 Jan 93 14:52:09 CST
From: Dan Connolly <connolly@pixel.convex.com>


>SHORTTAG is an optional feature, but SHORTREF is not, since
>it is required in the SGML declaration.  I think, according
>to the standard, a system which does not support SHORTREF
>is not compliant and therefore not even minimum SGML.

Hmm... I've got the standard in my lap, and while it usually
takes me at least 1/2hour to be sure I've reall all the
relavent sections, it appears to agree with your statement.

However, we're only interested in parsing instances of
a particluar DTD.

If we make no SHORTREF declarations in this DTD, we can
dispense with shortref processing in our parser.

>My solution only requires SHORTREF.  I code:
>
><!ELEMENT	newline	- o		EMPTY>
><!ENTITY	nltag	STARTTAG	"newline">
><!SHORTREF	nlmap	"&#RS;"		nltag>
><!USEMAP	nlmap			(verbatim)>
>
>The use of OMITTAG in the newline element is not
>necessary.  This code causes the parser to recognize
>record starts as newline tas within verbatim tags.
>My processor converts the newline tags back to record
>starts.

Hmmm... this is interesting. First a question: why
the newline element in the first place? why not just
make the shortref expand to a newline character in
the first place?

If we put declarations like this in the HTML DTD, it
would then be legal to treat

<XMP>
foo
</XMP>

different from <XMP>foo</XMP>

Thanks for the idea... it just might work!

Dan

From mleventh@us.oracle.com  Fri Jan  8 23:19:31 1993
Return-Path: <mleventh@us.oracle.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03123; Fri, 8 Jan 93 23:19:31 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05919; Fri, 8 Jan 1993 23:34:28 +0100
Received:  from hqsun4.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
	id AA02212; Fri, 8 Jan 93 14:34:25 PST
Received:  by hqsun4.us.oracle.com (5.59.10/37.3)
	id AA10337; Fri, 8 Jan 93 14:34:22 PST
Message-Id: <9301082234.AA10337@hqsun4.us.oracle.com>
Date: Fri, 8 Jan 93 14:34:22 PST
From: Michael Leventhal <mleventh@us.oracle.com>
To: connolly@pixel.convex.com
Subject: Re: SGML newline processing
Cc: www-talk@nxoc01.cern.ch


>However, we're only interested in parsing instances of
>a particluar DTD.
>
>If we make no SHORTREF declarations in this DTD, we can
>dispense with shortref processing in our parser.

You've already decided to buy-in on SGML.  You must,
correctly, I think, see the immediate and long-term
advantages in adhering to the international standard.
"Conforming", the minimum set of features, is a
non-arbitrary baseline which you can expect all
html-capable parsers to meet.

One should be able to get a PhD for a good
SHORTREF dissertation.  I think I've gotten the gist
of some of the discussion though - SHORTREF must be
supported in the SGML declaration in order to deal with
some problems which arise through the handling of 
some special codes on some systems.  For example, &#RS;
&#RE; equivalent to &#RS on UNIX systems

It is quite possible that making your parser conforming
will save your neck someday.

>Hmmm... this is interesting. First a question: why
>the newline element in the first place? why not just
>make the shortref expand to a newline character in
>the first place?

I don't think you could do that, since SHORTREF is an
implicit tagging scheme.  Even if you could it wouldn't
help since it would leave the ESIS structure unchanged,
with the same filtering of newlines as content is passed
to the process.  My scheme changes the ESIS before content
is passed to the process.

Michael

From dsr@hplb.hpl.hp.com  Mon Jan 11 11:49:46 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13758; Mon, 11 Jan 93 11:49:46 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21299; Mon, 11 Jan 1993 12:04:47 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 11 Jan 93 11:01:29 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA23480; Mon, 11 Jan 93 11:05:51 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301111105.AA23480@manuel.hpl.hp.com>
Subject: Re Re Customer pull on HTTP2
To: www-talk@nxoc01.cern.ch
Date: Mon, 11 Jan 93 11:05:48 GMT
Cc: dsr@hplb.hpl.hp.com
Mailer: Elm [revision: 66.25]

Kevin Hoadley says in:

>> Caching
>>-------
>>
>> It will be desirable to avoid overloading servers with popular documents by
>> supporting a caching scheme at local servers (or even at browsers?).

> This as well as caching, replication would be nice. But this is only
> practical if resource identifiers do not contain location information
> (otherwise replication is only possible by making all the peer servers to
> appear to be one machine, as in the DNS CNAME suggestion I made some time
> ago). But if resource identifiers do not contain host information then you
> need an external means of determining how to reach the resource.
> This is analagous to routing protocols (an address is not a route ...).

> Such a system is probably over ambitious for now.

I agree, but it is important to keep an eye of where things are going.
The ability to replicate documents in this way will depend on name servers
e.g. X.500. In the meantime is this necessary? At first, a simple scheme is
to send all remote requests via a fast local server. This server checks if
this Udi is in its cache, and if not forwards the request to the machine
named in the Udi itself. You can extend this to take advantage of several
caches, and the work done by ANSA (Advanced Networked Systems Architecture)
on trading may be apropriate.

... talking about when to purge the cache

> I think this is silly. I haven't changed a document for six months,
> therefore it is safe to say that it won't be changed for the next six
> months ...

Yes, perhaps not one of my best ideas! I think we need some position in
between caching docs only for several minutes, and the full replication
mechanism used with network news and nntp.

One approach is for the server to periodically refresh cache contents. (This
is what Lotus Notes does). You set it up to refresh docs at night, or perhaps
on a trickle basis in the background. The problem is knowing what the
appropriate interval is for each document. The "Expiry:" field or an
equivalent "KeepFor:" (time to live) field when present gives an explicit
suggestion. My "silly" suggestion was a rule of thumb aimed at allowing the
sever to "learn" that some docs don't change much, and so can be refreshed at
longer intervals.

Another complimentary approach is to provide a machanism whereby a server
owning a document informs a list of client servers when it determines that a
given document has changed. This is critical for a successful room booking
application. For this to work, the protocol needs to include the requests:

    NOTIFY hplose.hpl.hp.com:8001
    ADD Udi
    RETRY   1000 10

This is used to inform a server (named in the Udi) that another server
(IP address: hplose.hpl.hp.com, port 8001) wishes to be informed when this
document is changed or deleted. The RETRY parameter is optional and used to
determine the notification retry interval in seconds, followed by how many
times to try.

    NOTIFY hplose.hpl.hp.com:8001
    REMOVE Udi

The reverse operation removing a server from a notification list

    CHANGED Udi
    <Doc header>
    <Doc body>

The message sent to servers on the notification list when the specified doc
has changed. If the doc has been deleted then the body should be empty.

In the case where it is currently impossible to establish a connection with a
server on the notification list, the notification should be periodically
retried until a suitable timeout period has expired. See earlier RETRY field.

You don't need to complicate the http server loop to implement this
mechanism as notifications can be handled by a separate program.

... talking about problems with comparing date/time info

> This also depends on hosts agreeing on the date. To quote
> RFC1128, talking about a 1988 survey of the time/date on
> Internet hosts, "... a few had errors as much as two years"

Wow! I had no idea that this was the case. I had hoped that all machines
would have support for date/time conversion for all known time zones, so
that by including the time zone as part of the format, there would be no
problem.

>> I think that we need to provide an operation in which the server returns a
>> document only if it is later that a date/time supplied with  the request. 

> This would be useful as part of a replication system, as long as both ends
> exchanged timestamps initially so that the dates can be synchronised.

In this case we need to define how servers should process date/time info,
particularly when a mismatch is detected.

... talking about copyright protection

> It may be stating the obvious, but once you allow a user to access you
> data such that they can save it, there is no technical way you can prevent
> them from publically redistributing your data. This is a social/legal
> problem, not a technical one. Accepting that nothing can be done to stop
> deliberate abuse of licensed information, there is a need to prevent
> accidental abuse.

There is no *techical way* to stop me driving my car at a passerby and
killing him! The answer is that it is illegal to breach the copyright law.
In HP we have notices next to each photocopier, reminding us of what the law
allows us to do. The same will apply to networked access. Publishers are
concerned that they receive fair payment for their information, and the
critical issue is to ensure that all processes can pass an audit to show
their compliance.

My idea is that its ok to cache copyrighted docs so long as you put in an
effective mechanism for logging and handling payments. This mechanism must be
able to pass a suitable audit procedure. I believe that the scheme I described
would do this.

> Probably the simplest way to do this is to mark the
> document as one which should NOT be cached.

You need to separate the issue of copyright protection from ensuring secure
access to restricted information. I proposed the "Distribution:" header for
this purpose.

Many thanks for your comments,

Best wishes,

Dave Raggett, dsr@hplb.hpl.hp.com

From timbl@www3.cern.ch  Mon Jan 11 14:37:14 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14405; Mon, 11 Jan 93 14:37:14 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12769; Mon, 11 Jan 1993 14:52:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00475; Mon, 11 Jan 93 14:51:51 +0100
Date: Mon, 11 Jan 93 14:51:51 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301111351.AA00475@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: new HTML spec, sample implementation 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


Dan,


[I will limit the lines to 72 instead of 80, -- sorry!]

I have changed the links which I could find to point to the new DTD  
and the new spec.  There is a soft link "Current" so that one can  
link to the latest version but still allow reference and access to  
previous dated versions. See  
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/History.html

I have also edited the general description of HTML to bring it  
further into line with the DTD, I hope.  I have reorganised it so  
that there is more scope for adding detailed guidance and more  
examples.

I have put in a WIDTH attribute on PRE.  I have put in LINK.
Could we have both in the DTD next time?

I could do with references for the origins of the character  
highlighting elements, so as to pick up descriptions of them.  I have  
just guessed in  
http://info.cern.ch/hypertext/WWW/MarkUp/Highlighting.html.

Tim


From timbl@www3.cern.ch  Mon Jan 11 15:06:21 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14527; Mon, 11 Jan 93 15:06:21 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16320; Mon, 11 Jan 1993 15:21:27 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00499; Mon, 11 Jan 93 15:20:58 +0100
Date: Mon, 11 Jan 93 15:20:58 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301111420.AA00499@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: dealing with new-lines 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> This is a situation we need to resolve, one way or another. I'm inclined
> to decide that <p> elements are allowed in PRE elements, but they have
> no significance. 


That would complicate certainly the CERN browsers, in that if they see a <p>  
they always do the same thing.   They don't have mechanisms for being  
context-sensitive about these things -- they just do the right thing with
good HTML and don't bomb out with bad html.

I'd prefer us to say that the effect of <P> within <PRE> is undefined, or that  
it is not recommened but if used is a newline.  I'd like Thomas to take them  
out of his man pages, but butil then it isn't a disaster, its just double  
spacing.  I feel that it would be a kludge to say they had no effect within  
<PRE>  ... it would look weird to historians.

	--

I am prepared to change the <XMP> behaviour to be standard SGML for the sake of  
it even if the example secitions in our documents end up moving up or down a  
line as a result.


Tim

From dsr@hplb.hpl.hp.com  Mon Jan 11 16:26:35 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14999; Mon, 11 Jan 93 16:26:35 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28423; Mon, 11 Jan 1993 16:41:37 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 11 Jan 93 15:38:22 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA23888; Mon, 11 Jan 93 15:42:44 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301111542.AA23888@manuel.hpl.hp.com>
Subject: Re HTTP2: caching and copyright
To: www-talk@nxoc01.cern.ch
Date: Mon, 11 Jan 93 15:42:41 GMT
Cc: dsr@hplb.hpl.hp.com
Mailer: Elm [revision: 66.25]

These are comments on Tim's responses to my recent message on HTTP2.

>>   o   the "Expires:" field is optional

> agreed.

>>   o   the date values should be in a prescribed format to simplify
>>       machine interpretation (Is this adequately defined by existing RFCs?)

> agreed. yes it is, in RFC850

RFC977 provides a tighter definition for date/time restricting it to the time
zone of the server or GMT. I would like us to restrict it to GMT period - as
otherwise how can you in general find out the time zone of the server?

    NEWGROUPS date time [GMT] [<distribution>]

    The date is sent as 6 digits in the format YYMMDD, where YY is the last
    two digits of the year, MM is the two digits of the month, (with leading
    zero, if appropriate), and DD is the day of the month (with leading zero,
    if appropriate). The closest century is assumed as part of the year, i.e.
    86 specifies 1986, 30 specifies 2030, 99 is 1999, 00 is 2000).

    Time must also be specified. It must be as 6 digits HHMMSS with HH being
    hours in the 24-hour clock, MM minutes 00-59, and SS seconds 00-59.
    The time is assumed to be in the server's time zone unless the token "GMT"
    appears, in which case both time and date are evaluated at the 0 meridian.
    
RFC850 mentions that not all time zones have well known abbreviations,
making it difficult to carry out date/time arithmetic. Furthermore, Kevin
Hoadley's comment:

          This also depends on hosts agreeing on the date. To quote
      RFC1128, talking about a 1988 survey of the time/date on
      Internet hosts, "... a few had errors as much as two years"

suggests we will have problems with servers in this regard.
One solution would be for the server to send a field with each document:

        KeepFor: nnnn seconds | mmm days

The cache management software then notes the date/time received and works
out for itself the expiry date/time. This method has the great advantage of
avoiding all need for date/time conversion, and any reliance on the server's
having their clocks setup correctly.


>> I think that we need to provide an operation in which the server returns a
>> document only if it is later that a date/time supplied with  the request. If
>> it is the same (or earlier) the server should return a suitable status code
>> and an optional "Cost:" header, see below.

> Need to look at NNTP here.  We end up getting very close indeed to it.
> I would want the functionalty of this search to map onto the NEWNEWS
> very nicely.  A newsgroup is just a hypertext list anyway.

I like the NEWNEWS command, but feel we should keep the GET & SINCE command.
The latter allow you to refresh a cached document with one exchange whereas
you need two when using NEWNEWS and a subsequent GET.

The NEWNEWS command is intended for finding new basenotes and responses,
and should be contrasted with the NEWGROUPS command.

>> Note that servers shouln't cache documents with restricted readership since
>> each server don't know the restrictions to apply. This requires a further
>> header to identify such documents as being unsuitable for general caching:
>> 
>>     Distribution: restricted | unrestricted

> Good point.  Not the the distribution of other messages is in the form of
> To: and Cc: and Newsgroup: and in fact Distribution:.  (See  
> http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z12)
> So you'll need a new fieldname.  If we could only merge the functionality of  
> these systems in some cool way, it would be grand.

I don't understand the description of "Distribution: nj.all" in RFC850
(section 2.2.8). It is unclear what its argument is. Is it a geographical
hierarchy or is it some kind of newsgroup name with the "all" wildcard?

It would be nice in some circumstances to define the readership groups for
situations where a server could apply group membership information to restrict
readership. This field would be supplied by the author. This idea is I believe
in the same spirit as RFC850. Consider the following example:

    Distribution: incl.kbpd psl.all

This says that the document can be given to anyone in psl and anyone in the
kbpd subgroup of incl. You can make these names correspond to your
organisation. The maintenance of these readership groups is outside the scope
of the HTTP2 protocol. Local servers shouldn't cache documents including this
header unless they "understand" the specified readership groups and can apply
the same membership tests. This involves sharing the same definitions across a
group of servers, for instance within a campus or a company.

>> I would like the document header to include an optional cost header, e.g.
>>
>>      Cost: 4.05 US DOLLARS
>>      Copyright: Reuters Inc.

> I note here that both the copyright holder and the account for charging are 
> items in some address space, and we ought to be as flexible with these
> address spaces as with the udi.  So I would propose something like
>
>    ChargeTo:  HPInternal:/8126/148689  upto $2.00
>    
> would be better.  But how does this fit in with authentication?  Once you
> are authenticated, your prefered method of paying will be known.  You can't
> have charging without authentication!

Four points:

First, it certainly isn't the case that once you are authenticated
then the way of charging you is known. For example consider members of
the public wishing to pay for information using a credit card number for a
service they have never before accessed. In HP it may in some cases be
sufficient to check that the client's internet address starts with the
company's subnet code. However, the server still needs the employee
name, number and location code to cross charge.

Second, I don't think the "upto" concept is needed. In the vast majority of
cases a fixed cost will suffice. A point to watch when keeping documents in
local caches, is that this cost may change from time to time. This
corresponds to pricing of normal goods, and I believe can be adequately
handled by appropriately setting the "KeepFor" or "Expires" field.

Third, for legal purposes it is still necesary to tag documents with who owns
the copyright, as in books, music and other products. For this reason we
should include the "Copyright:".

Fourth, I like the idea of a universal scheme for naming the copyright owner
and charging method, but feel that this will take some time to take effect.
For the moment I would like to stick to the following:

    Cost: 4.05 US DOLLARS
    Copyright: 1988 Time International Inc.
    ChargeTo: HP/8126/148689

Where the meaning of the "CopyRight:" and "ChargeTo:" fields is outside the
scope of the HTTP2 protocol specification. The "Cost:" field always starts
with the amount and should be followed by the currency name.

The requesting GET could include an optional header:

    CostingUpTo:  2.50 US DOLLARS

This would result in the server returning an error message if this was less
than the cost of the requested document, and introduces issues of how
to recognising currency type and performing currency conversion. Users should
be able to see how much they will have to pay on preceding hypertext pages
(as supplied by the server).

> A simple thing in the first instance is to say that it illegal to cache
> a for-pay document unless you have a privat earrangement with the owner
> about refunding him.  This could be done using a completely separate billing
> process.

No. You can only get copies of documents for which the server recognises that
there is an effective arrangement for making the payment. However, if this is
the case, then caching presents no problems, provided the authetication and
ChargeTo information is preserved and supplied to the server with the GOT
command.

I will try and lay my hands on a copy of "Litterary Machines".

>> The protocol ought to allow for multiple GOT statements (and associated
>> headers in the same message. For this it seems simple enough to require a
>> terminating blank line.

> Hey, that;s not something you do for one method, it's a change to the whole 
>  protocol to introduce pipelining.

Oh dear! It seems a waste to have to set up a connection for each such
request. Perhaps the safest thing is to allow multiple Udi's with the GOT
command, all of which must be for the same client. What limits are there on
line length for headers or is there a mechanism for continuing arguments on
subsequent lines? This would still be effective in limiting network traffic,
and processing time.

>>  Effective support for discussion groups

>> My model is that discussion groups each have unique Udi's. Each discussion
>> group has a sequence of base notes, and each base note is associated with a
>> sequence of responses. I am unsure of how to deal with cross postings!

> I agree that the POST method is well defined as a method of the
> newsgroup class which takes an article as a parameter. In fact, as you say,
> cross-posting makes a mess of this, as it involved many groups in one atomic 
>  operation.  This is a peculiarity of news which makes it difficult to map
> onto the object model.  Any ideas?

The NNTP protocol employs the POST command to post an article, and relies
on the document's header to specify the news groups for posting to with the
Newsgroups header. The "References:" header is used to link a response to any
articles prompting submission of this article.

Thus each article can be posted to multiple groups, and can have zero or more
references to preceding articles. For convergence between NNTP and HTTP2 we
need to clarify the mapping of groups and references.

News groups as currently defined are hierarchical name spaces without
reference to a server or filing system. The WWW model currently ties
documents to both of these. I would like to be able to post responses as
WWW documents which refer to one (or more?) existing documents. We can already
do this. What we can't do is to find what documents reference a given
document. This is hard in principle and practice since the various documents
can be on different machines scattered over the entire world.

The answer is to provide a mechanism which allows servers to track which Udi's
should be recorded as being "responses" to other Udi's.

What is the analogous concept to news group?

These are lists of articles, and not articles as such. The GROUP command in
NNTP allows you to identify articles in given groups. The LIST command returns
the complete list of groups known to the server, while the NEWGROUPS command
returns groups created since a specified date/time, and matching on specified
distribution categories.

I think that in WWW we should treat groups as named documents which are
generated by the server from the database of postings stored under that name.
The important thing is to distinguish between the Udi's of references and
those of news groups.

Given these ideas I will now present my suggestions for the POST command:

The document header supplied with the POST command has the following fields:

    Newsgroups:  <followed by one or more Udi's>        /* optional */
    References:  <followed by one or more Udi's>        /* optional */

Followed by one of the following:

    DocumentName: Udi       /* for an existing document - body is void */
    NewDocument:            /* for new document, contents follow as body */

The semantics are the same as for NNTP, except that the Newsgroups header is
optional. In otherwords you can post responses to any WWW document - it
doesn't need to be in a news group. The server should return the Udi of the
document if successful (note that the NNTP POST command doesn't bother with
this).

We can include support for ARTICLE, BODY, HEAD, LIST and NEWGROUPS commands in
a way very similar to NNTP. The GROUP command in NNTP returns the first and
last article number in the group. This is unlikely to be what we want - as it
depends of the special naming scheme used for network news articles. We are
probably more interested in getting a list of article names in the group. In
my earlier message I suggested that this could best be achieved using the GET
command in conjunction with SINCE and BEFORE parameters (to allow for really
humungous groups with thousands of base notes). The server is responsible for
interpreting this command with the appropriate database query.

A really useful command missing from NNTP is the ability to list the responses
to a given document, i.e. the command names a given document/article, and is
returned with the list of Udi's for documents which were posted with that
article as part of their references. It would be great if this list was sent
by the server along with the base document, as a separate part in a multipart
message.

Finally, I want to draw attention to post-it style annotations. It would be
really nice to be able to post a note at a particular point within a given
document. The browser would show such annotations as little post-it symbols
which you click to see their contents. This requires similar mechanisms to
that for discussion groups. Perhaps we could have an ANNOTATE command:

    ANNOTATE   Udi  /* including an anchor for positioning the annotation */

   (body follows)

Authors place anchors in documents to suit their own needs and not the
unforeseen needs of others. It is therefore necessary to general the anchor
syntax in document Udi's to support a more flexible scheme based on pattern
matching. Servers should send the document along with the list of annotations.

Comments please.

Best wishes and sorry for such a long response,

Dave Raggett


From connolly@pixel.convex.com  Tue Jan 12 00:05:27 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18162; Tue, 12 Jan 93 00:05:27 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11374; Tue, 12 Jan 1993 00:20:32 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA18643; Mon, 11 Jan 93 17:20:11 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA11428; Mon, 11 Jan 93 17:20:09 -0600
Message-Id: <9301112320.AA11428@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: new HTML spec, sample implementation 
In-Reply-To: Your message of "Mon, 11 Jan 93 14:51:51 +0100."
             <9301111351.AA00475@www3.cern.ch> 
Date: Mon, 11 Jan 93 17:20:08 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I have also edited the general description of HTML to bring it  
>further into line with the DTD, I hope.  I have reorganised it so  
>that there is more scope for adding detailed guidance and more  
>examples.

Ok... we're getting close to a workable document here. I have
some suggestions for the organization.

The "Hypertext Markup Language" document I wrote was supposed
to replace the root of the HTML documentation. I suggest we
merge them. I'll work on it and let you know what I come
up with.

>I have put in a WIDTH attribute on PRE.  I have put in LINK.
>Could we have both in the DTD next time?

The WIDTH attribute is there. I'll add LINK.

>I could do with references for the origins of the character  
>highlighting elements, so as to pick up descriptions of them.  I have  
>just guessed in  
>http://info.cern.ch/hypertext/WWW/MarkUp/Highlighting.html.

From (texinfo)Specifying in the GNU info hierarchy:

`@code'
     Indicates text that is a literal example of a piece of a program.

`@samp'
     Indicates text that is a literal example of a sequence of
     characters.

`@kbd'
     Indicates the names of keys on the keyboard or characters you
     type.

`@key'
     Used for the conventional name for a key on a keyboard.

`@var'
     Indicates a metasyntactic variable.

`@dfn'
     Indicates the introductory or defining use of a term.

`@cite'
     Indicates the name of a book.

[I left @file out of HTML -- can't remember why.]

From Emph and Strong:

`@emph' and `@strong' are two forms of emphasis.  `@strong' is
stronger.

From Fonts:

@i,  @b and @t
--------------

These three commands specify font changes in the printed manual and
have no effect in the Info file.  `@i' requests italic font (in some
versions of TeX, a slanted font is used), `@b' requests bold face,
and `@t' requests the fixed-width font used by `@kbd'.  All three
commands apply to an argument that follows, surrounded by braces.

If possible, you should avoid using these three commands.  If you
find a need to use one, it probably indicates a lack in the Texinfo
language.

Dan


From connolly@pixel.convex.com  Tue Jan 12 02:03:55 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18926; Tue, 12 Jan 93 02:03:55 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17639; Tue, 12 Jan 1993 02:19:01 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA24567; Mon, 11 Jan 93 19:18:58 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA21364; Mon, 11 Jan 93 19:18:57 -0600
Message-Id: <9301120118.AA21364@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: strategy for HTML spec?
Date: Mon, 11 Jan 93 19:18:56 CST
From: Dan Connolly <connolly@pixel.convex.com>


Save for newline handling and Latin 1 characters, I feel
that most of the technical issues in the HTML spec have
been ironed out.

But the documentation in the web is far from up to date.
My spec isn't sufficient to replace the HTML stuff in the
web, so it gets tacked on through links. Meanwhile, many
of the examples and explanations are in conflict with the DTD.

And we're not getting any closer to a hardcopy or plain text
version of the spec.

I started editing Tim's latest work on the HTML spec, but
it's not clear how my edits will get into the web. I don't
want them just tacked on: they're corrections to stuff that's
not right! But without groupware support, it's slow going.
Hmm... we need a better strategy.

[begin bitching and moaning...]

Also, I am frustrated that noone else seems willing to look
closely at SGML at all. The SGMLs parser makes it easy to
try stuff out, and comp.text.sgml is a great place to learn
a lot of stuff, but none of the other implementors have
bothered to try them out.

For example, Tim asked if I could put LINK into the DTD.
I wasn't familiar with the motivation for the element at
the time, and I'm still not sure how it works exactly:
how many of them are allowed, for example?

If he would take the time to construct a couple example
documents using LINK (and make the necessary modifications
to the DTD), I'm sure things would be much clearer.

Another example: the newlines issue. It's easy to edit
a couple example files, run them through sgmls, and see
where the parser eats newlines and where it reports them
to the application.

And none of the data providers has grabbed SGMLs to check
their output, as far as I can tell.

I have put a lot of my free time into investigating HTML
and its relationship to SGML, and I have done my best
to report my findings, but I'm getting frustrated by
the lack of initiative from anyone else. Other folks
are willing to hack out implementations, but they're
not willing to check them against the SGML standard,
it seems. If nobody else is serious about SGML conformance,
I will find other ways to spend my free time. But I
think SGML conformance is critical to the the quality
of the WWW project.

[end bitching and moaning]

Dan

From anthony@aaii.oz.au  Tue Jan 12 03:31:24 1993
Return-Path: <anthony@aaii.oz.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19338; Tue, 12 Jan 93 03:31:24 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22654; Tue, 12 Jan 1993 03:46:11 +0100
Received: from wyndham-estates.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII)
	id AA12557; Tue, 12 Jan 1993 13:44:35 +1100
Message-Id: <199301120244.AA12557@yarra-glen.aaii.oz.au>
Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0)
	id AA22021; Tue, 12 Jan 1993 13:44:25 +1100
Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0)
	id AA10614; Tue, 12 Jan 93 13:44:25 EST
To: Dan Connolly <connolly@pixel.convex.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: strategy for HTML spec? 
In-Reply-To: Your message of "Mon, 11 Jan 1993 19:18:56 CST."
             <9301120118.AA21364@pixel.convex.com> 
Date: Tue, 12 Jan 1993 13:44:24 +1100
From: Anthony Baxter <anthony@aaii.oz.au>



In message <9301120118.AA21364@pixel.convex.com>you write:
> [begin bitching and moaning...]
> Also, I am frustrated that noone else seems willing to look
> closely at SGML at all. The SGMLs parser makes it easy to
> try stuff out, and comp.text.sgml is a great place to learn
> a lot of stuff, but none of the other implementors have
> bothered to try them out.

Rest assured, others (well, me, at least :) are fiddling with SGML. Bear in
mind, however, that my knowledge of it is still really, really rudimentary.

Its a fairly overwhelming (at least on initial exposure) concept.

The stuff you've done is definately appreciated. You've managed to get HTML
to a much more formally described language than it was before, and also to
the point where it isnt changing from one week to another (which was a real
bummer).

Anthony
--
 anthony baxter                 australian artificial intelligence institute
email : anthony@aaii.oz.au         1 grattan st, carlton, australia 3053
    /\/\||                                  phone : +613 663 7922
  Disclaimer: Unless otherwise specified, the above is my opinion, not AAII's.

From connolly@pixel.convex.com  Tue Jan 12 05:21:44 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19869; Tue, 12 Jan 93 05:21:44 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28757; Tue, 12 Jan 1993 05:36:50 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA01091; Mon, 11 Jan 93 22:36:45 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA00126; Mon, 11 Jan 93 22:36:43 -0600
Message-Id: <9301120436.AA00126@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: HTML todo list
Date: Mon, 11 Jan 93 22:36:43 CST
From: Dan Connolly <connolly@pixel.convex.com>

Please excuse the bitching and moaning from the last message.
My motto is "Accept the situation or do something about it."
Kind of a condensed version of the serenity prayer.

Since I don't have resources to fix the whole HTML situation,
here's a laundry list of everything I can think of about
HTML. Perhaps discussions and code fixes can refer
to "#15 in the HTML todo list" for example.


In http://info.cern.ch/hypertext/WWW/Technical.html

1. My dictionary lists "markup" as a word, not mark-up.
  HTML format[4]          A description of the mark-up language used for some
                         documents and for search hit-lists.

In http://info.cern.ch/hypertext/WWW/Daemon/Bugs.html
2. The PLAINTEXT situation should be logged as a bug against
the server. PLAINTEXT is deprecated.

In http://info.cern.ch/hypertext/WWW/FAQ/List.html
4. HTML should support QUESTION and RESPONSE elements to
support converting USENET FAQ's to HTML

In http://info.cern.ch/hypertext/WWW/Provider/ShellScript.html
5. PLAINTEXT is deprecated. Use PRE, and use a sed script
to change < to &#60, > to &#62, and & to &#38.

6. http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/dir2html.txt
This thing doesn't quote attributes; it uses XMP in stead of
PRE with numeric character references.

7. http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/ls2html.awk.txt
Quotes around HREFS, PLAINTEXT.

8. http://info.cern.ch/hypertext/WWW/Daemon/Implementation/asis.txt
Quote HREFS, numeric character references where necessary.

9. http://info.cern.ch/hypertext/WWW/HytelnetGate/src/htn2html.c
Uses HEADER in stead of HEAD.
Quote HREFs.
Special character entities?
Yeah! It uses numeric character references already!

In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
10. Mark-up again

11. This text seems out of place:
WWW parsers should
ignore tags which they do not understand,
and ignore attributes which they
do not understand of tags which they
do understand.

12. Default text: this node seems to confuse lots of issues. I suggest
we get rid of it. The way to look at HTML is as a stream of data and
markup. Newlines are handled differently all over the place. It might
be reasonable to talk about how newlines are handled by the text
formatter, after they have been handed over from the SGML parser.

In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
13. This text is out of place: 
Each tag starts
with a tag opener (a less than sign)
and ends with a tag closer (a greater
than sign).   Many tags have corresponding
closing tags which identical except
for a slash after the tag opener.

It's more thoroughly discussed in
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html
[which still needs revision: it's correct, but could use better
organization.]

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/HEAD.html
14. These blurbs should probably quote their element declarations
from the DTD, in order to help folks learn to read the DTD.
"Only certain elements are allowed" is vague: there are restrictions
about the order and occurence sometimes too.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/TITLE.html
15. This seems redundant:
The title of a document is given
between title tags:
<pre>		&#60;TITLE&#62; ... &#60;/TITLE&#62;
</pre>
Lexical details should be discussed elsewhere. The example is
good, but the mention of tags is out of place.

16. What does this mean?
It should
[...]
ideally fit on one line.

17. Should the TITLE element be CDATA, RCDATA, or PCDATA?
If we want to be able to use Latin chars in the title,
it can't be CDATA. The only difference between RCDATA
and PCDATA (with no subelements allowed) is that comments
are recognized in PCDATA, whereas they are just regular
data in RCDATA.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/ISINDEX.html
18. The word "Format" connotes lexical details, which are discussed
elsewhere. I endorse the use of examples, but I'd like to keep
the model of
	SGML source ==parser==> ESIS ==WWW semantics==>formatted output
consistent. The WWW semantics processor doesn't deal with <>'s etc.
It just sees the presence of the ISINDEX element and acts accordingly.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/NEXTID.html
19. The status of each element should be noted consistently. e.g.
Mainstream	Consistently used by past, present, and future implementations.
Deprecated	In use and will be supported, but should be avoided. (XMP)
Obsolete	In use in some documents, but will not be supported. (NEXTID)
Proposed	Not yet in the DTD or widely supported (e.g. LINK)
Standard	Not yet widely supported, but will be (e.g. PRE)
Extra		It's legal to ignore these. (e.g. EM)

http://info.cern.ch/hypertext/WWW/MarkUp/Elements/LINK.html
20. How many of these are allowed? I could change
<!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID?)>
to
<!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK?)>
or
<!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK*)>
I don't know if the latter is legal SGML. I'd have to try
it out.

21. Link types are not well defined. The only reason to put
something in a public specification is so everybody can agree
on some semantics. If there are no semantics to agree on,
why include the TYPE attribute? (It's status is at best
"proposed" in my mind, though it's in the DTD.)

In http://info.cern.ch/hypertext/WWW/MarkUp/Headings.html
22. "(at least six)" -- how about exactly six? Though I've
seen a lot of style guides that frown on anything more than 4.

In http://info.cern.ch/hypertext/WWW/MarkUp/SGML.html
23. We should give at least one complete reference to the standard, i.e.

	ISO 8879:1986, Information Processing -- Text and
        Office Systems -- Standard Generalized Markup Language
                         (SGML)

24. In the Archive section, we could metion comp.text.sgml,
the SGMLs parser materials, and the ifi.uio.no archive.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html
25. All attribute values have to be quoted, including NAME.
The example is wrong.

26. The TYPE attribute hardly seems worth mentioning. In the DTD,
it's a NAME, not just any old string.

27. We should look at modeling anchors as HyTime linkends
and/or ilinks.

28. We should look at modeling the LINK element as a HyTime
construct as well.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/P.html
29. I don't like the use of "exact representation" here:
The exact representation of
this (indentation,  leading, etc)
is not defined here, and may be a
function of other tags, style sheets
etc.

A reader could be confused between the source representation
and the rendered format. The source representation certainly
is defined. I'd say the "rendered representation" or some such.

30. Where are P's allowed? In the DTD, they're allowed in:
HTML, BODY, ADDRESS, BLOCKQUOTE, PRE but not in HEAD, A,
CODE, SAMP, etc.

In http://info.cern.ch/hypertext/WWW/MarkUp/Lists.html
31. Ordered lists: Obsolete or Standard?

32. "The format is:" Here again, this is an example, but it's
hardly a specification of the format of a UL element.

33. What does this mean?
The opening list tag  must be immediately
followed by the first list element.

34. The important difference between UL, MENU, and DIR is not
how they are displayed, but their semantic meanings. A MENU
is a list of things to choose from. A DIR is a list of names
in a directory.

35. We could also make this semantic distinction between PRE,
XMP, and LISTING, were it not for the syntactic confusion
surrounding XMP and LISTING.

36. Get rid of this:
the closing tag must obviously match
the opening tag.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/PRE.html
37. Wording of the newline documentation:
Line boundaries within the text are
significant, except for one immediately
following or immediatly preceding
a tag.

I don't like saying "newlines are significant" or "not significant."
Something like "newline characters shall be rendered as line breaks..."
or "newlines shall be ignored by the renderer..." would be better.

38. Semantics of newlines in PRE. Given the current DTD, a newline
after the PRE start tag or before the PRE end tag is not reported
by an SGML parser.

I think I can cook up some magic SHORTREF declarations that will
cause the SGML parser to report the newlines (possibly as P tags).
[This would obviate the need for special newline processing code
in libHTML]

In any case, I'd suggest that ALL NEWLINES REPORTED BY THE SGML
PARSER IN THE PRE ELEMENT BE DISPLAYED AS LINE BREAKS. That only
leaves the issue of which newlines are reported, which is governed
by the SGML standard.

39. I don't like the way this is worded:
The &#60;p&#62; tag should not be used.
If found, it should be interpreted
as a single new line.

I'd suggest: "it should be displayed as a line break" to avoid treating
<P> as "\n" and interpreting "\n" in some strange way.

40. "... character character highlighing elements may be used."
Ack! I don't recommend this! Hmmm... maybe only the B, I, and U
elements. This certainly conflicts with the current DTD.

In http://info.cern.ch/hypertext/WWW/MarkUp/Highlighting.html
41. These have status "Extra"
Where not supported by implementations,
like all tags, these should be ignored.<p>

This should be a warning to providers that some information may
be lost on some browsers.

42. (Definition of these and reference
- Dan?)
They come from TeXinfo.

43. I left the TeXinfo @file element out. I don't remember why.
It might have been an oversight. Do we want it in there?

44. Examples (TBD) see complete.html in my stuff.

In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html#z41
45. The PLAINTEXT tag terminates the HTML entity. What
follows is not SGML. In stead, there's an HTTP convention
that what follows is a text/plain body.

46. "The text may contain any ISO Latin printable characters" --
this conflicts with the DTD. I think a design that treats Latin
characters as external data entities is cleaner than one that
treats them as text characters, but I'm willing to go the
other way.

47. "including the
tag opener, so long as it does not
contain the closing tag in full."
For Pete's sake, could we get this out of there once and for all?
Perhaps it deserves a historical note or something, but we can't
leave it in as part of the standard. I'm willing to support
unquoted attribute values, but not this.

48. "The <a  NAME="z22">XMP tag</a>..." Use the term "element". The
term "tag" doesn't include the content of the element.

In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
49. "Special characters are represented
by SGML entities"
They're represented by numeric character references.
The lt, gt, and amp entities are not in the DTD. They should
be supported for historical reasons, but they are obsolete.

In http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/HTML.html
50. I'd like to move the Abstract, Specification, and the reference to
"Text and Markup" up into
http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
That node would look like

<H1>HyperText Markup Language</H1>
<H3>Abstract</H3>...
<H2>Language Reference</H2>
	<A>Text and Markup</A>
	<A>The Elements</A>
	<A>Implementors' Guide</A>
<H2>Specification</H2>
	<A>the DTD</A>
<H2>Appendices</H2>
	<A>futures</A>
	<A>constraints</A>

and this node would become "Implementors' Guide", with
pointers to recommended, complete, tolerated, errors,
libHTML, and SGMLs.

In http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/html.dtd
51. include ISO Latin 1 character set in SGML declaration?

52. Put PLAINTEXT back in HTML element (fell out by mistake.)

53. LINK element?

54. Get rid of H5 and H6?

55. Get rid of link TYPE lement?

56. Document BLOCKQUOTE in Elements reference.

57. EXPIRES attribute on HEAD?

58. Get rid of NEXTID element?

59. Document URN, TITLE, METHODS attributes of A element.

60. Proposed Headers element (like a DL; for RFC822 message headers:
<HEADERS>
<dt>To<dd>connolly@convex.com
<dt>Subject<dd>HTML todo list
</HEADERS>)

61. List STYLE attribute?

62. XMP and LISTING: CDATA or RCDATA?

In http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html
63. Under "Parsing Content Into Data and Markup," improve the
explanation of the MIXED, ELEMENT, EMPTY, CDATA, and RCDATA content
types (PCDATA is the wrong term) and how it affects parsing.

64. Revise the section on the sample implementation, libHTML, and
supported.html.

In http://info.cern.ch/hypertext/WWW/Test/test.html
65. This node should be moved to the implementos' guide.

In http://info.cern.ch/hypertext/WWW/MarkUp/Future.html
66. Delete the reference to the perl script.

67. There are two references here to old versions of my spec.

68. Header: it's in there: HEAD

69. Highlighting: it's in there (get rid of HP1 etc. in Elements reference)

70. Fixed width with anchors: it's in there: PRE.

71. Entities: Latin chars are in there. What do we need bullets for?

72. Comments: the comment element is a bad idea. SGML comments are
documented and supported.

73. Link types: we should look at HyTime before we go much further
on this.


In the midaswww-1.0 browser: [by the way: I've fixed all these in my copy]

74. HREF's with quotes don't work

75. Unrecognized tags are treated as data, rather than ignored.

76. numeric character references and entity references aren't supported.

77. ETAGO doesn't end XMP, LISTING, PLAINTEXT unless it's the right
GI. (e.g. <XMP>foo</foo> blah : blah should not be in the XMP element.)

78. local: acess scheme is wierd. I suggest we go with ftp: and
local-file: to match MIME, and get rid of local: and file:


Well, that's all I can think of. Good night.

Dan

From timbl@www3.cern.ch  Tue Jan 12 09:24:48 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20613; Tue, 12 Jan 93 09:24:48 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15619; Tue, 12 Jan 1993 09:39:56 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00817; Tue, 12 Jan 93 09:39:27 +0100
Date: Tue, 12 Jan 93 09:39:27 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301120839.AA00817@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: new HTML spec, sample implementation 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date: Fri, 08 Jan 93 13:57:32 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>  

>  This question seems to confuse two things: the ISOlat1 entity
>  set, and the ISO Latin 1 character set. The first is mapping
>  of names to glyphs, and the second is a mapping from the numbers
>  128-255 to glyphs. I think they're in alphabetical order
>  by name, but not in order by the ISO Latin 1 character set.

I think we should specify ISO latin 1 as the base set.  I think that  
a lot of people in the nordic countries use it routinely and they
will go crazy if they have to use overload the crurly brackets again
as they have to with mail.

Therefore, we should allow those people who have 8-bit capability to
just stick in 8-bit codes.  Admitedly I thought the ISO world kept to
the codes 21-7E and A1-FE hex for G0 and G1 graphics sets, using the  
others for control sets (C0 and C1). Maybe ISO Lantin 1 has nothing  
to do with ISO 8 bit extensions. Sorry I can't quote ISO numbers.
But whatever is common usage, let us have an 8 bit set.

(Anybody illuminate us on this?  Anybody got the ISO Latin 1  
character set listing by number?)

Now for died in the wool 7-bit hackers, is it fair to requier them to  
remember numbers, or would it be nicer to allow them to put in
codes using entity names?  Some people would I am sure like the  
latter, but it is NOT important because we are aiming for wysiwyg  
editors and so would regard human-readable character names as a  
temporary thing anyway.


>  Here is the crux of the matter:
>  

>  >The communication between it and the text object would have to be  
defined in  

>  >terms of a particular character set
>  

>  And this character set is stated in the SGML declaration at
>  the top of html.dtd.

No - that is something different. In the top of the DTD is specified  
the reference base set for the DTD itself and SGML documents.
The interface between two software modules is something else and can  
be independent of that.

>  If we define HTML in terms of the
>  full ISO Latin 1 character set, then the parser can deal with
>  &ouml, and pass it to the text object as a data character, just
>  like an 'A' character. For X displays using iso8559 fonts, that's
>  cool.


Sorry, is iso8559  = Iso latin 1?  (I have no head for numbers >1 :-)

yes it is cool. Use Midas or Viola to look at the Hyper-G stuff and  
it works very nicely.

>  But on a PC or a Mac, that means the text object will have to
>  scan all the data it gets and convert the Latin1 encoding to
>  it's own. Yuck.

Yup. Big deal?  Not really. Just a set of parallel tables.  Peter  
Flynn of the CURIA project is producing a lot of archived gaelic and  
is currently dealing with a requirement for a line-mode browser which  
can switch its characetr set depending on the terminal emulator the  
reader is using.

Problems only occur if there are characters which can't be mapped 1-1  
to the local set, and must be represented by more than one character  
(like uumlaut -> ue, ae dipthong -> ae etc) AND you can edit, in  
which case the original form must be preserved. In this case, passing  
on of the entity is essential.  But doing it for every character >127  
would be a pain memorywise. So I would suggest that a configuable  
table define which entities can be crunched down to a single  
character in the local representation and the rest be passed on from  
the SGML parser to the SGML app as external entities.

>  >... and perhaps if there is more than one  

>  >contender the SGML engine could have a compilation option.
>  

>  Hmmm... One might argue that as long as we support conversion  
inside
>  the SGML parser for EBCDIC machines, we might as well support PC  
and
>  Mac character sets while we're at it.

Yes.

Tim

From timbl@www3.cern.ch  Tue Jan 12 11:27:46 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21083; Tue, 12 Jan 93 11:27:46 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29889; Tue, 12 Jan 1993 11:42:53 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00938; Tue, 12 Jan 93 11:42:24 +0100
Date: Tue, 12 Jan 93 11:42:24 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301121042.AA00938@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: new HTML spec, sample implementation 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> The "Hypertext Markup Language" document I wrote was supposed
> to replace the root of the HTML documentation. I suggest we
> merge them. I'll work on it and let you know what I come
> up with.

There is of course nothing wrong with having two roots -- one as a  
specification and one as a user guide.   The specification should be  
more formal and use the correct terminology without apology, the  
burden of understanding being on the reader.  The user guide must  
start with the vocabulary expected of the new reader, and introduce  
things in an "easy" order. The onus of explanation is on the writer  
of the guide in this case, as we WANT people to write/output HTML.

Ideally of couse one would rewrite the whole thing but we haven't  
time, so the details about each element had best be represented just  
once.

I think we need a version of www which runs off RFCxxx-conforming  
RFCs, unless someone can do it with TeX.  Then we can feed it a  
stream of concatenated HTML.  We will need it for HTTP2 too.

Tim

From K.Hoadley@directory.rl.ac.uk  Tue Jan 12 12:00:56 1993
Return-Path: <K.Hoadley@directory.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21272; Tue, 12 Jan 93 12:00:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03266; Tue, 12 Jan 1993 12:16:04 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
          id <10563-0@directory.rl.ac.uk>; Tue, 12 Jan 1993 11:01:08 +0000
Date: Mon, 11 Jan 1993 16:27:37 +0000 (GMT)
From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
Sender: K.Hoadley@directory.rl.ac.uk
Reply-To: K.Hoadley@directory.rl.ac.uk
Subject: RE: Re HTTP2: caching and copyright
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Dave_Raggett's message of Mon, 11 Jan 93 15:42:41 GMT: <9301111542.AA23888@manuel.hpl.hp.com>
Message-Id: <Ximap.726837388.7590.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

>>> Note that servers shouln't cache documents with restricted readership since
>>> each server don't know the restrictions to apply. This requires a further
>>> header to identify such documents as being unsuitable for general caching:
>>>
>>>     Distribution: restricted | unrestricted

     There are a number of reasons why it might not be sensible
   to cache a document, eg in my local server I have a page 
   entitled "Current state of the network". This is a smart doc,
   refreshed everytime it is accessed. Caching this is just plain 
   silly. Thus a general mechanism (separate from access restrictions)
   is needed to prevent caching where it is unsuitable.
     Given that a general mechanism is also needed for cache timeouts,
   it seems sensilble to amalgamate the two, ie documents that should
   not be cached simply have their cache timeouts (TTL's) set to zero.
     Note that within the PROTOCOL, cache timing information should
   not be embedded within documents, for the simple reason that in the
   future such information will be needed for non-text bodyparts,
   ie my network status page might become a graphic, but it still
   should not be cached. Note that this does not stop any server
   IMPLEMENTATION from reading caching info embedded into in HTML,
   merely that the protocol (the bits on the wire) should be able to
   seperate the two.
 
>It would be nice in some circumstances to define the readership groups for
>situations where a server could apply group membership information to
>restrict readership.
...
>This says that the document can be given to anyone in psl and anyone in the
>kbpd subgroup of incl. You can make these names correspond to your
>organisation. The maintenance of these readership groups is outside 
>the scope of the HTTP2 protocol. 
>Local servers shouldn't cache documents including this
>header unless they "understand" the specified readership groups 
>and can apply the same membership tests.

       How does a server know if it "understands" readership groups ?
     How do I know if my Dave Raggett is the same as your Dave Raggett ?
     This information cannot be passed between servers; we would need
     a global naming scheme - X.500 distinguished names won't do
     as X.500 is not commonly enough used, e-mail addresses probably
     aren't good enough (at a quick count I can be reached through
     about 20 addresses at 4 institutes in 2 countries, does this
     mean that my membership or otherwise of a readership group
     depends on where I am logged on ?). We would also need a global
     authentication scheme ...
       This comes back to the idea that the only documents that should
     be cached are those whose read access is totally unlimited. Any
     other form of read access (ie, billed access to private data,
     logged access, restricted access) should require talking to
     the original server, not to some cached copy.

Kevin Hoadley

From timbl@www3.cern.ch  Tue Jan 12 15:21:17 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22511; Tue, 12 Jan 93 15:21:17 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25937; Tue, 12 Jan 1993 15:36:25 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01111; Tue, 12 Jan 93 15:35:57 +0100
Date: Tue, 12 Jan 93 15:35:57 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301121435.AA01111@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: WWW Workshop -- Call for interest?
Reply-To: timbl@nxoc01.cern.ch



We are considering holding a three-day workshop on the World-Wide Web
at CERN (Geneva, Switzerland) on or close to Wednesday 7th to Friday  
9th July 1993.   (The IETF meeting in Amsterdam, that starts on  
Monday 12th July).

The workshop would probably have three sections

1.	Tutorial sessions on what WWW is, how it works, and (mainly)
	how you set up clients and servers.  This would be for
	users who nood not know anything of WWW but should be
	computer litterate.
	
2.	Presentations by those who have already used the web in
	various different ways, with their findings and comments.
	
3.	A technical brainstorming (RFC editing?) session on
	protocols and data formats (HTTP and HTML).
	
The idea would be that people would not have to come for all of it:  
experienced WWWWizards could come on section (day?) 2, and users not  
interested in future development would leave after day 2.

	Anyone interested? 

	Suggestions?
	Would you come?
	Would you prefer another date
	-- are there things clashing with that date?

When replying, (to me, not to the list) if I don't know you please  
indicate whether you and your institute are involved in physics,  
software, networking, etc.

Thanks
	Tim BL

From timbl@www3.cern.ch  Tue Jan 12 18:14:18 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24077; Tue, 12 Jan 93 18:14:18 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15134; Tue, 12 Jan 1993 18:29:27 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01295; Tue, 12 Jan 93 18:28:58 +0100
Date: Tue, 12 Jan 93 18:28:58 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301121728.AA01295@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: HTML todo list
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Mon, 11 Jan 93 22:36:43 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>  

...
>  1. My dictionary lists "markup" as a word, not mark-up.

Done.

>  In http://info.cern.ch/hypertext/WWW/Daemon/Bugs.html
>  2. The PLAINTEXT situation should be logged as a bug against
>  the server. PLAINTEXT is deprecated.

Done.  There are many other servers like that. We cannot really
force them to convert to XMP when HTTP2 is round the corner.
I shall fix the basic server anyway.

>  In http://info.cern.ch/hypertext/WWW/FAQ/List.html
>  4. HTML should support QUESTION and RESPONSE elements to
>  support converting USENET FAQ's to HTML

Not sure about that one. Ther are several ways of mapping FAQs onto  
HTML as it is ... I would prefer to see for example a MENU of  
questions, each linked to the answer in a separate document which had  
its question as for example a H1 heading and TITLE.

>  In http://info.cern.ch/hypertext/WWW/Provider/ShellScript.html
>  5. PLAINTEXT is deprecated. Use PRE, and use a sed script
>  to change < to &#60, > to &#62, and & to &#38.

Fixed. I have put in a sed script txt2html to do the conversion.

>  6.  
http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/dir2html.txt
>  This thing doesn't quote attributes; it uses XMP in stead of
>  PRE with numeric character references.

Fixed.

>  7.  
http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/ls2html.awk.txt 

>  Quotes around HREFS, PLAINTEXT.
Fixed. No PLAINTEXT in this one, Quotes inserted.

>  8.  
http://info.cern.ch/hypertext/WWW/Daemon/Implementation/asis.txt

I have put comments in the source but not fixed it.

>  

>  9. http://info.cern.ch/hypertext/WWW/HytelnetGate/src/htn2html.c
>  Uses HEADER in stead of HEAD.
Fixed
>  Quote HREFs.
Already done as far as I could find
>  Special character entities?
>  Yeah! It uses numeric character references already!
No -- it used named entities.  I'll leave it
>  In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
>  10. Mark-up again
Fixed.
>  11. This text seems out of place:[...]
Agreed  

>  12. Default text: this node seems to confuse lots of issues. I  
suggest
>  we get rid of it. The way to look at HTML is as a stream of data  
and
>  markup. Newlines are handled differently all over the place. It  
might
>  be reasonable to talk about how newlines are handled by the text
>  formatter, after they have been handed over from the SGML parser.


People writing SGML don't want to know about parser and formatters  
(an arbitray distinction which is very questionable in the definition  
of a DTD or SGML -- it is only relevant to the definition of the  
software interface to an SGML engine)

>  In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
>  13. This text is out of place: 

>  Each tag starts
>  with a tag opener (a less than sign)
>  and ends with a tag closer (a greater
>  than sign).   Many tags have corresponding
>  closing tags which identical except
>  for a slash after the tag opener.


Take this as an informal intro not a spec.
Let's keep the spec in parallel.

>  It's more thoroughly >  In  
http://info.cern.ch/hypertext/WWW/MarkUp/Elements/HEAD.html
>  14. These blurbs should probably quote their element declarations
>  from the DTD, in order to help folks learn to read the DTD.

Yes. And the DTD should be in PRE with links back to the blurbs.
I have started a //info.cern.ch/hypertext/WWW/MarkUp/HTML.dtd.html

....
That's where I got to

Tim


From fine@cis.ohio-state.edu  Tue Jan 12 19:02:33 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24650; Tue, 12 Jan 93 19:02:33 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20589; Tue, 12 Jan 1993 19:17:39 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA12386; Tue, 12 Jan 93 13:17:30 -0500
Date: Tue, 12 Jan 93 13:17:30 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301121817.AA12386@soccer.cis.ohio-state.edu>
To: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: WWW Workshop -- Call for interest?
X-Mailer: Perl Mail System v1.1

In a similar vein, we should probably plan some sort of get-together (a BOF
maybe) for everyone who's going to the winter USENIX conference.  If
everyone who's going to be there could send me mail I could get an idea of
how many people that will be.

	  tom

From connolly@pixel.convex.com  Tue Jan 12 19:47:05 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25080; Tue, 12 Jan 93 19:47:05 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28680; Tue, 12 Jan 1993 20:02:11 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA04062; Tue, 12 Jan 93 13:01:55 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA15286; Tue, 12 Jan 93 13:01:53 -0600
Message-Id: <9301121901.AA15286@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML todo list 
In-Reply-To: Your message of "Tue, 12 Jan 93 18:28:58 +0100."
             <9301121728.AA01295@www3.cern.ch> 
Date: Tue, 12 Jan 93 13:01:52 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>  In http://info.cern.ch/hypertext/WWW/FAQ/List.html
>>  4. HTML should support QUESTION and RESPONSE elements to
>>  support converting USENET FAQ's to HTML
>
>Not sure about that one. Ther are several ways of mapping FAQs onto  
>HTML as it is ... I would prefer to see for example a MENU of  
>questions, each linked to the answer in a separate document which had  
>its question as for example a H1 heading and TITLE.

Well then maybe the USENET FAQ project needs a separate DTD. I'm
willing to table the issue for now.

>>  Special character entities?
>>  Yeah! It uses numeric character references already!
>No -- it used named entities.  I'll leave it

So lt, gt, and amp are "Deprecated" rather than "Obsolete", that
is, they are not recommended, but they will be supported. In that
case, we should update the DTD to include them.


>>  12. Default text: this node seems to confuse lots of issues. I  
>suggest
>>  we get rid of it. The way to look at HTML is as a stream of data  
>and
>>  markup. Newlines are handled differently all over the place. It  
>might
>>  be reasonable to talk about how newlines are handled by the text
>>  formatter, after they have been handed over from the SGML parser.
>
>
>People writing SGML don't want to know about parser and formatters  
>(an arbitray distinction which is very questionable in the definition  
>of a DTD or SGML -- it is only relevant to the definition of the  
>software interface to an SGML engine)

The distinction between parsers and formatters (i.e. applications)
is very much defined by SGML: a conforming application is not allowed
to act on anything but the ESIS. For example, it's illegal to
treat attribute values delimited by single quotes differently from
those surrounded by double quotes, because that information is
not reported by the parser. The same is true for newlines: it's
illegal to treat
<foo>
content
</foo>
different from <foo>content</foo> because the difference is
not reported by the parser (unless we do some shortref magic
to force the parser to report the difference.)

In any case, I think "people writing SGML" is the group for
whom an understanding of these issues is most critical.
They should be referred to the implementors' guide. This
business of "default text" or "Character Data" is thoroughly
discussed in "Text and Markup" under "Parsing content into
data and markup" and in "Recommended Usage" under "Body elements."

I wrote the "Text and Markup" node to replace this "Default Text"
or "Character Data" node, and I still think the node does
more harm than good.


>>  In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
>>  13. This text is out of place: 
>
>>  Each tag starts
>>  with a tag opener (a less than sign)
>>  and ends with a tag closer (a greater
>>  than sign).   Many tags have corresponding
>>  closing tags which identical except
>>  for a slash after the tag opener.
>
>
>Take this as an informal intro not a spec.
>Let's keep the spec in parallel.

I took great pains to make "Text and Markup" an
accessible yet correct intro to SGML syntax. I'd like
to see folks referred to that document for these issues.
If it's not readable, let's fix it.

We must be very careful
of two things: 1. that these redundant informal blurbs
do not in any way conflict with the SGML standard,
and 2. that they are not misleading.

This blurb mostly passes criteria 1: all tags do
indeed start with a less than sign (and I guess
"tag opener" is close enough to "start tag open delimiter"
though "... which is identical except for a slash after
the tag opener" is goofy. </, the end tag open delimiter,
is not viewed as a start tag open delimiter followed by
a slash.)

But not all less than signs indicate tags: a less than
sign is only recognized as STAGO when it's followed by
a letter.  And most A end tags are hardly identical
to their start tag, even modulo the slash. The case
of the start tag can be different from the case of the
end tag. I fear that folks will read this blurb and
write broken sed scripts.

Certainly there should be a link from this blurb to
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html#Tags

>  In  
>http://info.cern.ch/hypertext/WWW/MarkUp/Elements/HEAD.html
>>  14. These blurbs should probably quote their element declarations
>>  from the DTD, in order to help folks learn to read the DTD.
>
>Yes. And the DTD should be in PRE with links back to the blurbs.
>I have started a //info.cern.ch/hypertext/WWW/MarkUp/HTML.dtd.html

Excellent idea. But again, there are maintenance issues we must
sort out.

>That's where I got to

I certainly appreciate the speedy response, and the notes
of encouragement I got from a few others.

I am much more confident that this will all be resolved soon.

Dan


From fine@cis.ohio-state.edu  Tue Jan 12 22:27:51 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26683; Tue, 12 Jan 93 22:27:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03583; Tue, 12 Jan 1993 22:42:59 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13427; Tue, 12 Jan 93 16:42:55 -0500
Date: Tue, 12 Jan 93 16:42:55 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301122142.AA13427@soccer.cis.ohio-state.edu>
To: connolly@pixel.convex.com, timbl@nxoc01.cern.ch
Subject: Re: HTML todo list 
Cc: www-talk@nxoc01.cern.ch
X-Mailer: Perl Mail System v1.1

>
>>>  In http://info.cern.ch/hypertext/WWW/FAQ/List.html
>>>  4. HTML should support QUESTION and RESPONSE elements to
>>>  support converting USENET FAQ's to HTML
>>
>>Not sure about that one. Ther are several ways of mapping FAQs onto  
>>HTML as it is ... I would prefer to see for example a MENU of  
>>questions, each linked to the answer in a separate document which had  
>>its question as for example a H1 heading and TITLE.
>
>Well then maybe the USENET FAQ project needs a separate DTD. I'm
>willing to table the issue for now.

I'm perfectly happy using existing HTML to format the FAQs.  I wrote perl
scripts that convert the comp.unix.questions and comp.lang.perl FAQs
into hypertext.  They were done just as a proof of concept, go get an
idea of what it would look like.  They are available at
"http://www.cis.ohio-state.edu:80/hypertext/information/information.html"

(This address is subject to change)

I'd also like to express the opinion that we shouldn't make the HTML so
terribly specific.  Every new situation shouldn't require another addition
to HTML.  If that were the case, we'd never be finished.

>[...] The same is true for newlines: it's
>illegal to treat
><foo>
>content
></foo>
>different from <foo>content</foo> because the difference is
>not reported by the parser (unless we do some shortref magic
>to force the parser to report the difference.)

I don't think we should do any shortref magic.  The simplest thing
(the way it works now) is that the two examples above are identical.
I say this is fine.  If someone wants to stick a new-line in at the
beginning of some section, they can just stick it in there:

<foo>

content
</foo>

           tom

From connolly@pixel.convex.com  Tue Jan 12 23:10:06 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26846; Tue, 12 Jan 93 23:10:06 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09740; Tue, 12 Jan 1993 23:25:13 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA13978; Tue, 12 Jan 93 16:25:09 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA02411; Tue, 12 Jan 93 16:25:08 -0600
Message-Id: <9301122225.AA02411@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: HTML todo list 
In-Reply-To: Your message of "Tue, 12 Jan 93 16:42:55 EST."
             <9301122142.AA13427@soccer.cis.ohio-state.edu> 
Date: Tue, 12 Jan 93 16:25:07 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I'd also like to express the opinion that we shouldn't make the HTML so
>terribly specific.  Every new situation shouldn't require another addition
>to HTML.  If that were the case, we'd never be finished.

Well, suffice it to say that HTML doesn't give much semantic
information. It would be nice to express relationships between
pieces of information through the document structure, but in
HTML we mostly use links.

>>[...] The same is true for newlines: it's
>>illegal to treat
>><foo>
>>content
>></foo>
>>different from <foo>content</foo> because the difference is
>>not reported by the parser (unless we do some shortref magic
>>to force the parser to report the difference.)
>
>I don't think we should do any shortref magic.  The simplest thing
>(the way it works now) is that the two examples above are identical.
>I say this is fine.

But it's a royal pain to implement! Doing full SGML newline processing
by the standard is quite involved (see the article by Eric Naggum
in comp.text.sgml about SGML and Records that I referenced in
an earlier message). For example, you can't just get rid of all
newlines immediately before or after tags, like it says in the
web: Only those right after a start tag (of a non-empty element),
right before an end tag,
or the ones on a line containing only comments and processing instructions.
Newlines around <P> tags, for example, _are_ reported.

If we don't stick the SHORTREF magic in the DTD to force the
parser to report all newlines, we'll end up with countless hacks
at newline processing, none of which matches the standard, and
it'll be luck if any of them matches each other.

Dan


From fine@cis.ohio-state.edu  Tue Jan 12 23:36:39 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27044; Tue, 12 Jan 93 23:36:39 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13287; Tue, 12 Jan 1993 23:51:47 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13895; Tue, 12 Jan 93 17:51:29 -0500
Date: Tue, 12 Jan 93 17:51:29 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301122251.AA13895@soccer.cis.ohio-state.edu>
To: connolly@pixel.convex.com, @cis.ohio-state.edu@cis.ohio-state.edu
Subject: Re: HTML todo list 
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
X-Mailer: Perl Mail System v1.1

>>I don't think we should do any shortref magic.  The simplest thing
>>(the way it works now) is that the two examples above are identical.
>>I say this is fine.
>
>But it's a royal pain to implement! Doing full SGML newline processing
>by the standard is quite involved (see the article by Eric Naggum
>in comp.text.sgml about SGML and Records that I referenced in
>an earlier message). For example, you can't just get rid of all
>newlines immediately before or after tags, like it says in the
>web: Only those right after a start tag (of a non-empty element),
>right before an end tag,
>or the ones on a line containing only comments and processing instructions.
>Newlines around <P> tags, for example, _are_ reported.
>
>If we don't stick the SHORTREF magic in the DTD to force the
>parser to report all newlines, we'll end up with countless hacks
>at newline processing, none of which matches the standard, and
>it'll be luck if any of them matches each other.

Not necessarily.  Carefully define which new-lines have to be ignored.
This may yield something complex.  But then, you are still free to ignore
more new-lines than that in several different places, thus reducing the
problem.  In other words, it is up to the formatting program to decide
how to interpret them.  If it decides to throw out a few more new-lines
at the beginning or end of various data elements, life becomes much
easier.

You might have countless hacks, but since formatters ar allowed to
format things differently, does it matter?

Take this example:

  Here's some text<P>And some more text
  <P>
  And some final text.

SGML may say this:

  \nHere's some text
  (P
  )P
  And some more text\n
  (P
  )P
  \nAnd some final text.

But the formatter is still free to toss those new-lines at the beginning
and end of each paragraph (and in fact it had better if you don't want
a space at the beginning of your paragraphs).

	 tom

From timbl@www3.cern.ch  Wed Jan 13 11:38:51 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00890; Wed, 13 Jan 93 11:38:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07261; Wed, 13 Jan 1993 11:54:00 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01794; Wed, 13 Jan 93 11:53:30 +0100
Date: Wed, 13 Jan 93 11:53:30 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301131053.AA01794@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: KEEP UP THE GOOD WORK DAN
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



If people seem to be leaving it to you then that is becuase you are  
doing a good job.  I for one very much appraeciate it!  I have left  
you completeley with editorship of the document I know.  I will take  
it back again if you like.  Things will be so much easier when we  
have a checkin/checkout function.

I think that everyone agrees that SGML conformance is very important,  
but there are not many who are into it SGML to tangle with it in the  
way you can.

(I know I should get sgmls up, but I haven;t even brought up half the  
new browsers which have appeared, and I have to support a CERN user  
community of real users and service providers.  So free time is  
nonexistent (having a little family may have something to do with  
that too...). And there is HTTP2 which needs trial implementation as  
well.

We get a student (Arthur Secret is coming back) in March which should  
help.

From timbl@www3.cern.ch  Wed Jan 13 12:08:11 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01124; Wed, 13 Jan 93 12:08:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10686; Wed, 13 Jan 1993 12:23:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01827; Wed, 13 Jan 93 12:22:50 +0100
Date: Wed, 13 Jan 93 12:22:50 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301131122.AA01827@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Steve Romig <romig@cis.ohio-state.edu>
Subject: Re: Man pages server code, anyone?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



I think it would be useful to have the man pages code available.
Steve, could you put it up for FTP or tar it up and put it in 

/pub/incoming on info.cern.ch, please?

Any other contributions to man page fromatting would be welcome too.
By the way, your mail address would be a good addition to
http://www.cis.ohio-state.edu:80/hypertext/people/steve_romig.html

Tim

From rik@daneel.rdt.monash.edu.au  Wed Jan 13 12:29:00 1993
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01233; Wed, 13 Jan 93 12:29:00 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13234; Wed, 13 Jan 1993 12:44:06 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA01551; Wed, 13 Jan 93 22:43:54 +1100
Message-Id: <9301131143.AA01551@daneel.rdt.monash.edu.au>
To: www-talk@nxoc01.cern.ch
Subject: Re: Man pages server code, anyone? 
In-Reply-To: Your message of "13 Jan 93 12:22:50 +0100."
             <9301131122.AA01827@www3.cern.ch> 
Date: Wed, 13 Jan 93 22:43:54 +1100
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

> I think it would be useful to have the man pages code available.
> Steve, could you put it up for FTP or tar it up and put it in 
> 
> /pub/incoming on info.cern.ch, please?
> 
> Any other contributions to man page fromatting would be welcome too.

I haven't released my code yet, as I'm still trying to figure out what
the changes to the spec mean to me :-)

I can post what I have at the moment, but it doesn't take advantage of
the new TeXinfo stuff.

rik.
--
rik harris (rik@rdt) Faculty of Computing and Information Technology (x75 3227)

From romig@cis.ohio-state.edu  Wed Jan 13 14:41:22 1993
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01928; Wed, 13 Jan 93 14:41:22 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29076; Wed, 13 Jan 1993 14:56:32 +0100
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA10028; Wed, 13 Jan 93 08:56:26 -0500
Date: Wed, 13 Jan 93 08:56:26 -0500
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9301131356.AA10028@brachiosaur.cis.ohio-state.edu>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Tim Berners-Lee's message of Wed, 13 Jan 93 12:22:50 +0100 <9301131122.AA01827@www3.cern.ch>
Subject: Man pages server code, anyone?

I've been working on cleaning things up - there were some nasty bugs,
and I still need to check things to make sure that they are up to
date.  Tom keeps telling me to take out the newlines around the <p>'s
in <pre>'s, put them back, remove the <p>'s, remove them both, put
them both back...:-)

I'll make it all available for ftp later this week or early next.  

--- Steve

From fine@cis.ohio-state.edu  Wed Jan 13 21:01:19 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06098; Wed, 13 Jan 93 21:01:19 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17562; Wed, 13 Jan 1993 21:16:29 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA21656; Wed, 13 Jan 93 15:16:26 -0500
Date: Wed, 13 Jan 93 15:16:26 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301132016.AA21656@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: strategy for HTML spec?
X-Mailer: Perl Mail System v1.1

>[begin bitching and moaning...]
>
>Also, I am frustrated that noone else seems willing to look
>closely at SGML at all. The SGMLs parser makes it easy to
>try stuff out, and comp.text.sgml is a great place to learn
>a lot of stuff, but none of the other implementors have
>bothered to try them out.

[begin excuses]
Unfortunately, My job only permits me a couple of hours a day on this
project, and that includes coming up with local documentation.
[end excuses]

But you're right.

I personally believe this is one of the most important projects going
on on the internet right now.  I think you're doing a wonderful job,
getting things right, dealing with everybody's (like mine) annoying
criticism, etc.  But your doing this thing right, and I like it.

So how about a constructive idea?  I won't be able to implement this
until three weeks from now since I'm bouncing to two different
conferences for the next two weeks, but:

I could easily write a robot which would roam around the Web (perhaps
stochastically?), and verify the html, using sgmls.  Then, whenever
I come across something that's non-compliant, I could automatically
send mail to wwwmaster@sitename.  No one would have to annoy anyone else
about whether or not they've verified their HTML; a program would annoy
them automatically.

All we have to do is agree to set up the wwwmaster aliases.  (In the
event of bounce-o-grams, we could always annoy the postmaster, or
failing that, root.)

This would also be a good chance to map out the entire Web.  Anyone
know any good algorithms for drawing arbitrary directed graphs with
no overlap?  Which reminds me, a good directed graph is the right way
to implement a history mechanism.  Somebody want to take a crack at
it?

	  tom

From connolly@pixel.convex.com  Wed Jan 13 21:19:37 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06323; Wed, 13 Jan 93 21:19:37 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19754; Wed, 13 Jan 1993 21:34:46 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA04782; Wed, 13 Jan 93 14:34:42 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA01693; Wed, 13 Jan 93 14:34:40 -0600
Message-Id: <9301132034.AA01693@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: strategy for HTML spec? 
In-Reply-To: Your message of "Wed, 13 Jan 93 15:13:58 EST."
             <9301132013.AA21635@soccer.cis.ohio-state.edu> 
Date: Wed, 13 Jan 93 14:34:40 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I could easily write a robot which would roam around the Web (perhaps
>stochastically?), and verify the html, using sgmls.  Then, whenever
>I come across something that's non-compliant, I could automatically
>send mail to wwwmaster@sitename.  No one would have to annoy anyone else
>about whether or not they've verified their HTML; a program would annoy
>them automatically.

Sounds cool. This points out yet another thing the WAIS folks did
right: every database has an associated maintainer as part of
the protocol. WWW could learn a lot from WAIS.

>All we have to do is agree to set up the wwwmaster aliases.  (In the
>event of bounce-o-grams, we could always annoy the postmaster, or
>failing that, root.)

Perhaps HTML2 will provide a handle on how to get ahold of the relavent
person -- it should!

>This would also be a good chance to map out the entire Web.  Anyone
>know any good algorithms for drawing arbitrary directed graphs with
>no overlap?

Ever heard of map coloring problems? You can't draw an arbitrary
directed graph with no overlap. The set of graphs that you can
draw is the subject of great study, I believe. They're called
"planar" graphs.


>  Which reminds me, a good directed graph is the right way
>to implement a history mechanism.  Somebody want to take a crack at
>it?

This is another area where the HyTime folks have done a lot
of thinking that we should try to take advantage of.

Dan


From guido@cwi.nl  Wed Jan 13 23:35:16 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07515; Wed, 13 Jan 93 23:35:16 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04513; Wed, 13 Jan 1993 23:50:26 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA16003 (5.65b/3.6/CWI-Amsterdam); Wed, 13 Jan 1993 23:50:25 +0100
Received: by voorn.cwi.nl with SMTP
	id AA14654 (5.65b/3.5/CWI-Amsterdam); Wed, 13 Jan 1993 23:50:24 +0100
Message-Id: <9301132250.AA14654.guido@voorn.cwi.nl>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: strategy for HTML spec? 
In-Reply-To: Your message of "Wed, 13 Jan 1993 15:16:26 MET."
             <9301132016.AA21656@soccer.cis.ohio-state.edu> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Wed, 13 Jan 1993 23:50:24 +0100
Sender: Guido.van.Rossum@cwi.nl

>I could easily write a robot which would roam around the Web (perhaps
>stochastically?), and verify the html, using sgmls.  Then, whenever
>I come across something that's non-compliant, I could automatically
>send mail to wwwmaster@sitename.  No one would have to annoy anyone else
>about whether or not they've verified their HTML; a program would annoy
>them automatically.

I have written a robot that does this, except it doesn't check for
valid SGML -- it just tries to map out the entire web.  I believe I
found roughly 50 or 60 different sites (this was maybe 2 months ago --
I'm sorry, I didn't save the output).  It took the robot about half a
day (a saturday morning) to complete.

There were several problems.

First, some sites were down and my robot would spend a considerable
time waiting for the connection to time out each time it found a link
to such a site.  I ended up remembering the last error from a site and
skipping sites that were obviously down, but there are many different
errors you can get, depending on whether the host is down,
unreachable, doesn't run a WWW server, doesn't recognize the document
address you want, or has some other trouble (some sites were going up
and down while my robot was running, causing additional confusion).

Next, more importantly, some sites have an infinite number of
documents.  There are several causes for this.

First, several sites have gateways to the entire VMS documentation (I
have never used VMS but apparently the VMS help system is a kind of
hypertext).  While not exactly infinite the number of nodes is *very*
large.  Luckily such gateways are easily recognized by the kind of
pathname they use, and VMS help is unlikely to contain pointers to
anything except more VMS help, so I put in a simple trap to stop
these.

Next, there are other gateways.  I can't remember whether I
encountered a Gopher or WAIS gateway, but these would have even worse
problems.

Finally, some servers contain bugs that cause loops, by referencing to
the same document with an ever-growing path.  (The relative path
resolving rules are tricky, and I was using my own www client which
isn't derived from Tim's, which made this more severe, but I have also
found occurrences reproducible  with the CERN www client.)

Although I didn't specifically test for bad HTML, I did have to parse
the HTML to find the links, and found occasional errors.  I believe
there are a few binaries, PostScript and WP files that have links to
them, which take forever to fetch.  There were also various
occurrences of broken addresses here and there -- this was a good
occasion for me to debug my www client library.

If people are interested, I could run the robot again and report a
summary of the results.

I also ran a gopher robot, but after 1600 sites I gave up...  The
Veronica project in the Gopher world does the same and makes the
results available as a database, although the last time I tried it the
veronica server seemed too overloaded to respond to a simple query.

If you want source for the robots, the're part of the Python source
distribution: ftp to ftp.cwi.nl, directory, pub/python, file
python0.9.8.tar.Z.  The robot (and in fact my entire www and gopher
client library) is in the tar archive in directory python/demo/www.
The texinfo to html conversion program that I once advertized here is
also there.  (I'm sorry, you'll have to built the python interpreter
from the source before any of these programs can be used...)
Note that my www library isn't up with the latest HTML specs, this is
a hobby project and I neede my time for other things...

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From connolly@pixel.convex.com  Thu Jan 14 01:56:19 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08306; Thu, 14 Jan 93 01:56:19 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18151; Thu, 14 Jan 1993 02:11:29 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA17773; Wed, 13 Jan 93 19:11:17 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA21994; Wed, 13 Jan 93 19:11:15 -0600
Message-Id: <9301140111.AA21994@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: suggested libWWW architecture
Date: Wed, 13 Jan 93 19:11:15 CST
From: Dan Connolly <connolly@pixel.convex.com>


I sent this to tim a while ago, but I don't think
he's had time to look at it.

Meanwhile, libWWW is becomming reentrant, but I still
think the architecture is kinda clumsy: you have to
have a big data structure describing the DTD, and
a routine for each element, etc.

This doesn't mesh well with the MidasWWW architecture, which
can read the DTD from the X resource database at
runtime.

I have an idea for an architecture that the linemode and
MidasWWW could share (along with other new implementations).

It's not radically different from the current libWWW, but
there's a lot of grunt-work between the current libWWW
and what I've got here. But I think the end result would
be much more usable.

We start with the HText class. In stead of the various
style and append methods, we have four methods in a
virtual function table:

typedef struct{
  int (*start_tag) PARAMS((SGML_Object this, CONST char* gi,
			    CONST char** attributes, int nattrs));
  VOID (*end_tag) PARAMS((SGML_Object this, CONST char* gi));

  VOID (*entity) PARAMS((SGML_Object this, CONST char* name));

  VOID (*data) PARAMS((SGML_Object this, CONST char* data, int char_qty));
}SGML_DocClass;

The linemode would declare something like:

SGML_DocClass griddoc = {HText_start_tag, HText_end_tag,
			HText_entity, HText_data};

The HText implementation is responsible for keeping track of
the stack of open elements, if it needs to.

On top of these we build some format parsing routines:

SGML_parse(void* dest, void* closure, void* stream, int (getc)(void*));
/* psuedocode:
   int read, content;
   char buffer[1000];
   SGML_DocClass *docclass = (SGML_DocClass*)closure;

   while( (read = SGML_read(buffer, content, stream, getc)) != EOF){
     switch(read){
       case SGML_start_tag:
         ... parse name, attributes ...
         content = (docclass->startTag)(dest, name, attrs);
         if(content = empty){
           (docclass->endTag)(name);
           content = MIXED; /*@@ could be ELEMENT */
         }
         break;

       case SGML_end_tag:
         ... parse name ...
         (docclass->endTag)(name);
         content = MIXED; /*@@ could be ELEMENT */
         break;

       case SGML_entity:
         (docclass->entity)(data, name);
         break;

       default:
         (docclass->data)(dest, buffer);
    }
*/

PlainText_parse(HText* dest, void* docclass, void* stream, int (getc)(void*));
/* psuedocode:
   (docclass->startTag)(dest, "HTML");
   (docclass->startTag)(dest, "BODY");
   (docclass->startTag)(dest, "PRE");
   keep a local buffer of about 1000 chars.
   Call (getc)(stream) until EOF.
   Call HText_data(dest, buffer) whenever buffer is full.
   (docclass->endTag)(dest, "PRE");
   (docclass->endTag)(dest, "BODY");
   (docclass->endTag)(dest, "HTML");
*/

GopherListing_parse(HText* dest, void* dummy, void* stream, int (getc)(void*));
/* psuedocode:
   (docclass->startTag)(dest, "HTML");
   (docclass->startTag)(dest, "BODY");
   (docclass->startTag)(dest, "MENU");
   while(Gopher_parse_line(stream, getc, type, name, host, port, path)){
      char addr[BIG];
      sprintf(addr, "gopher://%s:%d/%c%s", host, port, type, path);
      (docclass->startTag)(dest, "A",
                       "HREF", addr,
                       0);
      (docclass->data)(dest, name);
      (docclass->endTag)(dest, "A");
   }
   (docclass->endTag)(dest, "MENU");
   (docclass->endTag)(dest, "BODY");
   (docclass->endTag)(dest, "HTML"); 
*/


We register each of these with the following routine:

int
ContentType_register(CONST char* type, CONST char* subtype,
		HTParseProc parse, void* closure);

For example:

main()
{
  ContentType_register("TEXT", "X-HTML", HTML_parse, griddoc);
  ContentType_register("TEXT", "PLAIN", PlainText_parse, griddoc);
  ContentType_register("APPLICATION", "X-GOPHER",
			 GopherListing_parse, griddoc);
}


The following routine can be used for any MIME entity. It will dispatch
the appropriate parsing routine based on the content type header:

int
ContentType_parse(const char* ct, HText* dest, void* stream, int (getc)(void*));


Then we build some load routines, one per access scheme:
(note that this design separates format from the access scheme, which
allows us to, for example, load a gopher menu
from a local file, or load HTML text from a Gopher server)

/* I don't have error handling worked out yet. We need to have a coherent
   design for this. It's a mess in the current WWWlib. */

/* I think the WWW file: should be split into ftp: and local-file:.
   It's cleaner to implement; there are precedents in the MidasWWW local:
   scheme and the MIME ftp and local-file access-types. */

int
LocalFile_load(HText* dest, CONST char* path, CONST char* search)
{
  FILE* stream;

  if(stream = fopen(path)){
    const char* content_type = WWW_zen_content_type_from_extension(path);
    ContentType_parse(content_type, dest, (void*)stream, (int ()(void*))getc);
    fclose(stream);
    return 1;
  }else{
    /* log an error */
    return 0;
  }
}

int
FTP_load(HText* dest, CONST char* path, CONST char* search);

int
HTTP_load(HText* dest, CONST char* path, CONST char* search);

int
Gopher_load(HText* dest, CONST char* path, CONST char* search);
{
  const char* content_type = Gopher_zen_content_type_from_gtype_char(*path);
  char* host = HTParse(path, PARSE_HOST);
  char* portnum = HTParse(path, PARSE_PORT);
  int port = atoi(portnum);
  static char* tab = "\007";
  static char* crlf = "\015\012";

  void* stream = TCPOpen(host, port);

  if(stream){
    TCPwrite(stream, path, strlen(path);
    if(search){
      TCPwrite(stream, tab, 1);
      TCPwrite(stream, search, strlen(search);
    }
    TCPwrite(stream, crlf, 2);
    ContentType_parse(content_type, dest, stream, TCPgetc);
    TCPclose(stream);
    return 1;
   }else{
    /* log an error */
    return 0;
   }
}


Then we register these just like formats:

HTAccess_register(const char* name, HTLoadProc load, void* closure);


And the HTLoadDocument routine in HTAccess.c becomes this:

int
HTAccess_load(HText* dest, HTParentAnchor* p, CONST char* address)
{
  char* scheme = HTParse(address, PARSE_SCHEME);
  /* path is everything after the colon, except the anchor */
  char* path = HTParse(address, PARSE_HOST|PARSE_PORT|PARSE_PATH);
  char* anchor = HTParse(address, PARSE_ANCHOR);
  char* search = HTParse(address, PARSE_SEARCH_TERMS);
  HText dest = HText_new(p); /* check for doc already loaded in p @@ */
  void* closure;
  HTLoadProc load;

  if(load = /* load routine registered for scheme. find closure too */){
    (load)(dest, path, search, closure);
  }
  HTSelect(dest, anchor);
}


What do you think?

Dan


From TONYJ@scs.slac.stanford.edu  Thu Jan 14 05:52:55 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09279; Thu, 14 Jan 93 05:52:55 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11351; Thu, 14 Jan 1993 06:08:07 +0100
Date: Wed, 13 Jan 1993 21:07 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: web roaming robot (was: strategy for HTML spec?)
To: Guido.van.Rossum@cwi.nl
Cc: www-talk@nxoc01.cern.ch
Message-Id: <0F3E6794C0824DD6@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"Guido.van.Rossum@cwi.nl"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

>I have written a robot that does this, except it doesn't check for
>valid SGML -- it just tries to map out the entire web.  I believe I
>found roughly 50 or 60 different sites (this was maybe 2 months ago --
>I'm sorry, I didn't save the output).  It took the robot about half a
>day (a saturday morning) to complete.

If you do run your robot again I would be very interested if you could 
generate a simple list of document titles and their corresponding 
document id's (or URL's). We have a powerful spires database here, 
interfaced to the web, which we could easily import such a file into to 
great a VERONICA like index of the web. I think that would be pretty 
useful (unless someone is already doing it??).

One other problem to add to you list.....many documents are probably 
only accessible by giving a "keyword" . Unless you can write a robot 
which can successfully guess all possible keywords, you cannot 
gaurantee to be able to traverse the whole web.

Tony

From TONYJ@scs.slac.stanford.edu  Thu Jan 14 07:29:11 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09584; Thu, 14 Jan 93 07:29:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21379; Thu, 14 Jan 1993 07:44:22 +0100
Date: Wed, 13 Jan 1993 22:44 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: suggested libWWW architecture
To: connolly@pixel.convex.com
Cc: www-talk@nxoc01.cern.ch
Message-Id: <1CB4EEAD60824DD6@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"connolly@pixel.convex.com"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.cern.ch"

From Dan:

>/* I think the WWW file: should be split into ftp: and local-file:.
>   It's cleaner to implement; there are precedents in the MidasWWW local:
>   scheme and the MIME ftp and local-file access-types. */

I agree.  Here are some comments along the same lines I sent Tim a while back.

From Tim:
>Re "local:"
>     
>The actual implementation of "file": in WWW checks the hostname to see
>whether it is the local host, and if so uses direct file access.
>(It also checks /Net/<hostname>/<path> in case of NFS mounting)
>That is why it was called "file:" rather than "ftp:".  This means that you >can
>edit files under /pub which other people get with ftp. For example.
>The IETF WG wanted "ftp:" to be available, so I have made that a synonym >for
>"file:".

My immediate reason for implementing local was that MidasWWW implements "file:" 
through the gateway, and so I needed some other temporary way to access local 
files. When MidasWWW supports "file:" directly I may get rid of local (or make 
it a synonym for file maybe). However I do have some other problems with the 
file implementation, mainly the confusion between files access by ftp and files 
accessed locally. Problems are:

a) How to tell whether a specified node is the "local" node? The /NET test is 
not portable, it doesn't work on our Unix system here (we use /nfs here). It 
works even less well on VAX clusters.

b) Even if I could tell that the file is on the local node, things still would 
not work since /pub is NOT the root of the anonymous FTP directory. I.e. 
file://localhost/test.html is NOT the same as local:/pub/test.html. Again this 
applies even more to non-unix systems.

Both of these problems tempt me to keep local:, or some equivalent. Comments?

Tony


From timbl@www3.cern.ch  Thu Jan 14 09:26:54 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09959; Thu, 14 Jan 93 09:26:54 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05709; Thu, 14 Jan 1993 09:42:06 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00242; Thu, 14 Jan 93 09:41:13 +0100
Date: Thu, 14 Jan 93 09:41:13 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301140841.AA00242@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Thomas A. Fine <fine@cis.ohio-state.edu>
Subject: Re: web roaming robot (was: strategy for HTML spec?)
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Tom,

Great idea, LOTS of applications.  Traversing a tree to a given depth
makes a book.  Tony's WWWVeronica is a great idea -- particularly as  
it can pick up WAIS indexes and Gopher and telent sites all together  
and make a megaIndex of the whole scene!

Implementation ideas:   The WWW library anchor object actually keeps  
track of every anchor visited.   It uses a hash table to speed up the  
generation of new names.  The HTAnchor_findParent or somesuch routine  
find it if it exists otherwise creates it.  You just need a return  
code to tell you whether you have a new one or not, whether to  
truncate the search there.

You could use the HTRules translation table for controlling the  
domain of search.  Useful things to do with the search  are

1. list all references OUT of the domain from within it
	For example, find all telnet sites listed in Hytelnet.
	List all WAIS indexes mentioned in the Web's WAIS catalogue.
2. list all referencs within, depth-first, with depth indication
	This can drive a book-making script
3. Apply command to everything within the domain
	for checking
	etc etc

I even wondered about putting the traverse code into the library do  
that arbitrary browsers could use it.  It would generate a hypertext  
list of all objects found for example.

Tim

From timbl@www3.cern.ch  Thu Jan 14 10:06:32 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10090; Thu, 14 Jan 93 10:06:32 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10773; Thu, 14 Jan 1993 10:21:43 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00272; Thu, 14 Jan 93 10:20:48 +0100
Date: Thu, 14 Jan 93 10:20:48 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301140920.AA00272@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: strategy for HTML spec? 
Cc: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Wed, 13 Jan 93 14:34:40 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>
>  Sounds cool. This points out yet another thing the WAIS folks did
>  right: every database has an associated maintainer as part of
>  the protocol. WWW could learn a lot from WAIS.

I suggest webmaster aliases for server-wide responsability and
a typed link for authorship of any given document.   Many
servers provide stuff from many areas, one person is not
responsible for everything.  Our local mainframe doc system
has a function key dedicated to "who is responsible for the runnish  
on my screen?!" function.   This is important for up-to-date info,
accountability.

I see this as one good use for a link type.  Something I have
wondered about a lot is a namespace for people in the URL scheme.
You can even find something about them using SMTP if they
are on the internet.
 <A HREF="mail:timbl@info.cern.ch" TYPE="author">tim</A>

Following the link would give options of mailing the person.

>  >All we have to do is agree to set up the wwwmaster aliases.


Any objections?

>  

>  Perhaps HTML2 will provide a handle on how to get ahold of the  
relavent
>  person -- it should!


You mean http2 or html2?

>  >This would also be a good chance to map out the entire Web.   
Anyone
>  >know any good algorithms for drawing arbitrary directed graphs  
with
>  >no overlap?
>  

>  Ever heard of map coloring problems? You can't draw an arbitrary
>  directed graph with no overlap. The set of graphs that you can
>  draw is the subject of great study, I believe. They're called
>  "planar" graphs.


I think we are allowed to let lines cross.  Just than minimising the
number of crossings (the "badness") is almose certainly np complete
But in fact a tree will probably be less confusing for people.

I like history trees like

AAAAAAAAAAA
  BBBBBBBBBBBBBBB
  CCCCCCCCCCCCC CCC C
  DDD DDDDDDDD
     EEEEEEEEEEEE
     AAAAAAAAAAAA *
     BBBBBBBBBBBBB *
  FFFFFFFFFF FFFFFF
     DDDDDD *
  GGGGGGGGGGGGGGG

wheer * indicates that the links from that node are listed at a same  
or higher level in the tree.  (You could give  line number  
cross-refernece or a link to the listing).  This is gives the real  
user the comforting illusion that (s)he is playing with a tree, which  
people seem to find easier to remember than a web.


>  >  Which reminds me, a good directed graph is the right way
>  >to implement a history mechanism.  Somebody want to take a crack  
at
>  >it?
>  

>  This is another area where the HyTime folks have done a lot
>  of thinking that we should try to take advantage of.

Where do we find the HyTime folk's thinking online?

>  Dan
>  

	Tim
	

From timbl@www3.cern.ch  Thu Jan 14 11:05:28 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10435; Thu, 14 Jan 93 11:05:28 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18139; Thu, 14 Jan 1993 11:20:39 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00336; Thu, 14 Jan 93 11:19:47 +0100
Date: Thu, 14 Jan 93 11:19:47 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301141019.AA00336@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Server maintainers please note
Reply-To: timbl@nxoc01.cern.ch


An addition to the server etiquette rules in
http://info.cern.ch/hypertext/WWW/Provider/Etiquette.html
says that for any internet host running a WWW server there should be  
a mail alias
	
	webmaster@hostname

to which problems with the server can be reported.

Remember also that it is wise to set up a domainname alias for
your server: rather than referring to it as  mysun4.cc.fred.edu
make an alias for example

	www.fred.edu

so that if you change machines, the alias can be switched to the new  
server.

	Thanks for your time, keep up the good work!
	
		Tim BL


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web team leader           (NeXTMail is ok)	
CERN, CN Division                     Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155



	

From murphy@dccs.upenn.edu  Thu Jan 14 14:43:46 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11713; Thu, 14 Jan 93 14:43:46 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15451; Thu, 14 Jan 1993 14:58:57 +0100
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA23440; Thu, 14 Jan 93 08:58:56 -0500
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA24187; Thu, 14 Jan 93 08:58:53 -0500
Date: Thu, 14 Jan 93 08:58:53 -0500
From: murphy@dccs.upenn.edu
Posted-Date: Thu, 14 Jan 93 08:58:53 -0500
Message-Id: <9301141358.AA24187@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: web roaming robot (was: strategy for HTML spec?) 


[Tim & Tom -- sorry for the duplication, I left out a comma
in the cc: list in the previous message]

Timbl:
> Great idea, LOTS of applications.  Traversing a tree to a given depth
> makes a book.  Tony's WWWVeronica is a great idea -- particularly as  
> it can pick up WAIS indexes and Gopher and telent sites all together  
> and make a megaIndex of the whole scene!

I agree that the map produced by traversing all of WWW would be
QUITE large and that it would be more efficiently searched as
an Index (WWWVeronica), if the output of the Robot were Text.

A new twist: (I am still trying to catch up on all the features &
functionality of WWW, so if WWW already does this, please tell me)

Is it possible for a user of WWW to see, graphically, a map of the
Web?  If the client software had a map to work with, instead of a
book, and the user could point at a spot on the map and select it,
then I think it would be a lot easier to navigate.

There could be a "short-range" scan which would show a close-up view
of the web links all around the current node, upto around 3 or 4
levels.

There could be a "long-range" scan which would show a global
view of the Web, leaving out the details of the local links.

This requires an extension beyond hypertext into hypermedia, of
course.

Anyway, would hyper-graphical representations of the Web be useful?
If it is worthwhile, is it doable?

--lam

Linda A Murphy                                  Internet: murphy@dccs.upenn.edu
Network Engineering                  Data Communications and Computing Services
University of Pennsylvania                                       (215) 898-9534

From timbl@www3.cern.ch  Thu Jan 14 17:47:51 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13720; Thu, 14 Jan 93 17:47:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11438; Thu, 14 Jan 1993 18:03:03 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00591; Thu, 14 Jan 93 18:02:07 +0100
Date: Thu, 14 Jan 93 18:02:07 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301141702.AA00591@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: HTML todo list
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


My machine crashed from too many wondows and I lost a few unsent mail  
messages with that.  So I may repeat myself at first, up to point 14.

Changes to the DTD I have made are in 

/hypertext/WWW/MarkUp/HTML.dtd.html

Connolly/Current/* is untouched.

> Date: Mon, 11 Jan 93 22:36:43 CST
> From: Dan Connolly <connolly@pixel.convex.com>
> 


> 1. My dictionary lists "markup" as a word, not mark-up.
Fixed
> 2. The PLAINTEXT situation should be logged as a bug against
OK it is but not many servers use it and clients like to be able to  
get source of postscript files for example easily. HTTP2 will fix it.
> 4. HTML should support QUESTION and RESPONSE elements to
> support converting USENET FAQ's to HTML
Too specific I think.
> In http://info.cern.ch/hypertext/WWW/Provider/ShellScript.html
> 5. PLAINTEXT is deprecated. Use PRE, and use a sed script
Done.  text2html.sed on th web under HTML generation tools.
> 6. .../WWW/Tools/HTMLGeneration/dir2html.txt
> This thing doesn't quote attributes; ...
Fixed. 

> 7. .../WWW/Tools/HTMLGeneration/ls2html.awk.txt> Quotes around  
HREFS, PLAINTEXT.
Fixed
 

> 8. .../WWW/Daemon/Implementation/asis.txt
> Quote HREFS, numeric character references where necessary.
Quote sin online version, original is being rewritten anyway I am  
told.
> 9. http://info.cern.ch/hypertext/WWW/HytelnetGate/src/htn2html.c
> Uses HEADER in stead of HEAD.
Fixed.
> Quote HREFs.
Fixed.
> Special character entities?
> Yeah! It uses numeric character references already!
Does it? You mean entities I think.
> In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html

> 10. Mark-up again
Fixed

> 11. This text seems out of place:
OK I have hidden it. :-) Does your spec say it anywhere?

> 12. Default text: this node seems to confuse lots of issues.
OK Reference to your doc instead

> In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
> 13. This text is out of place: 

Gone.
 

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/HEAD.html
> 14. These blurbs should probably quote their element declarations
I have started an HTML.dtd.html with links.
 

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/TITLE.html
> 15. This seems redundant:
Fixed.

> 16. What does this mean?
Elaborated and more sepcific.
 

> 17. Should the TITLE element be CDATA, RCDATA, or PCDATA?
> If we want to be able to use Latin chars in the title,
> it can't be CDATA. The only difference between RCDATA
> and PCDATA (with no subelements allowed) is that comments
> are recognized in PCDATA, whereas they are just regular
> data in RCDATA.

Good point.

 - If we specify Latin 1 as the base set, can't wehave latin 1
   characters in CDATA?

 - If we can't, then I guess we use PCADATA as it would be the
   only place except for <XMP> and <LISTING> where we can use
   RCDATA.
   

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/ISINDEX.html
> 18. The word "Format" connotes lexical details, which are discussed
> elsewhere. I endorse the use of examples, but I'd like to keep
> the model of
> 	SGML source ==parser==> ESIS ==WWW semantics==>formatted  
output
> consistent. The WWW semantics processor doesn't deal with <>'s etc.
> It just sees the presence of the ISINDEX element and acts  
accordingly.

Yes.  OK.  But I want as I said before (unless the crash lost the
message) to have two documents out of this. One is the HTML spec for  
MIME IANA registration.  The other is a readable document which is  
NOT 100% a precise refernce document but can be read by human beings  
WITHOUT SGML knowledge.  I can guess that this document will have 10  
times the readership of the other if it is readable, as <10% of the  
people creating HTML will know about SGML CROs etc etc.

It is good to have a lot of cross-reference between them.

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/NEXTID.html
> 19. The status of each element should be noted consistently. e.g.
> Mainstream	Consistently used by past, present, and future  
implementations.
> Deprecated	In use and will be supported, but should be avoided.  
(XMP)
> Obsolete	In use in some documents, but will not be supported.  
(NEXTID)
> Proposed	Not yet in the DTD or widely supported (e.g. LINK)
> Standard	Not yet widely supported, but will be (e.g. PRE)
> Extra		It's legal to ignore these. (e.g. EM)


We have almost as many categories as elements!  I'd add
Obsolescent	Will be obsolete when the alternative implementation
		(eg HTTP2) is available.
		
I'd make PRE mainstream as there are no implementations for which a  
new PRE-understanding version is not available or easily made  
available. And so cut out "Standard"  OOps I put it in again  
...see#31.

I have made NEXTID Mainstream.  Editors need it: can't do without it
really.  I would perhaps change it to <EDITING NEXTID=z27> if that  
was felt to be more logical.

We also need a hook for a version for the checkin/out/lock logic  
DAN(?) proposed.  That was that when you
lock or PUT a document, you specify the version so that a document  
can be PUT or CHECKED IN by a different person to the one who GoT it.
This means the server gives a key, a version or date code, with the  
document. This is all HTTP2 except when a document is stored  
somehwre, passed around and then eventually returned to the server.  
In that case, it needs a place to hold its original version number
on the server.

<EDITING NEXTID=z27 CHECKEDOUTAS="19930217234507">

Thoughts?

> http://info.cern.ch/hypertext/WWW/MarkUp/Elements/LINK.html
> 20. How many of these are allowed? I could change
Any non-negative integer
> ... <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK*)>
> I don't know if the latter is legal SGML. I'd have to try
> it out.
I think that's what we want.

> 21. Link types are not well defined. The only reason to put
> something in a public specification is so everybody can agree
> on some semantics. If there are no semantics to agree on,
> why include the TYPE attribute? (It's status is at best
> "proposed" in my mind, though it's in the DTD.)


Yes and no.  We need some well-define link type but we also need this  
as a hook for the future which we haven't enugh experience.  Link
types whould be registered.

This is a flexibility point, but it must be firm ... like
a towing ball on the back of your pickup you want to be able
to connect anything onto it but you want it well fixed onto the  
truck!

But I want to make it REL instead of TYPE as people think TYPE
refers to the object type of the desdtination object rather than the  
link.  (From messages on this list).

> In http://info.cern.ch/hypertext/WWW/MarkUp/Headings.html
> 22. "(at least six)" -- how about exactly six? Though I've
> seen a lot of style guides that frown on anything more than 4.

I agree.  I wuld frown ony anything over 3 in a hypertext document.
However, it is useful to generate a great big HTML document by
concatenating little ones, demoting their heading levels. You then  
print the big document. This generates up to 6 easily.  Maybe we  
should go to 9 but frown on >4.

> In http://info.cern.ch/hypertext/WWW/MarkUp/SGML.html
> 23. We should give at least one complete reference to the standard, 

Done.

> 24. In the Archive section, we could metion comp.text.sgml,
> the SGMLs parser materials, and the ifi.uio.no archive.

Link put in cruely.

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html
> 25. All attribute values have to be quoted, including NAME.
> The example is wrong.

I have cahnged NAME to ne a NAME -- ie doc-wide unique which it must   
be. Numberic ones are then not valid but I donb't generate them any  
more.  I think that we should stick to the intended ID system. In the  
future, we can think about IDs on many other elements.

> 26. The TYPE attribute hardly seems worth mentioning. In the DTD,
> it's a NAME, not just any old string.

I have made it REL as I said above and I think it is very important.

> 27. We should look at modeling anchors as HyTime linkends
> and/or ilinks.

Yes I agree when someone has time to get into that.

> 28. We should look at modeling the LINK element as a HyTime
> construct as well.
Ditto.

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/P.html
> 29. I don't like the use of "exact representation" here:
OK we stick to "rendering" for that

> 30. Where are P's allowed? In the DTD, they're allowed in:
> HTML, BODY, ADDRESS, BLOCKQUOTE, PRE but not in HEAD, A,
> CODE, SAMP, etc.

That's right.  They are not in the CERN implementations allowed in  
<DL> or <UL> etc, but they would be useful in those.
Comments?

> In http://info.cern.ch/hypertext/WWW/MarkUp/Lists.html
> 31. Ordered lists: Obsolete or Standard?

Standard. Bother I thought we'd got rd of that! (The next editor will  
turn them into unordered lists at the moment but I can fix that)
 

> 32. "The format is:" Here again, this is an example, but it's
> hardly a specification of the format of a UL element.

Ok. example.

> 33. What does this mean?
> The opening list tag  must be immediately
> followed by the first list element.

(LI | (A|%text)+)  in SGML I suppose just as you say.
You can't
	<UL>and here they all are:
	<LI>The first..
	<LI>the second
	</UL>
 

> 34. The important difference between UL, MENU, and DIR is not
> how they are displayed, but their semantic meanings. A MENU
> is a list of things to choose from. A DIR is a list of names
> in a directory.

Yes and no.  I too like logical definitions -- I am sold on semantic  
markup but HTML is to cover a vast range of data and semantics. MENU
These things are NOT necessarily what their names suggest -- many a  
selectable menu is set out as a DIR or a DL. The element names are
mnemonic only.  The blurb talks about how much text is in the  
paragraphs.

> 35. We could also make this semantic distinction between PRE,
> XMP, and LISTING, were it not for the syntactic confusion
> surrounding XMP and LISTING.

We coudl but we are deprecating XMP and LISTINg and PRE will do for
all.  You can only be very semantic in a very narrow application.
This is not one.

> 36. Get rid of this:
Gone

> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/PRE.html
> 37. Wording of the newline documentation:
> Line boundaries within the text are
Reworded with "render"

> 38. Semantics of newlines in PRE. Given the current DTD, a newline
> after the PRE start tag or before the PRE end tag is not reported
> by an SGML parser.
> 

> I think I can cook up some magic SHORTREF declarations that will
> cause the SGML parser to report the newlines (possibly as P tags).
> [This would obviate the need for special newline processing code
> in libHTML]
> 

> In any case, I'd suggest that ALL NEWLINES REPORTED BY THE SGML
> PARSER IN THE PRE ELEMENT BE DISPLAYED AS LINE BREAKS. That only
> leaves the issue of which newlines are reported, which is governed
> by the SGML standard.

... and with the issue of explaining the end result to the
simple HTML writer and to me without our needing to call on the
model of the SGML engine and application. Awaiting the results
of your tests with SHORTREF.

> 39. I don't like the way this is worded:
> The &#60;p&#62; tag should not be used.
Ok done

> 40. "... character character highlighing elements may be used."
> Ack! I don't recommend this! Hmmm... maybe only the B, I, and U
> elements. This certainly conflicts with the current DTD.

Serious point here folks.  There was a great demand for B I U
for man pages and the like. Why prohibit anything other than TT.
or to keep it simple, allow anything and mention TT should not be  
used, and the constraints of fixed width may limit the ability to  
render some highlighting.

I have introduced %htext noting that text always occurred with A.
I hope I have done it right.
 

> In http://info.cern.ch/hypertext/WWW/MarkUp/Highlighting.html
> 41. These have status "Extra"
> Where not supported by implementations,
> like all tags, these should be ignored.<p>
> 

> This should be a warning to providers that some information may
> be lost on some browsers.
> 

> 42. (Definition of these and reference
> - Dan?)
> They come from TeXinfo.
Thanks

> 43. I left the TeXinfo @file element out. I don't remember why.
> It might have been an oversight. Do we want it in there?

No too sepcific. We have enough.

> 44. Examples (TBD) see complete.html in my stuff.

I repeat that I like your examples but I would like them split
into GOOD HTML documents describing bad HTML documents,
with links to the bad documents for testing only.
We don't want people to follow links to the only documentation to  
find their parser has core dumped :-)

> In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html#z41
> 45. The PLAINTEXT tag terminates the HTML entity. What
> follows is not SGML. In stead, there's an HTTP convention
> that what follows is a text/plain body.
OK -- in.

> 46. "The text may contain any ISO Latin printable characters" --
> this conflicts with the DTD. I think a design that treats Latin
> characters as external data entities is cleaner than one that
> treats them as text characters, but I'm willing to go the
> other way.

I'm glad.  Lets.  I think that a full 8-character base will be  
easier.  I think the text should be able to contain any latin 1.

> 47. "including the
> tag opener, so long as it does not
> contain the closing tag in full."
> For Pete's sake, could we get this out of there once and for all?
OK OK OK :-) I hope "The text may contain any ISO Latin printable  
characters, but not the end tag opener. (See Historical note)" is OK


> 48. "The <a  NAME="z22">XMP tag</a>..." Use the term "element". The
> term "tag" doesn't include the content of the element.
Done.

> In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
> 49. "Special characters are represented
> by SGML entities"
> They're represented by numeric character references.
> The lt, gt, and amp entities are not in the DTD. They should
> be supported for historical reasons, but they are obsolete.
I would like them in the DTD. While people are still reading/writing
HTML they are useful. My mental ASCII table is in hex, not decimal,  
anyway.  Are they any overhead? Why the war against them? For the ISO
characters you wanted the opposite.  (Does your menatl ASCII table  
stop at 128? Mine too)

Comments?

> In  
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/HTML.html
> 50. I'd like to move the Abstract, Specification, and the reference  
to
> "Text and Markup" up into
> http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
> That node would look like
> 

> <H1>HyperText Markup Language</H1>
> <H3>Abstract</H3>...
> <H2>Language Reference</H2>
> 	<A>Text and Markup</A>
> 	<A>The Elements</A>
> 	<A>Implementors' Guide</A>
> <H2>Specification</H2>
> 	<A>the DTD</A>
> <H2>Appendices</H2>
> 	<A>futures</A>
> 	<A>constraints</A>
> 

> and this node would become "Implementors' Guide", with
> pointers to recommended, complete, tolerated, errors,
> libHTML, and SGMLs.
> 

> In  
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/html.dtd
> 51. include ISO Latin 1 character set in SGML declaration?
> 

> 52. Put PLAINTEXT back in HTML element (fell out by mistake.)
> 

> 53. LINK element?
> 

> 54. Get rid of H5 and H6?
> 

> 55. Get rid of link TYPE lement?
> 

> 56. Document BLOCKQUOTE in Elements reference.

This BLOCKQUOTE... it should be one thing or the other.
If it cannot contain other paragraph styles then it should be a  
paragraph style like address, and not be able to contain address.
This is easy for everyone to implement.

If it can contain ADDRESS then why not let it contain anything - in  
particular, headings. Trouble is, I can't represent that in RTF  
easily so than blows the NeXT and Mac browsers. So let's
make it 

<!ELEMENT BLOCKQUOTE - - (%htext;|P)+>
like ADDRESS, and bear it in mind for HTML3 which will have SECTION  
in, ie without the linear RTF constraint.

> 57. EXPIRES attribute on HEAD?

I toook it off .. its in HTTP2, as it applies to all formats not just  
HTML.
> 58. Get rid of NEXTID element?
 Nope .. needed to stop editors reusing deleted IDs. See above.
  

> 59. Document URN, TITLE, METHODS attributes of A element.
Ooo yes. Done. Lots of "notes" attached for info only.
 

> 60. Proposed Headers element (like a DL; for RFC822 message  
headers:
> <HEADERS>
> <dt>To<dd>connolly@convex.com
> <dt>Subject<dd>HTML todo list
> </HEADERS>)


Hmmm.
1. In fact, <DL COMPACT> looks very similar and has less narrow a  
meaning.
2.In fact the headers inforation could rather be regarded as part of  
the  metainfo in the <HEAD> element. Many of the RFC822 things will  
in fact be outside the document in the HTTP layer.  This is a bit  
chick-and-egg. Here we are describing an SGML dtd for a spoecific  
format for a MIME_wrapped RFC822 body, and in it we want to put the  
RFC822 header. Hmmm.  Something has got muddled. But I understand  
what you mean: very often one quotes mail messages as text. Strictly,  
one shouldn't though. You shouldn't be able to edit the headers.

Currently there is DL COMPACT which does that. It is implemented in  
www. I am torn betwen generality and the preacticality of getting  
something defined and outthe door and I thinkl the latter wins so  
let's put COMPACT as an attribute for DL and leave the HEADERs if you  
don't mind too much.


> 61. List STYLE attribute?

No I don't think so -- see discussion #60


> 62. XMP and LISTING: CDATA or RCDATA?
CDATA is probably nearest to the original intention?

This is your stuff dan I think:
> In  
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html
> 63. Under "Parsing Content Into Data and Markup," improve the
> explanation of the MIXED, ELEMENT, EMPTY, CDATA, and RCDATA content
> types (PCDATA is the wrong term) and how it affects parsing.
> 64. Revise the section on the sample implementation, libHTML, and
> supported.html.
> 

> In http://info.cern.ch/hypertext/WWW/Test/test.html
> 65. This node should be moved to the implementors' guide.
Same coments as above -- moved in <PRE>

> In http://info.cern.ch/hypertext/WWW/MarkUp/Future.html
> 66. Delete the reference to the perl script.
done
 

> 67. There are two references here to old versions of my spec.
> 68. Header: it's in there: HEAD
> 69. Highlighting: it's in there> 

> 70. Fixed width with anchors: it's in there: PRE.
gone .. all gone!

> (get rid of HP1 etc. in Elements reference)
No -- I will put that lot in another file though to keep it clean.
There are some people (here) who geenerate a lot of HPs.
 

> 71. Entities: Latin chars are in there. What do we need bullets  
for?
We don't.

> 72. Comments: the comment element is a bad idea. SGML comments are
> documented and supported.

They are rather different in that a comment can surround a whole
nested stack of SGML elements, and could ne nested. I don't suppose  
SGML comments can?

> 73. Link types: we should look at HyTime before we go much further
> on this.
Well, there is only 9 pages on hhypertext in HyTime (More Time than  
Hy) and in that I can't see any mention of link types.  As I said  
above (with a different metaphor), I think this should be a well  
defined and entrenched gate into uncharted terriory

> In the midaswww-1.0 browser: [by the way: I've fixed all these in  
my copy]
> 

> 74. HREF's with quotes don't work
Foxed wth Tony's fix
> 75. Unrecognized tags are treated as data, rather than ignored.
> 76. numeric character references and entity references aren't  
supported.
Could you post diffs please for those Dan? Thanks.

> 77. ETAGO doesn't end XMP, LISTING, PLAINTEXT unless it's the right
> GI. (e.g. <XMP>foo</foo> blah : blah should not be in the XMP  
element.)
> 

> 78. local: acess scheme is wierd. I suggest we go with ftp: and
> local-file: to match MIME, and get rid of local: and file:
Covered in another messsage.  I am prepared to split
file to ftp: and local: even though there are many (decnet, afs,
etc) ways to get at files and the client may be the best judge of  
what will work for him.

 Now, what about the SAVEDAS adddress so that from justthe content of  
the document hte partial UDIs can be resolved? I think that is a  
useful thing, and could be essentail. I will put that in as Standard.
 

> Well, that's all I can think of. Good night.
I hope you slept well...

I have made a provisional list of link relationships. Ihope
they show the utility of the attribute. They can always be ignored!

> Dan

Tim
 


From fine@cis.ohio-state.edu  Thu Jan 14 20:35:23 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15212; Thu, 14 Jan 93 20:35:23 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29711; Thu, 14 Jan 1993 20:50:34 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA29567; Thu, 14 Jan 93 14:50:30 -0500
Date: Thu, 14 Jan 93 14:50:30 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301141950.AA29567@soccer.cis.ohio-state.edu>
To: murphy@dccs.upenn.edu, timbl@nxoc01.cern.ch
Subject: Re: web roaming robot (was: strategy for HTML spec?) 
Cc: www-talk@nxoc01.cern.ch, litwack@dccs.upenn.edu
X-Mailer: Perl Mail System v1.1

>Timbl:
>> Great idea, LOTS of applications.  Traversing a tree to a given depth
>> makes a book.  Tony's WWWVeronica is a great idea -- particularly as  
>> it can pick up WAIS indexes and Gopher and telent sites all together  
>> and make a megaIndex of the whole scene!
>
>I agree that the map produced by traversing all of WWW would be
>QUITE large and that it would be more efficiently searched as
>an Index (WWWVeronica), if the output of the Robot were Text.
>
>A new twist: (I am still trying to catch up on all the features &
>functionality of WWW, so if WWW already does this, please tell me)
>
>Is it possible for a user of WWW to see, graphically, a map of the
>Web?  If the map produced by the WRR (Web Roaming Robot) were to
>produce a map instead of a book, and the user could point at a spot on
>the map and select it, then I think it would be a lot easier
>to navigate.

Well, thats more or less what I meant when I said this would make an
ideal history mechanism.

>There could be a "short-range" scan which would show a close-up view
>of the web links all around the current node, upto around 3 or 4
>levels.
>
>There could be a "long-range" scan which would show a global
>view of the Web, leaving out the details of the local links.

I'd prefer continuous zoom.  I've seen widgets that do this, although
I'm not sure where to find one.  At any rate the problem is solvable.

>This requires an extension beyond hypertext into hypermedia, of
>course.

Not necessarily.  As the first pass, it can be implemented as history
for the browsers.  Combine that with a saveable history, and you could
just stick in the whole web into your history.

On the other hand, I have (very distant) plans to lay a WWW browser on
top of GhostScript.  The browser would convert to postscript (also
very convenient for printing).  Ghostscript provides hooks for inserting
mouse functionality, for the clicking, and away we go.

The point is this: once that's done, hypertext postscript just sort of
happens.  It's there, with no additional work whatsoever.

>Anyway, would hyper-graphical representations of the Web be useful?
>If it is worthwhile, is it doable?

Useful, yes; doable, yes; easy, no.

The hard part is telling a computer to lay out the graph.  You can assume
a tree structure for any given local site, and be mostly correct, but I
get the impression that the web is much more web-like across multiple
sites.  Evan assuming a tree structure, you have to make sure that non
of your non-tree links are drawn on top of each other (in parallel, that is).

Suppose we have a tree like this:

	      A
	     /|\
	    / | \
	   B  C  D

If B, C, and D are all inter-linked, you can't draw their links and
have them all be visible, unless you move one of B, C, or D; or use
curved lines as links (anybody know how they generate the Usenet
maps?).  The specific solution is obvious, but generalizing it is not
(to me, anyway).

One concept that would probably help is grouping.  It's common that a
large body of documetation has a single entry point (or at least a
small number of them).  These could be displayed as a single element in
the map, until a certain zoom level is reached.  A good first guess
would be that each site is a single entity.

Parting Shot - does it occur to anyone that a Virtual Reality interface
might provide the best view of the web, and the best way of traversing it?
And does it also occur to anyone that this view of the web might look
a lot like the cyberspace described by author William Gibson?

	  tom

From connolly@pixel.convex.com  Fri Jan 15 01:13:46 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17681; Fri, 15 Jan 93 01:13:46 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25588; Fri, 15 Jan 1993 01:28:57 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA01399; Thu, 14 Jan 93 17:23:49 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA26924; Thu, 14 Jan 93 17:23:45 -0600
Message-Id: <9301142323.AA26924@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML todo list 
In-Reply-To: Your message of "Thu, 14 Jan 93 18:02:07 +0100."
             <9301141702.AA00591@www3.cern.ch> 
Date: Thu, 14 Jan 93 17:23:44 CST
From: Dan Connolly <connolly@pixel.convex.com>


Issues 1-10 are resolved to my satisfaction.

>> 11. This text seems out of place:
>OK I have hidden it. :-) Does your spec say it anywhere?

Well, it's mentioned in tolerated.html, but that's hardly
the place to go looking for explanations. I suppose we
need a section telling implementors how to handle errors
or something.

12-16: OK.

>> 17. Should the TITLE element be CDATA, RCDATA, or PCDATA?
>> If we want to be able to use Latin chars in the title,
>> it can't be CDATA. The only difference between RCDATA
>> and PCDATA (with no subelements allowed) is that comments
>> are recognized in PCDATA, whereas they are just regular
>> data in RCDATA.
>
>Good point.
>
> - If we specify Latin 1 as the base set, can't wehave latin 1
>   characters in CDATA?
>
> - If we can't, then I guess we use PCADATA as it would be the
>   only place except for <XMP> and <LISTING> where we can use
>   RCDATA.
>   

I agree that CDATA is closest to the original intent. And yes,
if we include Latin 1 chars in the document character set, we
can put them in CDATA, but they'd have to be actual 8 bit
characters, and not numeric character references.

Furthermore, it presents a problem for HTML writers. It's convenient
to treat all data characters the same way, that is, replace <, >, &
with character references. If we make the TITLE CDATA, then HTML
writers must special case this element, and not do the replacement.
Furthermore, they're out of luck if they want to write "</x" where
x is any letter.

On the flip side, if they do replace <>& with references, old parsers
probably won't grok. But I think that's a small price to pay: titles
with <>& in them will look ugly on old implementations. No big deal.

So, in the end, I vote for RCDATA.

This brings me to issue
79. How do we maintain the DTD?
The annotated DTD is a great idea. But we need to be sure the
actual SGML code matches the hypertext version. It seems we can
derive the SGML from the hypertext with:
% www -n -source HTML.dtd.html >HTML.dtd
Then we just have to maintain the hypertext version. I'll do some
testing and get back to you.

Also, 
80. The hypertext version of the DTD has some non-PRE parts. I suspect
a NeXT browser bug.

18: OK, but the discussion relates to issue 50.

>Yes.  OK.  But I want as I said before (unless the crash lost the
>message) to have two documents out of this. One is the HTML spec for  
>MIME IANA registration.

I disagree. I still think the root of the HTML documentation should
look like:

<H1>HyperText Markup Language</H1>
<H3>Abstract</H3>...
<H2>Language Reference</H2>
        <A>Text and Markup</A>
        <A>The Elements</A>
        <A>Implementors' Guide</A>
<H2>Specification</H2>
        <A>the DTD</A>
<H2>Appendices</H2>
        <A>futures</A>
        <A>constraints</A>

> The other is a readable document which is  
>NOT 100% a precise refernce document but can be read by human beings  
>WITHOUT SGML knowledge.  I can guess that this document will have 10  
>times the readership of the other if it is readable, as <10% of the  
>people creating HTML will know about SGML CROs etc etc.

I think this is madness. As I said before: it is exactly this group of
people, those writing HTML, that _must_ be aware of SGML syntax. The
"Text and Markup" document is about two pages of fairly readable
prose, in my opinion. If it's too much for folks to digest, let's do
something about that. But let's not create a priesthood here!

The whole point of my efforts is to make the HTML format
understandable by everyone who needs to understand it, while
maintaining SGML compliance.


>> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/NEXTID.html
>> 19. The status of each element should be noted consistently. e.g.

We already have some understanding of what the status is. What I'm
after is a way to look up the status of an element by name. This
relates to other reference needs too:

81. We need an alphabetical index of the HTML elements. Perhaps we
should reorganize the DTD so they appear in order there? I thought
http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
was going to be an alphabetical element reference. But I see the
need for the present organization. Still, I think we need another
element reference node.

back to
58. Get rid of NEXTID?
>I have made NEXTID Mainstream.  Editors need it: can't do without it
>really.

Hardly. It's a redundant optimization only: the editor need simply
scan all the anchor names, choose the highest, and add one.

Besides: it can be wrong. Suppose you create a document on the NeXT
and save it with NEXTID N=27. Then I edit it by hand and add anchor
names 27, 28, 29, and 30, but I forget to change NEXTID. Then
when you load it back into the NeXT editor, we'll have problems.

82. Do we need a place to put the locking cookie?
>We also need a hook for a version for the checkin/out/lock logic  
>DAN(?) proposed.  That was that when you
>lock or PUT a document, you specify the version so that a document  
>can be PUT or CHECKED IN by a different person to the one who GoT it.
>This means the server gives a key, a version or date code, with the  
>document. This is all HTTP2 except when a document is stored  
>somehwre, passed around and then eventually returned to the server.  
>In that case, it needs a place to hold its original version number
>on the server.
>
><EDITING NEXTID=z27 CHECKEDOUTAS="19930217234507">
>
>Thoughts?

Is
http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTTP2.html
the latest info on HTTP2? I don't see how the server gives the
cookie to the client on a CHECKOUT response. If the cookie goes
inside the HTML, then locking is limited to HTML format transfers.

I suspect that in stead, the cookie will be part of the headers
of the response. Then it would be the client's responsibility
to keep the cookie associated with the document content. It
might be handy, though, for the client to be able to tuck the
cookie inside the HTML, if the document is indeed HTML.

>> http://info.cern.ch/hypertext/WWW/MarkUp/Elements/LINK.html
>> 20. How many of these are allowed? I could change
>Any non-negative integer
>> ... <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK*)>
>> I don't know if the latter is legal SGML. I'd have to try
>> it out.
>I think that's what we want.

SGMLs says Okie Dokie. So this is resolved, pending a DTD update.


>> 21. Link types are not well defined. The only reason to put
>> something in a public specification is so everybody can agree
>> on some semantics. If there are no semantics to agree on,
>> why include the TYPE attribute? (It's status is at best
>> "proposed" in my mind, though it's in the DTD.)
>
>
>Yes and no.  We need some well-define link type but we also need this  
>as a hook for the future which we haven't enugh experience.  Link
>types whould be registered.
>
>This is a flexibility point, but it must be firm ... like
>a towing ball on the back of your pickup you want to be able
>to connect anything onto it but you want it well fixed onto the  
>truck!
>
>But I want to make it REL instead of TYPE as people think TYPE
>refers to the object type of the desdtination object rather than the  
>link.  (From messages on this list).

Ok. Now we have _some_ semantics to agree on. I agree the list
should be extensible, but until there was some list to start with,
I didn't see sufficient motivation to put it in the spec.

On the REL/TYPE name issue: This brings up issue
73. Link types: we should look at HyTime before we go much further
on this.

The REL/TYPE attribute is very close to the HyTime "anchroles"
attribute. See below for more on issue 73.

In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html
83. "The type is expressed by a string for extensibility."
I think it's a NAME, rather than CDATA in the DTD. So it's
not an arbitrary string -- it has to start with a letter etc.

>> In http://info.cern.ch/hypertext/WWW/MarkUp/Headings.html
>> 22. "(at least six)" -- how about exactly six? Though I've
>> seen a lot of style guides that frown on anything more than 4.
>
>I agree.  I wuld frown ony anything over 3 in a hypertext document.
>However, it is useful to generate a great big HTML document by
>concatenating little ones, demoting their heading levels. You then  
>print the big document. This generates up to 6 easily.  Maybe we  
>should go to 9 but frown on >4.

I agree with frowing on anything >4, but supporting up to 9 just
for this one application (concatenate, demote, print) seems like
a bad idea. I don't feel strongly one way or the other, though.

23: OK.

>> 24. In the Archive section, we could metion comp.text.sgml,
>> the SGMLs parser materials, and the ifi.uio.no archive.
>
>Link put in cruely.

Here's a reference to the SGMLs materials:
ftp://ifi.uio.no/pub/SGML/SGMLS/

>> In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html
>> 25. All attribute values have to be quoted, including NAME.
>> The example is wrong.
>
>I have cahnged NAME to ne a NAME -- ie doc-wide unique which it must   
>be. Numberic ones are then not valid but I donb't generate them any  
>more.  I think that we should stick to the intended ID system. In the  
>future, we can think about IDs on many other elements.

SGML considers omitting the quotes around an attribute value to
be a form of markup minimization. In the HTML DTD, I have turned
off all the minimization features, so ALL ATTRIBUTE VALUES MUST
BE QUOTED, regardless of whether they're CDATA, NAMEs, IDs, etc.

Now we have another issue:
84. Should anchor names by SGML IDs?
They're NMTOKENs in the current DTD. This restricts the syntax
to a string of 34 or fewer name characters. As for semantics,
the SGML parser will uppercase the string before handing it to
the application, but it won't check it for uniqueness.

Making this a NAME attribute would restrict the syntax further
so that it must begin with a letter.

Making this an ID attribute would give it the same syntax as NAME,
but the parser would also verify document-wide uniqueness.

The NMTOKEN approach was descriptive, whereas the ID approach
is somewhat prescriptive: it conflicts with some old HTML. I'm
all for moving to ID, though. I think we should take advantage
of SGML features wherever possible.


26-28: OK (but issue 73 is still open)

29: OK

>> 30. Where are P's allowed? In the DTD, they're allowed in:
>> HTML, BODY, ADDRESS, BLOCKQUOTE, PRE but not in HEAD, A,
>> CODE, SAMP, etc.
>
>That's right.  They are not in the CERN implementations allowed in  
><DL> or <UL> etc, but they would be useful in those.
>Comments?

Can we do the following in stead of using paragraphs in DL?
<DL>
<DT>large
<DT>big
<DD>Large and big are synonyms.
<DD>They share a definition.
<DD>This is the third paragraph of explanation about big
and large things.
</DL>

It appears that the linemode browser generally groks. Thus, let's
not mess with P's in DL's. (P's in UL's are messy enough to leave
out too, I guess.)

31-32: OK

>> 33. What does this mean?
>> The opening list tag  must be immediately
>> followed by the first list element.
>
>(LI | (A|%text)+)  in SGML I suppose just as you say.
>You can't
>	<UL>and here they all are:
>	<LI>The first..
>	<LI>the second
>	</UL>

I kinda thought LI's in UL's were just like P's in the BODY:
they separate, rather than terminate or begin, items.

But if you prefer/require the added structure, I'm all for it.

>> 34. The important difference between UL, MENU, and DIR is not
>> how they are displayed, but their semantic meanings. A MENU
>> is a list of things to choose from. A DIR is a list of names
>> in a directory.
>
>Yes and no.  I too like logical definitions -- I am sold on semantic  
>markup but HTML is to cover a vast range of data and semantics. MENU
>These things are NOT necessarily what their names suggest -- many a  
>selectable menu is set out as a DIR or a DL. The element names are
>mnemonic only.  The blurb talks about how much text is in the  
>paragraphs.

What the blurb talks about is exactly what I object to: defining
elements by their formatting. If they have no semantic difference, why
not just have one list element with an advisory WIDTH or COLUMNS
attribute?

In fact, I'd support more structure in these things. I suggest
that a MENU should be exactly a list of anchors -- same with DIR,
while UL is a list of free form text, possibly including anchors.

And the difference between MENU and DIR should not be defined in
terms of a number of characters. I'd explain it by saying that the
items in a DIR are likely to be short, mnemonic names that require
significant context for the user to choose between them, whereas MENU
items should be more verbose and may not require explanation or
context.

I see that you've edited the List document somewhat. It's getting
better, but there are some bugs too. Some sections that look like
they should be PRE are not (see #80).

In http://info.cern.ch/hypertext/WWW/MarkUp/Lists.html

85. The suggested syntax for COMPACT uses minimization, which has
been turned of in the HTML SGML declaration.

The markup
<DL COMPACT>
could be used if we had SHORTTAG (or maybe this is OMITTAG) yes,
but we don't. It's short for
<DL someattributename="COMPACT">
Some legal alternatives are:
<DL STYLE="COMPACT">
<DL COMPACT="yes">

35-37: OK

>> 38. Semantics of newlines in PRE. Given the current DTD, a newline
>> after the PRE start tag or before the PRE end tag is not reported
>> by an SGML parser.
>> 
>
>> I think I can cook up some magic SHORTREF declarations that will
>> cause the SGML parser to report the newlines (possibly as P tags).
>> [This would obviate the need for special newline processing code
>> in libHTML]
>> 
>
>> In any case, I'd suggest that ALL NEWLINES REPORTED BY THE SGML
>> PARSER IN THE PRE ELEMENT BE DISPLAYED AS LINE BREAKS. That only
>> leaves the issue of which newlines are reported, which is governed
>> by the SGML standard.
>
>... and with the issue of explaining the end result to the
>simple HTML writer and to me without our needing to call on the
>model of the SGML engine and application. Awaiting the results
>of your tests with SHORTREF.

Geez... you're really dragging your feet whenever it comes to
embracing SGML, aren't you? I think the number 1 issue is conformance,
with ease of documentation secondary. If we come up with a conforming
solution, folks can look at our documentation, SGML books, post to
comp.text.sgml, etc. for clarification.

On the other hand, if we cook up some shortcut (like "Line boundaries
within the text are
rendered as a move to the beginning
of the next line, except for one
immediately following or immediately
preceding a tag" which is not exactly what SGML reports, believe me),
a) folks using SGML compliant software will have to jump through
hoops to support our stuff, and b) our documentation becomes the
only place to look for guidance.

Back to the technical issues...

Newlines are also an issue in A elements. My version of the MidasWWW
browser sometimes displays an extra space in the case of:

some text with an <a
HREF="foo">
anchor</a> in it.

It displays one for the space after "an", and one for the newline,
since it doesn't remember whether it's in a word or not across
elements.

SGMLs would eat the newline after the A start tag. If I changed
libHTML to be in conformance on this issue, that would fix the
MidasWWW bug. I'm beginning to think that the way SGML handles
newlines by default makes some sense. We do need a cogent
explanation, though.

39: OK

>> 40. "... character character highlighing elements may be used."
>> Ack! I don't recommend this! Hmmm... maybe only the B, I, and U
>> elements. This certainly conflicts with the current DTD.
>
>Serious point here folks.  There was a great demand for B I U
>for man pages and the like. Why prohibit anything other than TT.
>or to keep it simple, allow anything and mention TT should not be  
>used, and the constraints of fixed width may limit the ability to  
>render some highlighting.

Highlighting elements like CODE, SAMP, etc. do not mandate a
particular formatting style. One shop may put SAMP sections
in a fixed width font, where another may just use a sans-serif
font to show the distinciton. Some shops may not make any
typographic distinction at all.

The PRE element is a complete escape from all this. It's an
element that says "here's what it looks like. The semantic
information has already been rendered into formatted text."
So while B, I, and U still have a place, CODE, SAMP, etc.
do not belong.


>I have introduced %htext noting that text always occurred with A.
>I hope I have done it right.

If you had built sgmls, you could know for sure :-) Yes, it
looks right to me, though I haven't done the translation
from hypertext to SGML code to check.

41-43: OK

>> 44. Examples (TBD) see complete.html in my stuff.
>
>I repeat that I like your examples but I would like them split
>into GOOD HTML documents describing bad HTML documents,
>with links to the bad documents for testing only.
>We don't want people to follow links to the only documentation to  
>find their parser has core dumped :-)

complete.html is GOOD HTML. But it lacks explanation.  I only meant to
suggest that the author of the Highlighting examples consult
complete.html, not that readers should be referred there.

45: OK

>> 46. "The text may contain any ISO Latin printable characters" --

OK, pending DTD update.

47-48: OK

>> In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
>> 49. "Special characters are represented
>> by SGML entities"
>> They're represented by numeric character references.
>> The lt, gt, and amp entities are not in the DTD. They should
>> be supported for historical reasons, but they are obsolete.
>I would like them in the DTD. While people are still reading/writing
>HTML they are useful. My mental ASCII table is in hex, not decimal,  
>anyway.  Are they any overhead? Why the war against them? For the ISO
>characters you wanted the opposite.  (Does your menatl ASCII table  
>stop at 128? Mine too)
>
>Comments?

For the ISO characters, I wanted to use names because I wanted to
treat them as external (i.e. non-SGML text) data entities. Since <, >,
and & have representations without resorting to entity processing,
that's the way I wanted to go. We would have had numeric character
references, handled by the parser, and external data entities, handled
by the application, but no text entities (which are handled by the
parser). It simplified the parser and the parser/application interface.

But since we're going to include ISO characters in the HTML
character set, but I still want to be able use their names,
we'll need to support text entities. As long as we're supporting
text entities, we might as well keep &lt;, &gt;, and &amp;.

>> 50. I'd like to move...

Whoa... no response at all? This was one of the major issues.
What does anybody else think of reorganizing this stuff?

51-57: OK, pending DTD update.

>> 58. Get rid of NEXTID element?
> Nope .. needed to stop editors reusing deleted IDs. See above.

I still say this doesn't belong in the standard. You can continue
to use it locally, Tim, but I don't think it's a generally
sound mechanism.

>> 59. Document URN, TITLE, METHODS attributes of A element.
>Ooo yes. Done. Lots of "notes" attached for info only.

Almost done. METHODS is not a comma separated list. The SGML
attribute type NAMES is one or more names separated by whitespace.

>> 60. Proposed Headers element (like a DL; for RFC822 message  
>let's put COMPACT as an attribute for DL and leave the HEADERs if you  
>don't mind too much.

Okie dokie.

>> 61. List STYLE attribute?
>No I don't think so -- see discussion #60

>> 62. XMP and LISTING: CDATA or RCDATA?
>CDATA is probably nearest to the original intention?

See 17. If we're going to have CDATA anywhere, it belongs
here. But I'd rather avoid it.

63-54: these are mine.

>> In http://info.cern.ch/hypertext/WWW/Test/test.html
>> 65. This node should be moved to the implementors' guide.
>Same coments as above -- moved in <PRE>

I don't follow you at all here. I think this relates closely
to #50.

66-70: OK

71: OK.

>> 72. Comments: the comment element is a bad idea. SGML comments are
>> documented and supported.
>
>They are rather different in that a comment can surround a whole
>nested stack of SGML elements, and could ne nested. I don't suppose  
>SGML comments can?

No, SGML comments can't be nested, but they could "surround a whole
nested stack of SGML elements." I'm prepared to debate the comment
element further, but shall we suffice it to say that it's obsolete?
It's listed as Deprecated in the web. This means it should be
supported by future implementations. I heartily disagree.

>> 73. Link types: we should look at HyTime before we go much further
>> on this.
>Well, there is only 9 pages on hhypertext in HyTime (More Time than  
>Hy) and in that I can't see any mention of link types.  As I said  
>above (with a different metaphor), I think this should be a well  
>defined and entrenched gate into uncharted terriory

The HyTime ilink architectural form has an attribute called "anchrole"
that has almost exactly the same semantics as the HTML anchor TYPE/REL
attribute, except that the HyTime anchrole has one name for each end
of the link, rather than a single name for the relationship between
the two ends. This obviates the need for the REV attribute: just
list the roles in the opposite order.

I'd like to get some HyTime folks to review the WWW data model. I
think we could get Elliot Kimber and/or Steve Newcomb to take a look
by posting to comp.text.sgml. I think that's just what I'll do.


74-77:
>> In the midaswww-1.0 browser: [by the way: I've fixed all these in  
>my copy]
>Could you post diffs please for those Dan? Thanks.

Tony and I have to sync up on all this. He's the author, and I
won't release stuff without his OK.

78: Not an HTML issue.

86. SAVEDAS
> Now, what about the SAVEDAS adddress so that from justthe content of  
>the document hte partial UDIs can be resolved? I think that is a  
>useful thing, and could be essentail. I will put that in as Standard.

Yuk, but OK for now. (I have lots to say about URLs, but until I
have time to do something about it, I'll leave them be :-)

Dan


From marca@wintermute.ncsa.uiuc.edu  Fri Jan 15 05:14:24 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18625; Fri, 15 Jan 93 05:14:24 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15482; Fri, 15 Jan 1993 05:29:37 +0100
Received: from uxc.cso.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA00409
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 14 Jan 93 22:29:34 -0600
Received: from wintermute.ncsa.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA18737
  (5.67a8/IDA-1.5 for <@newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch>); Thu, 14 Jan 1993 21:53:58 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	 id AA06221; Thu, 14 Jan 93 21:50:27 -0800
Date: Thu, 14 Jan 93 21:50:27 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301150550.AA06221@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: alpha/beta testers
X-Md4-Signature: 354cea467663c026100373b4c6d730e5

People interesting in alpha- and beta-testing a new Motif-based WWW
browser at various stages in its development, contact me... initially
it's hypertext only, but will soon have multimedia capabilities also.

Thanks,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Fri Jan 15 06:58:57 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19027; Fri, 15 Jan 93 06:58:57 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23638; Fri, 15 Jan 1993 07:14:10 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA07898
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 15 Jan 93 00:14:08 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA01783; Fri, 15 Jan 93 00:15:38 -0800
Date: Fri, 15 Jan 93 00:15:38 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301150815.AA01783@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: ebina@ncsa.uiuc.edu
Subject: questionable html constructs
X-Md4-Signature: b7421b4e3dc688876d9445b49dfe0460

We are finding the following situations in various HTML sources in the
web (mostly as a result of automatically generated HTML, e.g. man
pages), and, to put it mildly, it is confusing our browser and
ourselves....

... so quasi-authoritative answers (and corresponding cooperation from
HTML providers) to these questions would be greatly appreciated.

o What is the significance, if any, of <p>'s within a <pre> section?

o What is the significance, if any, of more than one <p> in a row,
  particularly on the same line?  And, how about the same situation in
  a <pre> section?

o Is '&lt' ('&lt;' without the semicolon) a valid construct?

o Can raw <'s and >'s be in a <pre> section?

Marc


From fine@cis.ohio-state.edu  Fri Jan 15 17:40:40 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24056; Fri, 15 Jan 93 17:40:40 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11979; Fri, 15 Jan 1993 17:55:54 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA07846; Fri, 15 Jan 93 11:55:50 -0500
Date: Fri, 15 Jan 93 11:55:50 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9301151655.AA07846@soccer.cis.ohio-state.edu>
To: marca@ncsa.uiuc.edu, www-talk@nxoc01.cern.ch
Subject: Re: questionable html constructs
Cc: ebina@ncsa.uiuc.edu
X-Mailer: Perl Mail System v1.1

>We are finding the following situations in various HTML sources in the
>web (mostly as a result of automatically generated HTML, e.g. man
>pages), and, to put it mildly, it is confusing our browser and
>ourselves....
>
>... so quasi-authoritative answers (and corresponding cooperation from
>HTML providers) to these questions would be greatly appreciated.
>
>o What is the significance, if any, of <p>'s within a <pre> section?

They are allowed, but I don't know that they should be interpreted,
since the new-lines are also significant.  I'd say that they should be
interpreted as ADDITIONAL line feeds; the people who set their code
up otherwise can just fix their html.  Ideally, you'd want to realize
that there's a <P> with every new-line, and if so, ignore one or the
other.  That's not really a legal treatment of SGML, but it should
produce nice results.  Of course it encourages people not to fix
their HTML.

>o What is the significance, if any, of more than one <p> in a row,
>  particularly on the same line?  And, how about the same situation in
>  a <pre> section?

It seems to be legal HTML, so I guess you just throw in a totally empty
paragraph.

>o Is '&lt' ('&lt;' without the semicolon) a valid construct?

No.

>o Can raw <'s and >'s be in a <pre> section?

No.

From connolly@pixel.convex.com  Sat Jan 16 01:06:11 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27160; Sat, 16 Jan 93 01:06:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26524; Sat, 16 Jan 1993 01:21:25 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA01078; Fri, 15 Jan 93 18:21:13 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA06921; Fri, 15 Jan 93 18:21:10 -0600
Message-Id: <9301160021.AA06921@pixel.convex.com>
To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
Cc: marca@ncsa.uiuc.edu, www-talk@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
Subject: Re: questionable html constructs 
In-Reply-To: Your message of "Fri, 15 Jan 93 11:55:50 EST."
             <9301151655.AA07846@soccer.cis.ohio-state.edu> 
Date: Fri, 15 Jan 93 18:21:10 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>o What is the significance, if any, of <p>'s within a <pre> section?
>
>They are allowed, but I don't know that they should be interpreted,
>since the new-lines are also significant.  I'd say that they should be
>interpreted as ADDITIONAL line feeds; the people who set their code
>up otherwise can just fix their html.  Ideally, you'd want to realize
>that there's a <P> with every new-line, and if so, ignore one or the
>other.  That's not really a legal treatment of SGML, but it should
>produce nice results.  Of course it encourages people not to fix
>their HTML.

This question is out of the jourisdiction of the SGML standard:
it's a question of how we're going to interpret things and display
them.

But, unlike the normal typeset paragraphs where ignoring a newline
here or there is no big deal, the writers of PRE sections want
some assurance as to what the output will look like.

It's on the todo list. I suggested we ignore <p> within <pre>,
but that looks like a bad idea. So now the current thinking,
I believe, is to render it as a line break. This makes those
man pages that end in <p> _and_ newline double space, but
we'll put the onus on the provider to fix that.

>>o What is the significance, if any, of more than one <p> in a row,
>>  particularly on the same line?  And, how about the same situation in
>>  a <pre> section?
>
>It seems to be legal HTML, so I guess you just throw in a totally empty
>paragraph.

I agree (again: this is not an SGML question, but a WWW question).

>>o Is '&lt' ('&lt;' without the semicolon) a valid construct?
>
>No.

Now this is an SGML question, and you're wrong: it's legal.

>>o Can raw <'s and >'s be in a <pre> section?
>
>No.

Again, this is an SGML question, and you're wrong.
<PRE>
Is a < b?
</PRE>
is perfectly valid markup.

Dan


From sugar!one!karl@uu.psi.com  Sat Jan 16 05:02:17 1993
Return-Path: <sugar!one!karl@uu.psi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27957; Sat, 16 Jan 93 05:02:17 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15419; Sat, 16 Jan 1993 05:17:29 +0100
Received: from sugar.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA02819; Tue, 12 Jan 93 04:39:21 -0500
Received: by NeoSoft.Com (smail2.5)
	id AA08127; 12 Jan 93 03:45:13 CST (Tue)
Received: by One.NeoSoft.Com (smail2.5)
	id AA00591; 12 Jan 93 00:06:00 CST (Tue)
Subject: Usenet news and WWW
To: www-talk@nxoc01.cern.ch
Date: Tue, 12 Jan 93 0:06:00 CST
From: Karl Lehenbauer <karl@one.neosoft.com>
In-Reply-To: <9301111351.AA00475@www3.cern.ch>; from "Tim Berners-Lee" at Jan 11, 93 2:51 pm
X-Mailer: ELM [version 2.2 PL13]
Message-Id: <9301120006.AA00591@One.NeoSoft.Com>

I am a latecomer, so forgive me if this is naive or old hat.

Many of the issues that people seem to be grappling with are already
handled by news.

For example, we are talking about caching nodes.  News has highly evolved
caching capabilities -- I mean, caching is what it is all about -- both for 
TCP/IP and UUCP-based links.

Someone mentioned the issue of caching and node names, apparently
node names would have to be rewritten by the cacher or need to be made
machine-independent in some way (?).  Article IDs are guaranteed unique
and are server-independent.  The mechanism for translating article
IDs to filenames is fast and pretty highly evolved.

Oh, ugh, "Supercedes:" doesn't cut it unless the article superceding
the old one replaces its article ID, which would probably be Bad.

Expiration dates can be set with "Expires:", and sites that 
archive certain groups already do special things on "Archive-Name:".

Plus news is already ultra-portable.

Is the brief-connection-per-document approach of HTTP still necessary
when the data is widely replicated?

It would be painful to go reap all the references that
point to expired articles, although if a user traversed to an expired
article, perhaps it could be pulled off of tape or an NNTP superserver 
somewhere.

Clearly the authors of WWW think news is important because WWW has 
nice capabilities for accessing NNTP servers.  What, then, is the 
motivation for HTTP as opposed to, say, using news with HTML article 
bodies?


From connolly@pixel.convex.com  Sat Jan 16 05:32:30 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28004; Sat, 16 Jan 93 05:32:30 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18297; Sat, 16 Jan 1993 05:47:45 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA09568; Fri, 15 Jan 93 22:47:41 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA13641; Fri, 15 Jan 93 22:47:39 -0600
Message-Id: <9301160447.AA13641@pixel.convex.com>
To: Karl Lehenbauer <karl@one.neosoft.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Usenet news and WWW 
In-Reply-To: Your message of "Tue, 12 Jan 93 00:06:00 CST."
             <9301120006.AA00591@One.NeoSoft.Com> 
Date: Fri, 15 Jan 93 22:47:39 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I am a latecomer, so forgive me if this is naive or old hat.

Nope. Your points are well made. I agree, mostly.

>Clearly the authors of WWW think news is important because WWW has 
>nice capabilities for accessing NNTP servers.  What, then, is the 
>motivation for HTTP as opposed to, say, using news with HTML article 
>bodies?

I thought NNTP could replace HTTP wholesale too. The irreconcilable
difference between a news article and a WWW node is that a WWW node
is editable. It may change over time. [I don't like this strateby,
bit that's what's in practice.]

Thus you have the question of versions, locking, the "home address"
of a document, etc.

Perhaps we could model WWW nodes as sets of articles -- a thread,
for example, so that each time you edit a node, you generate a
new ID.

The problem then is, what do you use for the name of the thing?
(for linking purposes, that is.)

Besides all that, WWW uses addresses -- article lodators, rather
than article identifiers. A WWW client has no /usr/spool/news
database to consult to get all its stuff. It can look at
ftp sites, gopher hosts, etc.

If URN's ever come to town and all the stuff on all those servers
share a namespace like the usenet message-id namespace, then
we may have a chance to play the game that way.

But in the mean time, there are several factors that motivate HTTP.

I certainly agree HTTP should look a _lot_ like NNTP.

Dan


From jim@wilbur.njit.edu  Sat Jan 16 19:13:16 1993
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29680; Sat, 16 Jan 93 19:13:16 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00693; Sat, 16 Jan 1993 19:28:32 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA08431; Sat, 16 Jan 93 13:28:30 -0500
Message-Id: <9301161828.AA08431@njitgw.njit.edu>
Received: by wilbur.njit.edu; Sat, 16 Jan 93 13:26:25 est
Date: Sat, 16 Jan 93 13:26:25 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: TONYJ@scs.slac.stanford.edu
Subject: INPUT tag (was: Searching)
Cc: al@eies2.njit.edu, cis!bieber@dxmint.cern.ch, murray@eies2.njit.edu,
        reddy@wilbur.njit.edu, roxanne@eies2.njit.edu, www-talk@nxoc01.cern.ch

Tony, I'll copy my reply to your query about the INPUT tag specs to www-talk.
We have an old spec for INPUT which was implimented pre web. It will be redone.
There is little agreement on the input tag, except that it will include
attributes for width, name, default, and help.  

With this limited definition, the client can impliment default search keys
and get proper resource for help.

We may create a default text to be used with the comment feature, which
will give all input/var field values in rfc822 style for mail based submission.

At issue are:

- handling typed inputs, including texts.
- applying inputs to search defaults. positional? named? override mech?
- applying inputs to go to defaults?
- getting data from users environment, e.g. users mail address.
- how the fields will be substituted into hrefs within the sgml context. scope?
- saving updated input values in bookmarks?
- communicating variables to activity scripts. (our "do" choice)

We need a mechanism to assign arbitrary attributes to anchores and documents.
These may share name space with input variables and VAR tagged data.

If the INPUT and VAR tags could assign an entity value that we can use as
&name; within hrefs, that would serve us well enough.  But, is that legal sgml?
It will require a second html parse of hrefs when they are selected.

Our expertise with sgml is limited-- we need a quick and dirty way to pass
data to activity scripts.  We are far from being able to make a final
proposal to the web community.  The minimal may be:

Tag	Attributes

INPUT	name, length, default, help
VAR	name, timeout

The default search would positionally concatonate inputs into keyword positions.
Documents containg VAR info would not be cached longer than timeout.

It seems that there is interest in fully interactive hypermedia within the web
context.  All proposals/feedback is welcomed.  Hopefully we can do it together.

jim

From timbl@www3.cern.ch  Mon Jan 18 13:49:27 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09213; Mon, 18 Jan 93 13:49:27 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13704; Mon, 18 Jan 1993 14:04:48 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02393; Mon, 18 Jan 93 14:03:52 +0100
Date: Mon, 18 Jan 93 14:03:52 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301181303.AA02393@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Re: Usenet news and WWW 
Reply-To: timbl@nxoc01.cern.ch


> 

> Date: Fri, 15 Jan 93 22:47:39 CST
> From: Dan Connolly <connolly@pixel.convex.com>
> 

> I thought NNTP could replace HTTP wholesale too. The irreconcilable
> difference between a news article and a WWW node is that a WWW node
> is editable. It may change over time. [I don't like this strateby,
> bit that's what's in practice.]


Irreconcilable?  There are a few other problems with using NNTP as  
the caching machine, the most basic being that there is no way of  
getting from the news article ID to its archive site.

> Thus you have the question of versions, locking, the "home address"
> of a document, etc.

Suppose we adopt a model of having names/addresses for BOTH the fixed  
article-like version AND for the logical live document.  [The version  
relationships can be expressed nicely with the LINK element and a  
link type in HTML -- do you wnat to move this into HTTP?]

> Perhaps we could model WWW nodes as sets of articles -- a thread,
> for example, so that each time you edit a node, you generate a
> new ID.

Yes exactly.

> The problem then is, what do you use for the name of the thing?
> (for linking purposes, that is.)

Well, you can use whichever you mean.  Sometimes I migth want to  
refer to a particular version, sometimes to the live document its  
genericity.

You need a server function to turn a link to an anchor in a specific  
version into an anchor in the live document. 

You need a server function to return a list of available versions of  
a live document. An exaple of this is an FYI which is live and an RFC  
which is dead. At any one time, an FYI is associated with a given  
RFC.  You can quote either. If you quote a paragraph number, then it  
is wise to quote the RFC. If you quote it as a generallt useful  
article to read, then quote the FYI number.

> Besides all that, WWW uses addresses -- article lodators, rather
> than article identifiers. A WWW client has no /usr/spool/news
> database to consult to get all its stuff. It can look at
> ftp sites, gopher hosts, etc.

This in only because we haven't got a good nameserver yet.  The Udi  
can become a name when a naming scheme exists.

> If URN's ever come to town and all the stuff on all those servers
> share a namespace like the usenet message-id namespace, then
> we may have a chance to play the game that way.

Yes. When we have an algorithm to dereference a URN.
 

> But in the mean time, there are several factors that motivate HTTP.
> 

> I certainly agree HTTP should look a _lot_ like NNTP.

So do I!  This why in the "Expires:" field for example,  I tries to  
use NNTP terminolgy but worry that we mustn't overload NNTP  
vocabulary with different meanings and so pervert it. We must be  
careful there is no semantic clash.  For example, when a news article  
Expires: then does it mean that the article itself vanishes or just  
the cached copy?  Some new articles really expire (the thingsthey  
talk about happen and have gone) and others are important history but  
still the caches throw them out.

> Dan

Tim 




From timbl@www3.cern.ch  Mon Jan 18 13:49:11 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09210; Mon, 18 Jan 93 13:49:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13681; Mon, 18 Jan 1993 14:04:31 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02388; Mon, 18 Jan 93 14:03:35 +0100
Date: Mon, 18 Jan 93 14:03:35 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301181303.AA02388@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Re: Usenet news and WWW
Reply-To: timbl@nxoc01.cern.ch


> Date: Tue, 12 Jan 93 0:06:00 CST
> From: Karl Lehenbauer <karl@one.neosoft.com>
>
> Many of the issues that people seem to be grappling with are  
already
> handled by news.

Yes ... but on the other hand there are things which are already  
handled by 

> For example, we are talking about caching nodes.  News has highly  
evolved
> caching capabilities -- I mean, caching is what it is all about --  
both for 

> TCP/IP and UUCP-based links.

I agree.  There are some snags with nes, though, for the ultimate  
retrieval tool. One trouble is, news caches documents very simply.  
The distribution scheme is a flood broadcast.  This is  OK for real  
news (shortlived articles), although many sites sag under the load of  
a lot of stuff they never read.  There are strict limit on what  
anyone posts because of the incredible worldwide total system load  
and disk space usage per message.  There is no well-defined algorithm  
for picking up archived news.  The message Id of an article is not  
enough: you need to know at least one of its newsgroups, its date,  
and be able to deduce the archibe node name and the organisation of  
the archive.

The conventions of posing FAQ lists and other "periodic postings" are  
in fact an abuse of the prototcol, and would be better served by a  
retrieval protocol rather than a broadcast protocol.

I know that the NNTP WG is looking at this sort of area, and maybe we  
should all get together.

In a nutshell, if you take all the data everywhere available online  
and put it into news, the news system will die. The use of newsgroup  
names and lists negotiated by system managers to control what  
documents are visible and cached where is too crude, too inflexible  
-- it doesn't scale well.  The caching has to be automatic.

All this said, obvioulsy news and retrieval are coming togather,  
which is why we have tried to look for analogies (see previous  
messages to this list) between news articles and grousp to hypertext  
documents and lists at all times.

> Someone mentioned the issue of caching and node names, apparently
> node names would have to be rewritten by the cacher or need to be  
made
> machine-independent in some way (?).

Don't worry about that.. I think you are referring to a discussion of  
complete vs. partial UILs.  Let's keep that apart...

> Article IDs are guaranteed unique
> and are server-independent.  The mechanism for translating article
> IDs to filenames is fast and pretty highly evolved.
> 

> Oh, ugh, "Supercedes:" doesn't cut it unless the article  
superceding
> the old one replaces its article ID, which would probably be Bad.

Certainly there is a  case for having the "current" version of an  
article and a given "fixed" version of an article each explicitly  
addressable. See  
http://info.cern.ch/hypertext/WWW/DesignIssues/Versioning.html
and linked things for an old discussion of these issues.

> Expiration dates can be set with "Expires:",

Exactly.  If you read the provisional HTTP2 spec there is
an explicit link to rfc850 under "Expires". (See
/hypertext/WWW/Protocols/HTTP/Object_Headers.html#z5)

>  and sites that 

> archive certain groups already do special things on  
"Archive-Name:".


Really?  Tell me more.  Is that in an RFC somewhere?
reference? Example?

> Plus news is already ultra-portable.
> 

> Is the brief-connection-per-document approach of HTTP still  
necessary
> when the data is widely replicated?

As I said above, the mass of data will not be widely replicated.
You don't want a copy of all the data in the phone book, you just  
want access to it, plus a cache (which you may currently keep in you  
diary).  When you're talking about all the phone book sin the world,  
this is still more the case!

So theer will in the end be a directory system not unlike X.500 which  
will allow you to find who has the nearest copy of a document you  
want, in a fairly sophisticated way. And you will pick up up from  
that place.  Then you will click again and pick up a reference from  
somewhere else.

An important feature of HTTP is that the document is returned with  
the minimum number of round trips. (Sorry for all the people who have  
heard this before).  Conection-oriented protocols like WAIS and NNTP  
have an introductory dialogue which slows down the first fetch by n*  
the distance/speed of light.

We probably need horses for courses -- there is nothing wrong with  
keeping a few protcols around optimised for different access  
profiles.

(BTW I think there is a need for a point-point low bandwidth protocol  
designed for beating the hell out of a phone line. One that will keep  
the phone line occpied in a very inteligent way with look-ahaed  
fetches of related documents and lists or parts of them so that a  
home user with a big disk can explore with optimised ease when he is  
paying by the minute. Another good student project)

> It would be painful to go reap all the references that
> point to expired articles, although if a user traversed to an  
expired
> article, perhaps it could be pulled off of tape or an NNTP  
superserver 

> somewhere.
> 

> Clearly the authors of WWW think news is important because WWW has 

> nice capabilities for accessing NNTP servers.  What, then, is the 

> motivation for HTTP as opposed to, say, using news with HTML  
article 

> bodies?

I hope I've showed that broadcast data can't cover the NIR world. But  
I also hope that we can allow the models to converge and create a  
supermodel which encompases them.  This is the end goal of HTTP2 or  
should we call it NNTP3.




From jackson@stsci.edu  Mon Jan 18 21:55:06 1993
Return-Path: <jackson@stsci.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12583; Mon, 18 Jan 93 21:55:06 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11760; Mon, 18 Jan 1993 22:10:26 +0100
Received: Mon, 18 Jan 93 16:10:24 EST from MARIAN.STSCI.EDU (kaos.stsci.edu) by stsci.edu (4.1)
Received: Mon, 18 Jan 93 16:10:21 EST by kaos.stsci.edu (4.1)
Date: Mon, 18 Jan 93 16:10:21 EST
From: Bob Jackson <jackson@stsci.edu>
Message-Id: <9301182110.AA20525@MARIAN.STSCI.EDU>
To: www-talk@nxoc01.cern.ch
Subject: Limited Search Ability
Reply-To: jackson@stsci.edu

In comparing the features provided by Gopher,
WAIS, and WWW, I noticed that neither WWW LineMode 
nor Viola WWW provides any search capabilities
within the text displayed.

Thus one is limited to scanning the text.  
For non-hypertext'd information, this is
a severe drawback.

Are there any plans to add this feature or is
it undesirable to do so?

From connolly@pixel.convex.com  Tue Jan 19 07:22:45 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17473; Tue, 19 Jan 93 07:22:45 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18250; Tue, 19 Jan 1993 07:38:01 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA05016; Tue, 19 Jan 93 00:37:05 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA19993; Tue, 19 Jan 93 00:37:02 -0600
Message-Id: <9301190637.AA19993@pixel.convex.com>
To: jim@wilbur.njit.edu (Jim Whitescarver)
Cc: TONYJ@scs.slac.stanford.edu, al@eies2.njit.edu, cis!bieber@dxmint.cern.ch,
        murray@eies2.njit.edu, reddy@wilbur.njit.edu, roxanne@eies2.njit.edu,
        www-talk@nxoc01.cern.ch
Subject: Re: INPUT tag (was: Searching) 
In-Reply-To: Your message of "Sat, 16 Jan 93 13:26:25 EST."
             <9301161828.AA08431@njitgw.njit.edu> 
Date: Tue, 19 Jan 93 00:37:01 CST
From: Dan Connolly <connolly@pixel.convex.com>


>We may create a default text to be used with the comment feature, which
>will give all input/var field values in rfc822 style for mail based submission
.
>
>At issue are:
>
>- handling typed inputs, including texts.
>- applying inputs to search defaults. positional? named? override mech?
>- applying inputs to go to defaults?
>- getting data from users environment, e.g. users mail address.
>- how the fields will be substituted into hrefs within the sgml context. scope
?
>- saving updated input values in bookmarks?
>- communicating variables to activity scripts. (our "do" choice)
>
>We need a mechanism to assign arbitrary attributes to anchores and documents.
>These may share name space with input variables and VAR tagged data.
>
>If the INPUT and VAR tags could assign an entity value that we can use as
>&name; within hrefs, that would serve us well enough.  But, is that legal sgml
?
>It will require a second html parse of hrefs when they are selected.
>
>Our expertise with sgml is limited-- we need a quick and dirty way to pass
>data to activity scripts.  We are far from being able to make a final
>proposal to the web community.  The minimal may be:
>
>Tag	Attributes
>
>INPUT	name, length, default, help
>VAR	name, timeout
>
>The default search would positionally concatonate inputs into keyword position
s.
>Documents containg VAR info would not be cached longer than timeout.
>
>It seems that there is interest in fully interactive hypermedia within the web
>context.  All proposals/feedback is welcomed.  Hopefully we can do it together

[I'm going over old mail, replying to stuff I missed. I confess I
can't make much of this sketch. But from what I understand...]

I need examples to help me think. Tell me if this example matches
your model:

The client C sends GET foo to server S. S returns:

<HEAD>
<TITLE>Search Template</TITLE>
<QUERYFORM base="medibase">diagnose condition where age is <recall name="age">
and symptoms includes (<if name="headache">headache</if>
<if name="blackouts">blackouts</if>)
</queryform>
</HEAD>
<BODY>
How old are you? <input name="age" type="number"
width="5" help="http:s/help/inputs#age">
<P>
Do you have any of the following symptoms?
<UL>
<li>headach? <input name="headache" type="boolean" width="3">
<li>blackouts? <input name="blackouts" type="boolean" width="3">
</ul>

The client displays the body of the document with a blank
for the age, and check-boxes for the symptoms, and a 
"query" button (similar to a "search" button in response
to <ISINDEX>). The user fills in the blanks and clicks
the query button. Then the client uses the QUERYFORM
to compose its query from the inputs. It sends

GET medibase HTRQ/1.0
Accept: text/plain

diagnose condition where age is 25
 and symptoms includes (blackouts).

to the server. The server performs the query on the medibase
database and returns some document.

Where does the volatile data (<VAR> stuff) come in?

This would require some additions to the DTD:

Inside HEAD, we'd allow QUERYFORM:
<!ELEMENT queryform - - (#PCDATA|recall|if|...)+>
<!ATTLIST queryform
	base CDATA #IMPLIED -- URL to search defaults to current doc --
	>
<!ELEMENT recall - O EMPTY>
<!ATTLIST recall
	name IDREF #required -- points to an input element -->
<!ELEMENT if - O (#PCDATA|if)+>
<!ATTLIST if
	name IDREF #required -- points to input element -->

Then inside BODY, we'd add the INPUT element:

<!ELEMENT input - O EMPTY>
<!ATTLIST input
	NAME ID #REQUIRED
	WIDTH NUMBER #IMPLIED
	DEFAULT CDATA #IMPLIED
	HELP CDATA #IMPLIED -- url of help info --
	>

This would require changes to both the server and the client,
but I don't see any way around that.

It's not a major change to HTML -- just a few more elements.
The way I suggest you associate input variables with things
in the query is through the ID/IDREF mechanism as above.

Does this jive at all with what you're thinking?

Dan


From dsr@hplb.hpl.hp.com  Tue Jan 19 11:58:23 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18806; Tue, 19 Jan 93 11:58:23 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23318; Tue, 19 Jan 1993 12:13:43 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Jan 93 11:10:20 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA03925; Tue, 19 Jan 93 11:14:56 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301191114.AA03925@manuel.hpl.hp.com>
Subject: HTML and Lists
To: www-talk@nxoc01.cern.ch
Date: Tue, 19 Jan 93 11:14:54 GMT
Mailer: Elm [revision: 66.25]

DL, UL and OL Lists
-------------------

Can we please avoid too tight a definition:

(from From: Dan Connolly  Thu, 14 Jan 93 to  www-talk)

> Can we do the following instead of using paragraphs in DL?
> 
> <DL>
> <DT>large
> <DT>big
> <DD>Large and big are synonyms.
> <DD>They share a definition.
> <DD>This is the third paragraph of explanation about big
> and large things.
> </DL>
> 
> It appears that the linemode browser generally groks. Thus, let's
> not mess with P's in DL's. (P's in UL's are messy enough to leave
> out too, I guess.)

I support:

    o   DD terms can include <P> breaks

    o   LI terms can include <P> breaks for UL and OL lists

The use of <P> in lists is both natural and easy to implement, and I for one
would find the repeated DD's awkward to deal with as well as screwing up the
natural semantics of a one to one relationship between DT and DD text.

    o   DT terms can be arbitrarily long and are wrapped onto the line below

This occasionally happens, e.g. when people place long anchors as DT terms.
It was also reasonably simple to implement.

It might be an improvement to emulate the approach used by Latex as in:

\begin{description}
    \item[TERMS ARE IN A BIG FONT]
        while their defintions follow in the normal font
        and wrap round with a margin indent.
\end{description}

giving:

  TERMS ARE IN A BIG FONT while their definitions follow in the normal font
    and wrap round with a margin indent.

versus the HTML guidelines which suggest:

  TERMS ARE IN A BIG FONT       while their defintions follow in the normal
                                font and wrap round with a margin indent.

The Latex approach allows terms to be as long as you like, and avoids the
issue of what to do when terms collide with the definition text. Perhaps
the HTML guidelines should leave this issue open ...

I would further like to have the freedom to embed lists, e.g. OL in UL and
vice versa, but allowing only one level of embedding, e.g.

<UL>
    <LI>This is a simple item.
    <LI>While this one requires some amplification:
        <OL>
            <LI>first point
            <LI>second point
            <LI>third point
        </OL>
    <LI>Another simple item
</UL>

My implementation of lists is fairly relaxed whilst being able to support
smooth scrolling of arbitrary length HTML documents. The processing demands
for this require the browser to be able parse backwards - working forwards
from the start of the document each time is MUCH TOO SLOW. This is not a
problem unless there is an HTML feature which forces you to go back
arbitrarily far before you can figure out the state (margins, font, active
tags etc.) from which to work forwards again to your current location.

The awkward features turn out to be:

    a)  ordered lists
    b)  multi-line DT terms

In practice neither of these has caused real problems since actual documents
keep their use to relatively short sections at a time. A way out of my
problems would be to embed state info in the buffer as processing attributes,
so far I have been able to provide good scrolling performance while keeping to
the vanilla text representation of HTML docs.

Cheers for now (the Pub is bekoning)

Dave Raggett

From dsr@hplb.hpl.hp.com  Tue Jan 19 16:43:10 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21788; Tue, 19 Jan 93 16:43:10 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00276; Tue, 19 Jan 1993 16:58:24 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Jan 93 15:55:00 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA05466; Tue, 19 Jan 93 15:59:36 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301191559.AA05466@manuel.hpl.hp.com>
Subject: QueryForms and Input tag
To: www-talk@nxoc01.cern.ch
Date: Tue, 19 Jan 93 15:59:34 GMT
Mailer: Elm [revision: 66.25]

Dan, I have some further suggestions for <queryform> which would greatly
broaden the opportunities for html interfaces to databases.

Let me know if you want me to see how these additions can be formalised
within your DTD, as I know you are being kept rather busy.

--------------

(in: Dan Connolly Tue, 19 Jan 93 Re: INPUT tag - was: Searching)

    The client C sends GET foo to server S. S returns:

    <HEAD>
      <TITLE>Search Template</TITLE>
      <QUERYFORM base="medibase">diagnose condition where age is
        <recall name="age">and symptoms includes (<if name="headache">
        headache</if><if name="blackouts">blackouts</if>)
      </QUERYFORM>
    </HEAD>
    <BODY>
      How old are you? <input name="age" type="number"
      width="5" help="http:s/help/inputs#age">
      <P>
      Do you have any of the following symptoms?
      <UL>
        <LI>headache? <input name="headache" type="boolean" width="3">
        <LI>blackouts? <input name="blackouts" type="boolean" width="3">
      </UL>

I like the idea, and am glad to see people are now taking an interest in html
and forms. Study of related projects suggests you need several things:

A variety of input fields:

    o   checkbox (boolean)
    o   text field
    o   numeric field (integer and floating point)
    o   radio-button groups
    o   one-from-many menu
    o   n-from-m menu

Summarising what you suggest above:

    <input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH] [help=HELPUDI]>

    FIELDNAME is a unique identifier for this form
    FIELDTYPE ::= "boolean" | "text" | "integer" | "float"

    The [ ] brackets denote optional attributes.
    
The width can be optional, since the browser can support sideways scrolling
of the input field when the entry exceeds the current display width.

Multiple choice items need a richer structure, e.g.

    <select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
        <choice>item 1
        <choice>item 2
        <choice>item 3
    </select>

    CHOICETYPE ::= "radio" | "single" | "multiple"

The choice initially shown is given by the value attribute for the <select>
token, defaulting to the first choice. The value returned is the item text
unless a "value" attribute is defined for that <choice>.

    <choice value=VALUETEXT>

I think that <a> tags should be permissible for <choice> text so that you can
provide further explanations upon request for each choice. If there isn't a
value attribute then the displayable text for the anchor would form part of
that choice in the obvious manner.

It is also useful to distinguish form decorations from output fields. I think
this can be adequately handled using the existing emphasis tags though.

How will the <queryform> tag take over from the <ISINDEX> mechanism? Right
now, the browser provides an input field and search button, but I assume that
in future, searchable documents will use the queryform approach instead.

Forms generally involve additional ideas:

    a)  expressions and queries for output fields

    b)  edits (constraints) on input field values

    c)  dependencies between fields

These can all be handled by the server, albeit with a performance penalty as
perceived by the user.

It is important to be able to show the current values as currently being in
error (along with an explanation). For example you could have a form for
configuring a computer system, which gives you choices for the number of hard
and soft drives:

   ---------------------------------------------------------------------------
       *  Fixed Drive(s): [2 x 512 Gb disk]
       *  Soft Drive(s):  [1 x 1.44 Mb 3.5" floppy]

   (*) Error: you are only allowed a combined total of 2 fixed and soft drives
   ---------------------------------------------------------------------------

So we need to provide attributes to:

    a)  signify that the current choice is in error in some way
    b)  that a given choice is not currently permissible (grayed out)

This can be done with two attributes (both default to "yes"):

    ok="yes" | "no"             ;;  for <input> and <select>
    enabled="yes" | "no"        ;;  for <choice>


Best wishes

Dave Raggett

From timbl@www3.cern.ch  Tue Jan 19 18:05:14 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22951; Tue, 19 Jan 93 18:05:14 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12549; Tue, 19 Jan 1993 18:20:36 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04605; Tue, 19 Jan 93 18:19:38 +0100
Date: Tue, 19 Jan 93 18:19:38 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301191719.AA04605@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HTML and Lists
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> (from From: Dan Connolly  Thu, 14 Jan 93 to  www-talk)
>
> Can we do the following instead of using paragraphs in DL?
> 

> <DL>
> <DT>large
> <DT>big
> <DD>Large and big are synonyms.
> <DD>They share a definition.
> <DD>This is the third paragraph of explanation about big
> and large things.
> </DL>
> 

> It appears that the linemode browser generally groks. Thus, let's
> not mess with P's in DL's. (P's in UL's are messy enough to leave
> out too, I guess.)

I don't like this as it is very much at variance with what DL has  
meant up till now.  The tags came from an IBM DTD which shares them I  
thought with eth AAP DTD. I think we should leave them be, as they  
were originally designed allowing pairs of <dt> <dd> but <p> within  
the <DD>. I must admit the NeXT browser can only produce a void  
"term" to make a new paragraph at the moment.

From dave's message:
| I support:
| 

|     o   DD terms can include <P> breaks
| 

|     o   LI terms can include <P> breaks for UL and OL lists

I agree

|     o   DT terms can be arbitrarily long and are wrapped onto the  
line below

You have to allow anything (almost) to be arbitrarily long as things  
will be egnerated automatically from other things, and arbitrary  
limits are then a pain.
 

| It might be an improvement to emulate the approach used by Latex as  
in:
...
|   TERMS ARE IN A BIG FONT while their definitions follow in the  
normal font
|     and wrap round with a margin indent.
| 

| versus the HTML guidelines which suggest:
| 

|   TERMS ARE IN A BIG FONT       while their defintions follow in  
the normal
|                                 font and wrap round with a margin  
indent.


This is just a preferance of the reader and the client app writer.


| I would further like to have the freedom to embed lists, e.g. OL in  
UL and
| vice versa, but allowing only one level of embedding, e.g.

I think we should stick to a non-nested structure for HTML and get it  
registered as a simple format.  Nested structured into HTML2 which we  
can all discuss when HTML is registered with IANA. Reasonable?


| My implementation of lists is fairly relaxed whilst being able to  
support
| smooth scrolling of arbitrary length HTML documents. The processing  
demands
| for this require the browser to be able parse backwards -

This could be regarded as a weird way of doing things though it  
doesn't use any memeory at all I see. Most people would I think just  
store the lot.

 

| Cheers for now (the Pub is bekoning)

A'roight fer some, mate..  ;-)

| Dave Raggett

Tim Berners-Lee

From connolly@pixel.convex.com  Wed Jan 20 09:46:28 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05596; Wed, 20 Jan 93 09:46:28 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27475; Wed, 20 Jan 1993 10:01:50 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA11467; Wed, 20 Jan 93 03:01:43 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA11039; Wed, 20 Jan 93 03:01:38 -0600
Message-Id: <9301200901.AA11039@pixel.convex.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: QueryForms and Input tag 
In-Reply-To: Your message of "Tue, 19 Jan 93 15:59:34 GMT."
             <9301191559.AA05466@manuel.hpl.hp.com> 
Date: Wed, 20 Jan 93 03:01:36 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I like the idea, and am glad to see people are now taking an interest in html
>and forms.

Does this mean my wag at an example does jive with your ideas? I'm
still not clear... especially on the protocol.

>Summarising what you suggest above:
>
>    <input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH] [help=HELPUDI]>
>
>    FIELDNAME is a unique identifier for this form
>    FIELDTYPE ::= "boolean" | "text" | "integer" | "float"
>
>    The [ ] brackets denote optional attributes.

Why not let's talk SGML, while we're at it? It's not so tough:

<!ENTITY % url "CDATA" -- this is kind of a DTD macro >
<!ELEMENT input - O EMPTY>
<!ATTLIST input
	name ID #REQUIRED
	type (boolean|text|integer|float) #REQUIRED
	help %url; #implied
	>

>Multiple choice items need a richer structure, e.g.
>
>    <select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
>        <choice>item 1
>        <choice>item 2
>        <choice>item 3
>    </select>
>
>    CHOICETYPE ::= "radio" | "single" | "multiple"

<!ELEMENT select - - (choice+)>
<!ATTLIST select
	name ID #REQUIRED
	type (radio|single|multiple) #REQUIRED
	value IDREF #IMPLIED -- defaults to first choice --
	help %url; #IMPLIED
	>
<!ELEMENT choice - - (%hypertext)+ -- see HTML DTD: text with A tags -->
<!ATTLIST choice
	id ID #IMPLIED -- select's value attribute points here --
	value CDATA #IMPLIED -- defaults to element content --
	>

>It is also useful to distinguish form decorations from output fields. I think
>this can be adequately handled using the existing emphasis tags though.

I don't get it; what's an output field?

>How will the <queryform> tag take over from the <ISINDEX> mechanism? Right
>now, the browser provides an input field and search button, but I assume that
>in future, searchable documents will use the queryform approach instead.
>
>Forms generally involve additional ideas:
>
>    a)  expressions and queries for output fields
>
>    b)  edits (constraints) on input field values
>
>    c)  dependencies between fields
>
>These can all be handled by the server, albeit with a performance penalty as
>perceived by the user.

Whoa! You mean there's a round trip every time the user enters a field?
This implies a stateful connection between the client and server.

This isn't the model I had in mind at all! I thought it went:
	* server sends whole form
	* user interacts with client only to fill out form
	* user instructs client to send completed form to server
	* client translates user inputs using <QUERYFORM> element
	  and sends results to server in HTRQ data
	* server processes query.

Dan


From dsr@hplb.hpl.hp.com  Wed Jan 20 12:55:26 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06827; Wed, 20 Jan 93 12:55:26 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09090; Wed, 20 Jan 1993 13:10:47 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 20 Jan 93 12:07:22 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA14755; Wed, 20 Jan 93 12:12:00 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301201212.AA14755@manuel.hpl.hp.com>
Subject: Re Re QueryForms and Input tag 
To: www-talk@nxoc01.cern.ch
Date: Wed, 20 Jan 93 12:11:58 GMT
Mailer: Elm [revision: 66.25]

Thanks Dan for your swift response. I hope the following clarifies my points:

> Why not let's talk SGML, while we're at it? It's not so tough:

You're on!

-------------------------------------------------------

<!-- The following defines the <input> tag with the attributes:

    name    (required)
        unique name used to identify field to server

    type    (required)
        indicates type of input value (boolean, text, integer, float)

    width   (optional, defaults to 20)
        width for field in terms of average char width
        browsers should allow users to type up to this number of chars
        and no more (except for dealing with control keys e.g. backspace)

    value   (optional, defaults to null or "")
        initial value to display in the input field

    ok      (optional, defaults to yes)
        when no, signifies that the current value is in error.

    enabled (optional, default to yes)
        when no, prevents user from changing this field's value

    help    (optional, default provided by application)
        a URL which would provide explanatory information for this field
-->

<!ENTITY % url "CDATA" -- this is kind of a DTD macro >
<!ELEMENT input - O EMPTY>
<!ATTLIST input
    name ID #REQUIRED
    type (boolean|text|integer|float) #REQUIRED
    width NUMBER "20"
    value CDATA ""
    ok (yes|no) "yes"
    enabled (yes|no) "yes"
    help %url; #IMPLIED
>

<!-- The following defines the <select> tag: -->

<!ENTITY SELECT - - (CHOICE)*>

<!ATTLIST select
    name ID #REQUIRED
    type (radio|single|multiple) #REQUIRED
    value PCDATA ""
    ok (yes|no) "yes"
    enabled (yes|no) "yes"
    help %url; #IMPLIED    
>

<!-- The following defines the <choice> tag: -->

<!ENTITY % inline "EM | TT | STRONG | B | I | U |
                        CODE | SAMP | KBD | KEY | VAR | DFN | CITE " >

<!ENTITY % text - - "#PCDATA | %inline;">

<!ENTITY CHOICE - O (%text; | CHOICE)*>

<!ATTLIST choice
    value PCDATA "" #REQUIRED
    enabled (yes|no) "yes"
>

-------------------------------------------------------

>> These can all be handled by the server, albeit with a performance penalty as
>> perceived by the user.

> Whoa! You mean there's a round trip every time the user enters a field?
> This implies a stateful connection between the client and server.
>
> This isn't the model I had in mind at all! I thought it went:
>        * server sends whole form
>        * user interacts with client only to fill out form
>        * user instructs client to send completed form to server
>        * client translates user inputs using <QUERYFORM> element
>          and sends results to server in HTRQ data

Oops! crossed wires - I intended just what you say above. The performance
penalty as perceived by the user comes from having to send the complete form
to find out that s/he has mistyped one of the fields.

A smarter/more sophistocated system would include scripts as part of the
queryform document, which apply the constraints locally WITHOUT any network
delays.

BUT that seems too complex for us to put in HTML for now!

Note that work at ETSI (European Telecommunications Standards Institute) on
hypermedia/multimedia standards for ISDN sees scripts as an essential element
for multimedia, and smart documents. Their work is being driven by the
European telecomms companies plus a few multimedia specialist companies, and
seems obsessed with videotex, and complex ISO multilayed standards.

Mail me if you are interested in references to this work.

Best wishes,

Dave Raggett

From dsr@hplb.hpl.hp.com  Wed Jan 20 13:33:53 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07244; Wed, 20 Jan 93 13:33:53 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13568; Wed, 20 Jan 1993 13:49:15 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 20 Jan 93 12:45:48 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA14775; Wed, 20 Jan 93 12:50:26 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9301201250.AA14775@manuel.hpl.hp.com>
Subject: Re Re HTML and Lists
To: www-talk@nxoc01.cern.ch
Date: Wed, 20 Jan 93 12:50:25 GMT
Mailer: Elm [revision: 66.25]

Thanks Tim for clarifying the current ideas for DL etc.

>> I would further like to have the freedom to embed lists, e.g. OL in UL and
>> vice versa, but allowing only one level of embedding, e.g.

> I think we should stick to a non-nested structure for HTML and get it  
> registered as a simple format.  Nested structured into HTML2 which we  
> can all discuss when HTML is registered with IANA. Reasonable?

Sounds fine to me. By the way, can you explain the status of the HTML
registration with IANA, e.g. does it include Dan's new emphasis tags or not?
Where will the queryform tags go - into HRML or HTML2?

By the way I am trying to cross-compile my X11/Xlib browser for Windows 3.1 on
the PC. I have found a package which gives you TCP/IP for Windows, but the
catch is they (Distinct of Saratoga CA) want royalties for run-time licenses!

Do you know of any alternative s/w for TCP/IP for Windows which has a free
run-time license, so that we could distribute the browser as freeware?

------

>> My implementation of lists is fairly relaxed whilst being able to support
>> smooth scrolling of arbitrary length HTML documents. The processing demands
>> for this require the browser to be able parse backwards -

> This could be regarded as a weird way of doing things though it  
> doesn't use any memory at all I see. Most people would I think just  
> store the lot.

Some confusion seems in evidence here. My browser currently just stores the
plain text of the HTML document with no extra info. I have the following
program structure:

    DisplayDoc()
        ParseHTML()
            GetToken()
                { GetLiteral() or GetWord() }

    DisplayDoc()
       Refreshes screen for current document type and contents

    ParseHTML()
      This procedure performs one of 4 functions, depending on mode parameter

        EITHER work forwards until current line intersects the top of the
        window and update sgml state variables in the process. (mode=FORWARDS)

        OR work forwards until the current line includes the desired anchor
        and update sgml state variables in the process. (mode=SEARCH)

        OR work forards until a specified part of the buffer,
        but NOT updating the sgml vars  (mode=HEIGHT)

        OR display the formatted text in the window, but leave state vars
        unchanged (mode=DISPLAY)

      The sgml parser is the same for all these functions and shares the
      same code to reduce problems in maintaining muliples copies of the
      same basic algorithm.

      It would be desirable to have a general sgml parser, supplemented by
      the process rules for word wrap, and line breaks etc. For now, I have
      hard-coded the HTML subset and procedural interpretation.

    DeltaHTMLPosition(long h) -- used by scrolling mechanism
       Find the text line which intersects/starts from the top of the window
       Note that h is the new pixel offset for the top of the window itself,
       for which the current value is PixelOffset+nClipped.

       This procedure is really tricky when the new position is above the
       current one. The simple approach would always work forwards from
       the start of the document, but this would be real slow for scrolling
       around near the end of long documents. The approach taken here
       attempts to work locally in the document working backwards looking for
       cues to discover line break decisions and state changes, then parsing
       forwards in the normal manner to get to the current point, giving you
       the relative offset. You now change the current poition to the earlier
       point, and repeat until you have climbed back up to the desired point.
       Works a treat!

    GetToken()
       Reads an html token including newlines and words

    GetLiteral()
       Used in verbatim modes (e.g. PRE), treats text lines as single words

    GetWord()
       Used to non-verbatim mode to recognise html tags, newlines and words
       dealing as appropriate with character references

Any comments?

From timbl@www3.cern.ch  Wed Jan 20 18:01:56 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10167; Wed, 20 Jan 93 18:01:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24644; Wed, 20 Jan 1993 18:17:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05229; Wed, 20 Jan 93 18:16:21 +0100
Date: Wed, 20 Jan 93 18:16:21 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301201716.AA05229@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: QueryForms and Input tag 
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

A few unrelated points about this.

A. There is a whole standard, as yukky as SGML, on Electronic data  
Intercahnge, meaning forms and form submission.  I know no more
except it looks like fortran backwards with no spaces.
But it might be interesting for a set of featuire to be supported.

B. I see a need for the definition os two things, a form to be filled  
out 9containing field types and constraints), and a format for the  
return of the field values. The latter is a structure of typed values  
(parameters) plus a note of the method to be applied and the object  
to which it is to be appllied. (I can see several different forms  
providing the same structure, for example a simpler form with a lkot  
of default values, and a separate one in French, all targetted at the  
same object).

I don't think the form should contain a macro for generting a query  
in an arbitrary language. That is too open-ended a function. I think  
the server should be responsible for taking a structure of field  
values and applying it to an object.

I'd like to see this generalised. In HTTP2, an object may allow a  
large set of operations. For each operations, one ought to be able to  
retrieve a form for filling out the parameters. The guts of this form  
should be no less than a complete parameter definition for the  
method. Of couse a general method returns a structure of results as  
well (rather than always a document).

I  see the following scenario:

1.	user follows a link to an object, a flight description, say
2.	The flight object has in its HTTP2 Allowed: field the
	Method RESERVE. The client program doesn't understand this
	but sticks it in the menu.
3.	The users wants to reserve a seat, and pulls down "RESERVE"
	from the menu.
4.	The client asks the server for a [set of] form[s] for which
	describe the parameters to the RESERVE method. The user may
	have to pick one.
5.	The user fills in the form.  The methodname RESERVE and the
	uri of the object he is operating on are supplied by the
	client software.
6.	Parameters (structure of field contents) , methodname and
	object uri are sent off to the server.
7.	A document is returned with the results.

The important thing is that we bridge the gap between automatic and  
manual procedures. Obviously, the user will soon be making local  
macros to reserve sets of flights for himself and his friends. So the  
guts of what goes on must be machine-understandable, not just  
human-readable.

Currently HTTP2 returns a MIME document. A MIME document can be a set  
of objects each with a Content-Type,  but it is kinda heavy for an  
array of 3 integers!  At this point, ASN/1 would seem a better bet (a  
rare thing! ;-) Perhaps we can look at a multipart message and a data  
structure in the same way with generality.

[A problem with including a more compact representation as part of a  
MIME document is that MIME doesn't like encoding techniques to be  
applied which hide the internal types from a MIME gateway. Therefore,  
one might just have to say there was a black box MIME object like

	Content-Type: application/ASN-1
	Content-encoding: base64

Of course ASN/1 like SGML requires a reference to the DTD equivalent
for the (numeric in this case) tag values.  What a plethora of choice  
we have with SGML, ASN/1, RCC822... Perhaps we can write  
architectural forms for DTDs which produce ASN/1-equivalent  
definitions, which will then allow the DTD to define the ASN/1 and  
ASN/1 to become a natural alternative syntax for any conforming DTD.
[It could (is?) done now, but the architectural forms would allow a  
field which is in fact an integer to be sent as an ASn/1 integer  
rather than as a bit of text]

In fact of course the form itself in fact contains a specification of  
the type of the field value structure, so from the form one can  
generate the DTD and/or ASN/1 description for the reply ... silly me.
In fact one can imagine the output data coming in the same way, as a  
set of field values plus a set of forms which would allow its display  
in various languages etc.  The specification of a method required  
just giving the URIs of the infput and output forms.

At any rate, I think it is important to differentiate the set of  
values from the form.

Tim





From davis@dri.cornell.edu  Wed Jan 20 18:30:09 1993
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10430; Wed, 20 Jan 93 18:30:09 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28408; Wed, 20 Jan 1993 18:45:33 +0100
Received: by willow.tc.cornell.edu id AA23567
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 20 Jan 1993 12:45:02 -0500
Date: Wed, 20 Jan 1993 12:45:02 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199301201745.AA23567@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: EDI for forms?


I have been trying to track down information about EDI.
If someone can point me at something to read I will be
be glad to generate a summary for the www list.

At present I am too ignorant to take a position on whether
EDI would be useful for HTML, even if it does have awfl syntax


From jim@wilbur.njit.edu  Wed Jan 20 18:46:20 1993
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10607; Wed, 20 Jan 93 18:46:20 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00729; Wed, 20 Jan 1993 19:01:44 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA14292; Wed, 20 Jan 93 13:01:41 -0500
Message-Id: <9301201801.AA14292@njitgw.njit.edu>
Received: by wilbur.njit.edu; Wed, 20 Jan 93 12:59:38 est
Date: Wed, 20 Jan 93 12:59:38 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: connolly@pixel.convex.com
Subject: Re: INPUT tag (was: Searching)
Cc: TONYJ@scs.slac.stanford.edu, al@eies2.njit.edu, cis!bieber@dxmint.cern.ch,
        murray@eies2.njit.edu, reddy@wilbur.njit.edu, roxanne@eies2.njit.edu,
        www-talk@nxoc01.cern.ch

Thanks Dan.  I'll need to study your example a bit.  Specifically what I
had in mind was close to that, I think.
-----------------example-
How old are you? <input name="age" type="number"
width="5" help="http:s/help/inputs#age">
<P>
Do you have any of the following symptoms?
<UL>
<li>headach? <input name="headache" type="boolean" width="3" default="No">
<li>blackouts? <input name="blackouts" type="boolean" width="3" default="No">
</UL>
<P>
<a href="http:/eies2.njit.edu:1234/medsearch?&age;+&headache;+&blackouts;">
Click here to search</a>
------------------end example-
I think you did something similar...  Note that the search could would be
the same as the anchor in the example above.  In this case the search engine
would have to know about the keyword order meaning, but it would work with
http1 systems without "too" much work in existing browsers.

The only connection between <input> and <var></var> is that the name attribute
in each would define a value in the browsers context.  In the first iteration
we won't support the name attribute in either, we will simply use the whole
list of input values in search and do.  Later it will be important to mantain
the users namespace.

jim

From emv@garnet.msen.com  Wed Jan 20 21:49:34 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11864; Wed, 20 Jan 93 21:49:34 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18265; Wed, 20 Jan 1993 22:04:57 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nEmbW-001IDDC@garnet.msen.com>; Wed, 20 Jan 93 16:04 WET
Message-Id: <m0nEmbW-001IDDC@garnet.msen.com>
To: Jim Davis <davis@dri.cornell.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: EDI for forms? 
In-Reply-To: Your message of Wed, 20 Jan 93 12:45:02.
             <199301201745.AA23567@willow.tc.cornell.edu> 
Date: Wed, 20 Jan 93 16:04:40 EST
From: Edward Vielmetti <emv@msen.com>

  I have been trying to track down information about EDI.
  If someone can point me at something to read I will be
  be glad to generate a summary for the www list.
  
There is a mailing list, EDI-L, which is gatewayed into Usenet as
"bit.listserv.edi-l".  I suspect there are notebooks kept which you
could review.

Try
	listserv@uccvma.ucop.edu
with the usual set of Listserv commands to review the list.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


From jim@wilbur.njit.edu  Wed Jan 20 22:00:56 1993
Return-Path: <jim@wilbur.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11972; Wed, 20 Jan 93 22:00:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19098; Wed, 20 Jan 1993 22:16:17 +0100
Received: by njitgw.njit.edu (5.57/Ultrix3.0-C)
	id AA19306; Wed, 20 Jan 93 16:16:10 -0500
Message-Id: <9301202116.AA19306@njitgw.njit.edu>
Received: by wilbur.njit.edu; Wed, 20 Jan 93 16:14:06 est
Date: Wed, 20 Jan 93 16:14:06 est
From: jim@wilbur.njit.edu (Jim Whitescarver)
To: davis@dri.cornell.edu, www-talk@nxoc01.cern.ch
Subject: Re:  EDI for forms?

The last time I looked, EDI included BOTH SGML and ASN equivalent definitions.
It may be worthwhile to borrow some things from there, but I stopped following
the standards development there because it got too too too complicated (rich?).

The beauty of HTML is it's simplicity/ease of use.  I hope we keep it that
way.  Although a number of standards have addressed forms, I do not know
of any using SGML to define interactive interfaces as we are attempting.  We
are not concerned with how the form looks, so much, the client should have
freedom in that respect.  Our initial problem, defining input fields, may
benifit most from looking at GUI development tools and translating to SGML.

Sorry, I couldn't find the ISO numbers for EDI, it's been a while...

jim

p.s.  Shouldn't HTML2 include HyTime links?  HTML's relative references in 
anchors are much nicer than HyTime markups, but HyTime seems like the
natrual markup extension for full multi-media.  This seems to countradict
my plee to keep HTML simple, but one could always invoke a HyTime client
to follow a HyTime link.

From connolly@pixel.convex.com  Thu Jan 21 23:26:07 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22226; Thu, 21 Jan 93 23:26:07 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14802; Thu, 21 Jan 1993 23:41:33 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA03107; Thu, 21 Jan 93 16:41:43 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA24439; Thu, 21 Jan 93 16:40:55 -0600
Message-Id: <9301212240.AA24439@pixel.convex.com>
To: www-talk@nxoc01.cern.ch
Subject: thoughts on the future of HTML [long]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cut-here"
Date: Thu, 21 Jan 93 16:40:54 CST
From: Dan Connolly <connolly@pixel.convex.com>

--cut-here

HTML was designed to be simple. Folks are supposed to be
able to whack out HTML with a text editor -- no rocket
science required.

Also, you ought to be able to use MS/Word or the equivalent
to write your documents or to view HTML documents.

But it's also designed to be processed by machine -- lots
of machines all over the planet.

Enter SGML.

It seemed like the natural choice, so Tim implemented an
informal SGML parser in his WWW clients.

Nobody really knew the ins and outs of SGML, so information
providers who wanted to produce HTML automatically just
checked to be sure the public www client grokked.

Then other folks tried to write HTML parsers. We discovered
that there were a lot of issues that were not covered by
any spec other than the WWW source code.

Then I tried to use the sgmls parser to develop an HTML
to FrameMaker tool. I discovered that the WWW source code
conflicted with the SGML standard. Uh oh!

By now I think we all agree that we should actually use SGML
to specify the syntax and structure of HTML.

But I wonder: on whom rests the responsibility for validating
HTML documents? This is really an HTTP issue: is it part
of the protocol that the data stream is _valid_ HTML? Or
is it the client's responsibility to deal with errors?

I suggest that it should be the responsibility of the _server_
to produce valid HTML. Of course the client should be robust
in the face of errors. But I suggest that when a client and
a server differ on their interpretation of a document, the
client is at fault if the document is valid, and the server
is at fault if the document is not.

It's too late to introduce this scenario into HTTP v0.9. But
future servers should have the burden of producing valid documents.
This will add complexity to the server code: it can no longer
just grab the contents of any old .html file and ship it
out the port. But it could, for example, fix the markup errors
on the fly and write error messages to a log file.

If a server knows the structure of the document it sends,
it should be able to send the document using SGML, ASN/1,
MIME, or whatever transport mechanism we chose. This is the
real value of standardizing on SGML: the syntax is one
thing, but we don't even have to use it! We have a DTD
that tells, in a more abstract way, what the content of
the document is.

With that in mind, I suggest we make HTML2 more prescriptive
than HTML. It should match the way documents are structured
and processed more than the way they are typed in a text editor.

For example, the following document is legal, but it's a pain
to process:

--cut-here
Content-Type: text/x-html

<html>
Here's the first paragraph. It's at the out structural level.<P>

The is the <em>Second</em> paragraph.
<body>
Here's another paragraph.
<H1>Another one</h1>
The last paragraph.
</body>
</html>

--cut-here

Imagine you want to parse that document and answer queries
like: "show me the second paragraph of the document."

HTML isn't supposed to be too sophisticated, but it _is_
supposed to model typical word-processor documents fairly
well. A paragraph is a pretty fundamental chunk of information.
The definition of a paragraph in HTML is much more complex
than it need be.

Consider the following representation of essentially
the same document:

--cut-here
Content-Type: text/x-html

<html>
 <body>
  <A>Here's the first paragraph.</A>
  <a>The is the <em>Second</em> paragraph.</a>
  <a>Here's another paragraph.</a>
  <H1>Another one</h1>
  <a>The last paragraph.</a>
 </body>
</html>

--cut-here

The the elements that make up the content of the BODY are
all paragraphs. Wouldn't it be a lot easier to write
a formatter for the latter type of document?

The original HTML design was motivated by conventional use
of SGML, with shortrefs and other markup minimization features
to aid keyboarding of documents.

But Tim (wisely) didn't want to put those features in his
parser, so we ended up with a compromise: it's fairly
easy to keyboard, but it has virtually no structure.

so...

I suggest that future versions of HTML should have more structure.

How much structure? Enough. Enough to model whatever kinds of
document make a WWW node. About as much as a TeXinfo node, which
is pretty similar to a FrameMaker TextFlow, or a MS/Word section.
We should probably also model typical markup conventions of internet
mail and USENET news.

Then... the big step: hytime. I _really_ think we should look at
hytime architectural forms to model things like threads, webs,
hierarchies of documents, etc.

I think we could use HyTime mechanisms to form an abstraction
that models the structure of unix filesystems, message threads,
and other typical hypertext organizations on the internet.

This is how we should model "relative links." The unix ../../foo
syntax is fine as a model. But we should abstract the features from
that syntax, so that we can use the same model on VMS systems without
ad-hockery.

That syntax happens to work for most gopher holes too,
but that's cheating: the gopher "path" string is supposed to be opaque.
The URL spec says something about how servers that use hierarchical
databases should use the unix path syntax. [What a load of hooey!
Oh... Ahem... sorry.]

And the syntax of most WAIS URLs' has _two_ unix paths in it. What
do you do with that?

I really think HyTime links and locs are a good way to model all this.
The connection between HyTime and SGML is incidental. The only reason
to use SGML markup is to _interchange_ information between HyTime
applications (...or to talk about HyTime constructs in email, or any
of the other things that text is convenient for.)

Standardizing HTML was one thing: it's only used in the WWW community.
But standardizing the WWW addressing architecture is a much larger
venture. I hope eventually the various IETF groups etc. will realize
that the HyTime community has thought about formal mechanisms to
name and reference information a lot, and the product of their labors,
HyTime, may have some technical merit as well as the weight [and
overhead...] of an international standard.

Dan

p.s. I thought I subscribed to the cni-arch mailing list where URL
stuff was supposed to happen. I don't remember getting anything from
that list for a long time. Is there any URL discussion going on?

--cut-here--

From connolly@pixel.convex.com  Fri Jan 22 06:52:51 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24826; Fri, 22 Jan 93 06:52:51 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17869; Fri, 22 Jan 1993 07:08:18 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA12777; Fri, 22 Jan 93 00:08:15 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA05532; Thu, 21 Jan 93 18:31:50 -0600
Message-Id: <9301220031.AA05532@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: libHTML to date
Date: Thu, 21 Jan 93 18:31:49 CST
From: Dan Connolly <connolly@pixel.convex.com>

See:

ftp://info.cern.ch/pub/incoming/libHTML-930121.tar.Z

There's a lot of work left to be done, but the architecture
I've come up with looks quite workable. For example, you can
do and of these with the same basic mechanism:

% sgml_test HTML MIF <some_html_file >mif_equivalent

% sgml_test plaintext HTML <any_old_file >html_equivalent

% sgml_test plaintext MIF <any_old_file >mif_equivalent

I gotta go. It's a rush job, but I'd like folks to get a look
at the HMDoc architecture.


Besides... HTML to MIF is handy!
(and plaintext to HTML might be handy for servers...)

Dan


From gmk@pegasos.ccsr.uiuc.edu  Fri Jan 22 22:04:43 1993
Return-Path: <gmk@pegasos.ccsr.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01542; Fri, 22 Jan 93 22:04:43 MET
Received: from complex.ccsr.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04481; Fri, 22 Jan 1993 22:20:11 +0100
Received: from pegasos.ccsr.uiuc.edu  (pegasos.ccsr.uiuc.edu) by complex.ccsr.uiuc.edu with SMTP id AA27669
  (5.67a/IDA-1.5 for <www-talk@nxoc01.cern.ch>); Fri, 22 Jan 1993 15:19:19 -0600
Received: by  pegasos.ccsr.uiuc.edu  (NX5.67c/NeXT-2.0)
	id AA00539; Fri, 22 Jan 93 15:18:10 -0600
Date: Fri, 22 Jan 93 15:18:10 -0600
From: gmk@pegasos.ccsr.uiuc.edu (Gottfried Mayer-Kress)
Message-Id: <9301222118.AA00539@ pegasos.ccsr.uiuc.edu >
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Joseph Hardin<hardin@ncsa.uiuc.edu>
Subject: (This file must be converted with BinHex 4.0)
Cc: Rob McCool<robm@turtle.ncsa.uiuc.edu>, MailingLists@pegasos.ccsr.uiuc.edu

Eudora send attachments with the following message:
(This file must be converted with BinHex 4.0)

I only have stuffit, is there a conversion program?
I get the message: Not a StuffIt file
Can't read file header.

Can I edit the file so that it becomes readable?

Thanks,
---
Gottfried Mayer-Kress
Center for Complex Systems Research, Department of Physics
3025 Beckman Institute, 405 N Mathews, Urbana, Il 61801
gmk@pegasos.ccsr.uiuc.edu (NeXT-Mail)
gmk@goshawk.lanl.gov, gmk@santafe.edu 

(217)-244-5877 (voice/fax modem),x8371(fax), x1994 (msg)


From marca@wintermute.ncsa.uiuc.edu  Sat Jan 23 14:04:12 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05543; Sat, 23 Jan 93 14:04:12 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02974; Sat, 23 Jan 1993 14:19:43 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA04049
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 23 Jan 93 07:19:42 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA24212; Sat, 23 Jan 93 07:21:17 -0800
Date: Sat, 23 Jan 93 07:21:17 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301231521.AA24212@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: NCSA X Mosaic 0.5 released
X-Md4-Signature: 73d08d8c8e9930840fefb9989bfe91ac

By the power vested in me by nobody in particular, alpha/beta version
0.5 of NCSA's Motif-based networked information systems and World Wide
Web browser, X Mosaic, is hereby released:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/xmosaic-0.5.tar.Z

This release of X Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).

Binaries for these platforms are available on ftp.ncsa.uiuc.edu in
/Web/xmosaic/binaries-0.5.  More binaries will be supplied as I am
able to find other Motif-configured platforms to use (DEC MIPS
probably within the next half hour).

Although this is alpha/beta software, I'm looking more for feedback on
design and functionality than bug reports right now -- down the road
the bulk of the program will be rewritten in C++ anyway, so don't take
the current code too seriously.  But bug reports are welcome too.  New
releases will probably come out about every 7-14 days until 1.0
arrives.

A list of current and future capabilities of X Mosaic follows this
message.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


Current capabilities
....................

Motif interface.
Multiple toplevel windows.
Save/mail/print document (plaintext or HTML).
Document source- and URL-viewing windows.
History list per window with GUI interface.
Option for new window per document (TurboGopher interface).
On-the-fly font selection.
Many common document choices accessible via menubar.
Keyword search capability.
Hotlist capability -- keep list of interesting documents,
  add/remove items, list is persistent across sessions.
Smart handling of documents too big for single X window --
  virtual document pages via inlined hypertext.
Interruptable at any time via SIGUSR1 signal.
No config or resource file installation required; 
  self-contained executable.
Hypertext help.
Integration with NCSA Collage and NCSA DTM to broadcast documents 
  into real-time networked workgroup collaboration sessions.
Stable! :-)


Future capabilities
...................

Multimedia/MIME.
Asynchronous collaboration functionality.
  (annotations, references, revision control).
Hypermedia interface to scientific data.
Visual hyperweb/hierarchy layout and navigation.
3D/immersive interface.
???


From marca@wintermute.ncsa.uiuc.edu  Sun Jan 24 15:03:12 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11359; Sun, 24 Jan 93 15:03:12 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03497; Sun, 24 Jan 1993 15:18:45 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09379
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 24 Jan 93 08:18:43 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA01000; Sun, 24 Jan 93 08:20:18 -0800
Date: Sun, 24 Jan 93 08:20:18 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301241620.AA01000@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: &AElig;, &Aacute;, &Acirc;, etc.
X-Md4-Signature: e466d51879ae729780ff21efd3be4edb

Are the mnemonic representations of ISO Latin 1 characters (e.g. in
the subject or in
http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/930106/ISOlat1.html)
really necessary for HTML?

As far as I can see, the question translates to 'Is there anyone who's
going to be typing in these things by hand that can't type the numeric
references instead?' and 'Aren't HTML editors going to be used to
produce documents with these characters anyway, and can't editors use
the numeric representation just as easy as the mnemonic
representation?'

Marc


From timbl@www3.cern.ch  Mon Jan 25 10:26:08 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16694; Mon, 25 Jan 93 10:26:08 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11382; Mon, 25 Jan 1993 10:41:42 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01418; Mon, 25 Jan 93 10:39:52 +0100
Date: Mon, 25 Jan 93 10:39:52 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301250939.AA01418@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: &AElig;, &Aacute;, &Acirc;, etc.
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

(Re why use names not numbers)

Hmmmm.   Yes, I agree in principle but then maybe we should send  
stuff more compactly in ASN/1.  There are advantages to having it  
readable, or writable, by people but I see your point.

Is it difficult to put in?  Like any reason for leving the option  
out?

Tim

From timbl@www3.cern.ch  Mon Jan 25 10:27:28 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16704; Mon, 25 Jan 93 10:27:28 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11470; Mon, 25 Jan 1993 10:43:03 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01424; Mon, 25 Jan 93 10:41:13 +0100
Date: Mon, 25 Jan 93 10:41:13 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301250941.AA01424@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: &AElig;, &Aacute;, &Acirc;, etc.
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


BTW there is already a large collection of Gaelic in the CURIA   
project, on the web and using funny characters by name rather
than number.  It's much more current practice in SGML I think.


Tim

From timbl@www3.cern.ch  Mon Jan 25 17:44:14 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22627; Mon, 25 Jan 93 17:44:14 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16517; Mon, 25 Jan 1993 17:59:48 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01746; Mon, 25 Jan 93 17:57:59 +0100
Date: Mon, 25 Jan 93 17:57:59 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301251657.AA01746@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: NCSA X Mosaic 0.5 released
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


Marc,

Brilliant!  I have copied into the bin areas on our local workstation  
support server, and will advertise it here.  Having the thing  
self-contained in one file makes life a lot easier.

I have put copies of your files on:

ftp://info.cern.ch/pub/www/bin/sun4/xmosaic_0.5.Z
ftp://info.cern.ch/pub/www/bin/decstation/xmosaic_0.5.Z
ftp://info.cern.ch/pub/www/bin/rs6000/xmosaic_0.5.Z
ftp://info.cern.ch/pub/www/bin/sgi/xmosaic_0.5.Z
ftp://info.cern.ch/pub/www/src/xmosaic_0.5.tar.Z

for anyone who is closer to CERN than NCSA.

I append a few detailed comments on the program.

	Tim
__________________________________________________________________
Xmosaic has a lot of practical things which real uses want -- like  
mail and print and a bookmarks and stuff. Well done!

I like the quick change fonts, too, and the option of single or  
multiple window operating mode.

That said, it would also be nice to customise it easily (yes, I want  
to have my cake and eat it!).  So the ability to set the home page up  
system-wide with some sort of a .xmosaicrc file would be useful.
We'll have to make a covering script to fix 


I have a feeling that a menu option which sets the current document  
home (persistently) by writing out a ~/xxx.rc file is probably an  
easy way for users in arbitrary places to find out where to start.
"Set home here" or something.

From the system manager's point of view, a system-wide .rc would  
allow the home page to bet set up site wide without anyone having  
know about environment variables.  For one thing, easy though it is  
to pick CERN out from the document menu, when NCS is difficult to  
reach, one doesn't want the program to hang.  It migth also be useful  
to set a pointer to the root of a copy of your help tree.

In practice, of course, a full app defaults will probably be needed  
to cater for all tastes. If you are interested in my personal tastes,

- Local "experts" believe that non-serif fonts for titles and serifed  
fonts for the rest are easiest to read on paper at leat. Helvetica  
for headings and New century for text would appease some of the  
locals.

- The colours: I like having a distinctive colour for "internals"  
like UDIs and source --- but white on light grey is a little  
difficult for me to read.... perhaps a darker grey?
Similarly I would prefer the overall text contrast to be higher and  
the anchors a different color with less contrast.


Other little things ...

Search text prompt always available: should be greyed out onluess  
ISINDEX.  If document is searchable and not editable, this field  
should come up selected when the window is loaded, so i can just go  
ahead and type and hit return.

I got a crash when I mimimised the main window, brought it back up  
and then did a "reload". The error message was:-


asis01% X Error of failed request:  BadWindow (invalid Window  
parameter)
  Major opcode of failed request:  2 (X_ChangeWindowAttributes)
  Minor opcode of failed request:  0
  Resource id in failed request:  0x4c000e7
  Serial number of failed request:  26455
  Current serial number in output stream:  26689

This was running on a sun and displaying on HP.

I load a document and the free-format text disappears under the  
right-hand margin. I fiddle with the window size, returning it to  
what it was, and teh text flows nicely to fit.  Would have been good  
if it could have got it right first time.

I think you know about:

- Anchors which have no HREFs should not be highlighted
- Jump to anchor withing document doesn't work

Every new browser is sexier than the last.  There is a lot of  
cross-fertilisation going on, which is very good. KUTGW everyone...

From connolly@pixel.convex.com  Tue Jan 26 17:44:43 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10529; Tue, 26 Jan 93 17:44:43 MET
Received: from convex.convex.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07725; Tue, 26 Jan 1993 17:59:59 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA25893; Tue, 26 Jan 93 10:59:45 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA28397; Tue, 26 Jan 93 10:59:44 -0600
Message-Id: <9301261659.AA28397@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), www-talk@nxoc01.cern.ch
Subject: user preferences was: NCSA X Mosaic 0.5 released 
In-Reply-To: Your message of "Mon, 25 Jan 93 17:57:59 +0100."
             <9301251657.AA01746@www3.cern.ch> 
Date: Tue, 26 Jan 93 10:59:43 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Xmosaic has a lot of practical things which real uses want -- like  
>mail and print and a bookmarks and stuff. Well done!

Definitely. I haven't built it yet, but bookmarks are a MUST! I use
xgopher a lot in stead of midasWWW cuz with midsaWWW, I have to
edit my home page by hand to add bookmarks.


But Tim: about this user preferences stuff. I disagree with your
strategy:

>That said, it would also be nice to customise it easily (yes, I want  
>to have my cake and eat it!).  So the ability to set the home page up  
system-wide with some sort of a .xmosaicrc file would be useful.
>We'll have to make a covering script to fix 
>
>
>I have a feeling that a menu option which sets the current document  
>home (persistently) by writing out a ~/xxx.rc file is probably an  
>easy way for users in arbitrary places to find out where to start.
>"Set home here" or something.
>
>>From the system manager's point of view, a system-wide .rc would  
>allow the home page to bet set up site wide without anyone having  
>know about environment variables.  For one thing, easy though it is  
>to pick CERN out from the document menu, when NCS is difficult to  
>reach, one doesn't want the program to hang.  It migth also be useful  
>to set a pointer to the root of a copy of your help tree.

X application should use the X resource database to get user
preferences. Folks can build their X resource database from
system-wide app-defaults files, files in their home directory,
environment variables, command-line-args, etc.

Works good.

I've seen you write a couple times about having a user preference
system that worked the same on the NeXT, Mac, X boxes, etc.

Making them look the same from an API would be great.

But don't make users adapt to a new WWW scheme for doing user preferences.
NeXT folks should use the NeXT user preference database, just like all
they do for their other tools. Mac folks should find "Preferences..."
under the edit menu. X folks know how to muck with .Xdefaults and xrdb.
(though a friendlier UI to the x resource database is badly needed).

The unix dot-files scheme is passe, I think -- especially for distributed
applications. Don't require folks to use it. For example, with the
X resource database, I can load resources off host A into my X server,
then run midasWWW on host B and it will see my preferences.

Dan

From timbl@www3.cern.ch  Wed Jan 27 16:07:08 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18333; Wed, 27 Jan 93 16:07:08 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22209; Wed, 27 Jan 1993 16:22:47 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02807; Wed, 27 Jan 93 16:20:57 +0100
Date: Wed, 27 Jan 93 16:20:57 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301271520.AA02807@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: New release of unix server for WWW "httpd"
Reply-To: timbl@nxoc01.cern.ch



The 0.9b release of the basic WWW daemon (httpd) contains a few bug  
fixes, and the ability to browse directories.  Note that the 0.9a  
release was buggy and should not be used (Thanks to Jon Streets/FNAL  
and Peter Lister/Cranfield for pointing this out.)

The new release is available by anonymous FTP as usual on
host info.cern.ch, in /pub/www/src/WWDaemon_0.9b.tar.Z.
You also need /pub/www/src/WWWLibrary_1.0a.tar.Z.

New in this release:

 -	Directory browse: if a directory name is given,
 	it is returned as hypertext.  This is opional: it can
	be always enabled, always diabled, or enabled
	only for directories containing a file
	named ".www_browsable".
 

 -	README inclusion:  When a directory contains a
 	README file, the file may be included either linked
	to the list with all the other files, or may have its
	text embedded before or after the list.
	
By using these features, a WWW server can be set up to serve
existing trees containing for example plain text files with
very little effort.

The online documentation gives the new command line options
-dy -dn -ds -db -dt and -dr which control the directory browsing.

(The server has been tested on the NeXT.  Any bugs to me ASAP
please!)

	Tim Berners-Lee



__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web team leader           (NeXTMail is ok)	
CERN, CN Division                     Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From pflynn@curia.ucc.ie  Wed Jan 27 17:32:21 1993
Return-Path: <pflynn@curia.ucc.ie>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19144; Wed, 27 Jan 93 17:32:21 MET
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06857; Wed, 27 Jan 1993 17:47:59 +0100
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 2101; Wed, 27 Jan 93 17:46:56 SET
Received: from IRUCCIBM.BITNET (NJE origin MAILER@IRUCCIBM) by CEARN.CERN.CH (LMail V1.1b/1.7e) with BSMTP id 8072; Wed, 27 Jan 1993 17:46:56 +0100
Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id
 8896; Wed, 27 Jan 93 16:44:25 IST
Received: from curia.ucc.ie by IRUCCVAX.UCC.IE (PMDF #12095) id
 <01GU0QD0M034000MNN@IRUCCVAX.UCC.IE>; Wed, 27 Jan 1993 16:35 GMT
Received: by curia.ucc.ie (4.1/SMI-4.1) id AA10353; Wed, 27 Jan 93 16:33:38 GMT
Date: Wed, 27 Jan 93 16:33:38 GMT
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Getting searching to work
To: www-talk@nxoc01.cern.ch
Message-Id: <9301271633.AA10353@curia.ucc.ie>
X-Envelope-To: www-talk@info.cern.ch

How is it best to add a simple search facility to a httpd server?
Or, better put, if a user wends hir way into one of my html menus,
is there a simple addition I can make that will add a search capability?
What I'd like is something like:

<dl>
<dt><a name=dub href="dubliners.html">Dubliners<dd>by James Joyce
<dt><a name=ulysses href="ulysses.html">Ulysses<dd>by James Joyce
[etc]
<dt><a name=something href=somepointer>Search<dd>the above texts for
a name or keyword
</dl>

Can a href point to a script or binary which will pipe its output back
to httpd and return the user to the same menu? Can that script be as
simple as, say, "grep '$1' * >somewhere" ? Or (as we're using PAT),
something like "pat something; $1 >somewhere" and get httpd to pass
the contents of the "name" aatribute into the "something" argument?
Or do I need another piece of already-httpd-enmeshed software? What
are people using for the Bible search that is available thru WWW?

///Peter

From connolly@pixel.convex.com  Wed Jan 27 18:05:12 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19584; Wed, 27 Jan 93 18:05:12 MET
Received: from convex.convex.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11408; Wed, 27 Jan 1993 18:20:50 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA03768; Wed, 27 Jan 93 11:20:47 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA24102; Wed, 27 Jan 93 11:20:45 -0600
Message-Id: <9301271720.AA24102@pixel.convex.com>
To: pflynn@curia.ucc.ie (Peter Flynn)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Getting searching to work 
In-Reply-To: Your message of "Wed, 27 Jan 93 16:33:38 GMT."
             <9301271633.AA10353@curia.ucc.ie> 
Date: Wed, 27 Jan 93 11:20:45 CST
From: Dan Connolly <connolly@pixel.convex.com>


>How is it best to add a simple search facility to a httpd server?

This is supported functionality. See the user guide:
http://info.cern.ch/hypertext/WWW/Daemon/User/Guide.html

I just wanted to take the opportunity to point out once again
that the <ISINDEX> strategy for marking up searchable documents
is less than optimal.

Inline "search this anchor" elements are preferable, at least
to me.

This request shows that it's intuitive to at least one other person:
he just made a guess and picked the inline searchable-anchors
strategy:

>What I'd like is something like:
>
><dl>
><dt><a name=dub href="dubliners.html">Dubliners<dd>by James Joyce
><dt><a name=ulysses href="ulysses.html">Ulysses<dd>by James Joyce
>[etc]
><dt><a name=something href=somepointer>Search<dd>the above texts for
>a name or keyword
></dl>

Dan


From timbl@www3.cern.ch  Thu Jan 28 08:00:51 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25591; Thu, 28 Jan 93 08:00:51 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10947; Thu, 28 Jan 1993 08:16:31 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03115; Thu, 28 Jan 93 08:14:39 +0100
Date: Thu, 28 Jan 93 08:14:39 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301280714.AA03115@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re: Getting searching to work
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date: Wed, 27 Jan 93 16:33:38 GMT
>  From: pflynn@curia.ucc.ie (Peter Flynn)
>  

>  How is it best to add a simple search facility to a httpd server?
>  Or, better put, if a user wends hir way into one of my html menus,
>  is there a simple addition I can make that will add a search  
capability?

Not as simple as you'd like, I suspect.  The httpd daemon doesn't  
support a search directly.  What you can do is (hack httpd or) run  
another daemon which is completely written in sh or csh or perl (pick  
your favorite).  There are some examples on the web. Then you have
something like

  <dt><a name=something
 href="http://curia.ucc.ie:9000/keywordsearchsearch/joyce">
 Search<dd>the above texts for a name or keyword

When the user follows the link, the special server  on
port 9000 gets a
	GET /keywordsearchsearch/joyce
request, and returns a search panel document:

  <head>
    <isindex>
  </head>
  <body>
  Give keywords, or words from the title, to find books
  by James Joyce which match all keywords given.
  </body>

The <isindex> flag tells the www program that the document is a  
search panel and enables the FIND command. (On smarter browers it
enables the search text input field.)

When the user types a keyword, that same special server gets a
different request:

	GET /keywordsearch/joyce?portrait+young

Your script reads that from stdin and must write the result back to
stdout. Like

	#! /bin/csh
	request = ( `echo "$<" ) 

	'echo request[2] | sed -f request.sed ' | sed -f reply.sed
	
where request.sed is something like 

	s|^\([^/]*\)/\([^?]*\)?\(.*\)| pat -\1 -cat \2 \3|g
	s|+| |g

(I no nothing of pat, so that is all made up. Notice I used parts of  
the address of the serach panel to specify options to pat)  The  
output is formatted into a hypertext file, in the example by  
reply.sed
which has to generate a hypertext document with a valid reference
to the found documents with their addresses on your original
httpd server.

Which all is in fact simpler than it looks -- largely because the
thibng is just a program runnng from stdin to stdout which you
can test on a terminal.  When you run it under inetd (just like
httpd is run, but on port 9000) it is inetd which takes care of
attaching stdin and stdout to the client.

As pat sounds like a serious peice of retrieval machinery, it
would certainly be worth wrapping it up as a W3 server to make it
available on the web.

A couple of hints:  1. Put lots of parameters into the address
of the serach panels so that you can put pointers to all kinds
of different pat features if you needs them
2. In the search panel document which your port 9000 server script
generates, put a pointer to related serach panels, help pages etc.

>  What I'd like is something like:
>  

>  <dl>
>  <dt><a name=dub href="dubliners.html">Dubliners<dd>by James Joyce
>  <dt><a name=ulysses href="ulysses.html">Ulysses<dd>by James Joyce
>  [etc]
>  <dt><a name=something href=somepointer>Search<dd>the above texts  
for
>  a name or keyword
>  </dl>

This is basically what I have described.  When the guy follws the  
link, he gets back a micro-document which tells him about the search
he can do.  This is the WWW model. The Gopher model, which Dan  
Connolly prefers, is that he should immediately get prompted for
keywords with a default search panel. I'll discuss that in a separate  
message.

Tim


From timbl@www3.cern.ch  Thu Jan 28 08:09:10 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25604; Thu, 28 Jan 93 08:09:10 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11749; Thu, 28 Jan 1993 08:24:50 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03123; Thu, 28 Jan 93 08:22:58 +0100
Date: Thu, 28 Jan 93 08:22:58 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301280722.AA03123@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Addendum Re: Getting searching to work
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


Addendum:

Od course, if you hack the C code of httpd, then you can
make the original document immeditaly searchable:

<isindex>
<dl>
<dt><a name=dub href="dubliners.html">Dubliners<dd>by James Joyce
<dt><a name=ulysses href="ulysses.html">Ulysses<dd>by James Joyce
[etc]
<dt>You can give keywords to search the above texts.
</dl>

This involves no extra panels for the user, but involves the
httpd daemon being able to handle a request

	GET /document/list?portrait+of+the+artist

The place to sneak it in is in HTRetrieve.c, when the
"keywords" parameter to HTRetrieve(soc,doc,keywords) is not NULL.
The keywords parameter is a space-separated string.
(I talk of version 0.9b at least)

It is of course safer to have compiled servers than shell scripts
from the security point of view.  Keep any servers, scripts or
compiled, root-owned and writable only by root!

Tim

From timbl@www3.cern.ch  Thu Jan 28 08:54:48 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25743; Thu, 28 Jan 93 08:54:48 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16889; Thu, 28 Jan 1993 09:10:28 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03157; Thu, 28 Jan 93 09:08:35 +0100
Date: Thu, 28 Jan 93 09:08:35 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301280808.AA03157@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: Getting searching to work 
Cc: pflynn@curia.ucc.ie (Peter Flynn), www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



>  Date: Wed, 27 Jan 93 11:20:45 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>  

>  I just wanted to take the opportunity to point out once again
>  that the <ISINDEX> strategy for marking up searchable documents
>  is less than optimal.
>  

>  Inline "search this anchor" elements are preferable, at least
>  to me.


OK, Dan, I see you aren't going to give up on this one :-).  As
we want to be able to map Gopher modes effectively too, how about
using a link type:


<dl>
<dt><a name=dub href="dubliners.html">Dubliners<dd>by James Joyce
<dt><a name=ulysses href="ulysses.html">Ulysses<dd>by James Joyce
[etc]
<dt><a name=something REL=SEARCH href=somepointer>Search<dd>the above  
texts for
a name or keyword
</dl>

The "SEARCH" relationship is a presentation instruction a bit like  
"EMBED" or "PRESENT".  It means, "Don't just jump to this, search it  
immediately".   A nice thing about it is that if the browser doesn't
understand it, then it will still work, just not be presented in the
way the author had intended.

What do you think?

>  Dan

Tim

From pflynn@curia.ucc.ie  Thu Jan 28 11:08:30 1993
Return-Path: <pflynn@curia.ucc.ie>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26424; Thu, 28 Jan 93 11:08:30 MET
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03726; Thu, 28 Jan 1993 11:24:10 +0100
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 4326; Thu, 28 Jan 93 11:23:06 SET
Received: from IRUCCIBM.BITNET (NJE origin MAILER@IRUCCIBM) by CEARN.CERN.CH (LMail V1.1b/1.7e) with BSMTP id 4334; Thu, 28 Jan 1993 11:23:06 +0100
Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id
 1772; Thu, 28 Jan 93 10:21:11 IST
Received: from curia.ucc.ie by IRUCCVAX.UCC.IE (PMDF #12095) id
 <01GU1R4KQHTC000OLZ@IRUCCVAX.UCC.IE>; Thu, 28 Jan 1993 10:08 GMT
Received: by curia.ucc.ie (4.1/SMI-4.1) id AA16204; Thu, 28 Jan 93 10:06:37 GMT
Date: Thu, 28 Jan 93 10:06:37 GMT
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re: Getting searching to work
To: connolly@pixel.convex.com
Cc: www-talk@nxoc01.cern.ch
Message-Id: <9301281006.AA16204@curia.ucc.ie>
X-Envelope-To: www-talk@nxoc01.cern.ch, connolly@pixel.convex.com

>This is supported functionality. See the user guide:
>http://info.cern.ch/hypertext/WWW/Daemon/User/Guide.html

Eeek. Thanks you. Perhaps this file should be called Guide.RTFM

>I just wanted to take the opportunity to point out once again
>that the <ISINDEX> strategy for marking up searchable documents
>is less than optimal.

This is not apparent to me (OK, it's early in the morning :-)
In what way is it suboptimal?

>Inline "search this anchor" elements are preferable, at least
>to me.
>
>This request shows that it's intuitive to at least one other person:
>he just made a guess and picked the inline searchable-anchors
>strategy:

Flattery like this will get you a long way :-)

By "search this anchor" do you mean "search from here onwards to EOF"
or are you implying that the file should be marked up as <a name=anchor>
lots and lots of text, megabytes even, to which the user might want to
restrict the search</a> ?

///Peter


From timbl@www3.cern.ch  Thu Jan 28 15:09:13 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28412; Thu, 28 Jan 93 15:09:13 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01921; Thu, 28 Jan 1993 15:24:54 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03450; Thu, 28 Jan 93 15:23:01 +0100
Date: Thu, 28 Jan 93 15:23:01 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9301281423.AA03450@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: user preferences was: NCSA X Mosaic 0.5 released 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date: Tue, 26 Jan 93 10:59:43 CST
>  From: Dan Connolly <connolly@pixel.convex.com>
>  

...
>  But Tim: about this user preferences stuff. I disagree with your
>  strategy:
>  

...
>  X application should use the X resource database to get user
>  preferences. Folks can build their X resource database from
>  system-wide app-defaults files, files in their home directory,
>  environment variables, command-line-args, etc.
>  

>  Works good.
>  

>  I've seen you write a couple times about having a user preference
>  system that worked the same on the NeXT, Mac, X boxes, etc.
>  

>  Making them look the same from an API would be great.

We agree about that.

>  But don't make users adapt to a new WWW scheme for doing user  
preferences.
>  NeXT folks should use the NeXT user preference database, just like  
all
>  they do for their other tools. Mac folks should find  
"Preferences..."
>  under the edit menu. X folks know how to muck with .Xdefaults and  
xrdb.
>  (though a friendlier UI to the x resource database is badly  
needed).


Absolutely.  I didn't mean to advocate a and actual .rc file,
I totally agree that the mechanism should be the natural local one  
one in each environment. Like look and feel should also always be  
local.

Tim

From connolly@pixel.convex.com  Fri Jan 29 00:08:48 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03799; Fri, 29 Jan 93 00:08:48 MET
Received: from convex.convex.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12027; Fri, 29 Jan 1993 00:24:29 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA21605; Thu, 28 Jan 93 17:24:23 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA00475; Thu, 28 Jan 93 17:19:35 -0600
Message-Id: <9301282319.AA00475@pixel.convex.com>
To: pflynn@curia.ucc.ie (Peter Flynn)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Getting searching to work 
In-Reply-To: Your message of "Thu, 28 Jan 93 10:06:37 GMT."
             <9301281006.AA16204@curia.ucc.ie> 
Date: Thu, 28 Jan 93 17:19:35 CST
From: Dan Connolly <connolly@pixel.convex.com>


>>This is supported functionality. See the user guide:
>>http://info.cern.ch/hypertext/WWW/Daemon/User/Guide.html
>
>Eeek. Thanks you. Perhaps this file should be called Guide.RTFM

Ooops. My mistake. I got httpd confused with gopherd.
I don't think httpd supports searches after all.

Soryy.

Dan


From ccprl@xdm001.ccc.cranfield.ac.uk  Fri Jan 29 17:38:22 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10519; Fri, 29 Jan 93 17:38:22 MET
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20841; Fri, 29 Jan 1993 17:53:57 +0100
Received: by xdm001 
	id AA09759; Fri, 29 Jan 93 16:53:49 GMT
Received: by xdm039 (5.57/4.7) id AA19849; Fri, 29 Jan 93 16:53:45 GMT
Message-Id: <9301291653.AA19849@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: RTF translator... How long??
Date: Fri, 29 Jan 93 16:53:39 GMT
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

We have hypertext info in Microsoft RTF format, and my boss wants it
available on Unix... Her plan is to run Soft PC on our workstations,
which will be expensive and slow, but most of all inelegant.

I see placeholders in the httpd code for RTF, and documentation on the
web saying that this is being considered, but how long is it likely to
be before I can feed RTF to the web? Is anyone actively working on
this? If so, would you like an alpha/beta test site? If not, where can
I get an RTF format definition, so that I can have a go myself?

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From connolly@pixel.convex.com  Fri Jan 29 19:14:48 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11515; Fri, 29 Jan 93 19:14:48 MET
Received: from convex.convex.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02003; Fri, 29 Jan 1993 19:30:31 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA03857; Fri, 29 Jan 93 12:30:24 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA14018; Fri, 29 Jan 93 12:30:23 -0600
Message-Id: <9301291830.AA14018@pixel.convex.com>
To: "Peter Lister,
    Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: RTF translator... How long?? 
In-Reply-To: Your message of "Fri, 29 Jan 93 16:53:39 GMT."
             <9301291653.AA19849@xdm039> 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cut=here"
Date: Fri, 29 Jan 93 12:30:22 CST
From: Dan Connolly <connolly@pixel.convex.com>


--cut-here

>I see placeholders in the httpd code for RTF, and documentation on the
>web saying that this is being considered, but how long is it likely to
>be before I can feed RTF to the web? Is anyone actively working on
>this?

I have been, but I don't expect to be able to do much more work
on it.

> If so, would you like an alpha/beta test site? If not, where can
>I get an RTF format definition, so that I can have a go myself?

I wrote a Motif widget for displaying RTF stuff -- it probably
doesn't directly support the hypertext conventions you used in
your RTF documents, but you should be able to fix it somehow.

Most of the RTF parsing code was written by Paul DuBois. Ask
archie about the RTFstuff package.

Here's the source distribution for my widget:

--cut-here
Content-Type: message/external-body;
	access-type=ANON-FTP;
	site="export.lcs.mit.edu";
	directory="contrib";
	name="XcRichText-1.5.tar.Z";

Content-Type: application/x-tarZ; name="XcRichText-1.5.tar.Z"

--cut-here

As for RTF and WWW:

I'm working on an architecture for dealing with HTML documents
in various formats. There's a base HMDoc class, whose essential
methods are startTag, data, and endTag. I've written two parsers:

SGML_parseInstance -- parses an SGML instance, and calls the HMDoc's
	startTag, data, and endTag methods as the info is parsed.
Plaintext_parse -- parses plain text files. Calls the HMDoc's
	startTag method to start a PRE element, then calls the data
	method repeatedly to load the data, then calls the endTag
	method.

And I'ver written three HMDoc subclasses:

InCore -- builds a data structure to store all the information from
	the tags and data. You can call it's traverse method, and
	it will traverse the data structure and pass all the tags
	and data to another HMDoc.
HTMLwriter -- responds to startTag, endTag methods by writing SGML
	markup to a stream. Responds to data method by writing it
	to a stream, representing <, >, and & as character references.
MIFwriter -- responds to methods by writing a MIF representation
	of the document to a stream.

So, for example, you can use SGML_parseInstance to read an HTML
document into an InCore HMDoc, then use the InCore traverse method
to pass the data to a MIFwriter to write it in MIF format.
Or you could use Plaintext_parse and give it a MIFwriter, and convert
straight from plain text to MIF witout ever storing the document
in memory.

These modules are designed to drop into existing clients. For
example, the xmosaic client has a Save As... dialog box with
several format options. All you need to do is map the
format options to HMDoc subclasses. Then traverse the document,
calling the HMDoc's tag and data methods, and it will write
the document in the appropriate format.

The GridText module from the linemode browser could be turned
into another HMDoc subclass.

Also, it should be easy to write LaTeXwriter or RTFwriter subclasses.

To support reading RTF documents, I'd start with Paul Dubois'
RTF parsing stuff, and make it into a routine like SGML_parseInstance.
The routine would have to recognize the RTF equivalent of start
tags, end tags, and data.

If your RTF files have paragraph tags that match the HTML tags,
it's easy. If, on the other hand, your RTF files were written
without HTML in mind, you've got a more difficult task on your
hand.

You have two options: 1) try to zen some HTML structure out of the
info in the RTF file, or 2) treat the RTF file essentially as
a graphic, and use something like my RTF widget to display it.

Option 2 doesn't allow you to integrate hypertext in your RTF
documents with WWW, but it may be the easiest way to go.


Dan

--cut-here--


From marca@wintermute.ncsa.uiuc.edu  Sat Jan 30 06:15:16 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16932; Sat, 30 Jan 93 06:15:16 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24087; Sat, 30 Jan 1993 06:31:00 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA20139
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 29 Jan 93 23:30:58 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA17543; Fri, 29 Jan 93 23:32:31 -0800
Date: Fri, 29 Jan 93 23:32:31 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301300732.AA17543@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: X Mosaic 0.5 status report
X-Md4-Signature: 30a400cd060bcfb0e018f471a7915c89

Some people are having trouble running X Mosaic 0.5 on Suns running
X11R5.  The problem is apparently that we accidentally dynamically
linked in the X libraries but statically linked the Motif library, so
if you're running R5 on a Sun the Motif library is apparently being
thrown for a loop when it gets hooked up with the R5 libraries and
isn't expecting it.  In the future, all Sun X libraries will be
statically linked.

In the meantime, downgrade your Suns to X11R4 :-).

0.6 oughta be out real soon now; a list of things changed as of this
moment follows...

History window now shows both 'where you've been' and
  'where you can go'.
Previously visited nodes are colored differently, a la Midaswww;
  this global history is automatically persistent across sessions.
New resources for customization, including:
  Show URLs instead of Document Titles.
  Customize window per document feature.
  Optionally have pointer and focus warp to keyword entry field
    when you reach a searchable node.
  Optionally turn off global history mechanism.
Button2 can now activate anchors; forces a new window
  to open (as with Window Per Document feature).
Going from a document necessarily wider than the window
  (e.g. preformatted text) to a normal document will now
  get rid of the horizontal spacebar and reformat properly.
Addition of Whine option under Help.
Addition of Go To and Go To Local options under Navigate.
<listing> is now recognized.
Numeric character references (e.g. &#60;) are now handled.
Anchors without href's aren't colored anymore.
Memory leak in document reformatting nailed.
Layout glitches fixed.
Better help.
Other misc bugfixes and cleanups.

Cheers,
Marc


From marca@wintermute.ncsa.uiuc.edu  Sat Jan 30 08:08:33 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17213; Sat, 30 Jan 93 08:08:33 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05494; Sat, 30 Jan 1993 08:24:17 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA27909
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 30 Jan 93 01:24:13 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA18161; Sat, 30 Jan 93 01:25:49 -0800
Date: Sat, 30 Jan 93 01:25:49 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301300925.AA18161@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from A. User
X-Md4-Signature: 560352446d02b3ac2d794c3cde7bbc71

A. User of Mosaic sent the following:

------- Start of forwarded message -------
There seems to be a bug in how it handles some HTML, the following, from a
WAISgate response of a wais index of a mail log, doesn't print the anchor,
simply the 'score: ' line. You can click on the empty space as a hot spot
though.

<DT><A HREF=support/TEXT/629/1=vail%3A210;2=/usr/local/aaii/wais/support;3=40962%2041591%20/usr/users/ash/adm/support;4=vail%3A210;5=/usr/local/aaii/wais/support;6=40962%2041591%20/usr/users/ash/adm/support;7=%00;> <anand@whi Re: Turbo printer daemon</A><DD>Score:  948, lines:  19
------- End of forwarded message -------

Looks to me like this (the un-escaped '<') is the fault of the
WWW/WAIS gateway?  I've tested this with the linemode browser,
Violawww, and Midaswww and all of them choke too -- and quite
reasonably, I'd say.  (Although, Dan, I haven't tried libHTML on this
yet.)

Marc


From connolly@pixel.convex.com  Sat Jan 30 17:26:50 1993
Return-Path: <connolly@pixel.convex.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18524; Sat, 30 Jan 93 17:26:50 MET
Received: from convex.convex.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17267; Sat, 30 Jan 1993 17:41:35 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
	id AA13495; Sat, 30 Jan 93 10:40:08 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
	id AA24566; Sat, 30 Jan 93 10:40:05 -0600
Message-Id: <9301301640.AA24566@pixel.convex.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded message from A. User 
In-Reply-To: Your message of "Sat, 30 Jan 93 01:25:49 PST."
             <9301300925.AA18161@wintermute.ncsa.uiuc.edu> 
Date: Sat, 30 Jan 93 10:40:04 CST
From: Dan Connolly <connolly@pixel.convex.com>


>A. User of Mosaic sent the following:
>
><DT><A HREF=support/TEXT/629/1=vail%3A210;2=/usr/local/aaii/wais/support;3=409
62%2041591%20/usr/users/ash/adm/support;4=vail%3A210;5=/usr/local/aaii/wais/sup
port;6=40962%2041591%20/usr/users/ash/adm/support;7=%00;> <anand@whi Re: Turbo 
printer daemon</A><DD>Score:  948, lines:  19
>
>Looks to me like this (the un-escaped '<') is the fault of the
>WWW/WAIS gateway?

Absolutely. The HREF isn't quoted, and the < in <and needs to
be escaped so it won't be treated as markup.

Dan


From marca@wintermute.ncsa.uiuc.edu  Sat Jan 30 23:38:56 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20616; Sat, 30 Jan 93 23:38:56 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11296; Sat, 30 Jan 1993 23:54:42 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05872
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 30 Jan 93 16:54:40 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA20060; Sat, 30 Jan 93 16:56:16 -0800
Date: Sat, 30 Jan 93 16:56:16 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301310056.AA20060@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: solicitation for widgets
X-Md4-Signature: 9e9dd38a8c93ebb35e92c95c6f976f3e

Fellow WWW'ers,

If all goes as planned, X Mosaic will be expanded in the
not-too-distant future to be able to handle heterogeneous MIME
documents.  This capability will probably take the form of a MIME
"master widget" that will create child widgets to display various data
elements -- text, GIF images, JPEG images, MPEG movies, and so on.
The child widgets will in turn be able to have active elements of
their own...  a widget represent audio/basic will have a 'play'
button, a readout giving the duration of the audio clip, and so on.
Widgets representing unknown types will have controls to allow saving
the data to a local file or possibly passing it to an external
program.

So, we're going to need widgets to display as many different common
datatypes as possible -- for example, we plan to use Dan Connolly's
RTF widget for RTF data elements -- and we'd like to solicit pointers
to or donations of widgets that can display common data formats.  (Of
course, we're distributing full source for X Mosaic and its respective
parts every step of the way.)

The more widgets we don't have to write ourselves, the faster we can
get multimedia X Mosaic out the door and the more capabilities it can
have... so pointers or donations will be most appreciated.

Marc


From marca@wintermute.ncsa.uiuc.edu  Sun Jan 31 11:44:25 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22951; Sun, 31 Jan 93 11:44:25 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26909; Sun, 31 Jan 1993 12:00:11 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09585
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 31 Jan 93 05:00:10 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA26947; Sun, 31 Jan 93 05:01:45 -0800
Date: Sun, 31 Jan 93 05:01:45 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9301311301.AA26947@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: NCSA X Mosaic 0.6 released
X-Md4-Signature: 1fa066f10f5c445903b4082e69c821f8

Shazam and kaboom -- alpha/beta version 0.6 of NCSA's Motif-based
networked information systems and World Wide Web browser, X Mosaic, is
hereby released:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/xmosaic-0.6.tar.Z

This release of X Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).

Binaries for these platforms (and DEC Ultrix) are available:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/binaries-0.6

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working binaries
are welcome.)  The 0.6 Sun binary should work on systems running X11R5
(unlike the 0.5 binary); please let me know ASAP if this isn't so.

Changes since 0.5 are:

History window now shows both 'where you've been' and
  'where you can go'.
Previously visited nodes are colored differently, a la Midaswww;
  this global history is automatically persistent across sessions.
New resources for customization, including:
  Show URLs instead of Document Titles.
  Customize window per document feature.
  Optionally have pointer and focus warp to keyword entry field
    when you reach a searchable node.
  Optionally turn off global history mechanism.
  Specify home document (overridden by WWW_HOME env variable).
Button2 can now activate anchors; forces a new window
  to open (as with Window Per Document feature).
Going from a document necessarily wider than the window
  (e.g. preformatted text) to a normal document will now
  get rid of the horizontal scrollbar and reformat properly.
Scrollbar and document page state is maintained so stepping
  through the history list lands you were last in each document.
Addition of Whine option under Help.
Addition of Go To and Go To Local options under Navigate.
Addition of outlet to Ghostview for PostScript documents
  (this is a hack but it's a slick demo feature).
<listing> is now recognized.
Tabs now work in preformatted/plaintext regions.
Numeric character references are now handled.
Anchors without href's aren't colored anymore.
Search Keyword field's sensitivity is managed correctly now.
SIGINT now interrupts network connections too
  (so you can hit Ctrl-C in shell window at any time).
Memory leak in document reformatting nailed.
Cloning a window is now intelligent and doesn't do a network
  reload; also, window size is maintained.
Layout glitches fixed.
Text selection glitches fixed.
Other misc bugfixes and cleanups.
Better help.

Although this is alpha/beta software, I'm looking more for feedback on
design and functionality than bug reports right now -- down the road
the bulk of the program will be rewritten in C++ anyway, so don't take
the current code too seriously.  But bug reports are welcome too.  New
releases will probably come out about every 7-14 days until 1.0
arrives.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From falken@helios.tnt.uni-hannover.dbp.de  Mon Feb  1 17:27:43 1993
Return-Path: <falken@helios.tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02184; Mon, 1 Feb 93 17:27:43 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04905; Mon, 1 Feb 1993 17:43:31 +0100
Date:  1 Feb 93 16:42
From: "(Lutz Falkenhagen)" <falken@helios.tnt.uni-hannover.dbp.de>
To: www-talk@nxoc01.cern.ch
Message-Id: <RFC-822*9302011642.AA10080@helios.tnt.uni-hannover.dbp.de>
Subject: request: mail gateway

RFC-822-HEADERS:
Cc: falken

==================
Hi, 
I am new in this mailing list. I am working at the University of Hannover, where
I am building an information system for our institut. One way of getting 
information is to allow each person of our institut to save news from a news
server in a global mail file. For proving this information via WWW I need a
mail gateway for WWW as I have found it for wais and other formats. 

Is there anybody working on a mail gateway for WWW or is it already available 
on the net? 
Thanks in advance.
	Lutz

________________________________________________________________________________

Dipl.-Ing. Lutz Falkenhagen	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
phone:  +49-511-762-5312           Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1, Germany
email: falken@tnt.uni-hannover.de
X400: s=falken;ou=tnt;p=uni-hannover;a=dbp;c=de;      
________________________________________________________________________________

From marca@wintermute.ncsa.uiuc.edu  Tue Feb  2 04:02:55 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07654; Tue, 2 Feb 93 04:02:55 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01360; Tue, 2 Feb 1993 04:18:45 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28473
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 1 Feb 93 21:18:44 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05945; Mon, 1 Feb 93 21:20:20 -0800
Date: Mon, 1 Feb 93 21:20:20 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302020520.AA05945@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: queries
X-Md4-Signature: c6939722b120a5e6f7421ea713bf67d4

So I enter a searchable document, and my browser lets me make a query,
resulting in URL, say, 'foo?keyword'.  

The resulting document is also searchable.  So I make another query.

Should the resulting URL be 'foo?keyword?anotherkeyword' or
'foo?anotherkeyword' ... ???

Marc


From anthony@aaii.oz.au  Tue Feb  2 04:50:44 1993
Return-Path: <anthony@aaii.oz.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07869; Tue, 2 Feb 93 04:50:44 MET
Received: from aaii_slip.aaii.oz.AU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05503; Tue, 2 Feb 1993 05:06:25 +0100
Received: from harlie.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII)
	id AA00823; Tue, 2 Feb 1993 15:05:12 +1100
Message-Id: <199302020405.AA00823@yarra-glen.aaii.oz.au>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: queries 
In-Reply-To: Your message of "Mon, 01 Feb 1993 21:20:20 -0800."
             <9302020520.AA05945@wintermute.ncsa.uiuc.edu> 
Date: Tue, 02 Feb 1993 15:05:04 +1100
From: Anthony Baxter <anthony@aaii.oz.au>



In message <9302020520.AA05945@wintermute.ncsa.uiuc.edu>you write:
> So I enter a searchable document, and my browser lets me make a query,
> resulting in URL, say, 'foo?keyword'.  
> 
> The resulting document is also searchable.  So I make another query.
> 
> Should the resulting URL be 'foo?keyword?anotherkeyword' or
> 'foo?anotherkeyword' ... ???
Surely it depends whether the second search is 'refining' the first one, or
is another search on the original document? If it is continuing the first
search, then it shouldnt be foo?anotherkeyword, as this will mean the first
search will be ignored.

Anthony

From marca@wintermute.ncsa.uiuc.edu  Tue Feb  2 04:52:38 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07875; Tue, 2 Feb 93 04:52:38 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05559; Tue, 2 Feb 1993 05:08:28 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA00342
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 1 Feb 93 22:08:26 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA06465; Mon, 1 Feb 93 22:10:03 -0800
Date: Mon, 1 Feb 93 22:10:03 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302020610.AA06465@wintermute.ncsa.uiuc.edu>
To: Anthony Baxter <anthony@aaii.oz.au>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: queries 
In-Reply-To: <199302020405.AA00823@yarra-glen.aaii.oz.au>
References: <199302020405.AA00823@yarra-glen.aaii.oz.au>
	<9302020520.AA05945@wintermute.ncsa.uiuc.edu>
X-Md4-Signature: 548ef8b15af163ade3f6e5e6ed955257

Anthony Baxter writes:
> In message <9302020520.AA05945@wintermute.ncsa.uiuc.edu>you write:
> > So I enter a searchable document, and my browser lets me make a query,
> > resulting in URL, say, 'foo?keyword'.  
> > 
> > The resulting document is also searchable.  So I make another query.
> > 
> > Should the resulting URL be 'foo?keyword?anotherkeyword' or
> > 'foo?anotherkeyword' ... ???
>
> Surely it depends whether the second search is 'refining' the first
> one, or is another search on the original document? If it is
> continuing the first search, then it shouldnt be foo?anotherkeyword,
> as this will mean the first search will be ignored.

Well, I agree, but how does my poor li'l browser tell the difference?

Marc



From timbl@www3.cern.ch  Tue Feb  2 14:31:39 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10494; Tue, 2 Feb 93 14:31:39 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06760; Tue, 2 Feb 1993 14:47:31 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01422; Tue, 2 Feb 93 14:44:48 +0100
Date: Tue, 2 Feb 93 14:44:48 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302021344.AA01422@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Fwd: Mac WWW alpha binary
Reply-To: timbl@nxoc01.cern.ch


FYI, with caveat

Begin forwarded message:

From: cailliau@cernnext.cern.ch
Date: Tue, 2 Feb 93 12:18:09 +0100
To: dhirmes@hamp.hampshire.edu, tim@cernnext.cern.ch
Subject: Mac WWW

/pub/www/bin/mac

now has MacWWW.hqx which is the binhex of a self-extracting archive  
of the application.
Beware, there still are bugs: it sometimes hangs the machine!

Robert.


From timbl@www3.cern.ch  Tue Feb  2 15:29:51 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11059; Tue, 2 Feb 93 15:29:51 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15911; Tue, 2 Feb 1993 15:45:41 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01489; Tue, 2 Feb 93 15:42:57 +0100
Date: Tue, 2 Feb 93 15:42:57 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302021442.AA01489@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: queries
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>    

>    Begin forwarded message:
>    

>    Date: Mon, 1 Feb 93 21:20:20 -0800
>    From: marca@ncsa.uiuc.edu (Marc Andreessen)
>    To: www-talk@nxoc01.cern.ch
>    Subject: queries
>    X-Md4-Signature: c6939722b120a5e6f7421ea713bf67d4
>    

>    So I enter a searchable document, and my browser lets me make a  
query,
>    resulting in URL, say, 'foo?keyword'.  

>    

>    The resulting document is also searchable.  So I make another  
query.
>    

>    Should the resulting URL be 'foo?keyword?anotherkeyword' or
>    'foo?anotherkeyword' ... ???

It should be foo?anotherkeyword as the existing search is stripped  
off.  There is an HTSearch() which does it.

Tim

>    Marc
>    

>    

>  

From koellner%Csa6.LBL.Gov@lbl.bitnet  Tue Feb  2 22:45:38 1993
Return-Path: <koellner%Csa6.LBL.Gov@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15895; Tue, 2 Feb 93 22:45:38 MET
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12386; Tue, 2 Feb 1993 23:01:31 +0100
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 0833; Tue, 02 Feb 93 23:00:18 SET
Received: from Lbl.Bitnet (NJE origin MAILER@LBL) by CEARN.CERN.CH (LMail V1.1b/1.7e) with BSMTP id 0284; Tue, 2 Feb 1993 23:00:17 +0100
Received: from Csa6.LBL.Gov by Csa3.LBL.Gov via INTERNET ;
          Tue, 2 Feb 93 14:01:13 PST
Date:    Tue, 2 Feb 93 14:01:09 PST
From: koellner%Csa6.LBL.Gov%Lbl.BITNET@cearn.bitnet (Werner Koellner, LBL)
Message-Id: <930202140109.2160149a@csa6.lbl.gov>
Subject: viola/www memory leak
To: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"www-talk@nxoc01.cern.ch"

                                         LBL, Physics Division,  2-FEB-1993

    Hi,
        I've mentioned this previously without raising any particular
        definitive response and thought I'll bring it up once again:

        I run viola/www on a diskless SUN Sparcstation 1+ served by a
        SUN690MP and I find that viola "leaks memory" quite badly such
        that I am forced to exit all processes and start over about once
        a week. I am wondering if anyone else has seen this kind of problem
        on their machine?

                                   Werner

From wei@xcf.berkeley.edu  Wed Feb  3 07:43:11 1993
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19150; Wed, 3 Feb 93 07:43:11 MET
Received: from xcf.Berkeley.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08732; Wed, 3 Feb 1993 07:59:04 +0100
Received: by xcf.Berkeley.EDU (5.65/XCF-1.34)
	id AA05742; Tue, 2 Feb 93 22:59:51 -0800
Date: Tue, 2 Feb 93 22:59:51 -0800
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9302030659.AA05742@xcf.Berkeley.EDU>
To: koellner%Csa6.LBL.Gov%Lbl.BITNET%cearn.BITNET@jade.berkeley.edu,
        www-talk@nxoc01.cern.ch
Subject: Re:  viola/www memory leak

Well, a relatively astonishing number of leaks have been discovered 
(by purify) and plugged up in my working copy of viola. So, in the 
Next Release you should no longer need to restart your Xserver 
periodically, as much. (The X server was a victim of viola's habit 
of piling up pixmaps and fonts...).

"When's the next release?" ...I'm working on it. <fuzzylogic>This 
indefinite answer has much to do with the viola and the browser's 
indefinite number of features which are currently being, and 
considered to be, added</fuzzylogic>.

It's been a while since an update, but I think you'll like it when 
it's out. Meanwhile, there is Marc's Xmosaic, which seems very
well done!

-Pei

From fine@cis.ohio-state.edu  Thu Feb  4 00:22:30 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28312; Thu, 4 Feb 93 00:22:30 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27442; Thu, 4 Feb 1993 00:38:24 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA15829; Wed, 3 Feb 93 18:38:18 -0500
Date: Wed, 3 Feb 93 18:38:18 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9302032338.AA15829@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Usenet FAQ Project
X-Mailer: Perl Mail System v1.1

Well, I've completed a draft of the format to be used by FAQ writers, and
software that converts it to HTML.  Take a look at the "Usenet FAQs" item
found in:

HREF="http://www.cis.ohio-state.edu:80/hypertext/information/information.html"

This will get you to a (almost empty) list of FAQs which conform and have
been formatted.  Currently the only thing here is my as yet unposted
posting, in hypertext form.

Go to the part on more information.  This includes the
posting (which hasn't actually been posted yet).  Also, since the posting
itself will conform to the format described therein, you will also find
the hypertext version of the posting in the same document.

Please take a look, and pass comments back to me.  If I don't hear anything
for a couple of days, I'll assume everything is fine and go ahead and post.

I'm still wrestling with one problem:  How do I tell people who are
naive to the ways of WWW how to find this specific information in the
web?  I've listed all the browsers around, and each one comes up with a
different view of the web.  I suppose I could just include the URL, but
then they'd have to figure out how to get whichever browser they picked
to go there.  Any suggestions?

If you want to glance at the software, send me mail, and I'll send you
a copy.

Things not completed yet:
  Still doesn't automatically scan news.
  Software doesn't automatically insert itself into our web (trivial).

	tom

P.S.  My future agenda:
  1. complete editor  (very soon)
  2. update browser   (very soon)
  3. clean up all of our documentation so it actually conforms (soon)
  4. write some fun robots (slightly soon)
  5. work on MIME stuff (not real soon)
  6. work on hypertext postscript (not real soon)


From julian@vxcrna.cern.ch  Thu Feb  4 16:39:00 1993
Return-Path: <julian@vxcrna.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04546; Thu, 4 Feb 93 16:39:00 MET
Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21619; Thu, 4 Feb 1993 16:53:16 +0100
Date: Thu, 4 Feb 1993 16:53:12 +0100
Message-Id: <9302041553.AA21619@dxmint.cern.ch>
From: julian@vxcrna.cern.ch (Julian Bunn. CN Division, CERN. 41 22 767 5029, beep 5551)
X-Vms-To: MINT::www-talk@info.cern.ch
X-Vms-Cc: JULIAN
Subject: XMosaic for VMS
X-Mail11-Ostype: VAX/VMS
Apparently-To: <www-talk@info.cern.ch>

I have ftp'ed the executable and command file for the VMS/Multinet/Motif1.1
port of XMosaic onto /pub/incoming on info.cern.ch.

These files are also available via DECnet on VXCRNA. They are:
USER$USEREXE:XMOSAIC.EXE
USER$UTILS:XMOSAIC.COM


Julian

From timbl@www3.cern.ch  Thu Feb  4 17:52:47 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05392; Thu, 4 Feb 93 17:52:47 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02639; Thu, 4 Feb 1993 18:08:43 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01113; Thu, 4 Feb 93 18:05:47 +0100
Date: Thu, 4 Feb 93 18:05:47 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302041705.AA01113@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: julian@vxcrna.cern.ch (Julian Bunn. CN Division, CERN. 41 22 767 5029,
     beep 5551)
Subject: Re: XMosaic for VMS
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


The files are now in /pub/www/bin/vms.   Note that if you have  
different sharable libraries you will need the object files --  
contact Julain for coordinates.

The executable is either 0.1 or 0.5 of Xmosaic   -- I'm not sure!

	Tim BL
	
> Date: Thu, 4 Feb 1993 16:53:12 +0100
> From: julian@vxcrna.cern.ch (Julian Bunn. CN Division, CERN. 41 22  
767 5029, beep 5551)
> 

> I have ftp'ed the executable and command file for the  
VMS/Multinet/Motif1.1
> port of XMosaic onto /pub/incoming on info.cern.ch.
> 

> These files are also available via DECnet on VXCRNA. They are:
> USER$USEREXE:XMOSAIC.EXE
> USER$UTILS:XMOSAIC.COM
> 

> 

> Julian
> 


From RASHTY@hujivms.bitnet  Thu Feb  4 18:14:05 1993
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05626; Thu, 4 Feb 93 18:14:05 MET
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05115; Thu, 4 Feb 1993 18:30:01 +0100
Message-Id: <9302041730.AA05115@dxmint.cern.ch>
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 9099; Thu, 04 Feb 93 18:28:45 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1c/1.7e) with BSMTP id 1833; Thu, 4 Feb 1993 18:28:45 +0100
Received: by HUJIVMS (HUyMail-V6k); Thu, 04 Feb 93 19:29:52 +0200
Date:     Thu,  4 Feb 93 19:28 +0200
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch
Subject:  an Idea for a new WWW disc. group

Hi,

I think it is time to create a new group for all the users of the WWW, that
will let them exchange ideas of data sources ect.

In the Hebrew University we have created several data bases on our WWW which
may be intersting to other users of the WWW.
(GcG - for Genetic Biolegy, Tex and more)

I think that the www-talk is more for the technical side of the WWW, and there
should be another list like WWW-DATA for exchanging information about data
sources.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:                                                      **** Thanks !! **** :
: Dudu Rashty                Rashty@Vms.Huji.Ac.Il         __o     o__     :
: Computation Center         Bitnet:Rashty@HUJIVMS       _ \<,_   _.>/ _   :
: The Hebrew University      Phone:  +972-2-584397      (_)/ (_) (_) \(_)  :
: Jerusalem 91904, ISRAEL.   Fax:    +972-2-527349       D    u    d    u  :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From paolo@venedig.ai.univie.ac.at  Thu Feb  4 19:25:37 1993
Return-Path: <paolo@venedig.ai.univie.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06480; Thu, 4 Feb 93 19:25:37 MET
Received: from moskau.ai.univie.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14215; Thu, 4 Feb 1993 19:41:01 +0100
Received: by moskau.ai.univie.ac.at id AA11577
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 4 Feb 1993 19:38:54 +0100
From: paolo petta <paolo@venedig.ai.univie.ac.at>
Message-Id: <199302041838.AA11577@moskau.ai.univie.ac.at>
Subject: an Idea for a new WWW disc. group (fwd)
To: www-talk@nxoc01.cern.ch
Date: Thu, 4 Feb 1993 19:38:52 +0100
X-Mailer: ELM [version 2.3 PL11]

[original message by Dudu Rashty +972-2-584848 ]
> ...
> 
> I think that the www-talk is more for the technical side of the WWW, and
> there should be another list like WWW-DATA for exchanging information about
> data sources.
> 

I second this proposal.

pAolo
--
paolo petta                                            +43-1-5336112(Tel)
Austrian Research Inst. for Artificial Intelligence    +43-1-5320652(Fax)
Schottengasse 3, A-1010 Vienna, Austria, Europe     paolo@ai.univie.ac.at 

From murphy@dccs.upenn.edu  Thu Feb  4 19:30:10 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06545; Thu, 4 Feb 93 19:30:10 MET
Received: from NOC1.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14405; Thu, 4 Feb 1993 19:46:05 +0100
Received: from LAM.DCCS.UPENN.EDU by noc1.dccs.upenn.edu
	id AA27847; Thu, 4 Feb 93 13:46:03 -0500
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA06905; Thu, 4 Feb 93 13:37:18 -0500
Posted-Date: Thu, 04 Feb 93 13:37:17 -0500
Message-Id: <9302041837.AA06905@lam.dccs.upenn.edu>
To: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: an Idea for a new WWW disc. group 
In-Reply-To: Your message of "Thu, 04 Feb 93 19:28:00 +0200."
             <9302041730.AA05115@dxmint.cern.ch> 
Date: Thu, 04 Feb 93 13:37:17 -0500
From: murphy@dccs.upenn.edu
X-Mts: smtp


How about an nntp newsgroup for www?

my suggestion: comp.infosystems.www


--lam


From putz@parc.xerox.com  Thu Feb  4 20:44:51 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07244; Thu, 4 Feb 93 20:44:51 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22732; Thu, 4 Feb 1993 21:00:45 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11662>; Thu, 4 Feb 1993 12:00:11 PST
Received: by spoggles.parc.xerox.com id <58401>; Thu, 4 Feb 1993 11:59:55 -0800
Date: 	Thu, 4 Feb 1993 11:59:38 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: an Idea for a new WWW disc. group 
In-Reply-To: <9302041837.AA06905@lam.dccs.upenn.edu>
To: murphy@dccs.upenn.edu
Cc: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>,
        www-talk@nxoc01.cern.ch
Message-Id: <93Feb4.115955pst.58401@spoggles.parc.xerox.com>

I also would like to see it as a newsgroup such as comp.infosystems.www.  Maybe there should be two:

	comp.infosystems.www
	comp.infosystems.www.implementation

-- Steve Putz

From TONYJ@scs.slac.stanford.edu  Thu Feb  4 21:18:28 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07476; Thu, 4 Feb 93 21:18:28 MET
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25314; Thu, 4 Feb 1993 21:32:48 +0100
Date: Thu, 4 Feb 1993 12:32 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: an Idea for a new WWW disc. group
To: www-talk@nxoc01.cern.ch
Message-Id: <10E423B850A00218@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ

>I also would like to see it as a newsgroup such as 
>comp.infosystems.www.  Maybe there should be two:
>
>	comp.infosystems.www
>	comp.infosystems.www.implementation

Sounds great to me....does anyone understand the formal 
procedure for going about creating a new comp.* newsgroup? How 
do we start?

TJ

From fine@cis.ohio-state.edu  Thu Feb  4 21:25:36 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07593; Thu, 4 Feb 93 21:25:36 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26148; Thu, 4 Feb 1993 21:41:30 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA24153; Thu, 4 Feb 93 15:41:13 -0500
Date: Thu, 4 Feb 93 15:41:13 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9302042041.AA24153@soccer.cis.ohio-state.edu>
To: Putz.parc@xerox.com, murphy@dccs.upenn.edu
Subject: Re: an Idea for a new WWW disc. group 
Cc: RASHTY%HUJIVMS.BITNET@cearn.bitnet, www-talk@nxoc01.cern.ch
X-Mailer: Perl Mail System v1.1

>I also would like to see it as a newsgroup such as comp.infosystems.www.  Maybe there should be two:
>
>	comp.infosystems.www

I say let's start with one, and go from there.

I'll push this through.  A quick summary of what I have to do:
I post a Request For Discussion to news.announce.newgroups, in which I
propose the newsgroup, its ensues, in which everyone agrees with my
proposal (yeah, right!), and then it goes to vote.

It's not clear to me how long the discussion lasts, the regular posting
says 30 days, but that may be only if no agreement is made.  I believe
if an agreement can be made quickly, a vote can be called for sooner.
But there's plenty of time to find that out after the discussion has
been started.

Also, In addition to news.announce.newgroups, I should post to other
relevant newsgroups.  Does anyone have any suggestions of groups where this
posting should go?  I was figuring on comp.infosystems.  (Suggest quick,
I'll give you all a couple of hours.)

Note that the disussion will take place in news.groups.  Follow-ups to
the request for discussion will go there automatically.

     tom

BTW, Here's the regualar posting that describes the whole procedure.
-----------------------------------------------------------------------------

Archive-name: creating-newsgroups/part1
Original-author: woods@ncar.ucar.edu (Greg Woods)
Last-change: 23 Sep 1992 by spaf@cs.purdue.edu (Gene Spafford)

				 GUIDELINES FOR USENET GROUP CREATION

REQUIREMENTS FOR GROUP CREATION:

   These are guidelines that have been generally agreed upon across
USENET as appropriate for following in the creating of new newsgroups in
the "standard" USENET newsgroup hierarchy. They are NOT intended as 
guidelines for setting USENET policy other than group creations, and they
are not intended to apply to "alternate" or local news hierarchies. The 
part of the namespace affected is comp, news, sci, misc, soc, talk, rec,
which are the most widely-distributed areas of the USENET hierarchy.
   Any group creation request which follows these guidelines to a
successful result should be honored, and any request which fails to
follow these procedures or to obtain a successful result from doing so
should be dropped, except under extraordinary circumstances.  The
reason these are called guidelines and not absolute rules is that it is
not possible to predict in advance what "extraordinary circumstances"
are or how they might arise.
   It should be pointed out here that, as always, the decision whether or not
to create a newsgroup on a given machine rests with the administrator of that
machine. These guidelines are intended merely as an aid in making those
decisions.


The Discussion

1) A request for discussion on creation of a new newsgroup should be posted to
   news.announce.newgroups, and also to any other groups or mailing lists at
   all related to the proposed topic if desired.  The group is moderated, and
   the Followup-to: header will be set so that the actual discussion takes
   place only in news.groups.  Users on sites which have difficulty posting to
   moderated groups may mail submissions intended for news.announce.newgroups
   to announce-newgroups@uunet.uu.net.

   The article should be cross-posted among the newsgroups, including
   news.announce.newgroups, rather than posted as separate articles.  Note that
   standard behaviour for posting software is to not present the articles in
   any groups when cross-posted to a moderated group; the moderator will handle
   that for you.

2) The name and charter of the proposed group and whether it will be moderated
   or unmoderated (and if the former, who the moderator(s) will be) should be
   determined during the discussion period. If there is no general agreement on
   these points among the proponents of a new group at the end of 30 days of
   discussion, the discussion should be taken offline (into mail instead of
   news.groups) and the proponents should iron out the details among
   themselves.  Once that is done, a new, more specific proposal may be made,
   going back to step 1) above.  

3) Group advocates seeking help in choosing a name to suit the proposed
   charter, or looking for any other guidance in the creation procedure, can
   send a message to group-advice@uunet.uu.net; a few seasoned news administrators
   are available through this address.

The Vote

1) AFTER the discussion period, if it has been determined that a new group is
   really desired, a name and charter are agreed upon, and it has been
   determined whether the group will be moderated and if so who will
   moderate it, a call for votes may be posted to news.announce.newgroups and
   any other groups or mailing lists that the original request for discussion
   might have been posted to. There should be minimal delay between the
   end of the discussion period and the issuing of a call for votes.
   The call for votes should include clear instructions for how to cast
   a vote. It must be as clearly explained and as easy to do to cast a
   vote for creation as against it, and vice versa.  It is explicitly
   permitted to set up two separate addresses to mail yes and no votes
   to provided that they are on the same machine, to set up an address
   different than that the article was posted from to mail votes to, or
   to just accept replies to the call for votes article, as long as it
   is clearly and explicitly stated in the call for votes article how
   to cast a vote.  If two addresses are used for a vote, the reply
   address must process and accept both yes and no votes OR reject
   them both.

2) The voting period should last for at least 21 days and no more than 31
   days, no matter what the preliminary results of the vote are. The exact
   date that the voting period will end should be stated in the call for
   votes. Only votes that arrive on the vote-taker's machine prior to this
   date will be counted.

3) A couple of repeats of the call for votes may be posted during the vote, 
   provided that they contain similar clear, unbiased instructions for
   casting a vote as the original, and provided that it is really a repeat
   of the call for votes on the SAME proposal (see #5 below). Partial vote
   results should NOT be included; only a statement of the specific new
   group proposal, that a vote is in progress on it, and how to cast a vote.
   It is permitted to post a "mass acknowledgement" in which all the names
   of those from whom votes have been received are posted, as long as no
   indication is made of which way anybody voted until the voting period
   is officially over.

4) ONLY votes MAILED to the vote-taker will count. Votes posted to the net
   for any reason (including inability to get mail to the vote-taker) and 
   proxy votes (such as having a mailing list maintainer claim a vote for 
   each member of the list) will not be counted.

5) Votes may not be transferred to other, similar proposals. A vote shall
   count only for the EXACT proposal that it is a response to. In particular,
   a vote for or against a newsgroup under one name shall NOT be counted as
   a vote for or against a newsgroup with a different name or charter,
   a different moderated/unmoderated status or (if moderated) a different
   moderator or set of moderators.

6) Votes MUST be explicit; they should be of the form "I vote for the
   group foo.bar as proposed" or "I vote against the group foo.bar
   as proposed". The wording doesn't have to be exact, it just needs to
   be unambiguous. In particular, statements of the form "I would vote
   for this group if..." should be considered comments only and not
   counted as votes.

7) A vote should be run only for a single group proposal.  Attempts to create
   multiple groups should be handled by running multiple parallel votes rather
   than one vote to create all of the groups.

The Result

1) At the completion of the voting period, the vote taker must post the
   vote tally and the E-mail addresses and (if available) names of the voters
   received to news.announce.newgroups and any other groups or mailing lists
   to which the original call for votes was posted. The tally should include
   a statement of which way each voter voted so that the results can be
   verified.

2) AFTER the vote result is posted, there will be a 5 day waiting period,
   beginning when the voting results actually appear in 
   news.announce.newgroups, during which the net will have a chance to
   correct any errors in the voter list or the voting procedure.

3) AFTER the waiting period, and if there were no serious objections that might
   invalidate the vote, and if 100 more valid YES/create votes are received
   than NO/don't create AND at least 2/3 of the total number of valid votes
   received are in favor of creation, a newgroup control message may be sent 
   out.  If the 100 vote margin or 2/3 percentage is not met, the group should 
   not be created.

4) The newgroup message will be sent by the news.announce.newgroups moderator
   at the end of the waiting period of a successful vote.  If the new group is
   moderated, the vote-taker should send a message during the waiting period to
   Gene Spafford <spaf@cs.purdue.edu> and David C. Lawrence <tale@uunet.uu.net> with
   both the moderator's contact address and the group's submission address.

5) A proposal which has failed under point (3) above should not again be
   brought up for discussion until at least six months have passed from the
   close of the vote.  This limitation does not apply to proposals which never
   went to vote.

-- 
Gene Spafford
Software Engineering Research Center & Dept. of Computer Sciences
Purdue University, W. Lafayette IN 47907-1398
Internet:  spaf@cs.purdue.edu	phone:  (317) 494-7825



From arl@cs.hut.fi  Thu Feb  4 22:02:05 1993
Return-Path: <arl@cs.hut.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08013; Thu, 4 Feb 93 22:02:05 MET
Received: from deathstar.cs.hut.fi by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28703; Thu, 4 Feb 1993 22:16:02 +0100
Received: by deathstar.cs.hut.fi id AA04807
  (5.65c8/HUTCS-C 1.3 for www-talk@nxoc01.cern.ch); Thu, 4 Feb 1993 23:15:54 +0200
Date: Thu, 4 Feb 1993 23:15:54 +0200
Message-Id: <199302042115.AA04807@deathstar.cs.hut.fi>
From: Ari Lemmke <arl@cs.hut.fi>
Sender: arl@cs.hut.fi
To: www-talk@nxoc01.cern.ch
Subject: Re: an Idea for a new WWW disc. group
In-Reply-To: <10E423B850A00218@SCS.SLAC.STANFORD.EDU>
References: <10E423B850A00218@SCS.SLAC.STANFORD.EDU>
Reply-To: <arl@cs.hut.fi>
Organization: Helsinki University of Technology, Finland.

"Tony Johnson (415) 926 2278" writes:
> >	comp.infosystems.www
> >	comp.infosystems.www.implementation
> 
> Sounds great to me....does anyone understand the formal 
> procedure for going about creating a new comp.* newsgroup? How 
> do we start?

	1)	Someone has to write RFD (Request For Discussion) for
		c.i.w and c.i.w.i
	2)	post it to announce-newgroups@rpi.edu (or post it
		to moderated newsgroup news.announce.newgroups.
		Remember to add before your RFD text all the
		newsgroups you want the article to appear if
		you email it.
	3)	The discussion period is about 30 days, and
		should be in news.groups newsgroup.
	4)	Then if it's clear that such a newsgroup should
		be available you can write CFV (Call For Voting)
	5)	Take care you have other person as vote-taker,
		so you can make propaganda for your group (other
		than RFD ;-).
	6)	The voting period is 21-31 days.
	7)	When the group passes, it takes 7 days until the
		group is created.
	8)	If the group does _not_ pass the next voting is
		allowed after 6 months.

	Material used for comp.os.linux saved in directory
	nic.funet.fi:/pub/OS/Linux/doc/news/create_docs
	use FTP, gopher, or WWW (?). Or just read news.* groups
	to find out how they do it ...

	Someone should put under WWW "How to create a new newsgroups"
	etc. docs .. ;-)

	Just do it !!! ;-)

> TJ

	arl

From timbl@www3.cern.ch  Fri Feb  5 10:34:33 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12966; Fri, 5 Feb 93 10:34:33 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02778; Fri, 5 Feb 1993 10:50:31 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01494; Fri, 5 Feb 93 10:47:34 +0100
Date: Fri, 5 Feb 93 10:47:34 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302050947.AA01494@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: <arl@cs.hut.fi>
Subject: Re: an Idea for a new WWW disc. group
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Thu, 4 Feb 1993 23:15:54 +0200
> From: Ari Lemmke <arl@cs.hut.fi>
...
> 

> 	1)	Someone has to write RFD (Request For Discussion) for
> 		c.i.w and c.i.w.i
> 	2)	post it to announce-newgroups@rpi.edu (or post it
> 		to moderated newsgroup news.announce.newgroups.
> 		Remember to add before your RFD text all the
> 		newsgroups you want the article to appear if
> 		you email it.
> 	3)	The discussion period is about 30 days, and
> 		should be in news.groups newsgroup.
> 	4)	Then if it's clear that such a newsgroup should
> 		be available you can write CFV (Call For Voting)
> 	5)	Take care you have other person as vote-taker,
> 		so you can make propaganda for your group (other
> 		than RFD ;-).


Ed volunteered to count votes, if someone elese would do the CFV.
He has set up vote counting machinery. Check with Ed. Are you there,  
Ed?

> 	6)	The voting period is 21-31 days.
> 	7)	When the group passes, it takes 7 days until the
> 		group is created.
> 	8)	If the group does _not_ pass the next voting is
> 		allowed after 6 months.
> 

> 	Material used for comp.os.linux saved in directory
> 	nic.funet.fi:/pub/OS/Linux/doc/news/create_docs
> 	use FTP, gopher, or WWW (?). Or just read news.* groups
> 	to find out how they do it ...

URL:	file://nic.funet.fi/pub/OS/Linux/doc/news/create_docs

> 	Someone should put under WWW "How to create a new newsgroups"
> 	etc. docs .. ;-)

This is all in monthly postings to comp.news.newuser or somesuch.  
There is a pointer to that group in the web if you browsee throug the  
newsgroups.

> 	Just do it !!! ;-)

Do check with Ed first or if you can't get him, mention in a preface  
to the moderator that you think that Ed sent in a CFD which got lost  
in the wash.  Groups which start with muddled different CFDs confuse  
people and are frowned on... 


> 	arl
> 

 Tim Bl
 

From bloemer@helios.tnt.uni-hannover.dbp.de  Fri Feb  5 11:06:21 1993
Return-Path: <bloemer@helios.tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13178; Fri, 5 Feb 93 11:06:21 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06311; Fri, 5 Feb 1993 11:22:18 +0100
Date:  5 Feb 93 10:21
From: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>
To: fine@cis.ohio-state.edu
Cc: www-talk@nxoc01.cern.ch
Message-Id: <RFC-822*9302051021.AA05007@helios.tnt.uni-hannover.dbp.de>
Subject: Re: an Idea for a new WWW disc. group


A newsgroup for the World Wide Web project is really missing
and positioning the newsgroup beside of comp.infosystems.gopher
and comp.infosystems.wais is ideal.

But I would prefer as a name for the new group: 

comp.infosystems.world-wide-web

instead of

comp.infosystems.www.

WWW is much shorter and easier to write, but only insiders know what
www is standing for. The name world-wide-web on the other side gives
instantly an idea of the intentions of such a system. So for
presentation and public relation purposes the term world-wide-web 
is much better.

Another problem is the pronounciation of www. Has anyone a suggestion?

Finally I would like to suggest that we come to an agreement
on how to name the World Wide Web project in speech and writing.
In the past I have seen the following terms:

World Wide Web, World-Wide-Web, WorldWideWeb, world-wide-web,
www, WWW, W3, w3,

Compare this confusing collection of terms with the term "Gopher".
"Gopher" is a single, easy pronouncable and associative term.

And the terms for the different browsers and other software:

www, WWW, viola, violaWWW, WWWViola, tkwww, TkWWW, tkWWW, midaswww,
MidasWWW, Xmosaic, xmosaic, X Mosaic, WWWNextStep, WWWLibrary,
HTMLGate, WWWLineMode, www_and_frame, print-www, WWWMailRobot ...

When I first come to info.cern.ch last year with just a vague idea
of what World Wide Web could mean. I was very confused and it takes
some time and experimentation until I know what I need to get started.
The situation now is b even worse.


Arnold


________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1
phone:  +49-511-762-5320           Germany
________________________________________________________________________________



From timbl@www3.cern.ch  Fri Feb  5 14:39:34 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14633; Fri, 5 Feb 93 14:39:34 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08121; Fri, 5 Feb 1993 14:55:29 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01621; Fri, 5 Feb 93 14:52:32 +0100
Date: Fri, 5 Feb 93 14:52:32 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302051352.AA01621@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>
Subject: By any other name: was: an Idea for a new WWW disc. group
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

A lot of people have to type in newsgroup names.  They just won't  
read comp.infosystems.world-wide-web!  www is no more crypict than  
wais, and gopher is not very explanatory for all its uniqueness.

> Finally I would like to suggest that we come to an agreement
> on how to name the World Wide Web project in speech and writing.
> In the past I have seen the following terms:
>
> World Wide Web, World-Wide-Web, WorldWideWeb, world-wide-web,
> www, WWW, W3, w3,

We write "World-Wide Web (W3)" at the start of every paper, and W3  
from then on.

[BTW: W3 was chosen eventually because a in many languages to  
pronounce WWW takes longer than saying World-Wide Web and people just  
couldn't handle it.  So we suggest the pronounciation "double you  
three".  (We ruled out W cubed because though it is more logical you  
can't superscript in mail.  We ruled out V6 because its to cute.  We  
ruled out InfoMesh and then MIT used it. We have only found one  
company called WWW --- a technical documentation company in Freiburg  
who have a "WWW explain" product. Their advertisement doesn't say  
what WWW stands for there. (Maybe you could phone them on 0761/40 10  
221 and find out, Arnold!)

That is the project.  Filenames, logos, etc all use WWW as it is  
catchy, easy to see and type. But of course lower case is de riguer
in unix commands and ftp directories normally. Hence www.

Tim BL  (Tim B-L?  Timbl?  timbl?  TBL? tbl? sigh  :-)

From anthony@aaii.oz.au  Fri Feb  5 14:42:38 1993
Return-Path: <anthony@aaii.oz.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14668; Fri, 5 Feb 93 14:42:38 MET
Received: from aaii_slip.aaii.oz.AU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08395; Fri, 5 Feb 1993 14:58:25 +0100
Received: from wyndham-estates.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII)
	id AA16780; Sat, 6 Feb 1993 00:57:28 +1100
Message-Id: <199302051357.AA16780@yarra-glen.aaii.oz.au>
Received: from idyll.aaii.oz.AU (idyll) by wyndham-estates. (5.65c/SMI-4.0)
	id AA13504; Sat, 6 Feb 1993 00:57:22 +1100
Received: from localhost by idyll.aaii.oz.AU (4.1/SMI-4.0)
	id AA02623; Sat, 6 Feb 93 00:57:21 EST
To: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: an Idea for a new WWW disc. group 
In-Reply-To: Your message of "05 Feb 1993 10:21:00."
             <RFC-822*9302051021.AA05007@helios.tnt.uni-hannover.dbp.de> 
Date: Sat, 06 Feb 1993 00:57:20 +1100
From: Anthony Baxter <anthony@aaii.oz.au>



In message <RFC-822*9302051021.AA05007@helios.tnt.uni-hannover.dbp.de>you write
:
> 
> But I would prefer as a name for the new group: 
> 
> comp.infosystems.world-wide-web

Is in the 14 character limit, so sounds ok. Its just that the software and
the project has always been WWW. (Similar to WAIS - from its acronym, it
isnt obvious what it is).
> Another problem is the pronounciation of www. Has anyone a suggestion?

I originally tried 'double-ewe double-ewe double-ewe', but that got to be
too annoying, so 'double-ewe three' works fine for me. :)
> 
> Finally I would like to suggest that we come to an agreement
> on how to name the World Wide Web project in speech and writing.
> In the past I have seen the following terms:
> 
> World Wide Web, World-Wide-Web, WorldWideWeb, world-wide-web,
> www, WWW, W3, w3,

Most of the documentation I've seen from CERN have either 'World Wide
Web' or 'WWW'.

> When I first come to info.cern.ch last year with just a vague idea
> of what World Wide Web could mean. I was very confused and it takes
> some time and experimentation until I know what I need to get started.
> The situation now is b even worse.

Its actually pretty similar to the Gopher world, there's Gopher, XGopher,
Turbo-Gopher, and no doubt other clients that I dont know about. :)

Explaining this sort of thing is what FAQ's are for :-)

Anthony
--
 anthony baxter                 australian artificial intelligence institute
email : anthony@aaii.oz.au         1 grattan st, carlton, australia 3053
    /\/\||                                  phone : +613 663 7922
Disclaimer: Unless otherwise specified, the above is my opinion, not AAII's.

From bloemer@helios.tnt.uni-hannover.dbp.de  Fri Feb  5 16:24:11 1993
Return-Path: <bloemer@helios.tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15600; Fri, 5 Feb 93 16:24:11 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26749; Fri, 5 Feb 1993 16:40:04 +0100
Date:  5 Feb 93 15:39
From: "(Arnold Bloemer)" <bloemer@helios.tnt.uni-hannover.dbp.de>
To: timbl@nxoc01.cern.ch
Message-Id: <RFC-822*9302051539.AA05794@helios.tnt.uni-hannover.dbp.de>
Subject: Re: By any other name: was: an Idea for a new WWW disc. group

RFC-822-HEADERS:
Cc: www-talk@nxoc01.cern.ch, bloemer

==================

> From timbl@www3.cern.ch Fri Feb  5 15:07:31 1993
             ^^^^

nice variation :-)

...
> We write "World-Wide Web (W3)" at the start of every paper, and W3  
> from then on.
> 
> [BTW: W3 was chosen eventually because a in many languages to  
> pronounce WWW takes longer than saying World-Wide Web and people just  
> couldn't handle it.  So we suggest the pronounciation "double you  
> three".  (We ruled out W cubed because though it is more logical you  
> can't superscript in mail.  We ruled out V6 because its to cute.  We  
> ruled out InfoMesh and then MIT used it. We have only found one  
> company called WWW --- a technical documentation company in Freiburg  
> who have a "WWW explain" product. Their advertisement doesn't say  
> what WWW stands for there. (Maybe you could phone them on 0761/40 10  
> 221 and find out, Arnold!)

I just phoned them.

WWW stands for: "Wirtschaftswerbung Woerlen". "Wirtschaftswerbung" means
"Business to Business Communication" and Mr. Woerlen is the big boss
of WWW.

"WWW Explain" is the name of a subsidiary of WWW which is offering
technical documentation services.

They told me about the same problems with pronounciation of WWW in
different languages.

And they gave me a hint, that there is a service available which looks
for and verifies names for other companies. A name shall cost about 
70000 Deutsche Mark or 44000 US $.

Arnold


________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1
phone:  +49-511-762-5320           Germany
________________________________________________________________________________


From joe@athena.mit.edu  Mon Feb  8 07:16:49 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05379; Mon, 8 Feb 93 07:16:49 MET
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05780; Mon, 8 Feb 1993 07:32:52 +0100
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA19996; Mon, 8 Feb 93 01:26:38 EST
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA19528; Mon, 8 Feb 93 01:26:37 -0500
Date: Mon, 8 Feb 93 01:26:37 -0500
Message-Id: <9302080626.AA19528@theodore-sturgeon>
To: tk-www@athena.mit.edu, www-announce@nxoc01.cern.ch,
        www-talk@nxoc01.cern.ch, tcl-archive@athena.mit.edu
Subject: Announcing tkWWW Version 0.5 Alpha


tkWWW Version 0.5 alpha (joe@athena.mit.edu)
--------------------------------------------

WHAT IS THIS?
-------------
World Wide Web (WWW) is a hypertext project which seeks to build a
world wide network of hypertext links.  There are several different
browsers for this system including a simple tty interface.  For a 
demo of the terminal browsers for WWW, telnet to the following sites:

 telnet info.cern.ch or telnet 128.141.201.74 (SWISS)
 telnet eies2.njit.edu or telnet 128.235.1.43 (USA [NJ])
 telnet vms.huji.ac.il or telnet 128.139.4.3  (ISRAEL)
 telnet info.funet.fi or telnet 128.214.6.100 (FINLAND)

 and login as "www"

Tk is an interpreted toolkit which allows one to build X11 applications
quickly and easily.

tkWWW is a Tk interface to (WWW), which lets you send embedded buttons,
scrollbars, etc in hypertext written for WWW.

The Tk browser has the following advantages.

1. Since the entire user interface is written in an interpreted 
   language, it should be very easy to make modifications and extensions
   to the system.

2. tkWWW can be configured with the "htext" widget which makes it is 
   possible to imbed Tk code into hypertext or with the "text" widget
   which makes it possible to display multi-fonts.  In the next few
   months, there will be a new revision of tK which will allow imbeded
   tK code with the "text" widget and support for the tkWWW "htext" widget
   will be discontinued.

WHERE IS THIS?
--------------
tkWWW 0.5 can be anon ftp'ed from
   export.lcs.mit.edu:/contrib/tkWWW-0.5.tar.Z
   barkley.berkeley.edu:/tcl/extensions/tkWWW-0.5.tar.Z
   info.cern.ch:/pub/WWW/src/tkWWW-0.5.tar.Z

WHAT HAS CHANGED SINCE 0.4?
---------------------------
Converted tkWWW to use www library 1.1a
Introduced multi-fonts
Added menu options to access various tkWWW sources.
Added cloning by pressing button2.

MAILING LIST
------------
There is a mailing list devoted to discussions about tkWWW at 
 
   tk-www@athena.mit.edu

To get on this list, send e-mail to

   tk-www-request@athena.mit.edu

INSTALLATION
----------

1. Edit the file "tkWWW.imake" to set system defaults

2. Type the following commands in the directory TkWWW

    xmkmf
    make world
    make install



From janssen@parc.xerox.com  Tue Feb  9 00:45:30 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13258; Tue, 9 Feb 93 00:45:30 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12282; Tue, 9 Feb 1993 01:01:34 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12375>; Mon, 8 Feb 1993 16:01:12 PST
Received: by holmes.parc.xerox.com id <25546>; Mon, 8 Feb 1993 16:01:06 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon,  8 Feb 1993 16:00:51 -0800 (PST)
Message-Id: <0fRjEnkB0KGWQ3=bYw@holmes.parc.xerox.com>
Date: 	Mon, 8 Feb 1993 16:00:51 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: Linearized version of the WWW HTTP2 spec?

Does anyone have a linearized, suitable-for-printing version of the
HTTP2 spec?  Where do I retrieve it from?

Bill

From marca@wintermute.ncsa.uiuc.edu  Tue Feb  9 08:38:29 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15839; Tue, 9 Feb 93 08:38:29 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27291; Tue, 9 Feb 1993 08:54:33 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA10498
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 9 Feb 93 01:54:32 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA02689; Tue, 9 Feb 93 01:56:12 -0800
Date: Tue, 9 Feb 93 01:56:12 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302090956.AA02689@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu
Subject: annotations, personal -> private
X-Md4-Signature: a3eda1763429c6ab429419a514de9c0a

Version 0.7 of X Mosaic will have personal annotations: for any
document, you can make an annotation (or several annotations) that
will be inlined into the document you're annotating each time you
access that document.  (Actually, a link to the annotation is inlined,
but anyway...)

This is the first step towards a more complicated subject.  To wit,
there is a wide spectrum between wholly personal annotations and
openly public annotations.  The former can be implemented easily by
storing annotations in one's local directory; the latter (potentially)
by having servers store and serve annotations to documents they
themselves serve (an approach that is used by at least one existing
system, the Worm Community System from the University of Arizona,
which is serving as my initial model for annotation/asynch
collaboration capabilities).

However, suppose you want to share some annotations with one other
person, some with your department (~10 people), some with your
organization (~200 people), and some with the whole world.  What then?

Here's one idea: a new type of server, an annotation server, will be
run by each group of people desiring to share annotations among
themselves.  This server will archive, maintain, and serve annotations
to any document in the web to the members of the group only.  Every
time a member of one or more of these group does a document access,
her client checks with the appropriate annotation servers (as in the
above example, there could be 3 or 4 of 'em).

(A modified version of this scenario is to run a centralized
annotation server per organization, and to allow subgroups to be
established at will within that organization but managed by the same
server.)

These issues shade over into other types of asynch collaboration
issues, including web-based revision control, protection at the
document level, and so on.

So what do people think?  Ideas I haven't thought of?  Problems with
ideas I have thought of?

Marc


From emv@garnet.msen.com  Tue Feb  9 22:27:45 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23957; Tue, 9 Feb 93 22:27:45 MET
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04644; Tue, 9 Feb 1993 22:43:50 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nM2k6-001IDpC@garnet.msen.com>; Tue, 9 Feb 93 16:43 WET
Message-Id: <m0nM2k6-001IDpC@garnet.msen.com>
To: timbl@nxoc01.cern.ch
Cc: <arl@cs.hut.fi>, www-talk@nxoc01.cern.ch
Subject: Re: an Idea for a new WWW disc. group 
In-Reply-To: Your message of Fri, 05 Feb 93 10:47:34.
             <9302050947.AA01494@www3.cern.ch> 
Date: Tue, 09 Feb 93 16:43:31 EST
From: Edward Vielmetti <emv@msen.com>

I'm here.  If you need a vote-counter, I'll tally them up, just please
keep me out the loop on name-picking :)

--Ed

From marca@wintermute.ncsa.uiuc.edu  Wed Feb 10 04:57:01 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27445; Wed, 10 Feb 93 04:57:01 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13942; Wed, 10 Feb 1993 05:13:08 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16254
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 9 Feb 93 22:13:06 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05540; Tue, 9 Feb 93 22:14:45 -0800
Date: Tue, 9 Feb 93 22:14:45 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302100614.AA05540@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Gopher+
X-Md4-Signature: f32f2cba49565499ef0d4c4a0cc3edfa

Well, they've gone ahead and done it....

Marc

Date: Tue, 9 Feb 93 18:18:28 CST
From: gopher@boombox.micro.umn.edu (The Gopher Team)
Original-To: gopher-news@boombox.micro.umn.edu
Subject: First release of Gopher+ clients and server
Newsgroups: comp.infosystems.gopher
Distribution: comp

Dateline: Minneapolis, MN  9 Feb 1993

The University of Minnesota Internet Gopher Team is pleased to announce
the availability of first beta release of gopher+ clients and server.
Now available for anonymous ftp from boombox.micro.umn.edu are:

   TurboGopher1.6b1       ---  A Gopher+ client for the Macintosh

   available as /pub/gopher/Macintosh-TurboGopher/TurboGopher.1.06b1.hqx

and 

   gopher+1.2beta.tar.Z   ---  A Gopher+ client and server for Unix systems

   available as /pub/gopher/Unix/gopher+1.12.tar.Z


After spending most of January eating turnips we have our first test
release of Gopher+ software.  However, not all features have been
implemented yet, and there is plenty of testing to be done.  You
probably don't want to give this to everyone on your campus.... 
yet :-) 

Please, *Please*, Please send bug reports to
gopher@boombox.micro.umn.edu 


Features currently implemented for TurboGopher
----------------------------------------------

Supports Multiple views of documents.

Fetches item attributes (administrator, modification date etc.)

Supports access to "Admit1" gopher+ servers

   (Admit1 is an extension to Gopher+ that allows secure
    authentication on a per user basis to servers using a ticketing
    scheme)

User selectable helper applications for displaying alternate views and
images. 

Support for JPEG, GIF, PICT, and sundry other image/document formats.

Intelligent Gopher+ error handling.

File retrieval status is displayed in a separate window for each
retrieval.  This makes it easy to terminate file retrievals or obtain
status when several concurrent retrievals are active.

Rudimentary support for ASK queries from the server.


Features currently implemented for the UNIX client
--------------------------------------------------

Intelligent Gopher+ error handling.

Fetches item attributes (administrator, modification date etc.)

Supports Multiple views of documents.

Gripe command allows the user to complain to the specific adminstrator
of a document.

Configurable helper applications for displaying alternate views and
images. 

More than rudimentary support for ASK queries from the server.


Features currently implemented for the UNIX server
--------------------------------------------------

Supports ASK blocks. Allows answers to multiple queries to be
retrieved from a gopher+ client.

Supports multiple views via configurable filename extension mapping. 

Basic Gopher+ error responses.

Item attributes (administrator, abstracts, etc.)

Very little documentation, but a bunch of examples

Replacement code for .cap files.


Gopher+ attribute registry
--------------------------

The Gopher+ attribute is available via gopher on host

Host=boombox.micro.umn.edu 
Port=70
Path=0/gopher/gopher_protocol/Gopher+/Gopher+AttributeRegistry

This is also available via ftp to boombox.micro.umn.edu


Gopher+ example server
----------------------

We are also running an example gopher+ example server.

Connect to gopher.tc.umn.edu and select:

   Information about Gopher
      Gopher+ example server

Note that the machine this points to will be changing soon.  We will
update the link to be current..  (i.e. don't depend on it being on
mudhoney.micro.umn.edu)



From marca@wintermute.ncsa.uiuc.edu  Wed Feb 10 10:33:36 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29267; Wed, 10 Feb 93 10:33:36 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28687; Wed, 10 Feb 1993 10:49:43 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23069
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 10 Feb 93 03:49:42 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA08526; Wed, 10 Feb 93 03:51:23 -0800
Date: Wed, 10 Feb 93 03:51:23 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302101151.AA08526@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: XMosaic on Sun's
X-Md4-Signature: 3ed5b3eaf01908689c9aee0de3829dda

People who have tried to run X Mosaic 0.6 on Sun workstations and had
lots of problems with run-time translation table errors and
backspace/delete not working in the text entry fields......

I think I have a solution.  Append (or move) the following file to
/usr/lib/X11/XKeysymDB:

---------------------------------- CUT HERE ----------------------------------
!
!		OSF Keysyms
!
osfBackSpace			:1004FF08
osfInsert			:1004FF63
osfDelete			:1004FFFF
osfCopy				:1004FF02
osfCut				:1004FF03
osfPaste			:1004FF04

osfAddMode			:1004FF31
osfPrimaryPaste			:1004FF32
osfQuickPaste			:1004FF33

osfPageUp			:1004FF41
osfPageDown			:1004FF42

osfEndLine			:1004FF57
osfBeginLine			:1004FF58

osfActivate			:1004FF44

osfMenuBar			:1004FF45

osfClear			:1004FF0B
osfCancel			:1004FF69
osfHelp				:1004FF6A
osfMenu				:1004FF67
osfSelect			:1004FF60
osfUndo				:1004FF65

osfLeft				:1004FF51
osfUp				:1004FF52
osfRight			:1004FF53
osfDown				:1004FF54

!             DEC specific keysyms
!
DRemove				:1000FF00
---------------------------------- CUT HERE ----------------------------------

And if you try it, please let me know if this solves your problem, or
doesn't...

Marc


From julian@vxcrna.cern.ch  Wed Feb 10 16:51:30 1993
Return-Path: <julian@vxcrna.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02605; Wed, 10 Feb 93 16:51:30 MET
Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05285; Wed, 10 Feb 1993 16:54:51 +0100
Date: Wed, 10 Feb 1993 16:54:51 +0100
Message-Id: <9302101554.AA05285@dxmint.cern.ch>
From: julian@vxcrna.cern.ch (Julian Bunn. CN Division, CERN. 41 22 767 5029, beep 5551)
X-Vms-To: MINT::marca@ncsa.uiuc.edu
X-Vms-Cc: MINT::SYSTEM@LNS61.TN.CORNELL.EDU,MINT::www-talk@info,JULIAN
Subject: VMS Port of XMosaic
X-Mail11-Ostype: VAX/VMS
Apparently-To: <www-talk@info>
Apparently-To: <system@lns61.tn.cornell.edu>
Apparently-To: <marca@ncsa.uiuc.edu>


    TimBL asked me to pass on details of the VMS port. Although it seemed
rather tricky at the time, the actual changes for VMS are simple. Instead
of sending you the diff -c results, they can be summarised as:

    1) In gui.c, #ifdef VMS to avoid including unistd.h
    2) In main.c, #ifdef VMS then do not signal SIGUSR1 (ugly fix)
    3) In Xresources.h I had to change all 17 point fonts to 18 point,
       as the DECwindows MOTIF seems to lack them. I also changed
       the anchor colour to Red instead of hex 9f, since some people's
       X defaults specified a blue background, so making the anchors
       invisible!
    4) STRDUP was missing from VMS, and from the Ultrix system I used.
       So I included a version as a separate file.

Finally, I wrote a little VMS command file that does the compile and
link for VMS systems running Multinet. This is included below, as is
STRDUP.


VMS_MAKE.COM
-------------------------------------------------------------------------
$!========================================================================
$!
$! Name      : VMS_MAKE
$!
$! Purpose   : Make the VMS version of XMosaic
$!
$! Arguments : None
$!
$! Created  10-FEB-1993   Julian J. Bunn
$!
$!========================================================================
$   ON ERROR     THEN $ GOTO EXIT
$   ON CONTROL_Y THEN $ GOTO EXIT
$ copy sys$input sys$output

  Procedure for making XMosaic. This procedure expects to find the
  /src files in the current directory, the /libhtmlw sources in a
  subdirectory [.libhtmlw] and the /libwww sources in a subdirectory
  [.libwww]. This version produces an executable for Multinet TCP/IP.
  UCX and Wollongong versions can be created by changing the CC compile
  flag appropriately (UCX or WIN_TCP respectively).


$ if f$search("libhtmlw.dir") .eqs. ""
$ then
$    write sys$output "You need directory [.libhtmlw]"
$    exit
$ endif
$ if f$search("libwww.dir") .eqs. ""
$ then
$    write sys$output "You need directory [.libwww]"
$    exit
$ endif
$ library/create libhtmlw.olb
$ write sys$output "Compiling source in LIBHTMLW"
$ set def [.libhtmlw]
$ delete *.obj.*
$loop1:
$ file = f$search("*.c")
$ if file .eqs. "" then goto end_loop1
$ write sys$output "File : ''file'"
$ cc /nowarn 'file
$ if $severity 
$ then 
$    library/ins [-]libhtmlw *.obj
$    delete *.obj.*
$ endif
$ goto loop1
$end_loop1:
$ library/create [-]libwww.olb
$ set def [-.libwww]
$ write sys$output "Compiling source in LIBWWW"
$ delete *.obj.*
$loop2:
$ file = f$search("*.c")
$ if file .eqs. "" then goto end_loop2
$ write sys$output "File : ''file'"
$ cc /nowarn/define=(multinet=1) 'file
$ if $severity 
$ then 
$    library/ins [-]libwww *.obj
$    delete *.obj.*
$ endif
$ goto loop2
$end_loop2:
$ write sys$output "Compiling source in []"
$ set def [-]
$ delete *.obj.*
$loop3:
$ file = f$search("*.c")
$ if file .eqs. "" then goto end_loop3
$ write sys$output "File : ''file'"
$ cc /nowarn 'file
$ goto loop3
$end_loop3:
$ write sys$output "Linking all files. Expect warnings."
$! Note that this is without DTM
$ ass/user sys$input sys$command
$ link/exe=xmosaic main,gui,mo-www,mo-dtm,xmx,xmx2,strdup,-
  libwww/lib,libhtmlw/lib,sys$input/opt
multinet_socket_library/share
sys$share:decw$xmlibshr/share
sys$share:decw$xmulibshr/share
$
$ write sys$output "Finished."
$ directory/size=all/prot xmosaic.exe
$EXIT:
$   EXIT

-----------------------------------------------------------------------
STRDUP.C
-----------------------------------------------------------------------
/* strdup.c -- return a newly allocated copy of a string
   Copyright (C) 1990 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */

#ifdef STDC_HEADERS
#include <string.h>
#include <stdlib.h>
#else
char *malloc ();
char *strcpy ();
#endif

/* Return a newly allocated copy of STR,
   or 0 if out of memory. */

char *
strdup (str)
     char *str;
{
  char *newstr;

  newstr = (char *) malloc (strlen (str) + 1);
  if (newstr)
    strcpy (newstr, str);
  return newstr;
}

-------------------------------------------------------------------------


Hope this information is of use.
                                   Julian

From marca@wintermute.ncsa.uiuc.edu  Thu Feb 11 11:45:45 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10845; Thu, 11 Feb 93 11:45:45 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16905; Thu, 11 Feb 1993 12:01:53 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14906
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 11 Feb 93 05:01:51 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14677; Thu, 11 Feb 93 05:03:32 -0800
Date: Thu, 11 Feb 93 05:03:32 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302111303.AA14677@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: X Mosaic update, and question.
X-Md4-Signature: 60bdc51efee7e78cb308f0ae892518eb

Just an X Mosaic update, and a question...

Update: 0.7 is almost ready to go; some more stress testing and we'll
ship.  A list of things that have changed follows.

Question: X Mosaic is starting to get big.  And it's probably starting
to slow down a little, due to a lot of the housekeeping things needed
to support the more advanced functionality, user interface components,
and so on.  We're basically developing with fast RISC boxes in mind as
the platform for running Mosaic, but we realize that many sites (in
particular, those with large numbers of machines and in
non-development environments) don't have that much power for their
user base.  At what point will we start making X Mosaic unusable for
people with less-powerful systems?  In particular, what kinds of
features, and GUI toys, are particularly expendable for performance
reasons?  And how concerned should we be about this anyway?

Anyhow, on to the current list of changes (cut straight out of X
Mosaic with the new fancy selections feature :-):

Help On Mosaic v0.7
*******************

Version 0.7 includes the following changes from version 0.6:

 o Annotations!
    o Personal only (until smart servers get written).
    o Automatic inlining of annotation pointers into documents.
    o Annotations automatically persistent across sessions
      (naturally).
    o Annotations are subsequently editable/removable.
    o Lots of neat GUI things.
 o Underlined anchors! You're gonna love this.
    o 0, 1, 2, or 3 underlines for each of unvisited and previously
      visited anchor types.
    o Solid or dashed underlines for each of unvisited and
      previously visited anchor types.
 o Application exits when all windows are closed.
 o Support for <menu> and <dir>.
 o Better support for nested lists (filled bullets, empty bullets, empty
   boxes).
 o Better selection capabilities:
    o Select by character.
    o New resource, fancySelections: if true, selections will be
      "pretty-printed" when pasted into a normal X window (with
      underlined headers, bullets for lists, etc.). This is modifiable
      per-window from the menubar also.
 o Additional command-line argument: free-standing URL will be used
   as home document, and overrides all other specifications (including
   WWW_HOME, X resource homeDocument, and -home flag). Is that
   enough ways to specify the home document??? :-)
 o Additional command-line flag -mono, for getting black&white
   fallback X defaults... you mono people out there are gonna have to let
   me know if I'm providing a decent set of mono resources. Should
   there be a distinction between -mono and -greyscale??
 o Middle button button in scrolled lists is now equivalent of
   double-clicking with left button.
 o Performance enhancement for history window's future list.
 o Fix for gopher connection port usage.
 o Fix for proper gopher and WAIS document titles.
 o Temporary fix to access Supreme Court documents on Cornell Law
   School server (if manager of that server is out there, please contact me
   -- you have a problem).
 o Option menu for document title/url display at top of window.
 o Cute icons in upper right-hand corner of windows for quick window
   ID.
 o Previous search keyword is trimmed correctly.
 o Search keyword remains in text field until search is complete.
 o New 'Clear Global History' option (to revert all anchors back to the
   unvisited color).
 o Fixed bug in hotlist geometry layout.
 o Lots of new resources:
    o confirmExit
    o ghostviewCommand
    o mailCommand
    o printCommand
    o xtermCommand
    o globalHistoryFile
    o defaultHotlistFile
    o personalAnnotationDirectory
 o Tabs now behave absolutely properly in preformatted text.
 o Fixed premature signal setup causing coredump when ctrl-c was hit
   during startup.
 o Hotlist is saved every time it's changed, to avoid losing information.
 o Busy cursor is used more often, as it should be.
 o Better handling of telnet/xterm functions (forked into background;
   browser never lands on 'telnet' document).
 o Ghostview runs in background now.
 o Changed application class name to 'XMosaic' for consistency.
 o Minor bugfixes and cleanups.

Many many thanks to all the users who have sent in comments, bug
reports, and suggestions... I hope 0.7 lives up to the promises I've
made as a result :-).

Cheers,
Marc


From fine@cis.ohio-state.edu  Thu Feb 11 17:57:16 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14587; Thu, 11 Feb 93 17:57:16 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28383; Thu, 11 Feb 1993 18:13:25 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA18211; Thu, 11 Feb 93 12:13:22 -0500
Date: Thu, 11 Feb 93 12:13:22 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9302111713.AA18211@soccer.cis.ohio-state.edu>
To: marca@ncsa.uiuc.edu, www-talk@nxoc01.cern.ch
Subject: Re: X Mosaic update, and question.
X-Mailer: Perl Mail System v1.2

>Just an X Mosaic update, and a question...
>
>Update: 0.7 is almost ready to go; some more stress testing and we'll
>ship.  A list of things that have changed follows.
>
>Question: X Mosaic is starting to get big.  And it's probably starting
>to slow down a little, due to a lot of the housekeeping things needed
>to support the more advanced functionality, user interface components,
>and so on.  We're basically developing with fast RISC boxes in mind as
>the platform for running Mosaic, but we realize that many sites (in
>particular, those with large numbers of machines and in
>non-development environments) don't have that much power for their
>user base.  At what point will we start making X Mosaic unusable for
>people with less-powerful systems?  In particular, what kinds of
>features, and GUI toys, are particularly expendable for performance
>reasons?  And how concerned should we be about this anyway?

We're mostly a bunch of 8 Meg, 12 Mips Monochrome Sun SLCs with no
local swap.  With 0.6, we get a big start-up wait (about 15 seconds),
but after that response is acceptable.  Also, I noticed that if you
don't strip the binary, it's roughly 2.5Meg.  If you do strip it, its
about 1.5Meg.  Unstripped, its bigger then an unstripped emacs;
stripped its smaller than a stripped emacs.  Imagine if someone
implemented a Motif version of emacs...  Speaking of which, you
_are_ well under the size of FrameMaker (3.1 Meg stripped).

It's hard for me to say what things could be dropped.  Everything is
just so cool.  Perhaps if you could try to figure out which things take
up all the space?

Also, could you please have it die with SIGINT?

      tom

From timbl@www3.cern.ch  Thu Feb 11 18:42:35 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15075; Thu, 11 Feb 93 18:42:35 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07306; Thu, 11 Feb 1993 18:58:45 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05809; Thu, 11 Feb 93 18:55:44 +0100
Date: Thu, 11 Feb 93 18:55:44 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302111755.AA05809@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: libWWW: New architecture
Reply-To: timbl@nxoc01.cern.ch



I am testing out the new library (2.alpha?) which has a lot of
new features largely as a result comment on this list (many from
Dan Connoly, but also others). So I thought I'd bounce the end result  
off you all as to check it for stupidities.

The driving forces are putting in MIME, and allowing the library
to be used by disparate browsers and editors and servers without
modification.

The thing is still all portable C but even more OO in style. Two new  
objects are HTStream which is something you can write to .. it  
supports

	put_character
	put_string
	write 	/* buffer */
	end
	free

Some of the machinery works character by character
(state machine parsers) but it's useful to have faster methods when
there is no characterwise intervention.

This is to allow MIME encoding pipelines to be built, as well as the
existing facilities to be more flexible.  Streams stack, and freeing
the top of the stack frees off the stack.  As a side issue the stream
idea allows the difference between sockets and FILE * to be overcome
cleanly without the hacks necessary on some systems which shall be  
nameless. Streams subclasses exist to

	write to a FILE *
	write to a socket
	parse an SGML file of (dtd)
		pushing the results into (structured)
	convert plain text to valid HTML -> other stream
	format a (structured) described by (dtd) as plain text
		pushing the results -> other stream
	parse a MIME document (to come)

There is a different creation routine for each case.
The "structured" object is a subclass of HTStream called  
HTStructured. It is a sort of rich stream, accepting also the methods

	start_element(element_number, attributes)
	end_element(elemenet_number)
	put_entity(entity_number)

Obviously an HTStructured thing has a pointer to a DTD structure
so that the element numbers and entity numbers make sense.
Elements and entities are passed around as numbers so that the
string lookup is only done once if at all.

Structued subclasses objects exist to

	Pretty-print structued text to plain text stream
	Generate SGML for the stream, given its DTD
	Present the structured object to the user

This last one is the one you browser writers hook into
and it should be alot easier than tangling with styles.

You can also of course regenerate the stream from your
widget and use the HTML generator structured object
to write your file back to the server. (Thisis to
encourage more hypertext editors out there!)

There is another class of object called a protocol.
It supports GET and will soon support PUT and other
useful things.  Current subclasses handle

	http
	news
	gopher
	files and directories
	FTP files and directories
	WAIS without gateway will come

Typically News and Gophe protocol
objects ask for a HTStructured object (which may
in fact go to a display, or a client if we are a server, or
a file etc through a small stream stack) and build it.
Although the structured object is defined by a DTD,
and has an SGML model, there is no generation of SGML from
news, etc within a browser for speed (unless the user wants
to save something as SGML).

Other things .. a common interface for alerts, confirmation and  
questions to the user from the bowels of the library,  and sometime a  
spinning callback for geting out of
those long timeouts..

Constructive criticism welcome, I'll put the code out
when I can.

Tim Berners-Lee




From rmah@panix.com  Thu Feb 11 23:34:03 1993
Return-Path: <rmah@panix.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18862; Thu, 11 Feb 93 23:34:03 MET
Received: from sun.Panix.Com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22923; Thu, 11 Feb 1993 23:50:13 +0100
Received: by sun.Panix.Com id AA15963
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Thu, 11 Feb 1993 17:50:03 -0500
Date: Thu, 11 Feb 1993 17:48:51 -0500 (EST)
From: Robert Mah <rmah@panix.com>
Subject: Please add me to the mailing lIst
To: www-talk@nxoc01.cern.ch
Message-Id: <Pine.3.05.9302111751.A15919-9100000@sun.panix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

My e-mail address is rmah@panix.com. Please add me to the mailing list
discussing W3.

Thanks,
Rob

[----------------------------------------------------------------------]
[ Robert S. Mah   | Voice: 212-947-6507   | "Every day an adventure,   ]
[ One Step Beyond | EMail: rmah@panix.com |  every moment a challenge" ]
[----------------------------------------------------------------------]



From marca@wintermute.ncsa.uiuc.edu  Fri Feb 12 04:35:41 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21538; Fri, 12 Feb 93 04:35:41 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06932; Fri, 12 Feb 1993 04:51:51 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11023
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Thu, 11 Feb 93 21:51:43 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:rkatz@darpa.mil id AA20861; Thu, 11 Feb 93 21:53:19 -0800
Date: Thu, 11 Feb 93 21:53:19 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302120553.AA20861@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: X Mosaic 0.7 released
X-Md4-Signature: dfeb02d3c78b96c5a3c700be40e36854

Shazam and kaboom -- beta version 0.7 of NCSA's Motif-based networked
information systems and World Wide Web browser, X Mosaic, is hereby
released:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/xmosaic-0.7.tar.Z

This release of X Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).
  DEC Ultrix.

Binaries for these platforms are available:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/binaries-0.7

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working binaries
are welcome.)  Documentation is available online, but is temporarily
out of date (I'll probably bring it up to date this weekend).

Changes since 0.6 include:

 o Annotations!
    o Personal only (until smart servers get written).
    o Automatic inlining of annotation pointers into documents.
    o Annotations automatically persistent across sessions (naturally).
    o Annotations are subsequently editable/removable.
    o Lots of neat GUI things.
 o Underlined anchors! You're gonna love this.
    o 0, 1, 2, or 3 underlines for each of unvisited and previously
      visited anchor types.
    o Solid or dashed underlines for each of unvisited and previously
      visited anchor types.
 o Application exits when all windows are closed.
 o Support for <menu> and <dir>.
 o Better support for nested lists (filled bullets, empty bullets, 
   empty boxes).
 o Better selection capabilities:
    o Select by character.
    o New resource, fancySelections: if true, selections will be
      "pretty-printed" when pasted into a normal X window (with
      underlined headers, bullets for lists, etc.). This is modifiable
      per-window from the menubar also.
 o Additional command-line argument: free-standing URL will be used as
   home document, and overrides all other specifications (including
   WWW_HOME, X resource homeDocument, and -home flag). Is that
   enough ways to specify the home document??? :-)
 o Additional command-line flag -mono, for getting black&white fallback
   X defaults... you mono people out there are gonna have to let me know if
   I'm providing a decent set of mono resources. Should there be a
   distinction between -mono and -greyscale??
 o Middle button button in scrolled lists is now equivalent of
   double-clicking with left button.
 o Performance enhancement for history window's future list.
 o Fix for gopher connection port usage.
 o Fix for proper gopher and WAIS document titles.
 o Temporary fix to access Supreme Court documents on Cornell Law
   School server (if manager of that server is out there, please contact me --
   you have a problem).
 o Option menu for document title/url display at top of window.
 o Cute icons in upper right-hand corner of windows for quick window ID.
 o Previous search keyword is trimmed correctly.
 o Search keyword remains in text field until search is complete.
 o New 'Clear Global History' option (to revert all anchors back to the
   unvisited color).
 o Fixed bug in hotlist geometry layout.
 o Lots of new resources:
    o confirmExit
    o ghostviewCommand
    o mailCommand
    o printCommand
    o xtermCommand
    o globalHistoryFile
    o defaultHotlistFile
    o personalAnnotationDirectory
 o Tabs now behave absolutely properly in preformatted text.
 o Fixed premature signal setup causing coredump when ctrl-c was hit
   during startup.
 o Hotlist is saved every time it's changed, to avoid losing information.
 o Busy cursor is used more often, as it should be.
 o Better handling of telnet/xterm functions (forked into background;
   browser never lands on 'telnet' document).
 o Ghostview runs in background now.
 o Changed application class name to 'XMosaic' for consistency.
 o Minor bugfixes and cleanups.

Although this is beta software, I'm looking more for feedback on
design and functionality than bug reports right now -- down the road
the bulk of the program will be rewritten in C++ anyway, so don't take
the current code too seriously.  But bug reports are welcome too.  New
releases will probably come out about every 7-14 days until 1.0
arrives.

Finally, thanks again to everyone who's contributed comments and bug
reports, and please... keep 'em coming.

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From romig@cis.ohio-state.edu  Fri Feb 12 18:12:06 1993
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00744; Fri, 12 Feb 93 18:12:06 MET
Received: from brachiosaur.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02771; Fri, 12 Feb 1993 18:28:17 +0100
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA01807; Fri, 12 Feb 93 12:28:10 -0500
Date: Fri, 12 Feb 93 12:28:10 -0500
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9302121728.AA01807@brachiosaur.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Cc: p.lister@cranfield.ac.uk, chen@cds002.cebaf.gov
Subject: CIS gateways, waisgate patches are available now

I just made our man page, RFC and info gateways available for
anonymous ftp (ftp.cis.ohio-state.edu, /pub/www/cis.tar.Z).  I've
included our patches to WAISGate that allow it to use a rules file to
remap document addresses to other gateways.  There's a brief README
and a longer about_this_cobweb.html that describe how things fit
together.  

The man page converter works on the formatted versions of the man
pages, so that we don't have to deal with the various macro packages
as well as eqn and tbl.  We create the HTML versions of all of the man
pages and store those somewhere for efficiency (time, not space!).
The converter turns man page and rfc references into anchors.

The rfc converter works on the fly - it retrieves things from our
anonymous ftp repository, uncompresses them, and converts them into
html, turning things that look like rfc references into anchors.

The infogate daemon is a modified version of the info2html script
written by Eelco van Asperen <evas@cs.few.eur.nl>.  Like the rfc
converter, it works on the fly.  References look like "tar.info",
which would retrieve the node named "Top" from the file tar.info, or
"tar.info,Why", which refers to the node named "Why".

Have fun, let me know if you find bugs.  Since this stuff is available
now, I'd appreciate it if sites could set up their own man page
gateways - we don't have a way to restrict access right now, but I am
somewhat concerned about licensing violations and all that.  We plan
to leave the rfc, ien, and emacs info gateways open, and you're
welcome to use them.

It isn't mentioned much in the docs, but the Makefile includes the
commands we use to index the Usenet FAQ's from news.answers.  You
might find that useful as well.

--- Steve

From marca@wintermute.ncsa.uiuc.edu  Mon Feb 15 04:51:27 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05350; Mon, 15 Feb 93 04:51:27 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07643; Mon, 15 Feb 1993 05:08:18 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22097
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Sun, 14 Feb 93 22:08:16 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA04065; Sun, 14 Feb 93 22:09:58 -0800
Date: Sun, 14 Feb 93 22:09:58 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302150609.AA04065@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: X Mosaic 0.8 released
X-Md4-Signature: 3357bd9c76b53a8bdb32c82bfde27cce

With a bang and a whimper, beta version 0.8 of NCSA's Motif-based
networked information systems and World Wide Web browser, X Mosaic, is
hereby released:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/xmosaic-0.8.tar.Z

This release of X Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).
  DEC Ultrix.

Binaries for these platforms are available:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/binaries-0.8

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working binaries
are welcome.)  Documentation is available online, but is temporarily
out of date (I'll probably bring it up to date this weekend).

Changes since 0.7 include:

 o Telnet access is enabled for IBM systems (and others that don't define
   'unix' by default).
 o TN3270 access is now available (probably will only work on IBM
   systems).
 o Underline setting now carries from window to window like it should.
 o Stupid little bugs nailed in open local file routines.
 o More stupid little bugs nailed in opening multiple windows.
 o Fixed buglet with text fields on some platforms.
 o Most plaintext documents can now be annotated (except for results of
   WAIS queries and those that use <plaintext> explicitly).
 o Annotate and Edit Annotation menubar entries disabled for stupid Ultrix,
   since the annotation window causes a spurious BadWindow error for no
   apparent reason at all.
 o Better colors (including brighter colors on non-SGI platforms).
 o Makefile option to compile with mono colors as the default.
 o Revised copyright notice.
 o A few random bugfixes and cleanups.

Although this is beta software, I'm looking more for feedback on
design and functionality than bug reports right now -- down the road
the bulk of the program will be rewritten in C++ anyway, so don't take
the current code too seriously.  But bug reports are welcome too.  New
releases will probably come out about every 7-14 days until 1.0
arrives.

Finally, thanks again to everyone who's contributed comments and bug
reports -- keep 'em coming.

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Mon Feb 15 05:20:48 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05557; Mon, 15 Feb 93 05:20:48 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09539; Mon, 15 Feb 1993 05:37:38 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23008
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Sun, 14 Feb 93 22:37:37 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA04545; Sun, 14 Feb 93 22:39:19 -0800
Date: Sun, 14 Feb 93 22:39:19 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302150639.AA04545@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: X Mosaic 0.8 released
In-Reply-To: <9302150609.AA04065@wintermute.ncsa.uiuc.edu>
References: <9302150609.AA04065@wintermute.ncsa.uiuc.edu>
X-Md4-Signature: 22c593d547445fa6e682eb6b1dbc1ad8

Anybody who pulled down 0.8 binaries already (by 10:40PM CST on
Sunday) is encouraged to do so again, as one last-minute bug was just
fixed.

Thanks, and sorry for any inconvenience,

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From M.T.Hamilton%loughborough.ac.uk@mailhost.lut.ac.uk  Thu Feb 18 07:45:12 1993
Return-Path: <M.T.Hamilton%loughborough.ac.uk@mailhost.lut.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16138; Thu, 18 Feb 93 07:45:12 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17732; Thu, 18 Feb 1993 08:02:10 +0100
Date: 17 Feb 93 18:04
From: Martin Hamilton <M.T.Hamilton@loughborough.ac.uk>
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Reply-To: Martin Hamilton <M.T.Hamilton@loughborough.ac.uk>
Message-Id: <Pine.3.05.9302171704.D1502-b100000(a)genie.lut.ac.uk>
Subject: High performance networking & distributed systems archive

RFC-822-HEADERS:
X400-Recipients: non-disclosure:;
Original-Sender: Martin Hamilton <M.T.Hamilton@loughborough.ac.uk>
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
MIME-Version: 1.0

==================
Announcement
============
Access to the high performance networking & distributed systems archive at
Loughborough is now available on an experimental basis via the World-Wide
Web system.  Its address is:

   http://genie.lut.ac.uk:80/

Please feel free to add this server to any lists/bookmarks you may keep of
this sort of thing.  See below for feedback & bug reporting.


About the archive
=================
(from http://genie.lut.ac.uk/DS-Archive/HighPerformanceNetworking.html)

This archive contains information which may be relevant to high speed
networking and distributed systems researchers - papers and technical
reports authored at this site and elsewhere, details of forthcoming
conferences, contact names in the field, general notices, e.g. job adverts
and new journals, details of relevant publications, overviews and
documentation of significant distributed computing projects plus freely
distributable packages and bibliographies.

Some of the information in this archive is copyright protected - where
this is the case it is indicated.

The archive is accessible through gopher (gopher://hill.lut.ac.uk),
anonymous ftp (ftp://hill.lut.ac.uk), and now directly via World-Wide Web
(http://genie.lut.ac.uk).


Feedback
========
The archive is run on a volunteer basis by Jon Knight, please contact him
if you have any comments about the archive contents or would like to
contribute to it.

The hypertext markup was produced by Martin Hamilton.  Please contact him
if you have any trouble with WWW access, or any suggestions.

Jon Knight <J.P.Knight@lut.ac.uk>
&
Martin Hamilton <M.T.Hamilton@lut.ac.uk>



From murphy@dccs.upenn.edu  Thu Feb 18 21:30:33 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26105; Thu, 18 Feb 93 21:30:33 MET
Received: from NOC2.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19909; Thu, 18 Feb 1993 21:47:29 +0100
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA29887; Thu, 18 Feb 93 15:47:24 -0500
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA25717; Thu, 18 Feb 93 15:47:20 -0500
Date: Thu, 18 Feb 93 15:47:20 -0500
From: murphy@dccs.upenn.edu
Posted-Date: Thu, 18 Feb 93 15:47:20 -0500
Message-Id: <9302182047.AA25717@lam.dccs.upenn.edu>
To: engineering@dccs.upenn.edu, nav@dccs.upenn.edu, www-talk@nxoc01.cern.ch
Subject: Discussion about a new nntp newsgroup - comp.infosystems.www


Here's my two cents worth:

Path: netnews.upenn.edu!scotty.dccs.upenn.edu!murphy
From: murphy@scotty.dccs.upenn.edu
Newsgroups: news.groups
Subject: RFD: comp.infosystems.www
Message-ID: <730067983.25662@scotty.dccs.upenn.edu>
Date: 18 Feb 93 20:39:46 GMT
Sender: news@netnews.upenn.edu
Lines: 82
Nntp-Posting-Host: lam.dccs.upenn.edu

Tom Fine writes:
>> The purpose of this group will be to exchange information and ideas
>> regarding the use, design and development of the World Wide Web, and
>> the information in the Web.
>> 
>> World Wide Web is an information system which is hypertext based.  It
>> will currently interface with both WAIS and gopher systems.  Future
>> plans include a move toward the use of MIME documents.  There are a
>> number of applications already in place for using this information
>> system.

   Thank you for proposing the WWW group.  Let me know when
   you plan to vote.

   I agree on the name of the group (comp.infosystems.www).

   I agree that part of the purpose should be discussing the
   use, design, and development of WWW (double-ewe three)
   and discussing what information that is/will be/should be
   available in the Web.

I would also like to see:

* Announcements about what software is available, how to get
   it, how stable it is, who worked on it, where to report
   problems to or get help from, etc.  I realize that this
   information is also in the Web itself -- perhaps someone
   can come up with a tool which automatically groks the
   appropriate portions of WWW hypertext and posts it once a
   month the comp.infosystems.www, for those who don't
   already have the ability to get to the Web but who are
   interested in it?

* Discussion of how to package WWW software so that it is
   trivial to build and install on as many platforms as
   possible, including Macintosh and other microcomputers?
   By "software", I mean:

       1) WWW hypertext browsing clients,
       2) WWW hypertext servers,
       3) WWW hypertext preparation tools -- utilities &
       clients which make it possible for a non-technical
       clerical staff person to write and provide
       information in the Web.

   There are also gateway programs to other sources of info
   (e.g. FTP, NNTP, TechInfo), but they don't necessarily
   have to run on as wide a variety of platforms as the
   three types of tools above.  But they should be easily
   installable by a Unix sys admin type person.

* Discussion of comparisons between WWW and Gopher as well
   as other CWIS technology, both on a technical level and
   on a non-technical level.  For example:

   1) What functionality do you get from WWW that you don't
   get from the other cwis info systems?

   2) Are they competing or complimentary technologies?

   3) Why has Gopher caught in the Internet on while WWW has
   not?

   4) How can folks working on WWW make WWW more accessible
   to people who are not part of the High Energy Physics
   research area -- how to target a bigger audience so that
   if there is something worthwhile in WWW but not in
   Gopher, someone else beside me and a few others will know
   about it!


Clearly I think that WWW has more to opher than Gopher

(whoops, please forgive my spelling, I meant 'offer'!  ;-)


LAM

Linda A Murphy                                  Internet: murphy@dccs.upenn.edu
Network Engineering                  Data Communications and Computing Services
University of Pennsylvania                                       (215) 898-9534


From fine@cis.ohio-state.edu  Thu Feb 18 22:16:46 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26970; Thu, 18 Feb 93 22:16:46 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27503; Thu, 18 Feb 1993 22:33:45 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA04980; Thu, 18 Feb 93 16:33:57 -0500
Date: Thu, 18 Feb 93 16:33:57 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9302182133.AA04980@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: RFD for newsgroup
X-Mailer: Perl Mail System v1.2

The request for discussion for comp.infosystems.www has been posted.
Please carry on all discussions about the newsgroup creation in
news.groups.

If it looks like there are going to be any major arguments (like about
the newsgroup name), we should take them off-line immediately, settle
them quickly, and resume the discussion, so that they don't delay the
creation of the newsgroup.

	tom

From VMNETNEW@slacvm.slac.stanford.edu  Tue Feb 23 00:30:25 1993
Return-Path: <VMNETNEW@slacvm.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12549; Tue, 23 Feb 93 00:30:25 MET
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01187; Tue, 23 Feb 1993 00:47:31 +0100
Received: from SLACVM.SLAC.STANFORD.EDU (MAILER@SLACVM) by
 SCS.SLAC.STANFORD.EDU with PMDF#10283; Mon, 22 Feb 1993 10:05 PDT
Received: by SLACVM (Mailer R2.08 R208004) id 0765; Mon, 22 Feb 93 10:00:55 PST
Date: Mon, 22 Feb 1993 17:10:13 GMT
From: marcus@x4u.desy.de (Marcus Speh)
Subject: Info on Hypertext format ?
Sender: VMNETNEW@slacvm.slac.stanford.edu
To: WWW-TALK@nxoc01.cern.ch
Message-Id: <MARCUS.93Feb22181013@x4u.desy.de>
X-Envelope-To: WWW-TALK@INFO.CERN.CH
Newsgroups: slac.www.talk,slac.www.interest
Path: slacvm!unixhub!dxcern!dscomsa!marcus
Lines: 449
X-Sender: usenet@dscomsa.desy.de (usenet)
Organization: Deutsches Elektronen-Synchrotron, Hamburg, Germany.

Someone from the DESY computer centre assured me
that this was the Hyper-FAQ to the WWW-wizards. I hope
to pass your kill-file nevertheless. [The same person
did not have any clue how to answer my question.]
     
I wanted to start a FAQ for one of the hepnet.* newsgroups.
Since the freeHEP server at freehep.scri.fsu.edu is tied to
WWW, and it also archives the hepnet hierarchy, my question
is: how do I format my FAQ in Hypertext?
     
	Besides the question, I also have an information to
give: on the faq-maintainers mailing list, there is a BIG
debate right now on standard formats for FAQs. The discussion
was started by Thomas A. Fine's posting to the list which I
repost here--though I don't assume that the WWWmasters haven't
heard about it. In the future, the project he outlines may be
the cheapest way of getting your FAQ into Hypertext, but right
now the possibility does not seem to exist.
     
I'd like to know what you guys think.
     
  --Marcus Speh
  --<marcus@x4u.desy.de>
     
     
     
------------------------------ cut here -----------------------------
From: Thomas A. Fine <fine@cis.ohio-state.edu>
To: faq-maintainers@MIT.EDU
Subject: Converting FAQs to hypertext
Date: Fri, 12 Feb 93 20:55:55 -0500
     
     
I'm trying to develop a project which will convert FAQs into hypertext
documents under the World Wide Web system.  I have a specification,
which is included, for a standard format for FAQs such that they can
easily be translated into hypertext documents.  We will translate all
conforming FAQs at Ohio State, and make them available to the world in
hypertext.  I'd like to let everyone have a look at what I'm doing, so
you can point out problems before I go ahead and do it.
     
First I'd like to make certain things clear:
     
  * We can deal with more than one format.  If you find what I've done
    too restrictive, we can probably develop software that will turn
    your own format into hypertext.  I would encourage the development
    of several different formats, as long as "several" is substantially
    less than the total number of news.answers postings.
     
  * The development of additional formats and software is fairly easy.
    When the original concept was developed, I wrote perl scripts to
    convert comp.lang.perl and comp.unix.questions FAQs to hypertext
    (different software for each), in about 3 hours.  Software for
    the format I'm recommending was also fairly easy, although it has
    been tweaked on a fair bit, so it was more than three hours.
     
  * The format that I'm proposing is very flexible, IMHO.  It is designed
    for generic documents as well as lists of questions and answers.
     
  * My format preserves most of the text formatting of the original
    document.
     
  * I'm very open to suggestions, volunteers, etc.
     
  * I don't want to make conformance to ANY format a posting requirement.
    If you choose not to conform to anything, you just won't have your
    posting turned into hypertext.
     
  * If you know about WWW and want to supply your FAQ to us directly as
    hypertext, we can make arrangements for that.
     
  * Submission of FAQs to us will be through two different methods.  The
    most painless is post it to news.answers -- we'll scan it and
    convert anything we find that conforms (we may scan other
    newsgroups as well).  The other method will be to send us mail to
    <an address that hasn't been set up yet>.  This method will provide
    faster response that you might want if you are modifying your FAQ
    and want to see it in hypertext.
     
  * The conversion software will be available (this is a requirement for
    contributed software and formats).  Currently, we have software which
    converts a document, but we don't have any software for scanning news
    or catching mail.  Fairly trivial though.
     
Background
     
World Wide Web is a networked information retrieval system, with its own
hypertext documents at its base.  Even though WWW is still under development
much of it is already solid, and there are already several applications
and a nice amount of information available.  WWW can interface with both
WAIS and Gopher, and interfaces with other systems have been prototyped.
It is ideal as a local help system, as code already exists for converting
man pages, RFCs, emacs info documents, and lots of other things into
hypertext.
     
Currently, WWW only supports hypertext documents, although plans are being
made for a protocol which will deal with all MIME document types.  Lots
of other ideas are being passed around and there's still much to be done.
Volunteers are welcome.  There is a mailing list; subscribe via
www-talk-request@nxoc01.cern.ch.  Hopefully we will have our own newsgroup
soon.
     
What follows is several things in one:  It is a rough draft of what will
be posted monthly to news.answers describing this project.  It is a
description of the format.  And it conforms to the format, and therefore
serves as an example.  A formatted version is available if you grab the
software (information is available in the document).
     
I'd very much prefer that you look at the hypertext results before
commenting.  If you don't want to go through the hassle of compiling
the software, XMosaic is available in binary form (see below).
     
	 tom
     
----------------------------------------------------------------------------
     
Path: cis.ohio-stae.edu
From: fine@cis.ohio-state.edu (Thomas A Fine)
Newsgroups: news.misc,comp.infosystems,comp.answers,news.answers
Subject: The World Wide Web FAQ Project
Followup-To: comp.infosystems
Date: 11 Feb 1993 15:08:54 -0500
Expires: 11 Mar 1993 00:00:00 GMT
Summary: Information on the conversion of FAQs to WWW hypertext documents
Organization: The Ohio State University Dept. of Computer and Info. Science
Lines: 240
Message-ID: <asdfINN123@soccer.cis.ohio-state.edu>
NNTP-Posting-Host: soccer.cis.ohio-state.edu
Content-Type: text/x-usenet-FAQ;
	version=1.0;
	title="Hypertext FAQs"
     
Archive-name: hypertext-faq-format
Last-modified: 1993/02/11
     
Statement of Intent
-------------------
     
FAQs are a wonderful resource, but hard to work through.  This project
is an attempt to unite the volume of information found in news.answers
and other newsgroups with The World Wide Web, a system for networked
information retrieval.
     
World Wide Web uses hypertext documents and a network transport
protocol to build a huge web of information all over the world.
Accessing documents is as easy as clicking on a mouse.  (there are
tty-based interfaces available too).  WWW (as we like to call it, for
obvious reasons) also knows how to talk to other services including
WAIS and Gopher.  There are plans to extend the document type to be a
MIME document, of which WWW's hypertext (called HTML, for HyperText
Markup Language) will be one part.
     
Since we don't expect everyone to learn HTML (although it is fairly
straight forward), we have designed a format that can be used for
news.answers (et. al) documents and FAQs which will allow us to
automatically convert them to hypertext.  The format has been designed
to allow FAQ maintainers to providing conforming news articles with
minimal changes.  Note that while this is currently the only format,
it is possible to support multiple formats.
     
The format is described in following sections.  Note that this article
itself conforms to the format, and a formatted version is available thru
the Web (See "Getting WWW Software").
     
Getting WWW Software
--------------------
     
To see what this document looks like after it's been formatted, grab
yourself some software and give it a try.  The software is available
via anon ftp from various places.  There are several different packages
available:
     
ftp.ncsa.uiuc.edu in /Web/xmosaic
  xmosaic-0.7.tar.Z                X11 browser - fairly new, very nice.
				   (binary available in the dir binaries-0.7)
     
info.cern.ch in /pub/www/src
  tkWWW-0.4.tar.Z                  X11 browser - Tcl/Tk implementation
  viola920730.tar.Z                X11 browser - a bit out of date
  midaswww-1.0.tar.Z               X11 browser - new version expected soon
  WWWLineMode_1.3b.tar.Z           dumb terminal browser
  WWWNextStep_0.15.tar.Z           A NextStep browser and editor
  www_and_frame-0.2.tar.Z          A package for editing HTML with FrameMaker
  [my tty-based browser and editor will hopefully be included soon]
     
To find the FAQ stuff in the Web, you will need the following Universal
Resource Locator, which can be typed into your browser in an application
specific way (the XMosaic author promised to include a built-in link to
the information):
     
  "http://www.cis.ohio-state.edu:80/hypertext/faq/usenet/FAQ-List.html"
     
The hypertext documents produced from conforming FAQs uses few of the
features of html, and so will look rather plain looking.  If you would
like more information, start by getting the software and rummaging
around the web.  You can also get on the www-talk mailing list by
sending to www-talk-request@nxoc01.cern.ch.  Lastly, you could bug me
with mail if you were really desparate.  If after seeing what this
system can do, you decide you want to provide your documentation
directly as hypertext, contact me (fine@cis.ohio-state.edu) and we'll
work out the details.  Send questions about this format to the same.
     
The Header Format
-----------------
[Note that when "article" is used, a single article is being referred to.
 When "posting" is used, the entire set of articles are being referred to.]
     
In order to be recognized as a conforming article, it must use MIME
headers as follows:
     
For single-article postings, the header must include:
     
  Content-type: text/x-usenet-FAQ
     
In addition, two fields can be added to this line:
     
  version=1.0
     
This indicates the version number to process the file with.  If absent,
version 1.0 will be assumed.  The other field:
     
  title="The title of the article"
     
This will be used in various places in the conversion to hypertext.  If
not present, the subject line (in its entirity) of the first article
of the posting will be used as the title of that posting.  The posting
title must be unique.
     
Note that when attributes are used, semicolons should also be used
after the Content-type, and after each attribute except for the last:
     
  Content-type: text/x-usenet-FAQ;
	  version=1.0;
	  title="Blarg"
     
For multiple-article postings, the Content-type information as described
above should be the first thing found in the BODY of the first article
of the posting (it can be included in the secondary header with
Archive-name and Version lines found in many FAQs).  In addition, each
article header must contain the MIME multipart information:
     
  Content-type: message/partial;
	  number=1;
	  total=3;
	  id="totally-unique-id-string"
     
The "total" attribute is only required on the final part of the document.
The id will be the same for each article in the posting, but is supposed
to be guarenteed unique among postings.  A format similar to the typical
news message id is recommended, e.g. something including the poster and
the posting host along with an id unique to that host (the time).
     
The Body Format
---------------
The content is fairly free-form.  It can contain any of the following
"sections"
     
    Documents
    Ignored text
    Questions/Answers
     
The Ignored text is stripped out first, then the articles are appended,
together.  The converter then expects to see a series of "Documents"
and or "Questions/Answers" sections.  These are all described
below if you are in text, or are links at the top level, if you
are in hypertext.
     
These will be formatted into a top level hypertext document with links
to all the other documents.  The software will attempt to handle simple
subsets of this format accordingly; for instance if a posting consists
entirely of a single questions/answers section, the conversion will
show the list of questions as the top level of the hypertext (this
hasn't been implemented yet).
     
Each of the Documents or Questions/Answers sections must be started
with a blank line, a left-justified title line, and a left-justified
line of dashes to underscore the title.  The only exception is a posting
which is either a single document, or a single set of questions/answers,
in which case no such title is required anywhere.  Also, the first
section does not require such a title; if it is left out, the title
"Introduction" will be used.
     
Documents
---------
A document section is just any section of text, separated by the section
title described previously, and not matching the Questions/Answers form.
This means you must make sure no line in a document section starts with
a number followed by a right parenthesis.
     
This section on "Documents" you are reading now will be an entire
hypertext document after conversion (this may not be the best
choice for the hypertext layout, but makes a good example.)
     
Ignored Text
------------
Some text can be ignored in the posting.  Typically in news articles, you
may need to include some redundant text in every article, that won't be
needed in the hypertext.  Also some information, like how to unpack the
articles might be unneeded.  Lists of questions are another example, since
the conversion software builds this list from the questions themselves.
     
To mark text as uneeded, it should be surrounded by lines consisting only
of "--".
     
An example starts here:
--
This text won't show up in the hypertext.
--
That was the example.  Note that if you are looking at the hypertext, there
was nothing between the start and the end, because it was ignored.
     
Important note:  Text will stop being ignored at the end of each ARTICLE,
even if there is no ending "--".  (This can be used to  eliminate
signatures, since lots of people use the "--" there anyway.)
     
Questions/Answers
-----------------
Any section which contains a left justified number followed by a right
parenthesis and then white space will be treated as a Questions/Answers
section.  The number can contain several decimal points, so "1.4.11) "
is an acceptable starting string for a question.
     
The requirements for this section can be summed up as:
* There must be a blank line before and after each question.
* All answer text must be indented from the left margin.
* All questions must be have no indentation on the first line.
* All questions start with a number, a right parenthesis, and some whitespace.
     
There can be a section title for some portion of the questions.  It
must have no indentation, and must be preceded by blank line, and
followed by a blank line and then a question.  It cannot start with a
number!
     
Creating Additional Links
-------------------------
Anywhere where the string ``(See "document title")'' occurs, a link
will be created to that document if it exists.  This link is just
an example: (See "Questions/Answers").
     
If you are going to do this, make sure you refer to a document title
that is unique.  All non-unique references will be ignored.
     
Questions and Answers
---------------------
     
Section 1.  The Documents
     
1.1) What is the documents section for?
     
  For introductions to newsgroups, introductions to FAQs, and other
  postings of interest for a newsgroup that don't fall into the question
  and answer scheme.
     
1.2) What if I have only a single document (and no questions)?
     
  Then make sure there are zero or one document titles (a title line
  followed by a line of dashes), and nothing that looks like the start
  of a Question/Answer section.
     
     
Section 2.  The Question/Answer portion of the FAQ
     
2.1) What if my question is too
     long to fit on one line?
     
  Just make sure you don't put a blank line in the question.  The software
  will deal correctly.
     
2.2) How do you distinguish section titles from questions, if both
start at the beginning of the line?
     
  Sections titles can not start with numbers.  Questions have to start with
  a number, followed by a right parenthesis and then whitespace.
     
2.3) Where, exactly, should I put blank lines
     
  A blank line has to occur before and after each question.  Blank lines
  must also occur before each section title.  All other blank lines will
  be preserved.
     
Section 3.  Other questions
     
3.1) Can I create additional links?
     
  Yeah, just put in text that looks like this:
     
      (See "Creating Additional Links")
     
  It must refer to a Document title or Q/A title somewhere in the posting.
     
3.2) Can I do tree structuring?
     
  The format is converted into a three level tree, but you can't impose
  any other structure on it, unless you want to provide your documentation
  directly as hypertext.
     
3.3) What if I don't like your format?
     
  Come up with your own.  We may even help you write the software to convert
  it.  Since the format requires a version number, its easy for us to support
  multiple versions at the same time.
     
  If you do decide to create your own format, it would be best if it would
  be general enough for more than your own postings, as we think it would
  be a little cumbersome having a separate piece of software for every
  different posting.
     
3.4) Since this uses MIME headers, will there be an application
     to read such documents with a MIME news/mail reader?
     
  Eventually, but not now.
     
3.5) Why didn't you use SeText format?
     
  Because we wanted to get this done quickly, and SeText isn't a fully
  realized standard yet.  Also, its not clear that SeText will handle
  all the functionality we needed.  It is possible that future versions
  will be based on SeText, or at least include some of its features.
     
  BTW SeText is a pseudo-markup language for text documents.  All the
  markups are chosen as items which won't interfere with the reading
  of the document in an unformatted state.  Neat stuff, but not ripe
  yet.
     
About this posting
------------------
This is posted monthly to news.answers, comp.answers, comp.infosystems,
and news.misc.  If changes are made between posts, no differences will
be posted as the formatted and unformatted versions available through
the web are assumed to be the latest.
     
Send comments and corrections about this posting to fine@cis.ohio-state.edu.
Please send a context diff, or an entire modified version of the file.
     
--
------------------------------------------------------------------------------
| Thomas A. Fine    | fine@cis.ohio-state.edu   | 2036 Neil Avenue Mall      |
| CIS Staff         | (614) 292-7325            | Columbus, Ohio 43210       |
| The Ohio State University - Department of Computer and Information Science |
     
     
     
--
       //////////////////////////////////////////////////////////
      //   marcus@x4u.desy.de   //  Marcus Speh               //
     //  [131.169.30.33]       //  II. Inst. f. Theor. Phys. //
    // Phone: (040) 8998-2260 //  Luruper Chaussee 149      //
   // FAX: (040) 8998-2267   //  2000 Hamburg 50 / Germany //
  //////////////////////////////////////////////////////////

From fine@cis.ohio-state.edu  Tue Feb 23 01:47:23 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13110; Tue, 23 Feb 93 01:47:23 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06584; Tue, 23 Feb 1993 02:04:31 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA11086; Mon, 22 Feb 93 20:05:11 -0500
Date: Mon, 22 Feb 93 20:05:11 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9302230105.AA11086@soccer.cis.ohio-state.edu>
To: marcus@x4u.desy.de, www-talk@nxoc01.cern.ch
Subject: Re: Info on Hypertext format ?
X-Mailer: Perl Mail System v1.2

>Someone from the DESY computer centre assured me
>that this was the Hyper-FAQ to the WWW-wizards. I hope
>to pass your kill-file nevertheless. [The same person
>did not have any clue how to answer my question.]
>     
>I wanted to start a FAQ for one of the hepnet.* newsgroups.
>Since the freeHEP server at freehep.scri.fsu.edu is tied to
>WWW, and it also archives the hepnet hierarchy, my question
>is: how do I format my FAQ in Hypertext?
>     
>	Besides the question, I also have an information to
>give: on the faq-maintainers mailing list, there is a BIG
>debate right now on standard formats for FAQs. The discussion
>was started by Thomas A. Fine's posting to the list which I
>repost here--though I don't assume that the WWWmasters haven't
>heard about it. In the future, the project he outlines may be
>the cheapest way of getting your FAQ into Hypertext, but right
>now the possibility does not seem to exist.

Ha!  You can't get rid of me.  Well, I'll answer your question, and
then for all the WWW people out there, I'll give a project status.

The software to handle the format I posted already exists.  If you
want to conform to that, you can do that, and I can send you the software.

Or you can rummage through the web and figure out how to format things
yourself.  It's not a huge amount of material, but there are some finer
points you have to know.

Or you can wait until I finish my editor.  At this rate, who knows when
that will be.  I haven't had time to work on it in a month, even though
it is 90 percent complete.  It certainly won't be until after I get
the FAQ stuff relatively settled (see below).

Status
------
Well, I sent my proposed format to the faq-maintainers mailing list to
see what sort of reaction I would get.  Ouch.  Not all bad though.  Some
people may choose to use my format.  At any rate, many people pointed
me at the digest format, while other unsubscribed from the mailing list.
:-)   :-(

The digest format is a format for encapsulating lots of little articles
into one big article.  It was designed for mailing lists (See RFC 1153).
Its use for FAQs is dubious at best (each question becomes a separate
article).  At any rate no one conforms precisely (or in the ballpark)
to the standard.  And 90 percent don't try to use it at all.  Still that
seems to be the direction people are going.

So, I'm working up some conversion software that will deal with their
whimsical excuse for the Digest format.  It will buy me about 30-40
FAQs right off the bat, and hopefully help sell the idea.

       tom

From marca@wintermute.ncsa.uiuc.edu  Wed Feb 24 02:45:32 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07705; Wed, 24 Feb 93 02:45:32 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04517; Wed, 24 Feb 1993 03:02:41 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09946
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 23 Feb 93 20:02:40 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14970; Tue, 23 Feb 93 20:04:25 -0800
Date: Tue, 23 Feb 93 20:04:25 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302240404.AA14970@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu
Subject: a question...
X-Md4-Signature: 53986a4d165c01f1c2602e3c154e243d

One of the things NCSA is interested in as part of our Mosaic work (of
which X Mosaic is only the first result) is gathering and analyzing
sociological data corresponding to use of distributed information
systems as well as use of the tools used to access those information
systems.

To make a long story short, in the name of Real Academic Research
(involving simulations and analysis that will be run on our Connection
Machine 5, if that makes it sound more impressive), we're thinking
about building logging mechanisms into the Mosaic tools that track a
number of interesting information access parameters:

        which documents are visisted
        how long each document is visited
        how many times each document is visited
          ... and in what sequence
        how hyperlinks are used
        how multimedia features are used
        how search features are used
        (in the future) how intelligent assistance is used
          ... and how it is not used
        etc.

First, this would be entirely voluntary -- when you start Mosaic for
the first time, you would get a registration screen that, among other
things, would let you either say, ``Yes, I Want To Help NCSA'', or
``No NCSA, Stay Out Of My Cyberspace''.

Second, this would be entirely under user control -- it could be
turned off at any time, via a menu option and/or X resources and/or
whatever other methods we can come up with.  (Or, if data accidentally
gets collected and sent to us when you didn't want it to, drop us a
note and we'll purge it from our systems.)

Third, it would be entirely automatic in that the log reports would be
sent, via email, by the program without the user having to do
anything.

Fourth, all information would be held in the strictest confidence --
it would go right to the project's social scientists and stay on
secure machines inside NCSA; even I (your humble hacker) would
probably never see it.  We'll swear to this on a stack of religious
texts of your choice.  Data will, of course, someday be published in
the generalized, analyzed aggregate -- but there will be no way for
anyone to trace back anything to any user anywhere.

Fifth, and this is the best part -- cooperating with us on this and
helping us gather this data would essentially mean more support for
the Mosaic project, enabling us to build more and better tools for
you.  And, the information we learn from the analyzed data will be fed
back into our development -- a particularly exciting concept for us,
because we want to start building intelligence into the systems, and
we need this type of analysis to have something to build on.

So... what do you think?  Should we do it?  Should we not do it?  Will
anyone rebel and refuse to use our software outright?  Given the
parameters outlined above (esp. the completely voluntary & under user
control parts), could it still be considered to be an invasion of
privacy, or possibility thereof?  Does it make you hopping mad to even
think that we'd consider it?  What?

Thanks for your help,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Wed Feb 24 12:29:06 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12148; Wed, 24 Feb 93 12:29:06 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29670; Wed, 24 Feb 1993 12:46:17 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04763; Wed, 24 Feb 93 12:41:52 +0100
Date: Wed, 24 Feb 93 12:41:52 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302241141.AA04763@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Logging user access. Was: a question...
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



Logging user access is something which we definitely want ..for a  
number of reasons

	-  Justifying the project by showing statistics
	-  Demonstrating the readership profiles of 

		different material
	-  Demonstrating the usage profile across sites
	
The privacy issue is very important, and so I had intended to
log each action "A read B" as "A read something" and "B was read"
independently.  This would give the basic profiles.  Anything futher  
would be an infringement of privacy, so yes that the user would
have to agree to it. The problem is, then the sociological data would  
be immediatly filtered ... all the alt.sex.bondage readers would
filter themselves out!  Perhaps two levels are needed.

The network load is also something which I considered a possible  
problem, so I decided on a scheme (have I said this before?) in which
an event was logged with probability p=exp(-a*t) and the probability
p is included in the message so that the message can be given weight  
1/p in the analysis. The time t with which p decays is from  
compilation of the source, so you get more fine-grained
info on the new releases.
The messages would be UDP packets so as not to clog gateways.

We have a monitoring service here which is already monitoring the use  
of other CERN software -- I am not sure whether it is tcp or udp  
based.  


*Coincidence:*  As I write the file system on our server has JUST  
filled up in attempting to process server January's log data....
is this a warning?!

BTW: Marc, you were going to log how LONG an article was read for.
I think that is very tricky... if you can come up with a good measure
of how much the person LIKED the article (automatically) then you
will really have something.  Someone whose name I forget in Stockholm
just gave a talk about inferrding document affinities from readership  
profiles... using the user  as a more refined text comparison program
than a work occurence engine.  I suggested WWW usage data as source,
but realized that for example of all the talk I had just given with
XMosaic, the document which was left on the screen for the longest  
time was quite irrelevant.

Something linked with this is finding relevant material for
a particular person.  How about a service which takes someone's
global history file and tells them all that's new in the world
which would interest them?  In other words, if you do keep
data about a particular person, then that can help them find more  
data like it.... a sophisticated form of relevance feedback.
 

 - - -
 

I think that as you are collecting data from the public, then the
data should also be made available to the public, with names and
addresses removed.

Another possibility is that all servers keep logs and share the
results... but it will always be incomplete.


Tim

From montulli@ukanaix.cc.ukans.edu  Thu Feb 25 00:48:12 1993
Return-Path: <montulli@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25201; Thu, 25 Feb 93 00:48:12 MET
Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28967; Thu, 25 Feb 1993 01:05:23 +0100
Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA37203; Wed, 24 Feb 1993 18:07:20 -0600
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Message-Id: <9302250007.AA37203@ukanaix.cc.ukans.edu>
Subject: Re: a question...
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Wed, 24 Feb 93 18:07:19 CST
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9302240404.AA14970@wintermute.ncsa.uiuc.edu>; from "Marc Andreessen" at Feb 23, 93 8:04 pm
X-Mailer: ELM [version 2.3 PL2]

> 
> One of the things NCSA is interested in as part of our Mosaic work (of
> which X Mosaic is only the first result) is gathering and analyzing
> sociological data corresponding to use of distributed information
> systems as well as use of the tools used to access those information
> systems.
> 
> To make a long story short, in the name of Real Academic Research
> (involving simulations and analysis that will be run on our Connection
> Machine 5, if that makes it sound more impressive), we're thinking
> about building logging mechanisms into the Mosaic tools that track a
> number of interesting information access parameters:
> 
... I made the long story even shorter.

This brings up an even better point than statistics.  There should be
built in mechanisms that will allow a user to respond directly to
the information provider.  This provides many benifits.  The first one is
that this is a nice way to correct typos, and other obvious errors that can
go unnoticed to the provider.  When a viewer sees a mistake he/she can
dash off a little note/flame informing the provider of the mistake.  This
is alot simpler than finding out the site and sending to an administrator.

Secondly, a user may wish to make a suggestion or ask for additional
information from the provider.  If they could send a note to the person
-directly- responseble for the information it would be much more likely
that they would get a meaningful reply.

Another useful feature is mailing error reports to an information provider
if they have an invalid link or if a site is unavailible.  This would
be done automatically by the client.  This provides useful data for
debugging a hypertext network and providing statistics for site availibility.

These features are built into the Lynx hypertext browser and have proved
to be VERY useful.  Document owners are listed inside of the hypertext 
file and are used as the address of comments and error reports.

Comments?
:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************


From VMNETNEW@slacvm.slac.stanford.edu  Thu Feb 25 11:38:17 1993
Return-Path: <VMNETNEW@slacvm.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00939; Thu, 25 Feb 93 11:38:17 MET
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06534; Thu, 25 Feb 1993 11:55:28 +0100
Received: from SLACVM.SLAC.STANFORD.EDU (MAILER@SLACVM) by
 SCS.SLAC.STANFORD.EDU with PMDF#10283; Thu, 25 Feb 1993 02:54 PDT
Received: by SLACVM (Mailer R2.08 R208004) id 7577; Thu, 25 Feb 93 02:54:18 PST
Date: Thu, 25 Feb 1993 10:41:40 GMT
From: roeber@vxcrna.cern.ch
Subject: Another electronic archive of papers
Sender: VMNETNEW@slacvm.slac.stanford.edu
To: WWW-TALK@nxoc01.cern.ch
Reply-To: roeber@cern.ch
Message-Id: <1993Feb25.114140.1@vxcrna.cern.ch>
X-Envelope-To: WWW-TALK@INFO.CERN.CH
Xref: unixhub cern.www.talk:9 slac.www.talk:2
Newsgroups: cern.www.talk,slac.www.talk
Path: slacvm!unixhub!dxcern!vxcrna.cern.ch!roeber
X-Sender: news@dxcern.cern.ch (USENET News System)
Organization: CERN -- European Organization for Nuclear Research
Lines: 33

Ooh, ooh, more resources to add.  If this keeps up, I'll have
to learn how to do this myself..  Anybody have disk space?  I
can't guarantee my workstation.
     
Crossposted from comp.theory.dynamic-sys: (with editing)
     
> Newsgroups: comp.theory.dynamic-sys
> From: ronnie@crow.lanl.gov (Ronnie Mainieri)
> Subject: Electronic Archive
> Message-ID: <1993Feb24.001900.24722@newshost.lanl.gov>
>
> I would like to announce an electronic archive for papers on chaos.
> The subjects covered are defined by the topics within the scope of
> Chaos, Physica D, Physical Review E and Nonlinearity journals.   Papers
> on low-dimensional dynamical systems, simple non-equilibrium
> statistical mechanics, quantum chaos, and the theory of Fredholm
> determinants are all welcome.   A list of recent titles is given below.
>
> The electronic archive accepts, stores, and allows access to manuscripts.  If
> you join, periodically (once a week) you will receive the abstracts of the
> papers submitted.   There is also a discussion group that you may join.
> It is hoped that enough people will join this archive server so that we
> can do away completely with having to mail out and request preprints.
>
[ etc...  the full article is in c.t.d-s ]
     
--
Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 20 82 99
--
"Sorry, baby, I can't take you to the pizza joint tonight, I've got to go
back to the lab and split the atom." -- Ayn Rand, "What is Romanticism?"

From RASHTY@hujivms.bitnet  Thu Feb 25 14:01:49 1993
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02324; Thu, 25 Feb 93 14:01:49 MET
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26892; Thu, 25 Feb 1993 14:19:02 +0100
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 2728; Thu, 25 Feb 93 14:17:11 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1c/1.7e) with BSMTP id 1777; Thu, 25 Feb 1993 14:17:08 +0100
Received: by HUJIVMS (HUyMail-V6k); Thu, 25 Feb 93 15:18:49 +0200
Date:     Thu,  25 Feb 93 15:18 +0200
Message-Id: <25020093151848@HUJIVMS>
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch
Cc: cc-l@dxmint.cern.ch
Subject:  new www interface for vms systems

Hi,

I am working now on a new interface for the www.

The interface is both english and hebrew (it can also be french and english)
It is written for a VMS system with smg screen functions.

The base of this interface is the linemode 1.4 with some improvements i have
made to the source.

there are still some bugs which i am working on...
and I hope to release the first version in july 1993.

You can try it out, by telnet to vms.huji.ac.il username: NEWWWW

For more information or suggestions please contact me.

thanks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:                                                      **** Thanks !! **** :
: Dudu Rashty                Rashty@Vms.Huji.Ac.Il         __o     o__     :
: Computation Center         Bitnet:Rashty@HUJIVMS       _ \<,_   _.>/ _   :
: The Hebrew University      Phone:  +972-2-584397      (_)/ (_) (_) \(_)  :
: Jerusalem 91904, ISRAEL.   Fax:    +972-2-527349       D    u    d    u  :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From janssen@parc.xerox.com  Thu Feb 25 20:38:24 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09125; Thu, 25 Feb 93 20:38:24 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02819; Thu, 25 Feb 1993 20:55:36 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11606>; Thu, 25 Feb 1993 11:55:10 PST
Received: by holmes.parc.xerox.com id <25546>; Thu, 25 Feb 1993 11:55:03 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 25 Feb 1993 11:54:49 -0800 (PST)
Message-Id: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
Date: 	Thu, 25 Feb 1993 11:54:49 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: WWW-TALK@nxoc01.cern.ch
Subject: xmosaic experience

I had an unsettling experience last night.  I wanted to look at the
latest draft of an Internet RFC, and thought to myself, ``Why not use
this nifty xmosaic tool to fetch it?'', since I had recently discovered
xmosaic.  So I typed in a URL, and it core-dumped on me.  Well, it's
only version 0.8, and probably doesn't know everything yet, so I tried
going through a gopher gateway (still using xmosaic) and accessing it
that way.  Well, I got through to the RFC -- and suddenly my X server
started chewing up CPU.  After chugging for several minutes (X11R5 on a
Sparc-2 with 48MB of RAM), xmosaic puts up the text of the RFC, marked
``page 1 of 5''.  Huh?  Surely this document has about 50 pages?

Turns out xmosaic has this (to me, fatally flawed) design decision I
hadn't suspected.  Instead of using a text widget (I'm not familiar with
the capabilities of the Motif text widget, but perhaps it does not
handle multi-font, multi-color text), xmosaic seems to *paint* text
strings on a window, and then pan the window around when the user
scrolls, rather than re-drawing the text.

Fascinating.

Bill

From marca@wintermute.ncsa.uiuc.edu  Thu Feb 25 21:21:04 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09714; Thu, 25 Feb 93 21:21:04 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08505; Thu, 25 Feb 1993 21:38:15 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA17900
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Thu, 25 Feb 93 14:38:13 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA21530; Thu, 25 Feb 93 14:39:58 -0800
Date: Thu, 25 Feb 93 14:39:58 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
Subject: xmosaic experience
In-Reply-To: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
References: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
X-Md4-Signature: c631c3909c5c4a8643dde351a92e0826

Bill Janssen writes:
> I had an unsettling experience last night.  I wanted to look at the
> latest draft of an Internet RFC, and thought to myself, ``Why not
> use this nifty xmosaic tool to fetch it?'', since I had recently
> discovered xmosaic.  So I typed in a URL, and it core-dumped on me.
> Well, it's only version 0.8, and probably doesn't know everything
> yet, so I tried going through a gopher gateway (still using xmosaic)
> and accessing it that way.  Well, I got through to the RFC -- and
> suddenly my X server started chewing up CPU.  After chugging for
> several minutes (X11R5 on a Sparc-2 with 48MB of RAM), xmosaic puts
> up the text of the RFC, marked ``page 1 of 5''.  Huh?  Surely this
> document has about 50 pages?
> 
> Turns out xmosaic has this (to me, fatally flawed) design decision I
> hadn't suspected.  Instead of using a text widget (I'm not familiar
> with the capabilities of the Motif text widget, but perhaps it does
> not handle multi-font, multi-color text), xmosaic seems to *paint*
> text strings on a window, and then pan the window around when the
> user scrolls, rather than re-drawing the text.

You are correct that the Motif text widget does *not* handle
multi-font, multi-color text.

Did you read the explanation for the "document pages" feature (or
fatally flawed design decision, whichever) in the docs, for which a
hyperlink is especially set up right by where it says "Document Page 1
of 5"?  Apparently not.  Let me summarize.

The X Window System has this (to me, fatally flawed) design decision I
hadn't suspected.  X windows can only be so big.  Up to the size of a
16-bit integer, in fact, in pixels.  This is really really bad.  This
means that the other WWW X browsers (at least Viola and Midas, the
only two I've been able to get working) will *not* correctly handle
documents that, when layed out, take up more pixels in height than
that -- e.g., your RFC.  Go try it on them.  Then look at what X
Mosaic does, which is lay out as much text as possible in the window
and then give you convenient automatic inlined hyperlinks to the
remainder of the text, partitioned into window-sized chunks.  Then
tell me who's making fatally flawed decisions.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Thu Feb 25 21:32:06 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09934; Thu, 25 Feb 93 21:32:06 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08884; Thu, 25 Feb 1993 21:49:17 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18548
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Thu, 25 Feb 93 14:49:15 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA21564; Thu, 25 Feb 93 14:50:52 -0800
Date: Thu, 25 Feb 93 14:50:52 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302252250.AA21564@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
Subject: xmosaic experience
In-Reply-To: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
References: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
X-Md4-Signature: 464e7272e2cd97b5af20987073a90154

Bill Janssen writes:
> I had an unsettling experience last night.  I wanted to look at the
> latest draft of an Internet RFC, and thought to myself, ``Why not use
> this nifty xmosaic tool to fetch it?'', since I had recently discovered
> xmosaic.  So I typed in a URL, and it core-dumped on me.  Well, it's
> only version 0.8, and probably doesn't know everything yet [...]

And another thing.

No doubt it doesn't know everything yet, but it's not going to get any
smarter if core dump reports don't come with a description of what
happened to cause the core dump.  Could you please provide the URL you
used to cause it to coredump?

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From guido@cwi.nl  Thu Feb 25 22:00:46 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10268; Thu, 25 Feb 93 22:00:46 MET
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12125; Thu, 25 Feb 1993 22:17:09 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA09062 (5.65b/3.8/CWI-Amsterdam); Thu, 25 Feb 1993 22:15:42 +0100
Received: by voorn.cwi.nl with SMTP
	id AA14957 (5.65b/3.8/CWI-Amsterdam); Thu, 25 Feb 1993 22:15:40 +0100
Message-Id: <9302252115.AA14957=guido@voorn.cwi.nl>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
Subject: Re: xmosaic experience 
In-Reply-To: Your message of "Thu, 25 Feb 1993 14:39:58 MET."
             <9302252239.AA21530@wintermute.ncsa.uiuc.edu> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Thu, 25 Feb 1993 22:15:40 +0100
Sender: Guido.van.Rossum@cwi.nl

Regarding Bill Jansen's experience, I read in his message a question
that you haven't answered but which perhaps lies at the core of his
complaint: the way I read it, he believes that you write the text
*once* into a background pixmap and then scroll it around.  I can't
believe this is true.  If indeed it isn't true you should perhaps
explain why it takes so long to read the RFC in (is it just slow ftp
or are you doing lots of processing?) and whether it is true that the
X server should be chewing up CPU?  Could it be that Bill's server is
too eager to do backing store and generates an exposure event for the
entire subwindow?  (Perhaps Xmosaic can set a resource that disables
this behavior?)

Relevant excerpts from Bill's message:

> [...]  Well, I got through to the RFC -- and
> suddenly my X server started chewing up CPU.  [...]
>
> [...] xmosaic seems to *paint*
> text strings on a window, and then pan the window around when the
> user scrolls, rather than re-drawing the text.

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From marca@wintermute.ncsa.uiuc.edu  Thu Feb 25 22:13:15 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10430; Thu, 25 Feb 93 22:13:15 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13692; Thu, 25 Feb 1993 22:30:27 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA20763
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 25 Feb 93 15:30:25 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA21764; Thu, 25 Feb 93 15:32:00 -0800
Date: Thu, 25 Feb 93 15:32:00 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302252332.AA21764@wintermute.ncsa.uiuc.edu>
To: Guido.van.Rossum@cwi.nl
Cc: www-talk@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
Subject: Re: xmosaic experience 
In-Reply-To: <9302252115.AA14957=guido@voorn.cwi.nl>
References: <9302252115.AA14957=guido@voorn.cwi.nl>
	<9302252239.AA21530@wintermute.ncsa.uiuc.edu>
X-Md4-Signature: 5d58570d33b7897760cfe3b414a28765

Guido.van.Rossum@cwi.nl writes:
> Regarding Bill Jansen's experience, I read in his message a question
> that you haven't answered but which perhaps lies at the core of his
> complaint: the way I read it, he believes that you write the text
> *once* into a background pixmap and then scroll it around.  I can't
> believe this is true.  If indeed it isn't true you should perhaps
> explain why it takes so long to read the RFC in (is it just slow ftp
> or are you doing lots of processing?) and whether it is true that
> the X server should be chewing up CPU?  Could it be that Bill's
> server is too eager to do backing store and generates an exposure
> event for the entire subwindow?  (Perhaps Xmosaic can set a resource
> that disables this behavior?)

It's not storing a huge window-sized pixmap -- that would take one
hell of a lot of memory.  It's letting the X window mechanism generate
appropriate expose events and repainting on the fly.  Parsing a
document that long and finding out how to break it up into document
pages just plain takes a while -- but, for what it's worth, it will
take less time in 0.9, for reasons I'm not even going to go into here.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From janssen@parc.xerox.com  Thu Feb 25 23:34:27 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11637; Thu, 25 Feb 93 23:34:27 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22721; Thu, 25 Feb 1993 23:51:40 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11656>; Thu, 25 Feb 1993 14:51:12 PST
Received: by holmes.parc.xerox.com id <25546>; Thu, 25 Feb 1993 14:51:02 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 25 Feb 1993 14:50:57 -0800 (PST)
Message-Id: <0fXIpFoB0KGW4v0hoS@holmes.parc.xerox.com>
Date: 	Thu, 25 Feb 1993 14:50:57 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: xmosaic experience
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
In-Reply-To: <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
References: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
	<9302252239.AA21530@wintermute.ncsa.uiuc.edu>

Relax, Marc.  First off, I really like xmosaic, and am hoping version
1.0 will be really great!  But secondly, I'm not your customer.  Who
cares what I think?  Thirdly, it *is* a design decision, probably made
for all kinds of reasons I'm not aware of which make it a *good* design
decision.  Fourth, of course I read your explanation.

Excerpts from direct: 25-Feb-93 xmosaic experience Marc
Andreessen@ncsa.uiu (2331)

> The X Window System has this (to me, fatally flawed) design decision I
> hadn't suspected.  X windows can only be so big.  Up to the size of a
> 16-bit integer, in fact, in pixels.  This is really really bad.  This
> means that the other WWW X browsers (at least Viola and Midas, the
> only two I've been able to get working) will *not* correctly handle
> documents that, when layed out, take up more pixels in height than
> that -- e.g., your RFC.  Go try it on them.  Then look at what X
> Mosaic does, which is lay out as much text as possible in the window
> and then give you convenient automatic inlined hyperlinks to the
> remainder of the text, partitioned into window-sized chunks.  Then
> tell me who's making fatally flawed decisions.

Well, since you ask...  If you're displaying text, it really doesn't
matter what the maximum size of a window is, so long as you can get at
least one line on it, right?  As the user scrolls through the text, you
just show different lines, right?  But apparently what you're doing is
turning each document into a giant image of text, and then panning
through that image, which of course runs you into size problems.  This
is an OK idea if you're building something like HyperCard.  But WWW
isn't always like HyperCard, it tends to mix the ``holy scroller'' model
with the ``card shark'' model of hypertext.  So this approach isn't
really suited either to WWW or to the X Window System, so far as I can
see.  (The problem with it on X is that is uses big chunks of window
system resources, typically in one big burst that locks out everything
else on the screen!)  The ``correct'' approach would be more of what
Viola does, which is to use a text widget.  By the way, Viola, the only
other browser I use, *does* in fact use a text widget, and handles my
document just fine.

As I said above, maybe I'm missing something?

Bill


From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 00:17:14 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12184; Fri, 26 Feb 93 00:17:14 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26602; Fri, 26 Feb 1993 00:34:27 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28578
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Thu, 25 Feb 93 17:34:24 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA22163; Thu, 25 Feb 93 17:36:10 -0800
Date: Thu, 25 Feb 93 17:36:10 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302260136.AA22163@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu,
        marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: xmosaic experience
In-Reply-To: <0fXIpFoB0KGW4v0hoS@holmes.parc.xerox.com>
References: <0fXIpFoB0KGW4v0hoS@holmes.parc.xerox.com>
	<9302252239.AA21530@wintermute.ncsa.uiuc.edu>
	<EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
X-Md4-Signature: 1a892af7eddde237559724ae86a443ff

Bill Janssen writes:
> Relax, Marc.  First off, I really like xmosaic, and am hoping version
> 1.0 will be really great!  

It's good to hear that.  Public complaints about something that we
actually put a lot of time into don't encourage us any, though.  I'm
sure you can understand that.

> But secondly, I'm not your customer.  Who cares what I think?

Well, you literally are our customer.  But that's probably beside the
point... we do care what you think simply because having the wonderful
distributed beta team that we essentially have due to this group gives
us the opportunity to make our product much better than it could be
otherwise.  We very much value constructive criticism from
knowledgeable people.

> Well, since you ask...  If you're displaying text, it really doesn't
> matter what the maximum size of a window is, so long as you can get
> at least one line on it, right?  As the user scrolls through the
> text, you just show different lines, right?  But apparently what
> you're doing is turning each document into a giant image of text,
> and then panning through that image, which of course runs you into
> size problems.  This is an OK idea if you're building something like
> HyperCard.  But WWW isn't always like HyperCard, it tends to mix the
> ``holy scroller'' model with the ``card shark'' model of hypertext.
> So this approach isn't really suited either to WWW or to the X
> Window System, so far as I can see.  (The problem with it on X is
> that is uses big chunks of window system resources, typically in one
> big burst that locks out everything else on the screen!)  The
> ``correct'' approach would be more of what Viola does, which is to
> use a text widget.

We are using a widget.  A text widget, in fact -- just one we wrote
ourselves, since the Motif text widget doesn't support the
functionality we need.  We are not using a huge-ass 32K or 64K pixel
high pixmap or image, and we are not consuming memory to store such a
pixmap or anything else 32K or 64K high.  We are using a virtual
window that is that high because that way X handles the scrolling such
that we get the proper expose events at the proper times FOR THE AREA
OF THE WINDOW THAT IS ACTUALLY ONSCREEN.  To do our own scrolling
would require a lot of additional work.  Either someone funds us to do
that work or we are going to do more interesting things with our time.

Spend some time with our code before drawing conclusions, in public no
less, like ``you're turning each document into a giant page of text,
and then panning through that image''.

> By the way, Viola, the only other browser I use, *does* in fact use
> a text widget, and handles my document just fine.

OK, if that's the case then my apologies to Pei.  I have a dim memory
of trying this last year and simply seeing the document overrun the
window size, as happens with Midas -- I'm probably mistaken.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From janssen@parc.xerox.com  Fri Feb 26 01:02:35 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12701; Fri, 26 Feb 93 01:02:35 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00666; Fri, 26 Feb 1993 01:19:48 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11693>; Thu, 25 Feb 1993 16:19:24 PST
Received: by holmes.parc.xerox.com id <25546>; Thu, 25 Feb 1993 16:19:17 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 25 Feb 1993 16:19:16 -0800 (PST)
Message-Id: <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com>
Date: 	Thu, 25 Feb 1993 16:19:16 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen), Guido.van.Rossum@cwi.nl
Subject: Re: xmosaic experience
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
In-Reply-To: <9302252115.AA14957=guido@voorn.cwi.nl>
References: <9302252115.AA14957=guido@voorn.cwi.nl>

Excerpts from mail: 25-Feb-93 Re: xmosaic experience
Guido.van.Rossum@cwi.nl (1058)

> he believes that you write the text
> *once* into a background pixmap and then scroll it around.  I can't
> believe this is true.  If indeed it isn't true you should perhaps
> explain why it takes so long to read the RFC in (is it just slow ftp
> or are you doing lots of processing?) and whether it is true that the
> X server should be chewing up CPU?

Actually, I don't think it's a pixmap.  What every X text widget I'm
aware of does, is this:  It puts up a single window, and figures out
what lines of the text to paint in that window.  When the user scrolls
the text, it re-figures the lines, and repaints the window.  Thus it can
handle text of arbitrary length, with relatively small use of X Window
resources, even if backing store is enabled; in fact, backing store
works well with this scheme.

What I think xmosaic does is:  it creates both a fixed window as above,
then creates a huge-ass window as a child window.  It connects the
scrollbar to the child window, and allows the user to scroll the child
window around, instead of scrolling the text around.  This is a *much*
simpler way of doing things, but now X *will* allocate an internal
backing pixmap for that child window, even without backing store, and
without all of it being exposed.  So you're using one huge amount of
memory.  And this is just to avoid using the Motif text widget?  As I
say, this kind of approach would work OK on X for a HyperCard-like
system, but not for a scrolling system.

Excerpts from mail: 25-Feb-93 Re: xmosaic experience Marc
Andreessen@ncsa.uiu (1288)

> Parsing a document that long and finding out how to break it up into document
> pages just plain takes a while

Hmmm, the document was plain text.  Where's the parse?  And of course if
you didn't have to break it into document pages...

Bill

From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 01:13:49 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12925; Fri, 26 Feb 93 01:13:49 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02538; Fri, 26 Feb 1993 01:31:02 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA01086
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Thu, 25 Feb 93 18:31:00 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA22468; Thu, 25 Feb 93 18:32:45 -0800
Date: Thu, 25 Feb 93 18:32:45 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302260232.AA22468@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu,
        marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: xmosaic experience
In-Reply-To: <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com>
References: <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com>
	<9302252115.AA14957=guido@voorn.cwi.nl>
X-Md4-Signature: 3604dd05c180fb9542a493e65cdf1506

Bill Janssen writes:
> What I think xmosaic does is:  it creates both a fixed window as above,
> then creates a huge-ass window as a child window.  It connects the
> scrollbar to the child window, and allows the user to scroll the child
> window around, instead of scrolling the text around.  This is a *much*
> simpler way of doing things, but now X *will* allocate an internal
> backing pixmap for that child window, even without backing store, and
> without all of it being exposed.  So you're using one huge amount of
> memory.  And this is just to avoid using the Motif text widget?  As I
> say, this kind of approach would work OK on X for a HyperCard-like
> system, but not for a scrolling system.

Explain to me how we are able to allocate a 32K * 1024 * 1 byte pixmap
or image or block of random memory or whatever it is you claim we're
doing and still fit in on a typical workstation.  For example, I
currently have that situation running within X Mosaic on my 24MB
workstation and not only is scrolling almost instantaneously fast but
ps -lef reports this:

30 S   marca 22431 12382  0  26 25 * 1123:680  80127908 18:24:21 ttyq1     0:16 /usr/people/marca/mosaic/xmosaic/sr

Where in there is that 32MB of memory buried?

And look, goddammit, we are not trying to avoid using the Motif text
widget.  The Motif text widget is not capable of supporting colors and
fonts.  You show me how to put colors and fonts in a Motif text
widget, or support the rest of the functionality we need, and I'll
damn well do it.

> Hmmm, the document was plain text.  Where's the parse?  And of
> course if you didn't have to break it into document pages...

The parse is because I switched to using <xmp> in 0.8 to support
annotations to plaintext documents (since <xmp> can be terminated and
<plaintext> cannot).  In 0.9 this will be handled as it should be and
<plaintext> will be used again, obviating the need to do a lot of the
parsing that's going on right now.  But we're still going to be using
a Widget and we're still not going to be using the Motif text widget
and we're still going to have the document pages feature in there.

Marc


From janssen@parc.xerox.com  Fri Feb 26 01:50:28 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13385; Fri, 26 Feb 93 01:50:28 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06411; Fri, 26 Feb 1993 02:07:41 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11710>; Thu, 25 Feb 1993 17:07:27 PST
Received: by holmes.parc.xerox.com id <25546>; Thu, 25 Feb 1993 17:07:24 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 25 Feb 1993 17:07:22 -0800 (PST)
Message-Id: <QfXKp_UB0KGWMv0cdR@holmes.parc.xerox.com>
Date: 	Thu, 25 Feb 1993 17:07:22 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: xmosaic experience
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
In-Reply-To: <9302260232.AA22468@wintermute.ncsa.uiuc.edu>
References: <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com>
	<9302252115.AA14957=guido@voorn.cwi.nl>
	<9302260232.AA22468@wintermute.ncsa.uiuc.edu>

Excerpts from direct: 25-Feb-93 Re: xmosaic experience Marc
Andreessen@ncsa.uiu (2140)

> Explain to me how we are able to allocate a 32K * 1024 * 1 byte pixmap
> or image or block of random memory or whatever it is you claim we're
> doing and still fit in on a typical workstation.  For example, I
> currently have that situation running within X Mosaic on my 24MB
> workstation and not only is scrolling almost instantaneously fast but
> ps -lef reports this:

> 30 S   marca 22431 12382  0  26 25 * 1123:680  80127908 18:24:21 ttyq1  
>   0:16 /usr/people/marca/mosaic/xmosaic/sr

> Where in there is that 32MB of memory buried?

I finally looked at the X11R5 server source, and you're absolutely
right, the server is not allocating more than a screen-size of pixmap
for any one window, even a very big one.  Most of that time I was
looking at must have been spent parsing (but then why did `ps' show it
in the server?).  Thanks for correcting my misapprehension on that point.

> The Motif text widget is not capable of supporting colors and
> fonts.  You show me how to put colors and fonts in a Motif text
widget, or support the rest of the functionality we need,

Yep, as I said earlier, a design decision.

Bill

From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 01:55:33 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13476; Fri, 26 Feb 93 01:55:33 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06543; Fri, 26 Feb 1993 02:12:47 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02615
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Thu, 25 Feb 93 19:12:45 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA23148; Thu, 25 Feb 93 19:14:31 -0800
Date: Thu, 25 Feb 93 19:14:31 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302260314.AA23148@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu,
        marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: xmosaic experience
In-Reply-To: <QfXKp_UB0KGWMv0cdR@holmes.parc.xerox.com>
References: <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com>
	<9302252115.AA14957=guido@voorn.cwi.nl>
	<9302260232.AA22468@wintermute.ncsa.uiuc.edu>
	<QfXKp_UB0KGWMv0cdR@holmes.parc.xerox.com>
X-Md4-Signature: 095ed02cabc72299d21fb872dd436ee3

Bill Janssen writes:
> I finally looked at the X11R5 server source, and you're absolutely
> right, the server is not allocating more than a screen-size of pixmap
> for any one window, even a very big one.  Most of that time I was
> looking at must have been spent parsing (but then why did `ps' show it
> in the server?).

Because the Widget uses XTextExtents to figure out how big text chunks
are (which makes sense, since they could be in any font).  Like I say,
this should be faster in 0.9, since it won't have to do so much
parsing, since I will be handling plaintext documents correctly, since
annotation links will be handled separately from the document text
itself.  I think.

Marc


From janssen@parc.xerox.com  Fri Feb 26 02:18:55 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13688; Fri, 26 Feb 93 02:18:55 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09825; Fri, 26 Feb 1993 02:36:08 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11745>; Thu, 25 Feb 1993 17:35:41 PST
Received: by holmes.parc.xerox.com id <25546>; Thu, 25 Feb 1993 17:35:30 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 25 Feb 1993 17:35:15 -0800 (PST)
Message-Id: <8fXLDHoB0KGW0v0gsu@holmes.parc.xerox.com>
Date: 	Thu, 25 Feb 1993 17:35:15 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Bill Janssen <janssen@parc.xerox.com>,
        marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: xmosaic experience
Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu,
        marca@ncsa.uiuc.edu (Marc Andreessen)
In-Reply-To: <9302260314.AA23148@wintermute.ncsa.uiuc.edu>
References: <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com>
	<9302252115.AA14957=guido@voorn.cwi.nl>
	<9302260232.AA22468@wintermute.ncsa.uiuc.edu>
	<QfXKp_UB0KGWMv0cdR@holmes.parc.xerox.com>
	<9302260314.AA23148@wintermute.ncsa.uiuc.edu>

Excerpts from direct: 25-Feb-93 Re: xmosaic experience Marc
Andreessen@ncsa.uiu (693)

> Because the Widget uses XTextExtents to figure out how big text chunks
> are (which makes sense, since they could be in any font).

Yep, that must be it.  Thanks.

Bill

From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 03:50:04 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14920; Fri, 26 Feb 93 03:50:04 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18075; Fri, 26 Feb 1993 04:07:18 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA06409
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 25 Feb 93 21:07:16 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA24510; Thu, 25 Feb 93 21:09:02 -0800
Date: Thu, 25 Feb 93 21:09:02 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302260509.AA24510@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: proposed new tag: IMG
X-Md4-Signature: 290e31aa16432f2a9a2423a649f18b33

I'd like to propose a new, optional HTML tag:

        IMG

Required argument is SRC="url".  

This names a bitmap or pixmap file for the browser to attempt to pull
over the network and interpret as an image, to be embedded in the text
at the point of the tag's occurrence.

An example is:

        <IMG SRC="file://foobar.com/foo/bar/blargh.xbm"> 

(There is no closing tag; this is just a standalone tag.)

This tag can be embedded in an anchor like anything else; when that
happens, it becomes an icon that's sensitive to activation just like a
regular text anchor.

Browsers should be afforded flexibility as to which image formats they
support.  Xbm and Xpm are good ones to support, for example.  If a
browser cannot interpret a given format, it can do whatever it wants
instead (X Mosaic will pop up a default bitmap as a placeholder).

This is required functionality for X Mosaic; we have this working, and
we'll at least be using it internally.  I'm certainly open to
suggestions as to how this should be handled within HTML; if you have
a better idea than what I'm presenting now, please let me know.  I
know this is hazy wrt image format, but I don't see an alternative
than to just say ``let the browser do what it can'' and wait for the
perfect solution to come along (MIME, someday, maybe).

Let me know what you think.........

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From TONYJ@scs.slac.stanford.edu  Fri Feb 26 07:57:05 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16560; Fri, 26 Feb 93 07:57:05 MET
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12291; Fri, 26 Feb 1993 08:14:19 +0100
Date: Thu, 25 Feb 1993 23:13 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: proposed new tag: IMG
To: marca@ncsa.uiuc.edu
Cc: www-talk@nxoc01.cern.ch
Message-Id: <EAEA803710000191@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"marca@ncsa.uiuc.edu"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

>I'd like to propose a new, optional HTML tag:
>
>        IMG
>
>Required argument is SRC="url".  
>
>This names a bitmap or pixmap file for the browser to attempt to pull
>over the network and interpret as an image, to be embedded in the text
>at the point of the tag's occurrence.
>
>An example is:
>
>       <IMG SRC="file://foobar.com/foo/bar/blargh.xbm"> 
>
>(There is no closing tag; this is just a standalone tag.)

I have something very similar in Midas 2.0 (in use here at SLAC, and due for 
public release any week now), except that all the names are different, and it 
has an extra argument NAME="name". It has almost exactly the same 
functionality as your proposed IMG tag. e.g.

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

The idea of the name parameter was to allow the browser to have a set of 
"built in" images. If the name matches a "built in" image it would use that 
instead of having to go out and fetch the image. The name could also act as a 
hint for "line mode" browsers as to what kind of a symbol to put in place of 
the image.

I don't much care about the parameter or tag names,  but it would be sensible 
if we used the same things. I don't much care for abbreviations, ie why not 
IMAGE= and SOURCE=. I somewhat prefer ICON since it imlies that the IMAGE 
should be smallish, but maybe ICON is an overloaded word?

>Browsers should be afforded flexibility as to which image formats they
>support.  Xbm and Xpm are good ones to support, for example.  If a
>browser cannot interpret a given format, it can do whatever it wants
>instead (X Mosaic will pop up a default bitmap as a placeholder).

I was proposing to use the file extension (.xbm above) to tag what format the 
image was in, but with the intention that in future, when HTTP2 comes along, 
the same format negotiation technique would be used to access images.

Xbm and Xpm sound resonable to me, but do they sound reasonable for non-X 
based applications??

While we are on the subject of new tags, I have another, somewhat similar tag, 
which I would like to support in Midas 2.0. In principle it is:

<INCLUDE HREF="...">

The intention here would be that the second document is to be included into 
the first document at the place where the tag occured. In principle the 
referenced document could be anything, but the main purpose was to allow 
images (in this case arbitrary sized) to be embedded into documents. Again the 
intention would be that when HTTP2 comes along the format of the included 
document would be up for separate negotiation.

An alternative I was considering was:

<A HREF="..." INCLUDE>See photo</A>

I don't much like adding more functionality to the <A> tag, but the idea here 
is to maintain compatibility with browsers that can not honour the INCLUDE 
parameter. The intention is that browsers which do understand INCLUDE, replace 
the anchor text (in this case "See photo") with the included document 
(picture), while older or dumber browsers ignore the INCLUDE tag completely.

Comments?????

Tony

From guido@cwi.nl  Fri Feb 26 09:52:18 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17188; Fri, 26 Feb 93 09:52:18 MET
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28433; Fri, 26 Feb 1993 10:09:26 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA01314 (5.65b/3.8/CWI-Amsterdam); Fri, 26 Feb 1993 10:08:37 +0100
Received: by voorn.cwi.nl with SMTP
	id AA15955 (5.65b/3.8/CWI-Amsterdam); Fri, 26 Feb 1993 10:08:37 +0100
Message-Id: <9302260908.AA15955=guido@voorn.cwi.nl>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), WWW-TALK@nxoc01.cern.ch,
        ebina@ncsa.uiuc.edu
Subject: Re: xmosaic experience 
In-Reply-To: Your message of "Thu, 25 Feb 1993 16:19:16 MET."
             <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Fri, 26 Feb 1993 10:08:36 +0100
Sender: Guido.van.Rossum@cwi.nl

>What I think xmosaic does is:  it creates both a fixed window as above,
>then creates a huge-ass window as a child window.  It connects the
>scrollbar to the child window, and allows the user to scroll the child
>window around, instead of scrolling the text around.  This is a *much*
>simpler way of doing things,

Yes.  So far your story is correct.

>but now X *will* allocate an internal
>backing pixmap for that child window, even without backing store, and
>without all of it being exposed.  So you're using one huge amount of
>memory.

Wrong.  X does NOT allocate pixmaps just because you create a giant
window.  It remembers the size of the window and gives you expose
events when parts of the window become visible.  It does not even
allocate a pixmap for the visible part (since that's put directly in
screen memory).  What do you think exposure events were good for if
the server allocated a pixmap?  Soure that would be getting the worst
of two worlds!

I'll let Marc answer your attacks on XMosaic, but your knowledge of X
is less than what I expected.

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From kny@cs.hut.fi  Fri Feb 26 11:03:32 1993
Return-Path: <kny@cs.hut.fi>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17740; Fri, 26 Feb 93 11:03:32 MET
Received: from cardhu.cs.hut.fi by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09562; Fri, 26 Feb 1993 11:20:43 +0100
Received: by cardhu.cs.hut.fi id AA22920
  (5.65c8/HUTCS-C 1.3 for WWW-TALK@nxoc01.cern.ch); Fri, 26 Feb 1993 12:20:40 +0200
Date: Fri, 26 Feb 1993 12:20:40 +0200
From: Kim Peter Nyberg <kny@cs.hut.fi>
Message-Id: <199302261020.AA22920@cardhu.cs.hut.fi>
To: WWW-TALK@nxoc01.cern.ch
Subject: re: xmosaic experience
In-Reply-To: <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
References: <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
	<EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>


First of all, excuse me for jumping into this discussion all of the
sudden, but I couldn't resist. Being one of the members of the former
Erwise-team, I have some ideas about X-browsers (Erwise is a Motif-based
www-browser, implemented as a student project at Helsinki University
of Tech. during 91-92)

Marc Andreessen writes:
 > The X Window System has this (to me, fatally flawed) design decision I
 > hadn't suspected.  X windows can only be so big.  Up to the size of a
 > 16-bit integer, in fact, in pixels.  This is really really bad.  This

Well, unless we'll be seing >32k*32k displays in the near future, it's
not that bad.

 > means that the other WWW X browsers (at least Viola and Midas, the
 > only two I've been able to get working) will *not* correctly handle
 > documents that, when layed out, take up more pixels in height than
 > that -- e.g., your RFC.  Go try it on them.  Then look at what X

Erwise works correctly ;)
Actually, doing the scrolling by hand (even in an optimized way) isn't
that hard, you might want to take a look at our code (available at
anonymous@nic.funet.fi:pub/unix/hypertext).

Yes, I know, the code is something of a mess, especially since we
hacked a bit on the common code to get non-blocking transfers working
(it's nice to be able to retrieve multiple documents at the same time
and read through the ones on your screen, though).

 > Mosaic does, which is lay out as much text as possible in the window
 > and then give you convenient automatic inlined hyperlinks to the
 > remainder of the text, partitioned into window-sized chunks.  Then
 > tell me who's making fatally flawed decisions.

Hmmmh, no offence, but I think that's not not the correct way to solve
the problem.

Btw, have the current x-clients implemented non-blocking transfers?
It should be implemented in the common code, maybe it already is. It's
really too bad that we don't have the time to support erwise (three
of us are working almost full time at a software company, and try to get
on with our studies as well). Maybe in the summer ...

 > Marc

Kim

From timbl@www3.cern.ch  Fri Feb 26 13:52:07 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19490; Fri, 26 Feb 93 13:52:07 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06070; Fri, 26 Feb 1993 14:09:21 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05957; Fri, 26 Feb 93 14:04:55 +0100
Date: Fri, 26 Feb 93 14:04:55 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302261304.AA05957@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: proposed new tag: IMG
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



I had imagined that figues would be reprented as

<a name=fig1 href="fghjkdfghj"  REL="EMBED, PRESENT">Figure </a>

where the relation ship values mean

	EMBED		Embed this here when presenting it
	PRESENT		Present this whenever the source document
			is presented
	
Note that you can have various combinations of these, and if
the browser doesn't support either one, it doesn't break.

A see that using this as a method for selectable icons means nesting  
anchors.  Hmmm.   But I hadn't wanted a special tag.
Annother way would be to declare an entity with SYSTEM attribute  
giving the URL and then invoke that entity, but that would mean an
extendable entity dictionary which is not currently needed.


From TONYJ@scs.slac.stanford.edu  Fri Feb 26 14:56:54 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20251; Fri, 26 Feb 93 14:56:54 MET
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16963; Fri, 26 Feb 1993 15:14:08 +0100
Date: Thu, 25 Feb 1993 23:24 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Handling + in document searches
To: www-talk@nxoc01.cern.ch
Message-Id: <EC79F6C9D0000191@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ

I would like to reraise an issue I have mentioned before but not obtained a 
clear answer on. 

At SLAC we are using WWW as a means of accessing a set of High Energy Physics 
databases maintained here (SPIRES). One common usage is to search for 
particular particle types, for example PI+. There is an immediate problem in 
that the + symbol is treated specially in search strings by the current 
http-daemons, namely it is changed to a space (for largely historic reasons).

I would like to propose the following:

======

ALL browsers should perform the following translations on search strings typed 
in by the user:

   + " % and <space> should be replaced by %nn  where nn is  the ASCII         
                            code for the translated character 

ALL daemons should translate %nn in search strings back to the appropriate 
character. For historical reasons the + should continue to be translated to
<space> as now.

======

Comments????? Can we do it tomorrow?

Tony

From davis@dri.cornell.edu  Fri Feb 26 15:50:57 1993
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20949; Fri, 26 Feb 93 15:50:57 MET
Received: from WILLOW.TC.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29772; Fri, 26 Feb 1993 16:08:12 +0100
Received: by willow.tc.cornell.edu id AA14775
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 26 Feb 1993 10:07:34 -0500
Date: Fri, 26 Feb 1993 10:07:34 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199302261507.AA14775@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG


I like the functionality of Marc's proposal.  (I am indifferent
to the syntax, so long as we get a standard.)  While I daresay
that HTPP2 and Mime will oneday achieve the same power and more,
I like the idea of getting it soon.

Note that Tim's proposal

<a name=fig1 href="fghjkdfghj"  REL="EMBED, PRESENT">Figure </a>

is less general, since it can only be used inside anchors.  (Maybe
I don't understand it, though... do you have to click on the
anchor, or does PRESENT mean that it is "automatically" clicked?
If so, what happens to the text between the A and /A ?

As I understand it, I can use Marc A's scheme for inline pictures
(which might be big) or icons in anchors.

As for specifics of Marc A's proposal, two comments

1) why have SRC instead of HREF?

2) It would be nice if there was a way to specify the content type,
e.g. 

<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>

But I am completely willing to live with the requirement that I specify
the content type by file extension.  It's good enough for me.

From ccprl@xdm001.ccc.cranfield.ac.uk  Fri Feb 26 17:36:09 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22780; Fri, 26 Feb 93 17:36:09 MET
Received: from [138.250.1.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20543; Fri, 26 Feb 1993 17:53:06 +0100
Received: by xdm001 
	id AA05141; Fri, 26 Feb 93 16:52:38 GMT
Received: by xdm039 (5.57/4.7) id AA16834; Fri, 26 Feb 93 16:52:34 GMT
Message-Id: <9302261652.AA16834@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: patch to exec from httpd
Date: Fri, 26 Feb 93 16:52:31 GMT
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>


I seem to remember something about a patch to httpd to allow mapping
onto a command, rather than a file, but I can't remember where. Am I
hallucinating, or can someone let me know where this thing is?

Ta

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From timbl@www3.cern.ch  Fri Feb 26 17:52:34 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23091; Fri, 26 Feb 93 17:52:34 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22779; Fri, 26 Feb 1993 18:09:49 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06128; Fri, 26 Feb 93 18:05:22 +0100
Date: Fri, 26 Feb 93 18:05:22 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302261705.AA06128@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: John O'Neall <JON@frcpn11.in2p3.fr>
Subject: Re: info.cern.ch from rs6k
Cc: Tim Berners-Lee <timbl@nxoc01.cern.ch>,
        Bebo White <BEBO%SLACVM.bitnet@frcpn11.in2p3.fr>,
        www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



I'm sorry about this .. why not grab XMosaic or www and run it on  
your rs6000?  There is something which never works when telnetting
to a next from an rs6000 (www apart) which I don't want to tangle  
with now.  (One of my hariest days was trying to debug a NeXT when  
all I had was an rs600 to access it from!)

You could also try out another telnet server -- there's  a list in
the W3 FAQ which you can't read because it all comes in columns
1 and 80 ... ;-)

Begin forwarded message:

Date:         Fri, 26 Feb 93 16:08:19 MET
From: John O'Neall <JON@frcpn11.in2p3.fr>
Subject:      info.cern.ch from rs6k
To: Tim Berners-Lee <timbl@nxoc01.cern.ch>
Cc: Bebo White <BEBO%SLACVM.bitnet@frcpn11.in2p3.fr>

Tim --

I still have the problem I signalled 6 or 8 months ago, i.e., if i
telnet to info.cern.ch from an rs6k, the result is garbage:  Most of
the output is written to columns 1 and 80.  At that time, someone  
said,
yes, it was an error.  But from where?  Anything to be done?

Thanks in advance -- John

P.S. for Bebo -- Wonder if you see this at SLAC, where you use  
rs6k's.


From timbl@www3.cern.ch  Fri Feb 26 17:59:56 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23191; Fri, 26 Feb 93 17:59:56 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23184; Fri, 26 Feb 1993 18:17:11 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06142; Fri, 26 Feb 93 18:12:45 +0100
Date: Fri, 26 Feb 93 18:12:45 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9302261712.AA06142@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Jim Davis <davis@dri.cornell.edu>
Subject: Re: proposed new tag: IMG
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Fri, 26 Feb 1993 10:07:34 -0500
> From: Jim Davis <davis@dri.cornell.edu>
> 

> I like the functionality of Marc's proposal.  (I am indifferent
> to the syntax, so long as we get a standard.)  While I daresay
> that HTPP2 and Mime will oneday achieve the same power and more,
> I like the idea of getting it soon.
> 

> Note that Tim's proposal
> 

> <a name=fig1 href="fghjkdfghj"  REL="EMBED, PRESENT">Figure </a>
> 

> is less general, since it can only be used inside anchors. 


No ... it is just that the thing is seen as a type of link rather
than something totally new. Note that in the Microsoft world the
work "Link" always mean "embed the thing referred to here" --
this explains much of the confusion when explaining W3 to windows
users.

If you consider that often the reader (rather than the author) might
want to chose which figues are expanded inline rather than put in a  
separate window, and also that the reader (rather tham the author)
might want to chose whether related things are PRESENTed  
automatically or not,  then the use of <A> with switches looks
more appropriate. As Tony points out, an advantage is that it will
be handled relatively well by browsers which can't do it or
old ones which don't understand it.

> (Maybe
> I don't understand it, though... do you have to click on the
> anchor, or does PRESENT mean that it is "automatically" clicked?

You didn't quite but you do now.  yes ... PRESENT means  
CONSIDER-THIS-CLICKED.
> If so, what happens to the text between the A and /A ?


It is replaced by the object because of the EMBED relationship.

> As I understand it, I can use Marc A's scheme for inline pictures
> (which might be big) or icons in anchors.


If you allow an image, then suppose we also allow some content which  
includes anchors with x,y coordinates within the image. Then the
document can intercept mouse clicks and allow hypergraphics

I don't want to change HTML now if I can help it, until it has gone
to RFC track

Tim


From weber@eitech.com  Fri Feb 26 19:15:27 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24158; Fri, 26 Feb 93 19:15:27 MET
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04750; Fri, 26 Feb 1993 19:32:37 +0100
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA28537; Fri, 26 Feb 93 12:31:52 -0600
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA02974; Fri, 26 Feb 93 10:28:38 PST
Date: Fri, 26 Feb 93 10:28:38 PST
From: weber@eitech.com (Jay C. Weber)
Message-Id: <9302261828.AA02974@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG


While images are at the top of my list of desired medium types in a
WWW browser, I don't think we should add idiosyncratic hooks for media
one at a time.  Whatever happened to the enthusiasm for using the
MIME typing mechanism?  I made a concrete proposal a few months ago,
where HREFs can point to other parts in a MIME multipart (and thereby
to an "external-body"), and I've seen a similar idea recently regarding
embedding media clips in a "simplemail" format.  Don't we want to
take on something like this in HTML2?

Jay
---------------------------------------------------------------------
Jay C. Weber					weber@eitech.com
Enterprise Integration Technologies		weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100			(415)617-8002
Palo Alto, CA 94301

From evas@cs.few.eur.nl  Fri Feb 26 19:23:28 1993
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24317; Fri, 26 Feb 93 19:23:28 MET
Received: from kaa.cs.few.eur.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06115; Fri, 26 Feb 1993 19:40:40 +0100
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA20833; Fri, 26 Feb 93 19:40:38 +0100
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA14411; Fri, 26 Feb 93 19:40:33 +0100
Date: Fri, 26 Feb 93 19:40:33 +0100
Message-Id: <9302261840.AA14411@slc01.cs.few.eur.nl>
To: www-talk@nxoc01.cern.ch
Subject: Re: patch to exec from httpd

> I seem to remember something about a patch to httpd to allow mapping
> onto a command, rather than a file, but I can't remember where. Am I
> hallucinating, or can someone let me know where this thing is?

I have added some code to httpd to allow a filter to be run when 
a file with a certain extension is requested. 
The patches are on ftp.cs.few.eur.nl, file pub/www/Daemon0.9b.patch.
Here's the start of that file;

The patches add a generic conversion facility to the HTTP daemon.
The syntax of the httpd.conf file has been extended to include a 
'convert' entry. Below is a piece of our httpd.conf file:

	convert	info		/usr/pkg/www/bin/info2html
	convert	man		/usr/pkg/www/bin/man2html

'info' and 'man' are the file extensions and '/usr/pkg/www/bin/...'
are the filters that should convert the document to HTML.
The filter is called with the document name from the reference
as its only argument.

Note that the daemon code has the following extensions hard coded
so they can not be used with this facility:
	.html .rtf .tar .hqx .Z

If the daemon has been updated with this code and the filters
have been installed in the right directory, references like
'http://host/man/csh.man' or 'http://host/info/gcc.info' should
trigger the execution of the appropriate script and convert the
requested document to HTML format.

It is handy to create some mappings for the new document types
so references don't depend on the exact location of the documents
in your filesystem;

	map	/info/*		/usr/pkg/gnu/info/*
	#
	# map various man-page categories to directories:
	#
	map	/man/gnu/*	/usr/pkg/gnu/man/*
	map	/man/lang/*	/usr/lang/man/*
	map	/man/local/*	/usr/local/man/*
	map	/man/openwin/*	/usr/pkg/openwin3.0/man/*
	map	/man/newsprint/*	/usr/pkg/newsprint1.0/man/*
	map	/man/X/*	/usr/local/X11R5/man/*
	map	/man/*		/usr/man/*

The info2html and man2html filters are in the same directory
on our ftp server as this patch (host ftp.cs.few.eur.nl, directory
pub/www).

The sample conversion filters are written in Perl so you'll need the
perl program (available from archive sites all over the world);
make sure that the first line of the filters is correct
(/usr/local/bin/perl may not be the location of the perl
binary at your site).

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands
-----------------------------------------------------------------------------
 

From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 19:58:03 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24941; Fri, 26 Feb 93 19:58:03 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09644; Fri, 26 Feb 1993 20:15:17 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18356
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.CERN.CH); Fri, 26 Feb 93 13:15:15 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.CERN.CH id AA28911; Fri, 26 Feb 93 13:17:01 -0800
Date: Fri, 26 Feb 93 13:17:01 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302262117.AA28911@wintermute.ncsa.uiuc.edu>
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
In-Reply-To: <EAEA19FB30000191@SCS.SLAC.STANFORD.EDU>
References: <EAEA19FB30000191@SCS.SLAC.STANFORD.EDU>
X-Md4-Signature: f75e927fec973474e432749a0d90c7ab

"Tony Johnson (415) 926 2278" writes:
> I have something very similar in Midas 2.0 (in use here at SLAC, and
> due for public release any week now), except that all the names are
> different, and it has an extra argument NAME="name". It has almost
> exactly the same functionality as your proposed IMG tag. e.g.
> 
> <ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
> 
> The idea of the name parameter was to allow the browser to have a
> set of "built in" images. If the name matches a "built in" image it
> would use that instead of having to go out and fetch the image. The
> name could also act as a hint for "line mode" browsers as to what
> kind of a symbol to put in place of the image.

Sounds like a good idea -- we should have a list of more-or-less
standard names, then.  Which ones are you using?

> I was proposing to use the file extension (.xbm above) to tag what
> format the image was in, but with the intention that in future, when
> HTTP2 comes along, the same format negotiation technique would be
> used to access images.

Yup.  BTW, someone mentioned ``what happened to MIME'' -- this isn't a
substitute for the upcoming use of MIME as a standard document
mechanism; this provides a necessary and simple implementation of
functionality that's needed independently from MIME.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 20:02:39 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25043; Fri, 26 Feb 93 20:02:39 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09849; Fri, 26 Feb 1993 20:19:53 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18541
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Fri, 26 Feb 93 13:19:52 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:WWW-TALK@nxoc01.cern.ch id AA28924; Fri, 26 Feb 93 13:21:38 -0800
Date: Fri, 26 Feb 93 13:21:38 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302262121.AA28924@wintermute.ncsa.uiuc.edu>
To: Kim Peter Nyberg <kny@cs.hut.fi>
Cc: WWW-TALK@nxoc01.cern.ch
Subject: re: xmosaic experience
In-Reply-To: <199302261020.AA22920@cardhu.cs.hut.fi>
References: <199302261020.AA22920@cardhu.cs.hut.fi>
	<9302252239.AA21530@wintermute.ncsa.uiuc.edu>
	<EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
X-Md4-Signature: b92ea52940f158846b4e2c35c183fe16

Kim Peter Nyberg writes:
> Marc Andreessen writes:
>  > The X Window System has this (to me, fatally flawed) design decision I
>  > hadn't suspected.  X windows can only be so big.  Up to the size of a
>  > 16-bit integer, in fact, in pixels.  This is really really bad.  This
> 
> Well, unless we'll be seing >32k*32k displays in the near future, it's
> not that bad.

It is bad, because X's "virtual" window concept is a very convenient
way of doing things, and because the decision to chop pixel
coordinates to 16 bits is completely arbitrary -- Xlib in fact allows
you to pass in 32 bits, but this gets truncated to 16 bits by the time
the server gets it.  It's just plain silly that it's not 32 bits all
the way through.

>  > Mosaic does, which is lay out as much text as possible in the window
>  > and then give you convenient automatic inlined hyperlinks to the
>  > remainder of the text, partitioned into window-sized chunks.  Then
>  > tell me who's making fatally flawed decisions.
> 
> Hmmmh, no offence, but I think that's not not the correct way to
> solve the problem.

I agree that ideally we should be doing the scrolling ourselves, but
like I said, that has a number of concomitant effects that we're not
willing to accept right now.

> Btw, have the current x-clients implemented non-blocking transfers?
> It should be implemented in the common code, maybe it already is.
> It's really too bad that we don't have the time to support erwise
> (three of us are working almost full time at a software company, and
> try to get on with our studies as well). Maybe in the summer ...

I sure would like to have non-blocking I/O... I have looked at the
Erwise code for this, and am thinking about stealing a lot of your
changes, but haven't had time yet......

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 20:10:46 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25170; Fri, 26 Feb 93 20:10:46 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11187; Fri, 26 Feb 1993 20:28:01 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18948
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 26 Feb 93 13:27:59 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA28982; Fri, 26 Feb 93 13:29:45 -0800
Date: Fri, 26 Feb 93 13:29:45 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302262129.AA28982@wintermute.ncsa.uiuc.edu>
To: Jim Davis <davis@dri.cornell.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
In-Reply-To: <199302261507.AA14775@willow.tc.cornell.edu>
References: <199302261507.AA14775@willow.tc.cornell.edu>
X-Md4-Signature: e73cd9798efdf106e96d6611888d2999

Jim Davis writes:
> As for specifics of Marc A's proposal, two comments
> 
> 1) why have SRC instead of HREF?

Because I wanted to avoid overloading HREF -- doesn't really make
sense in this context, I don't think.

> 2) It would be nice if there was a way to specify the content type,
> e.g. 
> 
> <IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>
> 
> But I am completely willing to live with the requirement that I specify
> the content type by file extension.  It's good enough for me.

Actually, in Mosaic this will be possible by doing something like:

<A HREF="http://nsa.gov/pub/sounds/gorby.au"><IMG SRC="myimage.xbm></A>

Simple.....

Marc


From marca@wintermute.ncsa.uiuc.edu  Fri Feb 26 20:13:14 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25208; Fri, 26 Feb 93 20:13:14 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11979; Fri, 26 Feb 1993 20:30:28 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA19103
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Fri, 26 Feb 93 13:30:25 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:davis@dri.cornell.edu id AA28994; Fri, 26 Feb 93 13:32:09 -0800
Date: Fri, 26 Feb 93 13:32:09 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9302262132.AA28994@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch
Cc: Jim Davis <davis@dri.cornell.edu>, www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
In-Reply-To: <9302261712.AA06142@www3.cern.ch>
References: <9302261712.AA06142@www3.cern.ch>
X-Md4-Signature: 20aa4d97a13bad2f25e2b580974952ee

Tim Berners-Lee writes:
> I don't want to change HTML now if I can help it, until it has gone
> to RFC track

I absolutely agree in all cases -- my purpose in suggesting IMG is
that things are reaching the point where some browsers are going to be
implementing this feature somehow, even if it's not standard, just
because it's the logical next step, and it would be great to have
consistency from the beginning -- so that when HTML2 comes along,
we're all still in lockstep.....

Cheers,
Marc


From weber@eitech.com  Fri Feb 26 22:46:39 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27614; Fri, 26 Feb 93 22:46:39 MET
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29063; Fri, 26 Feb 1993 23:03:53 +0100
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA03322; Fri, 26 Feb 93 16:03:24 -0600
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA03785; Fri, 26 Feb 93 14:00:12 PST
Date: Fri, 26 Feb 93 14:00:12 PST
From: weber@eitech.com (Jay C. Weber)
Message-Id: <9302262200.AA03785@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG

> From marca@wintermute.ncsa.uiuc.edu Fri Feb 26 11:12:42 1993
> 
> Yup.  BTW, someone mentioned ``what happened to MIME'' -- this isn't a
> substitute for the upcoming use of MIME as a standard document
> mechanism; this provides a necessary and simple implementation of
> functionality that's needed independently from MIME.

Wait a minute -- let's temporarily forget about MIME, if it clouds the
issue.  My objection was to the discussion of "how are we going to
support embedded images" rather than "how are we going to support
embedded objections in various media".

Otherwise, next week someone is going to suggest 'lets put in a new
tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd">' for audio.
There shouldn't be much cost in going with something that generalizes.

Jay
---------------------------------------------------------------------
Jay C. Weber					weber@eitech.com
Enterprise Integration Technologies		weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100			(415)617-8002
Palo Alto, CA 94301

From ebina@void.ncsa.uiuc.edu  Fri Feb 26 22:54:48 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27707; Fri, 26 Feb 93 22:54:48 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00431; Fri, 26 Feb 1993 23:12:02 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA29109
  (5.65a/IDA-1.4.2 for WWW-TALK@nxoc01.cern.ch); Fri, 26 Feb 93 16:11:19 -0600
Return-Path: <ebina@void.ncsa.uiuc.edu>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
	id AA16478; Fri, 26 Feb 93 16:10:31 CST
Message-Id: <9302262210.AA16478@void.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), Guido.van.Rossum@cwi.nl,
        WWW-TALK@nxoc01.cern.ch
Subject: Re: xmosaic experience 
In-Reply-To: Your message of "Thu, 25 Feb 93 16:19:16 PST."
             <8fXK84sB0KGW8v0Ycj@holmes.parc.xerox.com> 
Date: Fri, 26 Feb 93 16:10:29 -0600
From: ebina@ncsa.uiuc.edu


> By the way, Viola, the only
> other browser I use, *does* in fact use a text widget, and handles my
> document just fine.

Actually, from having just looked at the viola code, I don't see that it
uses a text widget anywhere.  They have their own code to figure out the
visible text, and draw it each time.


>  
>  Actually, I don't think it's a pixmap.  What every X text widget I'm
>  aware of does, is this:  It puts up a single window, and figures out
>  what lines of the text to paint in that window.  When the user scrolls
>  the text, it re-figures the lines, and repaints the window.  Thus it can
>  handle text of arbitrary length, with relatively small use of X Window
>  resources, even if backing store is enabled; in fact, backing store
>  works well with this scheme.

How many X text widgets are you aware of?  Certainly the Motif Text widget
does NOT do what you describe.  The Athena Text widget does.  You have some
other text widget somewhere you are referring to?


As the author of the HTMLwidget (yes, it IS a widget, and you could link it
into either Athena or Motif and it will work with the other widgets) I 
suppose I should defend it a little here.

In general the criticisms of my design decision are correct, in specifics
they have all been wrong.  As I believe others have pointed out by now, your
X server is NOT allocating some huge chunk of memory.  Motif made the same
decision I did, and Athena did not.  There are many reasons behind the
decision, I will only mention one important one here that no one else has
covered yet.  I wanted my widget to work with other widgets sets
(specifically with either Athena or Motif).  In order to do the kind of
viewport scrolling Bill would like, the widget, has to know intimate details
about the internals of a second scrollbar widget which it is going to
display for scrolling.  This ties you to whatever widgets set's scrollbar
you end up using.

In the long run (xmosaic 2.0 or 3.0 if the project lasts that long) the
widget will be changed to do pretty much what Bill describes.  This will
tie it to the Motif widget set, and make it unusable in other widget
sets.  I personally dislike this because I disapprove of OSF's frequently
heavy handed methods, and don't like to see all my work benefitting them,
and only them, but other design decisions override my personal preferences,
and simple practicality forces the widget re-write.


As to the heated argument that seems to have resulted.  Sigh........
It would be nice if everyone double checked their facts before posting
them to thousands of people world-wide, but the majority of the people
on the net do not (including me at times).  This is unfortunate.

Marc,
	It seems to be human nature that if something works and they like
it, most say nothing.  But if they don't like it, most yell loudly. 
Someone once told me you can tell a software success by how many people 
were complaining, the more complaints, the more successful it was.  I
believe this is true.  So far we are in the envious position of receiveing
MORE praise than complaints.  Think a moment about how many happy quiet
people this means, compared to how few unhappy noisy people



	Eric Bina
	ebina@ncsa.uiuc.edu

From janssen@parc.xerox.com  Fri Feb 26 23:02:30 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27809; Fri, 26 Feb 93 23:02:30 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00626; Fri, 26 Feb 1993 23:19:45 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11803>; Fri, 26 Feb 1993 14:19:28 PST
Received: by holmes.parc.xerox.com id <25546>; Fri, 26 Feb 1993 14:19:18 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Fri, 26 Feb 1993 14:19:13 -0800 (PST)
Message-Id: <4fXdRVgB0KGWEv0WUA@holmes.parc.xerox.com>
Date: 	Fri, 26 Feb 1993 14:19:13 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Guido.van.Rossum@cwi.nl
Subject: Re: xmosaic experience
Cc: marca@ncsa.uiuc.edu (Marc Andreessen), WWW-TALK@nxoc01.cern.ch,
        ebina@ncsa.uiuc.edu
In-Reply-To: <9302260908.AA15955=guido@voorn.cwi.nl>
References: <9302260908.AA15955=guido@voorn.cwi.nl>

Excerpts from direct: 26-Feb-93 Re: xmosaic experience
Guido.van.Rossum@cwi.nl (1129)

> I'll let Marc answer your attacks on XMosaic, but your knowledge of X
> is less than what I expected.

Less than I expected, too  :-).

My, I hope I'm not causing anyone to commit suicide here...  I never
meant to ``attack'' XMosaic (which I like the general shape of), just
comment on some aspect of it (its scrolling system), which struck me as
unusual, and subject to some surprising restrictions, which I thought
others might enjoy knowing about.  Never mind :-)

Bill

From wei@xcf.berkeley.edu  Sat Feb 27 02:19:27 1993
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29987; Sat, 27 Feb 93 02:19:27 MET
Received: from xcf.Berkeley.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25709; Sat, 27 Feb 1993 02:36:42 +0100
Received: by xcf.Berkeley.EDU (5.65/XCF-1.34)
	id AA16512; Fri, 26 Feb 93 17:37:29 -0800
Date: Fri, 26 Feb 93 17:37:29 -0800
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9302270137.AA16512@xcf.Berkeley.EDU>
To: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG

To: marca@ncsa.uiuc.edu, timbl@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
Cc: davis@dri.cornell.edu

> > Tim Berners-Lee writes:
> > I don't want to change HTML now if I can help it, until it has gone
> > to RFC track. 
>
> Marc wrote:
> I absolutely agree in all cases -- my purpose in suggesting IMG is
> that things are reaching the point where some browsers are going to be
> implementing this feature somehow, even if it's not standard, just
> because it's the logical next step, and it would be great to have
> consistency from the beginning -- so that when HTML2 comes along,
> we're all still in lockstep.....

Yup, yup... Since this is becoming an issue, I might as well mention 
that viola too has a number of bitmap tags, but for a DTD other than HTML,
because it'd be a mess to mix such things with the current HTML. At this
point, HTML should stay stable.

Yup, we obviously need to agree upon the namings, etc, from the start, 
or it's gonna be a sincere pain to converge later... I don't have any 
particular preference for the names/syntax, as long as there is some 
accounting for the format used (not by file extension, but preferably
by using MIME format identifiers).

-Pei

From timbl  Sat Feb 27 16:49:48 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03815; Sat, 27 Feb 93 16:49:48 MET
Date: Sat, 27 Feb 93 16:49:48 MET
From: timbl (Tim Berners-Lee)
Message-Id: <9302271549.AA03815@ nxoc01.cern.ch >
To: marca@ncsa.uiuc.edu, timbl@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
Cc: davis@dri.cornell.edu, www-talk@nxoc01.cern.ch

Ok, so for HTML2 let's have something for inclusion.
I don't see any reason to limit it to images. Like
it could be more text or whatever.

SGML does provide an official way of doing this folks
and even if Dan C ain't here to round us up we maybe
ought to stick to the track.  It might have some useful
spinnoffs like people assuming that any SYSTEM attribute,
instead of being a "system defined" path for an
entity, would be a URI.

How about
<!ENTITY ICON6 SYSTEM "http://blah..">&ICON6;

Tim BL

From W.vanLeeuwen@nikhef.nl  Mon Mar  1 08:58:01 1993
Return-Path: <W.vanLeeuwen@nikhef.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17152; Mon, 1 Mar 93 08:58:01 MET
Received: from nikhefh.nikhef.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25655; Mon, 1 Mar 1993 09:15:19 +0100
Received: by nikhefh.nikhef.nl; Mon, 1 Mar 93 09:15:00 +0100
Message-Id: <9303010815.AA17525@nikhefh.nikhef.nl>
Date: Mon, 1 Mar 93 09:15:00 +0100
From: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)
Organisation: Nikhef-H (National Institute for Nuclear and High-Energy Physics)
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 5925013, +31 2995 2499 (home)
Telex: 10262 hef nl
Telefax: +31 20 5925155
To: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Subject: Re: patch to exec from httpd
Cc: www-talk@nxoc01.cern.ch

| I seem to remember something about a patch to httpd to allow mapping
| onto a command, rather than a file, but I can't remember where. Am I
| hallucinating, or can someone let me know where this thing is?

The NIKHEF answer to this question can be found in

 http://www.nikhef.nl/www/pub/default/how_to_hook.html

Willem van Leeuwen

From dsr@hplb.hpl.hp.com  Mon Mar  1 10:11:32 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17643; Mon, 1 Mar 93 10:11:32 MET
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05130; Mon, 1 Mar 1993 10:28:51 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 1 Mar 93 09:24:04 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12454; Mon, 1 Mar 93 09:29:52 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9303010929.AA12454@manuel.hpl.hp.com>
Subject: Re: proposed new tag: IMG
To: www-talk@nxoc01.cern.ch
Date: Mon, 1 Mar 93 9:29:50 GMT
Mailer: Elm [revision: 66.36.1.1]

> While images are at the top of my list of desired medium types in a
> WWW browser, I don't think we should add idiosyncratic hooks for media
> one at a time.  Whatever happened to the enthusiasm for using the
> MIME typing mechanism?  I made a concrete proposal a few months ago,
> where HREFs can point to other parts in a MIME multipart (and thereby
> to an "external-body"), and I've seen a similar idea recently regarding
> embedding media clips in a "simplemail" format.  Don't we want to
> take on something like this in HTML2?

True indeed! I want to consider a whole range of possible image/line art
types, along with the possibility of format negotiation. Tim's note
on supporting clickable areas within images is also important

Dave Raggett, HPLabs

From gss@iil.intel.com  Mon Mar  1 12:01:42 1993
Return-Path: <gss@iil.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18424; Mon, 1 Mar 93 12:01:42 MET
Received: from hermes.intel.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17436; Mon, 1 Mar 1993 12:19:02 +0100
Received: from iil.intel.com by hermes.intel.com (5.65/10.0i); Mon, 1 Mar 93 03:18:36 -0800
Received: by iil (5.57/10.0i); Mon, 1 Mar 93 13:18:23 +0200
From: gss@iil.intel.com (Sheaffer Gad)
Received: by ilx051 (AIX 3.2/UCB 5.64/IDC-RS6000-AIX-3.2)
	id AA63399; Mon, 1 Mar 1993 13:18:30 +0200
Date: Mon, 1 Mar 1993 13:18:30 +0200
Message-Id: <9303011118.AA63399@ilx051>
To: Iain.Lea%anl433.uucp@germany.eu.net, TONYJ@scs.slac.stanford.edu,
        gss@iil.intel.com, marca@ncsa.uiuc.edu, wei@xcf.berkeley.edu,
        www-talk@nxoc01.cern.ch
Subject: Reading news via WWW browsers


A couple of suggestions on better ways of reading news via WWW browsers.

Disclaimer: The only browser I used so far is Viola.

1 - Most discussions in most newsgroups consist of threads. Someone starts a
    thread, others respond, and so forth. We are using here a newsreader called
    TIN (written by Iain.Lea%anl433.uucp@Germany.EU.net) that whenever a news
    group in entered, it first indexes all the postings into threads, and then
    presents a view of the group traffic as a collection of threads.
    You pick a thread, and start from the first posting. The next posting you
    will get will be the next one along the thread.

    This approach lends itself very well to a hypertext browser. Using the 
    same indexing method as TIN, it will embed a link into the end of  each 
    article that will point to the next one in the thread, in addition to
    links in the beginning of the article that point to the previous article
    in the thread and to the start of the thread.

    Also having a menu of threads instead of a menu of postings at the
    news group entrance, makes the menu more compact and the access more 
    convenient.

    Again, the credit goes to Iain Lea and his newsreader is the best I have 
    seen so far.


2 - The newsreader part should in my opinion be part of WWW, not the browser.
    That way the effort will not be duplicated in each and every browser. In 
    the same way that WWW uses gophers and WAIS servers, it can use distributed
    news servers, that know how to feed it hypertext.

3 - Is there a way to read news groups not carried locally via the WWW ?
    We have here a rather limited selection on newsgroups (only 1500 or so :-)
    Some people are not that fortunate, and I know of many groups we do not
    carry either. Additionally, postings are kept here only for about 3 days.
    
    So - how about a facility to read news at the source?


4 - At least in viola there is no way to save locally a news article, thread
    or any remote file (sort of FTP it over). How about other browsers ?

    Do I have to go outside browser to bring it over, pick it with the mouse 
    from the screen or is there a way to do it from within?


I am new to this list, so please - hold your flame throwers.


Gad


From marca@wintermute.ncsa.uiuc.edu  Mon Mar  1 16:45:49 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01627; Mon, 1 Mar 93 16:45:49 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16889; Mon, 1 Mar 1993 17:03:01 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA10423
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 1 Mar 93 10:02:25 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:TONYJ@scs.slac.stanford.edu id AA14688; Mon, 1 Mar 93 10:04:08 -0800
Date: Mon, 1 Mar 93 10:04:08 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303011804.AA14688@wintermute.ncsa.uiuc.edu>
To: gss@iil.intel.com (Sheaffer Gad)
Cc: TONYJ@scs.slac.stanford.edu, gss@iil.intel.com, marca@ncsa.uiuc.edu,
        wei@xcf.berkeley.edu, www-talk@nxoc01.cern.ch
Subject: Reading news via WWW browsers
In-Reply-To: <9303011118.AA63399@ilx051>
References: <9303011118.AA63399@ilx051>
X-Md4-Signature: e0415b599af5fd8a17529647b6d71e6f

Sheaffer Gad writes:
>     Using the same indexing method as TIN, it will embed a link into
>     the end of each article that will point to the next one in the
>     thread, in addition to links in the beginning of the article
>     that point to the previous article in the thread and to the
>     start of the thread.
> 
>     Also having a menu of threads instead of a menu of postings at
>     the news group entrance, makes the menu more compact and the
>     access more convenient.

Good idea!  I can't wait to see your code... :-).

(I agree that TIN is the best newsreader I've seen so far in terms of
threading, etc. -- would be a good place to steal code from, if it's
legal.)

> 2 - The newsreader part should in my opinion be part of WWW, not the browser.
>     That way the effort will not be duplicated in each and every
>     browser. In the same way that WWW uses gophers and WAIS servers,
>     it can use distributed news servers, that know how to feed it
>     hypertext.

Except these hypertext news servers don't exist yet.  Again, can't
wait to see the code... (also, would be a pain in the butt to get the
current NNTP servers moved over to the new code -- probably better to
just rely on existing servers until the whole news population moves to
the next level of functionality -- and who knows, maybe that will be
hypertext).

> 3 - Is there a way to read news groups not carried locally via the WWW ?
>     We have here a rather limited selection on newsgroups (only 1500
>     or so :-) Some people are not that fortunate, and I know of many
>     groups we do not carry either. Additionally, postings are kept
>     here only for about 3 days.
>     
>     So - how about a facility to read news at the source?

Well, there's no such thing even in the news world itself, so I don't
know how we can do any better...

> 4 - At least in viola there is no way to save locally a news article, thread
>     or any remote file (sort of FTP it over). How about other
>     browsers ?

Mosaic lets you save/mail/print the current document (article), in
HTML, plaintext, or formatted text.  I'm not up to date on the other
browsers anymore.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From dsr@hplb.hpl.hp.com  Mon Mar  1 18:54:48 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03678; Mon, 1 Mar 93 18:54:48 MET
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02681; Mon, 1 Mar 1993 19:12:05 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 1 Mar 93 18:07:24 GMT
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12988; Mon, 1 Mar 93 18:13:13 GMT
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9303011813.AA12988@manuel.hpl.hp.com>
Subject: Re Reading news via WWW browsers
To: www-talk@nxoc01.cern.ch
Date: Mon, 1 Mar 93 18:13:11 GMT
Mailer: Elm [revision: 66.36.1.1]

> Most discussions in most newsgroups consist of threads. Someone starts a
> thread, others respond, and so forth. We are using here a newsreader called
> TIN (written by Iain.Lea%anl433.uucp@Germany.EU.net) that whenever a news
> group in entered, it first indexes all the postings into threads, and then
> presents a view of the group traffic as a collection of threads.
> You pick a thread, and start from the first posting. The next posting you
> will get will be the next one along the thread.

Yes, most of us here use the Notes interface, which maintains such threads
or "notes strings" as part of its database. The current NNTP news servers are
much too dumb for this - it takes far too many messages for the client to
work out the threads. You can do it, but it is painfully slow if your
NNTP server is on a remote machine.

> This approach lends itself very well to a hypertext browser. Using the 
> same indexing method as TIN, it will embed a link into the end of  each 
> article that will point to the next one in the thread, in addition to
> links in the beginning of the article that point to the previous article
> in the thread and to the start of the thread.

Yes, I too have been thinking along these lines. The first step is an "agent"
program which runs daily to get the complete list of news groups, sorts them
alphabetically then builds them into a small group of html docs that allow
users to browse the newsgroup names hierarchically. The next step is to
extend the agent to build an html doc for each newsgroup's index. This
involves getting the headers for any new articles in that newsgroup and
can be linked to the job of tracking backward references, and updating a
database of threads/notes strings.

In the longer term, we can lobby for such support to be added into future
releases of the NNTP daemon. Our only hope in the short term is to build
agent processes that do the additional processing as a regular background
activity. You can think of these as a variety of "knowbots" which carry out
tasks that are impractical to perform on an interactive basis.

I am sure NEWS is due for a shakeup what with the arrival of MIME and html as
a registered format. The current restrictions on character sets and plain
text is rather cramping these days. Furthermore the number of newsgroups has
grown enormously over the last few years - the ability to carry popular
groups locally and to get the others on request from remote servers seems
long overdue.

> Is there a way to read news groups not carried locally via the WWW ?
> We have here a rather limited selection on newsgroups (only 1500 or so :-)
> Some people are not that fortunate, and I know of many groups we do not
> carry either. Additionally, postings are kept here only for about 3 days.

I have been toying with an extension to the URL syntax for just this purpose:

        news://news.ysu.edu/alt.culture.*

This implies the list of newsgroups under alt.culture on the NNTP server
"news.ysu.edu".

        news://news.ysu.edu/alt.culture.usenet

This example specifies the newsgroup "alt.culture.usenet" as held on the
nntp server  "news.ysu.edu"

        news://news.ysu.edu/<C34u1w.7Ls@news.ysu.edu>

This specifies an actual news article from that newsgroup and server.

One outstanding problem is which machines archive what newsgroups? It is
often the case that the original article has been discarded from the local
server, and it would be really great if the browser could then try to get the
missing article from a remote archive system. The establishment of well known
servers for given groups would be a good start.

Best wishes

Dave Raggett, HPLabs, Bristol, England




From emv@garnet.msen.com  Mon Mar  1 19:14:49 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04003; Mon, 1 Mar 93 19:14:49 MET
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04378; Mon, 1 Mar 1993 19:32:08 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nTFHN-001IHrC@garnet.msen.com>; Mon, 1 Mar 93 13:31 WET
Message-Id: <m0nTFHN-001IHrC@garnet.msen.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: gss@iil.intel.com (Sheaffer Gad), TONYJ@scs.slac.stanford.edu,
        wei@xcf.berkeley.edu, www-talk@nxoc01.cern.ch
Subject: Re: Reading news via WWW browsers 
In-Reply-To: Your message of Mon, 01 Mar 93 10:04:08.
             <9303011804.AA14688@wintermute.ncsa.uiuc.edu> 
Date: Mon, 01 Mar 93 13:31:38 EST
From: Edward Vielmetti <emv@msen.com>

if i recall the html right, there was no way to specify that you read
news from a *particular* news server, a la the same way you'd point at
a particular gopher or wais server.

the syntax if you could would look something like
  nntp://news.msen.com:119/news.groups			a newsgroup
  nntp://news.msen.com:119/news.groups/1114		article (by number)
  nntp://news.msen.com:119/1236INNuq@news.msen.com	article (by msgid)

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)


From marca@wintermute.ncsa.uiuc.edu  Mon Mar  1 19:46:09 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04550; Mon, 1 Mar 93 19:46:09 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06915; Mon, 1 Mar 1993 20:03:25 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23802
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 1 Mar 93 13:03:23 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA15363; Mon, 1 Mar 93 13:05:08 -0800
Date: Mon, 1 Mar 93 13:05:08 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303012105.AA15363@wintermute.ncsa.uiuc.edu>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
In-Reply-To: <9303010929.AA12454@manuel.hpl.hp.com>
References: <9303010929.AA12454@manuel.hpl.hp.com>
X-Md4-Signature: c1e0ea50fa02b34e9e18d5a95a5194e0

Dave_Raggett writes:
> True indeed! I want to consider a whole range of possible image/line
> art types, along with the possibility of format negotiation. Tim's
> note on supporting clickable areas within images is also important

Actually, maybe we should think about a general-purpose procedural
graphics language within which we can embed arbitrary hyperlinks
attached to icons, images, or text, or anything.  Has anyone else seen
Intermedia's capabilities wrt this?  It's one of their most impressive
capabilities, actually.

Something like a cross between PostScript and CGM might work...
actually, maybe we should just use one or the other, and add the
extensions we need for the links.  Also we'd want to make sure that
it's completely editable.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From putz@parc.xerox.com  Mon Mar  1 20:09:23 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04913; Mon, 1 Mar 93 20:09:23 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08809; Mon, 1 Mar 1993 20:26:38 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11617>; Mon, 1 Mar 1993 11:26:24 PST
Received: by spoggles.parc.xerox.com id <58466>; Mon, 1 Mar 1993 11:26:14 -0800
Date: 	Mon, 1 Mar 1993 11:25:55 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: putz.parc@xerox.com
Subject: Re: Reading news via WWW browsers
In-Reply-To: <9303011118.AA63399@ilx051>
To: www-talk@nxoc01.cern.ch
Message-Id: <93Mar1.112614pst.58466@spoggles.parc.xerox.com>


Sheaffer Gad writes:
> 2 - The newsreader part should in my opinion be part of WWW, not the browser.

I agree.  I like the browsers be generic (although with some of
the new UI features being discussed) and not be burdened by
so many communication protocols.  Maybe even FTP should have
to go through a gateway WWW server.

Steve Putz
Xerox Palo Alto Research Center


From putz@parc.xerox.com  Mon Mar  1 20:20:31 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05124; Mon, 1 Mar 93 20:20:31 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10112; Mon, 1 Mar 1993 20:37:51 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11638>; Mon, 1 Mar 1993 11:37:35 PST
Received: by spoggles.parc.xerox.com id <58466>; Mon, 1 Mar 1993 11:37:31 -0800
Date: 	Mon, 1 Mar 1993 11:37:20 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: putz.parc@xerox.com
Subject: Re: Re Reading news via WWW browsers
In-Reply-To: <9303011813.AA12988@manuel.hpl.hp.com>
To: www-talk@nxoc01.cern.ch
Message-Id: <93Mar1.113731pst.58466@spoggles.parc.xerox.com>

I have a set of NetNews CD-ROMS from Sterling Software mounted in some
Pioneer CD-ROM changers.  They would make a reasonable news archive,
hooked up to a WWW server.  A full text index would be even better.  I am
looking into putting together such a server.

One problem is that Sterling is seriously behind in sending out the CD-ROMs.
I have not received any dated since August.  Too long a lag makes it less useful
as an archive for finding recently expired articles.  I'm even getting worried that
Sterling may discontinue the product (or go out of business).

-- Steve Putz

From marca@wintermute.ncsa.uiuc.edu  Mon Mar  1 20:21:48 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05139; Mon, 1 Mar 93 20:21:48 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10191; Mon, 1 Mar 1993 20:39:08 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26639
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 1 Mar 93 13:39:07 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA15746; Mon, 1 Mar 93 13:40:55 -0800
Date: Mon, 1 Mar 93 13:40:55 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303012140.AA15746@wintermute.ncsa.uiuc.edu>
To: putz.parc@xerox.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Reading news via WWW browsers
In-Reply-To: <93Mar1.112614pst.58466@spoggles.parc.xerox.com>
References: <9303011118.AA63399@ilx051>
	<93Mar1.112614pst.58466@spoggles.parc.xerox.com>
X-Md4-Signature: 284098158620968023b4ec0bf31e49a9

putz.parc@xerox.com writes:
> I agree.  I like the browsers be generic (although with some of
> the new UI features being discussed) and not be burdened by
> so many communication protocols.  Maybe even FTP should have
> to go through a gateway WWW server.

Yeegh!  When we have unlimited-bandwidth networks, then we can do
that, but until then, going through a gateway for something as
ubiquitous as FTP would be a mistreak IMHO....

Marc


From putz@parc.xerox.com  Mon Mar  1 20:37:51 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05392; Mon, 1 Mar 93 20:37:51 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11283; Mon, 1 Mar 1993 20:55:12 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11618>; Mon, 1 Mar 1993 11:54:47 PST
Received: by spoggles.parc.xerox.com id <58466>; Mon, 1 Mar 1993 11:54:34 -0800
Date: 	Mon, 1 Mar 1993 11:54:16 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: putz.parc@xerox.com
Subject: Re: Reading news via WWW browsers
In-Reply-To: "marca@wintermute.ncsa.uiuc.edu's message of Mon, 1 Mar 93 13:40:55 PST"
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Message-Id: <93Mar1.115434pst.58466@spoggles.parc.xerox.com>

> Yeegh!  When we have unlimited-bandwidth networks, then we can do
> that, but until then, going through a gateway for something as
> ubiquitous as FTP would be a mistreak IMHO....

I was thinking of a "local" gateway at each site (or even on the local workstation).
This makes sense for our site because all our off-site FTP traffic has to go through
a security gateway anyway.

Actually I believe the www library already has an optional provision for this anyway.
By setting an environment variable like WWW_file_GATEWAY, all "file:" requests
can be redirected to a local server.  Does this still work?

In any case, I still hold that fancy features like threaded news should be
implemented in a server, not in the WWW clients.

-- Steve

From marca@wintermute.ncsa.uiuc.edu  Mon Mar  1 20:41:25 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05446; Mon, 1 Mar 93 20:41:25 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11472; Mon, 1 Mar 1993 20:58:46 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28845
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 1 Mar 93 13:58:45 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA15837; Mon, 1 Mar 93 14:00:33 -0800
Date: Mon, 1 Mar 93 14:00:33 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303012200.AA15837@wintermute.ncsa.uiuc.edu>
To: putz.parc@xerox.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Reading news via WWW browsers
In-Reply-To: <93Mar1.115434pst.58466@spoggles.parc.xerox.com>
References: <93Mar1.115434pst.58466@spoggles.parc.xerox.com>
X-Md4-Signature: 746464fbf6bb760b8cad181c457ae733

putz.parc@xerox.com writes:
> In any case, I still hold that fancy features like threaded news
> should be implemented in a server, not in the WWW clients.

I agree!  Does this mean you're volunteering to write one?  :-)

Marc


From fine@cis.ohio-state.edu  Mon Mar  1 21:04:17 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05724; Mon, 1 Mar 93 21:04:17 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13521; Mon, 1 Mar 1993 21:21:38 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13987; Mon, 1 Mar 93 15:21:36 -0500
Date: Mon, 1 Mar 93 15:21:36 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9303012021.AA13987@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
X-Mailer: Perl Mail System v1.2


Here's my opinion.

The best way to do images in WWW is by using MIME.  I'm sure postscript
is already a supported subtype in MIME, and it deals very nicely with
mixing text and graphics.

But it isn't clickable, you say?  Yes your right.  I suspect there is
already an answer to this in display postscript.  Even if there isn't
the addition to standard postscript is trivial.  Define an anchor
command which specifies the URL and uses the current path as a closed
region for the button.  Since postscript deals so well with paths, this
makes arbitrary button shapes trivial.

Let's call this specially modified postscript HTPS.  Until HTPS becomes
some sort of standard, every copy of HTPS should include a piece of code
that asks the interpreter if it knows about the anchor command, and if
it doesn't it will substitute in a null command.

As far as implementation, this is easy, though not necessarily trivial.
Ghostscript already provides the ability to bind arbitrary functions to
mouse events.  It shouldn't be too horrible to set up anchor to keep
a table of button paths, and have mouse clicks call a function that looks
up what button they are in.

Let me point out that it wouldn't be hard to make such a system deal
with html too.  Many people already have code that converts html to
postscript.

	  tom

From janssen@parc.xerox.com  Mon Mar  1 23:27:26 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07483; Mon, 1 Mar 93 23:27:26 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26412; Mon, 1 Mar 1993 23:44:47 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11675>; Mon, 1 Mar 1993 14:44:22 PST
Received: by holmes.parc.xerox.com id <16134>; Mon, 1 Mar 1993 14:44:10 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon,  1 Mar 1993 14:44:01 -0800 (PST)
Message-Id: <sfYd6lEB0KGWM2qhZI@holmes.parc.xerox.com>
Date: 	Mon, 1 Mar 1993 14:44:01 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Iain.Lea%anl433.uucp@germany.eu.net, TONYJ@scs.slac.stanford.edu,
        gss@iil.intel.com, marca@ncsa.uiuc.edu, wei@xcf.berkeley.edu,
        www-talk@nxoc01.cern.ch, gss@iil.intel.com (Sheaffer Gad)
Subject: Re: Reading news via WWW browsers
In-Reply-To: <9303011118.AA63399@ilx051>
References: <9303011118.AA63399@ilx051>

Excerpts from ext.WorldWideWeb: 1-Mar-93 Reading news via WWW browsers
Sheaffer Gad@iil.intel.c (2279)

> We are using here a newsreader called
>     TIN (written by Iain.Lea%anl433.uucp@Germany.EU.net) that whenever a news
>     group in entered, it first indexes all the postings into threads, and then
>     presents a view of the group traffic as a collection of threads.

It's perhaps worth noting that the newsreader in use at the Software
Technology Program of MCC in 1987-1990, written by Michael Begeman,
called `gnews', did this.  `gnews' was released into the public domain
several years ago, but I don't know where to get it from MCC these days.
 Looks like the code can be used in other things, as long as the credit
is preserved.  I've put a copy for ftp as
ftp://parcftp.parc.xerox.com/transient/gnews.tar.Z.  It'll be there for
a couple of weeks.

Bill

From janssen@parc.xerox.com  Mon Mar  1 23:39:05 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07641; Mon, 1 Mar 93 23:39:05 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27560; Mon, 1 Mar 1993 23:56:26 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11671>; Mon, 1 Mar 1993 14:56:03 PST
Received: by holmes.parc.xerox.com id <16134>; Mon, 1 Mar 1993 14:55:59 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon,  1 Mar 1993 14:55:57 -0800 (PST)
Message-Id: <8fYdFxYB0KGWA2qi9Q@holmes.parc.xerox.com>
Date: 	Mon, 1 Mar 1993 14:55:57 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>, marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: proposed new tag: IMG
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9303012105.AA15363@wintermute.ncsa.uiuc.edu>
References: <9303010929.AA12454@manuel.hpl.hp.com>
	<9303012105.AA15363@wintermute.ncsa.uiuc.edu>

Excerpts from ext.WorldWideWeb: 1-Mar-93 Re: proposed new tag: IMG Marc
Andreessen@ncsa.uiu (884)

> Actually, maybe we should think about a general-purpose procedural
> graphics language within which we can embed arbitrary hyperlinks
> attached to icons, images, or text, or anything.  Has anyone else seen
> Intermedia's capabilities wrt this?  It's one of their most impressive
> capabilities, actually.

Other systems to look at which have this (fairly valuable) notion are
Andrew and Slate.  Andrew is built with _insets_, each of which has some
interesting type, such as text, bitmap, drawing, animation, message,
spreadsheet, etc.  The notion of arbitrary recursive embedding is
present, so that an inset of any kind can be embedded in any other kind
which supports embedding.  For example, an inset can be embedded at any
point in the text of the text widget, or in any rectangular area in the
drawing widget, or in any cell of the spreadsheet.  Each ``embedding''
consists of some direct information which specifies the display area of
the embedded information, and a pointer to the actual data object
(actually, in most current usage the embedded data object is directly
contained, but references do in fact work).

This business about embedding the display information is interesting, as
it seems to contradict the standard separation of data and display so
pervasive in Andrew.  In Andrew text, embedded insets are thought of as
single characters in rather strange fonts, so the rectangular area
information tells the text display widget the size of the ``character''.
 Similarly for embedded insets in the drawing widget.

Bill

From Nathan.Torkington@vuw.ac.nz  Tue Mar  2 00:19:53 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08099; Tue, 2 Mar 93 00:19:53 MET
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01569; Tue, 2 Mar 1993 00:36:52 +0100
Received: by kauri.vuw.ac.nz id AA20493
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Tue, 2 Mar 1993 12:36:43 +1300
Date: Tue, 2 Mar 1993 12:36:43 +1300
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199303012336.AA20493@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Internal links

I'm obviously not doing something right here.  I am using Mosaic, and
I have the following file called "test.html":

--begin
<T>Testing</T>
<H1><A HREF=#local>Hot Spot</A></H1>
Clicking on the words "Hot Spot" above should move the cursor to the
section below:
<P>
<H1><A NAME=local>Local Text</A></H1>
This is where the cursor should go to.
--end

but when I load it as a local file, it refuses to understand the
links.  It gets formatted okay, so it is being interpreted as an HTML
file, but the links aren't working.

When I click on a link, the file is redisplayed from the top of the
document.

This is most irritating :)

Any assistance would be gratefully appreciated (I have had the same
problem with the dumb-terminal client too).

Thanks,

Nat
(we now return you to your regularly scheduled battle for standards,
in which I vote for (a) using MIME descriptions for multimedia stuff,
and (b) writing gateways to serve ordinary RFC-compliant news as HTML
documents (by putting links for threads, and allowing searches for
keywords at the newsgroup and article levels))


From marca@wintermute.ncsa.uiuc.edu  Tue Mar  2 09:43:17 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12352; Tue, 2 Mar 93 09:43:17 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13558; Tue, 2 Mar 1993 10:00:38 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA08491
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 2 Mar 93 03:00:34 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA18802; Tue, 2 Mar 93 03:02:23 -0800
Date: Tue, 2 Mar 93 03:02:23 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303021102.AA18802@wintermute.ncsa.uiuc.edu>
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Cc: www-talk@nxoc01.cern.ch
Subject: Internal links
In-Reply-To: <199303012336.AA20493@kauri.vuw.ac.nz>
References: <199303012336.AA20493@kauri.vuw.ac.nz>
X-Md4-Signature: a047e8f7d911c1bcb1c24265d6002d63

Nathan Torkington writes:
> I'm obviously not doing something right here.  I am using Mosaic, and
> I have the following file called "test.html":
> 
> --begin
> <T>Testing</T>
> <H1><A HREF=#local>Hot Spot</A></H1>
> Clicking on the words "Hot Spot" above should move the cursor to the
> section below:
> <P>
> <H1><A NAME=local>Local Text</A></H1>
> This is where the cursor should go to.
> --end

(1) X Mosaic 0.8 doesn't jump to internal links inside documents like
    it should anyway; this is already fixed for 0.9.
(2) X Mosaic 0.9 won't behave any differently with your document,
    unless you've got a really small window, since all of the text is
    already in the window and there's nothing to jump to -- anchor
    local is already being displayed.  And what's the "cursor" you're
    referring to?  Not the mouse pointer??

BTW, <t> isn't HTML.

> When I click on a link, the file is redisplayed from the top of the
> document.
> 
> This is most irritating :)
> 
> Any assistance would be gratefully appreciated (I have had the same
> problem with the dumb-terminal client too).

What other behavior did you expect?

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@dxcern.cern.ch  Tue Mar  2 23:02:03 1993
Return-Path: <timbl@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22406; Tue, 2 Mar 93 23:02:03 MET
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04482; Tue, 2 Mar 1993 23:19:27 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04781; Tue, 2 Mar 1993 23:18:24 +0100
Date: Tue, 2 Mar 1993 23:18:24 +0100
From: timbl@dxcern.cern.ch (Tim Berners-Lee)
Message-Id: <9303022218.AA04781@dxcern.cern.ch>
To: marca@ncsa.uiuc.edu, putz.parc@xerox.com
Subject: Re: Reading news via WWW browsers
Cc: www-talk@nxoc01.cern.ch

First important point is that with the new library, the
same software modules will be pluggable into clients or
servers. The local file reading in the client will be
the same as the file reading in the server. Same with newsm
so you can chose what you put into a gateway and what goes
straight into the client. And given that each module turns
out (TIN may be bigger) to be pretty small I know where I
will want the code -- I will want my client to be able
to handle anything without recourse to a gateway. (I have
more than 640k.)  But I also know that I'll want to set
up gateways for everything for situations like being
on the end of a phone line without SLIP, or being in
a .com like PARC which requires a gateway. 

If someone IS going to hack TIN into a news access module,
please merge it with the NEW one not the old -- WWWizards
can look at 
http://info.cern.ch/hypertext/WWW/Library/HTNews.c
(the directory is browsable) but only for reference ..
don't build anyting till the files are all released.

BTW the line mode browser worked with the new library,
now I am putting in MIME parsing and HTTP2 so it is in peices again.

Tim BL

From timbl@dxcern.cern.ch  Tue Mar  2 23:09:24 1993
Return-Path: <timbl@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22527; Tue, 2 Mar 93 23:09:24 MET
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05142; Tue, 2 Mar 1993 23:26:49 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07248; Tue, 2 Mar 1993 23:25:51 +0100
Date: Tue, 2 Mar 1993 23:25:51 +0100
From: timbl@dxcern.cern.ch (Tim Berners-Lee)
Message-Id: <9303022225.AA07248@dxcern.cern.ch>
To: fine@cis.ohio-state.edu, www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG


HTTP2 allows a document to contain any type which
the user has said he can handle, not just registered MIME
types. So one can experiment. Yes I think there is a case
for postscript with hypertext.
I don't know whether display postcript has enough.
I know Adobe are trying to establish their own postscript-based
"PDF" which will have links, and be readable by their
proprietory brand of viewers.

I thought that a generic overlaying language for anchors
(Hytime based?) would allow the hypertext and the graphics/video
standards to evolve separately, which would help both.

Let the IMG tag be INCLUDE and let it refer to an arbitrary
document type.  Or EMBED if INCLUDE sounds like a cpp include
which people will expect to provide SGML source code to be
parsed inline -- not what was intended.

Tim BL

From emv@garnet.msen.com  Wed Mar  3 06:57:42 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27265; Wed, 3 Mar 93 06:57:42 MET
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04785; Wed, 3 Mar 1993 07:15:06 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nTmjJ-001II3C@garnet.msen.com>; Wed, 3 Mar 93 01:14 WET
Message-Id: <m0nTmjJ-001II3C@garnet.msen.com>
To: timbl@dxcern.cern.ch (Tim Berners-Lee)
Cc: marca@ncsa.uiuc.edu, putz.parc@xerox.com, www-talk@nxoc01.cern.ch
Subject: Re: Reading news via WWW browsers 
In-Reply-To: Your message of Tue, 02 Mar 93 23:18:24.
             <9303022218.AA04781@dxcern.cern.ch> 
Date: Wed, 03 Mar 93 01:14:43 EST
From: Edward Vielmetti <emv@msen.com>

if i were hacking HTNews I'd look at the work being done with the
'nov' News Overview database, which is a set of extensions for
threaded news readers to get back all of the relevant information from
a group (subject, from, date, references, newsgroups lines) in one
transaction, rather than fetching each header set separately.

but i'm not hackign HTNews right now,

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)


From janssen@parc.xerox.com  Wed Mar  3 08:23:57 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27617; Wed, 3 Mar 93 08:23:57 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11088; Wed, 3 Mar 1993 08:41:21 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11856>; Tue, 2 Mar 1993 23:41:10 PST
Received: by holmes.parc.xerox.com id <16134>; Tue, 2 Mar 1993 23:41:08 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue,  2 Mar 1993 23:41:07 -0800 (PST)
Message-Id: <UfZ64HIB0KGWE2qeFZ@holmes.parc.xerox.com>
Date: 	Tue, 2 Mar 1993 23:41:07 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: WWW program to fetch document source?

Is there a simple WWW tool which will will take a UDI or URL (and which
is officially used these days by WWW?) and write the source of the
document to stdout?  Something like

	wwwFetch file://foo.bar.type/blah/blah/oink.ps >/tmp/a

I notice that ``www -n -source'' still does a bit of formatting, enough
to confuse Postscript and GIF files.

Bill

From timbl@www3.cern.ch  Wed Mar  3 08:39:15 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27756; Wed, 3 Mar 93 08:39:15 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12405; Wed, 3 Mar 1993 08:56:39 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00692; Wed, 3 Mar 93 08:51:07 +0100
Date: Wed, 3 Mar 93 08:51:07 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303030751.AA00692@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Bill Janssen <janssen@parc.xerox.com>
Subject: Re: WWW program to fetch document source?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> 

> Begin forwarded message:
> 

> Date: 	Tue, 2 Mar 1993 23:41:07 PST
> Sender: Bill Janssen <janssen@parc.xerox.com>
> From: Bill Janssen <janssen@parc.xerox.com>
> To: www-talk@nxoc01.cern.ch
> Subject: WWW program to fetch document source?
> 

> Is there a simple WWW tool which will will take a UDI or URL (and  
which
> is officially used these days by WWW?)

URL is the term for something limited to an address. URI
means a URL OR something which looks like it but is a name
in an abstract space.  The IETF WG talks about URLs only as
no namespace exists.  [[The URI term has had a hard time as
noone accepts the concept of a (name or address) as some people are
so hot on defending the essential difference of names and addresses]]

> and write the source of the
> document to stdout?  Something like
> 

> 	wwwFetch file://foo.bar.type/blah/blah/oink.ps >/tmp/a
> 

> I notice that ``www -n -source'' still does a bit of formatting,  
enough
> to confuse Postscript and GIF files.

Really?  A few months ago (Oct 92, version 1.3a I think)
a shortcut was introduced so that the
-source option pipes the source direct (CRLF and all) to stdout.
"Should work"!  It was particularly needed (and tested)
for postscript. Before, the source was treated as a plain text file,  
and wrapped at the line length.

> Bill
> 

Tim

From Nathan.Torkington@vuw.ac.nz  Thu Mar  4 03:54:18 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12365; Thu, 4 Mar 93 03:54:18 MET
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09504; Thu, 4 Mar 1993 04:11:41 +0100
Received: by kauri.vuw.ac.nz id AA05386
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 4 Mar 1993 16:11:35 +1300
Date: Thu, 4 Mar 1993 16:11:35 +1300
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199303040311.AA05386@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: WAIStoHTML daemon

Is it just me, or is the code and Makefile for this absolutely
knackered?  I'm on an SGI with irix 4.0.4 and I had to change some
prototypes, as well as add other .o files to the compilation in order
that things like logfile and HTclienthost be known to the world.

When I finally get it to compile, wsrc2html dumps core and ParseHTML
does diddly.  Not that I'm getting frustrated by this point, or
anything :-).

Does anyone have nice, simple code (translation: something that will
compile) for a server that will either deliver local WAIS databases as
accessed through WAIS: URLs, or will give the alleged WAISGate
functionality without the problems I am having?  Failing that, a
pointer to a more recent than 0.9a daemon and 1.1a library would be
appreciated.

Thanks,

Nat
(PS something for all you client writers to add is a "local search"
function that searches the current node for text)

From marca@wintermute.ncsa.uiuc.edu  Thu Mar  4 04:28:10 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12567; Thu, 4 Mar 93 04:28:10 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11686; Thu, 4 Mar 1993 04:45:36 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23587
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 3 Mar 93 21:45:33 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA28225; Wed, 3 Mar 93 21:47:23 -0800
Date: Wed, 3 Mar 93 21:47:23 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303040547.AA28225@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Wednesday evening pre-release beta testers...?
X-Md4-Signature: 04e62ff6d131e4865af91e1b7d0ece99

Anybody awake tonight who wants to stress-test a pre-release 0.9 X
Mosaic, please let me know.....

Thanks,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Thu Mar  4 09:29:33 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14589; Thu, 4 Mar 93 09:29:33 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07381; Thu, 4 Mar 1993 09:46:57 +0100
Received: from uxc.cso.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA19798
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 4 Mar 93 02:46:53 -0600
Received: from wintermute.ncsa.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA12362
  (5.67a8/IDA-1.5 for <@newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch>); Thu, 4 Mar 1993 02:09:41 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA01057; Thu, 4 Mar 93 02:09:16 -0800
Date: Thu, 4 Mar 93 02:09:16 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303041009.AA01057@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu
Subject: NCSA Mosaic for X 0.9 released
X-Md4-Signature: 45ea884717beb8e4112219c5cdb83f79

Beta version 0.9 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is hereby released:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/xmosaic-0.9.tar.Z

This release of NCSA Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).
  DEC Ultrix.

Binaries for these platforms are available:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/binaries-0.9

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working binaries
are welcome.)  Documentation is available online, but is temporarily
out of date (I'll probably bring it up to date this weekend).  (Does
that look familiar yet???)

Changes since 0.8 include:

 o Some multimedia support. Yew asked for it...
    o GIF, JPEG, TIFF, audio, AIFF, DVI, MPEG, MIME, XWD,
      PostScript automatically recognized.
    o Pipe to external viewers (with viewers set via X resource
      mechanism).
    o Also retrieve images, audio over Gopher.
    o But not over HTTP (unless you're running a modified HTTP
      server).
    o Inlined MIME/multimedia support will be coming down the
      road, so this is all just a temporary hack.
 o Transparent handling of compressed (.Z) files.
 o Hotlist now *always* saved after modification.
 o Fixed occasional infinite loop/crash for some 8-bit documents.
 o Fixed various parsing bugs associated with using <xmp> instead of
   <plaintext> internally.
 o Links to specific anchors now work properly.
 o Fixed bug with failure in repeated accesses via FTP.
 o Fixed bug with spurious ^M's in Gopher anchors.
 o Fixed bug opening local file while visiting remote file.
 o Fixed display bug with punctuation falling off end of line.
 o Fixed problem with BadAlloc crashes on some servers.
 o Annotation text features.
    o Choice of annotation links in header or footer.
    o Automatic (& fast) updating of annotations on every document
      view.
    o New defaultAuthorName resource to override use of normal
      fullname.
    o Annotations now always use machine's full name.
 o Menubar item 'Delete This Annotation'.
 o Audio annotations (SGI only, so far).
 o Fixed BadWindow bug for annotation window on DECstations.
 o All plaintext files can now be annotated.
 o Fixed occasional problem with size of hotlist/history windows.
 o Added sample app-defaults files to distribution.
 o New resources for multimedia stuff:
    o gifViewerCommand (default 'xv')
    o jpegViewerCommand (default 'xv')
    o tiffViewerCommand (default 'xv')
    o audioPlayerCommand (default 'showaudio' from Metamail
      distribution)
    o aiffPlayerCommand (default 'sfplay' -- SGI specific)
    o dviViewerCommand (default 'xdvi')
    o mpegViewerCommand (default 'mpeg_play')
    o mimeViewerCommand (default 'xterm -e metamail')
    o xwdViewerCommand (default 'xwud -in')
    o rgbViewerCommand (default 'ipaste' -- SGI specific)
    o postscriptViewerCommand
 o Deleted annotations now have all corresponding disk files removed.
 o Mosaic is smarter about the <plaintext> HTML token at the head of
   plaintext files.
 o Lots of little cleanups and bug fixes.

We're targeting a 1.0 release around the middle of March, so quick
feedback and bug reports will be GREATLY appreciated.

Finally, thanks *again* to everyone who's been contributing comments
and bug reports -- keep 'em coming!

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From davis@dri.cornell.edu  Thu Mar  4 18:57:49 1993
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20985; Thu, 4 Mar 93 18:57:49 MET
Received: from WILLOW.TC.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24883; Thu, 4 Mar 1993 19:15:16 +0100
Received: by willow.tc.cornell.edu id AA23264
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 4 Mar 1993 13:15:10 -0500
Date: Thu, 4 Mar 1993 13:15:10 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199303041815.AA23264@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: new links

I am coming to appreciate how XMosaic keeps track of which links I
have traversed in a session, (although I also don't like it to keep
track across sessions) and it makes me want even more.

It would be nice the browser could somehow show me which links were
new, where new might mean either
 1) the anchor was not present in the document last time I saw it, or
 2) the document on the other side of anchor has changed.  Of course,
this is not easy!

The simplest way to achieve #1 is to have the client keep track, for
each document, of all the anchors in the document.  This would of
course increase the size of the data the client needs to keep track
of.

We can reduce the size of this data for those documents which adopt a
uniform naming convention for anchors, e.g. all anchors are
sequentially numbered and numbers are never re-used.  An alternative
would be to adopt the convention of annotating the anchor with the
time and date it was created, e.g. something like

<A HREF="http://wiretap.spy.com:70/clinton.phonebook"
   ANCHOR-CREATED-BY = "Boris Badenoff"
   ANCHOR-CREATED-DATE = "3 Mar 1993 12:00 est">

To achieve #2 is much harder, since, in general, a link has no way of
knowing when the target document has changed.  But sometimes a partial
solution is better than nothing.  A partial step would be to annotate
the link with the time and date that the target was modified, so that,
at least for those cases where you DO know the target has changed, the
client can notice that, e.g.

<A HREF="http://wiretap.spy.com:70/clinton.phonebook"
   TARGET-MODIFIED-DATE = "5 Mar 1993 1:00 est">

From broccol@csdsun1a.arlut.utexas.edu  Thu Mar  4 21:38:23 1993
Return-Path: <broccol@csdsun1a.arlut.utexas.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23653; Thu, 4 Mar 93 21:38:23 MET
Received: from csdsun1b.arlut.utexas.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10813; Thu, 4 Mar 1993 21:55:01 +0100
Received: by csdsun1a.arlut.utexas.edu (4.1/Alliant-5.0)
	id AA27430; Thu, 4 Mar 93 14:51:46 CST
Date: Thu, 4 Mar 93 14:51:46 CST
From: broccol@csdsun1a.arlut.utexas.edu (Jonathan Abbey)
Message-Id: <9303042051.AA27430@csdsun1a.arlut.utexas.edu>
To: marca@ncsa.uiuc.edu
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9303040547.AA28225@wintermute.ncsa.uiuc.edu> (marca@ncsa.uiuc.edu)
Subject: Wednesday evening pre-release beta testers...?


I'd be interested in taking a look at it.  BTW, I understand that
version 0.8 has been taken off of the FTP archive.. should we stop using
it for some reason?

Jonathan

From marca@wintermute.ncsa.uiuc.edu  Fri Mar  5 06:56:21 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29117; Fri, 5 Mar 93 06:56:21 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23467; Fri, 5 Mar 1993 07:13:50 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11150
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 5 Mar 93 00:13:47 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05770; Fri, 5 Mar 93 00:15:36 -0800
Date: Fri, 5 Mar 93 00:15:36 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303050815.AA05770@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: multimedia files over httpd
X-Md4-Signature: 2a57437c7fe621084fe8cdaa610a5778

Some people using NCSA Mosaic 0.9 have noticed that they can't put
multimedia files on their own httpd servers and retrieve them
correctly with Mosaic.  What's happening in most cases is that the WWW
Daemon is prepending <PLAINTEXT> to the head of those files.

The problem lies in HTRetrieve.c, line 180:

    if (*extension == '.') {
        return    0==strcmp(".html", extension) ? WWW_HTML
                : 0==strcmp(".rtf",  extension) ? WWW_RICHTEXT
                : 0==strcmp(".txt",  extension) ? WWW_PLAINTEXT
                : 0==strcmp(".tar",  extension) ? WWW_BINARY
                : 0==strcmp(".hqx",  extension) ? WWW_BINARY
                : 0==strcmp(".Z",  extension) ? WWW_BINARY
                : WWW_PLAINTEXT;        /* Unrecognised : try plain text */
    } else {
        return WWW_PLAINTEXT;
    }

...and line 295:

        /* Tell the client which format is to be sent */
        if (format == WWW_HTML) {
            status = read_file(soc, fd);
        } else {
            if (format==WWW_PLAINTEXT) {
#ifdef USE_PLAINTEXT
                HTWriteASCII(soc, "<PLAINTEXT>\r\n");
                read_file(soc, fd);
#else
                HTWriteASCII(soc, "<HEAD></HEAD><BODY>\r\n");
                HTSendPreformatted(soc, fd);
                HTWriteASCII(soc, "</BODY>\r\n");
#endif
            } else {
                HTWriteASCII(soc,
"Sorry, this document appears to be neither a plain text file nor hypertext file.\n");
                HTWriteASCII(soc,
"The current version of www does not yet handle multiple formats. Watch this space...\n");
                free(document_name);
                return fd;
            }
        }

Basically, if you hack this so it just sends back files with
unrecognized extensions (or some set of extensions that your server
would like to serve) without prepending anything, things will work.
The only gotcha I've found is that anything on the server without the
extension .txt will no longer be given a free ride as <plaintext> from
the server to the client.

An alternate solution is to put your images, sound files, etc. on your
anonymous FTP server or (shudder) your Gopher server and then point to
them at that location from your HTML documents.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Fri Mar  5 08:33:52 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29742; Fri, 5 Mar 93 08:33:52 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02093; Fri, 5 Mar 1993 08:51:21 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02377; Fri, 5 Mar 93 08:45:47 +0100
Date: Fri, 5 Mar 93 08:45:47 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303050745.AA02377@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: multimedia files over httpd
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> Basically, if you hack this so it just sends back files with
> unrecognized extensions (or some set of extensions that your server
> would like to serve) without prepending anything, things will work.

This is a hack -- the suffix is NOT supposed to mean anything in HTTP
and there are servers which serve things with no suffix at all,
and have totally unfilelike names for objects. So beware.

Or use the not quite released Daemon 1.0 which will MIME-wrap them
according to HTTP2.  The

Sorry for the delay... I should answer [even] less mail :-}

Tim

From evas@cs.few.eur.nl  Fri Mar  5 09:50:14 1993
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00550; Fri, 5 Mar 93 09:50:14 MET
Received: from kaa.cs.few.eur.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11030; Fri, 5 Mar 1993 10:07:13 +0100
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA20327; Fri, 5 Mar 93 10:07:00 +0100
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA04105; Fri, 5 Mar 93 10:06:56 +0100
Date: Fri, 5 Mar 93 10:06:56 +0100
Message-Id: <9303050906.AA04105@slc01.cs.few.eur.nl>
To: www-talk@nxoc01.cern.ch
Subject: LineMode browser v1.4 for MS-DOS/PC-NFS available via ftp

Version 1.4 of the WWW LineMode browser is now available for MS-DOS
with the PC-NFS TCP/IP implementation. This is a fairly straight port
of the linemode browser.

host:	ftp.cs.few.eur.nl
file:	pub/www/pc/wwwlm14.zip

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands

From montulli@ukanaix.cc.ukans.edu  Fri Mar  5 18:51:12 1993
Return-Path: <montulli@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07539; Fri, 5 Mar 93 18:51:12 MET
Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00624; Fri, 5 Mar 1993 19:08:42 +0100
Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA41960; Fri, 5 Mar 1993 12:10:36 -0600
From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
Message-Id: <9303051810.AA41960@ukanaix.cc.ukans.edu>
Subject: rlogin type
To: www-talk@nxoc01.cern.ch
Date: Fri, 5 Mar 93 12:10:35 CST
X-Mailer: ELM [version 2.3 PL2]

There has been one or two messages that I have read hinting
about this capibility but none that I have seen stating
very clearly that an rlogin type is needed.  So now I'm 
saying it.  How about an rlogin type.  This would look
very similar to telnet type.

rloginaddress
    rlogin://[user@]hostport

hostport
    host[:port]

host
    hostname | hostnumber

user
    xalphas

If a client cannot process an rlogin then it can be treated as
a regular telnet type.  This is basically just a convienence
routine, saving the user from typing in a username.  I wouldn't
request this if it wasn't so easy to implement.

Well how about it???

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************


From Nathan.Torkington@vuw.ac.nz  Mon Mar  8 04:27:29 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29606; Mon, 8 Mar 93 04:27:29 MET
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14089; Mon, 8 Mar 1993 04:45:01 +0100
Received: by kauri.vuw.ac.nz id AA19333
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Mon, 8 Mar 1993 16:44:55 +1300
Date: Mon, 8 Mar 1993 16:44:55 +1300
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199303080344.AA19333@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Browser questions

1) Highlight phrase tags would be handy to have -- any ideas if/when
the browsers will support this?

2) Will there be a curses browser in the near future?

3) Are there Mac/PC browsers that are even vaguely reliable?

Nat
(almost ready to choose WWW for our CWIS)

From joe@athena.mit.edu  Mon Mar  8 15:22:41 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04877; Mon, 8 Mar 93 15:22:41 MET
Received: from ATHENA.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26342; Mon, 8 Mar 1993 15:40:14 +0100
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA23600; Mon, 8 Mar 93 09:39:16 EST
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA21416; Mon, 8 Mar 93 09:37:59 -0500
Date: Mon, 8 Mar 93 09:37:59 -0500
Message-Id: <9303081437.AA21416@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch, tk-WWW@athena.mit.edu
Subject: Any thoughts on exec: URL?


In the next version of tkWWW, I'm planning to include an "exec:" URL
header.  If you select a tag with this header it will display the text
at the end of the address and ask the user if it wants to execute it
as a system call.

Any thoughts?  In particular, are there any security problems won't be
fixed by asking the user whether or not to execute the command before
doing so?



From rik@daneel.rdt.monash.edu.au  Tue Mar  9 00:32:49 1993
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12797; Tue, 9 Mar 93 00:32:49 MET
Received: from daneel.rdt.monash.edu.au by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06598; Tue, 9 Mar 1993 00:50:23 +0100
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA28984; Tue, 9 Mar 93 09:49:00 +1000
Message-Id: <9303082349.AA28984@daneel.rdt.monash.edu.au>
To: joe@athena.mit.edu
Cc: www-talk@nxoc01.cern.ch, tk-WWW@athena.mit.edu
Subject: Re: Any thoughts on exec: URL? 
In-Reply-To: Your message of "08 Mar 93 09:37:59 EST."
             <9303081437.AA21416@theodore-sturgeon> 
Date: Tue, 09 Mar 93 09:48:59 +1100
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

> In the next version of tkWWW, I'm planning to include an "exec:" URL
> header.  If you select a tag with this header it will display the text
> at the end of the address and ask the user if it wants to execute it
> as a system call.
> 
> Any thoughts?  In particular, are there any security problems won't be
> fixed by asking the user whether or not to execute the command before
> doing so?

This is bringing the security problem down on the knowledge of the
user, which has never been a good idea (otherwise, password systems
would _work_).  If the users don't understand what a command does, some
will never execute them (which is admittedly no worse than the current
situation), and some will always execute them, which doesn't provide
any security.  I can see the neophytes looking at the box that popped
up with some gibberish, and saying that the Web is too complicated,
and then going back to gopher ;-)

Also, this will be extremely client specific.  There's no advantage in
including the same extension in non-unix clients, as the exec will not
work in (say) VMS or MS-DOG.  I'd like to see clients converge
towards a standard (or at least, have a standard converge towards
the clients), but this is not possible if URL's will only be useful
for one OS.  It would also be annoying to maintain a different Web for
different clients.

You could probably make it work by designing a meta-language, that
could be implemented by each client.  This way, you can build the
security in from the start, and not worry about unknowledgeable
users.

rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au              || Systems Programmer
+61 3 560-3265 (AH) +61 3 565-3227 (BH)                 || and Administrator
Faculty of Computing and Information Technology,        || Vic. Institute of
Clayton Campus, Monash University                       || Forensic Pathology

From marca@wintermute.ncsa.uiuc.edu  Tue Mar  9 07:23:43 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16215; Tue, 9 Mar 93 07:23:43 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13200; Tue, 9 Mar 1993 07:41:20 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA25283
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 9 Mar 93 00:40:05 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:tk-WWW@athena.mit.edu id AA20114; Tue, 9 Mar 93 00:41:54 -0800
Date: Tue, 9 Mar 93 00:41:54 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303090841.AA20114@wintermute.ncsa.uiuc.edu>
To: joe@athena.mit.edu
Cc: tk-WWW@athena.mit.edu, www-talk@nxoc01.cern.ch
Subject: Any thoughts on exec: URL?
In-Reply-To: <9303081437.AA21416@theodore-sturgeon>
References: <9303081437.AA21416@theodore-sturgeon>
X-Md4-Signature: 1cec6b1d136a55b4c5a19952b85a762d

joe@athena.mit.edu writes:
> Any thoughts?  In particular, are there any security problems won't be
> fixed by asking the user whether or not to execute the command before
> doing so?

It's a mammoth security problem in general, don't you think?  Asking
the user whether or not to execute a command absolves you of
responsibility for the results, but the results could still be
catastrophic.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From W.vanLeeuwen@nikhef.nl  Tue Mar  9 15:47:14 1993
Return-Path: <W.vanLeeuwen@nikhef.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21885; Tue, 9 Mar 93 15:47:14 MET
Received: from nikhefh.nikhef.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15212; Tue, 9 Mar 1993 16:04:48 +0100
Received: by nikhefh.nikhef.nl; Tue, 9 Mar 93 16:03:36 +0100
Message-Id: <9303091503.AA23825@nikhefh.nikhef.nl>
Date: Tue, 9 Mar 93 16:03:36 +0100
From: W.vanLeeuwen@nikhef.nl (Willem van Leeuwen)
Organisation: Nikhef-H (National Institute for Nuclear and High-Energy Physics)
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 5925013, +31 2995 2499 (home)
Telex: 10262 hef nl
Telefax: +31 20 5925155
To: marca@ncsa.uiuc.edu
Subject: anonymous ftp and xmosaic
Cc: www-talk@nxoc01.cern.ch

Hi,

I finally understandd the problem with xmosaic not always being able
to make ftp connections.
Some systems managers demand a full email address as password for
an anonymous ftp connection.
Just user@ is not sufficient.
To overcome this problem ANON_FTP_HOSTNAME has to be defined in libwww/HTFTP.c.

diff -r xmosaic-0.9/libwww/HTFTP.c xmosaic-0.9.n/libwww/HTFTP.c
48a49
> #define ANON_FTP_HOSTNAME

Best regards,

Willem van Leeuwen

From gss@iil.intel.com  Tue Mar  9 16:22:51 1993
Return-Path: <gss@iil.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22435; Tue, 9 Mar 93 16:22:51 MET
Received: from [143.185.65.3] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20134; Tue, 9 Mar 1993 16:40:28 +0100
Received: from iil.intel.com by hermes.intel.com (5.65/10.0i); Tue, 9 Mar 93 07:38:58 -0800
Received: by iil (5.57/10.0i); Tue, 9 Mar 93 17:38:39 +0200
From: gss@iil.intel.com (Sheaffer Gad)
Received: by ilx051 (AIX 3.2/UCB 5.64/IDC-RS6000-AIX-3.2)
	id AA51097; Tue, 9 Mar 1993 17:38:49 +0200
Date: Tue, 9 Mar 1993 17:38:49 +0200
Message-Id: <9303091538.AA51097@ilx051>
To: wei@xcf.berkeley.edu
Subject: printing WAIS documents
Cc: www-talk@nxoc01.cern.ch



Viola uses the line mode browser to convert html documents to
text. In doing it for WAIS documents, I encounter two problems:

1 - the URL of those documents contain ";" telling the shell that
    the instruction ended. you ahve  to go out of viola, and enclose
    it in quotation marks.

2 - Even after doing that, I get a message saying:

    "Fatal Error:  Returned message too large"

Is the documnet to long for the line mode browser, or is the URL to long ?


Example - printing a page from the Usenet Cookbook whose URL is:

http://info.cern.ch:8001/cmns-moon.think.com:210/WWP/TEXT/1706/2=cmns-moon.think.com;3=0000000223WWP%20;7=%00;

Any idea where what is wrong ? Viola has no difficulty displaying the page.

Gad

From gss@iil.intel.com  Tue Mar  9 16:30:39 1993
Return-Path: <gss@iil.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22644; Tue, 9 Mar 93 16:30:39 MET
Received: from [143.185.65.3] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20612; Tue, 9 Mar 1993 16:48:16 +0100
Received: from iil.intel.com by hermes.intel.com (5.65/10.0i); Tue, 9 Mar 93 07:46:47 -0800
Received: by iil (5.57/10.0i); Tue, 9 Mar 93 17:46:28 +0200
From: gss@iil.intel.com (Sheaffer Gad)
Received: by ilx051 (AIX 3.2/UCB 5.64/IDC-RS6000-AIX-3.2)
	id AA55806; Tue, 9 Mar 1993 17:46:38 +0200
Date: Tue, 9 Mar 1993 17:46:38 +0200
Message-Id: <9303091546.AA55806@ilx051>
To: wei@xcf.berkeley.edu
Subject: WAIS search results
Cc: www-talk@nxoc01.cern.ch



Is it possible to keep search results as a document, so that after looking at 
one of the articles found I will not have to perform the search again, but
rather return to it, and look at something else there ? 

I am willing to allocate storage for a html document generated locally as a
result of  a keyword search.

Gad

From timbl@www3.cern.ch  Tue Mar  9 16:35:46 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22830; Tue, 9 Mar 93 16:35:46 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21670; Tue, 9 Mar 1993 16:53:23 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06125; Tue, 9 Mar 93 16:47:45 +0100
Date: Tue, 9 Mar 93 16:47:45 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303091547.AA06125@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: roeber@axpvms.cern.ch (Frederick G.M. Roeber)
Subject: Re: Telecom Digest Archives
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Begin forwarded message:
> 

> Date: Tue, 9 Mar 1993 15:00:59 +0100
> From: roeber@axpvms.cern.ch (Frederick G.M. Roeber)
> 

> Hi,
> 

> May I suggest adding a pointer to the Telecom Digest archives to  
the 

>  
http://info.cern.ch/hypertext/DataSources/bySubject/Computing/Overview 
.html 

> page?  The archive's URL is file://lcs.mit.edu/telecom-archive .  I  
think it'd 

> be useful.


Thanks, it's in.

> (Also, wearing my marketing hat, the telecom digest is rather well  
read.  I 

> think if somebody were to "hypertextize" a couple archive items --  
like the 

> country code and city code information -- and put them back in the  
archive, it 

> would be good advertising for the web.)
> 

> Best regards,
> Frederick.

Anyone care to pick this one up?

Tim

From timbl@www3.cern.ch  Tue Mar  9 18:09:55 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24779; Tue, 9 Mar 93 18:09:55 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04206; Tue, 9 Mar 1993 18:27:33 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06289; Tue, 9 Mar 93 18:21:56 +0100
Date: Tue, 9 Mar 93 18:21:56 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303091721.AA06289@www3.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Alpha test of wwwlib 2.0 for developers only


If any of you developers would like to cast a tolerant eye over
the new library, it is in

ftp://info.cern.ch/pub/www/dev/WWWLibrary_2.0-alpha.tar.Z

I am working om it all the time, but I thought that if you
want to fit in with the new architecure which is much
more flexible then you might want to see the interfaces and
try it out now.

The server and line mode browser both basically work using
the new library.
I haven't released them.

Tim BL

From Nathan.Torkington@vuw.ac.nz  Wed Mar 10 05:04:21 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03904; Wed, 10 Mar 93 05:04:21 MET
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11671; Wed, 10 Mar 1993 05:21:57 +0100
Received: by kauri.vuw.ac.nz id AA13306
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Wed, 10 Mar 1993 17:21:50 +1300
Date: Wed, 10 Mar 1993 17:21:50 +1300
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199303100421.AA13306@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: FAQ file

Is there a need for an entry point into the web that isn't part of the
web?  By that I mean something for the bazillions of people who don't
know about WWW yet, but who do read news.  This would be a periodic
post on news.answers, comp.infosystems.gopher, comp.infosystems.wais
and alt.hypertext, and would explain what the web is and how to access
it.

Nat

From RASHTY@hujivms.bitnet  Wed Mar 10 07:23:47 1993
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04978; Wed, 10 Mar 93 07:23:47 MET
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00147; Wed, 10 Mar 1993 07:41:27 +0100
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 3552; Wed, 10 Mar 93 07:39:19 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 0376; Wed, 10 Mar 1993 07:39:19 +0100
Received: by HUJIVMS (HUyMail-V6k); Wed, 10 Mar 93 08:41:16 +0200
Date:     Wed,  10 Mar 93 8:40 +0200
Message-Id: <10030093084056@HUJIVMS>
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch
Subject:  Alpha test of wwwlib 2.0 for developers only

Hi,

1) In the wwwlib 1.0 there is a problem with the ftp protocol, It is unable to
establish connection with VMS and other systems.

Part of this problem is the way it define the RETR command (it does it in a
unix style and not in a VMS style)

I think that in gopher+ this problem of accessing different ftp servers
is fixed,

Is it also in the new wwwlib 2.0 ???

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:                                                      **** Thanks !! **** :
: Dudu Rashty                Rashty@Vms.Huji.Ac.Il         __o     o__     :
: Computation Center         Bitnet:Rashty@HUJIVMS       _ \<,_   _.>/ _   :
: The Hebrew University      Phone:  +972-2-584397      (_)/ (_) (_) \(_)  :
: Jerusalem 91904, ISRAEL.   Fax:    +972-2-527349       D    u    d    u  :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From timbl@www3.cern.ch  Wed Mar 10 11:52:01 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07295; Wed, 10 Mar 93 11:52:01 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08707; Wed, 10 Mar 1993 12:09:41 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06896; Wed, 10 Mar 93 12:04:03 +0100
Date: Wed, 10 Mar 93 12:04:03 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303101104.AA06896@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch,
        Dennis Nicholson - BUBL <cijs03@vaxa.strath.ac.uk>, iiir@merit.edu,
        lis-link@mailbase.ac.uk, nir@mailbase.ac.uk
Subject: World-Wide Web documentation in paper form
Reply-To: timbl@nxoc01.cern.ch



For all of you that want to take the information about the
web on the plane with you and don't have a modem for your airphone,
or for those who simply love the rustle of paper, here are some of
the key documents about the web and how it works in paper form.

Each document is in available postscript (.ps) and also in plain  
ASCII text (.txt) form, in the anonymous FTP archive site at  
info.cern.ch. (FTP to info.cern.ch, log in as "anonymous", give your  
user@host as password, then change directory to pub/www/doc )

line-mode-guide.ps	Instructions for running the line-mode
			client

www-server-guide.ps	Instructions for running a server

http-spec.ps		The HTTP protocol used by new W3 servers
			
html-spec.ps		The Hypertext Markup Language (HTML)
			

The last three have recently been revised.

If anyone has any comments on these, please send them to me or
to the www-talk@info.cern.ch discussion list if you are a member.
The HTML and later the HTTP specs are headed in the Internet
Draft - RFC direction so comment at this stage is appreciated.
The documents are all generated from the hypertext, and so
apart from the specs which are designed to be linear documents, they  
made read a little strangely. None of them is perfect, but the  
pressure has been so high for printed documentation that we  
distribute them as they are.


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web team leader           (NeXTMail is ok)	
CERN, CN Division                     Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From timbl@www3.cern.ch  Wed Mar 10 15:41:14 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10384; Wed, 10 Mar 93 15:41:14 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07881; Wed, 10 Mar 1993 15:58:53 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA07093; Wed, 10 Mar 93 15:53:15 +0100
Date: Wed, 10 Mar 93 15:53:15 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303101453.AA07093@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: libwww 2.0-alpha  --- www and httpd available.
Reply-To: timbl@nxoc01.cern.ch


For developers:

I have put new 2.0-alpha compatible line mode browser and daemon  
sources into the same ftp://info.cern.ch/pub/www/dev directory as
the library so you can see how it works.  Yes, I know there
is lots of conceptal design which is not documented, but if you
have used the old library this should be much easier.  Documentation  
will come ...  I would like priority feedback on whether features
or documentation are preferred!

Some features of the new library are

- registration system for format-converting modules
- registration of external programs for
   presenting new types of object
- registration of protocol modules
- registration of filename suffix <-> content-type mapping

These registration routines exist, and a default initialisation files  
exists, initialisation will be done from config files, etc etc.
but you can add your own init module.

- HTML genereration as well as parsing
- Same module used by daemon and browser for looking at directories
- Ability to write files back in a protocol-independent manner

The www will for example (if DISPLAY is defined) run xv to view
jpeg and gif files, ghostview on postscript etc.  There is an  
embryonic test dataset in  
http://info.cern.ch/hypertext/WWW/Test/Overview.html
of things to test in the new protocol.

The current daemon will return a MIME format message if it gets a new
style request.  It will not (yet) be intelligent about which format  
to send back.  But the client provides all it needs to know.

Tim

From wei@swindle.berkeley.edu  Wed Mar 10 18:27:39 1993
Return-Path: <wei@swindle.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13740; Wed, 10 Mar 93 18:27:39 MET
Received: from swindle.Berkeley.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02387; Wed, 10 Mar 1993 18:45:17 +0100
Received: by swindle.Berkeley.EDU (5.65/XCF-1.34)
	id AA23889; Wed, 10 Mar 93 09:46:23 -0800
Date: Wed, 10 Mar 93 09:46:23 -0800
From: wei@swindle.berkeley.edu (Pei Y. Wei)
Message-Id: <9303101746.AA23889@swindle.Berkeley.EDU>
To: gss@iil.intel.com, wei@swindle.berkeley.edu
Subject: Re:  WAIS search results
Cc: www-talk@nxoc01.cern.ch

> Is it possible to keep search results as a document, so that after looking
> at one of the articles found I will not have to perform the search again, 
> but rather return to it, and look at something else there ? 
>
> I am willing to allocate storage for a html document generated locally as a
> result of  a keyword search.

That version of ViolaWWW forgets about the search result page after you
follow a link in it. A simple way to get around this, for now, is to 
simply clone that page first, then use it to navigate among the results.

-Pei

From fine@cis.ohio-state.edu  Wed Mar 10 19:30:49 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14635; Wed, 10 Mar 93 19:30:49 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10342; Wed, 10 Mar 1993 19:48:29 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA18814; Wed, 10 Mar 93 13:48:23 -0500
Date: Wed, 10 Mar 93 13:48:23 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9303101848.AA18814@soccer.cis.ohio-state.edu>
To: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Subject: Re: FAQ file
X-Mailer: Perl Mail System v1.2

>Is there a need for an entry point into the web that isn't part of the
>web?  By that I mean something for the bazillions of people who don't
>know about WWW yet, but who do read news.  This would be a periodic
>post on news.answers, comp.infosystems.gopher, comp.infosystems.wais
>and alt.hypertext, and would explain what the web is and how to access
>it.

Well, we are getting very near the point where we should do a Call for
Votes on the creation of comp.infosystems.www (I'd say we've reached
that point).  Once we get our newsgroup, then we should consider something
like that.  Didn't someone out there mention that they would handle
the voting?

     tom

From timbl@www3.cern.ch  Thu Mar 11 09:07:41 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22748; Thu, 11 Mar 93 09:07:41 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14060; Thu, 11 Mar 1993 09:25:23 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA07752; Thu, 11 Mar 93 09:19:43 +0100
Date: Thu, 11 Mar 93 09:19:43 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303110819.AA07752@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: World-Wide Web documentation in paper form
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Do you want spell-checking type information?

Not this stage, but any factual boobs or omissions,
ways in which presentation is bad,
or particularly technical problems with the protocols described!

> Nat

Tim

From emv@garnet.msen.com  Thu Mar 11 09:30:37 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23087; Thu, 11 Mar 93 09:30:37 MET
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17213; Thu, 11 Mar 1993 09:48:18 +0100
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nWiw3-001IGcC@garnet.msen.com>; Thu, 11 Mar 93 03:48 WET
Message-Id: <m0nWiw3-001IGcC@garnet.msen.com>
To: Thomas A. Fine <fine@cis.ohio-state.edu>
Cc: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Subject: Re: FAQ file 
In-Reply-To: Your message of Wed, 10 Mar 93 13:48:23.
             <9303101848.AA18814@soccer.cis.ohio-state.edu> 
Date: Thu, 11 Mar 93 03:48:00 EST
From: Edward Vielmetti <emv@msen.com>

> didn't someone out there mention that they would handle the voting

yes, i have mailboxes ready for it, "www-yes@msen.com" and
"www-no@msen.com".  if someone wants to test and confirm please do so.
i'd like to stick an auto-acknowlege on these too.

--Ed

ps if you do the FAQ right, you should be able to make it so that
people can use it as a link right into the rest of the web.   (a MIME
message, with a body part that's a pointer to someone's home page)

From montulli@stat1.cc.ukans.edu  Thu Mar 11 14:11:22 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25939; Thu, 11 Mar 93 14:11:22 MET
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25160; Thu, 11 Mar 1993 14:29:03 +0100
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA40364; Thu, 11 Mar 1993 07:23:29 -0600
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9303111323.AA40364@stat1.cc.ukans.edu>
Subject: Lynx 2.0 Alpha with WWW support
To: www-talk@nxoc01.cern.ch
Date: Thu, 11 Mar 93 7:23:29 CST
X-Mailer: ELM [version 2.3 PL2]

Lynx 2.0 (Alpha version) is now available.

Lynx was developed by the University of Kansas for use as a CWIS
interface.

With the help of the WWWLibrary Lynx is now a complete WWW client!

Lynx provides a simple, easy to use full screen curses interface 
for UNIX systems.  As well as some advanced features such as 
a configureable and editable home page for each user and cut
and paste functions for moving links to the home page.  

Lynx provides a simple yet powerful printing interface, providing
the functionality to mail files to yourself and any number of
system administrator configured printers.  Lynx also fills
in some of the missing Gopher interface. (CSO, file transfer, etc)

Assistance is needed for porting Lynx to all operating system, as
K.U. has a very limited number of operating systems in use.

For a limited time the alpha (and soon beta) version will be available
for anonymous ftp from 'acs220.cc.ukans.edu' in the /pub directory.

Any and all comments and suggestions are welcome and encouraged!

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************

From marca@wintermute.ncsa.uiuc.edu  Fri Mar 12 07:17:05 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09707; Fri, 12 Mar 93 07:17:05 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14220; Fri, 12 Mar 1993 07:34:48 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23748
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 12 Mar 93 00:34:46 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11337; Fri, 12 Mar 93 00:36:39 -0800
Date: Fri, 12 Mar 93 00:36:39 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303120836.AA11337@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: help stomp out a Mosaic bug under Ultrix 4.2...
X-Md4-Signature: c6b6e505ef601684c7e8aef9b757b75e

There seems to be a nasty li'l bug somewhere inside either Mosaic or
Motif that is causing an occasional coredump when closing a window,
but only on Ultrix boxes (and then only on some Ultrix boxes -- I
absolutely cannot reproduce it on our Ultrix box).  The traceback
looks like this:

>  0 abort.abort(0x84d82, 0x2b9612ee, 0x84d82, 0x2b9612ee, 0x4003b4)
["../fprintf.c":25, 0x5442ec]
   1 RealFatal() ["main.c":64, 0x4002cc]
   2 FatalProblem(sig = 10, code = 16, scp = 0x7fffa984, addr =
0x4002e8 = "\350\377\275'^T") ["main.c":79, 0x4003b0]
   3 _draw(0x2400114, 0x1013ddac, 0x7fffb030, 0x1010b158, 0x5)
["XmString.c":3470, 0x43732c]
   4 _XmStringDrawImage(0x1, 0x100132e0, 0x4feaf0, 0x1010b158, 0x5)
["XmString.c":3583, 0x4376d4]
   5 DrawList(0x0, 0x1, 0x1, 0x0, 0x0) ["List.c":2016, 0x44ab10]
   6 XmListDeleteItemsPos(0x46064c, 0x2, 0x22, 0x0, 0x40727c)
["List.c":5851, 0x451c68]
   7 mo_kill_node_descendents(win = 0x100926c8, node = 0x100d9778)
["history.c":79, 0x40a384]
   8 mo_delete_window(win = 0x100926c8) ["gui.c":3331, 0x407278]
   9 menubar_cb(w = 0x100cefa0, client_data = 0x10009 = "", call_data =
0x7fffafb0 = "\n") ["gui.c":2211, 0x405740]
   ...

If this happens to you, can you send me the values of count and
node->position in mo_kill_node_descendents()?  Also let me know if the
window history dialog was open for the window being closed at the
time.

Thanks much,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From ccprl@xdm001.ccc.cranfield.ac.uk  Fri Mar 12 14:43:35 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13263; Fri, 12 Mar 93 14:43:35 MET
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AB11767; Fri, 12 Mar 1993 15:01:16 +0100
Received: by xdm001 
	id AA18040; Fri, 12 Mar 93 14:01:09 GMT
Received: by xdm039 (5.57/4.7) id AA10183; Fri, 12 Mar 93 14:01:02 GMT
Message-Id: <9303121401.AA10183@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: WWW processing of tar files
Date: Fri, 12 Mar 93 14:00:58 GMT
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

Have WWW (or Gopher for that matter) developers considered processing
tar and tar.Z files as if they were directories? One could browse the
contents of a remote tar file, or treat it as a binary file to copy
back to the local host.

This has obvious application for shareware source at FTP archives, and
could save disk space and bandwidth: removing the need to copy an
entire tar file back when only a few are wanted; economising on server
disk space by not having to keep an unpacked directory tree as well as
a tar.Z; encouraging bulk transfers to be compressed, yet still
allowing the user to see "just files". Browsers would allow the user to
save the tar/tar.Z file, or just the list of contents, or transparently
unpack it. If added to libwww, it can be built easily into client and server ends.

Comments? Is this sensible?

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From timbl@dxcern.cern.ch  Fri Mar 12 16:57:21 1993
Return-Path: <timbl@dxcern.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15773; Fri, 12 Mar 93 16:57:21 MET
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01080; Fri, 12 Mar 1993 17:15:03 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07452; Fri, 12 Mar 1993 17:14:24 +0100
Date: Fri, 12 Mar 1993 17:14:24 +0100
From: timbl@dxcern.cern.ch (Tim Berners-Lee)
Message-Id: <9303121614.AA07452@dxcern.cern.ch>
To: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: Re:  WWW processing of tar files

This sounds fairly simple.  The question is, at which point should
the unpacking be done?  If the server simply presents the whole
file as a directory tree, then the client will never get the whole
tar file in one. But if the whole tar file is shipped over as a
lump, then looking at the first README is expensive.

How about both?  Suppose anz directorz which has an xxx.tar[.Z]
in it is visible as both xxx.tar.Z for capture and also as
a plain virtual directorz xxx for browsing?

The new librarz uses the same code for the server as for the client, so
having written one the other way will come free. I gets its just
a popen("zcat xxx.tar.Z | tar -tf -") ... can tar produce a
subdirectorz listing?  hmmm... shouldn't be a problem.

  
Sorry about the zy interchanges ... funnz kezboard lazout...
Swiss people will be able to read it, anzwaz!  :-)

Tim

From ccprl@xdm001.ccc.cranfield.ac.uk  Fri Mar 12 17:57:11 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16883; Fri, 12 Mar 93 17:57:11 MET
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10351; Fri, 12 Mar 1993 18:14:49 +0100
Received: by xdm001 
	id AA23826; Fri, 12 Mar 93 17:14:42 GMT
Received: by xdm039 (5.57/4.7) id AA11269; Fri, 12 Mar 93 17:14:31 GMT
Message-Id: <9303121714.AA11269@xdm039>
To: cbs%uk.ac.earn-relay::ch.cern.dxcern::timbl@cchub.decnet.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: Re: WWW processing of tar files 
In-Reply-To: Your message of Fri, 12 Mar 93 16:34:38 +0000.
             <9303121634.AA22968@xdm001> 
Date: Fri, 12 Mar 93 17:14:30 GMT
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> How about both?  Suppose anz directorz which has an xxx.tar[.Z]

Exactly what I was trying to get at. Clients and servers would have
dynamic settings like "treat_tar_files_as_directories" true/false.
Servers could have a setting, on a per directory basis, depending on
the presence of .treat_tar_files_as_directories, like .www_browsable,
or command line switches, so that tar/tar.Z files can appear as files,
directories or both, and also as contents listings (from tar tv) so
that clients don't need to haul the whole archive over the net or
traverse the tree to see what's in it. Possibly also a line or  flag in
httpd.conf, rather like the map extensions? I would incline to giving
server admins several different wasy to go about setting this, for
bulk, per dir and individual files. I dunno, Tim, you're the boss.

In essence, tar files would be treated like directory now are, with the
exception that the binary contents of the tars are of interest, whereas
the binary contents of directories aren't.

Peter

From paolo@venedig.ai.univie.ac.at  Fri Mar 12 18:15:13 1993
Return-Path: <paolo@venedig.ai.univie.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17168; Fri, 12 Mar 93 18:15:13 MET
Received: from moskau.ai.univie.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13464; Fri, 12 Mar 1993 18:32:40 +0100
Received: by moskau.ai.univie.ac.at id AA11211
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 12 Mar 1993 18:32:28 +0100
From: paolo petta <paolo@venedig.ai.univie.ac.at>
Message-Id: <199303121732.AA11211@moskau.ai.univie.ac.at>
Subject: Re:  WWW processing of tar files -> '.z' files!
To: www-talk@nxoc01.cern.ch
Date: Fri, 12 Mar 1993 18:32:25 +0100
X-Mailer: ELM [version 2.3 PL11]

[original message by Tim Berners-Lee ]
> 
> This sounds fairly simple.  The question is, at which point should
> the unpacking be done?  If the server simply presents the whole
> file as a directory tree, then the client will never get the whole
> tar file in one. But if the whole tar file is shipped over as a
> lump, then looking at the first README is expensive.
> 

A related request: with the Distribution of GNU software already
changed to gzip-ped '.z' files I would like to see gzip used in
www lest it does not entail any legalese problems. From my (shortsighted)
point of view this should be easy, as gzip "understands" (i.e.:uncompresses)
.Z files...

On a different note: has anyone done any work with the 'REL' and 'REV'
attributes, especially in combination with the 'Includes' relationship?
After LOONG hesitation, it looks like something might finally start
happening at our place, drawing on our experience with knowledge
representation schemas like the KL-ONE family (basically, using
REL and REV 'Includes' links as is-a and part-of specifications...).

Thank you!

pAolo

ps.: our COMPLIMENTS to all the www-related developers!
--
paolo petta                                            +43-1-5336112(Tel)
Austrian Research Inst. for Artificial Intelligence    +43-1-5320652(Fax)
Schottengasse 3, A-1010 Vienna, Austria, Europe     paolo@ai.univie.ac.at 

From marca@wintermute.ncsa.uiuc.edu  Sat Mar 13 05:12:41 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25234; Sat, 13 Mar 93 05:12:41 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13249; Sat, 13 Mar 1993 05:30:26 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09722
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 12 Mar 93 22:30:23 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14200; Fri, 12 Mar 93 22:32:12 -0800
Date: Fri, 12 Mar 93 22:32:12 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303130632.AA14200@wintermute.ncsa.uiuc.edu>
To: timbl@dxcern.cern.ch (Tim Berners-Lee)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
In-Reply-To: <9303022225.AA07248@dxcern.cern.ch>
References: <9303022225.AA07248@dxcern.cern.ch>
X-Md4-Signature: bfd43bcf4a749aaee7c69eeb202da3de

Back to the inlined image thread again -- I'm getting close to
releasing Mosaic v0.10, which will support inlined GIF and XBM
images/bitmaps, as mentioned previously.  So I just reread the
exchanges we had a while back, and have a few comments...

Tim Berners-Lee writes:
> Let the IMG tag be INCLUDE and let it refer to an arbitrary document
> type.  Or EMBED if INCLUDE sounds like a cpp include which people
> will expect to provide SGML source code to be parsed inline -- not
> what was intended.

We're not prepared to support INCLUDE/EMBED at this point; it raises a
number of nasty issues that are quite separate from the idea of
inlined images.  For example, what happens if one EMBEDS a document
that in turn EMBEDS the first document?  Oops.  Aside from this, I'm
not sure I see the point in allowing arbitrary EMBED's for things like
chunks of texts: this is a hypertext system, after all, and it ought
to be possible to get the functional effect of an EMBED by using an
ordinary link.  Right?

So, we're probably going to go with <IMG SRC="url"> (not ICON, since
not all inlined images can be meaningfully called icons).  For the
time being, inlined images won't be explicitly content-type'd; down
the road, we plan to support that (along with the general adaptation
of MIME).  Actually, the image reading routines we're currently using
figure out the image format on the fly, so the filename extension
won't even be significant.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Sat Mar 13 07:54:40 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26119; Sat, 13 Mar 93 07:54:40 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24832; Sat, 13 Mar 1993 08:12:24 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA17770
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 13 Mar 93 01:12:22 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA15020; Sat, 13 Mar 93 01:14:01 -0800
Date: Sat, 13 Mar 93 01:14:01 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303130914.AA15020@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: binary file access via Mosaic
X-Md4-Signature: 2c3a6314939fd5cff58d08974b594917

A frequent comment of Mosaic users is that binary files of a type that
Mosaic doesn't recognize (i.e., with a filename extension that Mosaic
doesn't recognize) aren't just saved to disk rather than uselessly
displayed as text.  The following document (online as
http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/file-typing-issues.html)
details the issues involved and explains the solution developed for
the uncoming 0.10 release; I'd appreciate any comments or feedback.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


NCSA Mosaic File Typing Issues
******************************

Motivation
==========

Quite independent from their sources, files have types. A given file can
be plaintext, HTML, GIF, JPEG, AIFF, MPEG, PostScript, you name it.
(MIME provides a way to type data elements within a file, but the file
itself still has a type: MIME.)

In an ideal world, the type of each file would be well-defined metadata
always accessible to an information browsing client prior to the act of
accessing the file. This is true on the Macintosh, but not on most other
systems, and certainly not on the Unix-dominated Internet. Bummer.

Therefore, in an imperfect world, Mosaic uses the common (but not
mandated and not standardized) convention of examining a file's
extension to attempt to determine its type. PostScript files are assumed
to be suffixed '.ps', GIF files '.gif', etc. In this way, Mosaic can
correctly determine file types for the majority of the data files available
on the Internet.

When a file type cannot be thus derived, Mosaic makes a guess. Files
coming over a HTTP server are assumed to be HTML; files coming
from any other source (except Gopher; see below) are assumed to be
plaintext.

This, of course, causes a problem. What happens when a file is assumed
to be viewable text, but it really isn't? Well, Mosaic attempts to display
it as text. Boom. Serious badness.

Solution
========

In Mosaic version 0.10 (and later), there is a solution. The user is
allowed to select, on the fly, whether untyped files (i.e., files with no
recognizable suffix) are to be assumed to be viewable (text) or not
viewable (data). If the former, such files will be displayed; if the latter,
such files will be dumped to a local disk and the user will be notified
appropriately.

When files of unrecognized types are automatically dumped to disk as
binary data in this manner, Mosaic is said to be in "binary transfer
mode".

A toggle button in the Options menu allows you to turn binary transfer
mode on and off, on the fly, at the per-window level. It is implicitly
assumed that binary transfer mode will generally be off, since many
common documents (for example, the results of a WAIS query, with a
URL something like '.../my-database?query') need to be assumed to be
text for the usual Mosaic interfaces to function. However, when you're
in a situation, e.g. while browsing an anonymous FTP site, where you
know you want to pull over 'file.xyz' and you know that file 'file.xyz' is
really binary data and shouldn't be displayed as text, then you turn on
binary transfer mode, access the file, grab the file from the local disk
(where it is dumped automatically by Mosaic), and switch back out of
binary transfer mode.

Note that binary transfer mode does not impact other Mosaic
functionality; notably:

 o Automatic and transparent uncompression of compressed (.Z)
   and gzip'd (.z) files still occurs with untyped files.
 o Binary (data) files with recognized extensions (e.g., '.gif' and
   '.jpeg') are still passed off to the appropriate external viewers.
   (Note that a new feature in 0.10 is that if the name of an data
   type's external viewer is defined via the X resource mechanism
   to be "dump", then data files in that format will be dumped to
   disk as if they were untyped files being retrieved in binary
   transfer mode.)

Notes
=====

Note that it is practically impossible to heuristically determine whether
an untyped file is viewable or not viewable as text for the simple reason
that 8-bit text is now commonplace.

Gopher has its own typing system (and not a very good one, at that). As
such, the rules don't apply. Mosaic tries to do the right thing with
various types of Gopher files, but using a different scheme, based on the
Gopher-defined file types.

marca@ncsa.uiuc.edu


From guido@cwi.nl  Sat Mar 13 11:38:41 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26780; Sat, 13 Mar 93 11:38:41 MET
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13137; Sat, 13 Mar 1993 11:56:27 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA27572 (5.65b/3.8/CWI-Amsterdam); Sat, 13 Mar 1993 11:56:27 +0100
Received: by voorn.cwi.nl with SMTP
	id AA05476 (5.65b/3.8/CWI-Amsterdam); Sat, 13 Mar 1993 11:56:26 +0100
Message-Id: <9303131056.AA05476=guido@voorn.cwi.nl>
Subject: Re: proposed new tag: IMG 
To: www-talk@nxoc01.cern.ch
Date: Sat, 13 Mar 1993 11:56:26 +0100
From: Guido van Rossum <Guido.van.Rossum@cwi.nl>

>We're not prepared to support INCLUDE/EMBED at this point; it raises a
>number of nasty issues that are quite separate from the idea of
>inlined images.  For example, what happens if one EMBEDS a document
>that in turn EMBEDS the first document?  Oops.

I would consider this an error of the author that needs to be detected
to protect the browser.  It only requires maintaining a stack of
nested EMBEDS.

>Aside from this, I'm
>not sure I see the point in allowing arbitrary EMBED's for things like
>chunks of texts: this is a hypertext system, after all, and it ought
>to be possible to get the functional effect of an EMBED by using an
>ordinary link.  Right?

Some other hypertext systems do this, in a sense: in Guide there are,
apart from real GOTO stype hyperlinks, also "folds" (I think they are
called) which are sort of embedded documents that you can open and
close.  The advantage in certain situations is that opening a fold
retains more context than following a link.  It feels like using an
outline processor, which is rather pleasant (for certain kinds of
information).

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

PS. I keep hearing about supporting MIME.  Is there consensus on the
form this should take?  (I remeber getting in an unpleasant fight with
Dan Connolly about this once -- BTW is he still with us?)

From marca@wintermute.ncsa.uiuc.edu  Sat Mar 13 11:58:25 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26822; Sat, 13 Mar 93 11:58:25 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14123; Sat, 13 Mar 1993 12:16:10 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24190
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 13 Mar 93 05:16:09 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA16417; Sat, 13 Mar 93 05:18:03 -0800
Date: Sat, 13 Mar 93 05:18:03 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303131318.AA16417@wintermute.ncsa.uiuc.edu>
To: Guido.van.Rossum@cwi.nl
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG 
In-Reply-To: <9303131054.AA05457=guido@voorn.cwi.nl>
References: <9303130632.AA14200@wintermute.ncsa.uiuc.edu>
	<9303131054.AA05457=guido@voorn.cwi.nl>
X-Md4-Signature: 0adad6d1eb30b6578b70c6dff2338d07

Guido.van.Rossum@cwi.nl writes:
> >We're not prepared to support INCLUDE/EMBED at this point; it raises a
> >number of nasty issues that are quite separate from the idea of
> >inlined images.  For example, what happens if one EMBEDS a document
> >that in turn EMBEDS the first document?  Oops.
> 
> I would consider this an error of the author that needs to be detected
> to protect the browser.  It only requires maintaining a stack of
> nested EMBEDS.

Still, I'd argue the principle is still there.  If a document has to
be pieced together on the fly, it could get arbitrarily complex, and
even if that were limited, we'd certainly start experiencing major
hits on performance for documents structured in this way.  This
essentially throws the single-hop principle of WWW out the door (well,
IMG does that too, but for a very specific reason and in a very
limited sense) --- are we sure we want to do that?

> Some other hypertext systems do this, in a sense: in Guide there are,
> apart from real GOTO stype hyperlinks, also "folds" (I think they are
> called) which are sort of embedded documents that you can open and
> close.  The advantage in certain situations is that opening a fold
> retains more context than following a link.  It feels like using an
> outline processor, which is rather pleasant (for certain kinds of
> information).

Would be nice to be able to do this, but it would essentially be just
a fancy multi-windowed version of the current distributed hypertext
model, right?  Instead of jumping to whole new documents, the act of
triggering a link would open up more information in the current
context.  That doesn't require EMBED functionality...

> PS. I keep hearing about supporting MIME.  Is there consensus on the
> form this should take?  (I remeber getting in an unpleasant fight with
> Dan Connolly about this once -- BTW is he still with us?)

Mosaic currently recognizes documents suffixed .mime and throws 'em
off to metamail.  Some support for MIME is in Tim's new WWW library
(although I haven't looked very closely at it).  Other than that, I'm
not sure what the consensus exactly is.  And Dano's history, I do
believe...

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From montulli@stat1.cc.ukans.edu  Sat Mar 13 22:06:07 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00402; Sat, 13 Mar 93 22:06:07 MET
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05952; Sat, 13 Mar 1993 22:23:52 +0100
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA15765; Sat, 13 Mar 1993 15:18:26 -0600
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9303132118.AA15765@stat1.cc.ukans.edu>
Subject: Support for CSO and gopher type 2
To: www-talk@nxoc01.cern.ch
Date: Sat, 13 Mar 93 15:18:26 CST
X-Mailer: ELM [version 2.3 PL2]

As many of you may know, Gopher file type 2 is a CSO nameserver 
interface.  All of the WWW clients that I have seen do not support
this file type.  Why not?

A page similar to the Gopher index page could be displayed,
with some additional instructions on how to construct a query.

For instance:  To search on all fields simply say "query STRING"
	       To search on a particular field like a name field
	       say "query name=STRING"

The client simply has to send an extra "\nquit\n" to complete the
query, or cut off the connection when the string "200:Ok" or
"501:No matches to your query." is sent by the server. 

Considering the fact that there are over 100 CSO servers available
for these queries, doesn't it seem necessary to support them?

Maybe a new url type is in order:
	"cso://cso.univ.edu:105/"

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************


From marca@wintermute.ncsa.uiuc.edu  Sun Mar 14 09:42:00 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03564; Sun, 14 Mar 93 09:42:00 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00513; Sun, 14 Mar 1993 09:59:48 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA01499
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Sun, 14 Mar 93 02:58:54 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:rkatz@darpa.mil id AA22479; Sun, 14 Mar 93 03:00:45 -0800
Date: Sun, 14 Mar 93 03:00:45 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303141100.AA22479@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: NCSA Mosaic for X 0.10 released
X-Md4-Signature: 0db169a5824c601861f4fd1ef360d334

Beta version 0.10 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is hereby released:

file://ftp.ncsa.uiuc.edu/Web/xmosaic/xmosaic-0.10.tar.Z
                         .../xmosaic/binaries-0.10/xmosaic-sun.Z
                         .../xmosaic/binaries-0.10/xmosaic-sgi.Z
                         .../xmosaic/binaries-0.10/xmosaic-ibm.Z
                         .../xmosaic/binaries-0.10/xmosaic-dec.Z

This release of NCSA Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).
  DEC Ultrix.

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working
binaries, or development systems, are welcome.)  Documentation is
available online.

Changes since 0.9 include:

 o Support for <IMG> tag: inlined images in HTML documents.
    o Handles X bitmap and GIF formats so far.
    o New resource, colorsPerInlinedImage, can be used to restrict
      color use of inlined images -- default is 50.
    o Image files can be located anywhere on the net (pointed to by
      URL); image data is cached in memory for fast display and
      reuse.
    o Example of inlined bitmap: 
      <IMG SRC="file://foobar.com/foobar.xbm">
    o Example of inlined image serving as anchor: 
      <A HREF="http://foobar.com/ref.html"> 
      <IMG SRC="file://foobar.com/blagh.gif"> </A>
 o Better support for acting as binary file retrieval client.
    o Each window can either be in binary transfer mode or not;
      resource binaryTransferMode controls startup value (default
      is 'False', and you probably don't want to change this). A
      toggle button in the Options menu allows changing on the fly.
    o If a window is not in binary trasfer mode, data files with
      unrecognized types will be displayed in the window as either
      plain text or HTML (depending on the server type), as before.
    o If a window is in binary transfer mode, data files with
      unrecognized types will be dumped to a local file after being
      transferred over as binary data.
    o Regardless of whether a window is in binary transfer mode or
      not, files with recognizes types (images, sound, etc.) will be
      handled as usual, and uncompression will be transparent as
      usual.
    o The whole point of all this is to allow the user to select on the
      fly how a given file of an unrecognized type is to be handled.
    o Because files are currently typed by filename extension,
      binary transfer mode should generally be kept off, otherwise
      it will screw up things like WAIS searches pretty badly. Also,
      since Gopher does things differently from everyone else,
      things are different there too.
    o Setting one of the multimedia resources to the text string
      "dump" will cause files of that type to be dumped to local
      disk as though in binary transfer mode.
    o See http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/file-typing-issues.html 
      for a more thorough discussion of these issues.
 o Audio annotations for Sun's with /usr/demo/SOUND/record (or
   something similar) are now enabled. Resources
   recordCommandLocation and recordCommand are used to specify the
   command used to record sound; theoretically, this approach can be
   used on any platform with appropriate hardware and software,
   although SGI Indigo & Sun Sparcstation are the only two that I know
   of.
 o Search capability within documents: enter search term, scrollbar
   jumps to match and match is highlighted; repeat as desired.
 o Enhanced support for various Gopher types, including binary files
   and CSO phonebooks (sorry, phonebooks aren't supported yet, but at
   least now an error message shows up).
 o Spaces converted to +'s in keyword queries now.
 o Scrollbar arrows now increment a reasonable amount when viewing
   large documents.
 o Anonymous FTP password is now always user@host.domain,
   enabling access to every strange FTP server out there that I know of.
 o Pattern-matching to determine file type based on file name now uses
   caseless string compare.
 o Better default visited anchor color for non-SGI color displays.
 o Messages from libwww now show up in pop-up dialogs like they
   should.
 o Telnet never gets asked to use unrecognized -l flag.
 o Tar files are now always retrieved to local disk (and not displayed).
 o Replacement (and better) Archie interface.
 o Mail Developers window is cleared on each use.
 o New resource trackVisitedAnchors; can be used to turn off tracking
   of visited anchors altogether.
 o Better transparent uncompression support:
    o Gzipped (.z) files are now recognized and uncompressed on
      the fly (as well as .Z files, as before).
    o New resources uncompressCommand (default 'uncompress')
      and gunzipCommand (default 'gunzip').
 o As usual, little bugfixes and cleanups.

We're targeting a 1.0 release for the beginning of April, so quick
feedback and bug reports will be GREATLY appreciated.

Finally, thanks *again* to everyone who's been contributing comments
and bug reports -- keep 'em coming!

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Sun Mar 14 10:04:09 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03630; Sun, 14 Mar 93 10:04:09 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02373; Sun, 14 Mar 1993 10:21:57 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02730
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 14 Mar 93 03:21:52 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA22592; Sun, 14 Mar 93 03:20:25 -0800
Date: Sun, 14 Mar 93 03:20:25 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303141120.AA22592@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: inlined image demo/explanation
X-Md4-Signature: 10f571f810bd847227b931aead9293e6

A demo and explanation of the inlined image functionality in Mosaic
0.10 is at
http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/inlined-images.html.

Cheers,
Marc

--



From tom%begbick.law.cornell.edu@router.mail.cornell.edu  Sun Mar 14 13:06:09 1993
Return-Path: <tom%begbick.law.cornell.edu@router.mail.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03926; Sun, 14 Mar 93 13:06:09 MET
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18285; Sun, 14 Mar 1993 13:23:56 +0100
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160636(5)>; Sun, 14 Mar 1993 07:23:53 -0500
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA03131; Sun, 14 Mar 93 07:17:11 EST
Date: Sun, 14 Mar 1993 07:17:11 -0500
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9303141217.AA03131@begbick.law.cornell.edu.law.cornell.edu>
To: montulli@stat1.cc.ukans.edu
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Lou Montulli's message of Sat, 13 Mar 93 15:18:26 CST <9303132118.AA15765@stat1.cc.ukans.edu>
Subject: Support for CSO and gopher type 2

Lou:

The as-yet-mysterious Cello MS-Windows client supports CSO queries
as a gopher://  subscheme.  At the moment, the functionality is
limited -- you can only do searches on the name.  I will eventually
build in a method of launching a 'fields' query and retrieving the
results to a form for the user to fill in, much as the character-based
DOS gopher client and TurboGopher clients do.  But at the moment 
I'm cobbling up a bunch of things for a demo at the end of the month, 
and want to leave this particular frill fairly simple for now.

Regards,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+















From murphy@dccs.upenn.edu  Mon Mar 15 18:14:14 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17296; Mon, 15 Mar 93 18:14:14 MET
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02588; Mon, 15 Mar 1993 18:32:04 +0100
Received: from NOC2.DCCS.UPENN.EDU by mcsun.EU.net with SMTP
	id AA10016 (5.65b/CWI-2.209); Mon, 15 Mar 1993 18:21:45 +0100
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA11932; Mon, 15 Mar 93 12:19:41 -0500
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA26665; Mon, 15 Mar 93 12:19:40 -0500
Date: Mon, 15 Mar 93 12:19:40 -0500
From: murphy@dccs.upenn.edu
Posted-Date: Mon, 15 Mar 93 12:19:40 -0500
Message-Id: <9303151719.AA26665@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch
Subject: FYI - John Franks: "This is a golden oportunity for the WWW people."


Apparently, he is not a fan of gopher+ 

--lam


Path: netnews.upenn.edu!dsinc!spool.mu.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!math.nwu.edu!john
From: john@math.nwu.edu (John Franks)
Newsgroups: comp.infosystems.gopher
Subject: Re: Gopher License - Actual Data... I'm very disappointed.
Keywords: gopher commercial server license departmental budget
Message-ID: <1993Mar11.165207.24573@news.acns.nwu.edu>
Date: 11 Mar 93 16:52:07 GMT
References: <1993Mar11.015639.16976@spdcc.com>
Sender: usenet@news.acns.nwu.edu (Usenet on news.acns)
Reply-To: john@math.nwu.edu
Organization: Dept of Math, Northwestern Univ
Lines: 49
Nntp-Posting-Host: hopf.math.nwu.edu

In article <1993Mar11.015639.16976@spdcc.com>, raisch@spdcc.com (Rob Raisch) writes:
> 
> Mark, Paul Yen, Fahad, et. al., congratulations.  You  may have succeeded
> in accomplishing something which it takes a large corporation years of 
> practice and many hundreds of thousands of dollars to do:
> 
> 	You've killed the product before it ever leaves your door.
> 
> --Paul Lindner writes:
> --	I know that the UofMN will take a moderate stance on these matters.
> --	You're not going to see another IPX etal here.
> --
> --	Greed would kill gopher, believe me..
> 

There is a good chance that greed has killed gopher.  Certainly, IMHO,
this puts an end to gopher+.  Most likely there will be other servers
created which are public domain or with GNU-like licenses, but they
won't be gopher+ compatible.  If such a server were available now, I
guess I would switch to it.

Also Univ of Minn will cease (or maybe already has) to be the central
authority of gopherdom.  I'm afraid we will have incompatible versions
of servers.  It really is extremely important now to get an rfc, to
try to nail down the minimal protocol.

I really do have a great sense of sadness about this.  There are a number
of examples of extremely successful "pro bono publico" software.  One
thinks of perl, gcc, gnu emacs and the NCSA offerings.  I had hoped that
gopher would be another and it is disappointing to see greed wipe out
that hope.

I had hoped that gopher would become the main vehicle for electronic
scholarly journals.  It would be a great boon to academia if all
scholarly journals could be accessed with the same protocols so a
student or researcher would only need to learn to use one type of
client to access the "electronic library" of the future.  Today it
seems rather unlikely that this library will use a gopher protocol.
Scholarly journals certainly can't afford to pay 7.5% of their gross
receipts to the Minnesota gopher team, not to mention the $5K
annually.  Most likely we will end up with several incompatible
proprietary schemes for accessing electronic journals.  Or maybe WWW
will start to take off.  Electronic publishers are very interested in
SGML anyway.  This is a golden oportunity for the WWW people.

-- 

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

From timbl@www3.cern.ch  Mon Mar 15 18:17:30 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17347; Mon, 15 Mar 93 18:17:30 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02995; Mon, 15 Mar 1993 18:35:21 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00815; Mon, 15 Mar 93 18:34:54 +0100
Date: Mon, 15 Mar 93 18:34:54 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303151734.AA00815@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: 2.0 alpha testers?
Reply-To: timbl@nxoc01.cern.ch

I would like brave alpha testers of the 2.0 www code, in particular  
of the multimedia bits.

The 2.0 libwww, line mode client and the server are on
ftp://info.cern.ch/pub/www/src now.   The library will handle  
multiple types of the same document when resolving links to
imaginary files called xxx.multi -- it will return xxx.ps or xxx.txt  
or xxx.gif depending on what the client can handle.

The bug in the server release that it didn't contain and code is  
fixed!

The tables of suffixes are in the c code (*Init.c) for now.
Note they can be quite different on client and server. See  
HTFormat.h, HTFile.h for routines to add configuation info
from your specific app code.

The current tables excpet ghostview and xv to be available
if DISPLAY is defined (for X) or the usual plethora of
image-handling apps on the NeXT [RIP].

Servers:  Note the rule file must now translate from a string
starting without protocol or nodename (as transferred in HTTP)
into a URI -- that is, you have to put file: onto the front
of all the filenames like:

#	HTTPD config file
#
map 	/	     /hypertext/WWW/LineMode/Defaults/cern.html
map 	/hypertext/* file://www3/Net/dxcern/userd/timbl/hypertext/*
pass	file://www3/Net/dxcern/userd/timbl/hypertext/*
fail 	*

You may see the implicatioon of this that you can map into
other spaces, and yes, that is right -- like you can map bits of
your http space into news of ftp or gopher or whatever. In other
words, the server works as a gateway to everything the client can
handle.  (Note gatewaying news: is not strictly legal I think)

This means you turn virtually anything into HTML.  But I haven't got
www command line options fixed up yet.

Directory listings are not sorted yet, but they do get README
put in (not for FTP directories, but for local ones).  As the
server and client code are the same, you can use a www client as
a directory browser.

Please let me know if you take this code and try it.  The important
thing is for client developers to check out the interfaces.

Tim


From timbl@www3.cern.ch  Tue Mar 16 16:47:33 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02727; Tue, 16 Mar 93 16:47:33 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19962; Tue, 16 Mar 1993 17:05:25 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01772; Tue, 16 Mar 93 17:04:57 +0100
Date: Tue, 16 Mar 93 17:04:57 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303161604.AA01772@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Upgraded  2.0 sources.  Please upgrade servers.
Reply-To: timbl@nxoc01.cern.ch


There is some new HTTP test data for 2.0 clients on
http://info.cern.ch/hypertext/WWW/Test/Overview.html

I have upgraded the sourecs on ftp://info.cern.ch/pub/www/src
to fix a few bugs.  The daemon now can take a directory name to  
export on the command line to save having to write a rule file.

There is a back-compatibility problem with HTTP, in that some old  
servers are messed up by the new protocol.  I think this is pre 0.9a  
servers, which do not ignore the third word on the command line.
Servers based on csh etc should be OK, as is the 0.9b server.
This is unfortunate, and means we have to do round upgrading servers  
before upgrading clients.  I would recommend that servers be updated
as soon as possible.  The new httpd is running on info.cern.ch and
doesn't seem to have upset anyone yet after the first 40k  
transactions.  I would now class the 2.0 server code as beta.
The client I will keep as alpha (a) to prevent people picking it
up and getting snagged on old servers, and (b) because there is
more functionality to go in. (WAIS etc)  However, is seems to work  
well too, and so feel free to pick it up to test new servers.

I would like to keep a list of servers which have upgraded, so
please mail me if you do.

When you do upgtae, the new binary is quite compatible with the old  
binary except that the rule file must map requests onto sull URLs,  
including the file: prefix. The online doc has been modified.


From timbl@www3.cern.ch  Wed Mar 17 09:34:39 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13479; Wed, 17 Mar 93 09:34:39 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09496; Wed, 17 Mar 1993 09:52:32 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00440; Wed, 17 Mar 93 09:51:57 +0100
Date: Wed, 17 Mar 93 09:51:57 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303170851.AA00440@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: WWWLibrary_2.02-beta : Incompatibility fix;  Literate programming
Reply-To: timbl@nxoc01.cern.ch



The 2.02 version of the library is marked "beta" to indicate that it  
ought to work reliably and needs testing.   Compatible line-mode  
browser and daemon are available too as before. Sources are in
ftp://info.cern.ch/pub/www/src as usual.

Changes are
-----------

- Fix so that the HTTP client will fall back to old HTTP with servers
 which don't like the HTTP extenstions.  The incompatibility problem
 of yeste
 

- A format called text/x-c which can be generated from hypertext.

	www -to text/x-c xxxx.html > xxxx.h
	
  will produce a formatted .h file with everything enclosed in
  comments except for preformtted sections, which are treated as
  code.  This allows files like
   
http://info.cern.ch/hypertext/WWW/Library/Implementation/HTFormat.html 

  to be self-documenting source files.
  

  

 Internal documentation.
 ----------------------
 

I have made a token bit of documentation on the library to explian
a few features using the above technique. I used
http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/text2html.sed
to generate the html froim the .h files in the first place before  
marking it up. Feedback on forms and content (but not extent which I  
know is not much!) is welcome.

Tim BL


__________________________________________________________
Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web team leader           (NeXTMail is ok)	
CERN, CN Division                     Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




  

From guido@cwi.nl  Wed Mar 17 12:15:35 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14896; Wed, 17 Mar 93 12:15:35 MET
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03437; Wed, 17 Mar 1993 12:33:28 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA07859 (5.65b/3.8/CWI-Amsterdam); Wed, 17 Mar 1993 12:33:27 +0100
Received: by voorn.cwi.nl with SMTP
	id AA25810 (5.65b/3.8/CWI-Amsterdam); Wed, 17 Mar 1993 12:33:26 +0100
Message-Id: <9303171133.AA25810=guido@voorn.cwi.nl>
To: www-talk@nxoc01.cern.ch
Subject: Delivery errors
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Wed, 17 Mar 1993 12:33:25 +0100
Sender: Guido.van.Rossum@cwi.nl

One of the more annoying aspects of being a member of the www
community is the flood of mail you get whenever you send something to
the list.  And I don't mean enthousiastic (or even less positive)
reactions: I'm referring to the messages from mailer daemons all over
the world that tell you a certain address is unreachable.  Hey, I
don't maintain the list, why should I be bothered with these errors!?

I am maintaining a mailing list myself and I know that it is possible
to set up things so this does not generally happen.  Just a few more
aliases and an extra header line added to each outgoing message should
do the trick.  (Giving detailed instructions makes no sense since
different distribution systems do it differently.)  Please, Tim, I
know you're very busy and your work is much appreciated, but would you
please try to (get somebody to?) fix the mailing list setup?

TIA,

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From timbl@www3.cern.ch  Wed Mar 17 18:06:00 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19732; Wed, 17 Mar 93 18:06:00 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28151; Wed, 17 Mar 1993 18:23:55 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00910; Wed, 17 Mar 93 18:23:20 +0100
Date: Wed, 17 Mar 93 18:23:20 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303171723.AA00910@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Multimedia Server binaries available.
Reply-To: timbl@nxoc01.cern.ch



Binaries of the 2.02 multimedia server are available by anoymous ftp  
from info.cern.ch for hp, sgi, next, sun,decstation:

/pub/www/bin/decstation/httpd_2.02-beta*
/pub/www/bin/decstation/www_2.0-alpha*
/pub/www/bin/next/httpd_2.0-alpha*
/pub/www/bin/next/www_2.0-alpha*
/pub/www/bin/sgi/httpd_2.02-beta*
/pub/www/bin/sgi/www_2.0-alpha*
/pub/www/bin/snake/httpd_2.02-beta*
/pub/www/bin/snake/www_2.0-alpha*
/pub/www/bin/sun4/httpd_2.02-beta*
/pub/www/bin/sun4/www_2.0-alpha*

I repeat the earlier comment that the compatibilty problem has been  
fixed.

The sources have been improved (now 2.02), and the README.

The server is quite compaible wit the old server except the
rule file format which must map requests to a full URI.

Send me any bugs ASAP -- thanks for those who already have, they
should be taken care of in the above.

Tim Berners-Lee
WWW CERN


From timbl@www3.cern.ch  Wed Mar 17 18:09:55 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19818; Wed, 17 Mar 93 18:09:55 MET
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28538; Wed, 17 Mar 1993 18:27:50 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00915; Wed, 17 Mar 93 18:27:12 +0100
Date: Wed, 17 Mar 93 18:27:12 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9303171727.AA00915@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Sorry, can't convert format
Cc: stellr@smyrna.cc.vt.edu (Ray Stell), www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


| 

| Date: Tue, 16 Mar 93 23:57:13 -0800
| From: marca@ncsa.uiuc.edu (Marc Andreessen)
| 

| Ray Stell writes:
| > Using 0.9 to the following:
| > 

| >        
http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/txt2html.sed
| > 

| > returns the following:
| > 

| >       HTFormat: Sorry, can't convert from application/binary to  
www/present.
| > 

| > is it something I said?

Which, translated, means:  "I'm sorry, the document as far as I can
tell is binary and I don't know how to present that to you as
you haven't told me you can handle binary."

That is because I haven't reagistered .sed as text.  I just might
make the default text rather than binary. Anyone got any smart
ideas about how to distinguish (fast?).  In the mean time
I'll register a new suffix.



| That is DEFINITELY not a Mosaic bug.  Looks like the server is  
having
| a little trouble (the client/server architecture of WWW is such  
that
| error messages like this are returned from the server to the client  
as
| if they were the actual requested document -- the client never  
knows
| the difference [and thus doesn't *need* to know the difference,  
which
| keeps things simple]).


This simple but sometimes confusing system is richer with 2.0.
The response can be of type OK, error, forward, etc.  The error
message causes a different sort of object to be loaded.
[[Actually each client can do something different with the  
HTLoadError routine]]. 


Tim BL

From marca@wintermute.ncsa.uiuc.edu  Thu Mar 18 06:09:16 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00846; Thu, 18 Mar 93 06:09:16 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03250; Thu, 18 Mar 1993 06:27:39 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02559
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Wed, 17 Mar 93 23:27:20 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:jcma@reagan.ai.mit.edu id AA06328; Wed, 17 Mar 93 23:29:12 -0800
Date: Wed, 17 Mar 93 23:29:12 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303180729.AA06328@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: NCSA Mosaic for X 0.11 (maintenance release)
X-Md4-Signature: b63d3931cb5bafe0847addd0acbdf232

NCSA Mosaic for X 0.11, a maintenance release with two small but
crucial bugfixes, is now in the usual place...

        file://ftp.ncsa.uiuc.edu/Web/xmosaic

Changes are:

 o Bug fix for non-SGI X servers: bitmaps now show up with
   correct (normal foreground and background) colors.
 o Bug fix for Ultrix: no more meaningless coredumps when
   closing windows.

0.12 will come in 2-3 weeks with another batch of miscellaneous
bugfixes, followed by 1.0 shortly thereafter.  As usual, thanks in
advance for feedback and comments!

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From joe@athena.mit.edu  Fri Mar 19 03:23:16 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14358; Fri, 19 Mar 93 03:23:16 MET
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10664; Fri, 19 Mar 1993 03:41:40 +0100
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA11386; Thu, 18 Mar 93 21:29:28 EST
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA29181; Thu, 18 Mar 93 21:29:27 -0500
Date: Thu, 18 Mar 93 21:29:27 -0500
Message-Id: <9303190229.AA29181@theodore-sturgeon>
To: tk-www@athena.mit.edu, www-talk@nxoc01.cern.ch,
        www-announce@nxoc01.cern.ch
Cc: tcl-archive@harbor.ecn.purdue.edu
Subject: Announcing tkWWW Version 0.6 alpha


tkWWW Version 0.6 alpha (joe@athena.mit.edu)
--------------------------------------------
WHAT IS THIS?

-------------
World Wide Web (WWW) is a hypertext project which seeks to build a
world wide network of hypertext links.  There are several different
browsers for this system including a simple tty interface.  For a 
demo of the terminal browsers for WWW, telnet to the following sites:

 telnet info.cern.ch or telnet 128.141.201.74 (SWISS)
 telnet eies2.njit.edu or telnet 128.235.1.43 (USA [NJ])
 telnet vms.huji.ac.il or telnet 128.139.4.3  (ISRAEL)
 telnet info.funet.fi or telnet 128.214.6.100 (FINLAND)

 and login as "www"

Tk is an interpreted toolkit which allows one to build X11 applications
quickly and easily.

tkWWW is a Tk interface to (WWW).

Since the entire user interface is written in an interpreted language,
it is very easy to make modifications and extensions to the system.
Right now, work is under way to convert tkWWW to a full fledged HTML
editor.

What has changed since 0.5?
---------------------------
works with vanilla wish
User configurable menus
Help system (under construction)
Personal annotation with format compatible with xmosaic
Menu option to mail hypertext pages to other users
Menu option to print hypertext pages
Now recognizes the environment variable WWW_HOME
Goes to internal links
The beginnings of a HTML editor 
Ability to change fonts (under edit menu)

Where is this?
--------------
tkWWW 0.6 can be anon ftp'ed from
   export.lcs.mit.edu:/contrib/tkWWW-0.6.tar.Z
   harbor.ecn.purdue.edu:/tcl/extensions/tkWWW-0.6.tar.Z
   info.cern.ch:/pub/WWW/src/tkWWW-0.6.tar.Z

Mailing list
------------
There is a mailing list devoted to discussions about tkWWW at 
 
   tk-www@athena.mit.edu

To get on this list, send e-mail to

   tk-www-request@athena.mit.edu

To Install
----------

1. Edit the file "tkWWW.imake" to set system defaults
2. Type "make"
3. Type "make install"





From mcharity@hq.lcs.mit.edu  Fri Mar 19 15:53:39 1993
Return-Path: <mcharity@hq.lcs.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21384; Fri, 19 Mar 93 15:53:39 MET
Received: from HQ.LCS.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03422; Fri, 19 Mar 1993 16:12:04 +0100
Received: by hq.LCS.MIT.EDU 
	id AA20922; Fri, 19 Mar 93 10:12:27 EST
Date: Fri, 19 Mar 93 10:12:27 EST
From: mcharity@hq.lcs.mit.edu (Mitchell N Charity)
Message-Id: <9303191512.AA20922@hq.LCS.MIT.EDU>
To: www-talk@nxoc01.cern.ch
Subject: NCSA X Mosaic and X server crashes
Reply-To: mcharity@lcs.mit.edu
X-Phone: NE43-512:253-6023  home(617)497-1506

Being delighted by xmosaic, I have been doing lots of demos.
Unfortunately, X servers are crashing.

Using the xmosaic-0.9 and -0.10 distribution binaries,
I have encountered crashes on a variety of servers:
   MIT X11r5 on DEC with DEC xmosaic
   MIT X11r4 on Vax with AIX xmosaic
   MacX      on Mac with Sun xmosaic

But, is beta code, right?
Well, apparently mine is the only bug report on this.
Thus the NCSA folk responded that it was the "fault" of the servers.

So, if you have a server crash, I suggest you email marca@ncsa.uiuc.edu,
so the problem's magnitude can be guaged.

Mitchell

From germuska@antioch.acns.nwu.edu  Fri Mar 19 17:49:59 1993
Return-Path: <germuska@antioch.acns.nwu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23850; Fri, 19 Mar 93 17:49:59 MET
Received: from antioch.acns.nwu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19419; Fri, 19 Mar 1993 18:08:24 +0100
Received: by antioch.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA05692; Fri, 19 Mar 93 11:05:44 CST
From: germuska@antioch.acns.nwu.edu (Joe Germuska)
Message-Id: <9303191705.AA05692@antioch.acns.nwu.edu>
Subject: problems building the httpd daemon
To: www-talk@nxoc01.cern.ch
Date: Fri, 19 Mar 1993 11:05:43 -0600 (CST)
Reply-To: j-germuska@nwu.edu (Joe Germuska)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1198      

I got the following files from the info.cern.ch archive:
WWWDaemon_0.9b.tar.Z and WWWLibrary_1.1a.tar.Z

After unpacking them, I looked for the BUILD script that was with the more
recently released beta versions (which I started with but scrapped after
encountering numerous errors and problems.)

So I made the library OK, although I gather that you shouldn't have to do
that -- isn't it the case that building the Daemon builds the library in
temporary space?  Anyway, I then proceeded to try make for the Daemon, and
get hung up in several places; some I could fix -- like it looks for
Makefile.include in the sun4 directory, where there is no such file...

Anyway, in going through these parts, I get the feeling that the rush to
provide lots of services to lots of people has left some things only half
done!  Has anyone else figured out all the things one has to change to
build the httpd daemon for a sun4?  Any assistance is greatly appreciated.

	Joe

-- 
joe germuska | j-germuska@nwu.edu | Network Response Center
ACNS-Distributed Systems Services, Northwestern University
"The only thing that speaks the truth is the eloquence of
passing time; the spoken word is a jacket too tight..."

From marca@wintermute.ncsa.uiuc.edu  Fri Mar 19 22:58:14 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28984; Fri, 19 Mar 93 22:58:14 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17634; Fri, 19 Mar 1993 23:16:40 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02085
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 19 Mar 93 16:16:37 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA07105; Fri, 19 Mar 93 16:18:42 -0600
Date: Fri, 19 Mar 93 16:18:42 -0600
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303192218.AA07105@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: NCSA X Mosaic and X server crashes
In-Reply-To: <9303191512.AA20922@hq.LCS.MIT.EDU>
References: <9303191512.AA20922@hq.LCS.MIT.EDU>
X-Md4-Signature: 230b5774d3d55705db1dcc977ae4442e

Mitchell N Charity writes:
> Being delighted by xmosaic, I have been doing lots of demos.
> Unfortunately, X servers are crashing.
> 
> Using the xmosaic-0.9 and -0.10 distribution binaries,
> I have encountered crashes on a variety of servers:
>    MIT X11r5 on DEC with DEC xmosaic
>    MIT X11r4 on Vax with AIX xmosaic
>    MacX      on Mac with Sun xmosaic
> 
> But, is beta code, right?
> Well, apparently mine is the only bug report on this.
> Thus the NCSA folk responded that it was the "fault" of the servers.
> 
> So, if you have a server crash, I suggest you email marca@ncsa.uiuc.edu,
> so the problem's magnitude can be guaged.
> 
> Mitchell

Let me address this is painfully honestly as I can.  As I explained to
Mr. Charity in private email, it is literally impossible for an X
client to *cause* an X server crash.  It is literally not possible.

What is happening to Mr. Charity, of course, is that the X client is
issuing some sequence of requests (Lord knows what sequence, since
he's sent me no information from which I can attempt to guess) that is
exposing bugs in the X servers he's using.

Let me repeat again: X clients cannot *cause* X server crashes, and
there is no way for an X client to know what particular sequence of
requests will expose a particular server bug, so it's not even
possible to prevent those bugs from being exposed in a particular
server by a particular client.  There is nothing the client can do to
prevent server crashes caused by server bugs -- nothing.

Thus, yes, indeed, Mr.  Charity's crashes are the "fault" of the
servers.  When I worked at a certain Large Workstation Maker with a
Three Word Name that shall remain unidentified, incoming bug reports
of the nature "client XYZ crashes the server" were routinely
classified AND FIXED as server bugs.  It is simply the way things are.
It is simply how X is designed, and implemented.

So no, don't send mail to me because your X server is crashing.  If
your email domain is 'lcs.mit.edu', as Mr. Charity's happens to be,
and you're using a stock MIT server, I suggest you walk down the hall
or across the quad and talk to the X server experts.  If your server
was supplied by your vendor, complain to your vendor.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From joe@athena.mit.edu  Sun Mar 21 05:01:14 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10531; Sun, 21 Mar 93 05:01:14 MET
Received: from ATHENA.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15986; Sun, 21 Mar 1993 05:19:43 +0100
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA17606; Sat, 20 Mar 93 23:19:41 EST
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA27327; Sat, 20 Mar 93 23:18:25 -0500
Date: Sat, 20 Mar 93 23:18:25 -0500
Message-Id: <9303210418.AA27327@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch
Subject: Documentation for libWWW version 2.0


Does anyone have documentation for libWWW version 2.0.  A brief
description of how the various parts of libWWW hang together would be
greatly appreciated.



From bloemer@tnt.uni-hannover.dbp.de  Mon Mar 22 13:41:27 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24058; Mon, 22 Mar 93 13:41:27 MET
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07862; Mon, 22 Mar 1993 13:59:55 +0100
Received: by ixgate.gmd.de id AA19844; Mon, 22 Mar 93 13:58:44 +0100
Date: 17 Mar 93 11:38 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: www-talk@nxoc01.cern.ch, timbl@www3.cern.ch
Message-Id: <RFC-822:>
Subject: Re: Upgraded  2.0 sources.  Please upgrade servers.

RFC-822-HEADERS:
Cc: bloemer

==================

> From timbl@www3.cern.ch Tue Mar 16 17:18:43 1993
> From: Tim Berners-Lee <timbl@www3.cern.ch>
> To: www-talk@nxoc01.cern.ch
> Subject: Upgraded  2.0 sources.  Please upgrade servers.
> ...
> There is a back-compatibility problem with HTTP, in that some old  
> servers are messed up by the new protocol.  I think this is pre 0.9a  
> servers, which do not ignore the third word on the command line.
> Servers based on csh etc should be OK, as is the 0.9b server.
> This is unfortunate, and means we have to do round upgrading servers  
> before upgrading clients.  I would recommend that servers be updated
> as soon as possible.  The new httpd is running on info.cern.ch and
> doesn't seem to have upset anyone yet after the first 40k  
> transactions.  I would now class the 2.0 server code as beta.
> ...

1. I just got a problem with your new httpd on info.cern.ch.

   When I tried to access the file: 

   http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/fix-html.pl

   with xmosaic 0.10, I got the following error message:

   HTFormat: Sorry, can't convert from application/binary to www/present.

   The line-mode browser www 1.3a produced the same error message.

   With www 2.0 an empty page were produced.

  After that I tried to use the new binary transfer mode feature of mosaic. 
  The result was a file with the above error message.

  The same problem occured with other files referenced from: 
  http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/Overview.html
  for example: text2html.sed

2. Is it possible to get the files referenced from:
   http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/Overview.html
   via ftp ? 

   Or can someone put the files on info.cern.ch under /WWW/dev ?


Arnold

________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1
phone:  +49-511-762-5320           Germany
________________________________________________________________________________


From jackson@stsci.edu  Mon Mar 22 18:34:13 1993
Return-Path: <jackson@stsci.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28725; Mon, 22 Mar 93 18:34:13 MET
Received: from stsci.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24998; Mon, 22 Mar 1993 18:52:45 +0100
Received: Mon, 22 Mar 93 12:52:43 EST from MARIAN.STSCI.EDU (kaos.stsci.edu) by stsci.edu (4.1)
Received: Mon, 22 Mar 93 12:52:40 EST by kaos.stsci.edu (4.1)
Date: Mon, 22 Mar 93 12:52:40 EST
From: Bob Jackson <jackson@stsci.edu>
Message-Id: <9303221752.AA09093@MARIAN.STSCI.EDU>
To: www-bug@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Trouble getting httpd server up
Reply-To: jackson@stsci.edu

I ftp'd the binaries and ...

% install httpd_2.02-beta /kaos/data1/bin/httpd
% install www_2.0-alpha /kaos/data1/bin/www
% rehash

I wanted to serve an existing directory tree

% httpd -v -p 8009 -dyt /kaos/data1/gopher-data &
httpd -v -p 8009 -dyt /kaos/data1/gopher-data &
[1] 9081
% Rule: For `/*' op 2 `/kaos/data1/gopher-data/*'
Rule: For `*' op 3 `(null)'
Daemon: Parsed address as port 8009, inet 0.0.0.0
IP: Opened socket number 3
Daemon: Master socket(), bind() and listen() all OK
Daemon: Waiting for connection or message. (Mask=8 hex, max=4 hex).

albeit with no httpd.conf file present.

Now I tried to look at the server

% www http://kaos.stsci.edu:8009/
www http://kaos.stsci.edu:8009/
Daemon: New incoming connection:
Daemon: Accepted new socket 4
Daemon: Waiting for connection or message. (Mask=18 hex, max=5 hex).
Message waiting on socket 4
Daemon: Reading socket 4 from host 130.167.107.12
Daemon: net read returned 128, errno=0
Daemon: Client accepts text/plain
Daemon: Client accepts text/html
Daemon: Client accepts image/jpeg
Daemon: Client accepts image/gif
Daemon: Client accepts application/postscript
New anchor 200b0 has hash 47 and address `/'
HTAccess: loading document /
For `/' using `/kaos/data1/gopher-data/'
HTRule: ...and pass `/kaos/data1/gopher-data/'
HTFile: can't stat /marian/u1/jackson/WWW///kaos/data1/gopher-data/
HTAccess: Opening `/marian/u1/jackson/WWW///kaos/data1/gopher-data/' gives -1
TCP: Local host name is kaos.stsci.edu
FTP: Looking for /kaos/data1/gopher-data/
HTTPAccess: Can't find internet node name `'.
TCP: Error 0 in `errno' after call to FTP file load() failed.
	Error 0
**** HTAccess: socket or file number returned by obsolete load routine!
     [End]



[1]    Exit 172             httpd -v -p 8009 -dyt /kaos/data1/gopher-data


I get the same error when I use the www_1.4 client.

Why are HTFile and HTAccess looking at:
	
	/marian/u1/jackson/WWW///kaos/data1/gopher-data/


Do I need a .html file in /kaos/data1/gopher-data ?

From putz@parc.xerox.com  Mon Mar 22 21:00:14 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00976; Mon, 22 Mar 93 21:00:14 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10820; Mon, 22 Mar 1993 21:18:42 +0100
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <12329>; Mon, 22 Mar 1993 11:39:00 PST
Received: by spoggles.parc.xerox.com id <58466>; Mon, 22 Mar 1993 11:26:03 -0800
Date: 	Mon, 22 Mar 1993 11:25:56 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: using perl for W3 servers
To: www-talk@nxoc01.cern.ch
Message-Id: <93Mar22.112603pst.58466@spoggles.parc.xerox.com>

I have a couple of HTML servers written in perl, running
under SunOS Unix, invoked via inetd.

Is there a way in perl to find out the internet address of the client?
Or do I have to give up the convenience of inetd to do that?

Steve Putz
Xerox Palo Alto Research Center

P.S.  Will there be a vote soon for the comp.infosystems.www newsgroup?

From mvanheyn@cs.indiana.edu  Mon Mar 22 21:15:07 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01179; Mon, 22 Mar 93 21:15:07 MET
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12981; Mon, 22 Mar 1993 21:33:38 +0100
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA00891; Mon, 22 Mar 1993 15:33:16 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Putz.parc@xerox.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: using perl for W3 servers 
In-Reply-To: Your message of "Mon, 22 Mar 1993 11:25:56 PST."
             <93Mar22.112603pst.58466@spoggles.parc.xerox.com> 
Date: Mon, 22 Mar 1993 15:33:16 -0500
Message-Id: <888.732832396@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: 
>I have a couple of HTML servers written in perl, running
>under SunOS Unix, invoked via inetd.
>
>Is there a way in perl to find out the internet address of the client?
>Or do I have to give up the convenience of inetd to do that?

I have an HTTP server written in perl, under SunOS Unix, as a
standalone daemon without inetd.  I considered inetd but am of the
opinion that the performance would be unacceptable if perl had to
parse the whole thing for every request.  Forks are not that expensive
in perl, and probably will be faster once we convert to a OpSys with
copy-on-write.  Thus, the code from mine looks more or less like the
code on page 345 of the Camel book.  It's running; URL
http://cs.indiana.edu/ if you want to peek.  I plan to release the
code once it's stable, though people can have unstable copies if they
really want.

The following code is taken from page 153 of the Camel book, and
probably does what you want:

  $sockaddr = 'S n a4 x8';
  $mysockaddr = getsockname(S);
  ($family, $port, $myaddr) = unpack($sockaddr, $mysockaddr);

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
De Gaulle remark[s ...] about the American "will to power, cloaking itself in
idealism."  By now, this will to power is not so much cloaked in idealism as
it is drowned in fatuity.		- Chomsky

From marca@wintermute.ncsa.uiuc.edu  Thu Mar 25 03:36:45 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12192; Thu, 25 Mar 93 03:36:45 MET
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24543; Thu, 25 Mar 1993 03:55:23 +0100
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05605
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 24 Mar 93 20:55:21 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA21772; Wed, 24 Mar 93 20:57:27 -0600
Date: Wed, 24 Mar 93 20:57:27 -0600
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303250257.AA21772@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: ebina@ncsa.uiuc.edu
Subject: icelandic characters
X-Md4-Signature: 18b591fb55ae5ad9f00050075f05243b

Anyone know just what the "Icelandic characters thorn and eth", as
referenced in http://info.cern.ch/hypertext/WWW/MarkUp/ISOlat1.html,
are?

(BTW, for the people who've been asking about it, full support for the
ISO Latin1 escapes will be in Mosaic v0.12.  As well as additional
support for 8-bit cleanliness, inlined images as anchors at end of
document and images in paragraphs generally, HTML highlighting
elements, nested definition lists, compact definition lists, etc.  Boy
oh boy oh boy, I tell ya, the Champaign post office better just be
jammed chock full of expensive gifts and foodstuffs from all around
the world after this one comes out....... :-)

Cheers,
Marc


From murphy@dccs.upenn.edu  Thu Mar 25 19:09:19 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22691; Thu, 25 Mar 93 19:09:19 MET
Received: from NOC2.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28393; Thu, 25 Mar 1993 19:27:57 +0100
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA18192; Thu, 25 Mar 93 13:27:51 -0500
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA19981; Thu, 25 Mar 93 13:26:35 -0500
Date: Thu, 25 Mar 93 13:26:35 -0500
From: murphy@dccs.upenn.edu
Posted-Date: Thu, 25 Mar 93 13:26:35 -0500
Message-Id: <9303251826.AA19981@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch
Subject: what happened to the comp.infosystems.www newsgroup?


last i heard, voting was supposed to be around March 15th.
10 days ago.

is it time? 
how do I vote?

--lam

From fine@cis.ohio-state.edu  Thu Mar 25 19:48:58 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23690; Thu, 25 Mar 93 19:48:58 MET
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11436; Thu, 25 Mar 1993 20:07:37 +0100
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA27112; Thu, 25 Mar 93 14:07:28 -0500
Date: Thu, 25 Mar 93 14:07:28 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9303251907.AA27112@soccer.cis.ohio-state.edu>
To: murphy@dccs.upenn.edu, www-talk@nxoc01.cern.ch
Subject: Re: what happened to the comp.infosystems.www newsgroup?
X-Mailer: Perl Mail System v1.2

>last i heard, voting was supposed to be around March 15th.
>10 days ago.
>
>is it time? 
>how do I vote?

I just sent out the call for votes to news.announce.newgroups, and
comp.infosystems.  The voting begins as soon as the articles appear
(which depends on how soon the moderator posts them).  Please DO NOT
vote until you see the actual call for votes, and please do NOT send
me votes.

	 tom

From janssen@parc.xerox.com  Sat Mar 27 00:51:13 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16615; Sat, 27 Mar 93 00:51:13 MET
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08652; Sat, 27 Mar 1993 01:09:48 +0100
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11642>; Fri, 26 Mar 1993 16:09:32 PST
Received: by holmes.parc.xerox.com id <16134>; Fri, 26 Mar 1993 16:09:30 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Fri, 26 Mar 1993 16:09:22 -0800 (PST)
Message-Id: <AfgtgmcB0KGW42TWd5@holmes.parc.xerox.com>
Date: 	Fri, 26 Mar 1993 16:09:22 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: timbl@nxoc01.cern.ch
Subject: Some HTTP questions
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: 
References: 

Tim, I've been going over the HTTP spec
(ftp://info.cern.ch/pub/www/doc/http-spec.txt), and have some questions.

What (if any) "Authorization" and "ChargeTo" schemes have been
registered?  Is anyone using these, to your knowledge?

The format of a response is not really clear, from the spec.  What is
"the format of a MIME message"?  Does this mean, "the format of an
RFC-822 message, as amended by RFC 1341"?  Or does this mean, "the MIME
headers `Content-Type' and `Content-Encoding' should appear first,
followed by a blank line, followed by the body of the response"?  Do
binary responses (gif, etc.) need to be BASE64'ed?  (Presumably not.)

Presumably the document ftp://info.cern.ch/pub/www/doc/http.txt is now
obsolete?

Is anyone working on an NFS server for HTTP?  That is, a server where
files on the file system would actually be references to HTTP-accessible
objects?

Thanks.

Bill

From Nathan.Torkington@vuw.ac.nz  Sun Mar 28 08:47:04 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26242; Sun, 28 Mar 93 08:47:04 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08834; Sun, 28 Mar 1993 09:05:44 +0200
Received: by kauri.vuw.ac.nz id AA25536
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Sun, 28 Mar 1993 19:05:39 +1200
Date: Sun, 28 Mar 1993 19:05:39 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199303280705.AA25536@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Tabular environment in HTML

I can see that I'm going to want to deliver information in tabular
form in HTML, but there's no way to do that currently.

How about

<TABULAR COLS=6>
<TI>Item<TI>Item<TI>Item<TI>Item<TI>Item<TI>Item
<TI>Item<TI>Item<TI>Item<TI>Item<TI>Item<TI>Item
</TABULAR>

Nat

From joe@athena.mit.edu  Sun Mar 28 22:22:51 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29237; Sun, 28 Mar 93 22:22:51 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22288; Sun, 28 Mar 1993 22:41:36 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA02920; Sun, 28 Mar 93 15:41:35 EST
Received: by theodore-sturgeon (5.57/4.7) id AA06069; Sun, 28 Mar 93 15:41:34 -0500
Message-Id: <9303282041.AA06069@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch
Subject: Is this legal HTML?
Date: Sun, 28 Mar 93 15:41:33 EST
From: Joseph Wang <joe@athena.mit.edu>

Is it legal HTML to start an internal anchor without a closing </A>?
For example, <A NAME="foo"> without a </A>

The trouble with doing this is that the hypertext browser has no way of
knowing whether to highlight the text behind the starting anchor or not.


From joe@athena.mit.edu  Mon Mar 29 01:20:55 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00401; Mon, 29 Mar 93 01:20:55 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04738; Mon, 29 Mar 1993 01:39:41 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA10214; Sun, 28 Mar 93 18:39:28 EST
Received: by theodore-sturgeon (5.57/4.7) id AA06631; Sun, 28 Mar 93 18:39:27 -0500
Message-Id: <9303282339.AA06631@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch
Cc: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: Is this legal? 
Date: Sun, 28 Mar 93 18:39:26 EST
From: Joseph Wang <joe@athena.mit.edu>


O.K. unterminated anchors are illegal.

Are nested anchors?  It seems that the line mode browser doesn't support it
if it is legal.


From timbl  Mon Mar 29 17:00:50 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09613; Mon, 29 Mar 93 17:00:50 MET DST
Date: Mon, 29 Mar 93 17:00:50 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303291500.AA09613@ nxoc01.cern.ch >
To: janssen@parc.xerox.com, timbl@nxoc01.cern.ch
Subject: Re: Some HTTP questions
Cc: www-talk@nxoc01.cern.ch

Thanks for your comments.  By "MIME message" it means an RCC-822
message as enhanced by RFC1341, but with of ocurse the possibility of 8 bit
transmission. Something which we may want to add for this is a length
header field which MIME only allows on external, not internal, body parts.
We should sheck out the STMP 8 bit extensions which I am not sufficiently
knowledgable about.

No, base64 encodeing will not be necessary.  We have to decide
which MIME features may be sent without any permission from the client
but I imagine that all MIME encodings should be understood, but
only text/plain and text/html are required to be understood a priori.

No, I don't know of any Alex-style NFS server for http: space.

Tim BL

From timbl  Mon Mar 29 18:04:45 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10691; Mon, 29 Mar 93 18:04:45 MET DST
Date: Mon, 29 Mar 93 18:04:45 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303291604.AA10691@ nxoc01.cern.ch >
To: www-yes@msen.com
Subject: YES vote for comp.infosystems.www
Cc: www-talk@nxoc01.cern.ch


To help create the comp.infosystems.www newsgroup,
please send a message to www-yes@msen.com

Tim BL
W3 at CERN

From putz@parc.xerox.com  Mon Mar 29 18:39:01 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11220; Mon, 29 Mar 93 18:39:01 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21352; Mon, 29 Mar 1993 18:57:47 +0200
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11608>; Mon, 29 Mar 1993 08:57:35 PST
Received: by spoggles.parc.xerox.com id <34118>; Mon, 29 Mar 1993 08:57:21 -0800
Date: 	Mon, 29 Mar 1993 08:57:16 PST
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: Tabular environment in HTML
In-Reply-To: <199303280705.AA25536@kauri.vuw.ac.nz>
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Cc: www-talk@nxoc01.cern.ch
Message-Id: <93Mar29.085721pst.34118@spoggles.parc.xerox.com>

Yes, I also have found a need for at least two-column tables.

Steve Putz

From timbl  Mon Mar 29 18:51:43 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11360; Mon, 29 Mar 93 18:51:43 MET DST
Date: Mon, 29 Mar 93 18:51:43 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303291651.AA11360@ nxoc01.cern.ch >
To: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Subject: Re: Tabular environment in HTML

Tabular work is, accordingto the experts, a can of worms.
However, it is important.  It is definitely not in HTML,
but a good discussion is definitively in order.
Tables in practice need all kinds of things
(joined cells, break lines, etc)  A lot of work has been done,
it needs to be brought together and written up.

Pointers, anyone?

Tim

From timbl  Mon Mar 29 18:54:22 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11419; Mon, 29 Mar 93 18:54:22 MET DST
Date: Mon, 29 Mar 93 18:54:22 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303291654.AA11419@ nxoc01.cern.ch >
To: joe@athena.mit.edu, www-talk@nxoc01.cern.ch
Subject: Re: Is this legal HTML?

No, any <A> must have an </A>.  

Also, anchors may not be nested.

Tim BL

From fine@cis.ohio-state.edu  Mon Mar 29 19:04:58 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11575; Mon, 29 Mar 93 19:04:58 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25335; Mon, 29 Mar 1993 19:23:45 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA01253; Mon, 29 Mar 93 12:23:42 -0500
Date: Mon, 29 Mar 93 12:23:42 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9303291723.AA01253@soccer.cis.ohio-state.edu>
To: timbl@nxoc01.cern.ch
Subject: Re: YES vote for comp.infosystems.www
Cc: www-talk@nxoc01.cern.ch
X-Mailer: Perl Mail System v1.2

>
>To help create the comp.infosystems.www newsgroup,
>please send a message to www-yes@msen.com

The rules of newsgroup creation demand equal time.  To vote against
the creation of the newsgroup, send a message to www-no@msen.com.

Please don't "reply all" to Tim's message, either, as this would make
it harder to sort out what things are votes, and what are replies to
his message.

For your convenience, here is a copy of the call for votes:

-------------------------------------------------------------------------
Subject: CFV: comp.infosystems.www

This is a formal Call for Votes on the creation of a new unmoderated
newsgroup called comp.infosystems.www, following a favorable discussion
of this newsgroup.

GROUP DETAILS
Name: comp.infosystems.www
Not moderated
Charter: In general, the discussion of all things related to the world
wide web, including design of software, development of new software,
and development of documentation within the Web.

VOTING

Do NOT send votes to me!!!
Do NOT post your vote!!!

To vote Yes: send mail to "www-yes@msen.com"
To vote No:  send mail to "www-no@msen.com"

In addition, the wording of the message must be in agreement with
the address, and should not include anything the least bit ambiguous.

Voting will end on April 20, 1993.  Any votes received after this
date will be ignored.

In order for the newsgroup to be created, the yes votes must account for
2/3 of the total number of votes, and must outnumber the no votes by
a margin of at least 100 votes.

       tom

------------------------------------------------------------------------------
| Thomas A. Fine    | fine@cis.ohio-state.edu   | 2036 Neil Avenue Mall      |
| CIS Staff         | (614) 292-7325            | Columbus, Ohio 43210       |
| The Ohio State University - Department of Computer and Information Science |

From marca@wintermute.ncsa.uiuc.edu  Mon Mar 29 19:35:05 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12133; Mon, 29 Mar 93 19:35:05 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01444; Mon, 29 Mar 1993 19:53:52 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26118
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Mon, 29 Mar 93 11:49:54 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Nathan.Torkington@vuw.ac.nz id AA09083; Mon, 29 Mar 93 11:52:03 -0600
Date: Mon, 29 Mar 93 11:52:03 -0600
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303291752.AA09083@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Subject: Re: Tabular environment in HTML
In-Reply-To: <9303291651.AA11360@ nxoc01.cern.ch >
References: <9303291651.AA11360@ nxoc01.cern.ch >
X-Md4-Signature: 8b0459c92d2e64908ec8634e2f86c660

Tim Berners-Lee writes:
> Tabular work is, accordingto the experts, a can of worms.  However,
> it is important.  It is definitely not in HTML, but a good
> discussion is definitively in order.  Tables in practice need all
> kinds of things (joined cells, break lines, etc) A lot of work has
> been done, it needs to be brought together and written up.
> 
> Pointers, anyone?

As I mentioned to Nathan in private email, maybe just doing a
reasonable clone of the LaTeX table functionality would be a good way
to go.

Marc


From marca@wintermute.ncsa.uiuc.edu  Tue Mar 30 10:07:25 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21837; Tue, 30 Mar 93 10:07:25 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06549; Tue, 30 Mar 1993 10:26:12 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05327
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 30 Mar 93 02:26:08 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11137; Tue, 30 Mar 93 02:28:16 -0600
Date: Tue, 30 Mar 93 02:28:16 -0600
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9303300828.AA11137@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: don't think this made it onto www-talk yet.....
X-Md4-Signature: 096bc88843f40a6ff3c097589cec0992

Newsgroups: cs.system.announce,alt.hypertext,gnu.emacs.sources
From: wmperry@avocado.ucs.indiana.edu (William M. Perry)
Subject: Announcing A World Wide Web Browser For Emacs
Nntp-Posting-Host: avocado.ucs.indiana.edu
Organization: Computer Science Student, Indiana University
Date: Tue, 30 Mar 1993 03:34:25 GMT

This is to announce a World Wide Web browser for emacs (.004beta) that I've
written over the last week.  It's not extremely pretty code, but it works
(95% or so).

Right now the only links this doesn't support are news links (which
shouldn't be all that hard to work in, just haven't had the time just yet).
Telnet, Gopher, Ftp, HTTP, and local file access are all supported.  If you
are using Lucid Emacs or Epoch, the headers, titles, and nodes are
highlighted/in a different font, and menus are used.

Main Points:
 1. Supports relative file access (ie: links to foo.html instead of
    http://xxx.com:80/bar/foo.html)
 2. Gopher support via the gopher.el package written by Scott Snyder
    (snyder@d0gsc.fnal.gov)
 3. Telnet support via the transparent.el package written by Brian Tompsett
    (briant@spider.co.uk)
 4. Remote file access via ange-ftp.el, written by Andy Norman
    (ange@hplb.hpl.hp.com)
 5. Http and local file support by me
 6. Support for all HTML formatting commands (that I could find anyway)
 7. Automatic uncompression of files (gunzip or uncompress based on the
    file extension)
 8. If in X, automatic recognition of sound/postscript/dvi/gif/jpg/etc
    files, and piping to external commands (user-specifiable)
 9. Understands XMosaic hotlist files (and can modify them)
10. Searching (server-based, but prompts for keywords, etc)
11. Previewing of html buffers (w3-preview-this-buffer).  Mainly used by me
    to write urls to try and break the parser, but also good for checking
    normal html docs while writing.

I've only found a few html documents that could break this (and even then
not _completely_), so I figured I would release it and see if anyone out
there would like to use it/become a beta-tester.  If you decide to grab
this, please send me a mail message, so I can know if anyone out there is
actually using this stuff I write. :)

The file(s) can be ftp'd from moose.cs.indiana.edu in /pub/elisp/w3/*
The tar file contains ange-ftp, gopher, transparent, and w3.  If you've
already got these installed on your system, just grab the w3.el file that
is also in that directory.  

The default home page for the viewer is a documentation tree I am putting
together here on our http server.
(http://moose.cs.indiana.edu:80/elisp/w3/docs.html)

The tar file includes a makefile.  You can use this to automatically update
your .emacs (make emacs), as well as byte-compile the files (make all).

-------------------------------------------------------------------------------
!!!!!!!!!!!!!!!!!!!!!!!!!! There is one major problem. !!!!!!!!!!!!!!!!!!!!!!!!
-------------------------------------------------------------------------------
If you don't have emacs linked with the hostname resolultion library
(-lresolve), this won't work right now.  I've tried to work around this by
having a function called w3-open-stream.  If you have hostname resolution
linked in, no problem.  Just alias w3-open-stream to be
open-network-stream.  Works fine.  Problem comes when I want to define
w3-open-stream to be (start-process ... "/usr/ucb/telnet " host port etc).
Doesn't work at all.  The string never gets sent to the subprocess, and the
connection is eventually timed out.  Weird part is that if I use edebug to
step through the function, it works perfectly - sends the string to the
subprocess, and the file is retrieved.  Same thing happens if I type the
commands in lisp-interaction-mode.  But calling it from within a function
causes it to choke.

Any help on that problem would be greatly appreciated, since a lot of
people don't link with -lresolve, and don't have sysadmins as nice as mine
that will redo it on a whim. :)

-------------------------------------------------------------------------------

Any help/feedback would be appreciated.  Especially http addresses of files
that cause this to choke.

The source code by itself is also available via http (of course):
http://moose.cs.indiana.edu:80/elisp/w3/w3.el

Thanks,
    -Bill Perry
-- William M. Perry (wmperry@indiana.edu) --
These views/programs have nothing to do with Indiana University, University
Computing Services, the CIA, the NSA, the KGB, NASA, or the ASPCA.  IU pays
me for programming in inferior programming languages like C++, not elisp!!!



From koellner%Csa6.LBL.Gov@lbl.bitnet  Wed Mar 31 01:02:59 1993
Return-Path: <koellner%Csa6.LBL.Gov@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03449; Wed, 31 Mar 93 01:02:59 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18493; Wed, 31 Mar 1993 01:21:48 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 6536; Wed, 31 Mar 93 01:17:49 SET
Received: from Lbl.Bitnet (NJE origin MAILER@LBL) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 1899; Wed, 31 Mar 1993 01:17:48 +0200
Received: from Csa6.LBL.Gov by Csa3.LBL.Gov via INTERNET ;
          Tue, 30 Mar 93 15:21:30 PST
Date:    Tue, 30 Mar 93 15:21:21 PST
From: koellner%Csa6.LBL.Gov%Lbl.BITNET@cearn.bitnet (Werner Koellner, LBL)
Message-Id: <930330152121.20801304@csa6.lbl.gov>
Subject: Question about xMosaic HOME PAGE
To: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"www-talk@nxoc01.cern.ch"

                                         LBL, Physics Division, 30-MAR-1993

    Is the "Home Page", i.e. mosaic-home.html in hoohoo.ncsa.uicu.edu, for
    xmosaic available via ftp or such? I have currently www, viola, and
    xmosaic available on our SUN's and in the case of viola/www I have
    edited the WWW_HOME page. Since I have the environment variable
    WWW_HOME set when I run xmosaic the *.html file for WWW gets picked up.
    To get mosaic-home.html displayed I need to unsetenv WWW_HOME first.
    Although that's no big deal, I would rather add an anchor to the
    xmosaic home page in my www.html file (or have the mosaic-home.html
    here).

    If I put an anchor to mosaic-home.html in my *.html the server refuses
    to hand it to me. I look forward to any suggestions or comments.

                   Many thanks,

                                   Werner

From timbl  Wed Mar 31 05:53:54 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05934; Wed, 31 Mar 93 05:53:54 MET DST
Date: Wed, 31 Mar 93 05:53:54 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303310353.AA05934@ nxoc01.cern.ch >
To: koellner%Csa6.LBL.Gov%Lbl.BITNET@cearn.bitnet, www-talk@nxoc01.cern.ch
Subject: Re: Question about xMosaic HOME PAGE

Werner, you say that you can pick up the XMosaic default home
page directly but not via a link from your own home page.
I suspect that this is a bug in the link.  Try picking it
up with

www -v

to see what it is trying to pick up, and if that doesn't show
you what is going wrong, mail the trace to me.

Tim
From koellner%Csa6.LBL.Gov@lbl.bitnet Wed Mar 31 01:03:51 1993
Return-Path: <koellner%Csa6.LBL.Gov@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03449; Wed, 31 Mar 93 01:02:59 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18493; Wed, 31 Mar 1993 01:21:48 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 6536; Wed, 31 Mar 93 01:17:49 SET
Received: from Lbl.Bitnet (NJE origin MAILER@LBL) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 1899; Wed, 31 Mar 1993 01:17:48 +0200
Received: from Csa6.LBL.Gov by Csa3.LBL.Gov via INTERNET ;
          Tue, 30 Mar 93 15:21:30 PST
Date:    Tue, 30 Mar 93 15:21:21 PST
From: koellner%Csa6.LBL.Gov%Lbl.BITNET@cearn.bitnet (Werner Koellner, LBL)
Message-Id: <930330152121.20801304@csa6.lbl.gov>
Subject: Question about xMosaic HOME PAGE
To: www-talk@nxoc01.cern.ch
X-St-Vmsmail-To: ST%"www-talk@nxoc01.cern.ch"
Status: RO

                                         LBL, Physics Division, 30-MAR-1993

    Is the "Home Page", i.e. mosaic-home.html in hoohoo.ncsa.uicu.edu, for
    xmosaic available via ftp or such? I have currently www, viola, and
    xmosaic available on our SUN's and in the case of viola/www I have
    edited the WWW_HOME page. Since I have the environment variable
    WWW_HOME set when I run xmosaic the *.html file for WWW gets picked up.
    To get mosaic-home.html displayed I need to unsetenv WWW_HOME first.
    Although that's no big deal, I would rather add an anchor to the
    xmosaic home page in my www.html file (or have the mosaic-home.html
    here).

    If I put an anchor to mosaic-home.html in my *.html the server refuses
    to hand it to me. I look forward to any suggestions or comments.

                   Many thanks,

                                   Werner


From timbl  Wed Mar 31 06:15:14 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06065; Wed, 31 Mar 93 06:15:14 MET DST
Date: Wed, 31 Mar 93 06:15:14 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303310415.AA06065@ nxoc01.cern.ch >
To: montulli@stat1.cc.ukans.edu, timbl@nxoc01.cern.ch
Subject: Re: Lynx 2.0
Cc: www-talk@nxoc01.cern.ch

Lou,

Looks great!   There was just today a discussion at the IETF of how
a good screen mode www is needed!   I will move the tar files and
put in pointers when I get home next week, and announce it as beta.
I just played with it a little, I will mention it to a few people here
and forward you rmessage to www-talk.  If your code is not on
the server in a week, mail me again in case I dropped all my mail in a hole.
or the plane crshed or something.  I think this will be really
useful because of the large number of _real_ (ie vt100) users
out there.... and your message is very timely!

Tim

	From montulli@stat1.cc.ukans.edu Wed Mar 31 02:13:38 1993
	Return-Path: <montulli@stat1.cc.ukans.edu>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA04097; Wed, 31 Mar 93 02:13:36 MET DST
	Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
		id AA24830; Wed, 31 Mar 1993 02:32:26 +0200
	Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
	          id AA01543; Tue, 30 Mar 1993 18:25:31 -0600
	From: montulli@stat1.cc.ukans.edu (Lou Montulli)
	Message-Id: <9303310025.AA01543@stat1.cc.ukans.edu>
	Subject: Lynx 2.0
	To: timbl@nxoc01.cern.ch
	Date: Tue, 30 Mar 93 18:25:31 CST
	X-Mailer: ELM [version 2.3 PL2]
	Status: RO

	Tim,
	    As you may know, Lynx 2.0 will have full WWW capabilities (or at least 
	those of the line mode browser).  Lynx 2.0 is currently in Beta test but I
	think it is about time for it to be added to the WWW software list that
	you maintain.  As a curses client I believe that Lynx has a lot to
	offer to the WWW comunity.  

	There is a demo account set up for anonymous login if you would 
	like to try it out.  Telnet to ukanaix.cc.ukans.edu and login as "www".

	Anonymous FTP access to the source and binaries is at acs220.cc.ukans.edu.

	Let me know what you want me to do to help get this set up.

	:lou
	-- 
	  **************************************************************************
	  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
	  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
	  *                         Kuhub.cc.ukans.edu               	           *
	  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
	  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
	  *					         			   *
	  *  For how we live is so different from how we ought to live that he who *
	  *  studies what ought to be done rather than what is done will learn the *
	  *  way to his downfall rather than to his preservation.  -Machiavelli    *
	  **************************************************************************



From dsr@hplb.hpl.hp.com  Wed Mar 31 13:45:39 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09692; Wed, 31 Mar 93 13:45:39 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27182; Wed, 31 Mar 1993 14:04:25 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 31 Mar 93 12:58:50 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA22020; Wed, 31 Mar 93 13:05:30 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9303311205.AA22020@manuel.hpl.hp.com>
Subject:  Re: Tabular environment in HTML
To: www-talk@nxoc01.cern.ch
Date: Wed, 31 Mar 93 13:05:28 BST
Mailer: Elm [revision: 66.36.1.1]

> Tabular work is, accordingto the experts, a can of worms.
> However, it is important.  It is definitely not in HTML,
> but a good discussion is definitively in order.
> Tables in practice need all kinds of things
> (joined cells, break lines, etc)  A lot of work has been done,
> it needs to be brought together and written up.

> Pointers, anyone?

> Tim

I have looked at Latex, tbl and Microsoft Word, and come up with a
rich yet easy scheme for augmenting HTML. Please look through
and voice your comments!

tbl is simple except when you want multi-line text which gets tedious
as you are forced to specify the line breaks explicitly. This can be
circumvented with a simple extension. The style of tbl leads to lots of
tabs for padding over empty cells. This comes from not being able to
say that a given cell should be further subdivided. It has a nice
feature for aligning numeric values, missing from Latex.

Latex's tablular environments are ok, but get messy for fields extending
across multiple columns.

Microsoft Word allows you to first specify the number of rows and columns
and then alter them, e.g. merging or splitting adjacent cells.


Here is my suggestion for a general scheme for specifying tables
which uses just three tags and IMHO is simpler than the above:

The following example from Lamport's Latex manual should make all this clear:

    -------------------------------------------------
    |    CG&A Hoofed Stock                          |
    |===============================================|
    |      ||    Price    |                         |
    |      ||-------------|                         |
    | Year ||  low | high |     Comments            |
    |-----------------------------------------------|
    | 1971 ||    97-245   | Bad year for farmers    |
    |      ||             | in the west.            |
    |-----------------------------------------------|
    |   72 ||   245-245   | Light trading due to a  |
    |      ||             | bad winter.             |
    |-----------------------------------------------|
    |   73 ||   245-2001  | No gnus was very good   |
    |      ||             | gnus this year.         |
    -------------------------------------------------

    <table>
        <line>
        <row cols="c">
        CG&A Hoofed Stock
        <line>
        <line>
        <row cols="|cb||c|cb|">
        Year <t>
        <table>
            <row cols="c">
            Price
            <line>
            <row cols="r|l">
            low <t> high
        </table>
        Comments
        <row cols="nnl20">
        1971 <t> 97-245 <t> Bad year for farmers in the west. <t>
        72 <t> 245-245 <t> Light trading due to a heavy winter.
        73 <t> 245-2001 <t> No gnus was very good gnus this year.
    </table>

Tables are specified by the <table> ... </table> tag.

You specify a format for the current row. This continues until a new
specification is given:

    <row cols=FORMAT> where the FORMAT is a string formed from:

    l       left aligned column
    r       right aligned column
    c       centered column
    n       numeric aligned column (on units or decimal point)

    t       align this cells contents at the top of the row
    b       align this cells contents at the bottom of the row

    |       a vertical line extending the height of this row only
            this is repeated for mutiple lines

The vertical alignment is an optional suffix following l,r,c,n.
An optional width can be given as an integer following l, r, c
(after t or b if present) to indicate the desired width of the column
in characters (av.char width), e.g. "lt40"

Numerically aligned fields will be nominally centered, but adjusted so
that the units digits line up (or the decimal point). You can also
specify more that one number, e.g. nnn-nnn, in which case the browser
may be able to line up the "-" chars, or failing that to simply centering
the text. (Should we make "-" an optional format character, e.g. "n-n" ?)

The text for each cell is separated by a tag e.g. <t> rather than the
tab character as used by tbl.

The <line> tag ends the current row and draws a line extending across the full
extent of this table. Any missing cell values are padded with blanks.

You can nest <table> tags to split a given cell into smaller ones. The width
and height of the nested table then effects the size of the row and column
of the parent table, into which it is inserted.

All rows in a given table have the same width. The width of each cell is
determined by the cell containing the largest value for the corresponding
row and column.

It may be advisable to require all <row> tags in a table to specify the
same number of columns. In this case you then need an "s" format character
to indicate a spanned column, i.e. merged with the preceding one.


Dave Raggett

HPLabs, Bristol, UK

+44 272 228046
dsr@hplb.hpl.hp.com

From janssen@parc.xerox.com  Thu Apr  1 00:56:39 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21635; Thu, 1 Apr 93 00:56:39 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21261; Thu, 1 Apr 1993 01:15:29 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11942>; Wed, 31 Mar 1993 15:15:08 PST
Received: by holmes.parc.xerox.com id <16134>; Wed, 31 Mar 1993 15:15:00 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 31 Mar 1993 15:14:54 -0800 (PST)
Message-Id: <ofiWLioB0KGWFC3=Zz@holmes.parc.xerox.com>
Date: 	Wed, 31 Mar 1993 15:14:54 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: Filters for HTML?
In-Reply-To: 
References: 

Does anyone have filters that will convert HTML to TeX?  Or TROFF?  Or
PostScript?  or anything...

Bill

From timbl  Thu Apr  1 01:45:54 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22389; Thu, 1 Apr 93 01:45:54 MET DST
Date: Thu, 1 Apr 93 01:45:54 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9303312345.AA22389@ nxoc01.cern.ch >
To: janssen@parc.xerox.com, www-talk@nxoc01.cern.ch
Subject: Re: Filters for HTML?
Cc: secret@dxcern.cern.ch

Yes, we have very crude filters for converting clean SGML to TeX
-- just 'sed' files.   They will take the output of the NextStep
WorldWideWeb.app becaus it puts line breaks in and so sed
can handle it.

If you want to make a converter which parses the HTML properly,
you could take the line mode client version 2.0, and
in the library just hack the HTML regeneration module
HTMLGen.{c,h} to produce TeX instead of HTML. The module
is driven by a stream of text and element stop/start by
element number, so it is just a set of tables of strings.

If you are interested in our mapping, ask Arthur Secret
<secret@dxcern.cern.ch> to mail you our latest sed files.
We in fact made one new latex macro  for the paper docs
we push out, in order to do a better job of DL lists.

The basic sed files for making article style latex are
on the web ... look under "tools for information providers".

Tim
	From janssen@parc.xerox.com Thu Apr  1 00:56:53 1993
	Return-Path: <janssen@parc.xerox.com>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA21635; Thu, 1 Apr 93 00:56:39 MET DST
	Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
		id AA21261; Thu, 1 Apr 1993 01:15:29 +0200
	Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11942>; Wed, 31 Mar 1993 15:15:08 PST
	Received: by holmes.parc.xerox.com id <16134>; Wed, 31 Mar 1993 15:15:00 -0800
	Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
	          via MS.5.6.holmes.parc.xerox.com.sun4_41;
	          Wed, 31 Mar 1993 15:14:54 -0800 (PST)
	Message-Id: <ofiWLioB0KGWFC3=Zz@holmes.parc.xerox.com>
	Date: 	Wed, 31 Mar 1993 15:14:54 PST
	Sender: Bill Janssen <janssen@parc.xerox.com>
	From: Bill Janssen <janssen@parc.xerox.com>
	To: www-talk@nxoc01.cern.ch
	Subject: Filters for HTML?
	In-Reply-To: 
	References: 
	Status: O

	Does anyone have filters that will convert HTML to TeX?  Or TROFF?  Or
	PostScript?  or anything...

	Bill


From janssen@parc.xerox.com  Thu Apr  1 03:22:48 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23431; Thu, 1 Apr 93 03:22:48 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13920; Thu, 1 Apr 1993 03:41:39 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11980>; Wed, 31 Mar 1993 17:41:14 PST
Received: by holmes.parc.xerox.com id <16134>; Wed, 31 Mar 1993 17:41:09 -0800
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 31 Mar 1993 17:41:02 -0800 (PST)
Message-Id: <AfiYUiwB0KGW5C30E5@holmes.parc.xerox.com>
Date: 	Wed, 31 Mar 1993 17:41:02 PST
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Subject: Re: Filters for HTML?
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9303312345.AA22389@nxoc01.cern.ch>
References: <9303312345.AA22389@nxoc01.cern.ch>

Thanks, I'll do that.  I think I'd generate texinfo instead of tex... 
Sort of circular, isn't it?

Bill

From marca@wintermute.ncsa.uiuc.edu  Thu Apr  1 08:19:47 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25708; Thu, 1 Apr 93 08:19:47 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03852; Thu, 1 Apr 1993 08:38:40 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA10178
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 1 Apr 93 00:38:22 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:raisch@ora.com id AA17130; Thu, 1 Apr 93 00:39:14 -0600
Date: Thu, 1 Apr 93 00:39:14 -0600
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304010639.AA17130@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: internet talk radio.....
X-Md4-Signature: c4cad968b7ceee5612ab7d3fedc91817

.....for March 31, 1993 is now in hypermedia form at:

        http://hoohoo.ncsa.uiuc.edu:80/radio.html

NCSA Mosaic 0.9 or later, with a properly configured
audioPlayerCommand resource (metamail's "showaudio", by default), is
the assumed interface.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From dsr@hplb.hpl.hp.com  Thu Apr  1 14:20:55 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28414; Thu, 1 Apr 93 14:20:55 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21491; Thu, 1 Apr 1993 14:39:46 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Thu, 1 Apr 93 13:34:10 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA02927; Thu, 1 Apr 93 13:40:52 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304011240.AA02927@manuel.hpl.hp.com>
Subject: Re internet talk radio.....
To: www-talk@nxoc01.cern.ch
Date: Thu, 1 Apr 93 13:40:50 BST
Mailer: Elm [revision: 66.36.1.1]

> NCSA Mosaic 0.9 or later, with a properly configured
> audioPlayerCommand resource (metamail's "showaudio", by default), is
> the assumed interface.

Great idea! It seems daft though to have to first down load the files
before playing them. What we need is a smarter approach which concurrently
retreives the audio data and pipes it into the audio player process.

You will still need a few seconds (~5) to fill up a fifo so that you don't
get gaps in the sound track due fluctuations in network traffic.

Unfortunately, very few of us in HPLabs have audio capability on our
workstations - grr gnash grr

Dave Raggett

From timbl  Thu Apr  1 19:16:00 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02957; Thu, 1 Apr 93 19:16:00 MET DST
Date: Thu, 1 Apr 93 19:16:00 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304011716.AA02957@ nxoc01.cern.ch >
To: www-talk@nxoc01.cern.ch
Subject: Summary of WWW BOF at IETF


There was a small meeting about WWW at the 26th 
Internet Engineering Task Force meeting in Columbus
Ohio on Tuesday.   This is a summary for the record.

Tim BL

                              
                       WWW BOF Minutes
                              
            This  is a summary of the discussion at the  WWW
          BOF at the 26th IETF.
     Status
            Tim   Berners-Lee   mentioned   a   few   recent
          developments:
                  + NCSA's "Mosaic" WWW client for  X11
                    agreed by the meeting to be the best
                    information access tool to date.  This
                    is at an advanced beta state (version
                    0.12).  FTP pickup rate for this product
                    now excedes that for NCSA telnet.
                  + A Windows client for MS-DOS machines
                    exists, the equivalent of XMosaic but
                    for PCs.   It is user configurable and
                    looks good.  A problem with release is
                    that a runtime licence is needed for te
                    TCP stack used (Distinct).
                  + The growth rate of access to the CERN
                    server has continued to double every
                    four months for the last two years with
                    no sign of tapering off.
     Man pages on the web
            Steve  Romig  of Ohio State was congrtulated  on
          his server server for unix manual pages.  This  is
          a  good  example  of an automatic server  (a  perl
          script  in  this case) which provides  a  powerful
          data  access.   Steve agreed  to  make  his  tools
          available on the web.
     Web Agenda
            There was a discussion of things which should be
          done  to  make  it easier for the web  to  spread.
          These include
                  + Better packaging of CERN sofware, in
                    particular the server: simpler
                    installation, irrelevant file hiding,
                    etc.
                  + Licencising of CERN software:  There was
                    deep concern expressed that investment
                    by others in WWW related projects wuld
                    be jepardized later by CERN's licencing
                    conditions, in the way that the
                    University of Minnesota have pulled the
                    rug out from under the Gopher project.
                    The General Public (Gnu-style) licence
                    was not so acceptable as pure public
                    domain code.  The meeting was quite
                    intent that this be solved very quickly.
                  + A better vt100 full-screen browser is
                    needed for a large dial-up user base.
            NCSA  are  likely to bring out a  public  domain
          very  simple  to  install  server,  as  a  partial
          solution to the first two issues issues.
            There was a proposal to create a small group  to
          implement the vt100 client, which formed and  aims
          to implement the product for public release.
          vt100 client
            [Note:   Minutes  after the BOF we  received  an
          announcement of the "Lynx" 2.0 beta release by Lou
          Montulli.  This may solve the problem or at  least
          provide  a  base.   Lynx is a  vt100  full  screen
          hypertext  WWW client.  Check it out by telnetting
          to  ukanaix.cc.ukans.edu and logging  in  as  www.
          Source and binaries are available by anon FTP from
          acs220.cc.ukans.edu]
     Standards
            The  three standards important for WWW  at  this
          stage are:
            The Universal Resource Locators spec defines the
          addressing syntax used by WWW.    This  is  to  be
          released immediately as an Internet Draft for  the
          standards track.
            The    Hypertext    Markup   Language     (HTML)
          specification  defines the  transport  format  for
          menus, hypertext and general online documentation.
          This  must  be  specified at RFC  standards  track
          level  in order to be submitted as a MIME content-
          type.  This in turn is necessary as HTTP uses MIME
          format  for returned multimedia messages,  and  we
          want   it  to  stay  MIME-compliant.   HTML   will
          therefore be released as an Internet Draft as soon
          as possible.
            HTTP is the access protocol used by WWW servers.
          An  extended (back-compatible) version  is in  use
          in the 2.0 and above CERN software.  This is quite
          open  to  extension  and so  any  comment  on  the
          protocol should be discussed on the www-talk list.
            It was agreed to put these documents through the
          IIR  working group whose chaiman, Chis Wieder, has
          agreed  to  oversee their passage.  The  BOF  will
          not, therfore, meet again or propose a WWW working
          group.
     Mailing lists and newsgroup
            To  join the technical mailing list, send a mail
          message to the address

                    www-talk-request@info.cern.ch

            for  human  attention.   There  is  a  newsgroup
          currently    being   formed.     Its    name    is
          comp.infosystems.www.  To vote  on  its  creation,
          please mail either
                    www-yes@msen.com
            or
                    www-no@msen.com

            depending  whether  you wish  the  group  to  be
          formed or not.
            
            
     Present:

     Tim Berners-Lee <timbl@info.cern.ch>  (chair)
     Jill Foster <Jill.Foster@newcastle.ac.uk>
     Jane Smith <Jane.Smith@cnidr.org>
     Karen Sollins <sollins@lcs.mit.edu>
     Mark Prior <mrp@itd.adelaide.edu.au>              *
     Jim Knowles <jknowles@binky.arc.nasa.gov>
     Steve Romig <romig@cis.ohio-state.edu>
     Michael Mealing <michael.mealing@it.gatech.edu>   *
     Mitra <mitra@pandora.sf.ca.us>                    *
     Cifford Neuman <bcn@isi.edu>                      *
     Alisa Hata <hata@cac.wasjington.edu>              *

       * add to mailing list www-talk@info.cern.ch

            Unfortunately   many  attendees   left   without
          filling in the roster sheet.
            

From marca@wintermute.ncsa.uiuc.edu  Thu Apr  1 23:08:14 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06660; Thu, 1 Apr 93 23:08:14 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17835; Thu, 1 Apr 1993 23:27:08 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24801
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 1 Apr 93 15:27:03 -0600
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA19565; Thu, 1 Apr 93 15:29:13 -0600
Date: Thu, 1 Apr 93 15:29:13 -0600
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304012129.AA19565@wintermute.ncsa.uiuc.edu>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re internet talk radio.....
In-Reply-To: <9304011240.AA02927@manuel.hpl.hp.com>
References: <9304011240.AA02927@manuel.hpl.hp.com>
X-Md4-Signature: cdaf392701c5e85c6f393c79fcf7cd51

Dave_Raggett writes:
> > NCSA Mosaic 0.9 or later, with a properly configured
> > audioPlayerCommand resource (metamail's "showaudio", by default), is
> > the assumed interface.
> 
> Great idea! It seems daft though to have to first down load the
> files before playing them. What we need is a smarter approach which
> concurrently retreives the audio data and pipes it into the audio
> player process.

Or alternately we need to harness packet audio/video into the
distributed hypermedia environment, so one can link to real-time
multicast feeds that are possibly kicked off on the remote system on
demand.  ??

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From dsr@hplb.hpl.hp.com  Fri Apr  2 10:49:14 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13647; Fri, 2 Apr 93 10:49:14 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03293; Fri, 2 Apr 1993 11:07:32 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 2 Apr 93 10:01:48 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA18094; Fri, 2 Apr 93 10:08:32 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304020908.AA18094@manuel.hpl.hp.com>
Subject: Re internet talk radio.....
To: www-talk@nxoc01.cern.ch
Date: Fri, 2 Apr 93 10:08:31 BST
Mailer: Elm [revision: 66.36.1.1]

Marc Andreessen responding to my comments:

>> Great idea! It seems daft though to have to first down load the
>> files before playing them. What we need is a smarter approach which
>> concurrently retreives the audio data and pipes it into the audio
>> player process.

> Or alternately we need to harness packet audio/video into the
> distributed hypermedia environment, so one can link to real-time
> multicast feeds that are possibly kicked off on the remote system on
> demand.  ??

> Marc

That would be fun! I recently attended a TCP/IP course given by
Jon Crowcroft (J.Crowcroft@cs.ucl.ac.uk) who told me that University
College London have been doing just this kind of thing.

They did live multicast audio to Europe of Bill Clinton's speech at
Silicon Graphics during his recent well publicised visit there. Thats
how I found out about the need for a 5 second fifo to avoid breaks.

A lot of work is going on in on multicast and we should hear results
soon. In the meantime I think that there is plenty you can do with
good old tcp and WWW audio replay on demand. The japanese telecoms
giant NTT have even demonstrated sending video via tcp, although this
does require some impressive video compression/decompression hardware
that will be a while coming to most workstations.

From dsr@hplb.hpl.hp.com  Fri Apr  2 18:46:58 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19990; Fri, 2 Apr 93 18:46:58 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18951; Fri, 2 Apr 1993 19:05:49 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 2 Apr 93 18:00:10 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA20689; Fri, 2 Apr 93 18:06:54 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304021706.AA20689@manuel.hpl.hp.com>
Subject: WWW access and ensuring confidentiality
To: www-talk@nxoc01.cern.ch
Date: Fri, 2 Apr 93 18:06:51 BST
Cc: sfk@hplb.hpl.hp.com
Mailer: Elm [revision: 66.36.1.1]

Here at Hewlett Packard, we need a way of preventing unauthorised
access to information, but want to take advantage of the WWW for
sharing information with colleagues.

Please give me your comments on our proposed solution.

I am working on a solution that makes use of UNIX's established
security mechanisms and making it easy for non-technical types
to manage things for themselves without the need to call out
the support staff.

Each web server can be run in two modes depending on a command line switch:

  Mode 1
  ======

    a)  all world readable files are accessible
    b)  systems in the .rhosts file are treated appropriately
    c)  all other files require a user name & password

  Mode 2
  ======

    a)  systems in the .rhosts file are treated appropriately
    b)  otherwise all files 

The Authorisation: field in HTTP2 is used to carry the username
and password, e.g.

    Authorisation: user fred:secret

Where "user" identifies the following as being username:password
which must refer to a valid user account on the host system. This
approach avoids the need for people to manage special configuration files.
We may also add a file similar to the .rhost file but specific to the web.

The browser keeps track of which system/protocol needs what user name/
password, and so only asks you once for each system per session. I am
also looking at using X11's interprocess communication facilities so
that multiple concurrent invokations of the browser can share the
same info to further minimise the pain.

The same approach is also used for our gateway from our closed subnet
to the rest of the world. This gateway relays tcp connections, but doesn't
accept requests to connect from the outside. I hence have to use ftp in
the passive mode.

In the future we will investigate more flexible approaches such as Kerberos
that avoid sending passwords in clear (unlike most UNIX apps such as ftp,
rlogin etc.).

Dave Raggett

Hewlett Packard Labs, Bristol, UK

    +44 272 228046
    dsr@hplb.hpl.hp.com

From mvanheyn@cs.indiana.edu  Fri Apr  2 19:36:36 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20915; Fri, 2 Apr 93 19:36:36 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16895; Fri, 2 Apr 1993 19:55:31 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA09149; Fri, 2 Apr 1993 12:55:29 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: WWW access and ensuring confidentiality 
In-Reply-To: Your message of "Fri, 02 Apr 1993 18:06:51 -0000."
             <9304021706.AA20689@manuel.hpl.hp.com> 
Date: Fri, 02 Apr 1993 12:55:28 -0500
Message-Id: <9145.733773328@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Dave_Raggett
>Here at Hewlett Packard, we need a way of preventing unauthorised
>access to information, but want to take advantage of the WWW for
>sharing information with colleagues.
>
>Please give me your comments on our proposed solution.
>
>I am working on a solution that makes use of UNIX's established
>security mechanisms and making it easy for non-technical types
>to manage things for themselves without the need to call out
>the support staff.

I've thought about implementing something like this, and I think
that's a reasonable starter solution.

(I'm sure you know all this already, but I'll mention it anyway...)

- If you want more than token security, passwords flying around the
  network in the clear is obviously a Bad Thing.
- Since the data is passed across the net in the clear, disclosure
  protection may or may not be attained; it depends whether this is
  going on a LAN or a WAN or what.

Kerberos type models are possible, but I don't think the current HTTP2
standard could work with kerberos (I believe this would require a
fundamental change in the request-response to something like
request-challenge-reply-response, which is a big change.  Or am I
recalling the changes to version 5 incorrectly?)

Ultimately, the general solution should be simple enough; since we're
already using MIME mail-like mechanisms for content identification,
once MIME and PEM are made interoperable (standards should be out
soon), you can have signed PEM (or PEM-like) requests and encrypted
responses.  There would be some trickiness, since the headers of the
response message are among what needs to be authenticated.  The bad
part is that PEM isn't here today, and may not be here any time
particularly soon.  But it's obviously the right solution in the long
run, particularly since the certification hierarchy would allow the
kind of legal mechanisms for non-deniability of origin and disclosure
protection that would be highly desirable for, say, a publisher to
make copyrighted works available via WWW for a modest fee.

Since I'm already posting to the list, anyone who is in the process of
trying to write a WWW server in perl may wish to glance at a brief
commentary in http://cs.indiana.edu/perl-server/intro.html that I
made; this includes some discussion of the design guidelines involved
in its creation (which are probably rather controversial) and the
code.  It's not code that you can just pop in and run on your machine,
but your friendly neighborhood perl hacker might find it interesting
to look at.

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
In fact, if you live in the USA, and you are not a Federal agency, you
shouldn't actually run PGP on your computer.
		- Phil Zimmermann

From Nathan.Torkington@vuw.ac.nz  Sun Apr  4 06:44:29 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05413; Sun, 4 Apr 93 06:44:29 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06803; Sun, 4 Apr 1993 07:03:38 +0200
Received: by kauri.vuw.ac.nz id AA06217
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Sun, 4 Apr 1993 17:03:31 +1200
Date: Sun, 4 Apr 1993 17:03:31 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304040503.AA06217@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: WWW Ideas

http://www.vuw.ac.nz:80/database/people/Nathan.Torkington/ideas/home.html

Currently I have:
 o Structured Queries in WWW
 o Integrating WAIS with WWW cleanly

Nat

From Nathan.Torkington@vuw.ac.nz  Sun Apr  4 06:47:44 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05440; Sun, 4 Apr 93 06:47:44 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08296; Sun, 4 Apr 1993 07:06:54 +0200
Received: by kauri.vuw.ac.nz id AA06275
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Sun, 4 Apr 1993 17:06:48 +1200
Date: Sun, 4 Apr 1993 17:06:48 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304040506.AA06275@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Re: WWW Ideas

That should be

http://www.vuw.ac.nz:80/databases/people/Nathan.Torkington/ideas/home.html

(note the "s" in databases ... *sigh*)

Nat.

From marca@wintermute.ncsa.uiuc.edu  Mon Apr  5 07:57:25 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15080; Mon, 5 Apr 93 07:57:25 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18226; Mon, 5 Apr 1993 08:16:38 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA00724
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 5 Apr 93 01:16:33 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11590; Mon, 5 Apr 93 01:14:36 -0500
Date: Mon, 5 Apr 93 01:14:36 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304050614.AA11590@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: NCSA Mosaic for X 0.12 released.
X-Md4-Signature: 8da987eb838bd6c7539b27c38853b6f6

Beta version 0.12 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is hereby released:

file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-source/xmosaic-0.12.tar.Z
                            .../xmosaic-binaries/xmosaic-sun.Z
                            .../xmosaic-binaries/xmosaic-sgi.Z
                            .../xmosaic-binaries/xmosaic-ibm.Z
                            .../xmosaic-binaries/xmosaic-dec.Z

This release of NCSA Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1 and GCC).
  DEC Ultrix.

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working
binaries, or development systems, are welcome.)  Documentation is
available online.

Changes since 0.11 include:

 o Files retrieved via binary transfer mode now get a file selection box
   for user-provided filename. 
 o Inlined image widths are now taken into account when formatting
   text & images together. 
 o Fixed trigger of server bug on some systems wrt freeing color cells. 
 o Inlined images work on 24-bit TrueColor servers now. 
 o GUI interface for mailing hotlist and window history lists. 
 o Support for <ol> (numbered lists). 
 o Better support for nested description lists. 
 o Support for <tt>, <b>, <i>, <em>, <strong>, <code>, <samp>,
   <kbd>, <var>, and corresponding resources italicFont, boldFont, and
   fixedFont. 
 o Better 8-bit cleanliness. 
 o Bug with inlined images as anchors at end of documents fixed. 
 o Compact description lists: <dl compact> causes first line of <dd>
   text to jump up on same line with <dt> if room exists. 
 o SGML representations of 8-bit ISO8859 characters now work. 
 o Fixed bugs with weird Lucida font metrics on DEC Alpha and a few
   other servers. 
 o Fixed coredump triggered by <li>'s outside of a list. 
 o Fixed coredumps on malformed URL's like telnet:machine.name. 
 o Fixed coredumps on malformed URL's like
   gopher:/gopher.uiuc.edu/. 
 o Various document types returned via WAIS searches are now
   detected (by extension only) and forked to viewers as appropriate. 
 o Fixed minor bug with disappearing whitespace. 
 o Fixed bug with extraneous newlines in description lists in very
   narrow windows. 
 o Fixed bug with erroneous description elements causing text to fall
   off the left side of the screen. 
 o Audio annotations on HP systems with audio hardware work now. 
 o Default SGI audio annotation quality is lower now, to decrease disk
   space usage. 
 o SCO Open Desktop support. 
 o Harris Nighthawk support. 
 o AIX 3.2 support for reading local directories. 
 o Minor bugfixes and cleanups. 

Thanks as usual to everyone who's been contributing comments and bug
reports -- keep 'em coming!

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From ajcole@cbl.leeds.ac.uk  Mon Apr  5 08:36:22 1993
Return-Path: <ajcole@cbl.leeds.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15351; Mon, 5 Apr 93 08:36:22 MET DST
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27704; Mon, 5 Apr 1993 08:55:37 +0200
Date:  4 Apr 93 20:02 +0100
From: Andrew J Cole <ajcole@cbl.leeds.ac.uk>
To: timbl <timbl@nxoc01.cern.ch>, www-talk <www-talk@nxoc01.cern.ch>
Cc: j-germuska@nwu.edu
Message-Id: <27434.9304041902(a)cbl.leeds.ac.uk>
Subject: Status of 2.02-beta (source and binary for sun4)

Tim,

I am a little confused over the status of httpd_2.02-beta, the sources on
info.cern.ch, and their relationship to httpd_2.02-beta and httpd_2.03-beta
(this is for a sun4).

Neither httpd_2.02-beta nor httpd_2.03-beta correctly return gif, mpeg or ps
files for me.

>-rwxrwxr-x  1 timbl    www       114688 Mar 17 17:01 httpd_2.02-beta
>-rwxrwxr-x  1 timbl    www       114688 Apr  1 18:00 httpd_2.03-beta

a typical error being ....

>HTFormat: Sorry, can't convert from application/postscript to www/present.<BODY>
><H1>Error 501</H1>
>
>  Sorry, can't convert from application/postscript to www/present.</BODY>

so I got the sources ....

>-rw-rw-r--  1 timbl    www       102293 Jan 27 14:47 WWWDaemon_0.9b.tar.Z
>-rw-rw-r--  1 timbl    www       145366 Mar 17 16:06 WWWDaemon_2.02-beta.tar.Z
>-rw-rw-r--  1 timbl    www       122575 Jan  6 16:39 WWWLibrary_1.1a.tar.Z
>-rw-rw-r--  1 timbl    www       168669 Mar 17 16:07 WWWLibrary_2.02-beta.tar.Z
>-rw-rw-r--  1 timbl    www        66881 Dec 14 12:13 WWWLineMode_1.4.tar.Z
>-rw-rw-r--  1 timbl    www        68803 Mar 16 15:27 WWWLineMode_2.0-alpha.tar.Z

and then unpacking WWWDaemon_2.02-beta.tar.Z, WWWLibrary_2.02-beta.tar.Z and
WWWLineMode_2.0-alpha.tar.Z which I had assumed would be sufficient to build
the current copy of httpd_2.02-beta (the dates on the tar files match nicely
with httpd_2.02-beta) ....

Running BUILD makes the sun4 Library then fails...

>mkdir ../../LineMode/sun4
>mkdir: ../../LineMode/sun4: File exists
>*** Error code 1 (ignored)
>(cd ../../LineMode/sun4; \
> make -f ../../All/Implementation/Makefile.product)
>make: Warning: Can't find `../../Specific/sun4/Makefile.include': No such file or directory
>Current working directory /usr/cblelcd/info.cern.ch/WWW/LineMode/sun4
>make: Fatal error in reader: ../../All/Implementation/Makefile.product, line 2: Read of include file `../../Specific/sun4/Makefile.include' failed
>Current working directory /usr/cblelcd/info.cern.ch/WWW/LineMode/sun4
>*** Error code 1
>make: Fatal error: Command failed for target `../../LineMode/sun4/www'

looking at Makefile.product ....

>% more All/Implementation/Makefile.product
>#       Make WWW product
>include ../../Specific/$(WWW_MACH)/Makefile.include
>include ../Implementation/CommonMakefile

its obvious that Specific needs changing to All ....

>mkdir ../../Daemon/sun4
>(cd ../../Daemon/sun4; \
> make -f ../../All/Implementation/Makefile.product)
>make: Fatal error: Don't know how to make target `../../Daemon/Implementation/HTDirRead.h'
>Current working directory /usr/cblelcd/info.cern.ch/WWW/Daemon/sun4
>*** Error code 1
>make: Fatal error: Command failed for target `../../Daemon/sun4/httpd'

missing file so after unpacking WWWDaemon_0.9b.tar.Z and overlaying with
WWWDaemon_2.02-beta.tar.Z ....

>(cd ../../Daemon/sun4; \
> make -f ../../All/Implementation/Makefile.product)
>cc -c -I../../Library/Implementation -DDEBUG  -o HTDaemonDIR.o -DRULES \
>-DRULE_FILE=\""/etc/httpd.conf"\" -DDIR_OPTIONS \
>        ../../Daemon/Implementation/HTDaemon.c
>cc -c -I../../Library/Implementation -DDEBUG  -DRULES -DRULE_FILE=\""/etc/httpd.conf"\" ../../Daemon/Implementation/HTRetrieve.c
>../../Daemon/Implementation/HTRetrieve.c: 37: Can't find include file HTDaemon.h
>*** Error code 2
>make: Fatal error: Command failed for target `HTRetrieve.o'
>Current working directory /usr/cblelcd/info.cern.ch/WWW/Daemon/sun4
>*** Error code 1
>make: Fatal error: Command failed for target `../../Daemon/sun4/httpd'

since I could not find HTDaemon.h and it doesnt appear to be necessary I
edited HTRetrieve.c to comment out the include file and everything then
recompiles ....

After this exercise the newly made httpd delivers both gif and Postscript
correctly but I am still seeing "Error 501" for .mpg files.

Have I missed something here?   

Andrew

From marca@wintermute.ncsa.uiuc.edu  Mon Apr  5 10:22:52 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16198; Mon, 5 Apr 93 10:22:52 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22153; Mon, 5 Apr 1993 10:42:04 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03164
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 5 Apr 93 03:42:00 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA12289; Mon, 5 Apr 93 03:44:10 -0500
Date: Mon, 5 Apr 93 03:44:10 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304050844.AA12289@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Mosaic 0.12 resources change
X-Md4-Signature: cf34bf094d5165a1debeb214c480a75f

People who already have Mosaic app-defaults files installed on their
systems should be aware that in 0.12 the class names for the following
resources:
        
        anchorColor
        visitedAnchorColor
        activeAnchorBG
        activeAnchorFG

...are no longer the resource names, capitalized.  

In other words, in your existing app-defaults file, you should
lower-case the first letter of each of AnchorColor,
VisitedAnchorColor, ActiveAnchorBG, and ActiveAnchorFG.  The 0.12
app-defaults files in the source distribution and in
/Mosaic/xmosaic-appdefaults on ftp.ncsa.uiuc.edu have this change
taken into account.

Sorry for the confusion,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From dsr@hplb.hpl.hp.com  Mon Apr  5 14:45:50 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18663; Mon, 5 Apr 93 14:45:50 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03942; Mon, 5 Apr 1993 15:04:48 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 5 Apr 93 13:58:56 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA02968; Mon, 5 Apr 93 14:05:43 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304051305.AA02968@manuel.hpl.hp.com>
Subject: Re WWW ideas
To: timbl@www3.cern.ch
Date: Mon, 5 Apr 93 14:05:40 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Dear Tim

What mechanism do you want to see for adding some simple extensions to HTML
e.g. to support forms and tables? As you know, I have thought quite a bit
about both of these. Perhaps an experimental browser and sample docs are
needed?

What happened to our ideas for having richer forms with support for
multiple fields? I enclose for you my proposal for extending HTML to 
support such forms. An outstanding issue is how you can escape special
characters in search string. I seem to remember that &#32; style
sgml character references are permitted, but this seems to be missing from
the current addressing bnf doc:

    http://info.cern.ch:80/hypertext/WWW/Addressing/BNF.html


The following is part of an exchange I had with Dan Connolly in January on
the modifications to HTML needed for such forms:

    1)  server sends whole form in response to a GET command

    2)  user interacts with client only to fill out form

    3)  user instructs client to send completed form to server

    4)  client sends form contents to server as a query string

    5)  server executes query and returns results

A smarter/more sophistocated system would include scripts as part of the
queryform document, which apply the constraints locally WITHOUT any network
delays. BUT that seems too open-ended and complex for us to put in HTML for
now!

Best wishes,

Dave Raggett

p.s. Did you get my suggestions for tables in HTML?


---A brief explanation of HTML forms:---------------------------------------

Forms are composed from the following elements

    o   checkbox (boolean)
    o   text field
    o   numeric field (integer and floating point)
    o   radio-button groups
    o   one-from-many menu
    o   n-from-m menu

These are specified with 4 new tags:

        <queryform>     appears between <head> and </head>
                        to indicate that this document is a query form, it
                        optionally specifies an href for processing the query

        <input>         boolean values, text, integer and floats

        <select>        radio buttons and selection menus

        <choice>        specifying alternatives for <select>

A formal definition is given later on as an extension to the DTD. An informal
definition is given first:

When the browser finds the <queryform> the user can fill in the form
and use it to make a request. The browser should offer a search button or
menu action. The <input> and <select> tags are then used to build the text
search string to send to the user.

The format for sending form contents back to the server has been chosen to
be backwards compatible with older HTTP servers. Thus the search string is
restricted to letters, digits, and chars from the string "$_@!%^&*()."

    QUERY  ::=  FIELD [+QUERY]
    FIELD  ::=  name@value | name@(VALUES)
    VALUES ::=  value [&VALUE]

e.g. "name@value+name@(value&value)

The use of brackets for multiple values allows servers to continue to treat
the characters &, ^, ! for logical operators.

The tags for form fields look like (more detail in the DTD):

    <input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH]>

    FIELDNAME is a unique identifier for this form
    FIELDTYPE ::= "boolean" | "text" | "date" | "integer" | "float"

    The [ ] brackets denote optional attributes.
    
The width can be optional, since the browser can support sideways scrolling
of the input field when the entry exceeds the current display width. For line
mode browsers, this requires a cursor addressing functionality, like CURSES.

The "date" format accepts a date in one of the following formats:

    o   12th June 1992
    o   June 12th 1992
    o   12/6/92
    0   6/12/92
    o   12-6-92
    o   12 Jun 92

The format is indifferent to MM/DD/YY or DD/MM/YY, and the form's text should
make it clear which is expected.

Multiple choice items need a richer structure, e.g.

    <select name=FIELDNAME type=CHOICETYPE [value=VALUE]>
        <choice>item 1
        <choice>item 2
        <choice>item 3
    </select>

    CHOICETYPE ::= "radio" | "single" | "multiple"

The choice initially shown is given by the value attribute for the <select>
token, defaulting to the first choice. The value returned is the item text
unless a "value" attribute is defined for that <choice>.

    <choice value=VALUETEXT>

I think that <a> tags should be permissible for <choice> text so that you can
provide further explanations upon request for each choice. If there isn't a
value attribute then the displayable text for the anchor would form part of
that choice in the obvious manner. The DTD includes a help parameter which
would permit browsers to offer help on form elements.

Forms generally involve additional ideas:

    a)  expressions and queries for output fields

    b)  edits (constraints) on input field values

    c)  dependencies between fields

These can all be handled by the server, albeit with a performance penalty as
perceived by the user.

It is important to be able to show the current values as currently being in
error (along with an explanation). For example you could have a form for
configuring a computer system, which gives you choices for the number of hard
and soft drives:

 ---------------------------------------------------------------------------
     *  Fixed Drive(s): [2 x 512 Gb disk]
     *  Soft Drive(s):  [1 x 1.44 Mb 3.5" floppy]

 (*) Error: you are only allowed a combined total of 2 fixed and soft drives
 ---------------------------------------------------------------------------

So we need to provide attributes to:

    a)  signify that the current choice is in error in some way
    b)  that a given choice is not currently permissible (grayed out)

This can be done with two attributes (both default to "yes"):

    ok="yes" | "no"             ;;  for <input> and <select>
    enabled="yes" | "no"        ;;  for <choice>

-----Additions to HTML DTD for QueryForms----------------------------------

<!-- uses Dan's definition for %URL, %inline and %text -->

<!-- The queryform element needs adding to the spec for HEAD -->

<!ELEMENT HEAD - - (TITLE ? & ISINDEX ? & QUERYFORM ? & NEXTID ? & LINK *
                        & BASE ? )>

<!ELEMENT QUERYFORM - 0 EMPTY]
<!ATTLIST QUERYFORM HREF %URL; #IMPLIED>

<!-- The following defines the <input> tag with the attributes:

    name    (required)
        unique name used to identify field to server

    type    (required)
        indicates type of input value (boolean, text, date, integer, float)

    width   (optional, defaults to 20)
        width for field in terms of average char width
        browsers should allow users to type up to this number of chars
        and no more (except for dealing with control keys e.g. backspace)

    value   (optional, defaults to null or "")
        initial value to display in the input field

    ok      (optional, defaults to yes)
        when no, signifies that the current value is in error.

    enabled (optional, default to yes)
        when no, prevents user from changing this field's value

    help    (optional, default provided by application)
        a URI which would provide explanatory information for this field
-->

<!ENTITY % url "CDATA" -- this is kind of a DTD macro >
<!ELEMENT input - O EMPTY>
<!ATTLIST input
    name ID #REQUIRED
    type (boolean|text|date|integer|float) #REQUIRED
    width NUMBER "20"
    value CDATA ""
    ok (yes|no) "yes"
    enabled (yes|no) "yes"
    help %URL; #IMPLIED
>

<!-- The following defines the <select> tag for selection menus -->

<!ENTITY SELECT - - (CHOICE)*>

<!ATTLIST select
    name ID #REQUIRED
    type (radio|single|multiple) #REQUIRED
    value PCDATA ""
    ok (yes|no) "yes"
    enabled (yes|no) "yes"
    help %URL; #IMPLIED    
>

<!-- The following defines the <choice> tag which is
        used to specify choices for the <select> tag  -->

<!ENTITY CHOICE - O (%text; | CHOICE)*>

<!ATTLIST choice
    value PCDATA "" #REQUIRED
    enabled (yes|no) "yes"
>


From mcclanah@dlgeo.cr.usgs.gov  Mon Apr  5 19:55:56 1993
Return-Path: <mcclanah@dlgeo.cr.usgs.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24305; Mon, 5 Apr 93 19:55:56 MET DST
Received: from sunl.cr.usgs.gov by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24530; Mon, 5 Apr 1993 20:15:11 +0200
Received: from dlgeo.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2)
	id AA12130; Mon, 5 Apr 93 13:15:04 CDT
Received: by dlgeo.cr.usgs.gov (5.4.1/1.34)
	id AA03620; Mon, 5 Apr 1993 13:17:48 -0500
Date: Mon, 5 Apr 1993 13:17:48 -0500
From: mcclanah@dlgeo.cr.usgs.gov
Message-Id: <9304051817.AA03620@dlgeo.cr.usgs.gov>
To: marca@ncsa.uiuc.edu
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Marc Andreessen's message of Mon, 5 Apr 93 01:14:36 -0500 <9304050614.AA11590@wintermute.ncsa.uiuc.edu>
Subject: NCSA Mosaic for X 0.12 released.

Kudos once again to the NCSA folks!!!  Two (or was it three) weeks ago
when Marc et al released Xmosaic 0.10 I ftp'd it and built it on my system,
hardly able to contain my excitement over the video capabilities. (I am
also interested in the audio stuff, but Data General Aviions don't
possess such)  It immediately puked when trying to display one of the
bitmaps, so I sent a trace back to Marc who passed it one to one
of their other programmers who recognized the problem as an 8 bit versus
24 bit TrueColor problem (because of the way 24 bit handles colors).
Well... in 0.12 that problem is resolved!  Most commercial products
don't offer that rapid of a response to bugs.

Keep up the great work, I am still beating my drum trying to
convince mgmt here that this is what we should be using for some
of the hypertext applications they are interested in around here.

Pat McClanahan		Internet:mcclanah@dlgeo.cr.usgs.gov
EROS Data Center 		 mcclanah@edc1.cr.usgs.gov
Sioux Falls, SD
605-336-4601

From TONYJ@scs.slac.stanford.edu  Mon Apr  5 20:54:42 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25188; Mon, 5 Apr 93 20:54:42 MET DST
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02115; Mon, 5 Apr 1993 21:13:57 +0200
Date: Mon, 5 Apr 1993 12:13 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: Re WWW ideas
To: dsr@hplb.hpl.hp.com
Cc: www-talk@nxoc01.cern.ch
Message-Id: <3435564452400CD1@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"dsr@hplb.hpl.hp.com"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

Dave Raggett writes....


>What mechanism do you want to see for adding some simple extensions to HTML
>e.g. to support forms and tables? As you know, I have thought quite a bit
>about both of these. Perhaps an experimental browser and sample docs are
>needed?

I would very much like to see both TABLES and FORMS implemented in HTML. I 
have a number of applications which could benefit greatly from the addition of 
these facilities. 

I like your specific proposals for TABLE and FORMS and think they should form 
the basis for discussion of extension of the HTML format in these areas.


>What happened to our ideas for having richer forms with support for
>multiple fields? I enclose for you my proposal for extending HTML to 
>support such forms. An outstanding issue is how you can escape special
>characters in search string. I seem to remember that &#32; style
>sgml character references are permitted, but this seems to be missing from
>the current addressing bnf doc:

I have previously suggested that we use the %nn (eg %32) syntax for special 
characters in search strings. (See my message to www-talk, 25-Feb-1993, subj: 
"Handling + in document searches") In reposonse to this note TimBL suggested 
this would be implemented in the next version of the WWWLibrary. I would 
certainly like to see this (or something giving equivalent functionality) 
documented in the HTTP documentation.

Tony Johnson


From wmperry@apricot.ucs.indiana.edu  Mon Apr  5 21:00:04 1993
Return-Path: <wmperry@apricot.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25294; Mon, 5 Apr 93 21:00:04 MET DST
Received: from apricot.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02363; Mon, 5 Apr 1993 21:19:17 +0200
Message-Id: <9304051919.AA02363@dxmint.cern.ch>
Received: by apricot.ucs.indiana.edu
	(5.65c/9.4jsm) id AA16527; Mon, 5 Apr 1993 14:19:15 -0500
Date: Mon, 5 Apr 1993 14:19:15 -0500
From: "William M. Perry" <wmperry@apricot.ucs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Cc: www-announce@nxoc01.cern.ch
Subject: New release of WWW Browser for emacs (.007beta) :)

Hello all,
   A new version of my WWW browser for emacs is now available.  I'll call
this .007beta for the lack of anything better. :)

   There are quite a few bug fixes in this release.  I'd like to thank the
following people for submitting bug reports/feeding my ego:

Larry Masinter 		<masinter@parc.xerox.com>
Marc Gemis 		<makke@wins.uia.ac.be>
Marc Andreessen 	<marca@ncsa.uiuc.edu>
Luis Miguel Silveira 	<lms@rle-vlsi.mit.edu>
Henry A. Rowley 	<har+@A.GP.CS.CMU.EDU>
Bob Cotton 		<bcotton@maestro.mitre.org>
Salil Deshpande 	<salil@kyle.eitech.com>
Jamie Zawinski 		<jwz@lucid.com>
Jay Glicksman 		<jay@eitech.eitech.com>
Steve Baumgarten 	<sbb@Panix.Com>
Erik Ostrom		<eostrom@nic.gac.edu>
Joe Germuska 		<j-germuska@nwu.edu>
paolo petta 		<paolo@mail4.ai.univie.ac.at>
Saul Youssef 		<youssef@ibm7.scri.fsu.edu>
Drew Burton 		<drb@MATH.AMS.ORG>

The source is available from moose.cs.indiana.edu in /pub/elisp/w3/  The
only file you'll need if you are upgrading from .004 is w3.el.  The
complete package you'll need to use w3-mode to its fullest is in w3.tar.Z.
This tar file contains ange-ftp, transparent.el, and a gopher browser,
authors are:
   ange-ftp: Andy Norman, ange@hplb.hpl.hp.com
 background: Joseph G. Keane <jk3k+@ANDREW.CMU.EDU>
transparent: Brian Tompsett, briant@spider.co.uk
     gopher: scott snyder <snyder@d0gsc.fnal.gov>
      forms: Johan Vromans (email unknown)

The start of a hypertext documentation tree is at:
http://moose.cs.indiana.edu:80/elisp/w3/docs.html.

-------------------------------------------------------------------------------
Things up & coming:
  news: link support
  support for logical styles <CITE>, etc
  font support for <EM>, <B>, etc styles
  ordered list handling
-------------------------------------------------------------------------------
Here is an excerpt from the changelog (since the last release):

Mon Apr  5 13:34:00 1993  William M. Perry  (wmperry@indiana.edu)
* v.007beta - second release
* Revamped local files - now use file:/ instead of nonstandard local:/
* Added better handling of definition lists.  (No support for Compact
  ones now though)

Fri Apr  2 10:28:08 1993  William M. Perry  (wmperry@indiana.edu)
* Definition lists now keep their zones/extents so they are highlighted
  correctly. 
* Fixed bug in <PRE> handling - left out a (goto-char (point-min))

Wed Mar 31 08:51:04 1993  William M. Perry  (wmperry@indiana.edu)
* Did work on resolving ./ & ../ links (only works for one level right
  now.  Will work on getting it recursive later.
* Changed data field in extents/zones to be (w3 . <type>) so I
  wouldn't grab a wrong item.
* Fixed a bug in title handling.  Left something out of an if
  statement and it would try to delete a region that (probably) didn't
  exist.
* Fixed bug in w3-follow-link (added a ':' to end of regexp).  Would
  cause it to screw up on a url like http.html.  Thanks to Erik Ostrom
  (eostrom@nic.gac.edu)
* Changed requires to autoloads where possible
* Wrapped require of transparent.el so it won't get loaded if in X
* Fixed bug in lemacs mouse links.
* Applied numerous patches from har@cs.cmu.edu & jwz@lucid.com to fix
  compilation problems with lemacs & epoch.

Tue Mar 30 15:05:01 1993  William M. Perry  (wmperry@indiana.edu)
* Added mouse support for following links in epoch & lucid emacs
  Store the link # in the data segment of the zone.  If mouse is
  clicked in a zone, extract the data, assoc it with w3-links-list and
  call w3-follow-link with it.  Hacky but works. :)
* Added (provide 'w3) for easier loading, etc.
* Fixed problems with epoch highlihting
* Fixed makefile problem (some files left out)

Sun Mar 28 13:04:12 1993  William M. Perry  (wmperry@indiana.edu)
* Added auto-viewing of ps/gif/jpg/etc files
* Added uncompression and gunzipping auto-recognition

Sat Mar 27 12:32:54 1993  William M. Perry  (wmperry@indiana.edu)
* v.004beta - first release
* Few changes to the parser
* Fixed PRE Handling so it parses out urls inside.
* Added handling of &#XXX to insert ascii value of XXX.

-- William M. Perry (wmperry@indiana.edu) --
If trees could scream, would we be so cavalier about cutting them
down? We might, if they screamed all the time, for no good reason.

From Nathan.Torkington@vuw.ac.nz  Tue Apr  6 09:28:26 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05810; Tue, 6 Apr 93 09:28:26 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12937; Tue, 6 Apr 1993 09:47:39 +0200
Received: by kauri.vuw.ac.nz id AA20978
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Tue, 6 Apr 1993 19:47:33 +1200
Date: Tue, 6 Apr 1993 19:47:33 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304060747.AA20978@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: WWW FAQ

I've made a first draft of a tentative FAQ that might get posted :-).
It is:

http://www.vuw.ac.nz:80/databases/people/Nathan.Torkington/ideas/www-faq.html

but be warned that Mosaic versions < 0.12 will not display nested
description lists correctly, so the output may (nay will) look odd
from 2/3 on.

Comments, feedback, &c appreciated.

Nat.

From timbl@www3.cern.ch  Tue Apr  6 14:14:26 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08480; Tue, 6 Apr 93 14:14:26 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15674; Tue, 6 Apr 1993 14:33:42 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01753; Tue, 6 Apr 93 14:31:34 +0100
Date: Tue, 6 Apr 93 14:31:34 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304061331.AA01753@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Escaped characters in search strings in HTTP
Cc: dsr@hplb.hpl.hp.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Tony, Dave, folks in general:

Characters otherwise not allowed in a URL SHALL be escaped using
the %nn notation, and ARE handled this way in the 2.0 WWW library
server and client.

This is is not just a suggestion! :-)

	Tim

(Tony wrote:
 

> I have previously suggested that we use the %nn (eg %32) syntax for  
special 

> characters in search strings. (See my message to www-talk,  
25-Feb-1993, subj: 

> "Handling + in document searches") In reposonse to this note TimBL  
> suggested
  ^^^^^^^^^
> this would be implemented in the next version of the WWWLibrary. I  
would 

> certainly like to see this (or something giving equivalent  
functionality) 

> documented in the HTTP documentation.
)

From timbl@www3.cern.ch  Tue Apr  6 17:31:48 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11161; Tue, 6 Apr 93 17:31:48 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04462; Tue, 6 Apr 1993 17:51:06 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02068; Tue, 6 Apr 93 17:48:56 +0100
Date: Tue, 6 Apr 93 17:48:56 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304061648.AA02068@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Improvements on HTML. 
Cc: dsr@hplb.hpl.hp.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



There have been a lot of improvements proposed for HTML.

	- Various forms of includion of graphics
	- Tables
	- Forms

I think we should get some concrete proposals for an HTML2 out
onto this list.  This would bring us closer to a DTD for the
new thing, which would allow everyone to go out and
implement it.

It is important that noon gets the feeling that the basic
HTML spec is shifting under their feet, so a new name for the
enhanced format might be useful. But not endless discussion of it.

The new format should of course be a superset of HTML.  The first
thing it should incldue is indefinite nesting of constructs
which is not allowed in HTML.

To kick off the discussion, I propose for the forms part the
following

FIELDS
======
<FIELD NAME="f1" FIELDTYPE=TEXT MAXLEN=40>     </FIELD>

This field could be inserted anywhere, including
inside lists and character emphasis, and so would pick up
the formatting from that.  Any contents of the field
would, in a basic form, represent a default value.

The fieldtype could default to text, but other values
could be for example INT, FLOAT, URI. The latter would
allow icons to be dropped in, or bookmarks pasted in,
for giving references to other documents.
Example:

<h2>Personal Details</h2>
<DL>
<DT>Name<DD><EM><FIELD NAME="nam" FIELDTYPE=TEXT  
MAXLEN=40></FIELD></EM>
<DT>Address<DD><FIELD NAME="adr" FIELDTYPE=TEXT MAX=200></FIELD>
<DT>Children<DD><FIELD NAME="kids" FIELDTYPE=INT> 0 </FIELD>
<DT>Publications<DD><FIELD NAME="pubs" FIELDTYPE=URI MAX=100></FIELD>
</DL>
Any other comments?
<PRE>
<FIELD NAME="cmt"></FIELD>
</PRE>

RADIO BUTTONS
=============

The radio button element could have exactly the same syntax as the
MENU list or for that matter LI or DIR.  Or even an attribute
RADIO on any of these existing ones?  Need a way of setting the  
default.

<RADIO>
<LI>Male
<LI DEFAULT>Female
</RADIO>

Tim BL
_________________________________________________________


BTW: 	If anyone has not voted as to the creation of the
	comp.infosystems.www newsgroup, remember to send a message
	to www-yes@msen.com or www-no@msen.com. Voting ends April 20.

From timbl  Tue Apr  6 21:51:06 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17526; Tue, 6 Apr 93 21:51:06 MET DST
Date: Tue, 6 Apr 93 21:51:06 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304061951.AA17526@ nxoc01.cern.ch >
To: unite@mailbase.ac.uk
Subject: Re: VT100 etc...
Cc: timbl, www-talk@nxoc01.cern.ch

Lonnie Mandigo sums up the problem well. Looking at
Lonnie's diagram, the top box in the top box looks
like, in our case, the WWW network access library.
In the bottom of the box are the vt100 client and
X client boxes -- why not add Windows and Mac clients?
That is, you don't HAVE to have another line between
the network access bit and the display software, it can
all be linked into the same program. As it is for
most WWW clients.

The interesting bit is the line down from the top
box to the bottom box, and this is especially relevant
when it represents a phone line.  Then the top box
becomes a gateway between the internet protocols in all
their glory and a special phone line protocol.
Then, the bottom box (the user's software) and the
top box (gateway or internet-connected client)
are basically the same except with the internet access
code unplugged and the phoneline acess code plugged in.
As you say, the display and access code are separated.

The requirements or the phone line protocol are that
it should be efficient, it should allow long transfers
to be stopped at short notice to make way for new ones,
and it should, preferably, look ahead to guess what the
user might want next, and transfer it while he is reading
what he has got.   This would take advantage of a reasonable
amount of cache disk space on the user's machine, if he has
it.  The ideal is to keep the phone line humming as it is
the bottleneck. The user browses around, with an apparently
very good response time. All the scrolling and such is done
locally so that is instant.

There is not as far as I know any existing public protocol
which does this.   If anyone knows of one, please say!
If anyone wants to [form a group to] define and implement
one, then why not.  I see this as an important step
toward getting the internet information world out to
everyone in schools and homes.

Tim Berners-Lee
WWW Project
CERN, Europe

From dsr@hplb.hpl.hp.com  Wed Apr  7 13:06:52 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28866; Wed, 7 Apr 93 13:06:52 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18865; Wed, 7 Apr 1993 13:25:55 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 7 Apr 93 12:19:52 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA25551; Wed, 7 Apr 93 12:26:43 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304071126.AA25551@manuel.hpl.hp.com>
Subject: Re Improvements on HTML
To: www-talk@nxoc01.cern.ch
Date: Wed, 7 Apr 93 12:26:40 BST
Cc: timbl@www3.cern.ch
Mailer: Elm [revision: 66.36.1.1]

In <9304061648.AA02068@www3.cern.ch> Tim says

> There have been a lot of improvements proposed for HTML.

>         - Various forms of includion of graphics
>         - Tables
>         - Forms

> I think we should get some concrete proposals for an HTML2 out
> onto this list.  This would bring us closer to a DTD for the
> new thing, which would allow everyone to go out and
> implement it.

Glad to hear you say it!

> The new format should of course be a superset of HTML.  The first
> thing it should include is indefinite nesting of constructs
> which is not allowed in HTML.

Some guidelines would be useful here, e.g. can you nest OL or UL in the
DT glossary text in a DL list, or what about OL within UL within a DL list? 
What level of nesting should browsers aim to show effectively?

For formal presentation as an elective Internet standard we should aim to
be as precise as possible, e.g. via accurate DTD's and a range of examples.
I there enclose a DTD fragment with my proposal for forms.

> To kick off the discussion, I propose for the forms part the
> following

> FIELDS
> ======
> <FIELD NAME="f1" FIELDTYPE=TEXT MAXLEN=40>     </FIELD>

Tim, er did you receive my message with a detailed suggestion for forms?

My practical experience with building hypertext/forms based interfaces
for sales staff etc. has shown the value of:

    o   to be able to freely embed fields in other
        textural or graphical backgrounds

    o   the need for fields with constrained types
        e.g. dates, booleans, integer ranges, free text, ...

    o   the need to initialise fields with default values

    o   the ability to highlight fields as being in error

    o   the ability to disable the field to prevent further change

    o   the need for one-from-many AND many-from-many menus

    o   giving authors control over the realisation of such menus
        e.g. radio buttons, drop down, and permanently visible lists

Fields showing derived values, (e.g. a total figure in an expenses claim),
and arbitrary constraints between different fields can be handled by the
server. In this way you avoid can the need for a scripting language.

If the user sets a field to an incorrect value, the ability to highlight
the field makes it practical to draw the user's attention to that field
with the implication that its value should be changed. An accompanying
error message can be given as part of the surrounding text.

Similarly, it is often the case that given certain settings of fields, that
other fields cannot be changed. To make this obvious you should change the
appearence of these fields. In my browser, I show fields with a darker colour
when they accept input and the lighter window background colour when they are
read-only. Clicking the mouse over a read-only field has no effect.

As an author I want control over how a selection menu appears. When there are
few choices, radio buttons or lists work well. When there are lots of
selection fields it is strongly desirable to be able to use drop-down
selections, which appear in the body of the form as a button and a box
showing the currently selected value(s) for that field. Clicking on the
button causes the list of possible choices to appear, with the current
selection highlighted in some way.

Essentially we need two tags, one for input fields and one for selections.
These should be able to be placed freely with other HTML tags, so that you
could embed fields in a preformatted text if you need tight control over
the appearence. You could also put input and (dropdown) selection fields in
glossary lists.


Input Fields:
============

These fields have the following attributes:

    o   field name - used to identify the field's value to the server

    o   field type - boolean, text, date, uri, integer, float

    o   field width (optional) giving maximum length of field value

    o   field status (optional) ok (the default), in error, read-only

    o   initial value (optional)


Selection Fields:
================

These fields have the following attributes:

    o   field name - used to identify the field's value to the server

    o   field type - one-from-many or many-from-many

    o   field appearence (optional) radio, list, drop-down

    o   field status (optional) ok (the default), in error, read-only

The field appearence is a hint to the browser of how the author intends the
field to be displayed. For a drop-down field it would also be desirable to
be able to suggest the maximum size for displaying current selections,
particularly with many-from-many fields.

The set of possible choices can be specified as Tim points out with the
<LI> tag without the need for a new tag.

Here is my suggested DTD for the <input> and <select> tags. I prefer
these names as they seem more verb-like and appropriate than <field>
and <radio>.

<!-- INPUT tag

    o   The field name and type are required.

    o   The width, status and value attributes are optional.

    o   Boolean fields have values "yes" or "no"

    o   Date fields have values matching:

            "19th January 1992"
            "19 Jan 92"
            "19 Jan 92"
            "19/1/92"   with '/' or '-' as separators
            "1/19/92"

    o   URL fields have values corresponding to existing standards
        for universal resource locators

    o   values should be enclosed on "quotes"
-->

<!ELEMENT INPUT - O EMPTY>

<!ATTLIST INPUT
    name ID #REQUIRED
    type (boolean|text|date|url|integer|float) #REQUIRED
    width NUMBER "20"
    status (ok|error|frozen) "ok"
    value CDATA ""
>

<!-- SELECT tag

    o   The field name and type are required.

    o   The showas, width, status and value attributes are optional

    o   selected values are indicated with the LI tag
-->

<!ENTITY SELECT - - (LI)*>

<!ATTLIST SELECT
    name ID #REQUIRED
    type (single|multiple) #REQUIRED
    showas (radio|list|dropdown) "radio"
    width NUMBER "20"
    status (ok|error|frozen) "ok"
>

<!-- LI tag

    When the LI tag appears inside a <SELECT> ... </SELECT>
    the text following the LI tag is treated as a possible choice
    (up to the next LI tag or the terminating end-select tag).

    The LI tag is extended to indicate whether this alternatative
    has been selected or not, e.g.

        <LI SELECTED> versus <LI>

    Strictly speaking I am not sure if this is valid SGML, you should
    probably always give an attribute value as in <li selected=yes>
    but this seems excessive ...
-->    

<!ELEMENT LI - O EMPTY>

<!ATTLIST LI
    selected (yes|no) "no">


From dsr@hplb.hpl.hp.com  Wed Apr  7 13:58:25 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29264; Wed, 7 Apr 93 13:58:25 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06038; Wed, 7 Apr 1993 14:17:37 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 7 Apr 93 13:11:46 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA25570; Wed, 7 Apr 93 13:18:39 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304071218.AA25570@manuel.hpl.hp.com>
Subject: Re  VT100 etc...
To: timbl@nxoc01.cern.ch
Date: Wed, 7 Apr 93 13:18:37 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

In  <9304061951.AA17526@ nxoc01.cern.ch > Tim makes the case for
WWW browsers that work effectively over phone lines.

It also seems to me that we should revisit the specs for HTRQ and
the HTTP Mime headers to boost network performance via compression.

Tim says:

> The requirements or the phone line protocol are that
> it should be efficient, it should allow long transfers
> to be stopped at short notice to make way for new ones,
> and it should, preferably, look ahead to guess what the
> user might want next, and transfer it while he is reading
> what he has got.   This would take advantage of a reasonable
> amount of cache disk space on the user's machine, if he has
> it.  The ideal is to keep the phone line humming as it is
> the bottleneck. The user browses around, with an apparently
> very good response time. All the scrolling and such is done
> locally so that is instant.

> There is not as far as I know any existing public protocol
> which does this.   If anyone knows of one, please say!
> If anyone wants to [form a group to] define and implement
> one, then why not.  I see this as an important step
> toward getting the internet information world out to
> everyone in schools and homes.

Are you familiar with the standard for Compressed TCP/IP Headers for
Low-Speed Serial Links, RFC1144? This cuts the headers down to an
average of 3 bytes and is both efficient and simple to implement
(about 250 lines of C). It was motivated by the need to get good
response times when using telnet over phone lines running from
300 to 19,200 bps. It is designed to increase line efficiency
while offering an under 200 millisecond response time for character
echo. For a 9600 bps line there is no point in increasing packet size
longer than 200 bytes. Increasing the maximum packet size to 576 bytes
increases the average delay by 188% while throughput increases by 3%.

The complete Berkely Unix implementation of cslip is available by
anonymous ftp from ftp.ee.lbl.gov as "cslip.tar.Z". I expect versions are
also available from PC software vendors, e.g. Distinct of Saratoga CA who
can be contacted at mktg@distinct.com (if not we should press them to
implement cslip right away!). Smart IP implementations also open and close
the phone line intelligently - so you don't hang onto an expensive long
distance line a moment longer than you need to.

The next step is to devise a www browser which offers look-ahead (under
user control via a preferences menu of course!). This would need to take
into account available resources (disk, memory, line costs) to decide which
references to prefetch. I, for one, would hate the browser to prefetch
megabytes of postscript and jpeg files! This shows the need to check file
size first using the appropriate methods, and underlines the need for
HTTP2 servers to supply a Length: field with document headers.

Finally www servers should offer compressed versions of documents. I have
looked through the MIME spec and the appropriate thing seems to be:

 a) documents are returned with an attribute specifying the kind
    of compression

        Content-Type: text/html; compression=Z
        Content-Transfer-Encoding: 8BIT

 b) Browsers can request compression with the HTRQ field

        Accept-Encoding: compression=Z

Where "Z" stands for the standard compress/uncompress utilities.
Some alternatives could be "z" for gzip, and "lzh", "zip" for the PC.

What do you think?

Dave Raggett

From timbl@www3.cern.ch  Thu Apr  8 16:44:39 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20307; Thu, 8 Apr 93 16:44:39 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10792; Thu, 8 Apr 1993 17:04:01 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03714; Thu, 8 Apr 93 17:01:52 +0100
Date: Thu, 8 Apr 93 17:01:52 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304081601.AA03714@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: mitra@pandora.sf.ca.us (Mitra)
Subject: Re: URL of URL document
Cc: uri@bunyip.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


The Internet Draft on URLs as ammended at the 26th IETF is on

	ftp://info.cern.ch/pub/ietf/url4.ps

The only reason it isn't in the ID directory yet is that I haven't
made a plain text RFC-style version yet.  But I think I have figured
out how to, I just have to borrow my wife's laptop again for a  
moment.  ;-)     It has been OKd by the RFC editor.

Tim

From jackson@stsci.edu  Thu Apr  8 19:17:10 1993
Return-Path: <jackson@stsci.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22677; Thu, 8 Apr 93 19:17:10 MET DST
Received: from stsci.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04319; Thu, 8 Apr 1993 19:36:31 +0200
Received: Thu, 8 Apr 93 13:36:29 EDT from MARIAN.STSCI.EDU (kaos.stsci.edu) by stsci.edu (4.1)
Received: Thu, 8 Apr 93 13:36:26 EDT by kaos.stsci.edu (4.1)
Date: Thu, 8 Apr 93 13:36:26 EDT
From: Bob Jackson <jackson@stsci.edu>
Message-Id: <9304081736.AA20543@MARIAN.STSCI.EDU>
To: www-talk@nxoc01.cern.ch
Subject: WWW Information Discovery Tools
Reply-To: jackson@stsci.edu

In comparing WWW vs Gopher and WAIS, I  admit
that WWW is a more powerful data representation model.

But, its ability to discover information is only as good as 
the links are and the links are made by hand.

Gopher and WAIS have global information discovery tools 
which know more than any one person does about available
resources, e.g.,

	WAIS's directory-of-servers
	Gopher's Veronica
	Gopher's ts/tb or jughead

and which are created by software.

Is anyone working on similar tools for WWW?


From wmperry@guava.ucs.indiana.edu  Thu Apr  8 19:40:15 1993
Return-Path: <wmperry@guava.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22979; Thu, 8 Apr 93 19:40:15 MET DST
Received: from guava.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AB08392; Thu, 8 Apr 1993 19:59:36 +0200
Message-Id: <9304081759.AB08392@dxmint.cern.ch>
Received: by guava.ucs.indiana.edu
	(5.65c/9.4jsm) id AA03714; Thu, 8 Apr 1993 12:59:31 -0500
Date: Thu, 8 Apr 1993 12:59:31 -0500
From: "William M. Perry" <wmperry@guava.ucs.indiana.edu>
To: jackson@stsci.edu
Cc: www-talk@nxoc01.cern.ch
Subject: Re: WWW Information Discovery Tools
In-Reply-To: <9304081736.AA20543@MARIAN.STSCI.EDU>
References: <9304081736.AA20543@MARIAN.STSCI.EDU>

Bob Jackson writes:
>In comparing WWW vs Gopher and WAIS, I  admit
>that WWW is a more powerful data representation model.
>
>But, its ability to discover information is only as good as 
>the links are and the links are made by hand.
>
>Gopher and WAIS have global information discovery tools 
>which know more than any one person does about available
>resources, e.g.,
>
>	WAIS's directory-of-servers
>	Gopher's Veronica
>	Gopher's ts/tb or jughead
>
>and which are created by software.
>
>Is anyone working on similar tools for WWW?

  Well, right now it would be pretty trivial to modify my emacs browser to
follow _every_ link it finds and record it.  Only problem would be in
keeping it from getting in an infinite loop, but that wouldn't be too hard.
Problem would be disk space & CPU time.

  Once I get the browser stable, I can work on something like this - unless
someone else wants to work on it in the meantime.  Might be more
stable/faster if written in C though. :)  But then what isn't?

  What type of format would the output have to be in?  It would be very
easy to spit out "URL :: TITLE" into a file.

-- William M. Perry (wmperry@indiana.edu) --
'When you look long into the Abyss, the Abyss also looks into you.'
    - Nietzsche

From marca@wintermute.ncsa.uiuc.edu  Thu Apr  8 19:42:59 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23028; Thu, 8 Apr 93 19:42:59 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08611; Thu, 8 Apr 1993 20:02:21 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA01589
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 8 Apr 93 13:02:19 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA27578; Thu, 8 Apr 93 13:04:29 -0500
Date: Thu, 8 Apr 93 13:04:29 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304081804.AA27578@wintermute.ncsa.uiuc.edu>
To: jackson@stsci.edu
Cc: www-talk@nxoc01.cern.ch
Subject: WWW Information Discovery Tools
In-Reply-To: <9304081736.AA20543@MARIAN.STSCI.EDU>
References: <9304081736.AA20543@MARIAN.STSCI.EDU>
X-Md4-Signature: f88a5674b70113dee9b34d4d641ff6bc

Bob Jackson writes:
> In comparing WWW vs Gopher and WAIS, I  admit
> that WWW is a more powerful data representation model.
> 
> But, its ability to discover information is only as good as 
> the links are and the links are made by hand.
> 
> Gopher and WAIS have global information discovery tools 
> which know more than any one person does about available
> resources, e.g.,
> 
> 	WAIS's directory-of-servers
> 	Gopher's Veronica
> 	Gopher's ts/tb or jughead
> 
> and which are created by software.
> 
> Is anyone working on similar tools for WWW?

Yup -- they're called Gopher and WAIS.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Thu Apr  8 19:52:26 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23261; Thu, 8 Apr 93 19:52:26 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11728; Thu, 8 Apr 1993 20:11:48 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02147
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 8 Apr 93 13:11:45 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:jackson@stsci.edu id AA27614; Thu, 8 Apr 93 13:13:56 -0500
Date: Thu, 8 Apr 93 13:13:56 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304081813.AA27614@wintermute.ncsa.uiuc.edu>
To: jackson@stsci.edu, www-talk@nxoc01.cern.ch
Subject: WWW Information Discovery Tools
In-Reply-To: <9304081804.AA27578@wintermute.ncsa.uiuc.edu>
References: <9304081736.AA20543@MARIAN.STSCI.EDU>
	<9304081804.AA27578@wintermute.ncsa.uiuc.edu>
X-Md4-Signature: 2600e0962e9a2c4c04f4f816f45fab75

Marc Andreessen writes:
> Bob Jackson writes:
> > In comparing WWW vs Gopher and WAIS, I  admit
> > that WWW is a more powerful data representation model.
> > 
> > But, its ability to discover information is only as good as 
> > the links are and the links are made by hand.
> > 
> > Gopher and WAIS have global information discovery tools 
> > which know more than any one person does about available
> > resources, e.g.,
> > 
> > 	WAIS's directory-of-servers
> > 	Gopher's Veronica
> > 	Gopher's ts/tb or jughead
> > 
> > and which are created by software.
> > 
> > Is anyone working on similar tools for WWW?
> 
> Yup -- they're called Gopher and WAIS.

Actually, my first answer was a little too cute for its own good.  The
real answer is that we (for one) are working on what could be termed
similar tools for wide-range hypermedia resource discovery, but it's
too early to tell how much we're going to be able to do or how it's
going to turn out, so there's not much else I can say about it at the
moment....

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From TONYJ@scs.slac.stanford.edu  Thu Apr  8 22:25:51 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26320; Thu, 8 Apr 93 22:25:51 MET DST
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24596; Thu, 8 Apr 1993 22:45:12 +0200
Date: Thu, 8 Apr 1993 13:44 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: WWW Information Discovery Tools
To: wmperry@guava.ucs.indiana.edu
Cc: www-talk@nxoc01.cern.ch
Message-Id: <9C69093772A094D1@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"wmperry@guava.ucs.indiana.edu"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

William M. Perry (wmperry@indiana.edu) writes:

>  Well, right now it would be pretty trivial to modify my emacs browser to
>follow _every_ link it finds and record it.  Only problem would be in
>keeping it from getting in an infinite loop, but that wouldn't be too hard.
>Problem would be disk space & CPU time.

Unfortunately I don't think infinite loops is the only problem to be solved. 
For example we have databases of Physics Publications accessable via the web, 
and cross-referenced for citations. This databases contain ~300,000 entries. A 
robot, even if it is smart enough to not get into a loop, could spend many days 
roaming this one database trying to find all the entries. One way around that 
would be to have a list of places where the robot should not look, but finding 
this list would itself be a time consuming task. 

Conversly there are many interesting documents that can only be accessed by 
giving a keyword, making it difficult for a robot to discover these documents 
at all.  

>  Once I get the browser stable, I can work on something like this - unless
>someone else wants to work on it in the meantime.  Might be more
>stable/faster if written in C though. :)  But then what isn't?
>
>  What type of format would the output have to be in?  It would be very
>easy to spit out "URL :: TITLE" into a file.

If anyone does solve the problems and generate a "URL :: TITLE" list (possibly 
a few other fields such as last modified date would be useful too) I would be 
happy to try to make the information available through the database we have 
interfaced to WWW.

Tony Johnson


From putz@parc.xerox.com  Fri Apr  9 00:12:09 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27682; Fri, 9 Apr 93 00:12:09 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24059; Fri, 9 Apr 1993 00:31:31 +0200
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11685>; Thu, 8 Apr 1993 15:31:10 PDT
Received: by spoggles.parc.xerox.com id <2445>; Thu, 8 Apr 1993 15:31:08 -0700
Date: 	Thu, 8 Apr 1993 15:30:53 PDT
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: WWW Information Discovery Tools
In-Reply-To: <9C69093772A094D1@SCS.SLAC.STANFORD.EDU>
To: www-talk@nxoc01.cern.ch
Message-Id: <93Apr8.153108pdt.2445@spoggles.parc.xerox.com>

Mapping out Web-space is harder than you think.
Not all infinite link chains are loops.  For example,
I have a WWW server that uses links to set search parameters,
so infinite sequences like the following are possible:

      Change maximum matches from 5 to: 2[1], 15[2], 30[3]
...
      Change maximum matches from 30 to: 5[1], 15[2], 40[3], 80[4]
...
      Change maximum matches from 80 to: 5[1], 40[2], 90[3], 180[4]
...
      Change maximum matches from 180 to: 5[1], 90[2], 190[3], 380[4]

From Nathan.Torkington@vuw.ac.nz  Fri Apr  9 00:36:19 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28023; Fri, 9 Apr 93 00:36:19 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02227; Fri, 9 Apr 1993 00:55:39 +0200
Received: by kauri.vuw.ac.nz id AA01179
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 9 Apr 1993 10:55:32 +1200
Date: Fri, 9 Apr 1993 10:55:32 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304082255.AA01179@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Bob Jackson's message <9304081736.AA20543@MARIAN.STSCI.EDU>
Subject: WWW Information Discovery Tools

Bob Jackson writes:

> 	WAIS's directory-of-servers
> 	Gopher's Veronica
> 	Gopher's ts/tb or jughead
> 
> Is anyone working on similar tools for WWW?

First of all -- the WAIS directory of servers differs from the others
in that Veronica and archie (which you didn't mention but should have)
are both automated.  Listing on the directory of servers is by
registration only -- the d.o.s doesn't search for machines that accept
connections at port 210 or anything like that.

The decision should be made whether we should have a registration
process for WWW -- a central page of servers that could then be fed to
a WWW version of archie/veronica to provide a list of titles/URLs.
Part of the registration process might be keeping track of the
"too-dense" sections and keeping the archie/veronica away from them.

Check out
	http://www.vuw.ac.nz:80/databases/people/Nathan.Torkington/ideas/reggie.html

for my musings on the subject.

Nat

From Nathan.Torkington@vuw.ac.nz  Fri Apr  9 00:45:20 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28126; Fri, 9 Apr 93 00:45:20 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02785; Fri, 9 Apr 1993 01:04:38 +0200
Received: by kauri.vuw.ac.nz id AA01375
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Fri, 9 Apr 1993 11:04:33 +1200
Date: Fri, 9 Apr 1993 11:04:33 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304082304.AA01375@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: HTML editor wishlist ...

I've got a pre-alpha Tcl/Tk based editor for HTML written, and this is
my current wishlist for it ... if you have other desires, please let
me know.

The program should ...
: generate display of what it might look like through a browser
: reformat to tidy up the display
: remember internal links to use for link destinations
: have a couth directory browser in the load/save options
: have hotkeys for most everything 
: be able to insert predefined structures ("a list") which are
  automatically filled in, and terminated on a hotkey sequence
: be able to fork and display/edit two pages simultaneously

Nat

From guido@cwi.nl  Fri Apr  9 01:15:46 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28377; Fri, 9 Apr 93 01:15:46 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12374; Fri, 9 Apr 1993 01:35:09 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA14742 (5.65b/3.8/CWI-Amsterdam); Fri, 9 Apr 1993 01:35:06 +0200
Received: by voorn.cwi.nl with SMTP
	id AA15021 (5.65b/3.8/CWI-Amsterdam); Fri, 9 Apr 1993 01:35:05 +0200
Message-Id: <9304082335.AA15021=guido@voorn.cwi.nl>
To: www-talk@nxoc01.cern.ch
Subject: Re: WWW Information Discovery Tools 
In-Reply-To: Your message of "Thu, 08 Apr 1993 13:36:26 MDT."
             <9304081736.AA20543@MARIAN.STSCI.EDU> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Fri, 09 Apr 1993 01:35:05 +0200
Sender: Guido.van.Rossum@cwi.nl

A few months ago I wrote a simple robot that roamed the net just like
you propose.  I *think* I've just redistributed my message describing
it to the group again (this mail software plays foul tricks upon me
:-).  Since the net has grown a lot since then I might run it again
and see what problems it will run into these days.  I did discover or
think of and remedy the problems with a simple-minded approach that
were mentioned on the list this time.

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From guido@cwi.nl  Fri Apr  9 01:19:28 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28406; Fri, 9 Apr 93 01:19:28 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14885; Fri, 9 Apr 1993 01:38:51 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA14959 (5.65b/3.8/CWI-Amsterdam); Fri, 9 Apr 1993 01:38:49 +0200
Received: by voorn.cwi.nl with SMTP
	id AA15043 (5.65b/3.8/CWI-Amsterdam); Fri, 9 Apr 1993 01:38:47 +0200
Message-Id: <9304082338.AA15043=guido@voorn.cwi.nl>
Subject: Re: strategy for HTML spec? 
To: www-talk@nxoc01.cern.ch
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Fri, 09 Apr 1993 01:38:46 +0200
From: Guido van Rossum <Guido.van.Rossum@cwi.nl>

[This is the message I intended to redisatribute to the list,
describing my roaming robot.  Maybe I should make the results of this
available as a searchable HTML document?  --Guido]

>I could easily write a robot which would roam around the Web (perhaps
>stochastically?), and verify the html, using sgmls.  Then, whenever
>I come across something that's non-compliant, I could automatically
>send mail to wwwmaster@sitename.  No one would have to annoy anyone else
>about whether or not they've verified their HTML; a program would annoy
>them automatically.

I have written a robot that does this, except it doesn't check for
valid SGML -- it just tries to map out the entire web.  I believe I
found roughly 50 or 60 different sites (this was maybe 2 months ago --
I'm sorry, I didn't save the output).  It took the robot about half a
day (a saturday morning) to complete.

There were several problems.

First, some sites were down and my robot would spend a considerable
time waiting for the connection to time out each time it found a link
to such a site.  I ended up remembering the last error from a site and
skipping sites that were obviously down, but there are many different
errors you can get, depending on whether the host is down,
unreachable, doesn't run a WWW server, doesn't recognize the document
address you want, or has some other trouble (some sites were going up
and down while my robot was running, causing additional confusion).

Next, more importantly, some sites have an infinite number of
documents.  There are several causes for this.

First, several sites have gateways to the entire VMS documentation (I
have never used VMS but apparently the VMS help system is a kind of
hypertext).  While not exactly infinite the number of nodes is *very*
large.  Luckily such gateways are easily recognized by the kind of
pathname they use, and VMS help is unlikely to contain pointers to
anything except more VMS help, so I put in a simple trap to stop
these.

Next, there are other gateways.  I can't remember whether I
encountered a Gopher or WAIS gateway, but these would have even worse
problems.

Finally, some servers contain bugs that cause loops, by referencing to
the same document with an ever-growing path.  (The relative path
resolving rules are tricky, and I was using my own www client which
isn't derived from Tim's, which made this more severe, but I have also
found occurrences reproducible  with the CERN www client.)

Although I didn't specifically test for bad HTML, I did have to parse
the HTML to find the links, and found occasional errors.  I believe
there are a few binaries, PostScript and WP files that have links to
them, which take forever to fetch.  There were also various
occurrences of broken addresses here and there -- this was a good
occasion for me to debug my www client library.

If people are interested, I could run the robot again and report a
summary of the results.

I also ran a gopher robot, but after 1600 sites I gave up...  The
Veronica project in the Gopher world does the same and makes the
results available as a database, although the last time I tried it the
veronica server seemed too overloaded to respond to a simple query.

If you want source for the robots, the're part of the Python source
distribution: ftp to ftp.cwi.nl, directory, pub/python, file
python0.9.8.tar.Z.  The robot (and in fact my entire www and gopher
client library) is in the tar archive in directory python/demo/www.
The texinfo to html conversion program that I once advertized here is
also there.  (I'm sorry, you'll have to built the python interpreter
from the source before any of these programs can be used...)
Note that my www library isn't up with the latest HTML specs, this is
a hobby project and I neede my time for other things...

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From tom%begbick.law.cornell.edu@router.mail.cornell.edu  Fri Apr  9 11:20:50 1993
Return-Path: <tom%begbick.law.cornell.edu@router.mail.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03377; Fri, 9 Apr 93 11:20:50 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28218; Fri, 9 Apr 1993 11:40:13 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160601(3)>; Fri, 9 Apr 1993 05:40:06 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA04206; Fri, 9 Apr 93 05:32:28 EDT
Date: Fri, 9 Apr 1993 05:32:28 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9304090932.AA04206@begbick.law.cornell.edu.law.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Resource discovery and the Web

Folks:
     Lawyers and legal scholars have for several years now used
advanced resource discovery tools called 'research assistants' and
'librarians'. While these are also prone to going into infinite loops,
they do incorporate fairly sophisticated natural-language recognition
capability and are marginally cheaper to develop and maintain than software ;-).

     Seriously, though, there are important aspects of resource
discovery best left to humans, considerations like 'relevance to task
at hand' and 'degree of relatedness to present document holdings' and
'reputation of source author'.  Of course, leaving these things to
human judgment means that you have to be at least slightly willing to
accept the judgment of the human involved...and that you probably want
that human to have at least some automated tools.

    What has in fact emerged in our field is an informal system of
registration similar to what someone proposed in an earlier message.
At the moment, there are two sites which maintain Net 'kiosks'
focussed on legal information (ours and Washington and Lee).  One of
these (ours) maintains a mailing list which is solely for the purpose
of communicating the discovery of or need for new Net-based legal
information. There are also a couple of well-known lists for
legal-tech and law-library people on which such offers and needs
appear regularly.  Also important to us -- but not yet in place -- is
a system for registering 'works in progress'.  Much of what is most
useful to us at present involves marking up existing public-domain
documents of some size (say the Internal Revenue Code); there is a
rather limited set of documents involved and everyone in the field
would I imagine prioritize them in roughly the same way, so there is a
great chance of duplication of effort if work-in-progress is not
communicated in some way.

Might we not do the same thing for the Web?  I plan to put together a
'law page' roughly paralleling what we've done with our Gopher site
soon, and put it together in such a way that it could be partitioned
off to other sites and other editors by sub-field as it grows.  To be
truthful, I'm also anxious to pass off the maintenance of this
information to others with more substantive legal expertise as quickly
as possible. I'm even less capable of judging the quality of legal
information than I am of writing software, and moreover I get paid to
do software...

Regards,
Tb.

Thomas R. Bruce
tom@law.mail.cornell.edu

From mike@fionn.lbl.gov  Fri Apr  9 17:31:34 1993
Return-Path: <mike@fionn.lbl.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07232; Fri, 9 Apr 93 17:31:34 MET DST
Received: from fionn.lbl.gov by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01483; Fri, 9 Apr 1993 17:50:57 +0200
Received: by fionn.lbl.gov (4.1/1.39)
	id AA07762; Fri, 9 Apr 93 08:50:53 PDT
Message-Id: <9304091550.AA07762@fionn.lbl.gov>
From: mike@fionn.lbl.gov (Michael Helm)
Date: Fri, 9 Apr 1993 08:50:53 PDT
Reply-To: mike@fionn.lbl.gov
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: www-talk@nxoc01.cern.ch
Subject: httpd-2.03, puzzle

I've been using the httpd-0.9 daemon on a Sun running SunOS 4.1.3.  I
need to run the daemon on another platform for which only httpd-2.x
daemons are available, so I thot I'd give that revision level a try on
the Sun.  I tried both the 2.02 & 2.03 daemons on the Sun.  I can't
get them to do anything useful.  Here's is what the daemon tells me :

Daemon: net read returned 28, errno=0 New anchor 24040 has hash 76 and
address `/var/adm/www/test.html' HTAccess: loading document
/var/adm/www/test.html HTFile: can't stat //WWW///var/adm/www/test.html
FTP: Looking for /var/adm/www/test.html HTTPAccess: Can't find internet
node name `'. HTAccess: Can't access `/var/adm/www/test.html' IP: PASSIVE
socket 0 assumed from inet daemon Daemon: Reading socket 0 from host
128.3.128.60 Log: Fri Apr 9 14:46:39 1993 128.3.128.60 GET
/var/adm/www/test.html HTAccess: Opening
`//WWW///var/adm/www/test.html' gives -1 TCP: Local host name is inti TCP:
Error 13 in `errno' after call to FTP file load() failed. Permission denied
Daemon: Socket 0 disconnected by peer

This is the real address of the document on the daemon's file system:
/var/adm/www/test.html

Why did it manufacture this garbage? : //WWW///var/adm/www/test.html

I looked at the source code for 2.02 but it didn't seem to match
up with what I saw happening, or else (or also) I didn't understand it.
Perhaps it's irrelevant, because I couldn't get this material to
compile so it is probably not what was used to compile the
daemon binaries available.  I also couldn't find anything in the
online documentation that differed from the treatment of the
earlier httpd.

This is the map file I used:
map / /test.html
map /*  /var/adm/www/*
pass /var/adm/www/*
fail *

I have this in /etc/httpd.conf also.

Any advice?  If you respond, please cc me directly, I'm not sure
I'm on this mailing list yet.

Thanks,
Michael Helm  (mike@fionn.lbl.gov)
LBL

From mcrae@lib.ucsf.edu  Fri Apr  9 21:40:52 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11210; Fri, 9 Apr 93 21:40:52 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09132; Fri, 9 Apr 1993 22:00:15 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA04176; Fri, 9 Apr 93 12:47:28 PDT
Message-Id: <9304091947.AA04176@knowman.lib.ucsf.EDU>
To: www-talk@nxoc01.cern.ch
Subject: List archives, HTML/SGML authoring tools, etc.
Date: Fri, 09 Apr 93 12:58:09 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>

Hi,
  I just joined this list and can't seem to access the archives at
http://eies2.njit.edu:80/wmail.html.  So, I don't know what's been
discussed recently.  Where else can I find the archives?
  I'm interested in HTML/SGML authoring tools.  Can we have an update
on the status of any X11-based editor?  We would like to start
generating HTML and are evaluating which course is the best to take.
We could buy a NeXTStep machine, or Framemaker for our Suns.  But
it would really be great if we had an X11-based editor on a par with
Xmosaic.  I may be able to find the time to contribute to such an
effort.  How about it, Marc?  What's the prognosis?
  What about commercial SGML authoring systems such as ArborText?  Is
anyone out there using them?  Does anyone have anything good/bad to
say about any of them?
  One project we are considering getting started on is integrating the
Z39.50 information retrieval protocol into WWW.  We're a library and
Z39.50 is becoming *very* important to us.  Z39.50, by the way, is
essentially the protocol used by WAIS (with a few caveats).  I have
yet to take a close look at the WWW-WAIS gateway code.  Comments?
  Finally, in http://hoohoo.ncsa.uiuc.edu:80/www-overview.html, TBL
says 
    HTML is eventually going to be a real ``standard''; by
    the time that happens, it should be fully SGML-compliant.
What does "real" mean in this context?  Which standards organization(s)
are involved?
Chris
-----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From marca@wintermute.ncsa.uiuc.edu  Sat Apr 10 11:17:28 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17948; Sat, 10 Apr 93 11:17:28 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21122; Sat, 10 Apr 1993 11:36:53 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA04791
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 10 Apr 93 04:36:51 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03932; Sat, 10 Apr 93 04:39:05 -0500
Date: Sat, 10 Apr 93 04:39:05 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304100939.AA03932@wintermute.ncsa.uiuc.edu>
To: Christopher McRae <mcrae@lib.ucsf.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: List archives, HTML/SGML authoring tools, etc.
In-Reply-To: <9304091947.AA04176@knowman.lib.ucsf.EDU>
References: <9304091947.AA04176@knowman.lib.ucsf.EDU>
X-Md4-Signature: c677b98fe5554a0ffc51197a4c340a6a

Christopher McRae writes:
>   I'm interested in HTML/SGML authoring tools.  Can we have an
> update on the status of any X11-based editor?  We would like to
> start generating HTML and are evaluating which course is the best to
> take.  We could buy a NeXTStep machine, or Framemaker for our Suns.
> But it would really be great if we had an X11-based editor on a par
> with Xmosaic.  I may be able to find the time to contribute to such
> an effort.  How about it, Marc?  What's the prognosis?

We'd like to do it, but we have all kinds of things on our plate right
now and not enough people/time to do them all.  So it's hard to say
when the editor is going to move far enough up the "important todo"
list to be given time and energy, if the current situation holds
(i.e., if nobody dumps a pile of money on our laps).

>   One project we are considering getting started on is integrating the
> Z39.50 information retrieval protocol into WWW.  We're a library and
> Z39.50 is becoming *very* important to us.  Z39.50, by the way, is
> essentially the protocol used by WAIS (with a few caveats).  I have
> yet to take a close look at the WWW-WAIS gateway code.  Comments?

Mosaic has to speak Z39.50 sometime this year -- again, not sure when,
though -- and we're hoping it will be done for us (i.e., in the client
library) but if not we'll probably put work into it.

>   Finally, in http://hoohoo.ncsa.uiuc.edu:80/www-overview.html, TBL
> says 
>     HTML is eventually going to be a real ``standard''; by
>     the time that happens, it should be fully SGML-compliant.
> What does "real" mean in this context?  Which standards organization(s)
> are involved?

Probably the Internet RFC process (?), which would make it a
"standard" on a roughly equivalent footing with the format of Internet
mail messages, or MIME, or the FTP protocol, or anything else defined
by an RFC.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Sat Apr 10 14:26:43 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18413; Sat, 10 Apr 93 14:26:43 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11766; Sat, 10 Apr 1993 14:46:09 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11034
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 10 Apr 93 07:46:07 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05025; Sat, 10 Apr 93 07:48:20 -0500
Date: Sat, 10 Apr 93 07:48:20 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304101248.AA05025@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Internet Talk Radio revisited
X-Md4-Signature: 738740a3d664de2d324324878f77ccbf

See http://www.ncsa.uiuc.edu/radio/radio.html for a damn good time....

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From Nathan.Torkington@vuw.ac.nz  Sun Apr 11 11:57:28 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24871; Sun, 11 Apr 93 11:57:28 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14445; Sun, 11 Apr 1993 12:16:53 +0200
Received: by kauri.vuw.ac.nz id AA25271
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Sun, 11 Apr 1993 22:16:43 +1200
Date: Sun, 11 Apr 1993 22:16:43 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304111016.AA25271@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: *whew* Internet Services List (kinda) hypertexted

I've just spend the last three or so hours marking up the Internet
Services List so that it
 a) has a presentable structure, and
 b) has links to everything

I trimmed some items out that weren't relevant but I think I have
links to most things.  If you plan on accessing the document
frequently, please make a local copy -- our network is expensive :-(

The list is:
  http://www.vuw.ac.nz:80/non-local/internet-services.html
and is 25k long.

Cheers;

Nat

From Nathan.Torkington@vuw.ac.nz  Sun Apr 11 12:05:10 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24881; Sun, 11 Apr 93 12:05:10 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15971; Sun, 11 Apr 1993 12:24:35 +0200
Received: by kauri.vuw.ac.nz id AA25952
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Sun, 11 Apr 1993 22:24:30 +1200
Date: Sun, 11 Apr 1993 22:24:30 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304111024.AA25952@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Nat's home page

Is now:

	http://www.vuw.ac.nz:80/who/Nathan.Torkington/home.html

not
	..../databases/people/Nathan.Torkington.html

Cheers;

Nat

From TONYJ@scs.slac.stanford.edu  Sun Apr 11 22:08:59 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27126; Sun, 11 Apr 93 22:08:59 MET DST
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20101; Sun, 11 Apr 1993 22:28:27 +0200
Date: Sun, 11 Apr 1993 13:28 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: *whew* Internet Services List (kinda) hypertexted
To: www-talk@nxoc01.cern.ch
Message-Id: <F5A0D16282A094D1@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: in%"www-talk@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ

>I've just spend the last three or so hours marking up the Internet
>Services List so that it
> a) has a presentable structure, and
> b) has links to everything

>I trimmed some items out that weren't relevant but I think I have
>links to most things.  If you plan on accessing the document
>frequently, please make a local copy -- our network is expensive :-(

This looks great....I've put a copy on:

http://slacvx.slac.stanford.edu:80/misc/internet-services.html

which I will try to keep up-to-date with Nat's original (which version of 
the WWW server supports automatic mirroring??). This should give faster 
access, (at least for those in the US).

Tony

From emv@garnet.msen.com  Sun Apr 11 23:13:22 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27679; Sun, 11 Apr 93 23:13:22 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02071; Sun, 11 Apr 1993 23:32:50 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0ni9dw-001IFDC@garnet.msen.com>; Sun, 11 Apr 93 17:32 WET DST
Message-Id: <m0ni9dw-001IFDC@garnet.msen.com>
To: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: *whew* Internet Services List (kinda) hypertexted 
In-Reply-To: Your message of Sun, 11 Apr 93 13:28:00.
             <F5A0D16282A094D1@SCS.SLAC.STANFORD.EDU> 
Date: Sun, 11 Apr 93 17:32:32 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

The www command line client has the command
 www -source http://slacvx.slac.stanford.edu:80/misc/internet-services.html
which can be used for mirroring.  Redirect the output to a file.

The http protocol has no notion of file dates or sizes, so it's not
entirely suitable for the sorts of optimizable automatic mirroring
that packages like lmjm@src.doc.ic.ac.uk's "mirror" uses; if bytes
across a link are precious and you want to mirror a site behind that
link putting the files out in ftp-land is to date the only efficient
way to go.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)


From mvanheyn@cs.indiana.edu  Mon Apr 12 00:58:50 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28172; Mon, 12 Apr 93 00:58:50 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19911; Mon, 12 Apr 1993 01:18:19 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA24990; Sun, 11 Apr 1993 18:18:16 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Cc: tloos@cs.indiana.edu
Subject: Re: *whew* Internet Services List (kinda) hypertexted 
In-Reply-To: Your message of "Sun, 11 Apr 1993 13:28:00 PDT."
             <F5A0D16282A094D1@SCS.SLAC.STANFORD.EDU> 
Date: Sun, 11 Apr 1993 18:18:15 -0500
Message-Id: <24988.734570295@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: "Tony Johnson (415) 926 2278"
>>I've just spend the last three or so hours marking up the Internet
>>Services List so that it
>> a) has a presentable structure, and
>> b) has links to everything
>
>>I trimmed some items out that weren't relevant but I think I have
>>links to most things.  If you plan on accessing the document
>>frequently, please make a local copy -- our network is expensive :-(
>
>This looks great....I've put a copy on:
>
>http://slacvx.slac.stanford.edu:80/misc/internet-services.html

There's another version of this available from the Indiana University
home page which Tom Loos put together a while back, but I think it's
current.  The URL is http://cs.indiana.edu/internet/internet.html for
the main list.  I keep meaning to make it searchable via a keywork
index one of these days.

By the way, I notice that the Internet services list in Stanford has
links to a finger entry at Berkeley which goes via a WWW-finger
gateway in New Zealand.  This seems rather inefficient, to say the
least.  There is also a finger gateway (which I consider cool, since
it includes graphical support from faces) on our server which people
in the states might consider.  Look in
http://cs.indiana.edu/finger/gateway for information on it.

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted

Lawyer: n.  One skilled in circumventing the law.
		- Ambrose Bierce

From montulli@stat1.cc.ukans.edu  Mon Apr 12 02:13:07 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28678; Mon, 12 Apr 93 02:13:07 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03470; Mon, 12 Apr 1993 02:32:36 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA41106; Sun, 11 Apr 1993 19:25:34 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9304120025.AA41106@stat1.cc.ukans.edu>
Subject: Lynx 2.0 Beta revision 7
To: www-talk@nxoc01.cern.ch
Date: Sun, 11 Apr 93 19:25:33 CDT
Cc: www-announce@nxoc01.cern.ch
X-Mailer: ELM [version 2.3 PL2]

A new version of Lynx is now available at acs220.cc.ukans.edu
for anonymous ftp.

If you don't know what Lynx is try telneting to ukanaix.cc.ukans.edu
and logging in as 'www' for a demo.

Revisions 7 is mostly a large group of bug fixes, but there is
also a new feature to allow you to turn on link numbering, so
Lynx can look alot like the line mode browser. (Wow! :)

Support for VMS is greatly increased.
Big thanks to Foteos Macrides and Selden E. Ball, Jr. for all the VMS
bug reports and fixes.

Binaries are also available for AIX, Ultrix, SUN, and VMS.

On a completely different note:
I have also put up a test gateway to read Lynx internal format 
documents.  Our entire CWIS and the WWW Demo pages are now
accessable through this gateway.  

The University of Kansas CWIS is at:
 http://acs220.cc.ukans.edu:8002/cwis.screen
The WWW demo start page is at:
 http://acs220.cc.ukans.edu:8002/www.start
    
The data server will move to a more permanent machine in a couple of
weeks.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************

From marca@wintermute.ncsa.uiuc.edu  Mon Apr 12 09:16:47 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00561; Mon, 12 Apr 93 09:16:47 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23398; Mon, 12 Apr 1993 09:36:16 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA21194
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Mon, 12 Apr 93 02:36:14 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA15542; Mon, 12 Apr 93 02:38:29 -0500
Date: Mon, 12 Apr 93 02:38:29 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304120738.AA15542@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: NCSA Mosaic 0.13 released.
X-Md4-Signature: 249c82a3acff5fb28ed50ddf204c5b70

Beta version 0.13 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is hereby released:

file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-source/xmosaic-0.13.tar.Z
                            .../xmosaic-binaries/xmosaic-sun.Z
                            .../xmosaic-binaries/xmosaic-sgi.Z
                            .../xmosaic-binaries/xmosaic-ibm.Z
                            .../xmosaic-binaries/xmosaic-dec.Z
                            .../xmosaic-diffs/xmosaic-0.12-0.13-diffs.Z

This release of NCSA Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.3 with stock X11R4 and Motif 1.1, and GCC).
  DEC Ultrix.

More binaries will be supplied as I am able to find other
Motif-configured platforms to use.  (Contributions of working
binaries, or development systems, are welcome.)  Documentation is
available online.

Changes since 0.12 include:

 o Fixed occasional mysterious coredump in startup routines. 
 o Fixed occasional stupid coredump in freeing document text. 
 o Fixed silly coredump on accessing malformed URLs like
   ftp:/tcp/xxx.yyy.zzz.www. 
 o Fixed URL parsing choke on accessing URL 'test.html#foobar' as
   an initial program argument. 
 o Added system() call error reporting. 
 o Changed default anchor representations: blue and single solid
   underline for unvisited, dark purple and single dashed underline
   for visited. 
 o Jumping from 2nd+ document page to 1st document page in a
   single document via anchors works now. 
 o Various glitches with scrollbars, document pages, etc. fixed. 
 o New toggle-button options (caseless, backwards) in File->Search
   window. 
 o File->Search doesn't put search results on top line of window. 
 o Use of -l flag for rlogins restored. 
 o Built-in finger interface with faces support (thanks, Marc V of
   IU!). 
 o Miscellaneous bug fixes and cleanups. 

Thanks as usual to everyone who's been contributing comments and bug
reports -- keep 'em coming!

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From tom%begbick.law.cornell.edu@router.mail.cornell.edu  Mon Apr 12 17:58:25 1993
Return-Path: <tom%begbick.law.cornell.edu@router.mail.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03593; Mon, 12 Apr 93 17:58:25 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27556; Mon, 12 Apr 1993 18:17:54 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160620(2)>; Mon, 12 Apr 1993 12:17:51 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA04963; Mon, 12 Apr 93 12:10:05 EDT
Date: Mon, 12 Apr 1993 12:10:05 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9304121610.AA04963@begbick.law.cornell.edu.law.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Plans for cello MS-Windows client

Folks:

A considerable degree of mystery has surrounded the development of the
Cello Windows browser.  Here's some information - and a kind-of,
sort-of schedule - which I hope will help some of you who have been
curious about it.

Capabilities:

As presently constructed, Cello works directly as a WWW, gopher, FTP,
and Telnet client in much the same way as XMosaic does.  The terminal
emulation for the Telnet client is, for the moment, restricted to ANSI
emulation, but this will either be improved to support more
sophisticated features in future or else hooks will be added to permit
you to run your own Windows Telnet.

Tagset support includes all of the current WWW tags excepting more
nebulous, contemplated tags like <BLOCKQUOTE>.  Text attribute tags
(<STRONG>, <B>, <I>, <U>, etc are supported).  <OL> is supported.
Diacritical and national characters are not supported, but will be
soon up to the limits of the Windows ANSI character set.

Gopher+ is not currently supported but will be in a future version.

NNTP support is in development.

In addition, Cello supports post-processing of any and all files for
which the user configures an association-by-filename-extension in the
WIN.INI file.  For all practical purposes, this means that out-of-line
viewing of graphics files and out-of-line listening to audio files are
currently supported provided that 1) the user has an appropriate app
installed for the file-extension as given in the URL and 2)the URL
uses a file:// scheme.  (For example, I can't get at Marc's Internet
Talk Radio files; the http:// access scheme in their URL's causes
Cello to assume that they're in HTML format -- is this a bad thing?
should I have a way of handling this?).
I can play .au files, though.

This last gets a little tricky in terms of .Z and .zip and the
handling of other compressed files. Cello is not too bright about
handling these -- it happily will decompress them, and then has no
idea what to display.  How are others handling this?

I also hope to develop a URL scheme and code for handling DDE and OLE
linking by the time of the first release.  Anyone have any suggestions
about what the URL for such things ought to look like?

Internals (library):

At present Cello uses very little of the WWW common library.  This is
in part a product of the difficulty of porting into the Windows
environment, and in part a product of my laziness in understanding the
common code architecture.  This can and probably will change in future
versions, with NNTP support as a 'trial balloon' in that direction.

The GUI internals are about half Windows-API-direct and half Borland
ObjectWindows. Coding is C++.  No release of source code is
contemplated.

Internals(TCP/IP):

At present Cello uses a commercial TCP/IP stack from the Distinct
Corporation.  The coding from my end will be converted to Winsock
compliance prior to beta release, but I am cynical about what 'Winsock
compliance' means at this stage.  For that and a few other reasons we
will obtain an unlimited runtime license from Distinct which will
permit us to distribute their stack to academic institutions at no
cost to the end user for one year.  After that, we'll see.  The
Distinct package does offer some useful features, such as SLIP and PPP
support and dialling, which we would like to keep around.


Plans:

So far as progress and dates are concerned, here's the plan:

As matters stand:

-- NNTP is not yet implemented, and will be prior to beta release.
-- Terminal emulation is in the process of being cleaned up.
-- HTML is stable -- at least until the next round of improvements is
put in .
-- I have about 3,412,345 minor user interface changes/improvements to
make.


All this argues for a limited beta release around 1 May, with general
availability around 1 June and something stable enough to call a
'version' by July 15.

Overarching concerns:

The LII is a garage shop primarily interested in the distribution of
law-related information over the Web.  We are not a full-blown
software shop...and for that reason some of this probably will seem a
bit fluky/nebulous to a number of you.  Dates will probably slip, and
some features will be slow in coming....and I'm afraid it's the best I
can do for all of you who have already shown interest in a 'vaporware'
product.   Do keep those cards and letters coming -- I need feedback
and suggestion on features and implementation (though some things may
not happen right away).  We could also use money (grin).

Regards,

Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


From putz@parc.xerox.com  Mon Apr 12 20:55:15 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06290; Mon, 12 Apr 93 20:55:15 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19360; Mon, 12 Apr 1993 21:14:44 +0200
Received: from spoggles.parc.xerox.com ([13.2.16.98]) by alpha.xerox.com with SMTP id <11624>; Mon, 12 Apr 1993 12:14:35 PDT
Received: by spoggles.parc.xerox.com id <2445>; Mon, 12 Apr 1993 12:14:26 -0700
From: Steve Putz <putz@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: Current Status of comp.infosystems.www
Message-Id: <93Apr12.121426pdt.2445@spoggles.parc.xerox.com>
Date: 	Mon, 12 Apr 1993 12:14:12 PDT


                                                               LAST DAY
PROPOSAL                         RFD             CFV           TO  VOTE
-----------------------------------------------------------------------
comp.infosystems.www            16 Feb          26 Mar          20 Apr
                   Yes votes to:  www-yes@msen.com
                    No votes to:  www-no@msen.com


[Just a reminder to vote if you have not yet]

From murphy@dccs.upenn.edu  Mon Apr 12 20:59:29 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06368; Mon, 12 Apr 93 20:59:29 MET DST
Received: from NOC2.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19478; Mon, 12 Apr 1993 21:18:58 +0200
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA07514; Mon, 12 Apr 93 15:18:52 -0400
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA01852; Mon, 12 Apr 93 15:18:51 -0400
Posted-Date: Mon, 12 Apr 93 15:18:50 -0400
Message-Id: <9304121918.AA01852@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch
Subject: Where is the WWW client for Macintosh these days?
Date: Mon, 12 Apr 93 15:18:50 -0400
From: murphy@dccs.upenn.edu
X-Mts: smtp


I haven't noticed any announcements about it lately...

Did it ever make it past Alpha?  What host can I fetch it from?

thanks,
--lam

------- Forwarded Message

Return-Path: smith@pobox.upenn.edu
Received-Date: Mon, 12 Apr 93 15:05:48 -0400
Received: from STAFF.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA05477; Mon, 12 Apr 93 15:05:46 -0400
Received: from NOC1.DCCS.UPENN.EDU by staff.dccs.upenn.edu
	id AA04290; Mon, 12 Apr 93 15:05:44 -0400
Received: from POBOX.UPENN.EDU by noc1.dccs.upenn.edu
	id AA11877; Mon, 12 Apr 93 15:05:42 -0400
Return-Path: <smith@pobox.upenn.edu>
Received: from SMITH.DCCS.UPENN.EDU by pobox.upenn.edu
	id AA02969; Mon, 12 Apr 1993 15:05:40 -0400
Date: Mon, 12 Apr 1993 15:05:40 -0400
Posted-Date: Mon, 12 Apr 1993 15:05:40 -0400
Message-Id: <9304121905.AA02969@pobox.upenn.edu>
To: murphy@dccs.upenn.edu
From: smith@pobox.upenn.edu (Judy Smith)
Subject: Re: Faster access to the WWW Internet Services  from the U.S.A.

Yes, I'd like to try it. But, alas, no client.  I went looking to find out
if the MacWWW beta client had progressed to another version (the old
one doesn't allow you to point anywhere other than CERN) but not only could
I NOT find anything new, the old version of the software seems to have
disappeared as well.  Have you heard anything on the WWW discussion groups
about the demise of this project?

Judy

- ---
Judy Smith                       ISC Communications Group, Penn 
smith@pobox.upenn.edu                            (215) 898-0007


------- End of Forwarded Message


From montulli@stat1.cc.ukans.edu  Mon Apr 12 23:48:40 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09219; Mon, 12 Apr 93 23:48:40 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11859; Tue, 13 Apr 1993 00:08:10 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA40230; Mon, 12 Apr 1993 17:01:09 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9304122201.AA40230@stat1.cc.ukans.edu>
Subject: Traversal program
To: www-talk@nxoc01.cern.ch
Date: Mon, 12 Apr 93 17:01:08 CDT
X-Mailer: ELM [version 2.3 PL2]


Last week there was quite a bit of talk about traversing the Web
to compile a list of all Web documents.

I have tweeked my traversal program a little for WWW documents
and it looks like it will work.

The traversal program only attempts to follow http: links and
keeps a list of all links as they are traversed.  

The question I have now is:  Should I run it?  I'm not entirely
sure what it will do.  It will certainly put a big load on
the network.  Will it get bogged down in some incredibly dense
subtree?  What day of the week would be the best time to run?

Currently the URL, Document Title and the link name that referenced
the document are saved in a Tab delimiter format.  Are there
any tabs in document titles?

What does everyone else think?

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************


From montulli@stat1.cc.ukans.edu  Tue Apr 13 02:06:58 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10610; Tue, 13 Apr 93 02:06:58 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19534; Tue, 13 Apr 1993 02:26:29 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA12644; Mon, 12 Apr 1993 19:19:34 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9304130019.AA12644@stat1.cc.ukans.edu>
Subject: HTML to Postscript
To: www-talk@nxoc01.cern.ch
Date: Mon, 12 Apr 93 19:19:33 CDT
X-Mailer: ELM [version 2.3 PL2]


Is anyone interested in writing an HTML to postscript program??

There may already exist some SGML to postscript programs so
the job might not be too hard.  How about any of you
Postscript wizards that are hiding out there?

I would like to use this as a print filter for Lynx.  And I'm
sure Marc Andreessen would like to use one as well!

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet         			   *
  *                         Kuhub.cc.ukans.edu               	           *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!         	913/864-0436	       Lawrence, KS 66044  *
  *					         			   *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************

From Nathan.Torkington@vuw.ac.nz  Tue Apr 13 02:27:45 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10743; Tue, 13 Apr 93 02:27:45 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26523; Tue, 13 Apr 1993 02:47:12 +0200
Received: by kauri.vuw.ac.nz id AA04595
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Tue, 13 Apr 1993 12:47:07 +1200
Date: Tue, 13 Apr 1993 12:47:07 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304130047.AA04595@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Lou Montulli's message <9304130019.AA12644@stat1.cc.ukans.edu>
Subject: HTML to Postscript

Lou Montulli writes:

> Is anyone interested in writing an HTML to postscript program??

I have an HTML to LaTeX program (better IMHO than the sed script
available from CERN).  I will upload the latest version to NCSA as
html2latex-0.9b.tar.Z.

It handles:
 -- bold, italics, etc
 -- sections, subsections
 -- titling and authorship
 -- numbering or non-numbering the sections
 -- automatic table-of-contentsing

It doesn't know about;
 -- <DL COMPACT>

In the future, I *might* write an HTML style for LaTeX.  Maybe.
Possibly.  Hmmm.

Nat.

From marca@wintermute.ncsa.uiuc.edu  Tue Apr 13 03:11:38 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11041; Tue, 13 Apr 93 03:11:38 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08203; Tue, 13 Apr 1993 03:31:09 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA21789
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Mon, 12 Apr 93 20:31:07 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA18258; Mon, 12 Apr 93 20:33:22 -0500
Date: Mon, 12 Apr 93 20:33:22 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304130133.AA18258@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: NCSA Mosaic for X 0.13 addendum.
X-Md4-Signature: 2859342ca97a46851ead0b499c875bce

The NCSA Mosaic 0.13 Sun binary that was available on
ftp.ncsa.uiuc.edu in /Mosaic/xmosaic-binaries as xmosaic-sun up until
5 minutes ago was linked to Sun's libresolv.a, which is necessary for
Suns not running DNS and does not *usually* screw up Suns running DNS,
but does screw up a large enough (non-zero) percentage of Suns running
DNS that it is now apparent to Yours Truly that I can't just make
available a single Sun binary and expect it to work on all Suns on the
network.  Bummer.

The upshot is that there are now two Sun binaries available:

file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-binaries/xmosaic-sun
file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-binaries/xmosaic-sun-lresolv

If you picked up a copy of the previous xmosaic-sun 0.13 binary and it
didn't work for you, please pick up a copy of the new xmosaic-sun
binary and try it out (and if it still doesn't work, please yell at
me).

Sorry for the confusion,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Tue Apr 13 03:14:01 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11074; Tue, 13 Apr 93 03:14:01 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10459; Tue, 13 Apr 1993 03:33:32 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA21896
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 12 Apr 93 20:33:30 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA18269; Mon, 12 Apr 93 20:35:43 -0500
Date: Mon, 12 Apr 93 20:35:43 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304130135.AA18269@wintermute.ncsa.uiuc.edu>
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Cc: www-talk@nxoc01.cern.ch
Subject: HTML to Postscript
In-Reply-To: <199304130047.AA04595@kauri.vuw.ac.nz>
References: <199304130047.AA04595@kauri.vuw.ac.nz>
	<9304130019.AA12644@stat1.cc.ukans.edu>
X-Md4-Signature: ba80022826c914e825a86de8bf9f7ff3

Nathan Torkington writes:
> I have an HTML to LaTeX program (better IMHO than the sed script
> available from CERN).  I will upload the latest version to NCSA as
> html2latex-0.9b.tar.Z.

And it is now available as:

file://ftp.ncsa.uiuc.edu/Mosaic/misc/html2latex-0.9b.tar.Z

Thanks, Nat!

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From Nathan.Torkington@vuw.ac.nz  Tue Apr 13 03:24:45 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11149; Tue, 13 Apr 93 03:24:45 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13831; Tue, 13 Apr 1993 03:44:12 +0200
Received: by kauri.vuw.ac.nz id AA06615
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Tue, 13 Apr 1993 13:44:06 +1200
Date: Tue, 13 Apr 1993 13:44:06 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304130144.AA06615@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Project Gutenberg's Roget's Thesaurus

We all know that it has been WAISified, but now it has been HTMLated
(unfortunately it hasn't been WAISified *and* HTMLated, but that comes
later).  The software (simple and easy to use) to build this HTMLated
version of the thesaurus will be available from NCSA's FTP site as
roget-dist-1.1.tar.Z some time.

It can be tested out *in the meantime* as
	http://www.vuw.ac.nz/non-local/gutenberg/roget/home.html
but I urge you to make your own local version of the database, or to
wait for someone closer to you to do so.  As I've said before, we get
it in the wallet for each connection, and the index is 44K.

Report any problems to
	Nathan.Torkington@vuw.ac.nz

Enjoy,

Nat

From janssen@parc.xerox.com  Tue Apr 13 05:28:47 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12440; Tue, 13 Apr 93 05:28:47 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21940; Tue, 13 Apr 1993 05:48:18 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11669>; Mon, 12 Apr 1993 20:47:57 PDT
Received: by holmes.parc.xerox.com id <16134>; Mon, 12 Apr 1993 20:47:53 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon, 12 Apr 1993 20:47:40 -0700 (PDT)
Message-Id: <EfmXTQcB0KGW4gGGZ1@holmes.parc.xerox.com>
Date: 	Mon, 12 Apr 1993 20:47:40 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: HTML to Postscript
In-Reply-To: <199304130047.AA04595@kauri.vuw.ac.nz>
References: <199304130047.AA04595@kauri.vuw.ac.nz>

Unfortunately, html2latex seems to use the include file "getopt.h",
which is nowhere on my Sun that I can see.

Bill

From Nathan.Torkington@vuw.ac.nz  Tue Apr 13 05:57:30 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12568; Tue, 13 Apr 93 05:57:30 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28667; Tue, 13 Apr 1993 06:16:58 +0200
Received: by kauri.vuw.ac.nz id AA12033
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Tue, 13 Apr 1993 16:16:54 +1200
Date: Tue, 13 Apr 1993 16:16:54 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304130416.AA12033@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Project Gutenberg's Paradise Lost

Project Gutenberg's "Paradise Lost" can now be marked up for
hypertext.  When Marc moves it out of incoming,
	file://ftp.ncsa.uiuc.edu/Web/misc/plrabn-dist-1.1.tar.Z
will hold a set of scripts and some documentation for converting a
Project Gutenberg etext of "Paradise Lost" into HTML marked-up copy.

Note that this distribution does not carry the text of Paradise Lost
(the distribution is 12K) but does have hypertext documents with links
to the text itself.

To see it in action, try
	http://www.vuw.ac.nz/non-local/gutenberg/works/plrabn/home.html
If you plan on making links to it or using it extensively, please
obtain the distribution and make your own copy, or wait until a closer
site to you produces such a copy.

Any problems should be reported to
	Nathan.Torkington@vuw.ac.nz

<A HREF="http://www.vuw.ac.nz/who/Nathan.Torkington/home.html">Nat</A>

From Nathan.Torkington@vuw.ac.nz  Tue Apr 13 05:59:37 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12584; Tue, 13 Apr 93 05:59:37 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28742; Tue, 13 Apr 1993 06:19:05 +0200
Received: by kauri.vuw.ac.nz id AA12095
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Tue, 13 Apr 1993 16:19:00 +1200
Date: Tue, 13 Apr 1993 16:19:00 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304130419.AA12095@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Bill Janssen's message <EfmXTQcB0KGW4gGGZ1@holmes.parc.xerox.com>
Subject: Re: HTML to Postscript

Bill Janssen writes:

> Unfortunately, html2latex seems to use the include file "getopt.h",
> which is nowhere on my Sun that I can see.

When Marc moves it from incoming,
	file://ftp.ncsa.uiuc.edu/Web/misc/html2latex-0.9c.tar.Z
will hold a version that does not require your system to have getopt.h
(but you must still have the getopt function in your library, for
html2latex to parse its arguments).

Nat.
(I've known some drunk people whose arguments I couldn't parse --
should I have had getopt.h installed in brain@gnat:/usr/include ? :-)

From CSP1DWD@mvs.oac.ucla.edu  Tue Apr 13 12:25:10 1993
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14771; Tue, 13 Apr 93 12:25:10 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12245; Tue, 13 Apr 1993 12:44:42 +0200
Message-Id: <9304131044.AA12245@dxmint.cern.ch>
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 3135; Sat, 06 Nov 93 01:42:56 SET
Received: from UCLAMVS.BITNET (NJE origin MAILER@UCLAMVS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 9437; Sat, 6 Nov 1993 01:42:56 +0200
Date:    Mon, 12 Apr 93 16:42 PDT
To: murphy@dccs.upenn.edu
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: Re: Where is the WWW client for Macintosh these days?
Cc: www-talk@nxoc01.cern.ch

>  Did it ever make it past Alpha?  What host can I fetch it from?

It's over at info.cern.ch... I don't think it has passed alpha yet.
It's be nice if we had something like Xmosaic for the MAC. Xmosaic
is the most general and capable information services browser I've
yet to see.

-- Denis


From timbl@www3.cern.ch  Tue Apr 13 12:26:14 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14783; Tue, 13 Apr 93 12:26:14 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12378; Tue, 13 Apr 1993 12:45:47 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05574; Tue, 13 Apr 93 12:43:31 +0100
Date: Tue, 13 Apr 93 12:43:31 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304131143.AA05574@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: jackson@stsci.edu
Subject: Re: WWW Information Discovery Tools
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Thu, 8 Apr 93 13:36:26 EDT
> From: Bob Jackson <jackson@stsci.edu>
> 

> In comparing WWW vs Gopher and WAIS, I  admit
> that WWW is a more powerful data representation model.
> 

> But, its ability to discover information is only as good as 

> the links are and the links are made by hand.


As marc says, you can certainly run a wais index on
the data you serve up with w3, and serve up that index
as a w3 server.  Just look at the famous unix manual pages
in the mosaic menu ... that is indexed hypertext.
You don't have to use the wais indexing tool, of course, you
could use anything.

> Gopher and WAIS have global information discovery tools 

> which know more than any one person does about available
> resources, e.g.,
> 

> 	WAIS's directory-of-servers
> 	Gopher's Veronica
> 	Gopher's ts/tb or jughead
> 

> and which are created by software.
> 

> Is anyone working on similar tools for WWW?

Now we're talking indexes across servers.

I agree there is a need for an index of resources.  I think a few  
people are thinking of it, but as far as I know there isn't one yet,  
and while that is the case, there is an opening for someone who
would like to put together a quick hack on the public WAIS code
with www as front end.  Contributions please!  Using www to collect  
the data for indexing means that the same indexer would be able to
run over not only native w3 servers, butalso anything else (wais,  
gopher, etc) which it was pointed at, and the result would be an
index which would cover all these forms.  This would be really  
useful, as one doesn't  in general know what sort of a server has
the data one wants. So the new index will INCLUDE the directory
of servers and veronica.  All on one swell foop.  Anyone going to
go for it?

Tim

(I know some scandinavians hava funding proposal in for this, but if  
they are beaten to the post I am _sure_ they will find ways of  
spending the money!)



From wmperry@papaya.ucs.indiana.edu  Tue Apr 13 16:28:46 1993
Return-Path: <wmperry@papaya.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17994; Tue, 13 Apr 93 16:28:46 MET DST
Received: from papaya.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27354; Tue, 13 Apr 1993 16:48:16 +0200
Message-Id: <9304131448.AA27354@dxmint.cern.ch>
Received: by papaya.ucs.indiana.edu
	(5.65c/9.4jsm) id AA03059; Tue, 13 Apr 1993 09:48:14 -0500
Date: Tue, 13 Apr 1993 09:48:14 -0500
From: "William M. Perry" <wmperry@papaya.ucs.indiana.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: New Version of The Emacs Browser For W3 (.04b)

Hello All,
  
   This is to announce yet another version of my WWW browser for emacs.  It
supports Epoch, Lucid, and vanilla emacs.  Lucid&Epoch support fonts and
highlighting.  The Epoch version now supports graphics (bitmaps, gifs,
group3 faxes, raster, X window-dumps, X icons, graymaps, PICT, MacPaint
files, and Targa files) - this requires that Epoch was compiled with
HAVE_XPM defined, and also needs the pbmplus package (or some other way to
convert the images into an XPixMap that epoch can understand).  It also
supports all tags except for news links.  The Lucid Emacs now supports
setting the fonts for headers, etc in your .Xresources file.

    The package is available via anonymous ftp from moose.cs.indiana.edu in
/pub/elisp/w3.  Get the w3.tar.Z file if you are upgrading from an earlier
version.  Get w3.tar.Z & extras.tar.Z if this is the first time.
extras.tar.Z contains:
---------------------------------------------------------------------------
   Package            Author
   -------            ------
   ange-ftp: Andy Norman, ange@hplb.hpl.hp.com
 background: Joseph G. Keane <jk3k+@ANDREW.CMU.EDU>
transparent: Brian Tompsett, briant@spider.co.uk
     gopher: scott snyder <snyder@d0gsc.fnal.gov>
      forms: Johan Vromans (jv@mh.nl)
---------------------------------------------------------------------------

  Please drop me a line if you grab the package, just so I have some idea
of how many people are using it. :)  Suggestions for improvements, bug
reports, and bug fixes are all welcome.

  Some documentation on w3-mode is in
http://moose.cs.indiana.edu:80/elisp/w3/docs.html

Enjoy,
	Bill Perry

-- William M. Perry (wmperry@indiana.edu) --
Probably the earliest flyswatters were nothing more than some sort of
striking surface attached to the end of a long stick.

---------------------------------------------------------------------------
  Here is an excerpt of the changelog file since the last release:
Tue Apr 13 08:30:58 1993  William M. Perry  (wmperry@indiana.edu)
* v.04b
* Fixed graphic support to work over http links (Epoch Only)
* Fixed graphic support so it will figure out if the conversion failed
  or not - warning message if it did.
  
Mon Apr 12 07:35:40 1993  William M. Perry  (wmperry@indiana.edu)
* v.03b
* Fixed lemacs support so it doesn't nuke your xdefaults.  Also fixed
  the passing of face-objects, since they are screen-specific, and
  therefore a Bad Thing.  Thanks to Jamie Zawinski (jwz@lucid.com)
* Changed menu code so that it put the link # in there also.  Helpful
  for when the links are unnamed, or named 'here' or 'this'.  Thanks
  to Jamie Zawinski (jwz@lucid.com) for saying the menus were hosed.

Sun Apr 11 16:30:44 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed graphics support for epoch - would only do 1 image per page.
* Fixed a few typos - thanks to eostrom@nic.gac.edu

Fri Apr  9 00:18:47 1993  William M. Perry  (wmperry@indiana.edu)
* Added graphics support for epoch (doesn't work over http, pretty
  much hardwired for me right now - commented out in the release)
* v.02b
* Several bug fixes (link finding, name fixing, others) - thanks to
  eostrom@nic.gac.edu for the fixes.
* Added eostrom@nic.gac.edu's zone-imitation functions for normal emacs.
  Also wrote corresponding forward&back link code.  I wrote the forward&
  back code for epoch&lemacs.

Thu Apr  8 13:23:27 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed being able to jump forward over non-links in []s. Thanks to
  eostrom@nic.gac.edu
* Fixed telnet handling - thanks to eostrom@nic.gac.edu for noticing
  it and for a preliminary fix.  Refined his fix.  Problem was that
  telnet wasn't getting enough time to start before I sent it a
  command.
* Fixed a few regular expressions - thanks to eostrom@nic.gac.edu
* Fixed bug in w3-add-document-hotlist which caused an error if the
  hotlist file didn't already exist.  Thanks to eostrom@nic.gac.edu
  for noticing it.


From timbl@www3.cern.ch  Tue Apr 13 17:38:43 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19221; Tue, 13 Apr 93 17:38:43 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10539; Tue, 13 Apr 1993 17:58:15 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05755; Tue, 13 Apr 93 17:56:02 +0100
Date: Tue, 13 Apr 93 17:56:02 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304131656.AA05755@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Style Guide for Online Hypertext
Reply-To: timbl@nxoc01.cern.ch



Many people recently have asked for a guide to writing on-line  
hypertext for the web.  I have therefore started a "living document"  
about it which is at
http://info.cern.ch/hypertext/WWW/Provider/Style/Overview.html

This is a collection of points about the design of networked  
documents.

If you have any smart ideas, or gripes about the way people have done  
things which translate into general advice, send them to me  
mentioning the guide and I'll try to put them in.
Also any comments on its utility or lack of would be apreciated

There isn't a paper version yet.

Tim Berners-Lee

From timbl@www3.cern.ch  Tue Apr 13 17:49:49 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19457; Tue, 13 Apr 93 17:49:49 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12718; Tue, 13 Apr 1993 18:09:22 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05778; Tue, 13 Apr 93 18:07:08 +0100
Date: Tue, 13 Apr 93 18:07:08 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304131707.AA05778@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: Project Gutenberg's Roget's Thesaurus
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



As more public domain hypertext comes on line, we are going to need
some big disks on each continent for it.  We should also perhaps use
some mirroring software to keep them up to date.

One possibility is we feed back the hypertext to Michael Hart.
It could just be an overlay of files which have pointers to
the actual text, or a smart server which can #include the
actual text into a wrapper document.

Nat, do you thing the Gutenberg project would consider
using their existing distribution chain for the stuff? We could
set up W3 servers on some of their machines maybe?  It would
take less CPU than FTP.

Tim

From wmperry@papaya.ucs.indiana.edu  Tue Apr 13 17:55:12 1993
Return-Path: <wmperry@papaya.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19585; Tue, 13 Apr 93 17:55:12 MET DST
Received: from papaya.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13023; Tue, 13 Apr 1993 18:14:44 +0200
Message-Id: <9304131614.AA13023@dxmint.cern.ch>
Received: by papaya.ucs.indiana.edu
	(5.65c/9.4jsm) id AA03401; Tue, 13 Apr 1993 11:14:42 -0500
Date: Tue, 13 Apr 1993 11:14:42 -0500
From: "William M. Perry" <wmperry@papaya.ucs.indiana.edu>
To: timbl@nxoc01.cern.ch
Cc: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Subject: Re: Project Gutenberg's Roget's Thesaurus
In-Reply-To: <9304131707.AA05778@www3.cern.ch>
References: <9304131707.AA05778@www3.cern.ch>

Tim Berners-Lee writes:
[...]
>One possibility is we feed back the hypertext to Michael Hart.
>It could just be an overlay of files which have pointers to
>the actual text, or a smart server which can #include the
>actual text into a wrapper document.
[...]

   Are there any plans to have an html tag to include a file?  That way you
wouldn't have to depend on a server being smart enough to include the file.
Something akin to the IMG tag now.  ie: <INCLUDE SRC="XXXXXX">, and
possibly <INCLUDE SRC="HTTP://fqdn:80/XXXXXX">.

>Tim

-Bill Perry

-- William M. Perry (wmperry@indiana.edu) --
'I'm a simple man.  All I want is enough sleep for two normal men, enough
 whiskey for three, and enough women for four.'
    - Joel Rosenberg

From guido@cwi.nl  Tue Apr 13 18:17:47 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20071; Tue, 13 Apr 93 18:17:47 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18520; Tue, 13 Apr 1993 18:37:19 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA04299 (5.65b/3.8/CWI-Amsterdam); Tue, 13 Apr 1993 18:37:18 +0200
Received: by voorn.cwi.nl with SMTP
	id AA24791 (5.65b/3.8/CWI-Amsterdam); Tue, 13 Apr 1993 18:37:18 +0200
Message-Id: <9304131637.AA24791=guido@voorn.cwi.nl>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Project Gutenberg's Roget's Thesaurus 
In-Reply-To: Your message of "Tue, 13 Apr 1993 18:07:08 MDT."
             <9304131707.AA05778@www3.cern.ch> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Tue, 13 Apr 1993 18:37:17 +0200
Sender: Guido.van.Rossum@cwi.nl

>As more public domain hypertext comes on line, we are going to need
>some big disks on each continent for it.  We should also perhaps use
>some mirroring software to keep them up to date.

I see a problem coming here: how does an unreplicated document (say my
own home page) mane a reference to such a replicated document?  If I
have a reference to the closest replica, a user far away who follows
such a link will get pointed to the replica closest to *me*, not
closest to her.

Some possible solutions:

- a translation scheme whereby clients "know" (e.g. from a local
configuration file that may be updated automatically as mirror sites
are added) that information at host X is identical to info at host Y

- a magic string in hostnames that is translated dependent on the
geographical position of the client (e.g.
http://info-cern.closestmirror/...)

- upon first contact with a server, it might respond with "please
try the following mirror site which is closer to you" (this could be
put in HTTP2 I suppose).

This is a real problem with embedding location information in URLs...

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From RASHTY@hujivms.bitnet  Tue Apr 13 18:19:58 1993
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20115; Tue, 13 Apr 93 18:19:58 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18661; Tue, 13 Apr 1993 18:39:31 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 1797; Tue, 13 Apr 93 18:39:39 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 3377; Tue, 13 Apr 1993 18:39:38 +0200
Received: by HUJIVMS (HUyMail-V6k); Tue, 13 Apr 93 19:39:23 +0200
Date:     Tue,  13 Apr 93 19:38 +0200
Message-Id: <13040093193848@HUJIVMS>
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch
Subject:  Environment information

Hi,

I have collected some Environment information, You can point out to it by
http://vms.huji.ac.il/www_teva/environment.html

In the near future I will put their:
- Articles
- Addresses of international organizations
- News
....... and more.



Some other things, you may find useful are:

1) Information about the internet
http://vms.huji.ac.il/WWW_DIR/INTERNET.html

2) Updated list of wais server by name/subject
http://vms.huji.ac.il/www_wais/wais_servers.html
http://vms.huji.ac.il/www_wais/wais_by_subject.html

3) Recipes...
http://vms.huji.ac.il/www_DIR/recipes.html

Sorry if the menus are in English/Hebrew format:
(H) - Stands for Hebrew
(E) - Stands for English

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:                                                      **** Thanks !! **** :
: Dudu Rashty                Rashty@Vms.Huji.Ac.Il         __o     o__     :
: Computation Center         Bitnet:Rashty@HUJIVMS       _ \<,_   _.>/ _   :
: The Hebrew University      Phone:  +972-2-584397      (_)/ (_) (_) \(_)  :
: Jerusalem 91904, ISRAEL.   Fax:    +972-2-527349       D    u    d    u  :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From fine@cis.ohio-state.edu  Tue Apr 13 18:25:46 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20213; Tue, 13 Apr 93 18:25:46 MET DST
Received: from [128.146.53.5] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19030; Tue, 13 Apr 1993 18:45:18 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13798; Tue, 13 Apr 93 12:45:09 -0400
Date: Tue, 13 Apr 93 12:45:09 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9304131645.AA13798@soccer.cis.ohio-state.edu>
To: montulli@stat1.cc.ukans.edu, www-talk@nxoc01.cern.ch
Subject: Re: HTML to Postscript
X-Mailer: Perl Mail System v1.2

>
>Is anyone interested in writing an HTML to postscript program??

I have been interested for months.  Unfortunately, with my work load,
I'll likely continue to be interested for many more months.

On the other hand, I already have postscript that formats a string into
a paragraph.  That's one of the major hurtles.  If there's another
postscript wizard out there that wants to try it, let me know and I'll
send you that bit of code.

	tom

From romig@cis.ohio-state.edu  Tue Apr 13 18:59:19 1993
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20755; Tue, 13 Apr 93 18:59:19 MET DST
Received: from brachiosaur.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24050; Tue, 13 Apr 1993 19:18:51 +0200
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA00992; Tue, 13 Apr 93 13:18:07 -0400
Date: Tue, 13 Apr 93 13:18:07 -0400
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9304131718.AA00992@brachiosaur.cis.ohio-state.edu>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Tim Berners-Lee's message of Tue, 13 Apr 93 17:56:02 +0100 <9304131656.AA05755@www3.cern.ch>
Subject: Style Guide for Online Hypertext

>Many people recently have asked for a guide to writing on-line  
>hypertext for the web.  I have therefore started a "living document"  
>about it which is at
>http://info.cern.ch/hypertext/WWW/Provider/Style/Overview.html

Awesome, thanks for putting that together!  I'll dig up some notes I
had scribbled down about hypertext writing style and send them to you
soon.

--- Steve


From paolo@venedig.ai.univie.ac.at  Tue Apr 13 18:59:47 1993
Return-Path: <paolo@venedig.ai.univie.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20768; Tue, 13 Apr 93 18:59:47 MET DST
Received: from moskau.ai.univie.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24073; Tue, 13 Apr 1993 19:19:16 +0200
Received: by moskau.ai.univie.ac.at id AA26930
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Tue, 13 Apr 1993 19:18:52 +0200
From: paolo petta <paolo@venedig.ai.univie.ac.at>
Message-Id: <199304131718.AA26930@moskau.ai.univie.ac.at>
Subject: Re: HTML to Postscript
To: www-talk@nxoc01.cern.ch
Date: Tue, 13 Apr 1993 19:18:50 +0200
X-Mailer: ELM [version 2.3 PL11]

[original message by Thomas A. Fine ]
> 
> On the other hand, I already have postscript that formats a string into
> a paragraph.  That's one of the major hurtles.  If there's another
> postscript wizard out there that wants to try it, let me know and I'll
> send you that bit of code.
> 

Also, the recently posted (comp.sources.postscript) "textpro" text
manipulation functions might come in handy if going directly to PostScript
(includes super- and subscripts, multiple fonts & sizes, centering and
right alignment, and full justification as well as functions to permit
printing of characters precisely centered on the current point,...)

pAolo
-- 
paolo petta                                            +43-1-5336112(Tel)
Austrian Research Inst. for Artificial Intelligence    +43-1-5320652(Fax)
Schottengasse 3, A-1010 Vienna, Austria, Europe     paolo@ai.univie.ac.at 

From fheyligh%vnet3.vub.ac.be@cc1.kuleuven.ac.be  Tue Apr 13 19:11:33 1993
Return-Path: <fheyligh%vnet3.vub.ac.be@cc1.kuleuven.ac.be>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20985; Tue, 13 Apr 93 19:11:33 MET DST
Received: from cc1.kuleuven.ac.be by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27731; Tue, 13 Apr 1993 19:31:03 +0200
Received: from rc1.vub.ac.be by cc1.kuleuven.ac.be (IBM VM SMTP V2R2) with TCP;
   Tue, 13 Apr 93 19:30:22 +0200
Received: from vnet3.vub.ac.be by rc1.vub.ac.be (4.1/RC1-930409)
	id AA17258; Tue, 13 Apr 93 19:31:14 +0200
Received: from [134.184.35.101] (pespmc1) by vnet3.vub.ac.be (4.1/VUB.920213)
	id AA19343; Tue, 13 Apr 93 19:31:08 +0200
Message-Id: <9304131731.AA19343@vnet3.vub.ac.be>
Date: Tue, 13 Apr 1993 19:32:16 +0100
To: www-talk@nxoc01.cern.ch
From: fheyligh@vnet3.vub.ac.be (Francis Heylighen)
Subject: Integrating Email into WWW?

A thought that just occurred to me (I'm new on this list, so this may
already have been discussed and/or dismissed...). 

The basic idea of WWW is to integrate all existing and new Internet
services: FTP, Gopher, WAIS, Newsgroups, etc. I haven't heard anything yet
about integrating email, though. WWW documents regularly contain links to
people, presenting an address, email address and perhaps more info on the
persons activities and affiliations. But these are just passive data. It
would be interesting if I read an interesting document that I could
directly contact the author without leaving my WWW browser. 

One intuitive way to implement this would be that if I select the person's
name (or email address) I would get a dialogue in which I can compose an
email message. This might follow the same conventions as the "forms" which
were discussed here recently: fields for "Subject:", "To: (by default
already filled in with the email address", "From: (default my own
address"), "Text:", etc. The idea is that sending an email message or
request to a person is not basically different from sending a query to a
database server (the main difference being that the person may be even
slower and more unreliable when it comes to getting the answer one would
like to have). 

Of course, this implies that the appropriate email protocol (SMTP?) would
be incorporated in HTTP. But that can remain hidden from the user. 

A similar interface could be written for mailing lists (like www-talk),
bringing them on the  same footing as the already existing interface to
Newsgroups...

_______________________________________________________________________
Dr. Francis Heylighen                                Systems Researcher
PO, Free University of Brussels, Pleinlaan 2, B -1050 Brussels, Belgium
Phone:+32-2-6412525; Fax:+32-2-6412489; Email: fheyligh@vnet3.vub.ac.be
_______________________________________________________________________


From marca@wintermute.ncsa.uiuc.edu  Tue Apr 13 19:20:19 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21185; Tue, 13 Apr 93 19:20:19 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29885; Tue, 13 Apr 1993 19:39:51 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA13096
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 13 Apr 93 12:39:49 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:timbl@nxoc01.cern.ch id AA20897; Tue, 13 Apr 93 12:42:01 -0500
Date: Tue, 13 Apr 93 12:42:01 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304131742.AA20897@wintermute.ncsa.uiuc.edu>
To: Guido.van.Rossum@cwi.nl
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: Project Gutenberg's Roget's Thesaurus 
In-Reply-To: <9304131637.AA24791=guido@voorn.cwi.nl>
References: <9304131637.AA24791=guido@voorn.cwi.nl>
	<9304131707.AA05778@www3.cern.ch>
X-Md4-Signature: df0b5b5bae12b8e41c525b79d94b22ed

Guido.van.Rossum@cwi.nl writes:
> >As more public domain hypertext comes on line, we are going to need
> >some big disks on each continent for it.  We should also perhaps use
> >some mirroring software to keep them up to date.
> 
> I see a problem coming here: how does an unreplicated document (say my
> own home page) mane a reference to such a replicated document?  If I
> have a reference to the closest replica, a user far away who follows
> such a link will get pointed to the replica closest to *me*, not
> closest to her.
> 
> Some possible solutions:
> 
> - a translation scheme whereby clients "know" (e.g. from a local
> configuration file that may be updated automatically as mirror sites
> are added) that information at host X is identical to info at host Y
> 
> - a magic string in hostnames that is translated dependent on the
> geographical position of the client (e.g.
> http://info-cern.closestmirror/...)
> 
> - upon first contact with a server, it might respond with "please
> try the following mirror site which is closer to you" (this could be
> put in HTTP2 I suppose).
> 
> This is a real problem with embedding location information in URLs...

Sounds like it's time to move URN's (or whatever persistent Internet
resource identifiers are being called these days) out of the theory
stage and into practice.... anyone know what the status of the URN
work that was/is apparently going somewhere in the IETF?

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From nholtz@civeng.carleton.ca  Tue Apr 13 19:32:59 1993
Return-Path: <nholtz@civeng.carleton.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21436; Tue, 13 Apr 93 19:32:59 MET DST
Received: from alfred.ccs.carleton.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02623; Tue, 13 Apr 1993 19:52:29 +0200
Received: from zonker.cascade.carleton.ca by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA07660; Tue, 13 Apr 93 13:52:33 EDT
Received: by zonker.cascade.carleton.ca (5.61/5.17)
	id AA08120; Tue, 13 Apr 93 13:50:20 -0400
From: nholtz@civeng.carleton.ca (Neal Holtz)
Message-Id: <9304131750.AA08120@zonker.cascade.carleton.ca>
Subject: Re: Integrating WWW with mail
To: www-talk@nxoc01.cern.ch
Date: Tue, 13 Apr 93 13:50:18 EDT
X-Mailer: ELM [version 2.3 PL11]

Francis Heylighen writes:
> ... It
> would be interesting if I read an interesting document that I could
> directly contact the author without leaving my WWW browser. 
> 
> One intuitive way to implement this would be that if I select the person's
> name (or email address) I would get a dialogue in which I can compose an
> email message. ...

This would be very nice.  Along those same lines, the Lynx stuff from the 
University of Kansas has the interesting concept of file "ownership".  A special
tag gives the email address of the owner of the file, and the hypertext
browsers allow you to send them mail.  This is really a subset of the idea
proposed above, but it might be useful to have that concept of ownership
without any explicit reference in the text.

> Of course, this implies that the appropriate email protocol (SMTP?) would
> be incorporated in HTTP. But that can remain hidden from the user. 

Couldn't the various browsers just use the existing mail delivery mechanisms
and programs?

-- 
Prof. Neal Holtz,  Dept. of Civil Eng.,  Carleton University,  Ottawa,  Canada
Internet: nholtz@civeng.carleton.ca  Ph: (613)788-2600x5797 Fax: (613)788-3951

From murphy@dccs.upenn.edu  Tue Apr 13 20:00:48 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22031; Tue, 13 Apr 93 20:00:48 MET DST
Received: from NOC2.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05985; Tue, 13 Apr 1993 20:20:16 +0200
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA20914; Tue, 13 Apr 93 14:20:14 -0400
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA09793; Tue, 13 Apr 93 14:19:52 -0400
Posted-Date: Tue, 13 Apr 93 14:19:51 -0400
Message-Id: <9304131819.AA09793@lam.dccs.upenn.edu>
To: fheyligh@vnet3.vub.ac.be (Francis Heylighen)
Subject: Re: Integrating Email into WWW? 
In-Reply-To: Your message of "Tue, 13 Apr 93 19:32:16 BST."
             <9304131731.AA19343@vnet3.vub.ac.be> 
Cc: www-talk@nxoc01.cern.ch
Date: Tue, 13 Apr 93 14:19:51 -0400
From: murphy@dccs.upenn.edu
X-Mts: smtp


Is multi-media electronic mail around the corner?

If I come across an interesting picture, piece of music, or
other non-text document in the Web, I'd like to be able to
attach that to an e-mail message and send it to a colleague.

Or, how about only embedding the identifier for the document
into the e-mail message, leaving it upto the mail-reading
client software at the recipient's host to parse the
identifier, track down the document on the Internet, and
present it to the user in a way that is reasonable for his
desktop environment?

--lam


From mvanheyn@cs.indiana.edu  Tue Apr 13 20:20:27 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22384; Tue, 13 Apr 93 20:20:27 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11795; Tue, 13 Apr 1993 20:39:59 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA12205; Tue, 13 Apr 1993 13:39:54 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: murphy@dccs.upenn.edu
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Integrating Email into WWW? 
In-Reply-To: Your message of "Tue, 13 Apr 1993 14:19:51 -0400."
             <9304131819.AA09793@lam.dccs.upenn.edu> 
Date: Tue, 13 Apr 1993 13:39:53 -0500
Message-Id: <12201.734726393@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: 
>Is multi-media electronic mail around the corner?

Yes.  It's called MIME.  There's a nice friedly guide to it available;
the URL is file://ftp.uu.net/networking/mail/mime/mime.ps and
obviously it's in postscript.  The real specs are in RFC 1341.
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted


What do you mean this is a real workstation?  Where's the pipe key?

From nholtz@civeng.carleton.ca  Tue Apr 13 21:34:56 1993
Return-Path: <nholtz@civeng.carleton.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23882; Tue, 13 Apr 93 21:34:56 MET DST
Received: from alfred.ccs.carleton.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23867; Tue, 13 Apr 1993 21:54:26 +0200
Received: from zonker.cascade.carleton.ca by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA14258; Tue, 13 Apr 93 15:54:30 EDT
Received: by zonker.cascade.carleton.ca (5.61/5.17)
	id AA08341; Tue, 13 Apr 93 15:52:19 -0400
From: nholtz@civeng.carleton.ca (Neal Holtz)
Message-Id: <9304131952.AA08341@zonker.cascade.carleton.ca>
Subject: Campus Wide Info Systems
To: www-talk@nxoc01.cern.ch
Date: Tue, 13 Apr 93 15:52:17 EDT
X-Mailer: ELM [version 2.3 PL11]

Our university is about to start installing some sort of a CWIS.  It will
almost surely be using existing software, with little new being developed
here.  The powers that be think it best to give the users a menu-based
system such as gopher or freenet.

I am arguing for a hypertext approach.  I know that because of all
the gateways and compatibilities that exist, almost any information
provider is accessible from almost any user interface.  Still, the hypertext
concept is a style of user interface that is usable with the lowest technology
(terminals on 2400 baud lines) but extends far further on better technology.
I'm not sure that my obviously wise [:-)] arguments are having enough effect.

If anyone has been through similar exercises and has some winning arguments,
and doesn't mind taking a few minutes to share them, I would be eternally
grateful.  My arguments for are:
	1. There is as much software available for that as any other approach
		(the web and/or lynx, for example).
	2. Other kinds of providers (WAIS, gopher, etc.) are still usable.
	3. The user interface with VT100 terminal emulators and 2400 baud
	   lines are just as good.
	4. They give you a much richer system with only a very slightly
	   more complex user interface.
	5. The user interface is MUCH better when you can move to higher
	   transfer rates and more local power.
	6. They will change to a hypertext concept in 3 or 4 years
  	   anyway.  Might just as well start that way.
-- 
Prof. Neal Holtz,  Dept. of Civil Eng.,  Carleton University,  Ottawa,  Canada
Internet: nholtz@civeng.carleton.ca  Ph: (613)788-2600x5797 Fax: (613)788-3951

From janssen@parc.xerox.com  Wed Apr 14 00:07:56 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27052; Wed, 14 Apr 93 00:07:56 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14451; Wed, 14 Apr 1993 00:27:26 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11801>; Tue, 13 Apr 1993 15:16:15 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 13 Apr 1993 15:16:07 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue, 13 Apr 1993 15:16:03 -0700 (PDT)
Message-Id: <AfmniXoB0KGWMgGNIE@holmes.parc.xerox.com>
Date: 	Tue, 13 Apr 1993 15:16:03 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: timbl@nxoc01.cern.ch, Guido.van.Rossum@cwi.nl
Subject: Re: Project Gutenberg's Roget's Thesaurus
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9304131637.AA24791=guido@voorn.cwi.nl>
References: <9304131637.AA24791=guido@voorn.cwi.nl>

Excerpts from ext.WorldWideWeb: 13-Apr-93 Re: Project Gutenberg's Rog..
Guido.van.Rossum@cwi.nl (1150)

> I see a problem coming here: how does an unreplicated document (say my
> own home page) make a reference to such a replicated document?  If I

We're trying out a system at PARC that has a similar problem.  Our
tentative solution, translated to URL terms, is that one particular
scheme of URL is a list of URL's, any of which can be used to access the
document.  This would allow the client to use whichever copy of the
document it ``decides'' is closest/cheapest.  We also have different URL
schemes that allow us to say, ``look up this UID in a name-service of
this type'' -- indirection.

Bill

From montulli@stat1.cc.ukans.edu  Wed Apr 14 02:48:05 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29148; Wed, 14 Apr 93 02:48:05 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05403; Wed, 14 Apr 1993 03:07:36 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA17086; Tue, 13 Apr 1993 20:00:36 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9304140100.AA17086@stat1.cc.ukans.edu>
Subject: CSO gateway
To: www-talk@nxoc01.cern.ch
Date: Tue, 13 Apr 93 20:00:35 CDT
X-Mailer: ELM [version 2.3 PL2]


I have been annoyed by the lack of CSO support in WWW clients
so I decided to try and write a CSO gateway. 

I sort of succeded and I sort of failed.

The only way that I could figure out how to make it work was
to rewrite the Gopher CSO link to be more friendly to a gateway.
This may or may not work to implement this in WWW.

Anyways, a breif explanation and a demo are in

"file://acs220.cc.ukans.edu/pub/cso.html"

or for those who don't read URLs that means it is available by
anonymous ftp from acs220.cc.ukans.edu in /pub as cso.html.

Tell me what you think!

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet                                 *
  *                         Kuhub.cc.ukans.edu                             *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!             913/864-0436           Lawrence, KS 66044  *
  *                                                                        *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************

From rik@daneel.rdt.monash.edu.au  Wed Apr 14 03:05:34 1993
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29379; Wed, 14 Apr 93 03:05:34 MET DST
Received: from daneel.rdt.monash.edu.au by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06801; Wed, 14 Apr 1993 03:25:00 +0200
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA27121; Wed, 14 Apr 93 11:24:50 +1000
Message-Id: <9304140124.AA27121@daneel.rdt.monash.edu.au>
To: www-talk@nxoc01.cern.ch
Subject: Re: Project Gutenberg's Roget's Thesaurus 
In-Reply-To: Your message of "13 Apr 93 18:07:08 +0100."
             <9304131707.AA05778@www3.cern.ch> 
Date: Wed, 14 Apr 93 11:24:49 +1100
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

> As more public domain hypertext comes on line, we are going to need
> some big disks on each continent for it.  We should also perhaps use
> some mirroring software to keep them up to date.
> 
> One possibility is we feed back the hypertext to Michael Hart.
> It could just be an overlay of files which have pointers to
> the actual text, or a smart server which can #include the
> actual text into a wrapper document.
> 
> Nat, do you thing the Gutenberg project would consider
> using their existing distribution chain for the stuff? We could
> set up W3 servers on some of their machines maybe?  It would
> take less CPU than FTP.

From reading the stuff Michael Hart has written, and the arguments in
the GUTNBERG mailing list, I'd be surprised if they'd go for this.  They
seem to be interested in providing only plain ASCII files, and nothing
else.  I don't want people to think I am criticising them, they are doing
a wonderful job, but they tend to stick to ASCII only.

(that's not to say it's not worth a go :-)

rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au
+61 3 560-3265 (AH & ans.mach)      +61 3 565-3227 (BH)
Faculty of Computing and Information Technology,
Clayton Campus, Monash University, Australia

From joe@athena.mit.edu  Wed Apr 14 03:29:47 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29562; Wed, 14 Apr 93 03:29:47 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09617; Wed, 14 Apr 1993 03:49:17 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA29558; Tue, 13 Apr 93 21:49:14 EDT
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA09133; Tue, 13 Apr 93 21:49:13 -0400
Date: Tue, 13 Apr 93 21:49:13 -0400
Message-Id: <9304140149.AA09133@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch
Subject: Is there any timetable for moving HTML-2.0 out of beta?


In particular, is there a deadline for when HTTP daemons will be 
expected to grok HTML-2.0?


From timbl@www3.cern.ch  Wed Apr 14 09:10:58 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02254; Wed, 14 Apr 93 09:10:58 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25393; Wed, 14 Apr 1993 09:30:33 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06019; Wed, 14 Apr 93 09:28:17 +0100
Date: Wed, 14 Apr 93 09:28:17 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304140828.AA06019@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "William M. Perry" <wmperry@papaya.ucs.indiana.edu>
Subject: Re: Project Gutenberg's Roget's Thesaurus
Cc: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


| Date: Tue, 13 Apr 1993 11:14:42 -0500
| From: "William M. Perry" <wmperry@papaya.ucs.indiana.edu>

| Tim Berners-Lee writes:
| [...]
| >One possibility is we feed back the hypertext to Michael Hart.
| >It could just be an overlay of files which have pointers to
| >the actual text, or a smart server which can #include the
| >actual text into a wrapper document.
| [...]
| 

|    Are there any plans to have an html tag to include a file?  That  
way you
| wouldn't have to depend on a server being smart enough to include  
the file.
| Something akin to the IMG tag now.  ie: <INCLUDE SRC="XXXXXX">, and
| possibly <INCLUDE SRC="HTTP://fqdn:80/XXXXXX">.

If we were to adopt it, then the we should use the SGML entity  
scheme. Basically, this involves declaring a new entity
(thing which is inserted with a &   sign) as being an
external object with a given URL, and then making a reference
to that entity.  But we're talking about something slightly different
from what I was suggesting, in that the these tags or entities
would be picked up by the client, whereas I was thinking
of something implemented on the server which would be
invisible to the client.  It would be faster that way, and not
require any extensions either, like you could do it tomorrow with cpp
for example.

Tim


From guido@cwi.nl  Wed Apr 14 09:59:38 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02744; Wed, 14 Apr 93 09:59:38 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04037; Wed, 14 Apr 1993 10:19:07 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA13416 (5.65b/3.8/CWI-Amsterdam); Wed, 14 Apr 1993 10:19:03 +0200
Received: by voorn.cwi.nl with SMTP
	id AA26213 (5.65b/3.8/CWI-Amsterdam); Wed, 14 Apr 1993 10:19:01 +0200
Message-Id: <9304140819.AA26213=guido@voorn.cwi.nl>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: Project Gutenberg's Roget's Thesaurus 
In-Reply-To: Your message of "Tue, 13 Apr 1993 15:16:03 MDT."
             <AfmniXoB0KGWMgGNIE@holmes.parc.xerox.com> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Wed, 14 Apr 1993 10:19:01 +0200
Sender: Guido.van.Rossum@cwi.nl

>> I see a problem coming here: how does an unreplicated document (say my
>> own home page) make a reference to such a replicated document?  If I
>
>We're trying out a system at PARC that has a similar problem.  Our
>tentative solution, translated to URL terms, is that one particular
>scheme of URL is a list of URL's, any of which can be used to access the
>document.  This would allow the client to use whichever copy of the
>document it ``decides'' is closest/cheapest.  We also have different URL
>schemes that allow us to say, ``look up this UID in a name-service of
>this type'' -- indirection.

A list of URL's might work in some cases, but in general this means
that adding a new mirror site requires updating all references...

A name service sounds like a better solution -- bot how to integrate
this in HTML or HTTP?  And who's going to run the name service?  Or
could we use some existing name service?  (Perhaps DNS is flexible
enough to return a list of hosts for certain names, from which the
client could choose?  This would be ideal.  Anyone know anything about
DNS?)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From timbl@www3.cern.ch  Wed Apr 14 10:00:56 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02771; Wed, 14 Apr 93 10:00:56 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04614; Wed, 14 Apr 1993 10:20:29 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06075; Wed, 14 Apr 93 10:18:13 +0100
Date: Wed, 14 Apr 93 10:18:13 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304140918.AA06075@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: *whew* Internet Services List (kinda) hypertexted
Cc: Scott A. Yanoff <yanoff@csd4.csd.uwm.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


| Date: Sun, 11 Apr 1993 22:16:43 +1200
| From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
| 

| I've just spend the last three or so hours marking up the Internet
| Services List so that it
|  a) has a presentable structure, and
|  b) has links to everything

Oops!   I did the same thing a year or so back, and Scott has been
keeping the HTML up to date.  It is currently in
http://info.cern.chl/hypertext/DataSources/Yanoff.html
which has links from the "Information by type of server" page,
under telnet sites, as that is mostly what it is.

I suggest anyone who wants a local copy get onto Scott's mailing list
for the new releases of the hypertext version.  


Perhaps, Tony, you could keep a definitive version.  Scott doesn't  
seem to use any WWW tool himself and so sometimes it is necessary to  
check out the HTML and tweak a few typos with each release. Nathan,  
you might find that you want to improve the look of it and feed it  
back to Scott.

(Of course the ideal thing would be to persuade Scott to run a server
and serve it from source, if he has access to a reliable machine)

If anyone does end up serving this, let me know and I will stop
and update my pointers.

Tim


From emv@garnet.msen.com  Wed Apr 14 10:44:00 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03170; Wed, 14 Apr 93 10:44:00 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15037; Wed, 14 Apr 1993 11:03:27 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nj3NJ-001IJ4C@garnet.msen.com>; Wed, 14 Apr 93 05:03 WET DST
Message-Id: <m0nj3NJ-001IJ4C@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: my part of the web
Date: Wed, 14 Apr 93 05:03:07 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

If anyone has pointers to
	file://ftp.msen.com:/pub/emv/web/*.html
please note that I'm grovelling around in that directory quite a bit
these days and i'm trying (valiantly, i hope) to deuglify some stuff
that's there.

thanks

From timbl@www3.cern.ch  Wed Apr 14 15:40:58 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07158; Wed, 14 Apr 93 15:40:58 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14487; Wed, 14 Apr 1993 16:00:32 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06272; Wed, 14 Apr 93 15:58:17 +0100
Date: Wed, 14 Apr 93 15:58:17 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304141458.AA06272@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: joe@athena.mit.edu
Subject: Re: Is there any timetable for moving HTML-2.0 out of beta?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

| From: joe@athena.mit.edu
| Date: Tue, 13 Apr 93 21:49:13 -0400
| 

| In particular, is there a deadline for when HTTP daemons will be 

| expected to grok HTML-2.0?

I assume you mean  ^^^^ HTTP.

I haven't made a deadline, but one thing is imperitive, and that is
that any existing server or database which falls over given a third  
word on the HTTP request line MUST be upgraded immediately. These
servers are just buggy.  (mea culpa, I know!)

I notice that although new gopher servers seem to handle HTTP,
they treat any thirs word as a search term (instead of extracting
it from a ?xx+yy+zz suffix on the URL) and so break on full HTTP.

I have just fixed the techinfo gateway.

Tim

From dcmartin@lib.ucsf.edu  Wed Apr 14 19:34:39 1993
Return-Path: <dcmartin@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11986; Wed, 14 Apr 93 19:34:39 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25889; Wed, 14 Apr 1993 19:53:50 +0200
Received: from knowman.lib.ucsf.EDU by mcsun.EU.net with SMTP
	id AA04660 (5.65b/CWI-2.217); Wed, 14 Apr 1993 19:53:48 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA15799; Wed, 14 Apr 93 10:53:23 PDT
Message-Id: <9304141753.AA15799@knowman.lib.ucsf.EDU>
From: dcmartin@ckm.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: www-talk@nxoc01.cern.ch
Precedence: special-delivery
Subject: DNS & WWW
Date: Wed, 14 Apr 93 10:50:12 MDT
Sender: dcmartin@lib.ucsf.edu

Yes, DNS already has a facility to allow for multiple machines to be
considered capable of providing some service, either mail exchange (MX)
or providing the names of servers which can identify a host.

MX records are probably closest to what you want, since they allow for
multiple machines to be specified as mail exchange hosts with weighting
for the preferred and non-preferred hosts.

There are also Well Known Service (WKS) descriptions for hosts (e.g. ftp,
telnet, etc...) which would be analagous to advertising WWW, WAIS, Gopher,
etc.. 

dcm

From mike@fionn.lbl.gov  Wed Apr 14 20:44:25 1993
Return-Path: <mike@fionn.lbl.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12618; Wed, 14 Apr 93 20:44:25 MET DST
Received: from fionn.lbl.gov by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10532; Wed, 14 Apr 1993 21:03:51 +0200
Received: by fionn.lbl.gov (4.1/1.39)
	id AA00704; Wed, 14 Apr 93 12:03:46 PDT
Message-Id: <9304141903.AA00704@fionn.lbl.gov>
From: mike@fionn.lbl.gov (Michael Helm)
Date: Wed, 14 Apr 1993 12:03:45 PDT
In-Reply-To: dcmartin@ckm.ucsf.edu (David C. Martin)
       "DNS & WWW" (Apr 14, 10:50am)
Reply-To: mike@fionn.lbl.gov
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: www-talk@nxoc01.cern.ch
Subject: Re: DNS & WWW

On Apr 14, 10:50am, David C. Martin wrote:
> MX records are probably closest to what you want, since they allow for
> multiple machines to be specified as mail exchange hosts with weighting
> for the preferred and non-preferred hosts.

Perhaps someone should begin thinking about this & working
with the people who work on the DNS standards.  I'm not
sure WKS is used for much of anything & whether every implementation
can deal with it -- it never caut on.  Maybe a new kind of
record is needed, analogous to MX records, an IX record for
information exchangers?

From emv@garnet.msen.com  Wed Apr 14 22:18:01 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14181; Wed, 14 Apr 93 22:18:01 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26457; Wed, 14 Apr 1993 22:37:34 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0njED4-001IF4C@garnet.msen.com>; Wed, 14 Apr 93 16:37 WET DST
Message-Id: <m0njED4-001IF4C@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: WAIS databases as first class WWW objects
Date: Wed, 14 Apr 93 16:37:15 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

I'd like to see WAIS databases treated as first class objects in WWW.

For instance URLs like
	wais://wais.msen.com:210/reuters?
to define a database, and
	wais://wais.msen.com:210/reuters?communications
to define a search.

This probably involves moving code from the www-to-wais gateway into
the client library, or having "smart" clients go off and use 
"full featured" wais clients when they are presented with serviers.

The next step of this is to take the wais directory of servers and
add value to it by writing a .src->.html converter that makes things
look really nice.

--Ed

From janssen@parc.xerox.com  Wed Apr 14 23:24:17 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14905; Wed, 14 Apr 93 23:24:17 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04408; Wed, 14 Apr 1993 23:43:40 +0200
Received: from alpha.Xerox.COM by mcsun.EU.net with SMTP
	id AA12396 (5.65b/CWI-2.217); Wed, 14 Apr 1993 23:43:31 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12041>; Wed, 14 Apr 1993 14:41:42 PDT
Received: by holmes.parc.xerox.com id <16134>; Wed, 14 Apr 1993 14:41:37 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 14 Apr 1993 14:41:30 -0700 (PDT)
Message-Id: <Ufn8I_8B0KGW4gGQl8@holmes.parc.xerox.com>
Date: 	Wed, 14 Apr 1993 14:41:30 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Guido.van.Rossum@cwi.nl
Subject: Re: Project Gutenberg's Roget's Thesaurus
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9304140819.AA26213=guido@voorn.cwi.nl>
References: <9304140819.AA26213=guido@voorn.cwi.nl>

Excerpts from ext.WorldWideWeb: 14-Apr-93 Re: Project Gutenberg's Rog..
Guido.van.Rossum@cwi.nl (1149)

> A list of URL's might work in some cases, but in general this means
> that adding a new mirror site requires updating all references...

Yes, and in addition, it means that choosing an appropriate URL is up to
some client heuristics.  However, it does have the merit of not
requiring a round-trip conversation with the name service, which is
important to us.  I think the suggestion of having some kind of
meta-URL, which could be interpreted locally, would also merit more
thought.  Some sort of macrology like imake uses (ugh :-).  This would
solve some of the problems of a static list, without necessarily
requiring name service round trips.

Bill


From Nathan.Torkington@vuw.ac.nz  Thu Apr 15 02:39:10 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16735; Thu, 15 Apr 93 02:39:10 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24708; Thu, 15 Apr 1993 02:58:33 +0200
Received: by kauri.vuw.ac.nz id AA24137
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 15 Apr 1993 12:58:27 +1200
Date: Thu, 15 Apr 1993 12:58:27 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304150058.AA24137@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Edward Vielmetti's message <m0njED4-001IF4C@garnet.msen.com>
Subject: WAIS databases as first class WWW objects

Edward Vielmetti writes:

> I'd like to see WAIS databases treated as first class objects in WWW.

Testify!

> This probably involves moving code from the www-to-wais gateway into
> the client library, or having "smart" clients go off and use 
> "full featured" wais clients when they are presented with serviers.

I prefer the move into the client library, myself.  It would be
exceptionally simple to do -- just steal some of the code from the
existing gateway and munge munge munge.

> The next step of this is to take the wais directory of servers and
> add value to it by writing a .src->.html converter that makes things
> look really nice.

Yes!  Yes!  Such a converter should:
 o recognise news.group.format
 o recognise anonymous:/ftp/references
 o recognise maintainer@e-mail.addresses

Hmm, there must be more -- if that were all, I could do it with sed
commands:

s/([A-Za-z0-9-\.])+/<A HREF="news:\1">\1<\/A>/
s/([A-Za-z0-9-\.]+)(:?/?)([A-Za-z0-9-\.\/]+)/<A HREF="file:\/\/\1\/\3">\1\2\3<\/A>/
s/([A-Za-z0-9-\.]+@[A-Za-z0-9-\.])/<ADDRESS>\1<\/ADDRESS>/

Nat.

From marca@wintermute.ncsa.uiuc.edu  Thu Apr 15 08:46:24 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19725; Thu, 15 Apr 93 08:46:24 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21290; Thu, 15 Apr 1993 09:05:59 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11642
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 15 Apr 93 02:05:57 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA27356; Thu, 15 Apr 93 02:08:09 -0500
Date: Thu, 15 Apr 93 02:08:09 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304150708.AA27356@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: beginner's guide to html
X-Md4-Signature: 50d5b075c9d77da5dd47846dbb937798

In response to assorted requests and queries, I have written a simple
"Beginner's Guide" to writing documents in HTML.  It's up for grabs at
http://www.ncsa.uiuc.edu/demoweb/html-primer.html at the moment;
comments are welcome (but no complaints about my coverage or use of
the IMG tag that Mosaic supports; it's important internally).  

The guide also points to a rudimentary primer on URL's that might be
of interest to Web beginners (certainly the number of people who have
sent me Mosaic bug reports saying "URL 'machine.com' doesn't connect
to the ftp server", etc., would seem to indicate that basic knowledge
of URL's is not yet a given on the net).

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Thu Apr 15 09:23:56 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20023; Thu, 15 Apr 93 09:23:56 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04192; Thu, 15 Apr 1993 09:43:31 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06587; Thu, 15 Apr 93 09:41:14 +0100
Date: Thu, 15 Apr 93 09:41:14 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304150841.AA06587@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Project Gutenberg's Roget's Thesaurus 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


| Date: Tue, 13 Apr 93 12:42:01 -0500
| From: marca@ncsa.uiuc.edu (Marc Andreessen)

 

| Guido.van.Rossum@cwi.nl writes:
[...]
| > I see a problem coming here: how does an unreplicated document  
(say my
| > own home page) mane a reference to such a replicated document?   
If I
| > have a reference to the closest replica, a user far away who  
follows
| > such a link will get pointed to the replica closest to *me*, not
| > closest to her.
| > 

| > Some possible solutions:
| > 

| > - a translation scheme whereby clients "know" (e.g. from a local
| > configuration file that may be updated automatically as mirror  
sites
| > are added) that information at host X is identical to info at  
host Y

Yes, this is possible with the 2.0 library.  The line mode client
doesn't have the command line option yet, but the client library
can use a rule file, just like a server.

| > - a magic string in hostnames that is translated dependent on the
| > geographical position of the client (e.g.
| > http://info-cern.closestmirror/...)


This has been discussed, in fact having a host name which translates
info many IP addresses -- all the apparatus is there already in DNS
and most people say it won't break anything, we just need code to, if
DNS returns >1 IP address, ping them all to get the closest and  
remember which one it is.

| > - upon first contact with a server, it might respond with "please
| > try the following mirror site which is closer to you" (this could  
be
| > put in HTTP2 I suppose).


This is already the HTTP2 spec.  The reply field can be a "forward"
reply containing a pointer to the real object.  That is, HTTP2  
servers can be used as name servers.  No code yet in the library.
See http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRESP.html#z9

| > This is a real problem with embedding location information in  
URLs...
| 

| Sounds like it's time to move URN's (or whatever persistent  
Internet
| resource identifiers are being called these days) out of the theory
| stage and into practice.... anyone know what the status of the URN
| work that was/is apparently going somewhere in the IETF?

I thought it was going to get closer, but basically it was agreed  
that the format urn:publisher/id would work with a finite number of  
publishers.  I think you might see Peter Deutch and Chis Weider maybe  
putting some code together???

Remember that if you have to contact a name server every time,
you slow things down anyway. Basically, a little common sense 

in the client would guess that a related document was avalable from
the same server as last time.

Tim

From guido@cwi.nl  Thu Apr 15 09:27:26 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20076; Thu, 15 Apr 93 09:27:26 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04681; Thu, 15 Apr 1993 09:46:58 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA01311 (5.65b/3.8/CWI-Amsterdam); Thu, 15 Apr 1993 09:46:53 +0200
Received: by voorn.cwi.nl with SMTP
	id AA28500 (5.65b/3.8/CWI-Amsterdam); Thu, 15 Apr 1993 09:46:53 +0200
Message-Id: <9304150746.AA28500=guido@voorn.cwi.nl>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Project Gutenberg's Roget's Thesaurus 
In-Reply-To: Your message of "Wed, 14 Apr 1993 14:41:30 MDT."
             <Ufn8I_8B0KGW4gGQl8@holmes.parc.xerox.com> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Thu, 15 Apr 1993 09:46:52 +0200
Sender: Guido.van.Rossum@cwi.nl

>Yes, and in addition, it means that choosing an appropriate URL is up to
>some client heuristics.  However, it does have the merit of not
>requiring a round-trip conversation with the name service, which is
>important to us.  I think the suggestion of having some kind of
>meta-URL, which could be interpreted locally, would also merit more
>thought.  Some sort of macrology like imake uses (ugh :-).  This would
>solve some of the problems of a static list, without necessarily
>requiring name service round trips.

Why is avoiding a name server roundtrip important to you?  There's one
anyway in links of this type (the hostnames that it links to).  I
wouldn't think these roundtrips were very expensive?  (I never relly
notice delays around here.)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From ccprl@xdm001.ccc.cranfield.ac.uk  Thu Apr 15 11:43:12 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21626; Thu, 15 Apr 93 11:43:12 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23772; Thu, 15 Apr 1993 12:02:46 +0200
Received: by xdm001 
	id AA04621; Thu, 15 Apr 93 11:02:40 +0100
Received: by xdm039 (5.57/4.7) id AA27089; Thu, 15 Apr 93 11:02:35 +0100
Message-Id: <9304151002.AA27089@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: URLs and DNS
In-Reply-To: Your message of "Thu, 15 Apr 93 08:20:26 BST."
             <9304150720.AA02142@xdm001> 
Date: Thu, 15 Apr 93 11:02:30 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> The guide also points to a rudimentary primer on URL's that might be
> of interest to Web beginners (certainly the number of people who have
> sent me Mosaic bug reports saying "URL 'machine.com' doesn't connect
> to the ftp server", etc., would seem to indicate that basic knowledge
> of URL's is not yet a given on the net).

IMHO, URLs should have the same sort of status as numeric IP address -
a low-level format that must be agreed on by all, but essentially
invisible to end-users. I include WWW administrators among "end-users";
they don't need to be Unix/IP wizards to manage a few HTML docs and a
couple of databases. Certainly translating a "normal" FTP reference to
a URL is NOT fun for most users. URLs should be hidden behind DNS, just
like numeric IP addresses. I applaud the notion of a MX style record as
a start at least.

I did ask some time ago if Xmosaic could have a simple FTP window, to
prompt the user for a hostname (optionally dir/file name, username and
password) - maybe you'd get less false bug reports if you built it in,
Marc. I really do think that XMosaic would become very popular as a
value-added replacement FTP client.

Also, I would like to see a DNS and/or Hesiod URL registered, so that I
can get info directly from DNS/Hesiod in the same way as X500 or any
other service. Far more useful than an AFS URL, Tim.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875


From tom%begbick.law.cornell.edu@router.mail.cornell.edu  Thu Apr 15 12:23:43 1993
Return-Path: <tom%begbick.law.cornell.edu@router.mail.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21941; Thu, 15 Apr 93 12:23:43 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04930; Thu, 15 Apr 1993 12:43:18 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160566(2)>; Thu, 15 Apr 1993 06:43:10 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA05930; Thu, 15 Apr 93 06:35:10 EDT
Date: Thu, 15 Apr 1993 06:35:10 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9304151035.AA05930@begbick.law.cornell.edu.law.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: SMTP scheme


Folks:

Let me add my vote to Neil's in favor of an smtp:// scheme. I was in
fact on the verge of adding some such thing unilaterally to Cello (as
part of the support for CSO that Lou wants, as it happens).  I had in
mind something like:

    smtp://someone@somewhere/Subject:optional header line/...

with possibly any number of header lines following delimited by
slashes...

Are there better ways?

Regards,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From eostrom@nic.gac.edu  Thu Apr 15 19:23:38 1993
Return-Path: <eostrom@nic.gac.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28438; Thu, 15 Apr 93 19:23:38 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09911; Thu, 15 Apr 1993 19:43:15 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 0902; Thu, 15 Apr 93 19:43:20 SET
Received: from GACVAX1.BITNET (NJE origin SMTPUSER@GACVAX1) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 8912; Thu, 15 Apr 1993 19:43:20 +0200
Received: from next-7 (next-7.gac.edu) by gacvx1.gac.edu with PMDF#10127; Thu,
 15 Apr 1993 10:40 CST
Received: by next-7 (NeXT-1.0 (From Sendmail 5.52)/GACnet-2.0-NeXT) id AA01375;
 Thu, 15 Apr 93 11:35:31 CDT
Date: Thu, 15 Apr 93 11:35:31 CDT
From: eostrom@nic.gac.edu (Erik Ostrom)
Subject: Gopher+ and URLs
To: www-talk@nxoc01.cern.ch
Message-Id: <9304151635.AA01375@next-7>
X-Envelope-To: www-talk@nxoc01.cern.ch

(If there's a better forum for discussion of URLs, let me know.)

At the Gopher conference this Monday, a few people tried to convince
the UMN Gopher team to alter Gopher+ to use URLs.  (I wasn't one of
them, but I agreed.)  Having done a little hacking today on the
gopher-handling part of w3.el, though, I'm wondering about the
interaction of two facts:

>The path is interpreted in a manner dependent on the protocol being used.
>However, when it contains slashes, these must imply a hierarchical structure.
(from the URL spec)

but the Gopher protocol insists on the opacity of selector strings.
That is, if a Gopher selector string is "fumble/foo/.././bar/../baz", it
is *just that*, not "fumble/baz", which URL interpreters would come up
with.

I think this could be gotten around by quoting slashes in the path
part of a URL, although I'm not quite sure where the unquoting takes
place, so this might not work.  However, this seems unnecessary to me.
I guess what I want to ask is, why is any URL that contains a slash
forced into a hierarchical interpretation?  I would prefer that
specific schemes (http, ftp, afs, prospero?) be classified as
hierarchical, and hierarchy-based translations be limited to those
schemes.  New schemes, as they appear, can specify whether or not they
follow the standard hierarchical-structure rules.

This implies, of course, that if a client isn't familiar with a given
scheme, of course, it can't know whether or not to perform
translations on URLs in that scheme.  I'm not convinced that this is a
bad thing--if a program doesn't understand an address, it can just
pass it off to another program (e.g., a gateway) that does.

So, what am I overlooking?  I realize this would require clients to
store an additional piece of information for each scheme (hierarchical
bit), but this doesn't seem like a great cost to me in exchange for
some opacity of paths.

From janssen@parc.xerox.com  Thu Apr 15 20:12:55 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29326; Thu, 15 Apr 93 20:12:55 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20197; Thu, 15 Apr 1993 20:32:31 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11645>; Thu, 15 Apr 1993 11:32:11 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 15 Apr 1993 11:32:05 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 15 Apr 1993 11:31:57 -0700 (PDT)
Message-Id: <wfnOcRIB0KGWIo73EF@holmes.parc.xerox.com>
Date: 	Thu, 15 Apr 1993 11:31:57 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Bill Janssen <janssen@parc.xerox.com>, Guido.van.Rossum@cwi.nl
Subject: Re: Project Gutenberg's Roget's Thesaurus
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9304150746.AA28500=guido@voorn.cwi.nl>
References: <9304150746.AA28500=guido@voorn.cwi.nl>

Excerpts from ext.WorldWideWeb: 15-Apr-93 Re: Project Gutenberg's Rog..
Guido.van.Rossum@cwi.nl (815)

> Why is avoiding a name server roundtrip important to you?  There's one
> anyway in links of this type (the hostnames that it links to).

Right, and consulting a name-server every time would double the
round-trips.  It can also involve TCP setup around here, and process
context switches with your application (yep, every machine runs a local
name server).  All expensive -- and we're trying to keep our objects
light-weight.

Bill

From pandora@fernwood.mpk.ca.us  Thu Apr 15 21:02:33 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00358; Thu, 15 Apr 93 21:02:33 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28344; Thu, 15 Apr 1993 21:22:08 +0200
Received: by fernwood.mpk.ca.us; id AA05399; Thu, 15 Apr 93 11:23:12 -0700
From: mitra@pandora.sf.ca.us (Mitra)
Date: Thu, 15 Apr 1993 11:17:26 PDT
In-Reply-To:  eostrom@nic.gac.edu (Erik Ostrom)
       "Gopher+ and URLs" (Apr 15,  9:35am)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: eostrom@nic.gac.edu, www-talk@nxoc01.cern.ch
Subject: Re: Gopher+ and URLs
Cc: 
Message-Id:  <9304151117.aa25951@pandora.sf.ca.us>

Why worry about this Erik - the slashes in gopher are as hierarchical as 
in any other protocol and DO refer to the location in the directory structure.

OTOH - it is possible in the URL spec to define an opaque selector, and I
believe that the gopher one is defined that way.

- Mitra

From janssen@parc.xerox.com  Thu Apr 15 21:15:37 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00587; Thu, 15 Apr 93 21:15:37 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00851; Thu, 15 Apr 1993 21:35:13 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11679>; Thu, 15 Apr 1993 12:34:05 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 15 Apr 1993 12:33:55 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 15 Apr 1993 12:33:48 -0700 (PDT)
Message-Id: <ofnPWQ8B0KGWIo77lq@holmes.parc.xerox.com>
Date: 	Thu, 15 Apr 1993 12:33:48 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: some XMosaic questions

Figured I'd try here first...

1)  How does one fetch a binary or postscript file to a local file,
using XMosaic?  My postscript viewer doesn't let me save the viewed file
to another file...

2)  Has anyone put together a set of Emacs-style keybindings for the
Motif widgets?  Is it even possible?

Bill

From marca@wintermute.ncsa.uiuc.edu  Thu Apr 15 21:37:27 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00841; Thu, 15 Apr 93 21:37:27 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04060; Thu, 15 Apr 1993 21:57:03 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26395
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 15 Apr 93 14:57:01 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA29232; Thu, 15 Apr 93 14:59:17 -0500
Date: Thu, 15 Apr 93 14:59:17 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304151959.AA29232@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: www-talk@nxoc01.cern.ch
Subject: some XMosaic questions
In-Reply-To: <ofnPWQ8B0KGWIo77lq@holmes.parc.xerox.com>
References: <ofnPWQ8B0KGWIo77lq@holmes.parc.xerox.com>
X-Md4-Signature: 18fec4066af35165eeffed2ef8b92a46

Bill Janssen writes:
> 1)  How does one fetch a binary or postscript file to a local file,
> using XMosaic?  My postscript viewer doesn't let me save the viewed file
> to another file...

One doesn't, yet -- or one gets a better PostScript viewer :-).  As
the docs say, the "multimedia" support in there now is a hack and will
be better in the future.

> 2)  Has anyone put together a set of Emacs-style keybindings for the
> Motif widgets?  Is it even possible?

From the ol' Motif FAQ....

-----------------------------------------------------------------------------
Subject: 41) Is there an emacs binding for the text widget?

Answer: This set is due to Kee Hinckley (nazgul@alfalfa.com):

*XmText.translations: #override\n\
        Ctrl <Key>b:            backward-character()\n\
        Alt <Key>b:             backward-word()\n\
        Meta <Key>b:            backward-word()\n\
        Shift Alt <Key>b:       backward-word(extend)\n\
        Shift Meta <Key>b:      backward-word(extend)\n\
        Alt <Key>[:             backward-paragraph()\n\
        Meta <Key>[:            backward-paragraph()\n\
        Shift Alt <Key>[:       backward-paragraph(extend)\n\
        Shift Meta <Key>[:      backward-paragraph(extend)\n\
        Alt <Key><:             beginning-of-file()\n\
        Meta <Key><:            beginning-of-file()\n\
        Ctrl <Key>a:            beginning-of-line()\n\
        Shift Ctrl <Key>a:      beginning-of-line(extend)\n\
        Ctrl <Key>osfInsert:    copy-clipboard()\n\
        Shift <Key>osfDelete:   cut-clipboard()\n\
        Shift <Key>osfInsert:   paste-clipboard()\n\
        Alt <Key>>:             end-of-file()\n\
        Meta <Key>>:            end-of-file()\n\
        Ctrl <Key>e:            end-of-line()\n\
        Shift Ctrl <Key>e:      end-of-line(extend)\n\
        Ctrl <Key>f:            forward-character()\n\
        Alt <Key>]:             forward-paragraph()\n\
        Meta <Key>]:            forward-paragraph()\n\
        Shift Alt <Key>]:       forward-paragraph(extend)\n\
        Shift Meta <Key>]:      forward-paragraph(extend)\n\
        Ctrl Alt <Key>f:        forward-word()\n\
        Ctrl Meta <Key>f:       forward-word()\n\
        Ctrl <Key>d:            kill-next-character()\n\
        Alt <Key>BackSpace:     kill-previous-word()\n\
        Meta <Key>BackSpace:    kill-previous-word()\n\
        Ctrl <Key>w:            key-select() kill-selection()\n\
        Ctrl <Key>y:            unkill()\n\
        Ctrl <Key>k:            kill-to-end-of-line()\n\
        Alt <Key>Delete:        kill-to-start-of-line()\n\
        Meta <Key>Delete:       kill-to-start-of-line()\n\
        Ctrl <Key>o:            newline-and-backup()\n\
        Ctrl <Key>j:            newline-and-indent()\n\
        Ctrl <Key>n:            next-line()\n\
        Ctrl <Key>osfLeft:      page-left()\n\
        Ctrl <Key>osfRight:     page-right()\n\
        Ctrl <Key>p:            previous-line()\n\
        Ctrl <Key>g:            process-cancel()\n\
        Ctrl <Key>l:            redraw-display()\n\
        Ctrl <Key>osfDown:      next-page()\n\
        Ctrl <Key>osfUp:        previous-page()\n\
        Ctrl <Key>space:        set-anchor()\n


! If you'd like the Delete key to work like backspace instead of deleting
! backwards, add the following definition to the lines above.
!       <Key>osfDelete: delete-previous-character()\n\

! These aren't included because they could intefere with
| menu accelerators (or vice versa)
!       Alt <Key>p:             backward-paragraph()\n\
!       Meta <Key>p:            backward-paragraph()\n\
!       Shift Alt<Key>p:        backward-paragraph(extend)\n\
!       Shift Meta<Key>p:       backward-paragraph(extend)\n\
!       Alt <Key>w:             copy-clipboard()\n\
!       Meta <Key>w:            copy-clipboard()\n\
!       Ctrl Alt <Key>w:        cut-clipboard()\n\
!       Ctrl Meta <Key>w:       cut-clipboard()\n\
!       Alt <Key>y:             paste-clipboard()\n\
!       Meta <Key>y:            paste-clipboard()\n\
!       Alt <Key>f:             forward-word()\n\
!       Meta <Key>f:            forward-word()\n\
!       Alt <Key>n:             forward-paragraph()\n\
!       Meta <Key>n:            forward-paragraph()\n\
!       Shift Alt <Key>n:       forward-paragraph(extend)\n\
!       Shift Meta <Key>n:      forward-paragraph(extend)\n\
!       Shift Alt <Key>f:       forward-word(extend)\n\
!       Shift Meta <Key>f:      forward-word(extend)\n\
!       Alt <Key>d:             kill-next-word()\n\
!       Meta <Key>d:            kill-next-word()\n\
!       Alt <Key>h:             select-all()\n\
!       Meta <Key>h:            select-all()\n\

Similar sets of translations have been suggested by others.
------------------------------------------------------------------------------

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From emv@garnet.msen.com  Fri Apr 16 06:03:20 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06636; Fri, 16 Apr 93 06:03:20 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15943; Fri, 16 Apr 1993 06:22:57 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0njhww-001IDqC@garnet.msen.com>; Fri, 16 Apr 93 00:22 WET DST
Message-Id: <m0njhww-001IDqC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: (fwd) March IETF: On-line Minutes
Newsgroups: list.ietf
Organization: Msen, Inc. -- Ann Arbor, MI (account info +1 313 998-4562)
Date: Fri, 16 Apr 93 00:22:35 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

convert to html ?  --Ed

Path: nigel.msen.com!heifetz!news-mail-gateway
From: minutes@CNRI.Reston.VA.US
Subject: March IETF: On-line Minutes
Date: Thu, 15 Apr 1993 12:35:39 GMT


Below is a list of Minutes from the March IETF which are available
from the IETF remote directories.  For specific instructions on
retrieval, please send a message to minutes@cnri.reston.va.us.

Debra

========

March IETF Minutes
------------------

822ext/822ext-minutes-93mar.txt
93mar/atmmib-minutes-93mar.txt
93mar/confctrl-minutes-93mar.txt
93mar/frnetmib-minutes-93mar.txt
93mar/giss-minutes-93mar.txt
93mar/gopher-minutes-93mar.txt
93mar/imap-minutes-93mar.txt
93mar/loip-minutes-93mar.txt
93mar/modemgt-minutes-93mar.txt
93mar/snamib-minutes-93mar.txt
93mar/www-minutes-93mar.txt
appleip/appleip-minutes-93mar.txt
atm/atm-minutes-93mar.txt
cat/cat-minutes-93mar.txt
idmr/idmr-minutes-93mar.txt
ids/ids-minutes-93mar.txt
iiir/iiir-minutes-93mar.txt
iplpdn/iplpdn-minutes-93mar.txt
isis/isis-minutes-93mar.txt
isn/isn-minutes-93mar.txt
nir/nir-minutes-93mar.txt
nisi/nisi-minutes-93mar.txt
oda/oda-minutes-93mar.txt
ospf/ospf-minutes-93mar.txt
pem/pem-minutes-93mar.txt
pip/pip-minutes-93mar.txt
pppext/pppext-iplpdn-minutes-93mar.txt
pppext/pppext-minutes-93mar.txt
telnet/telnet-minutes-93mar.txt
thinosi/thinosi-minutes-93mar.txt
trainmat/trainmat-minutes-93mar.txt
trmon/trmon-minutes-93mar.txt
tuba/tuba-minutes-93mar.txt
uri/uri-minutes-93mar.txt
userdoc2/userdoc2-munites-93mar.txt
uswg/uswg-minutes-93mar.txt
wnils/wnils-minutes-93mar.txt
x400ops/x400ops-minutes-93mar-txt

March Area Reports
------------------

93mar/area.internet.93mar.txt
93mar/area.netmanagement.93mar.txt
93mar/area.userservices.93mar.txt


Interim Minutes
---------------

ipae/ipae-interim-minutes-93mar.txt


From dsr@hplb.hpl.hp.com  Fri Apr 16 11:14:13 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08739; Fri, 16 Apr 93 11:14:13 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04375; Fri, 16 Apr 1993 11:33:52 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA18935 (5.65b/CWI-2.217); Fri, 16 Apr 1993 11:33:47 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 16 Apr 93 10:26:16 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12032; Fri, 16 Apr 93 10:33:23 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304160933.AA12032@manuel.hpl.hp.com>
Subject: HTTP2 Patch for WWW Servers
To: www-talk@nxoc01.cern.ch
Date: Fri, 16 Apr 93 10:33:20 BST
Mailer: Elm [revision: 66.36.1.1]

Most WWW Servers need patching!
===============================

I have just finished upgrading our WWW servers and clients to
use HTTP2 and ran across a problem in using existing servers:

The new format:

    GET path HTRQ/V1.0\r\n

screws existing virtually all existing WWW servers which see the
version number as part of the path string. So you get errors like:

    a)  an empty file - the server simply gave up and closed the connection

    b)  a message to the effect: can't open file "foo.html HTRQ/V1.0"

The patch needed is very simple - you just need to check for a space
chararacter in the path string and if present, null it out!

        void http2_patch(char *path)
        {
            char *p;

            p = strchr(path, ' ');

            if (p)
                *p = '\0';
        }

Most of the CERN servers do accept the new format, with the exception
of the WAIS gateway - on info.cern.ch:8001 which needs patching.

A major motivation behind the new format is to allow servers to return
machine readable status information. This was a major omission with the
older protocol.

We have used the Authorization: field in HTRQ/V1.0 to give clients access
to private information using a username/password approach in the same
vein as rlogin, with support for /etc/hosts.equiv and .rhosts. We expect
to take advantage of the ChargeTo: field soon to cross-charge for selected
information.

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From Nathan.Torkington@vuw.ac.nz  Sat Apr 17 00:25:18 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21869; Sat, 17 Apr 93 00:25:18 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19858; Sat, 17 Apr 1993 00:44:49 +0200
Received: by kauri.vuw.ac.nz id AA08216
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Sat, 17 Apr 1993 10:44:31 +1200
Date: Sat, 17 Apr 1993 10:44:31 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304162244.AA08216@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: HTML Editing

I'm about to release v0.1 of my (Xlib, Xt and Athena Widget) HTML
editor, and I want to know what keybindings you would like.

This is what I have at the moment, but they overwrite the EMACS-style
bindings.  Would you rather lose (say) word-forward or have to use
something like Shift-Meta-F to have a preformatted block?

   Meta Shift <Key>A: tag(<ADDRESS>, </ADDRESS>)\n\
   Meta Shift <Key>B: tag(<B>, </B>)\n\
   Meta Shift <Key>C: tag(<CITE>, </CITE>)\n\
   Meta Shift <Key>D: tag(<DFN>, </DFN>)\n\
   Meta Shift <Key>E: tag(<EM>, </EM>)\n\
   Meta Shift <Key>I: tag(<I>, </I>)\n\
   Meta Shift <Key>K: tag(<KBD>, </KBD>)\n\
   Meta Shift <Key>L: tag(<CODE>, </CODE>)\n\
   Meta Shift <Key>M: tag(<SAMP>, </SAMP>)\n\
   Meta Shift <Key>S: tag(<STRONG>, </STRONG>)\n\
   Meta Shift <Key>T: tag(<TT>, </TT>)\n\
   Meta Shift <Key>U: tag(<U>, </U>)\n\
   Meta Shift <Key>U: tag(<VAR>, </VAR>)\n\
   Meta<Key>1: tag(<H1>, </H1>)\n\
   Meta<Key>2: tag(<H2>, </H2>)\n\
   Meta<Key>3: tag(<H3>, </H3>)\n\
   Meta<Key>4: tag(<H4>, </H4>)\n\
   Meta<Key>5: tag(<H5>, </H5>)\n\
   Meta<Key>6: tag(<H6>, </H6>)\n\
   Meta<Key>a: address(HREF)\n\
   Meta<Key>d: tag(<DL>, ~</DL>)\n\
   Meta<Key>e: tag(<DT>, <DD>~)\n\
   Meta<Key>f: tag(<PRE>~, </PRE>)\n\
   Meta<Key>i: tag(~<LI>)\n\
   Meta<Key>m: tag(<MENU>, ~</MENU>)\n\
   Meta<Key>n: address(NAME)\n\
   Meta<Key>p: tag(<P>~)\n\
   Meta<Key>q: tag(<BLOCKQUOTE>~, <BLOCKQUOTE>)\n\
   Meta<Key>r: tag(<DIR>, ~</DIR>)\n\
   Meta<Key>s: tag(<ISINDEX>)\n\
   Meta<Key>o: tag(<OL>, ~</OL>)\n\
   Meta<Key>t: tag(<TITLE>, </TITLE>)\n\
   Meta<Key>u: tag(<UL>, ~</UL>)\n\

Any feedback welcome,

Nat.

From marca@wintermute.ncsa.uiuc.edu  Sat Apr 17 01:22:42 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26826; Sat, 17 Apr 93 01:22:42 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27665; Sat, 17 Apr 1993 01:42:21 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18972
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 16 Apr 93 18:42:19 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA02952; Fri, 16 Apr 93 18:44:37 -0500
Date: Fri, 16 Apr 93 18:44:37 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304162344.AA02952@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: marca@ncsa.uiuc.edu
Subject: Mosaic support/feedback issues
X-Md4-Signature: f0219b8afa9718077914470dde006504

Dear Mosaic'ers,

The email load related to Mosaic from all over the world is crushing
my poor little Indigo.  This is *wonderful*, and this level of
external feedback has greatly contributed to the current success of
the Mosaic project (both internally at NCSA and in the outside world).

We are in the process of putting together a support team to deal
efficiently and thoroughly with Mosaic questions, comments, bug
reports, and general feedback; this support structure will be moving
into place over the next few months.  We are also in the process of
generating real documentation, including printed beginner-level user
guides and the like, for general distribution and use.

So, two comments.......

(a) Please send Mosaic-related correspondence (up to and including bug
    reports) to mosaic-x@ncsa.uiuc.edu whenever possible.  That way,
    all relevant support people (as well as myself) will automatically
    get copies of all incoming messages, which will help the
    preparation and execution of our support plan considerably.

(b) Please don't be discouraged if you don't get a response to a
    question, comment, or bug report immediately.  In particular,
    please don't *stop* sending feedback to us if we haven't responded
    to previous messages in a timely enough manner -- I read, and will
    continue to read, everything that comes in, but I just don't have
    enough time in the day to answer every message myself anymore
    (which is why we're putting together a real support team).  Every
    message you send us is valuable feedback that will be read and, to
    the best of our ability, acted upon.  Over time, we will try to
    catch up and reply to any messages that have slipped by me over
    the past few months and that inadvertently slip through the cracks
    as the support structure falls into place now..... in fact, I'm
    shortly going to dump the contents of my Mosaic mail folders
    (about 12 megs worth) from the last few months on our support
    people, so they'll undoubtedly have plenty to do right off the
    bat.

So, the bottom line is....... keep the feedback and questions coming!

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl  Sat Apr 17 01:24:57 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27038; Sat, 17 Apr 93 01:24:57 MET DST
Date: Sat, 17 Apr 93 01:24:57 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304162324.AA27038@ nxoc01.cern.ch >
To: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Subject: Re: HTML Editing

Here's a useful function:

Cut out the selected text, and put it in a new file,
with a link from where it was to where it is now, and leave
me typing in the linked source anchor.

Also:  link the selected text to a new file, and leave me 
typing into that new file.

An option of whether to prompt for or make up filenames
would be useful.

Tim

From joe@athena.mit.edu  Sat Apr 17 02:57:04 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04855; Sat, 17 Apr 93 02:57:04 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08042; Sat, 17 Apr 1993 03:16:43 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA01868; Fri, 16 Apr 93 21:16:33 EDT
Received: by theodore-sturgeon (5.57/4.7) id AA27505; Fri, 16 Apr 93 21:16:31 -0400
Message-Id: <9304170116.AA27505@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML Editing 
In-Reply-To: Your message of Sat, 17 Apr 93 10:44:31 +1200.
             <199304162244.AA08216@kauri.vuw.ac.nz> 
Date: Fri, 16 Apr 93 21:16:30 EDT
From: Joseph Wang <joe@athena.mit.edu>


Speaking of editors, I'm about a week from a release of a version of
tkWWW which contains a WYSIWYG HTML editor based on tk code that was
written by Nathan Torkington.



From ses@tipper.oit.unc.edu  Sat Apr 17 19:24:19 1993
Return-Path: <ses@tipper.oit.unc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15789; Sat, 17 Apr 93 19:24:19 MET DST
Received: from gibbs.oit.unc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23532; Sat, 17 Apr 1993 19:44:00 +0200
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
	id AA25840; Sat, 17 Apr 93 13:43:52 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
	id AA18607; Sat, 17 Apr 93 13:45:15 EDT
Message-Id: <9304171745.AA18607@tipper>
X-Really-To: gibbs.oit.unc.edu
To: timbl@nxoc01.cern.ch
Cc: mitra@pandora.sf.ca.us (Mitra), uri@bunyip.com, www-talk@nxoc01.cern.ch
Subject: Re: URL of URL document 
In-Reply-To: Your message of "Thu, 08 Apr 93 17:01:52 BST."
             <9304081601.AA03714@www3.cern.ch> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 17 Apr 93 13:45:15 -0400
From: Simon Spero <ses@tipper.oit.unc.edu>

Any progress on the text version? I was just trying to hack in a URL snarfer
into gnus, and I don't have a postscript printer at home. The thing I can't
remember is how URLs are supposed to be incorporated into netnews style
documents; I've been using an SGML style '&'...';' wrapper when I point
to stuff, but that's just cos I wasn't sure what the right thing to do is.
Simon

From emv@garnet.msen.com  Sun Apr 18 00:32:50 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18238; Sun, 18 Apr 93 00:32:50 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24327; Sun, 18 Apr 1993 00:52:31 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nkLkI-001IIjC@garnet.msen.com>; Sat, 17 Apr 93 18:52 WET DST
Message-Id: <m0nkLkI-001IIjC@garnet.msen.com>
To: pgw@equinox.unr.edu, www-talk@nxoc01.cern.ch
Subject: (fwd) [alt.etext] Text of "The Devil's Dictionary" on Wiretap
Newsgroups: alt.etext
Date: Sat, 17 Apr 93 18:52:10 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

Organization: Msen, Inc. -- Ann Arbor, MI (account info +1 313 998-4562)

Path: nigel.msen.com!sdd.hp.com!elroy.jpl.nasa.gov!swrinde!gatech!europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!uwm.edu!msuinfo!agate!usenet
From: dell@wiretap.spies.com (Thomas Dell)
Newsgroups: comp.archives
Subject: [alt.etext] Text of "The Devil's Dictionary" on Wiretap
Fcc: +answers
Followup-To: alt.etext
Date: 16 Apr 1993 18:25:40 GMT
Organization: The Internet Wiretap
Lines: 22
Sender: adam@soda
Approved: adam@soda
Distribution: world
Message-ID: <1qmtn4$peh@agate.berkeley.edu>
References: <C5JsHA.IJA@wiretap.spies.com>
NNTP-Posting-Host: soda.berkeley.edu
X-Original-Newsgroups: alt.etext
X-Original-Date: Thu, 15 Apr 1993 23:12:46 GMT

Archive-name: auto/alt.etext/Text-of-The-Devil-s-Dictionary-on-Wiretap

The Internet Wiretap has released a full etext of
"The Devil's Dictionary" by Ambrose Bierce, based on
the 1911 edition. It is available on the Internet
Wiretap (130.43.3.3) via Gopher and FTP:

Gopher:     Internet Wiretap
              Electronic Books at Wiretap
                Ambrose Bierce: The Devil's Dictionary

AnonFTP:    ftp wiretap.spies.com
              cd Library/Classic
                get devils.txt

The Devil's Dictionary is about 378K in length,
and is released into the public domain unencumbered.

--Tom

dell@wiretap.spies.com / Thomas E Dell


From marca@wintermute.ncsa.uiuc.edu  Sun Apr 18 05:42:17 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20330; Sun, 18 Apr 93 05:42:17 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21774; Sun, 18 Apr 1993 06:01:59 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA06627
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 17 Apr 93 23:01:57 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA02874; Sat, 17 Apr 93 23:04:13 -0500
Date: Sat, 17 Apr 93 23:04:13 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304180404.AA02874@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: experimental online versions of NCSA Access
X-Md4-Signature: bb9251986538c8bbc846194747421cd7

Mosaic users may want to take a glance at:

        http://www.ncsa.uiuc.edu/Pubs/access/accessDir.html

These are experimental and in the middle of being transferred into the
Web, but look pretty nice to me... (I had nothing to do with them :-).

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From Nathan.Torkington@vuw.ac.nz  Mon Apr 19 05:57:34 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27539; Mon, 19 Apr 93 05:57:34 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03641; Mon, 19 Apr 1993 06:15:47 +0200
Received: by kauri.vuw.ac.nz id AA14381
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Mon, 19 Apr 1993 16:15:37 +1200
Date: Mon, 19 Apr 1993 16:15:37 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304190415.AA14381@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: usage stats

Heh heh heh ... Rich Wiggins asked me to give the growth statistics in
the WWW FAQ (http://www.vuw.ac.nz/non-local/gnat/www-faq.html) for
both gopher and WWW.  He gave me the raw numbers, and what I get is:

Over the three (or is it four) month period from December '92 to March
'93, gopher usage increased by 65%.  If you think that sounds
impressive, wait -- WWW usage increased by 2800%.  Of course, the
relative operational ages of the systems should be taken into account,
but it still sounds pretty darn impressive :)

Nat.

From guido@cwi.nl  Mon Apr 19 09:43:33 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28857; Mon, 19 Apr 93 09:43:33 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14942; Mon, 19 Apr 1993 10:03:16 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA05356 (5.65b/3.8/CWI-Amsterdam); Mon, 19 Apr 1993 10:03:07 +0200
Received: by voorn.cwi.nl with SMTP
	id AA09172 (5.65b/3.8/CWI-Amsterdam); Mon, 19 Apr 1993 10:03:07 +0200
Message-Id: <9304190803.AA09172=guido@voorn.cwi.nl>
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: usage stats 
In-Reply-To: Your message of "Mon, 19 Apr 1993 16:15:37 MDT."
             <199304190415.AA14381@kauri.vuw.ac.nz> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Mon, 19 Apr 1993 10:03:06 +0200
Sender: Guido.van.Rossum@cwi.nl

>Over the three (or is it four) month period from December '92 to March
>'93, gopher usage increased by 65%.  If you think that sounds
>impressive, wait -- WWW usage increased by 2800%.  Of course, the
>relative operational ages of the systems should be taken into account,
>but it still sounds pretty darn impressive :)

Note one thing however -- I looked at my usage stats the other day and
found they had increased trmendously.  However, close inspection of
the log file showed that around April 3-6 a mail robot at
void.ncsa.uiuc.edu had been active, multiplying my load from an
average twenty to over a thousand requests per day...

Just to show that you need to know what you're measuring...

Interesting hostname, by the way...

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From stellr@smyrna.cc.vt.edu  Mon Apr 19 17:34:12 1993
Return-Path: <stellr@smyrna.cc.vt.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04516; Mon, 19 Apr 93 17:34:12 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03375; Mon, 19 Apr 1993 17:53:34 +0200
Received: from smyrna.cc.vt.edu by mcsun.EU.net with SMTP
	id AA08501 (5.65b/CWI-2.217); Mon, 19 Apr 1993 17:53:33 +0200
Received: by smyrna.cc.vt.edu (5.65/DEC-Ultrix/4.3)
	id AA00191; Mon, 19 Apr 1993 11:52:51 -0400
From: stellr@smyrna.cc.vt.edu (Ray Stell)
Message-Id: <9304191552.AA00191@smyrna.cc.vt.edu>
Subject: xmosaic on an Alpha
To: www-talk@nxoc01.cern.ch
Date: Mon, 19 Apr 93 11:52:50 EDT
X-Mailer: ELM [version 2.3 PL4]

Any tips on how to build Xmosaic on an Alpha?

Thank you.  
======================================================================
Ray Stell		stellr@smyrna.cc.vt.edu		(703) 231-4109

From emv@garnet.msen.com  Mon Apr 19 19:20:20 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06327; Mon, 19 Apr 93 19:20:20 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29476; Mon, 19 Apr 1993 19:40:05 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nkzol-001IFQC@garnet.msen.com>; Mon, 19 Apr 93 13:39 WET DST
Message-Id: <m0nkzol-001IFQC@garnet.msen.com>
To: Guido.van.Rossum@cwi.nl
Cc: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>, www-talk@nxoc01.cern.ch
Subject: Re: usage stats 
In-Reply-To: Your message of Mon, 19 Apr 93 10:03:06.
             <9304190803.AA09172=guido@voorn.cwi.nl> 
Date: Mon, 19 Apr 93 13:39:27 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

Note also that gopher statistics are inflated - there's double counting
(and double sending) of bytes when a gopher server fetches a file by
FTP and then gophers it to the client.

This is a clear case where high byte counts should be seen as a sign
of design defects not wide use...

--Ed

From pandora@fernwood.mpk.ca.us  Mon Apr 19 20:55:44 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08300; Mon, 19 Apr 93 20:55:44 MET DST
Received: from [130.93.1.2] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15452; Mon, 19 Apr 1993 21:15:27 +0200
Received: by fernwood.mpk.ca.us; id AA12321; Mon, 19 Apr 93 11:24:26 -0700
From: server@pandora.sf.ca.us (ist Administration )
Date: Mon, 19 Apr 1993 11:15:55 PDT
In-Reply-To:  Edward Vielmetti <emv@garnet.msen.com>
       "Re: usage stats" (Apr 19, 10:39am)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: emv@garnet.msen.com, Guido.van.Rossum@cwi.nl, Nathan.Torkington@vuw.ac.nz,
        www-talk@nxoc01.cern.ch
Subject: Re: usage stats
Cc: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>, www-talk@nxoc01.cern.ch
Message-Id:  <9304191115.aa21373@pandora.sf.ca.us>

 On Apr 19, 10:39am, Edward Vielmetti wrote:
} Note also that gopher statistics are inflated - there's double counting
} (and double sending) of bytes when a gopher server fetches a file by
} FTP and then gophers it to the client.

Not quite Ed, its counted once, when it shouldnt be counted at all! The
gopher-ftp gateway -> ftp server hop doesnt get counted.
} 
} This is a clear case where high byte counts should be seen as a sign
} of design defects not wide use...

Agreed! I posted a patch that fixes this defect for the Unix gopher
client.


- Mitra


From marca@wintermute.ncsa.uiuc.edu  Mon Apr 19 23:51:49 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11435; Mon, 19 Apr 93 23:51:49 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17831; Tue, 20 Apr 1993 00:11:35 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23318
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 19 Apr 93 17:11:17 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Nathan.Torkington@vuw.ac.nz id AA11458; Mon, 19 Apr 93 17:13:34 -0500
Date: Mon, 19 Apr 93 17:13:34 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304192213.AA11458@wintermute.ncsa.uiuc.edu>
To: Guido.van.Rossum@cwi.nl
Cc: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>, www-talk@nxoc01.cern.ch
Subject: Re: usage stats 
In-Reply-To: <9304190803.AA09172=guido@voorn.cwi.nl>
References: <199304190415.AA14381@kauri.vuw.ac.nz>
	<9304190803.AA09172=guido@voorn.cwi.nl>
X-Md4-Signature: b25d0d79d6d8d1597ced7c139f4652f1

Guido.van.Rossum@cwi.nl writes:
> >Over the three (or is it four) month period from December '92 to March
> >'93, gopher usage increased by 65%.  If you think that sounds
> >impressive, wait -- WWW usage increased by 2800%.  Of course, the
> >relative operational ages of the systems should be taken into account,
> >but it still sounds pretty darn impressive :)
> 
> Note one thing however -- I looked at my usage stats the other day and
> found they had increased trmendously.  However, close inspection of
> the log file showed that around April 3-6 a mail robot at
> void.ncsa.uiuc.edu had been active, multiplying my load from an
> average twenty to over a thousand requests per day...

Well, that's certainly not OUR fault!

(...................... well, OK, maybe it is.)

Eric Bina (ebina@ncsa.uiuc.edu) has been working on some automated
net-scanning tools -- yell at him if he's causing trouble.....

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From Nathan.Torkington@vuw.ac.nz  Tue Apr 20 00:10:28 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11657; Tue, 20 Apr 93 00:10:28 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20134; Tue, 20 Apr 1993 00:30:11 +0200
Received: by kauri.vuw.ac.nz id AA12133
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Tue, 20 Apr 1993 10:30:05 +1200
Date: Tue, 20 Apr 1993 10:30:05 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304192230.AA12133@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Authentication

HTTP2 ideas:

 -- authentication
	Currently I'm going to fake this with document delivery
	via e-mail, but I'd rather have *real* authentication.
	Should the authentication scheme be build in, or should
	it be left to clients and servers to guess?
 -- tracking changes
	I should be able to ping a document and get a unique
	value back (cf md5 or snefru) to see whether it has
	changed or not.

Nat.

From mcrae@lib.ucsf.edu  Tue Apr 20 00:52:29 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12126; Tue, 20 Apr 93 00:52:29 MET DST
Received: from [128.218.15.20] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29820; Tue, 20 Apr 1993 01:12:14 +0200
Received: from stimpy.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA03646; Mon, 19 Apr 93 16:12:34 PDT
Message-Id: <9304192312.AA03646@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Re: Authentication 
Date: Mon, 19 Apr 93 16:13:47 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>


Nathan Torkington writes:
> HTTP2 ideas:
> 
>  -- tracking changes
> 	I should be able to ping a document and get a unique
> 	value back (cf md5 or snefru) to see whether it has
> 	changed or not.
> 
> Nat.

  I would like to know not just whether a document has changed, but also what
about it is new/different.  This could be done by managing documents via
SCCS or some similar system which tracks modifications over time.  The client
could then request any particular version(s) of a document which are available
and display the results in some appropriate fashion (highlighting, different
fonts, etc).  A client may choose to keep a version history of previously
visited documents.
  This sort of functionality would require support in both HTML and HTTP, I
believe.  There needs to be some notion of the "current" or default version
of a multi-version document in the URL syntax.  The protocol should
provide some mechanism for the server to inform the client which versions
are available.  
  And then, of course, there's the issue of how to inform a "subscriber" that
an updated version is available.
Chris
-----------------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From pandora@fernwood.mpk.ca.us  Tue Apr 20 02:07:38 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12849; Tue, 20 Apr 93 02:07:38 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11915; Tue, 20 Apr 1993 02:27:23 +0200
Received: by fernwood.mpk.ca.us; id AA06807; Mon, 19 Apr 93 17:22:56 -0700
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: WWW under SCO Unix
Organization: Pandora Systems
Date: Tue, 20 Apr 1993 00:10:32 GMT
Message-Id: <C5r9tL.K83@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL9]
Apparently-To: www-talk@nxoc01.cern.ch


Has anyone tried porting to SCO Unix yet? In particular I'd like to get
the library ported so that I can take a look at the Lynx browser?

- Mitra


From timbl@www3.cern.ch  Tue Apr 20 14:27:39 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18673; Tue, 20 Apr 93 14:27:39 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20093; Tue, 20 Apr 1993 14:47:25 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA10829; Tue, 20 Apr 93 14:45:04 +0100
Date: Tue, 20 Apr 93 14:45:04 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304201345.AA10829@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: mitra@path.net (Mitra)
Subject: Re: WWW under SCO Unix
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Mitra,

Porting the library should be a piece of cake.  It has been for all  
other unix systems, and it runs on VMS...  Have you trid just
compiling as for some other machine?  We don't have SCO unix here.

Tim

From HOLTZMAN@sjuvm.bitnet  Tue Apr 20 19:23:48 1993
Return-Path: <HOLTZMAN@sjuvm.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24254; Tue, 20 Apr 93 19:23:48 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15717; Tue, 20 Apr 1993 19:43:36 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 6708; Tue, 20 Apr 93 19:43:32 SET
Received: from SJUVM.BITNET (NJE origin MAILER@SJUVM) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 3639; Tue, 20 Apr 1993 19:43:31 +0200
Received: from SJUVM (HOLTZMAN) by SJUVM.BITNET (Mailer R2.08) with BSMTP id
 9229; Tue, 20 Apr 93 13:41:57 EDT
Date:         Tue, 20 Apr 93 13:39:03 EDT
From: "Michael S. Holtzman" <HOLTZMAN%SJUVM.BITNET@cearn.bitnet>
Organization: St. John's University
Subject:      Status of V2 software for VM ?
To: www-talk <www-talk@nxoc01.cern.ch>
Message-Id:   <930420.133903.EDT.HOLTZMAN@SJUVM>

Greetings.  I attempted to compile the WWW Library v203b for CMS, but I
got a lot of 'long name' problems. Some new variables need to be added
to the "SHORT_NAMES" re-definitions.

(1) Are these IBM changes going to be made to the library code (and the
    linemode browser code)?   WHEN ??

(2) Is anyone aware of a full screen (or at least 3270) browser for CMS?

Thanx.

--------------------------------------------------------------------
Michael S. Holtzman      St. John's University    HOLTZMAN@SJUVM
Mgr, Academic Systems    Perboyre Hall, Rm B14    MIKE000@SJUMUSIC
(718) 990-1637           Jamaica, NY 11439

From uucp@fernwood.mpk.ca.us  Tue Apr 20 19:32:08 1993
Return-Path: <uucp@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24407; Tue, 20 Apr 93 19:32:08 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16991; Tue, 20 Apr 1993 19:51:54 +0200
Received: by fernwood.mpk.ca.us; id AA03529; Tue, 20 Apr 93 10:48:35 -0700
From: mitra@pandora.sf.ca.us (Mitra)
Date: Tue, 20 Apr 1993 10:36:46 PDT
In-Reply-To:  Tim Berners-Lee <timbl@www3.cern.ch>
       "Re: WWW under SCO Unix" (Apr 20,  6:45am)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: WWW under SCO Unix
Cc: www-talk@nxoc01.cern.ch
Message-Id:  <9304201036.aa17704@pandora.sf.ca.us>

Tim - unfortunately porting to SCO is rarely easy, so I figured it would
be better to see if someone else had done it, I can send you the error output
if you like :-)


- Mitra

From marca@wintermute.ncsa.uiuc.edu  Wed Apr 21 04:23:57 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02341; Wed, 21 Apr 93 04:23:57 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09430; Wed, 21 Apr 1993 04:43:45 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26176
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 20 Apr 93 21:43:24 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Nathan.Torkington@vuw.ac.nz id AA15988; Tue, 20 Apr 93 21:45:41 -0500
Date: Tue, 20 Apr 93 21:45:41 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304210245.AA15988@wintermute.ncsa.uiuc.edu>
To: Guido.van.Rossum@cwi.nl
Cc: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>, www-talk@nxoc01.cern.ch
Subject: Re: usage stats 
In-Reply-To: <9304190803.AA09172=guido@voorn.cwi.nl>
References: <199304190415.AA14381@kauri.vuw.ac.nz>
	<9304190803.AA09172=guido@voorn.cwi.nl>
X-Md4-Signature: 5e5ce0edc9d6de6a94899ce45a434e91

Guido.van.Rossum@cwi.nl writes:
> >Over the three (or is it four) month period from December '92 to March
> >'93, gopher usage increased by 65%.  If you think that sounds
> >impressive, wait -- WWW usage increased by 2800%.  Of course, the
> >relative operational ages of the systems should be taken into account,
> >but it still sounds pretty darn impressive :)
> 
> Note one thing however -- I looked at my usage stats the other day and
> found they had increased trmendously.  However, close inspection of
> the log file showed that around April 3-6 a mail robot at
> void.ncsa.uiuc.edu had been active, multiplying my load from an
> average twenty to over a thousand requests per day...

OK, hypothetical question time.

Suppose we had developed a new net scanning tool that consisted of a
daemon that can run independently of user guidance and a Motif-based
GUI that can attach/detach to/from the daemon at any time and allow a
user to interactively or asynchronously guide the daemon's progress
through the information space on the global network.

Suppose further, and more specifically, that this front-end was really
really impressive (also suppose I didn't write it, so I could
theoretically say that without sounding pompous) and included
interactive drag/drop/point/click graphical maps of the information
space the daemon traversed, as well as direct control over a variety
of constraint parameters to control the daemon's progress both in real
time and asynchronously (e.g., you can tell it where to look and what
to look for interactively, and then detach and let it run
asynchronously overnight, and then reattach in the morning to discover
what it's found).

If we had theoretically developed such a hypothetical tool, should we
release it to the net?  Or are experiences similar to Guido's above,
except on a much larger scale, liable to have severely deleterious
effects on the network and the servers currently on it, and should we
therefore not release it?

You be the judge.........

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From wmperry@avocado.ucs.indiana.edu  Wed Apr 21 04:42:29 1993
Return-Path: <wmperry@avocado.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02546; Wed, 21 Apr 93 04:42:29 MET DST
Received: from avocado.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10785; Wed, 21 Apr 1993 05:02:17 +0200
Message-Id: <9304210302.AA10785@dxmint.cern.ch>
Received: by avocado.ucs.indiana.edu
	(5.65c/9.4jsm) id AA17463; Tue, 20 Apr 1993 22:02:07 -0500
Date: Tue, 20 Apr 1993 22:02:07 -0500
From: "William M. Perry" <wmperry@avocado.ucs.indiana.edu>
To: marca@ncsa.uiuc.edu
Cc: Guido.van.Rossum@cwi.nl, Nathan.Torkington@vuw.ac.nz,
        www-talk@nxoc01.cern.ch
Subject: Re: usage stats 
In-Reply-To: <9304210245.AA15988@wintermute.ncsa.uiuc.edu>
References: <199304190415.AA14381@kauri.vuw.ac.nz>
	<9304190803.AA09172=guido@voorn.cwi.nl>
	<9304210245.AA15988@wintermute.ncsa.uiuc.edu>

Marc Andreessen writes:
>Guido.van.Rossum@cwi.nl writes:
>> >Over the three (or is it four) month period from December '92 to March
>> >'93, gopher usage increased by 65%.  If you think that sounds
>> >impressive, wait -- WWW usage increased by 2800%.  Of course, the
>> >relative operational ages of the systems should be taken into account,
>> >but it still sounds pretty darn impressive :)
>> 
>> Note one thing however -- I looked at my usage stats the other day and
>> found they had increased trmendously.  However, close inspection of
>> the log file showed that around April 3-6 a mail robot at
>> void.ncsa.uiuc.edu had been active, multiplying my load from an
>> average twenty to over a thousand requests per day...
>
>OK, hypothetical question time.
>
>Suppose we had developed a new net scanning tool that consisted of a
>daemon that can run independently of user guidance and a Motif-based
>GUI that can attach/detach to/from the daemon at any time and allow a
>user to interactively or asynchronously guide the daemon's progress
>through the information space on the global network.
>
>Suppose further, and more specifically, that this front-end was really
>really impressive (also suppose I didn't write it, so I could
>theoretically say that without sounding pompous) and included
>interactive drag/drop/point/click graphical maps of the information
>space the daemon traversed, as well as direct control over a variety
>of constraint parameters to control the daemon's progress both in real
>time and asynchronously (e.g., you can tell it where to look and what
>to look for interactively, and then detach and let it run
>asynchronously overnight, and then reattach in the morning to discover
>what it's found).
>
>If we had theoretically developed such a hypothetical tool, should we
>release it to the net?  Or are experiences similar to Guido's above,
>except on a much larger scale, liable to have severely deleterious
>effects on the network and the servers currently on it, and should we
>therefore not release it?

    Woooaaah ... this could be a problem. :)  The stats on our server went
from about 500 a day or so, to over 6000 in a 5 hour stretch when your bot
was roaming (didn't help that it seemed to jump into the man page link).
This could get ridiculous if people at 20 sites decided to let this bot
loose at once.
 
    How about:

	1. Have 2 or 3 sites that will have the bot - presumably major WWW
           sites (cern, ncsa, ??).  They can run their bots once a month,
           or whenever a new site opened, they could aim it there and let
           it rip.
        2. Extend the Motif interface so that it can connect to a remote
           machine (if it can't already).  Also tone it down a bit, so
           people not on the machine where its running can't point it in
           new areas or control its movement.  Have the main sites put up
           the data they collect on some sort of toned-down server, and let
           people look at the graphical representation of 'WEB-Space'(tm)
        3. Release the toned-down motif interface to everyone

   Would this be possible the way this hypothetical server/interface are
right now?  Or is this a dumb idea?  

   Also - how would(does) this display the 'map' of the information it
finds?  Just curious.

>You be the judge.........
>
>Cheers,
>Marc

-Bill
-- William M. Perry (wmperry@indiana.edu) --
He was a cowboy, mister, and he loved the land. He loved it so much he
made a woman out of dirt and married her. But when he kissed her, she
disintegrated. Later, at the funeral, when the preacher said, "Dust to
dust," some people laughed, and the cowboy shot them. At his hanging,
he told the others, "I'll be waiting for you in heaven--with a gun."

From emv@garnet.msen.com  Wed Apr 21 06:25:45 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03408; Wed, 21 Apr 93 06:25:45 MET DST
Received: from [148.59.1.11] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20621; Wed, 21 Apr 1993 06:45:33 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nlWg8-001IDWC@garnet.msen.com>; Wed, 21 Apr 93 00:44 WET DST
Message-Id: <m0nlWg8-001IDWC@garnet.msen.com>
To: "William M. Perry" <wmperry@avocado.ucs.indiana.edu>
Cc: marca@ncsa.uiuc.edu, Guido.van.Rossum@cwi.nl, Nathan.Torkington@vuw.ac.nz,
        www-talk@nxoc01.cern.ch
Subject: Re: usage stats 
In-Reply-To: Your message of Tue, 20 Apr 93 22:02:07.
             <9304210302.AA10785@dxmint.cern.ch> 
Date: Wed, 21 Apr 93 00:44:44 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

Hey folks, this is the same exact problem that 'archie' and 'veronica'
have run up against, let's see if we can draw conclusions from those.

First, it is better if you have a tool to generate a map to run it n
times locally on n hosts and then send those results out to be merged
together.  The archie equivalent of this is the "ls-lR.Z" file you see
in FTP sites.

Second if you do this well it will be popular and perhaps so popular
that your server will explode from overuse.

It would be better to move slowly and go for enough funding for
infrastructure so that it's not just a gee-can-we-do-it hack that ends
up being instantly oversubscribed....

--Ed

From evas@cs.few.eur.nl  Wed Apr 21 09:39:30 1993
Return-Path: <evas@cs.few.eur.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05308; Wed, 21 Apr 93 09:39:30 MET DST
Received: from kaa.cs.few.eur.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16021; Wed, 21 Apr 1993 09:59:10 +0200
Received: from evas@slc01.cs.few.eur.nl by cs.few.eur.nl (5.67/EUR)
	id AA21027; Wed, 21 Apr 93 09:59:00 +0200
From: Eelco van Asperen <evas@cs.few.eur.nl>
Received: by slc01.cs.few.eur.nl (5.67/EUR/BSD)
	id AA21452; Wed, 21 Apr 93 09:58:55 +0200
Date: Wed, 21 Apr 93 09:58:55 +0200
Message-Id: <9304210758.AA21452@slc01.cs.few.eur.nl>
To: emv@garnet.msen.com
Subject: Re: usage stats
Cc: www-talk@nxoc01.cern.ch

 
> First, it is better if you have a tool to generate a map to run it n
> times locally on n hosts and then send those results out to be merged
> together.  The archie equivalent of this is the "ls-lR.Z" file you see
> in FTP sites.

Yes, this is far better if updated regularly.

> Second if you do this well it will be popular and perhaps so popular
> that your server will explode from overuse.
 
Perhaps some code could be added to the http daemon to return an error
message when the system load or number of sessions exceeds a certain,
configurable limit ? Sendmail has a similar facility. 

Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands

From marca@wintermute.ncsa.uiuc.edu  Wed Apr 21 10:33:49 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05827; Wed, 21 Apr 93 10:33:49 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24612; Wed, 21 Apr 1993 10:53:37 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14779
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Wed, 21 Apr 93 03:53:36 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA18553; Wed, 21 Apr 93 03:55:49 -0500
Date: Wed, 21 Apr 93 03:55:49 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304210855.AA18553@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Cc: hardin@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu
Subject: NCSA Mosaic 1.0 released
X-Md4-Signature: c4b2af072a3400678ee91652a8970882

Version 1.0 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is hereby released:

file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-source/xmosaic-1.0.tar.Z
                            .../xmosaic-binaries/xmosaic-sun.Z
                            .../xmosaic-binaries/xmosaic-sgi.Z
                            .../xmosaic-binaries/xmosaic-ibm.Z
                            .../xmosaic-binaries/xmosaic-dec.Z
                            .../xmosaic-binaries/xmosaic-alpha.Z
                            .../xmosaic-diffs/xmosaic-0.13-1.0-diffs.Z

Changes since beta version 0.13 include:

 o Added new resource, gethostbynameIsEvil, for Sun's that
   coredump when gethostbyname() is called to try to find out what
   their own names are. (Command-line flag is -ghbnie.) 
 o Explicitly pop down all dialog boxes when document view
   window is closed, for window managers too dull to do so
   themselves. 
 o Better visited anchor color for non-SGI's. 
 o Added .hqx and .uu to list of file extensions handled like .tar files. 
 o Added 'Clear' button to Open box, to allow more convenient
   cut-n-paste entries of URL's. 
 o New resource 'autoPlaceWindows'; if set to False, new document
   view windows will not be automatically positioned by the
   program itself (but it's still up to your window manager just how
   they're placed). 
 o Command-line flags -i and -iconic now have desired effect (new
   resource initialWindowIconic can also be used). 
 o Gif-reading code is a little more bulletproof. 
 o Obscure infinite loop triggered by extra space in IMG tag fixed. 
 o Eliminated nonintuitive error message when image can't be read
   (inlined NCSA bitmap is indication enough that something's not
   right for authors, and readers can't do anything about bad images
   in any case). 
 o Obscure parsing bug (for constructs like <ADDRESS><A
   HREF=...>text<A></ADDRESS>) fixed. 
 o Fixed mysterious stupid coredump that only hits Suns. 
 o Fixed stupid coredump on URL's like '://cbl.leeds.ac.uk/'. 
 o Fixed buglet in handling rlogin URL's. 
 o New support for Solaris/SYSVR4 (courtesy
   dana@thumper.bellcore.com). 
 o Better support for HP-UX 8.x and 9.x (courtesy
   johns@hpwarf.wal.hp.com). 
 o Better support for NeXT (courtesy scott@shrug.dur.ac.uk). 
 o Some miscellaneous portability fixes (courtesy
   bingle@cs.purdue.edu). 
 o Miscellaneous bug fixes and cleanups. 

Comments, questions, and bug reports should be directed to
mosaic-x@ncsa.uiuc.edu.  Thanks in advance for any feedback you can
provide.

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From timbl@www3.cern.ch  Wed Apr 21 14:50:54 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08062; Wed, 21 Apr 93 14:50:54 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06386; Wed, 21 Apr 1993 15:10:43 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA12376; Wed, 21 Apr 93 15:08:11 +0100
Date: Wed, 21 Apr 93 15:08:11 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304211408.AA12376@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: spqr@minster.york.ac.uk
Subject: HTML, HMML, and HyperTeX
Cc: Adrian F Clark <alien@essex.ac.uk>, GOOSSENS@crnvma.cern.ch,
        www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

From: Adrian F Clark <alien@essex.ac.uk>
> To: spqr@minster.york.ac.uk
> Date: Wed, 21 Apr 93 12:12:13 +0100
> 

> The problem with HTML (IMHO, of course) is that it is text-only.   
We
> really want HTML -> HMML -- you'd have an information system that
> could display pix and sketches of pot sherds, for example.  Now if
> you're interested in exploring that possibility...


HMML is in fact already an extension of HTML for multimedia from  
O'Reilly.  There are similar extenstions from NCSA.  We just have to  
standardize on them for the next DTD which we define.  HTML was  
checkpointed so as not to make a moving target.  NCSA's (released)  
Mosaic for X handles embedded images in the hypertext, as does  
O'Reilly's (unreleased) Viola.

The pictures don't seem to have been very complicated to add (just to  
implement), it is just a question of agreeing on syntax.

In the WWW context, of couse, the tags refer to embedded images by
W3 address, and the retrieval code is responsible for negotiating a
suitable transfer representation for the pic independently of the
embedding document.

Tim Berners-Lee
WWW project, CERN

From julian@vxcrna.cern.ch  Wed Apr 21 16:14:28 1993
Return-Path: <julian@vxcrna.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09330; Wed, 21 Apr 93 16:14:28 MET DST
Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19769; Wed, 21 Apr 1993 16:32:45 +0200
Date: Wed, 21 Apr 1993 16:32:44 +0200
Message-Id: <9304211432.AA19769@dxmint.cern.ch>
From: julian@vxcrna.cern.ch (Julian J. Bunn, CN Division, CERN. Tel. 41 22 767 5029)
X-Vms-To: MINT::www-talk@nxoc01
X-Vms-Cc: JULIAN
Subject: VAX Document to HTML ?
X-Mail11-Ostype: VAX/VMS
Apparently-To: <www-talk@nxoc01>

Does anyone have, or know the whereabouts of, a tool which will
take as input a file of VAX Document SGML and convert it to
HTML.

I don't reaaly want to have to write one myself ....


Thanks,

Julian

From pandora@fernwood.mpk.ca.us  Wed Apr 21 19:48:14 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14207; Wed, 21 Apr 93 19:48:14 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20823; Wed, 21 Apr 1993 20:07:59 +0200
Received: by fernwood.mpk.ca.us; id AA28516; Wed, 21 Apr 93 10:53:41 -0700
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: Re: WWW under SCO Unix
Organization: Pandora Systems
Date: Wed, 21 Apr 1993 17:42:40 GMT
Message-Id: <C5uH75.DMw@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL8]
References: <9304201345.AA10829@www3.cern.ch>
Apparently-To: www-talk@nxoc01.cern.ch


On Marc's suggestion I grabbed the xmosaic-1.0 files, the library code
in there is much changed from the WWW library, although its parentage is
still visible.

The first set of changes worked fine and got rid of a bunch of bugs,
however the sticky point is in HTFile.c where it uses the "direct"
structure rather than "dirent" which is (according to xmosaic's tcp.h
file) more appropriate for several systems.  Unfortunately the code is
differennt enough between xmosaic and WWW that without better
understanding its not possible to just copy it over.

The actual error reported is that there is no d_namlen in the
structure.

Any help appreciated, 


- Mitra



From mcrae@lib.ucsf.edu  Wed Apr 21 20:50:53 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15267; Wed, 21 Apr 93 20:50:53 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27128; Wed, 21 Apr 1993 21:10:42 +0200
Received: from [128.218.33.6] by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA11079; Wed, 21 Apr 93 12:11:00 PDT
Message-Id: <9304211911.AA11079@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Re: usage stats 
In-Reply-To: Your message of "Tue, 20 Apr 93 22:02:07 CDT."
             <9304210302.AA10785@dxmint.cern.ch> 
Date: Wed, 21 Apr 93 12:11:43 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>


Marc Andreessen writes:
> Suppose we had developed a new net scanning tool that consisted of a
> daemon that can run independently of user guidance and a Motif-based
> GUI that can attach/detach to/from the daemon at any time and allow a
> user to interactively or asynchronously guide the daemon's progress
> through the information space on the global network.
> 
...
> space the daemon traversed, as well as direct control over a variety
> of constraint parameters to control the daemon's progress both in real
> time and asynchronously (e.g., you can tell it where to look and what
> to look for interactively, and then detach and let it run
> asynchronously overnight, and then reattach in the morning to discover
> what it's found).
> 

  Of course we want intelligent agents to search the information space for
us!  How else are we going to be able to talk to this web-monster we're
creating?  We need these "bots".
  The debate thus far has focused entirely on how to avoid taxing the
limited resources (network bandwidth, cpu cycles, etc) currently available.  
This is certainly an important consideration since we are here and now.
But, it seems to me that we should be spending more time talking about how
to enhance the intelligence of the agent, so that it's searches are more
efficient.  
  Further, it seems that the biggest obstacle, at this point, in moving
towards more intelligent searches is a lack of support in the web infra-
structure.  While SGML gives you a lot of structure within a node. the
links which relate one node to another provide no information about the
nature of the relationship between the nodes.  I know there has been dis-
cussion among WWW people in the past about using typed links, but I don't
know why they haven't been implemented.  Is it just something which noone
has gotten around to yet, or is there some reason why typed links have
been avoided? (other than backwards compatibility reasons, I mean)

Chris
----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From Nathan.Torkington@vuw.ac.nz  Wed Apr 21 23:16:11 1993
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18047; Wed, 21 Apr 93 23:16:11 MET DST
Received: from [130.195.11.3] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11947; Wed, 21 Apr 1993 23:35:52 +0200
Received: by kauri.vuw.ac.nz id AA18056
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 22 Apr 1993 09:35:37 +1200
Date: Thu, 22 Apr 1993 09:35:37 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199304212135.AA18056@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Re: usage stats

Why don't we do this: add a new command to a server (like GET) that is
LIST.  This returns a list of titles and URLs.  Existing servers,
gateways, etc, won't support this and so won't be listed.  As the new
releases of the servers (incorporating this command) come online, they
will be listed and registered.

Nifty?

Nat

From cwong@cs.cornell.edu  Thu Apr 22 00:56:09 1993
Return-Path: <cwong@cs.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19510; Thu, 22 Apr 93 00:56:09 MET DST
Received: from THIALFI.CS.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21939; Thu, 22 Apr 1993 01:16:00 +0200
Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99D)
	id AA13572; Wed, 21 Apr 93 19:15:58 -0400
Received: from OSIRIS.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D)
	id AA08596; Wed, 21 Apr 93 19:16:05 -0400
From: cwong@cs.cornell.edu (Christopher Yoong-Meng Wong)
Message-Id: <9304212315.AA04084@osiris.cs.cornell.edu>
Received: by osiris.cs.cornell.edu (5.67/N-0.13)
	id AA04084; Wed, 21 Apr 93 19:15:55 -0400
Subject: Xmosaic with X11R5?
To: www-talk@nxoc01.cern.ch
Date: Wed, 21 Apr 1993 19:15:54 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 159       

Has anyone had any luck with compiling Xmosaic using X11R5/Motif1.2.2? The
current Sun binaries (v 1.0) do not seem to work, and I have no X
experience.

Chris

From robm@ncsa.uiuc.edu  Thu Apr 22 10:40:25 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24711; Thu, 22 Apr 93 10:40:25 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27636; Thu, 22 Apr 1993 11:00:16 +0200
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA29281
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 22 Apr 93 04:00:13 -0500
Return-Path: <robm@ncsa.uiuc.edu>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
	id AA15015; Thu, 22 Apr 93 04:00:02 CDT
Message-Id: <9304220900.AA15015@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Thu, 22 Apr 1993 04:00:01 -0500
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: NCSA httpd version 0.3




    The beta version .3 of NCSA's HTTP server has been released and is
on ftp.ncsa.uiuc.edu (141.142.20.50) under /Web/ncsa_httpd.

    NCSA's httpd is a public domain implementation of the HTTP1
protocol, with some gopher-related extensions. I have attached the
README.BETA.3 and README.GOPHER files below.

    There are precompiled binaries for DEC's DECstation and DEC AXP
workstations, sun4 (SPARC) workstations, SGI Iris workstations,
NeXT's, and IBM RS/6000 workstations available on the ftp server. If
you port the server to another platform and need to modify anything to
do so, please let me know what the modifications were.

Any suggestions or bug/problem reports please send to
robm@ncsa.uiuc.edu.

--Rob

--
Rob McCool, NCSA SDG System Administrator
robm@ncsa.uiuc.edu r-mccool@uiuc.edu robm@imsa.edu
It was working ten minutes ago, I swear...


--- README.BETA.3 ---

NCSA HTTP server.

Beta release .3

This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.


Now that that's out of the way, we can move on to more interesting
things.

OVERVIEW
--------

    You've found the Beta release of NCSA's HTTP server. This code is
in testing and development, but is currently fully functional as an
HTTP1 server. 

This is beta release .3

NEW IN RELEASE .3
-----------------

    o Security hole (should be the last) fixed
    o Nearly complete drop-in gopher support. See README.GOPHER for details
    o Not being able to find the config file does not send back a path

NEW IN RELEASE .2
-----------------

    o Two security holes fixed
    o Double slashes in root index fixed
    o Not being able to find the error files no longer hangs the server

FEATURES
--------

    o Directory aliasing and denial. The server can be configured to
map different directories to different places in the filesystem, and
easily deny access to a particular directory or file by mapping it to
something which does not exist. The interface is designed to be simple.

    o Automatic directory index files and on-the-fly index generation.
If the server finds that the client is requesting a directory, it
first checks for a file, by default called "index.html" but which can
be compiled to any name, and if it does not find such a file it
generates an HTML index of the directory and sends it back to the
client.

    o Drop-in gopher support. This server is able to automatically
interpret gopher directory structures and construct, on the fly, HTML
indexes of them. Should be faster than gopherd in HTML mode.

    o Designed to be small and low-impact: the entire source is
currently ~500 lines, without gopher support. It's 800 with gopher support.

FUTURE PLANS
------------

    o HTTP2 support.

    o The ability to run from something other than inetd, so people
who are not root can use it.

    o Transfer logging

    o On the fly uncompression.


That should be all you need. E-mail problems, suggestions for features
or documentation, cash donations, food, etc. to robm@ncsa.uiuc.edu. I 
encourage you to try and break the server, or compromise its security, and 
let me know how you did it so I can fix it.

--Rob (robm@ncsa.uiuc.edu)


--- README.GOPHER ---


NCSA HTTP server.

Beta release .3

This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.


Now that that's out of the way, we can move on to more interesting
things.


OVERVIEW OF GOPHER SUPPORT
--------------------------

    As of beta release .3, this server will automatically generate
HTML listings of a gopher directory without going through gopherd.
This means that . files which are links are processed, and .cap files
are processed. Any request which begins with /gopher-data will be
considered a gopher request if gopher is turned on. Therefore, mapping
/gopher-data to the location of your server's data will allow you to
access /gopher-data and get a gopher listing in return.

    These features are new to .3, and I would appreciate any and all
feedback on its usefulness, features and/or lack thereof, problems,
and suggestions.

KNOWN PROBLEMS
--------------

    o Shell scripts are not executed; i.e. a file of type 0 with #! at
the beginning is returned plaintext instead of being executed.

    o There is a slight ordering inconsistency between this server and
the real gopherd, i.e. all numbered are placed first, in order, THEN
the unnumbered files are placed in alphabetical order. The gopher
server fills in the holes with alphabetized entries.

    o Not all gopher features are currently supported, namely the ph
interface.

    o Files of type 's', 'G', 'I', and any files which are special and
need to be treated in a special way are sent back to the client.
Therefore, if the file does not have the proper extension the client
may not recognize it. i.e. if a GIF does not have the .gif extension
NCSA Mosaic probably won't recognize it.


INSTALLATION
------------

    See the file INSTALL for normal and gopher installations. Be sure
you define GROK_GOPHER in httpd.h if you are compiling the server, or
that you use the binary with gopher support if you are using a
precompiled one.

    
--Rob (robm@ncsa.uiuc.edu)

From timbl@www3.cern.ch  Thu Apr 22 11:57:27 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25360; Thu, 22 Apr 93 11:57:27 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11627; Thu, 22 Apr 1993 12:17:17 +0200
Received: from dxmint.cern.ch by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA13625; Thu, 22 Apr 93 03:17:27 PDT
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11601; Thu, 22 Apr 1993 12:17:08 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01329; Thu, 22 Apr 93 12:13:30 +0100
Date: Thu, 22 Apr 93 12:13:30 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304221113.AA01329@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Christopher McRae <mcrae@lib.ucsf.edu>
Subject: Re: usage stats 
Cc: www-talk@lib.ucsf.edu
Reply-To: timbl@nxoc01.cern.ch


| Date: Wed, 21 Apr 93 12:11:43 MDT
| From: Christopher McRae <mcrae@lib.ucsf.edu>
| 

...
| nature of the relationship between the nodes.  I know there has  
been dis-
| cussion among WWW people in the past about using typed links, but I  
don't
| know why they haven't been implemented.  Is it just something which  
noone
| has gotten around to yet, or is there some reason why typed links  
have
| been avoided? (other than backwards compatibility reasons, I mean)
| 

| Chris


Well, they are in the HTML spec and they are in the WWW library ...
but noone has actually used them.  Go ahaead!   There is a  
provisional and embryonic list of relationships in the HTML
spec ftp://info.cern.ch/pub/www/doc/html-spec.ps

Tim


From germuska@antioch.acns.nwu.edu  Thu Apr 22 17:37:02 1993
Return-Path: <germuska@antioch.acns.nwu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00520; Thu, 22 Apr 93 17:37:02 MET DST
Received: from antioch.acns.nwu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11381; Thu, 22 Apr 1993 17:56:53 +0200
Received: by antioch.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA12562; Thu, 22 Apr 93 10:56:39 CDT
From: germuska@antioch.acns.nwu.edu (Joe Germuska)
Message-Id: <9304221556.AA12562@antioch.acns.nwu.edu>
Subject: HTML and MIME?
To: www-talk@nxoc01.cern.ch
Date: Thu, 22 Apr 1993 10:56:37 -0500 (CDT)
Reply-To: j-germuska@nwu.edu (Joe Germuska)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 438       

Currently, how do HTML and MIME relate?
I gather that HTML is intended to eventually be a MIME subtype -- is this
supported at all anywhere?  It might be nice to send HTML mail to people.

Thanks
	Joe
-- 
joe germuska | j-germuska@nwu.edu | Network Response Center
ACNS-Distributed Systems Services, Northwestern University
"The only thing that speaks the truth is the eloquence of
passing time; the spoken word is a jacket too tight..."

From emv@garnet.msen.com  Thu Apr 22 18:44:10 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01773; Thu, 22 Apr 93 18:44:10 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20013; Thu, 22 Apr 1993 19:03:58 +0200
Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0nm4gW-001IJ2C@garnet.msen.com>; Thu, 22 Apr 93 13:03 WET DST
Message-Id: <m0nm4gW-001IJ2C@garnet.msen.com>
To: j-germuska@nwu.edu (Joe Germuska)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML and MIME? 
In-Reply-To: Your message of Thu, 22 Apr 93 10:56:37.
             <9304221556.AA12562@antioch.acns.nwu.edu> 
Date: Thu, 22 Apr 93 13:03:26 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

HTML as a MIME subtype had been waiting on a stable HTML spec to
present to the Internet Assigned Numbers Authority (the people who
keep track of such names).

I am lead to belive that the 'html.dtd' document type definition for
files according to the SGML standard has been successfully processed
by a commercial SGML package (SoftQuad Author/Editor).  I'd encourage
people to try out other SGML systems (if necessary by posting stuff
to comp.text.sgml) and verify that we have the bugs shaken out, then
approach IANA with the spec.

--Ed

From scott@graft.berkeley.edu  Thu Apr 22 20:42:46 1993
Return-Path: <scott@graft.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04332; Thu, 22 Apr 93 20:42:46 MET DST
Received: from graft.Berkeley.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04913; Thu, 22 Apr 1993 21:02:38 +0200
Received: by graft.Berkeley.EDU (5.65/XCF-1.34)
	id AA20971; Thu, 22 Apr 93 12:07:14 -0700
Date: Thu, 22 Apr 93 12:07:14 -0700
From: scott@graft.berkeley.edu (Scott Silvey)
Message-Id: <9304221907.AA20971@graft.Berkeley.EDU>
To: www-talk@nxoc01.cern.ch
Subject: Please add me to this discussion list.


I saw a reference to this list while browsing an HTML document with WWW.
Unfortunately, there were no explicit instructions about how to get added,
so I resorted to this...

Thanks for your help.

Scott Silvey
scott@xcf.berkeley.edu

From timbl  Thu Apr 22 21:51:52 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05803; Thu, 22 Apr 93 21:51:52 MET DST
Date: Thu, 22 Apr 93 21:51:52 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304221951.AA05803@ nxoc01.cern.ch >
To: uri@bunyip.com, www-talk@nxoc01.cern.ch
Subject: URL plain text version's URL


The plain text of the URL document (version 4)
is on ftp://info.cern.ch/pub/ietf/url4.txt
just as the postscript is in ...ps

This is the same version .. thanks for the various
comments they are not yet in the document. 
(comments on Prospero, afs, and the incorrect urls in
the document's own references)

I'll make a new version when i can

(When I say same version, I mean as distributed
at the IETF after my edits at the IETF itself).

Tim

From mcrae@lib.ucsf.edu  Thu Apr 22 22:00:50 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05968; Thu, 22 Apr 93 22:00:50 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13132; Thu, 22 Apr 1993 22:18:30 +0200
Received: from stimpy.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA15574; Thu, 22 Apr 93 13:18:37 PDT
Message-Id: <9304222018.AA15574@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Re: usage stats
Date: Thu, 22 Apr 93 13:20:10 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>

TimBL writes (regarding typed links):
> Well, they are in the HTML spec and they are in the WWW library ...
> but noone has actually used them.  Go ahaead!   There is a  
> provisional and embryonic list of relationships in the HTML
> spec ftp://info.cern.ch/pub/www/doc/html-spec.ps
> 
> Tim

  Well, what d'ya know?  Thanks, Tim! I guess I'd better get around to
reading that spec.
  At first glance, it looks like there are two ways of relating one
document/node to another.  First, there is the LINK property in the header
of the node.  There may be any number of LINK elements within the header,
each one specifies some relationship between the document and some other
specifed document.  Secondly, a relationship can be specified for any
anchor using the REL or REV attributes.  There are currently about 13
relationship types currently supported.  See sections 3.1, 3.6, 3.15, and
chapter 6 of ftp://info.cern.ch/pub/www/doc/html-spec.ps.
  So, why are people *not* using typed links?  Has noone seen the need
or is everyone else as ignorant as I am?  Is anyone out there creating
such links?  Has anyone built support into their client(s)?
  Why are typed links interesting?  Well, one way they could be
immediately useful to me is in printing material from the web.  For
instance, I have been reading about the web, HTML, SGML, HTTP, hypertext,
etc.  The other night I wanted to take a hardcopy of some of the
documentation home with me, but I had to print it node by node.  (I did
find the postscript documents available via ftp, but they just aren't
as current or complete as the material on the web.)  If the links were
typed, and my client was smart enough, I could ask for a printout of
the current node and any anchors within it which are no more than 2 hops
away and whose type is "embed", "present", or "includes".  Depending on
the particular node that I was at, this should get me a manageable amount
of information relevant to my current interest.
  Of course, there are some design issues involved in deciding how to
display/present the results of such directives.
Chris
-----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From timbl  Thu Apr 22 22:01:48 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05997; Thu, 22 Apr 93 22:01:48 MET DST
Date: Thu, 22 Apr 93 22:01:48 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304222001.AA05997@ nxoc01.cern.ch >
To: j-germuska@nwu.edu
Subject: Re: HTML and MIME?
Cc: www-talk@nxoc01.cern.ch

HTML and MIME relate as follows.  HTML is to be proposed as aMIME
text/html type.  This is not only a Good Thing as you note, it also
is essential as the full HTTP protocol send back a MIME message.
That is, it uses RFC822 fields for its headings including the
Content-type field.

Yes, it would be very nice to send HTML mail to people!
For more details, check out click _here_ to check out the
HTTP spec :-)

HTML news too.
.               
Tim

From timbl  Thu Apr 22 22:03:52 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06054; Thu, 22 Apr 93 22:03:52 MET DST
Date: Thu, 22 Apr 93 22:03:52 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304222003.AA06054@ nxoc01.cern.ch >
To: emv@garnet.msen.com, j-germuska@nwu.edu
Subject: Re: HTML and MIME?
Cc: www-talk@nxoc01.cern.ch

	From emv@garnet.msen.com Thu Apr 22 18:44:22 1993
	Return-Path: <emv@garnet.msen.com>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA01773; Thu, 22 Apr 93 18:44:10 MET DST
	Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
		id AA20013; Thu, 22 Apr 1993 19:03:58 +0200
	Received: by garnet.msen.com (/\==/\ Smail3.1.25.1 #25.5)
		id <m0nm4gW-001IJ2C@garnet.msen.com>; Thu, 22 Apr 93 13:03 WET DST
	Message-Id: <m0nm4gW-001IJ2C@garnet.msen.com>
	To: j-germuska@nwu.edu (Joe Germuska)
	Cc: www-talk@nxoc01.cern.ch
	Subject: Re: HTML and MIME? 
	In-Reply-To: Your message of Thu, 22 Apr 93 10:56:37.
	             <9304221556.AA12562@antioch.acns.nwu.edu> 
	Date: Thu, 22 Apr 93 13:03:26 EDT
	From: Edward Vielmetti <emv@garnet.msen.com>

	HTML as a MIME subtype had been waiting on a stable HTML spec to
	present to the Internet Assigned Numbers Authority (the people who
	keep track of such names).

	I am lead to belive that the 'html.dtd' document type definition for
	files according to the SGML standard has been successfully processed
	by a commercial SGML package (SoftQuad Author/Editor).  I'd encourage
	people to try out other SGML systems (if necessary by posting stuff
	to comp.text.sgml) and verify that we have the bugs shaken out, then
	approach IANA with the spec.

	--Ed


Ed -- It has been run though sglms by Dan although not in the
very latest version.  I think it is just waiting for me to
put the right Satus message on it to make it an ID to
put it in Joyce's direction.

Tim

From fine@cis.ohio-state.edu  Thu Apr 22 22:45:56 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06971; Thu, 22 Apr 93 22:45:56 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19509; Thu, 22 Apr 1993 23:05:48 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13883; Thu, 22 Apr 93 17:05:44 -0400
Date: Thu, 22 Apr 93 17:05:44 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9304222105.AA13883@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: how should remote path names be handled?
X-Mailer: Perl Mail System v1.2

I was under the impression that when a relative or full path name
at a remote site was found, it was supposed to be converted (by the
browser) into a full http path, based on the current site and document.

Someone mentioned though that this is not the behaviour of some browsers.
So what should we expect?  Also, is there a difference in interpreting
a URL at a remote site between file:/blah    and  /blah ?

Examples:

current document
      http://mars.cs.state.edu:80/docs/cartoons/flinstones.html

link found
      HREF=jetsons.html
  is translated as
      http://mars.cs.state.edu:80/docs/cartoons/jetsons.html

link found
      HREF=../sitcoms/threes_company.html
  is translated as
      http://mars.cs.state.edu:80/docs/sitcoms/threes_company.html

link found
      HREF=/docs/drama/lalaw.html
  is translated as
      http://mars.cs.state.edu:80/docs/drama/lalaw.html

Yes, no, maybe?

I think that relative paths should be translated by the browser, and
their use should be encouraged.  Full paths should not be handled, and
their use should be discouraged.  The reason is the difference in
interpretation between the local and the remote access.  Since the
http daemon translates full paths, a full remote path may not point to
a real filename, and likewise a full local path may not be a valid
filename thru the server.  On the other hand, relative paths can be
handled correctly both locally and remotely, as long as the relative
path doesn't go outside the domain of what the server will allow.

	   tom

From timbl  Thu Apr 22 22:54:08 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07061; Thu, 22 Apr 93 22:54:08 MET DST
Date: Thu, 22 Apr 93 22:54:08 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304222054.AA07061@ nxoc01.cern.ch >
To: www-talk@nxoc01.cern.ch
Subject: WWW library now accesses WAIS servers directly
Cc: timbl


At last I have actually got around to doing it.
The 2.04 version of the library, if compiled
appropraitely, and linked with freeWAIS libraries
client.a and wais.a, will directly grok wais:* urls
and search and retrieve from WAIS servers.

As a quite separate thing, whether or not you have the
wais protocol linked in, there is a parser for wais
source files which, apart from formatting them a little,
puts a link to the wais index itself.  So any 2.04+
client coming across a application/x-wais-source type
file (as it assumes .src files to be) will do the
necessary.

I am not 100% happy about the way it works.

Firstly, to be 100% portable it does not cache source
files, so when you follow a link to a wais database
there is nothing much to display to the user: just the
database name.  This is the old problem that a wais database
does not describe itself, you have to happen to have the
source file somewhere.  I am told that in Z30.50-9X
the EXPLAIN function will cover this. If in the mean time
I do cache source files, I wonder where would be a good 
place to put them.

Secondly, the WAIS urls are still really messy, with stuff
in there which dosn't seem apropriate. One of the things
is the format of the data, because in wais this is returned
at search time and so (as in Gopher0 and half in Gopher+)
must be stored in the link.

BTW, does anyone have a definitive list of all WAIS type
fields and all Gopher type characters?

Anyway, the code is there for anyone who wants to play.
It may be buggy yet.  You can all go write wais: URLs.
Those who don't have the wais code compiled in remember
to 

     setenv WWW_wais_GATE http://info.cern.ch:8001/

which should wouk on all the old clients.
(That gateway won't grok new clients bt I'll fix that)

Enjoy...

Tim

From timbl  Thu Apr 22 23:01:36 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07208; Thu, 22 Apr 93 23:01:36 MET DST
Date: Thu, 22 Apr 93 23:01:36 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304222101.AA07208@ nxoc01.cern.ch >
To: fine@cis.ohio-state.edu, www-talk@nxoc01.cern.ch
Subject: Re: how should remote path names be handled?
Cc: timbl

Tom,

Your examples were all correct.  Any missing infromation
is taken from the left hand end of the URL of the referring
document.  When a relative path is given (no protocol,
hostname or leading /) then the rule is to strip
everything off the current URL which is to the right of
its rightmost "/", the append the relative path.
This is always what you expect, except that it might
surprise you if you don't think too hard that in directory
/a/fred, "bert" refers to /a/bert, not /a/fred/bert, so
/a/fred/bert should be referred to as "fred/bert" or "./bert".
Anyway, you are right, and if there are browsers which do otherwise
that is their problem, unless I've goofed.

Tim
____________reply to:
From fine@cis.ohio-state.edu Thu Apr 22 22:46:10 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06971; Thu, 22 Apr 93 22:45:56 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19509; Thu, 22 Apr 1993 23:05:48 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA13883; Thu, 22 Apr 93 17:05:44 -0400
Date: Thu, 22 Apr 93 17:05:44 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9304222105.AA13883@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: how should remote path names be handled?
X-Mailer: Perl Mail System v1.2
Status: R

I was under the impression that when a relative or full path name
at a remote site was found, it was supposed to be converted (by the
browser) into a full http path, based on the current site and document.

Someone mentioned though that this is not the behaviour of some browsers.
So what should we expect?  Also, is there a difference in interpreting
a URL at a remote site between file:/blah    and  /blah ?

Examples:

current document
      http://mars.cs.state.edu:80/docs/cartoons/flinstones.html

link found
      HREF=jetsons.html
  is translated as
      http://mars.cs.state.edu:80/docs/cartoons/jetsons.html

link found
      HREF=../sitcoms/threes_company.html
  is translated as
      http://mars.cs.state.edu:80/docs/sitcoms/threes_company.html

link found
      HREF=/docs/drama/lalaw.html
  is translated as
      http://mars.cs.state.edu:80/docs/drama/lalaw.html

Yes, no, maybe?

I think that relative paths should be translated by the browser, and
their use should be encouraged.  Full paths should not be handled, and
their use should be discouraged.  The reason is the difference in
interpretation between the local and the remote access.  Since the
http daemon translates full paths, a full remote path may not point to
a real filename, and likewise a full local path may not be a valid
filename thru the server.  On the other hand, relative paths can be
handled correctly both locally and remotely, as long as the relative
path doesn't go outside the domain of what the server will allow.

	   tom


From guido@cwi.nl  Thu Apr 22 23:52:07 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08029; Thu, 22 Apr 93 23:52:07 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28199; Fri, 23 Apr 1993 00:12:00 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA12812 (5.65b/3.8/CWI-Amsterdam); Fri, 23 Apr 1993 00:11:58 +0200
Received: by voorn.cwi.nl with SMTP
	id AA01174 (5.65b/3.8/CWI-Amsterdam); Fri, 23 Apr 1993 00:11:56 +0200
Message-Id: <9304222211.AA01174=guido@voorn.cwi.nl>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: fine@cis.ohio-state.edu, www-talk@nxoc01.cern.ch
Subject: Re: how should remote path names be handled? 
In-Reply-To: Your message of "Thu, 22 Apr 1993 23:01:36 MET."
             <9304222101.AA07208@ nxoc01.cern.ch > 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Fri, 23 Apr 1993 00:11:55 +0200
Sender: Guido.van.Rossum@cwi.nl

Tim BL writes:
>This is always what you expect, except that it might
>surprise you if you don't think too hard that in directory
>/a/fred, "bert" refers to /a/bert, not /a/fred/bert, so
>/a/fred/bert should be referred to as "fred/bert" or "./bert".
>Anyway, you are right, and if there are browsers which do otherwise
>that is their problem, unless I've goofed.

The last example is really worrysome!  If you are trying to follow
UNIX conventions, "./bert" should refer to the same thing as "bert",
so it would refer to "/a/bert"!  What does the library code actually
do?  (I don't have it handy!)

Another question about this subject is resolution of "../" prefixes.
In the above example, what does "../foo" refer to?  I'd hope "/foo".

Also, who is supposed to do the ".." resolution -- the client or the
server?

And what about "/../" in the middle of a path?  Does
"/foo/bar/../bletch" always mean "/foo/bletch" (if "/foo/bar" were a
symbolic link to a directory, it won't on UNIX, meaning that a client
doing "../" stripping might wind up at a different place than a server
blindly following the path (which might be dangerous if there are more
"../" parts than allowed -- I don't know if servers allow this).

Finally, I believe there are (or were) some gateway servers on the net
that are confused about this themselves: when in /a/b and attempting
to generate a relative reference to c, they would end up referring to
/a/b/c instead of /a/c, or when attempting to refer one level up they
would point to /a/a instead of /a.  (I seem to remember the CERN Emacs
Info gateway did this -- can't find where it is right now...)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>


From fine@cis.ohio-state.edu  Fri Apr 23 00:00:42 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08155; Fri, 23 Apr 93 00:00:42 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28892; Fri, 23 Apr 1993 00:20:35 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA14348; Thu, 22 Apr 93 18:20:33 -0400
Date: Thu, 22 Apr 93 18:20:33 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9304222220.AA14348@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: how should remote path names be handled?
X-Mailer: Perl Mail System v1.2

>Your examples were all correct.  Any missing infromation
>is taken from the left hand end of the URL of the referring
>document.  When a relative path is given (no protocol,
>hostname or leading /) then the rule is to strip
>everything off the current URL which is to the right of
>its rightmost "/", the append the relative path.
>This is always what you expect, except that it might
>surprise you if you don't think too hard that in directory
>/a/fred, "bert" refers to /a/bert, not /a/fred/bert, so

I think you need to clarify this.  If you are in a document inside of
/a/fred/  then bert should refer to /a/fred/bert.  If you meant that
fred is a document (the current one) inside of a, then bert should
refer to /a/bert.

>/a/fred/bert should be referred to as "fred/bert" or "./bert".
>Anyway, you are right, and if there are browsers which do otherwise
>that is their problem, unless I've goofed.

Should the browser collapse a .. path by itself, or pass it on to the
server:

  in           http://server/foo/bar/baz/doc.html
  translate    ../../cool.html
  to           http://server/foo/bar/baz/../../cool.html
  or           http://server/foo/doc.html

And I should note that collapsing the path is a very trivial operation.

       tom
             

From weber@eitech.com  Fri Apr 23 00:17:54 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08341; Fri, 23 Apr 93 00:17:54 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01944; Fri, 23 Apr 1993 00:37:37 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA09191; Thu, 22 Apr 93 17:37:11 -0500
Received: by eitech.com (4.1/SMI-4.1)
	id AA09192; Thu, 22 Apr 93 15:33:06 PDT
Date: Thu, 22 Apr 93 15:33:06 PDT
From: weber@eitech.com (Jay C. Weber)
Message-Id: <9304222233.AA09192@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re:  how should remote path names be handled?

Here's an idea can help with the remote pathname issues.
Excuse me if it's already in HTML 2.0 (actually the URL
spec) but I don't think it is.

How about variable name substitution in URLs?  E.g., you
could use a HREF=file://$parentsite$parentdir/foo.html to make
explicit how the broswer should construct relative pathnames.

The advantage of this over the current HREF=file:foo.html
scheme is it opens up many other kinds of context-sensitive
URLs, like substituting the parentsite but naming a new
directory path.  Or, browsers (the WWW library I guess) could
define new variables like $standardsite, which would depend
on the user's continent (per the recent suggestion about
distributing servers).

Or, what intriques me the most is using variable substitution
with Dave Raggett's electronic forms.  That is, we could define
a tag construct like

  <blank FIELDTYPE=string LVAL=keyw1>Enter Keyword:</entry>

A typical GUI browser would render this as an entry widget embedded
at the appropriate spot in the text.  Anything typed into the
widget would become the value of the variable $keyw1, and
subsequently substituted into a URL.  For example, we could put
WAIS keyword prompts inside the server HTML document, which would
be a good thing.

Jay
---------------------------------------------------------------------
Jay C. Weber					weber@eitech.com
Enterprise Integration Technologies		weber@cis.stanford.edu
459 Hamilton Avenue, Suite #100			(415)617-8002
Palo Alto, CA 94301

From pandora@fernwood.mpk.ca.us  Fri Apr 23 01:46:58 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09354; Fri, 23 Apr 93 01:46:58 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12504; Fri, 23 Apr 1993 02:06:47 +0200
Received: by fernwood.mpk.ca.us; id AA18228; Thu, 22 Apr 93 17:08:32 -0700
From: mitra@pandora.sf.ca.us (Mitra)
Date: Thu, 22 Apr 1993 16:48:27 PDT
In-Reply-To:  weber@eitech.com (Jay C. Weber)
       "Re:  how should remote path names be handled?" (Apr 22,  3:33pm)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: weber@eitech.com, www-talk@nxoc01.cern.ch
Subject: Re:  how should remote path names be handled?
Cc: 
Message-Id:  <9304221648.aa25344@pandora.sf.ca.us>

I'm not following this discussion in detail, but one issue I dont see addressed
is that the root of the tree will mean different things depending on the
application - for example ftp:/pub/fred is not the same as the file /pub/fred
or gopher:/pub/fred since both ftp and gopher interpret paths relative to 
a base address passed to the server.

- Mitra

From bloemer@tnt.uni-hannover.dbp.de  Fri Apr 23 09:23:59 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12946; Fri, 23 Apr 93 09:23:59 MET DST
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15371; Fri, 23 Apr 1993 09:43:49 +0200
Received: by ixgate.gmd.de id AA26524; Fri, 23 Apr 93 09:42:50 +0200
Date: 23 Apr 93  7:42 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: www-talk@nxoc01.cern.ch
Message-Id: <RFC-822:>
Subject: DYNAMIC Netfind from WWW

RFC-822-HEADERS:
Cc: www-bug@info.cern.ch, mosaic-x@ncsa.uiuc.edu, hardy@cs.colorado.edu,
        dehning, falken, grau, muenkel, niem, woelker, wollborn, seelmann,
        bloemer

==================
There is a very interesting new WAIS server. It is called DYNAMIC netfind
and performs Netfind searches via WAIS. For details see appendix of this
mail.

I tried to access this new database via the WWW-WAIS Gateway. Unfortunately
my XMosaic 1.0 client and the www 1.4a client running on info.cern.ch
both are reporting the following error:

----- Begin Included Message -----

WAISGate: Syntax error in WWW document address
`/ftp.cs.colorado.edu:8000/DYNAMIC%20netfind/DYNAMIC' 

Access error

The WWW-WAIS gateway reports the following error:

Syntax error in WWW document address 

Address received was 

/ftp.cs.colorado.edu:8000/DYNAMIC%20netfind/DYNAMIC

Syntax is //node:port/databse 

or //node:port/databse?query+query 

or //node:port/database/doctype/doclength/docid 


----- End Included Message -----

Dynamic searches via WAIS would be a very valuable new service which
would perfectly integrate in WWW.

Is there an easy way to patch the WAIS Gateway so that it can deal with
those kind of searches?

Arnold

_______________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49 511 762-5333           D-3000 Hannover 1
phone:  +49 511 762-5320           Germany
________________________________________________________________________________


----- Begin Included Message -----

From bloemer Fri Apr 23 09:05:45 1993
From: bloemer (Arnold Bloemer)
To: bloemer

DYNAMIC netfind

This WAIS server performs Netfind searches.  It uses the waisserver
from the Dynamic WAIS prototype at the University of Colorado in
Boulder.  To use this WAIS server: supply keywords for a Netfind
search.  A list of matching domains will be returned as relevant
documents.  Choose one of the domains to retrieve the results from a
Netfind search for that domain.  Due to the strict query format for
Netfind, keywords must be in the format: name key key...  

For example, to find information about Darren Hardy at the University
of Colorado in Boulder, use the keywords 'hardy boulder colorado' or
'hardy boulder colorado computer science'.

In order to use X WAIS with the Dynamic WAIS server you can apply the
patch for xwais found in the Dynamic WAIS distribution.  It's a simple
one-line patch to xwais.  Or you can add a text viewer to your filters
preference (either in the Xwais.filters resource or with the \

This database is maintained by hardy@cs.colorado.edu on host ftp.cs.colorado.edu. 

(The search matches your words against full document text. Access to this index is
provided by the WWW to WAIS gateway. Please specify search words to find
documents. For other databases, see the directory of servers.) 


----- End Included Message -----

Example:

winston ai mit

( 0) check_name: checking domain ai.mit.edu.  Level = 0
MAIL FOR Patrick H. Winston IS FORWARDED TO phw@ai.mit.edu
NOTE:	this is a domain mail forwarding arrangement - so mail intended
	for "winston" should be addressed to "winston@ai.mit.edu".

SYSTEM: ai.mit.edu
	Login name: phw       			In real life: Patrick H. Winston
	Directory: /home/c2/phw             	Shell: /usr/local/bin/tcsh
	Never logged in.
	New mail received Thu Apr 22 21:40:13 1993;
	  unread since Thu Apr 22 17:06:25 1993
	No Plan.



SUMMARY:
- The most promising email address for "winston"
  based on the above search is
  winston@ai.mit.edu.


From bloemer@tnt.uni-hannover.dbp.de  Fri Apr 23 09:56:52 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13174; Fri, 23 Apr 93 09:56:52 MET DST
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21335; Fri, 23 Apr 1993 10:16:29 +0200
Received: by ixgate.gmd.de id AA28210; Fri, 23 Apr 93 10:15:27 +0200
Date: 23 Apr 93  8:15 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: www-talk@nxoc01.cern.ch
Message-Id: <RFC-822:>
Subject: Re: DYNAMIC Netfind from WWW

RFC-822-HEADERS:
Cc: www-bug@info.cern.ch, mosaic-x@ncsa.uiuc.edu, hardy@cs.colorado.edu,
        dehning, falken, grau, muenkel, niem, woelker, wollborn, seelmann

==================

In my previous mail I included the description from dynamic-netfind.src.
I took the description which was diplayed by xmosaic and generated from the
WWW-WAIS Gateway. Unfortunately the gateway just returned the first
n lines of the description.

Is this a bug or a feature ?

See the appendix of this mail for the full description.

Arnold

P.S.: There is also a DYNAMIC archie


________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49 511 762-5333           D-3000 Hannover 1
phone:  +49 511 762-5320           Germany
________________________________________________________________________________


(:source
 :version 	3
 :ip-name 	"ftp.cs.colorado.edu"
 :tcp-port 	8000
 :database-name "DYNAMIC netfind"
 :cost 		0.00 
 :cost-unit 	:free 
 :maintainer 	"hardy@cs.colorado.edu"
 :description 	
"This WAIS server performs Netfind searches.  It uses the waisserver
from the Dynamic WAIS prototype at the University of Colorado in
Boulder.  To use this WAIS server: supply keywords for a Netfind
search.  A list of matching domains will be returned as relevant
documents.  Choose one of the domains to retrieve the results from a
Netfind search for that domain.  Due to the strict query format for
Netfind, keywords must be in the format: name key key...  

For example, to find information about Darren Hardy at the University
of Colorado in Boulder, use the keywords 'hardy boulder colorado' or
'hardy boulder colorado computer science'.

In order to use X WAIS with the Dynamic WAIS server you can apply the
patch for xwais found in the Dynamic WAIS distribution.  It's a simple
one-line patch to xwais.  Or you can add a text viewer to your filters
preference (either in the Xwais.filters resource or with the \"Prefs\"
button).  For example:

        DYNAMIC,xedit;

Dynamic WAIS extends the WAIS paradigm to support information from
remote search systems (as opposed to the usual collection of static
documents).  It supports gateways from WAIS to Archie and to our
Netfind Internet User directory service.  Unlike menu-level gateways
(such as the current interim telnet interface from the Internet Gopher
system to Netfind), Dynamic WAIS uses the Z39.50 information retrieval
protocol to seamlessly integrate the information spaces.  This approach
allows users to access a great deal of diverse information without
learning multiple user interfaces.

The key idea behind the Dynamic WAIS gateways is the conceptual work of
constructing mappings between the WAIS search-and-retrieve operations,
and the underlying Archie and Netfind operations.  In the case of
Netfind, for example, when the Dynamic WAIS user requests a search using
the \"dynamic-netfind.src\" WAIS source, the search is translated to a
lookup in the Netfind seed database, to determine potential domains to
search.  The Netfind domain selection request is then mapped into a WAIS
database selection request.  Once the user selects one of the domains to
search, the WAIS retrieval phase is mapped into an actual domain search
in Netfind.

If you would like to learn more about Dynamic WAIS, you can obtain the
source to the Dynamic WAIS prototype The prototype is available via
anonymous ftp from ftp.cs.colorado.edu in /pub/cs/distribs/dynamicwais.  
A paper on Dynamic WAIS is in preparation.

This WAIS server was created in January 1993 by Darren R. Hardy and
Michael F. Schwartz as part of the Networked Resource Discovery
Project.  You may reach them at the Department of Computer Science,
University of Colorado, Boulder, CO  80309-0430, or via email at
hardy@cs.colorado.edu and schwartz@cs.colorado.edu.
"
)

(:source
 :version 	3
 :ip-name 	"ftp.cs.colorado.edu"
 :tcp-port 	8000
 :database-name "DYNAMIC archie"
 :cost 		0.00 
 :cost-unit 	:free 
 :maintainer 	"hardy@cs.colorado.edu"
 :description 	
"This WAIS server performs Archie searches.  It uses the waisserver
from the Dynamic WAIS prototype at the University of Colorado in
Boulder.  To use this WAIS server: supply a keyword for an Archie
search.  A list of Archie servers will be returned as relevant
documents.  Choose one of the Archie servers to retrieve the results
from an Archie query.  Typically, Archie queries take more than 5
minutes due to the load on the Archie servers.  Dynamic WAIS uses the
Archie-Prospero client to query Archie servers.

In order to use X WAIS with the Dynamic WAIS server you can apply the
patch for xwais found in the Dynamic WAIS distribution.  It's a simple
one-line patch to xwais.  Or you can add a text viewer to your filters
preference (either in the Xwais.filters resource or with the "Prefs"
button).  For example:

	DYNAMIC,xedit;

Dynamic WAIS extends the WAIS paradigm to support information from
remote search systems (as opposed to the usual collection of static
documents).  It supports gateways from WAIS to Archie and to our
Netfind Internet User directory service.  Unlike menu-level gateways
(such as the current interim telnet interface from the Internet Gopher
system to Netfind), Dynamic WAIS uses the Z39.50 information retrieval
protocol to seamlessly integrate the information spaces.  This approach
allows users to access a great deal of diverse information without
learning multiple user interfaces.

The key idea behind the Dynamic WAIS gateways is the conceptual work of
constructing mappings between the WAIS search-and-retrieve operations,
and the underlying Archie and Netfind operations.  In the case of
Netfind, for example, when the Dynamic WAIS user requests a search using
the \"dynamic-netfind.src\" WAIS source, the search is translated to a
lookup in the Netfind seed database, to determine potential domains to
search.  The Netfind domain selection request is then mapped into a WAIS
database selection request.  Once the user selects one of the domains to
search, the WAIS retrieval phase is mapped into an actual domain search
in Netfind.

If you would like to learn more about Dynamic WAIS, you can obtain the
source to the Dynamic WAIS prototype The prototype is available via
anonymous ftp from ftp.cs.colorado.edu in /pub/cs/distribs/dynamicwais.  
A paper on Dynamic WAIS is in preparation.

This WAIS server was created in January 1993 by Darren R. Hardy and
Michael F. Schwartz as part of the Networked Resource Discovery
Project.  You may reach them at the Department of Computer Science,
University of Colorado, Boulder, CO  80309-0430, or via email at
hardy@cs.colorado.edu and schwartz@cs.colorado.edu.
"
)

From bloemer@tnt.uni-hannover.dbp.de  Fri Apr 23 17:03:48 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19637; Fri, 23 Apr 93 17:03:48 MET DST
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06583; Fri, 23 Apr 1993 17:23:37 +0200
Received: by ixgate.gmd.de id AA20904; Fri, 23 Apr 93 17:22:37 +0200
Date: 23 Apr 93  9:36 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: fine@cis.ohio-state.edu, www-talk@nxoc01.cern.ch, timbl@nxoc01.cern.ch
Message-Id: <RFC-822:>
Subject: Re: how should remote path names be handled?

RFC-822-HEADERS:
Cc: dehning, falken, grau, muenkel, niem, woelker, wollborn, bloemer

==================
I had severe problems with relative pathnames when I setup
a WAIS database of my local set of HTML pages.

The idea behind setting up this database was, that I would
be able to generate a projection of the Web based on a search.

After I retrieve a HTML Page from the WAIS database I want to
be able to follow all the links in the HTML Page.

But I experienced that I could only follow links with absolute
pathnames. A relative URL like "HREF=QuickGuide.html" was 
translated to the following:

http://info:8001/info:21401/AB-WWW/HTML/2798/1=ikarus%3A21401;2=/hom
e/bloemer/docs/wais/wais-databases/AB-WWW;3=0%202798%20/home/bloemer/appl/inter
net/infosystems/www/tmp/WWW/LineMode/Defaults/Customisation.html;4=ikarus%3A214
01;5=/home/bloemer/docs/wais/wais-databases/AB-WWW;6=0%202798%20/home/bloemer/a
ppl/internet/infosystems/www/tmp/WWW/LineMode/Defaults/QuickGuide.html

This yields an error of 'Missing DocID in request'.

So if you want to setup a WAIS database for searching through your
information system the only way seems to be using absolute pathnames.

Or is the last statement wrong ?

Arnold



From pandora@fernwood.mpk.ca.us  Fri Apr 23 19:35:09 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23253; Fri, 23 Apr 93 19:35:09 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26425; Fri, 23 Apr 1993 19:55:01 +0200
Received: by fernwood.mpk.ca.us; id AA15253; Fri, 23 Apr 93 10:54:40 -0700
From: mitra@pandora.sf.ca.us (Mitra)
Date: Fri, 23 Apr 1993 10:16:29 PDT
In-Reply-To:  "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
       "DYNAMIC Netfind from WWW" (Apr 23,  7:42am)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: bloemer@tnt.uni-hannover.dbp.de, www-talk@nxoc01.cern.ch
Subject: Re: DYNAMIC Netfind from WWW
Cc: 
Message-Id:  <9304231016.aa22792@pandora.sf.ca.us>

The Dynamic Netfind also fails with the Gopher-Wais gateway.

- Mitra

From mcrae@lib.ucsf.edu  Sat Apr 24 01:17:49 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00222; Sat, 24 Apr 93 01:17:49 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28551; Sat, 24 Apr 1993 01:37:43 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA21197; Fri, 23 Apr 93 16:37:47 PDT
Message-Id: <9304232337.AA21197@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Re:  how should remote path names be handled?
Date: Fri, 23 Apr 93 16:38:47 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>


Jay C. Weber writes:
> How about variable name substitution in URLs?  E.g., you
> could use a HREF=file://$parentsite$parentdir/foo.html to make
> explicit how the broswer should construct relative pathnames.
> 
> The advantage of this over the current HREF=file:foo.html
> scheme is it opens up many other kinds of context-sensitive
> URLs, like substituting the parentsite but naming a new
> directory path.  Or, browsers (the WWW library I guess) could
> define new variables like $standardsite, which would depend
> on the user's continent (per the recent suggestion about
> distributing servers).

  If you are going to add variable substitution to URL's, then perhaps
it would be best to define two types of variables: those which are
to be interpreted by the client, and those which the server should
expand.  
  Thus, a user could configure their browser session so as to
force a particular interpretation of any "variant" links
encountered.  The $standardsite variable mentioned above is
one example of a variable which should be interpreted locally,
i.e. by the client.
  Server-interpreted variables, on the other hand, could be used
by information administrators to ease the task of maintaining
document archives and to enhance reliability and efficiency.  The
$parentsite and $parentdir variables mentioned in Jay's message
are examples of these types of variables.  Another example would
be a $least_busy_server_of_group_GROUP variable, as in
	http://$least_busy_of_group_GROUP/foo.html.
The server would replace this variable with the address of the least
busy server in the group of servers named GROUP.
  So, how are the two types distinguished?  Suppose that a server
variable is preceeded by a single '$'. and client variables would be
referenced by two $, o


From mcrae@lib.ucsf.edu  Sat Apr 24 01:19:42 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00257; Sat, 24 Apr 93 01:19:42 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28634; Sat, 24 Apr 1993 01:39:35 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA21210; Fri, 23 Apr 93 16:39:41 PDT
Message-Id: <9304232339.AA21210@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Dave Raggett's electronic forms?
Date: Fri, 23 Apr 93 16:40:40 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>

Jay,
  What are Dave Raggett's electronic forms?
Chris
-----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From montulli@stat1.cc.ukans.edu  Sun Apr 25 23:34:59 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16605; Sun, 25 Apr 93 23:34:59 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29581; Sun, 25 Apr 1993 23:54:58 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA16072; Sun, 25 Apr 1993 16:47:49 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9304252147.AA16072@stat1.cc.ukans.edu>
Subject: Lynx 2.0.8 released!
To: www-talk@nxoc01.cern.ch
Date: Sun, 25 Apr 93 16:47:49 CDT
X-Mailer: ELM [version 2.3 PL2]

Version .8 of Lynx 2.0 is hereby released.

This is a major bug fix release.  
All reported bugs (50+) have been fixed (I say this with optimism).
I dare you to make it core dump now. :)

There are still a few minor html formatting bugs but this is a very
stable release.  I encourage everyone to find and report any bugs that
you can so that I can release a productional version (non Beta)
by June 1st.

If you are running an earlier version of Lynx PLEASE UPGRADE NOW!

If you read this message and have no idea what Lynx is, telnet
to kufacts.cc.ukans.edu and login as "www" for a demo and explaination.

Lynx source and binaries are available by anonymous FTP
at "ACS220.CC.UKANS.EDU" in the /pub directory.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet                                 *
  *                         Kuhub.cc.ukans.edu                             *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!             913/864-0436           Lawrence, KS 66044  *
  *                                                                        *
  *  For how we live is so different from how we ought to live that he who *
  *  studies what ought to be done rather than what is done will learn the *
  *  way to his downfall rather than to his preservation.  -Machiavelli    *
  **************************************************************************


From ianf@random.se  Mon Apr 26 04:23:36 1993
Return-Path: <ianf@random.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19202; Mon, 26 Apr 93 04:23:36 MET DST
Received: from mail.swip.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21959; Mon, 26 Apr 1993 04:43:35 +0200
Received: by mail.swip.net (5.65c8-/1.2)
	id AA00490; Mon, 26 Apr 1993 04:43:34 +0200
From: ianf@random.se (Ian Feldman)
Date: Mon, 26 Apr 93 03:58:55 +0200
Message-Id: <a8010e79@random.se>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Organization: random design -- "Opinions, cheaply"
X-Note: First Mac browser for setext, the structure-enhanced ASCII text
X-More: format in sumex-aim.stanford.edu:/info-mac/app/easy-view-22.hqx
X-Aftp: <garbo.uwasa.fi> :/mac/tidbits/setext/setext_concepts_Aug92.etx
Content-Type: setext/plain; charset=ascii_827
Content-Length: 1045
Subject: support for setext, the structure-enhanced text format, in WWW


Hi,
  forgive me for barging in on like this, infrequent listener on
  this list that I am, but I'd like you to cast an eye on a dis-
  cussion now underway in alt.hypertext, comp.text.sgml and several
  other crossposted groups, which may be of interest in regard to
  adding an ability to the WWW line-browser to recognize and access
  _implicitly_coded_ anchors in otherwise plaintext documents (the
  setext graphic markup method).

    Try this first:

news:a7fd5104@random.se       18K, 309 lines
news:a800bb38@random.se       24K, 507 lines

    else

file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a7fd5104@random.se
file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a800bb38@random.se

    else

From: Ian Feldman 
Newsgroups: alt.hypertext,comp.multimedia,alt.news-media,comp.text,comp.text.sgml,comp.sys.amiga.multimedia
Subject: Re: Looking for Electronic Publshing formats... [long]

    Thanks & enjoy. I did.


__Ian "Xanadude in waiting" Feldman <ianf@random.se>
       XU/Server[tm] not responding -- still trying


From guido@cwi.nl  Mon Apr 26 09:58:36 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21595; Mon, 26 Apr 93 09:58:36 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27797; Mon, 26 Apr 1993 10:18:32 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA02975 (5.65b/3.8/CWI-Amsterdam); Mon, 26 Apr 1993 10:18:29 +0200
Received: by voorn.cwi.nl with SMTP
	id AA08160 (5.65b/3.8/CWI-Amsterdam); Mon, 26 Apr 1993 10:18:29 +0200
Message-Id: <9304260818.AA08160=guido@voorn.cwi.nl>
To: ianf@random.se (Ian Feldman)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: support for setext, the structure-enhanced text format, in WWW 
In-Reply-To: Your message of "Mon, 26 Apr 1993 03:58:55 MDT."
             <a8010e79@random.se> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Mon, 26 Apr 1993 10:18:28 +0200
Sender: Guido.van.Rossum@cwi.nl

>  forgive me for barging in on like this, infrequent listener on
>  this list that I am, but I'd like you to cast an eye on a dis-
>  cussion now underway in alt.hypertext, comp.text.sgml and several
>  other crossposted groups, which may be of interest in regard to
>  adding an ability to the WWW line-browser to recognize and access
>  _implicitly_coded_ anchors in otherwise plaintext documents (the
>  setext graphic markup method).

Ironically, a similar but different proposal called "simplemail" is
currently being discussed in the IETF mailing list devoted to MIME
(ietf-822).  This is also based on common informal conventions used in
news today, like _this_ or *this*.  Even more ironically, simplemail
was also started by some individuals who didn't like richtext, the
proposal for "simple" text formatting that was originally part of the
proposed MIME standard (it is now a separate RFC).  Richtext looks
like SGML (at least superficially -- some real SGML gurus are offended
by richtext's claim of SGML-ness).

I'm not sure what the importance for WWW is, however.  There's a niche
for simplemail and/or setext in the mail/news world, because many
people will see it without any kind of viewer, and many others will be
composing it casually without help.  WWW documents are *always* viewed
by end users through an HTML-aware viewer, and HTML-aware editors
exist.  Translators from setext or simplemail to richer formats will
appear when these formats really take off.

At least one of simplemail's authors is on the WWW list. (Bill --
where are the simplemail files now?)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From timbl  Mon Apr 26 10:12:27 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21735; Mon, 26 Apr 93 10:12:27 MET DST
Date: Mon, 26 Apr 93 10:12:27 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9304260812.AA21735@ nxoc01.cern.ch >
To: bloemer@tnt.uni-hannover.dbp.de, fine@cis.ohio-state.edu,
        timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: how should remote path names be handled?


This is one of the ways inwhich I an unhappy ith the WAIS-WWW interface.
The WAIS docid is by design a string which should be opaque -- that
it does not hve any client-visible features like / ina URL to allow
relative pathnames. In fact, of course, all it really needs is the
file name, and the document type.  These could be put in in plain.
In fact we have to treat it as an opaque string, almost.We do 
make the assumption that it is a set of numbered fields. This is already
breaking the spec.  We can't assume what those fields are as from time
to time you find an experimental WAIS server weird numbers (which used
to crash the old gateway).

The solution as I see it is to dismantle the freeWAIS code a little
more and make a W3 server which will sit on top of the index
and return real pathnames.

(or you could cheat and run a W3 server which served up the files,
and also was the wais gateway, and change HTWAIS.c so that instead
of returning WAIS URLs it returned URLs pointing to itself as an HTTP
server. The code would not be able to access other WAIS servers but
itwould avoid changing any WAIS code.  Themapping from WAIS URL
to HTTP URL would have to take into account the rule file, or the
rul file would have to avoid mapping between docids and filenames  :-(


Tim BL

From emv@garnet.msen.com  Mon Apr 26 10:32:15 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21978; Mon, 26 Apr 93 10:32:15 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03225; Mon, 26 Apr 1993 10:52:13 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nnOuz-000EYnC; Mon, 26 Apr 93 04:52 EDT
Message-Id: <m0nnOuz-000EYnC@garnet.msen.com>
To: Guido.van.Rossum@cwi.nl
Cc: ianf@random.se (Ian Feldman), www-talk@nxoc01.cern.ch
Subject: Re: support for setext, the structure-enhanced text format, in WWW 
In-Reply-To: Your message of Mon, 26 Apr 93 10:18:28.
             <9304260818.AA08160=guido@voorn.cwi.nl> 
Date: Mon, 26 Apr 93 04:52:05 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

If we make a tiny hack to the WWW "news reader", e.g the thing that
parses NNTP articles, so that text of the form
    file://ftp.msen.com:/pub/emv/
or
    gopher://gopher.msen.com:70/
or other URLs standing by themselves on a line get treated as if they 
were something like
    <a href=file://ftp.msen.com:/pub/emv/></a>
then et voila we get very inexpensive hypertext links from inside news.

To simplify the parsing assume only that the URL is surrounded by whitespace.
Nothing else on the line.

I think this would work OK with both 'setext' and 'simplemail', so
long as both proposals are sparing with markup.

--Ed

From janssen@parc.xerox.com  Tue Apr 27 04:22:17 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09026; Tue, 27 Apr 93 04:22:17 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17817; Tue, 27 Apr 1993 04:42:14 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11728>; Mon, 26 Apr 1993 19:41:46 PDT
Received: by holmes.parc.xerox.com id <16134>; Mon, 26 Apr 1993 19:41:32 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon, 26 Apr 1993 19:41:22 -0700 (PDT)
Message-Id: <ofr9pGUB0KGW03jR5J@holmes.parc.xerox.com>
Date: 	Mon, 26 Apr 1993 19:41:22 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: ianf@random.se (Ian Feldman), Guido.van.Rossum@cwi.nl
Subject: Re: support for setext, the structure-enhanced text format, in WWW
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9304260818.AA08160=guido@voorn.cwi.nl>
References: <9304260818.AA08160=guido@voorn.cwi.nl>

Excerpts from ext.WorldWideWeb: 26-Apr-93 Re: support for setext, the..
Guido.van.Rossum@cwi.nl (1650)

> Ironically, a similar but different proposal called "simplemail" is
> currently being discussed in the IETF mailing list devoted to MIME
> (ietf-822).  This is also based on common informal conventions used in
> news today, like _this_ or *this*.  Even more ironically, simplemail
> was also started by some individuals who didn't like richtext, the
> proposal for "simple" text formatting that was originally part of the
> proposed MIME standard (it is now a separate RFC).  Richtext looks
> like SGML (at least superficially -- some real SGML gurus are offended
> by richtext's claim of SGML-ness).

I actually think that simplemail is quite a bit simpler and less
feature-full than setext, so perhaps this claim is a bit overstated.  My
argument was that for anything more complicated, a *real* markup
language, HTML or something richer, should be used.

> Bill --
> where are the simplemail files now?

ftp://parcftp.parc.xerox.com/transient/simplemail.ps

or

ftp://parcftp.parc.xerox.com/transient/simplemail.text

Bill


From sanders@bsdi.com  Tue Apr 27 05:26:02 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09595; Tue, 27 Apr 93 05:26:02 MET DST
Errors-To: sanders@bsdi.com
Received: from [137.39.95.2] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25280; Tue, 27 Apr 1993 05:46:02 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA12630; Mon, 26 Apr 93 22:45:56 -0500
Message-Id: <9304270345.AA12630@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: HTTP server written in perl
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 26 Apr 1993 22:45:55 -0500
From: Tony Sanders <sanders@bsdi.com>

Hi, I've been working on a HTTP server written in perl (originally from
Marc VanHeyningen at cs.indiana.edu).  I've gotten to the point where I'm
happy with it for my needs and thought maybe someone else might find it
useful.

I'm currently calling it version 0.14.  You can always get the latest
from <A HREF="http://www.bsdi.com/server">here</A>.

You can try it out using the <A HREF="http://www.bsdi.com/">server</A>
I have setup for my company if you like.

Features:

 o Very easy to setup (all code is written in perl)
 o README file with helpful tips
 o config file for easy setup
 o HTML docs <A HREF="http://www.bsdi.com/server/httpd.html">here</A>
 o can be run by normal user if not using port 80
 o chroot() support for more security if wanted
 o directory browser (with last modification, size and file/directory info)
 o date server sample code
 o finger server sample code
 o Other sample gateways from the original code (siks, neuro, sunman)
 o "loadable" drivers (helpful in debugging new gateways)

The code is provided ``as is'', and without warranty but feel free to
send me <sanders@bsdi.com> comments and I'll try and make it better.
If you write other gateways using this scheme please send them to me
and I'll try and integrate them.

    +--+
    |  |____   --------------------------------------------------------------
  __|       |  Tony Sanders                  Development and Customer Support
  \         |  sanders@BSDI.COM              Berkeley Software Design, Inc.
   \/\  * _/                                 1801 Wells Branch Parkway, #2111
      \_ /                                   Austin, TX  78728
        \|

From dsr@hplb.hpl.hp.com  Tue Apr 27 13:13:40 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13561; Tue, 27 Apr 93 13:13:40 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25846; Tue, 27 Apr 1993 13:33:41 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 27 Apr 93 12:27:15 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA02979; Tue, 27 Apr 93 12:34:41 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304271134.AA02979@manuel.hpl.hp.com>
Subject: Standardizing new HTML features
To: www-talk@nxoc01.cern.ch
Date: Tue, 27 Apr 93 12:34:39 BST
Cc: mcrae@lib.ucsf.edu
Mailer: Elm [revision: 66.36.1.1]

In a recent phone conversation, Tim Berners-Lee suggested I take over editing
a new DTD for extensions to the current HTML spec. Don't get worried - the
existing HTML tags will continue unchanged.

We need to pin down the HTML standard to place it on a proper footing as a
MIME content type. Many browsers now go beyond the current DTD and it is only
right that we update the DTD to reflect the best ideas. I hope to have a
preliminary draft available within a week or two to fire off discussions.
The aim is to evolve a consensus view of what extensions are appropriate
and which preserve the overall simplicity of HTML.

The features to consider include:

    o   nested lists (e.g. OL within UL, UL within DL, ...)
    o   embedded images with text flow etc.
    o   query forms
    o   tables
    o   other features ...

The DTD will be tested to ensure it conforms to the SGML standard. I also
would like to have software that allows you to check if your html documents
conform to the extended DTD (with nice warning messages). It would also be
very useful to collect guidelines for how clients should deal with bad HTML -
what rules of thumb people have found to be useful in practice ...

Regards,

Dave Raggett


From TONYJ@scs.slac.stanford.edu  Tue Apr 27 18:36:32 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18901; Tue, 27 Apr 93 18:36:32 MET DST
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09995; Tue, 27 Apr 1993 18:56:34 +0200
Date: Tue, 27 Apr 1993 09:56 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: Standardizing new HTML features
To: dsr@hplb.hpl.hp.com
Cc: www-talk@nxoc01.cern.ch
Message-Id: <6AA755ACB860012C@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"dsr@hplb.hpl.hp.com"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

Dave Raggett writes:

>In a recent phone conversation, Tim Berners-Lee suggested I take over editing
>a new DTD for extensions to the current HTML spec. Don't get worried - the
>existing HTML tags will continue unchanged.

Excellent! One area I would like to see clearly documented is what types of 
nesting of tags is legal, I have not found it clearly documented in the 
existing HTML documentation (of course maybe I didn't follow the right link).

For example, which of the following are legal/supported/encouraged HTML??

<a href=x>The <h1>Link</h1></a>
<a href=x>The <b>link</b></a>    
<b><i><e>Weird</e></i></b>     etc. etc. etc....

Of course one answer is that browsers should do their best with whatever they 
get....but I think in the interest of portability (and of something that works 
fine with ine browser working equally well with another one) it would be better 
to document what things are required to be supported. It would also be useful 
for browsers to have a -noextentensions flag (or some moral equivalent) under 
which they flag anything other than the strictly supported constructs to aid 
people in writing portable HTML. 

Tony





From weber@eitech.com  Tue Apr 27 19:44:19 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20444; Tue, 27 Apr 93 19:44:19 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17069; Tue, 27 Apr 1993 20:04:12 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA15869; Tue, 27 Apr 93 13:03:32 -0500
Received: by eitech.com (4.1/SMI-4.1)
	id AA08281; Tue, 27 Apr 93 10:58:58 PDT
Date: Tue, 27 Apr 93 10:58:58 PDT
From: weber@eitech.com (Jay C. Weber)
Message-Id: <9304271758.AA08281@eitech.com>
To: dsr@hplb.hpl.hp.com
Subject: Re:  Standardizing new HTML features
Cc: sweber@eitech.com, www-talk@nxoc01.cern.ch

Dave,

Three cheers to you for starting to pull together HTML enhancements!

On the subject of query forms, maybe I just don't understand where
Tim's old <QUERYFORM> ideas were heading, but we're working on an
approach that I like better.  I hinted at it in a recent message
regarding variable substitution, here's more detail.

Define new tags for acquiring information from the user about an
object retrieval.  A basic set of these tags is:

1.<ENTRYBLANK TYPE=type LENGTH=length DEFAULT=default VAR=lval>
  Prompt </ENTRYBLANK>

2.<QUESTION TYPE=type DEFAULT=default VAR=lval> Prompt </QUESTION>

3.<CHOICE DEFAULT=default VAR=lval>
  <ALTERNATIVE VAL=value1> Prompt1
  ...
  <ALTERNATIVE VAL=valuen> Promptn
  </CHOICE>

A GUI browser, for example, would turn the first kind of tags into
embedded entry widgets and do value checking based on the *type*
(e.g., string, bool, int, float).  Tags of the second kind might
turn into checkboxes, where the type could be 2-state or 3-state.
In both cases the Prompt would be a label string.  The GUI browser
could turn CHOICE constructs into radio buttons or listboxes,
depending on the number of ALTERNATIVES, the homgeneity of the 
Prompt lengths, etc.

A tty/emacs browser could turn these tags into screen prompts,
y/n questions, menu lists, whatever.

Either way, the key is that these tags set variables, named by VAR
parameters, first to the default value and then to any input by the
user.  These variables can then be substituted into URLs, thereby
dynamically creating URLs based on how the user fills in a form.

This scheme does require a URL variable substitution scheme like
I described in a recent message.  We're working on an implementation
as mods to the HTML 2.0 library.  Tim, would you be interested in
these mods?

Jay Weber
EIT

From janssen@parc.xerox.com  Tue Apr 27 20:35:14 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21483; Tue, 27 Apr 93 20:35:14 MET DST
Received: from [13.1.64.93] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24247; Tue, 27 Apr 1993 20:55:16 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11799>; Tue, 27 Apr 1993 11:54:53 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 27 Apr 1993 11:54:44 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue, 27 Apr 1993 11:54:33 -0700 (PDT)
Message-Id: <YfrM5dMB0KGWM3jKU3@holmes.parc.xerox.com>
Date: 	Tue, 27 Apr 1993 11:54:33 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: Standardizing new HTML features
Cc: mcrae@lib.ucsf.edu
In-Reply-To: <9304271134.AA02979@manuel.hpl.hp.com>
References: <9304271134.AA02979@manuel.hpl.hp.com>

:a 27-Apr-93 Standardizing new HTML feat.. Dave_Raggett@hplb.hpl.hp (1221)

>     o   embedded images with text flow etc.

It would be particularly nice if we got this right.  There was an
exchange a couple of months ago (beginning of March) that you (Dave)
were a part of, about allowing arbitrary embedded ``things'', with their
data being either specified in-line, or being included from another
document.  These things could be images or animations or audio or text
or whatever.  Marc mentioned several problems to be solved (I remember
circular references, for example).

Separable from this is another good idea:

:a 1-Mar-93 Re: proposed new tag: IMG Marc Andreessen@ncsa.uiu (884)

> maybe we should think about a general-purpose procedural
> graphics language within which we can embed arbitrary hyperlinks
> attached to icons, images, or text, or anything.  Has anyone else seen
> Intermedia's capabilities wrt this?  It's one of their most impressive
> capabilities, actually.

> Something like a cross between PostScript and CGM might work...
> actually, maybe we should just use one or the other, and add the
> extensions we need for the links.  Also we'd want to make sure that
it's completely editable.

Sounds like a good thing.  I've always been sort of surprised that TIFF
or another of these extensible image formats hasn't already been
extended to be a ``hyperimage'' format.

Bill

From putz@parc.xerox.com  Tue Apr 27 22:00:10 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23103; Tue, 27 Apr 93 22:00:10 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05142; Tue, 27 Apr 1993 22:20:11 +0200
Received: from spoggles.parc.xerox.com ([13.1.102.87]) by alpha.xerox.com with SMTP id <11822>; Tue, 27 Apr 1993 13:19:50 PDT
Received: by spoggles.parc.xerox.com id <2445>; Tue, 27 Apr 1993 13:19:43 -0700
Date: 	Tue, 27 Apr 1993 13:19:35 PDT
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: Standardizing new HTML features
In-Reply-To: <9304271134.AA02979@manuel.hpl.hp.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Message-Id: <93Apr27.131943pdt.2445@spoggles.parc.xerox.com>

Dave,

Of the features you listed, I personally place the greatest priority on query forms.  Weren't there a couple of proposals on this list a few weeks ago?

-- Steve Putz

From mowgli@magnus.acs.ohio-state.edu  Tue Apr 27 22:28:21 1993
Return-Path: <mowgli@magnus.acs.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23527; Tue, 27 Apr 93 22:28:21 MET DST
Received: from photon.magnus.acs.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09595; Tue, 27 Apr 1993 22:48:24 +0200
Received: by photon.magnus.acs.ohio-state.edu (5.65/3.910213)
	id AA11385; Tue, 27 Apr 93 16:48:23 -0400
From: Mowgli C Assor <mowgli@magnus.acs.ohio-state.edu>
Message-Id: <9304272048.AA11385@photon.magnus.acs.ohio-state.edu>
Subject: Postscript Behavior...
To: www-talk@nxoc01.cern.ch
Date: Tue, 27 Apr 93 16:48:22 EDT
X-Mailer: ELM [version 2.3 PL11]

  Um, I've been playing with various ways of getting postscript to display
via XMosaic (1.0). When you use FTP, things are fine, because the FTP daemon
doesn't do any processing, and so when XMosaic hands off to Ghostview or
whatever, life is fine.

  However, when HTTP processes the file, it puts the line :

<PLAINTEXT>

in front of the rest of the document. Thus, when it gets back to Ghostview,
it chokes because <PLAINTEXT> is invalid PS. This may again get us to the
point of needing "type tags" for different types of files, but with the
coming various "multi-media" browsers, it seems to me to be a problem we
need to solve somehow (perhaps the URLs will help, but I don't think they
are the ultimate solution).

  I can just set up a filter for Ghostscript which removes the offending
line, but is there a better solution?

				Thanks, <Mowgli>
-- 
Address: mowgli@magnus.acs.ohio-state.edu (Mowgli Assor in quasi-real life)
"Too many lonely hearts in the real world. Too many lonely nights in the real
 world. Too many fools who don't think twice, too many ways to pay the price.
 Don't wanna live my life in the real world." - The Alan Parsons Project

From marca@wintermute.ncsa.uiuc.edu  Wed Apr 28 00:23:01 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25370; Wed, 28 Apr 93 00:23:01 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02710; Wed, 28 Apr 1993 00:43:04 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11199
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 27 Apr 93 17:43:00 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA08523; Tue, 27 Apr 93 17:45:19 -0500
Date: Tue, 27 Apr 93 17:45:19 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304272245.AA08523@wintermute.ncsa.uiuc.edu>
To: Mowgli C Assor <mowgli@magnus.acs.ohio-state.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Postscript Behavior...
In-Reply-To: <9304272048.AA11385@photon.magnus.acs.ohio-state.edu>
References: <9304272048.AA11385@photon.magnus.acs.ohio-state.edu>
X-Md4-Signature: 321289c77a34540e193594af2c073c98

Mowgli C Assor writes:
>   Um, I've been playing with various ways of getting postscript to display
> via XMosaic (1.0). When you use FTP, things are fine, because the FTP daemon
> doesn't do any processing, and so when XMosaic hands off to Ghostview or
> whatever, life is fine.
> 
>   However, when HTTP processes the file, it puts the line :
> 
> <PLAINTEXT>
> 
> in front of the rest of the document. Thus, when it gets back to Ghostview,
> it chokes because <PLAINTEXT> is invalid PS. This may again get us to the
> point of needing "type tags" for different types of files, but with the
> coming various "multi-media" browsers, it seems to me to be a problem we
> need to solve somehow (perhaps the URLs will help, but I don't think they
> are the ultimate solution).
> 
>   I can just set up a filter for Ghostscript which removes the offending
> line, but is there a better solution?

The long-term solution is to move to HTTP2.  One short-term solution
that you may want to explore is the NCSA public domain httpd, on
ftp.ncsa.uiuc.edu in /Mosaic/ncsa_httpd, which will never do this to
data files.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Wed Apr 28 00:25:32 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25417; Wed, 28 Apr 93 00:25:32 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02825; Wed, 28 Apr 1993 00:45:35 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11407
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 27 Apr 93 17:45:26 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:dsr@hplb.hpl.hp.com id AA08528; Tue, 27 Apr 93 17:47:25 -0500
Date: Tue, 27 Apr 93 17:47:25 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304272247.AA08528@wintermute.ncsa.uiuc.edu>
To: Putz.parc@xerox.com
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Subject: Re: Standardizing new HTML features
In-Reply-To: <93Apr27.131943pdt.2445@spoggles.parc.xerox.com>
References: <9304271134.AA02979@manuel.hpl.hp.com>
	<93Apr27.131943pdt.2445@spoggles.parc.xerox.com>
X-Md4-Signature: 99a0f85df9e267e987da05d1c6ffa7f2

Putz.parc@xerox.com writes:
> Of the features you listed, I personally place the greatest priority
> on query forms.  Weren't there a couple of proposals on this list a
> few weeks ago?

Query forms and tables are my top two requests.  Dave's previous
proposals for query forms looked great to me at the time (as did his
table ideas -- at least I think they were his.....?  maybe I'm
confused).

Cheers,
Marc


From raisch@ora.com  Wed Apr 28 00:26:16 1993
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25424; Wed, 28 Apr 93 00:26:16 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02864; Wed, 28 Apr 1993 00:46:14 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA25101; Tue, 27 Apr 1993 18:45:23 -0400
Date: Tue, 27 Apr 1993 17:19:05 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Sender: Rob Raisch <raisch@ora.com>
Reply-To: Rob Raisch <raisch@ora.com>
Subject: Re: Standardizing new HTML features... WE'RE INTERESTED!
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch, mcrae@lib.ucsf.edu, Dale Dougherty <dale@ora.com>
In-Reply-To: <9304271134.AA02979@manuel.hpl.hp.com>
Message-Id: <Pine.3.03.9304271538.K11156-d100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


Dave,
	O'Reilly and Associates is *extremely* interested in helping you with
this effort.  We have a number of products in development which use HTML as
their technology base.  We see the future development of HTML to be of great
importance to our efforts.

	You mention the following as important issues in the future of HTML:

<QUOTE AUTHOR="Dave_Raggett <dsr@hplp.hpl.hp.com>">
    o   nested lists (e.g. OL within UL, UL within DL, ...)
    o   embedded images with text flow etc.
    o   query forms
    o   tables
</QUOTE>

	I would suggest that lists and text flow are really exclusively
rendering issues.  When I want to make a nested list, I may wish to write it
thusly:

<EXAMPLE>
	<UL>
	<LI>First Term, First Level.
	<UL>
	<LI>First Term, Second Level.
	<LI>Second Term, Second Level.
	</UL>
	<LI>Second Term, First Level.
	</UL>
</EXAMPLE>

	And I might *EXPECT* that it would be rendered as:

<PRE>
		First Term, First Level
			First Term, Second Level
			Second Term, Second Level
		Second Term, First Level
</PRE>

	
<COMMENT> And in fact, under Xmosaic, the *right* thing is done, with the
addition of some nice bullets to differentiate the different levels of the list.
</COMMENT>

But since there is no rendering information in HTML, and by definition there
cannot be, how the terms appear on the screen is left up to the renderer.  For
example, the www text mode browser renders these lists thusly: 

<PRE>
		First Term, First Level.
      
		First Term, Second Level.
      
		Second Term, Second Level.
      
		Second Term, First Level.
     
		[End]
</PRE>

	Since there is no definition of how things *must* look when presented to
the user, both behaviors are absolutely correct.

<HYPOTHESIS> Any expectations of how an object is rendered will be incorrect in
some instance of the use of that object.  Thus, all expectations of an object's
appearance are generally inadvisable.  </HYPOTHESIS>

	I would also suggest that the requirements of 'text flow' around
embedded graphics are also rendering time issues and should not effect the
definition of HTML. 

<OPINION> I believe that HTML, like it's progenitor SGML, should be simply a
method of describing data, not how it should appear on the screen.  In fact, I
think that this is exactly the sentiment which Tim Berners-Lee has expressed to
us all regarding his vision of HTML. The formatting of lists and the flow of
text around graphics do not fit this definition.  If this is an incorrect
assessment of the role HTML needs to serve I would be very interested in hearing
from others. </OPINION>

	The next elements on your list, query forms and tables, seem to be a
little clearer but pose similar problems. 

	To describe a "form", in the traditional sense, implies it's layout
simply based on the fact that a "form" is the presentation of information in a
controlled layout or format.  

<HYPOTHESIS> A form or table cannot be specified in HTML without breaking one of
HTML's first principles since forms and tables are descriptions of the
appearance of information in relationship to other elements and not the
description of information in terms of type and content. </HYPOTHESIS>

I believe that we can ask questions:

<EXAMPLE>
	<QUERY DEFAULT="Red" OPTIONS="Black|Blue|Red|Green|White">
	What is your favorite colour?
	</QUERY> 
</EXAMPLE>

since this is the tagging of an entity (description of data), with certain
special behaviors or attributes defined, I would think that this would be a
natural for HTML.

But, the moment we start talking about collecting this information into forms or
tables, with set, defined  relationships between elements, we are treading on
very thin ice, indeed. 

<ASIDE> I hesitate to mention it, but SGML has few (if any) provisions for
handling tabular data, and there are a lot of people who really want to be able
to do this, desperately! </ASIDE>

<ASSERTION> The organization of information into tabular form is intrinsically a
render-time issue, not a representational one. </ASSERTION>


	I am very interested in these issues, both from a personal standpoint
and a company one.  I have some ideas regarding a possible solution which I will
send out under seperate cover.  Thanks for your time.


 <SIGNATURE>	Rob Raisch, O'Reilly & Assoc.	</SIGNATURE>



From marca@wintermute.ncsa.uiuc.edu  Wed Apr 28 00:47:34 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25785; Wed, 28 Apr 93 00:47:34 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06690; Wed, 28 Apr 1993 01:07:37 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA13083
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 27 Apr 93 18:07:23 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:dsr@hplb.hpl.hp.com id AA08657; Tue, 27 Apr 93 18:09:42 -0500
Date: Tue, 27 Apr 93 18:09:42 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304272309.AA08657@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, mcrae@lib.ucsf.edu,
        www-talk@nxoc01.cern.ch
Subject: Re: Standardizing new HTML features
In-Reply-To: <YfrM5dMB0KGWM3jKU3@holmes.parc.xerox.com>
References: <9304271134.AA02979@manuel.hpl.hp.com>
	<YfrM5dMB0KGWM3jKU3@holmes.parc.xerox.com>
X-Md4-Signature: 22de3ced6b3768fca084c322c023ad9e

Bill Janssen writes:
> :a 27-Apr-93 Standardizing new HTML feat.. Dave_Raggett@hplb.hpl.hp (1221)
> 
> >     o   embedded images with text flow etc.
> 
> It would be particularly nice if we got this right.  There was an
> exchange a couple of months ago (beginning of March) that you (Dave)
> were a part of, about allowing arbitrary embedded ``things'', with
> their data being either specified in-line, or being included from
> another document.  These things could be images or animations or
> audio or text or whatever.  Marc mentioned several problems to be
> solved (I remember circular references, for example).

Yup, and I got jumped on (justifiably so, I suppose :-).  What
concerns me is not necessarily circular references (as Guido pointed
out at the time, that's easily avoidable) but rather the precedent and
mechanism this puts in place for making documents arbitrarily complex
in terms of the network connections needed to put them together on the
client side.  Inlined images located on other servers are bad enough
-- if we start making generic inclusions available, things are going
to get hairy.  IMHO.

Plus, this is hypertext -- most times, generic inclusions shouldn't be
per se necessary, or even necessarily useful compared to a hyperlink.

Also, I'm not certain that any multimedia data other than images needs
to be specifiable as inlined/included.  Things like audio and MPEG can
simply be pointed at from an anchor (as Mosaic does) and forked to
external viewers or processed internally, whichever the browser
prefers -- and with inlined images the whole thing will be iconic
anyway.

I would certainly love to hear discussion about what to do with text
flow -- it's starting to become a popular request.

Cheers,
Marc


From janssen@parc.xerox.com  Wed Apr 28 01:21:23 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26146; Wed, 28 Apr 93 01:21:23 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12757; Wed, 28 Apr 1993 01:41:26 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11888>; Tue, 27 Apr 1993 16:40:57 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 27 Apr 1993 16:40:54 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue, 27 Apr 1993 16:40:53 -0700 (PDT)
Message-Id: <MfrQG50B0KGWA3jLNB@holmes.parc.xerox.com>
Date: 	Tue, 27 Apr 1993 16:40:53 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, Mowgli C Assor <mowgli@magnus.acs.ohio-state.edu>
Subject: Re: Postscript Behavior...
In-Reply-To: <9304272048.AA11385@photon.magnus.acs.ohio-state.edu>
References: <9304272048.AA11385@photon.magnus.acs.ohio-state.edu>

Excerpts from ext.WorldWideWeb: 27-Apr-93 Postscript Behavior... Mowgli
C Assor@magnus.ac (1165)

> I've been playing with various ways of getting postscript to display
> via XMosaic (1.0). When you use FTP, things are fine

Well, not quite.  Though I've come to really enjoy XMosaic, and
appreciate greatly the enormous utility it provides, there do seem to be
two classes of documents:  those which are displayed in the XMosaic
document window, and those which are displayed by some external viewer
program (a feature which I think is great).  If a file is displayed in
the document window, I can manipulate it in certain ways; I can view the
source with the menu item "File/Document Source...", I can save it to a
file via the "Save As..." button.  When a file is displayed in some
external viewer, I can do neither; typically XMosaic's view of "what
document is selected" is the directory from which I selected the actual
selected document.

It would be nice if when a Postscript, audio, or image file is selected
(or any type which uses an external viewer), XMosaic would put something
in the document window (maybe "Document foo://foo.bar.bletch/dir/name
being displayed via command `xv DOC'" or some such), and make the source
of the document manipulable via the "File/Document Source..." and "Save
As..." buttons.  Or in some other way unify the two classes.

(I feel that I should emphasize what a minor though annoying bug this is
in a really great piece of work :-).

Bill

From marca@wintermute.ncsa.uiuc.edu  Wed Apr 28 01:38:20 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26383; Wed, 28 Apr 93 01:38:20 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14843; Wed, 28 Apr 1993 01:58:03 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16289
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 27 Apr 93 18:57:59 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:mowgli@magnus.acs.ohio-state.edu id AA08855; Tue, 27 Apr 93 19:00:17 -0500
Date: Tue, 27 Apr 93 19:00:17 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304280000.AA08855@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: Mowgli C Assor <mowgli@magnus.acs.ohio-state.edu>, www-talk@nxoc01.cern.ch
Subject: Re: Postscript Behavior...
In-Reply-To: <MfrQG50B0KGWA3jLNB@holmes.parc.xerox.com>
References: <9304272048.AA11385@photon.magnus.acs.ohio-state.edu>
	<MfrQG50B0KGWA3jLNB@holmes.parc.xerox.com>

Bill Janssen writes:
> It would be nice if when a Postscript, audio, or image file is selected
> (or any type which uses an external viewer), XMosaic would put something
> in the document window (maybe "Document foo://foo.bar.bletch/dir/name
> being displayed via command `xv DOC'" or some such), and make the source
> of the document manipulable via the "File/Document Source..." and "Save
> As..." buttons.  Or in some other way unify the two classes.

Yup -- in 2.x (or whatever we call the Next Generation, this summer),
non-text datatypes will be represented iconically and one will be able
to save to file, print (if possible), pipe through external viewer,
display with default mechanism, reload over the network, or whatever,
through the GUI.  This will be part of the MIME support also.  And the
WYSIWYG editing.  (Promises promises.)

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From janssen@parc.xerox.com  Wed Apr 28 01:58:34 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26629; Wed, 28 Apr 93 01:58:34 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17161; Wed, 28 Apr 1993 02:18:37 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11923>; Tue, 27 Apr 1993 17:18:11 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 27 Apr 1993 17:18:00 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue, 27 Apr 1993 17:17:55 -0700 (PDT)
Message-Id: <cfrQon0B0KGW83jSd2@holmes.parc.xerox.com>
Date: 	Tue, 27 Apr 1993 17:17:55 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Bill Janssen <janssen@parc.xerox.com>,
        marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Standardizing new HTML features
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, mcrae@lib.ucsf.edu,
        www-talk@nxoc01.cern.ch
In-Reply-To: <9304272309.AA08657@wintermute.ncsa.uiuc.edu>
References: <9304271134.AA02979@manuel.hpl.hp.com>
	<YfrM5dMB0KGWM3jKU3@holmes.parc.xerox.com>
	<9304272309.AA08657@wintermute.ncsa.uiuc.edu>

Excerpts from ext.WorldWideWeb: 27-Apr-93 Re: Standardizing new HTML ..
Marc Andreessen@ncsa.uiu (1750)

> Plus, this is hypertext -- most times, generic inclusions shouldn't be
> per se necessary, or even necessarily useful compared to a hyperlink.

Perhaps so, perhaps not.  There's a difference between a multimedia
document and a hyperlinked document, as your experiments with embedded
images richly show.

> Also, I'm not certain that any multimedia data other than images needs
> to be specifiable as inlined/included.  Things like audio and MPEG can
> simply be pointed at from an anchor (as Mosaic does) and forked to
> external viewers or processed internally, whichever the browser
> prefers...

Come now, so can images.  So why special-case them in XMosaic?  Because
your users are looking for multi-media, not just hypermedia.  Similarly,
HTML should allow embedded animations (very useful in documentation of
gestural interfaces, for one thing) or graphs or even other text.  I'm
basing my expectation of the power and utility of this mechanism on my
experience with Andrew and Slate, both of which have this feature. 
Typically what is shown for embedded sound, for instance, is a small
(tiny) control panel which allows control over the speed and amount of
the sound inset that is actually played, along with a label.

The other thing is, if you can specify the data for one of these
embedded things directly in the HTML document, you can then avoid some
of the complexity/connectivity problems you mention.  That's what I
meant by "in-line data", as opposed to "in-line" presentation, which
both included and external data would, presumably, have.

Bill

From mcrae@lib.ucsf.edu  Wed Apr 28 02:35:34 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27080; Wed, 28 Apr 93 02:35:34 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27374; Wed, 28 Apr 1993 02:55:36 +0200
Received: from stimpy.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA04724; Tue, 27 Apr 93 17:55:18 PDT
Message-Id: <9304280055.AA04724@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Proper use of HTML/SGML (was Re: Standardizing new HTML features)
Date: Tue, 27 Apr 93 17:57:28 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>

Rob,

  Either I'm getting used to markup, or your message was the clearest
example I've ever seen.  The text just flowed. ;^)

<QUOTE AUTHOR="Rob Raisch <raisch@ora.com>">
<OPINION> I believe that HTML, like it's progenitor SGML, should be simply a
method of describing data, not how it should appear on the screen.  In fact, I
think that this is exactly the sentiment which Tim Berners-Lee has expressed to
us all regarding his vision of HTML. The formatting of lists and the flow of
text around graphics do not fit this definition.  If this is an incorrect
assessment of the role HTML needs to serve I would be very interested in hearing
from others. </OPINION>
</QUOTE>

<OBSERVATION>
   HTML alone, in it's current form, is inadequate to serve the needs of
our community.  It has been designed/cultivated to describe the structure
of documents in an abstract manner.  It assumes that presentation issues
are resolved by the particular client system via some specific rendering
process.
  However, the community of users and publishers is demanding presentation-
level markup capabilites.  For various reasons, publishers want to express
their vision of how a document should appear.
</OBSERVATION>

<QUESTION> What is the mechanism by which we can represent presentational
"hints" in WWW documents?  I call them "hints" because a client is always
free to ignore any markup it doesn't like or understand.
</QUESTION>

  As Ian Feldman recently pointed out, a somewhat parallel discussion has
been taking place in comp.text, comp.text.sgml, and etc.  I would call your
attention to several articles in particular:
<DL>
<DT> <A HREF="news:19930426.003@erik.naggum.no">
  Four types of markup </A>
<DD>
	Coombs, Renear and DeRose : Markup Systems and the Future of
	Scholarly Text Processing, in CACM 30/11 (1987) pp 933-947.
<DT> <A HREF="news:1993Apr26.113014.21948@csi.uottawa.ca">
  SGML Document Design </A>
<DD>
	Document design conventions versus format constraints of SGML.
<DT> <A HREF="1993Apr27.181356.15093@msi.com">
  Multiple layers of markup</A>
<DD>
	Why can't we define multiple layers of markup spanning all these
	levels of structure?  A client could display whichever layer(s)
	the user was currently interested in.
<DT> <A HREF="news:19930427.154307.235@almaden.ibm.com">
  Re: Multiple levels of markup </A>
<DD>
	Follow-up to previous referenced article.
</DL>

Chris
-----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From mcharity@hq.lcs.mit.edu  Wed Apr 28 03:31:54 1993
Return-Path: <mcharity@hq.lcs.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27644; Wed, 28 Apr 93 03:31:54 MET DST
Received: from HQ.LCS.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10904; Wed, 28 Apr 1993 03:51:58 +0200
Received: by hq.LCS.MIT.EDU 
	id AA00452; Tue, 27 Apr 93 21:51:54 EDT
Date: Tue, 27 Apr 93 21:51:54 EDT
From: mcharity@hq.lcs.mit.edu (Mitchell N Charity)
Message-Id: <9304280151.AA00452@hq.LCS.MIT.EDU>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Marc Andreessen's message of Tue, 27 Apr 93 18:09:42 -0500 <9304272309.AA08657@wintermute.ncsa.uiuc.edu>
X-Phone: NE43-512:(617)253-6023  fax:258-8682  home:497-1506
Subject: Standardizing new HTML features
Reply-To: mcharity@lcs.mit.edu

Marc Andreessen writes:
>Plus, this is hypertext -- most times, generic inclusions shouldn't be
>per se necessary, or even necessarily useful compared to a hyperlink.

(Someone will shortly begin firing 22 caliber rounds into my office[1],
 so I will leave this verbose.)

Claim:
  Textual inclusion is a fundamental indirection/abstraction mechanism,
  required if www is to scale in volume and duration.

Argument:
 1 Inlining of dynamic/living documents is needed.
 2 This can be done at server or at client.
 3 You sometimes(often?) dont want to do it at server.

Elaboration:
 1. What happens if you cant inline dynamic information?
    Options:
      - Copying, and then either maintaining consistency or
                                 accepting obsolence.
      - Hyperlinking to it, even when you need it in flow of the doc.
      - Doing both, and push the burden onto the human.
      - Giving up.
 2. ...
 3. ...

Mumbles:
  I have fuzzy recollection of a cern doc which mentions brewster at
TMC in cambridge.  He switches jobs.  Does tim 1- leave it outdated
(print model), 2- hand edit it every time brewster moves (toy system
model), or what?
  What if I wish to inline think.com's phone number or mailing address?
  Suppose I write a living document criticizing unix.  To illustrate
my point, I wish to quote some single FAQ entry.  Do I 1- copy it, thus
losing the benefit of improvements to the FAQ, 2- point to it, forcing
me to use a document structuring I didnt want, 3- periodically hand
edit it (not), 4- have an agent edit it, n- or what?
  Can I create a composite document with out either losing consistency
or looking like a gopher menu?
  Inlining, by virtue of making the web representation more powerful,
might be used to address other problems.
Caching might be addressed by something (remotely) like
<A HREF=<INLINE HREF="http://wwwnamed-host/cern-cache">/pub/mumble>cern</A>.
WWW cache inheretence then follows the DNS hierarchy.

Must go.

Clarification:
 [1] Ceiling lights being rehung from concrete.

From marca@wintermute.ncsa.uiuc.edu  Wed Apr 28 04:06:21 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27892; Wed, 28 Apr 93 04:06:21 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16384; Wed, 28 Apr 1993 04:26:25 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24834
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 27 Apr 93 21:26:23 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA09321; Tue, 27 Apr 93 21:28:42 -0500
Date: Tue, 27 Apr 93 21:28:42 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304280228.AA09321@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: wais gateway available
X-Md4-Signature: 42df1f831b6b23655d6d31dca53c2051

North American WWW users, there is a WWW/WAIS gateway now available at
www.ncsa.uiuc.edu:8001.  It may not be quite stable yet, but feel free
to use it.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From cardeci@lysator.liu.se  Wed Apr 28 04:20:22 1993
Return-Path: <cardeci@lysator.liu.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28027; Wed, 28 Apr 93 04:20:22 MET DST
Received: from lysator.liu.se by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21811; Wed, 28 Apr 1993 04:40:26 +0200
Received: from bodil.lysator.liu.se (130.236.254.152) by lysator.liu.se (ALPHA-6.36/6.16) id AA21041; Wed, 28 Apr 1993 04:40:17 +0200 
Received: by bodil.lysator.liu.se (ALPHA-6.36/6.16) id AA17657; Wed, 28 Apr 1993 04:39:59 +0200 
Date: Wed, 28 Apr 1993 04:39:59 +0200
From: cardeci@lysator.liu.se
Message-Id: <199304280239.AA17657@bodil.lysator.liu.se>
To: www-talk@nxoc01.cern.ch
Subject: Lysator's WWW server

For those of you who haven't noticed, there is a new server, Lysators

http://www.lysator.liu.se:7500/


The '/' page:

Lysator Academic Computer Society 
=================================

Lysator's Gopher service 
   Includes the 'Projekt Runeberg', the Scandinavian electronic text
   projekt, and a lot of info about Lysator and Linkvping in general. A lot
   of these texts are being converted to hypertext format, so they will be
   available directly in WWW soon.

Lysator's FTP service 
   A lot of files, including Prime/PRIMOS; science fiction info; Amiga;
   LPMUD; LysKOM apps; IRC; Gnu EMACS; Ident server software.

Info about the MUD:s at Lysator, and MUD in general 
   Some info about the three differents MUD's running at Lysator.

The Science Fiction Archive 
   The archive of Science Fiction and Fantasy that currently resides
   here at Lysator is a collection of texts saved from USENET during
   the last 7-8 years. It is mostly reviews and lists of different kinds.

The whole Hackers Jargon file 
   This one is more than 1Mb largs, so it will take quite some time to get
   it, and format it for viewing. It will be fixed later.

About Lysator 
   Some information about Lysator Academic Computer Society, Here
   all members are listed (more than 300). More data is on the way.

Om Lysator (As above, but in swedish). 
   Lite info om Lysator, den stvrsta universitetsdatorfvreningen i
   Linkvping.

Dynamic Information
===================

Who's on at Lysator right now? 
   This is a listing of currently logged in persons.

Todays fortune 
   The infamous Fortune program.

Remote WWW's
============

Internet Info and all RFC's 
   The documents that provides the policies and standards of the 
   Internet.

The NCSA Mosaic Home Page 
   Information about the Mosaic client program for the World Wide Web.

Data by Subject 
   This is a listning of different WWW services available, organized by
   subject.

Selected Data 
   Here you can find some files from all over Internet, that have been
   selected because of their interesting subjects (At the moment pointers
   to a lot of etexts).

Per Hedbor (webmaster@lysator.liu.se)

From cardeci@lysator.liu.se  Wed Apr 28 05:15:39 1993
Return-Path: <cardeci@lysator.liu.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28525; Wed, 28 Apr 93 05:15:39 MET DST
Received: from lysator.liu.se by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07354; Wed, 28 Apr 1993 05:35:42 +0200
Received: from bodil.lysator.liu.se (130.236.254.152) by lysator.liu.se (ALPHA-6.36/6.16) id AA23948; Wed, 28 Apr 1993 05:35:40 +0200 
Received: by bodil.lysator.liu.se (ALPHA-6.36/6.16) id AA18435; Wed, 28 Apr 1993 05:35:22 +0200 
Date: Wed, 28 Apr 1993 05:35:22 +0200
From: cardeci@lysator.liu.se
Message-Id: <199304280335.AA18435@bodil.lysator.liu.se>
To: www-talk@nxoc01.cern.ch
Subject: Lysator's WWW server


For those of you who haven't noticed, there is a new server, Lysators

http://www.lysator.liu.se:7500/


The '/' page:

Lysator Academic Computer Society 
=================================

Lysator's Gopher service 
   Includes the 'Projekt Runeberg', the Scandinavian electronic text
   projekt, and a lot of info about Lysator and Linkvping in general. A lot
   of these texts are being converted to hypertext format, so they will be
   available directly in WWW soon.

Lysator's FTP service 
   A lot of files, including Prime/PRIMOS; science fiction info; Amiga;
   LPMUD; LysKOM apps; IRC; Gnu EMACS; Ident server software.

Info about the MUD:s at Lysator, and MUD in general 
   Some info about the three differents MUD's running at Lysator.

The Science Fiction Archive 
   The archive of Science Fiction and Fantasy that currently resides
   here at Lysator is a collection of texts saved from USENET during
   the last 7-8 years. It is mostly reviews and lists of different kinds.

The whole Hackers Jargon file 
   This one is more than 1Mb largs, so it will take quite some time to get
   it, and format it for viewing. It will be fixed later.

About Lysator 
   Some information about Lysator Academic Computer Society, Here
   all members are listed (more than 300). More data is on the way.

Om Lysator (As above, but in swedish). 
   Lite info om Lysator, den stvrsta universitetsdatorfvreningen i
   Linkvping.

Dynamic Information
===================

Who's on at Lysator right now? 
   This is a listing of currently logged in persons.

Todays fortune 
   The infamous Fortune program.

Remote WWW's
============

Internet Info and all RFC's 
   The documents that provides the policies and standards of the 
   Internet.

The NCSA Mosaic Home Page 
   Information about the Mosaic client program for the World Wide Web.

Data by Subject 
   This is a listning of different WWW services available, organized by
   subject.

Selected Data 
   Here you can find some files from all over Internet, that have been
   selected because of their interesting subjects (At the moment pointers
   to a lot of etexts).

Per Hedbor (webmaster@lysator.liu.se)


From bloemer@tnt.uni-hannover.dbp.de  Wed Apr 28 09:21:32 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00644; Wed, 28 Apr 93 09:21:32 MET DST
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26613; Wed, 28 Apr 1993 09:41:29 +0200
Received: by ixgate.gmd.de id AA16134; Wed, 28 Apr 93 09:40:29 +0200
Date: 28 Apr 93  7:40 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: janssen@parc.xerox.com, marca@ncsa.uiuc.edu
Message-Id: <RFC-822:>
Subject: Re: Standardizing new HTML features

RFC-822-HEADERS:
Cc: dsr@hplb.hpl.hp.com, mcrae@lib.ucsf.edu, www-talk@nxoc01.cern.ch, bloemer

==================

> From marca@wintermute.ncsa.uiuc.edu Wed Apr 28 01:17:16 1993
> ...
> Also, I'm not certain that any multimedia data other than images needs
> to be specifiable as inlined/included.  Things like audio and MPEG can
> simply be pointed at from an anchor (as Mosaic does) and forked to
> external viewers or processed internally, whichever the browser
> prefers -- and with inlined images the whole thing will be iconic
> anyway.

But it is much more impressive and intuitive, when you click on an
image and it starts moving in place. Paradise Software Inc. have a demo
which shows a hypermedia newspaper. In that demo there are two images 
which serve as anchors to two movies. When you start the movies they 
will run at the location of the images. I showed the demo to a couple 
of people and all were very impressed.

> 
> I would certainly love to hear discussion about what to do with text
> flow -- it's starting to become a popular request.

I would like this feature also very much.

Arnold


________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49 511 762-5333           D-3000 Hannover 1
phone:  +49 511 762-5320           Germany
________________________________________________________________________________


From cja@castle.edinburgh.ac.uk  Wed Apr 28 10:03:42 1993
Return-Path: <cja@castle.edinburgh.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01041; Wed, 28 Apr 93 10:03:42 MET DST
Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02708; Wed, 28 Apr 1993 10:23:44 +0200
Via: uk.ac.edinburgh.castle; Wed, 28 Apr 1993 09:22:56 +0100
To: www-talk@nxoc01.cern.ch
Subject: Extending HTML
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Date: Wed, 28 Apr 93 9:21:49 WET DST
Message-Id: <9304280921.aa24764@castle.ed.ac.uk>

RARE has set up a short study on network access to multimedia
information, which I am conducting.  I'm listening to the discussions on
extending HTML and HTTP with great interest. 

Talking to some of the potential USERS of multimedia information servers
(MMIS) and looking at their projects, I came up with a list of
requirements.  I know that WWW can do much of this, but not all, and it
seems that this might be a good time to mention some of these
requirements.  There are sections on Hyperlinks, Presentation (this
matches up with discussions on text flowing, inline images etc),
Searching, QoS and Management.  I'd be interested in comments. 

HYPERLINKS

It is clear that many applications require their users to be able to
navigate through the information base according to relationships
determined by the information provider - in other words, hyperlinks. 

Some "hypermedia" systems are in fact simply hypertext, in that they
require the source anchor of a hyperlink to be in a text node.  A true
hypermedia system allows hyperlinks to have their source anchors in
nodes of any media type.  This allows a user to click the mouse on a
component of a diagram or on part of a video sequence to cause one or
more related nodes to be retrieved and displayed. 

Some hypermedia systems allow target anchors of a hyperlinks to be
finer-grained than a whole node - eg the target anchor could be a word
or a paragraph within a text document.  It is not clear to me whether
this is a critical requirement.

PRESENTATION

Related information of different media types must be capable of
synchronised display.  The synchronisation may be in time and/or space. 
For instance, an image may have an associated text caption which should
be retrieved at the same time as the image and displayed adjacent to it,
perhaps in a window which the user can scroll.  A sound clip may have
some associated text (perhaps a translation) which must be displayed in
sync with the sound, eg in an automatically-scrolled window. 

SEARCHING

Database-type applications require varying degrees of sophistication in
retrieval techniques.  Typically, non-text nodes form the major data of
interest.  Such nodes have associated descriptions, which may be plain
text, or may be structured into fields.  Users need to be able to search
the descriptions, obtain a list of "hits", and select nodes from that
list to display.  Searching requirements vary from simple keyword
searching to full-text indexing (with or without Boolean combinations of
search words), to full SQL-style database retrieval languages.

The user must be able to retrieve and display all the information in a
record in a single operation.  (This may involve several separate
retrieval operations "under the hood", but the user should not be aware
of this.)

QUALITY OF SERVICE

User toleration of delay in computer systems depends on user perception
of the nature of the requested action.  If the user believes that no
computation is required, tolerable delays are of the order of 0.2s.  If
the user believes the action he or she has requested the computer to
perform is "difficult" - for instance a computation of some form - then
a tolerable delay is of the order of 2s.  Users tend to give up waiting
for a response after about 20s.

Such user expectations are difficult to meet, particularly for
voluminous multimedia data.  There are several ways of alleviating this
problem, some of which are described below. 

 *	Give clues that fetching a particular item might be timeconsuming -
	simply quoting the size may be sufficient. 

 *	Display a "progress" indicator while fetching data. 

 *	Allow the user to interact with other, previously fetched information
	while waiting for data to be fetched. 

 *	Allow several fetches to be performed in parallel. 

 *	Pre-fetch information which the client software believes the user
	will wish to see next. 

 *	Cache information locally. 

 *	Where multiple copies of the same information are held in different
	network locations, fetch the "nearest" copy.  This is (sometimes)
        known as "anycasting". 

 *	Offering multiple views of image or video data at different
	resolutions and therefore sizes enable the user to select a balance
	between speed of retrieval and data quality. 

 *      Make provision for using isochronous data streams (if available)
        for audio and video.

MANAGEMENT

In order to support applications involving real-money information
services (eg academic publishing) and learning/assessment applications,
there must be a reliable and secure access control mechanism.  A simple
password is unlikely to suffice - Kerberos authentication procedures are
a possibility. 

Users must be able to determine the charge for an item before retrieving
it (assuming that pay-per-item will be a common paradigm - alternatives
such as pay-per-call, pay-per-duration are also possible).  Access
records must be kept by the information server for charging purposes. 

Learning applications have similar requirements, except that the purpose
here is not to charge for information retrieved, but to monitor and
perhaps assess a student's progress. 

OTHER

Another requirement which has escaped from the above list is the ability to
specify in a hypermedia document a mail address, in such a way that the
user can click on it to invoke his/her mailer with the address ready
in the To: field.

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom



From dsr@hplb.hpl.hp.com  Wed Apr 28 12:31:51 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02807; Wed, 28 Apr 93 12:31:51 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25114; Wed, 28 Apr 1993 12:51:53 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 28 Apr 93 11:45:28 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA15480; Wed, 28 Apr 93 11:52:56 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304281052.AA15480@manuel.hpl.hp.com>
Subject: Re: Standardizing new HTML features
To: TONYJ@scs.slac.stanford.edu
Date: Wed, 28 Apr 93 11:52:52 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Tony Johnson writes:

> Excellent! One area I would like to see clearly documented is what types of 
> nesting of tags is legal, I have not found it clearly documented in the 
> existing HTML documentation (of course maybe I didn't follow the right link).

> For example, which of the following are legal/supported/encouraged HTML??

> <a href=x>The <h1>Link</h1></a>
> <a href=x>The <b>link</b></a>    
> <b><i><e>Weird</e></i></b>     etc. etc. etc....

The current DTD specifies that anchor text is PCDATA. This perhaps too strong
as it rules out ANY tags occurring between <A> and the </A>. The same is true
for the tags: <EM>, <TT>, <STRONG>, <B>, <I>, <U>, <CODE>, <SAMP>, <KBD>,
<VAR>, <DFN> and <CITE>.

The DTD also gives limitations on which tags can occur within lists - namely
the preceding tags, together with <LI> and <P>, but *no* nested lists.

I have a feeling that most people find the SGML DTD rather hard to follow
in detail. Goldfarb's account of SGML almost seems to go out of its way
to make life difficult for the newcomer. Perhaps we need to supplement the
HTML DTD with a more accessible BNF style description.

> Of course one answer is that browsers should do their best with whatever they 
> get....but I think in the interest of portability (and of something that works 
> fine with ine browser working equally well with another one) it would be better 
> to document what things are required to be supported.

An easy to understand, yet precise description of the core HTML is needed.
I feel we would also benefit from some guidelines for dealing with bad HTML,
and pointers to experimental extensions.

> It would also be useful for browsers to have a -noextentensions flag
> (or some moral equivalent) under which they flag anything other than the
> strictly supported constructs to aid people in writing portable HTML.

My first browser did this - but I got fed up with all the error messages!
Perhaps the browser should just report the document as not conforming
to the core spec and leave it to a separate program to generate a full report.

Regards,

Dave Raggett

From timbl@www3.cern.ch  Wed Apr 28 12:55:29 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03130; Wed, 28 Apr 93 12:55:29 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27356; Wed, 28 Apr 1993 13:15:33 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06297; Wed, 28 Apr 93 13:11:25 +0100
Date: Wed, 28 Apr 93 13:11:25 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304281211.AA06297@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Postscript Behavior...
Cc: Mowgli C Assor <mowgli@magnus.acs.ohio-state.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>Date: Tue, 27 Apr 93 17:45:19 -0500
>From: marca@ncsa.uiuc.edu (Marc Andreessen)

>Mowgli C Assor writes:
>>   Um, I've been playing with various ways of getting postscript to  
display
>> via XMosaic (1.0). [...]
>>   However, when HTTP processes the file, it puts the line :
>> 

>> <PLAINTEXT>
>> 

>> in front of the rest of the document. Thus, when it gets back to  
Ghostview,
>> it chokes because <PLAINTEXT> is invalid PS. This may again get us  
to the
>> point of needing "type tags" for different types of files, but  
with the
>> coming various "multi-media" browsers, it seems to me to be a  
problem we
>> need to solve somehow (perhaps the URLs will help, but I don't  
think they
>> are the ultimate solution).
>> 

>>   I can just set up a filter for Ghostscript which removes the  
offending
>> line, but is there a better solution?

The problem here is twofold.  Firstly, the old HTTP version
only knows about two formats, plain text and HTML.  It distinguishes  
text from HTML by prefixing it with <PLAINTEXT>.  Now it is possible  
of course to get a postscript file returned as "plain text" and then
treat it as postscript.  Secondly, though, there is a bug in XMosaic
which causes it not to look at the <PLAINTEXT> let alone strip it  
off.  This is because (contrary to the protocol) it guesses from the
URL (which is specified as being opaque and meaningless to hte  
client) what sort of a format it is and pipes it directly to
ghostview.  I guess it doesn't strip off the PLAINTEXT because it
just wants to open up a pipe.

I have put a -DXMOSAIC-HACK patch into the W3 library to allow the
library to return data to clients which have not said they can handle  
it. before that they would just say "sorry" if you wanted a picture  
and could only handle plain text. I hadn't realised there was this  
extra problem with the <PLAINTEXT> with mosaic.  The trouble is, if  
the <PLAINTEXT> is left out, everything returned will be parsed
(by conforming HTTP0 clients) as HTML.

>The long-term solution is to move to HTTP2.  One short-term solution
>that you may want to explore is the NCSA public domain httpd, on
>ftp.ncsa.uiuc.edu in /Mosaic/ncsa_httpd, which will never do this to
>data files.

Beware of course that if you put up data using this server, there are  
lots of people out there with the line mode browers who, instead of  
getting the postscript in a usable form which they can print, will  
get it parsed as HTML!

Moving to full HTTP is better.  The line mode browser and various  
others include the version 2 cern library which includes the full  
HTTP (or at least, this part of it).  I hope it isn't too much in the  
long term for xmosaic.  All multimedia browers should use the full  
HTTP. Otherwise servers can only assume that they can only handle  
ASCII and HTML.

BTW Marc I have put in the porting mods from xmosaic's tcp.h
into tcp.h in the new library ...

This is all my fault for not getting libwww v2 out earlier in the  
xmosaic development schedule.

>Cheers,
>Marc

Tim BL


From dsr@hplb.hpl.hp.com  Wed Apr 28 13:35:47 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03748; Wed, 28 Apr 93 13:35:47 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04156; Wed, 28 Apr 1993 13:55:49 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 28 Apr 93 12:49:24 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA15496; Wed, 28 Apr 93 12:56:46 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304281156.AA15496@manuel.hpl.hp.com>
Subject: Re:  Standardizing new HTML features
To: weber@eitech.com
Date: Wed, 28 Apr 93 12:56:45 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Jay C. Weber writes:

> Three cheers to you for starting to pull together HTML enhancements!

Thanks!

> On the subject of query forms, maybe I just don't understand where
> Tim's old <QUERYFORM> ideas were heading, but we're working on an
> approach that I like better.  I hinted at it in a recent message
> regarding variable substitution, here's more detail.

> Define new tags for acquiring information from the user about an
> object retrieval.  A basic set of these tags is:

....

Your proposed tags are similar to the ones I suggested some time ago.
I ended up with two new tags: <input> for bools, free text, dates
integers and floats, and <select> for single and multi-valued list
selections which can be visualized as the browser chooses. Tim suggested
that rather than introducing a new tag, the <LI> tag should be used for
specifying list members. It would take an optional parameter to specify
selected choices. Other ideas concern the need for indicating that fields
are currently in error or can't be altered (grayed out).

> Either way, the key is that these tags set variables, named by VAR
> parameters, first to the default value and then to any input by the
> user.  These variables can then be substituted into URLs, thereby
> dynamically creating URLs based on how the user fills in a form.

We seem to have several ways of passing the field contents to the server:

    a)  as part of the URL following a "?"
    b)  as part of the URL using variable substitution
    c)  as part of the TEXTSEARCH method with HTRQ/V1.0
    d)  as part of a new 'method'

One suggestion that would fit well with existing practice is to specialise
the format of the search string. The BNF for URL's defines the search string
as zero or more alphanumeric or symbol chars, where the symbols belong
to the set: "$-_@!%^&*()."  You can then pass a list of field values using
the BNF:

    QUERY  ::=  FIELD [+QUERY]
    FIELD  ::=  name@value | name@(VALUES)
    VALUES ::=  value [&VALUE]

e.g. "name@value+name@(value&value)

The use of brackets for multiple values allows servers to continue to treat
the characters &, ^, ! for logical operators.

Any comments?

Dave

From dsr@hplb.hpl.hp.com  Wed Apr 28 14:29:47 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04449; Wed, 28 Apr 93 14:29:47 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12208; Wed, 28 Apr 1993 14:49:46 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 28 Apr 93 13:42:58 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA20117; Wed, 28 Apr 93 13:50:25 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304281250.AA20117@manuel.hpl.hp.com>
Subject: Re: Standardizing new HTML features... WE'RE INTERESTED!
To: raisch@ora.com
Date: Wed, 28 Apr 93 13:50:22 BST
Cc: www-talk@nxoc01.cern.ch, mcrae@lib.ucsf.edu, dale@ora.com
Mailer: Elm [revision: 66.36.1.1]

Rob Raisch writes:

> Dave,
>        O'Reilly and Associates is *extremely* interested in helping you with
> this effort.  We have a number of products in development which use HTML as
> their technology base.  We see the future development of HTML to be of great
> importance to our efforts.

Thank you, any help would be greatfully appreciated.

> I would suggest that lists and text flow are really exclusively
> rendering issues.  When I want to make a nested list, I may wish to write it

...

> But since there is no rendering information in HTML, and by definition there
> cannot be, how the terms appear on the screen is left up to the renderer.

The current HTML standard as defined by the DTD forbids nested lists. It is
therefore no surprise that the line mode browser doesn't support them. Other
browsers have made extensions to the standard. It is certainly true, that the
SGML DTD doesn't specify how such lists should be rendered, however, the
accompanying description should provide sufficient guidelines, that authors
will have an adequate idea of how each construct will appear. The current
document says for example:

   "The representation of a list is not defined here, but a bulleted list for
    unordered lists and a sequence of numbered paragraphs for an ordered list
    would be quite appropriate. Other possibilities for interactive displays
    include  embedded scrollable browse panels."

The current spec needs extension to define what kinds of nesting of list tags
are permitted together with some comments on rendering issues.

> A form or table cannot be specified in HTML without breaking one of
> HTML's first principles since forms and tables are descriptions of the
> appearance of information in relationship to other elements and not the
> description of information in terms of type and content.

I think you are mistaken here. Forms can be defined in terms of a collection
of fields with specified types and allowed values. My proposal does indeed
do this - leaving it up to the browser to decided how to render the form. One
may also want to make it possible for authors to pass hints to browsers, but
this is a separate issue. Tables too, can be specified without getting mixed
up in the details of rendering, although some layout hints are useful.

Regards,

Dave Raggett

From strata@apple.com  Thu Apr 29 08:05:21 1993
Return-Path: <strata@apple.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00180; Thu, 29 Apr 93 08:05:21 MET DST
Received: from apple.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04485; Thu, 29 Apr 1993 03:35:15 +0200
Received: by apple.com (5.61/7-Aug-1992-eef)
	id AA29770; Wed, 28 Apr 93 18:35:10 -0700
	for www-talk@nxoc01.cern.ch
Date: Wed, 28 Apr 1993 18:35:05 PDT
From: Strata Rose <strata@apple.com>
To: www-talk@nxoc01.cern.ch
Subject: help! need URL's & guidance for K-12 demo Friday
Message-Id: <CMM.0.88.736047305.strata@apple.com>

I have just grabbed the xmosaic binaries and report so far so good on a 
Sun 4/330 running 4.1.3.  Haven't tested sound stuff yet, will try it
on a Sparc2 tomorrow.  I have some questions, though....

First of all, where can I find some good multimedia stuff for a demo
of Mosaic to a local K-12 unified school district?  I just got dragged
into this at the last minute, you know how these things are.  There's
some good stuff in the Mosaic demo document, but I'm hoping to find
stuff for both teachers and kids elsewhere, preferably at least some
of it education related.  Are there URL's for good GIF sites,
especially anything Space related?  I would love JPL or shuttle
images, and sound files of astronaut stuff would go over really well.
We'll be doing this over a T1 link, and are assuming a T1 for this
particular site, so the more the merrier, and huge files are not a
problem!

A source for reading netnews via XMosaic would be good as well, I want
to test the news interface but got a "disallowed" message when I tried
to enter any of the groups in the netnews page.  I want to demo the
"kids" and "sci" groups in particular to these folks; if the news
interface is like the rest of mosaic, I feel pretty confident that
K-12 can handle it trivially.  This was in the demo doc, by the way--
the "Usenet" under the Documents menu doesn't even get me that far.

This brings me to another question-- a number of the most important
documents in the "Documents" menu seem to be inaccessible.  The
"Information by Subject" "Data Sources by Service" and some other
"meta-lists" are refusing to serve the documents.  Some sites may be
inaccesible, but (for instance) I am seeing plenty of other stuff from
info.cern.ch so why not these documents?

Has anyone prepared an initial document which has resources for K-12
teachers and students?  How about for small businesses or independent
researchers?  The Gopher interface is great, but you can't easily
distinguish between full-text documents, book reviews, and so on.  The
folks who were looking over my shoulder this afternoon were quite
disappointed when much of "the good stuff" turned out to be course
descriptions, not documents.

With respect to WAIS, I keep getting these WAIS pages that say <big
type> foo.bar.baz is a WAIS server for some topic, but where do I go
from there?  The "search keyword" is grayed out, even when the text
says "a WAIS server which supports keyword searches on such and so".
What might I be doing wrong?  Clicking in the "Search Keyword" area or
actual box sometimes gets me a text prompt but it just beeps when I
type!

Given the cynicism of much of today's youth, you can understand why I
want to overcome some of these issues before the demo Friday morning!
Any help is much appreciated!

One more question-- the school system in question may decide that it
wants these (and other) tools but doesn't want to maintain their own
Unix hosts, just to connect via Xterms or somesuch.  I have looked at
the Mosaic copyrights and it looks like it would be legal for one of
the commercial providers to put the binaries up or run a web server or
whatever for the school system.  But what if the commercial provider
wanted to let their regular customers use it too?  Would that still be
legit, as long as their customers are buying an account, not buying
Mosaic or any specific rights to use it?  I don't want to install this
for some provider and then find out that I'm helping to violate UIUC's
copyright!  Guidance on this would be appreciated....


Thanks for any help on any of these; probably best to send to me and
not the list.  I'll be happy to summarize the URL info if I get any,
and will certainly pass on any K-12 demo-style document I end up
generating.

 _Strata

M. Strata Rose
Unix & Network Consultant
strata@apple.com





From fine@cis.ohio-state.edu  Thu Apr 29 08:18:51 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00329; Thu, 29 Apr 93 08:18:51 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01867; Wed, 28 Apr 1993 23:21:26 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA29609; Wed, 28 Apr 93 17:21:20 -0400
Date: Wed, 28 Apr 93 17:21:20 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9304282121.AA29609@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: comp.infosystems.www
X-Mailer: Perl Mail System v1.2

The vote was successful for the creation of the group by a wide margin.
I tried to post the vote yesterday, but uunet seems to be really confused,
and it couldn't find the moderator of news.announce.newgroups, despite
all best efforts.  Uunet fixed that today.  (Then I sent this notice
out to www-talk, and it bounced.  Then / on our mail machine filled up
and I lost the response from the postmaster at uunet about the
mail to news.announce.newgroups.  I love mail).

The procedure at this point is that I "post" the results (they go
to the moderator of news.announce.newgroups, and he posts).  Five days
after they are posted, if there are no major complaints, the moderator
will send out a message to create the newsgroup.

If anybody happens to know why I can't send mail to uunet, that would
help things a bit.

	 tom

(Let's hope the undergrad I sacrificed was enough to appease the mail
 gods.)

From timbl@www3.cern.ch  Thu Apr 29 09:03:40 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00686; Thu, 29 Apr 93 09:03:40 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23708; Thu, 29 Apr 1993 09:24:07 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA07682; Thu, 29 Apr 93 09:20:01 +0100
Date: Thu, 29 Apr 93 09:20:01 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304290820.AA07682@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: info.cern.ch dropout yesterday
Reply-To: timbl@nxoc01.cern.ch



Tom,

I sympathize with your mail sufferings, and apologize for the
bounce from www-talk.   I also apologize for everyone trying to
do anything with www on info.cern.ch yesterday.  An auto NFS mounted
file system couldn't automount for no reason I could find and
then between 1am and 9am the darn thing fixed itself for no
resaon I could find either. Maybe the reason you can't mail uunet
is someone has an nfs mounted disk somewhere. :-}

Tim

From marca@wintermute.ncsa.uiuc.edu  Thu Apr 29 09:14:48 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00869; Thu, 29 Apr 93 09:14:48 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26260; Thu, 29 Apr 1993 09:35:13 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14444
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 29 Apr 93 02:35:09 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA15605; Thu, 29 Apr 93 02:37:26 -0500
Date: Thu, 29 Apr 93 02:37:26 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304290737.AA15605@wintermute.ncsa.uiuc.edu>
To: Strata Rose <strata@apple.com>
Cc: www-talk@nxoc01.cern.ch
Subject: help! need URL's & guidance for K-12 demo Friday
In-Reply-To: <CMM.0.88.736047305.strata@apple.com>
References: <CMM.0.88.736047305.strata@apple.com>
X-Md4-Signature: 9e3952e483412165b465b536208dda32

Strata Rose writes:
> I have just grabbed the xmosaic binaries and report so far so good
> on a Sun 4/330 running 4.1.3.  Haven't tested sound stuff yet, will
> try it on a Sparc2 tomorrow.  I have some questions, though....
> 
> First of all, where can I find some good multimedia stuff for a demo
> of Mosaic to a local K-12 unified school district?  I just got dragged
> into this at the last minute, you know how these things are.  There's
> some good stuff in the Mosaic demo document, but I'm hoping to find
> stuff for both teachers and kids elsewhere, preferably at least some
> of it education related.  Are there URL's for good GIF sites,
> especially anything Space related?  I would love JPL or shuttle
> images, and sound files of astronaut stuff would go over really well.
> We'll be doing this over a T1 link, and are assuming a T1 for this
> particular site, so the more the merrier, and huge files are not a
> problem!

Hopefully others can help with more general recommendations, but I
suggest you take a look at.....
        
        http://www.ncsa.uiuc.edu/evl/Welcome.html

.....although there are some SGI-only images and animations in there,
it's got a lot of good, impressive, content-filled (I can say that
since I didn't create it) multi/hypermedia stuff that can be viewed on
any color platform.

> A source for reading netnews via XMosaic would be good as well, I
> want to test the news interface but got a "disallowed" message when
> I tried to enter any of the groups in the netnews page.  I want to
> demo the "kids" and "sci" groups in particular to these folks; if
> the news interface is like the rest of mosaic, I feel pretty
> confident that K-12 can handle it trivially.  This was in the demo
> doc, by the way-- the "Usenet" under the Documents menu doesn't even
> get me that far.

If you have a valid NNTP/netnews server available to you, set
environment variable NNTPSERVER to it before starting Mosaic and then
you can access any group with URL's of form......

        news:alt.hypertext

......or whatever.

> This brings me to another question-- a number of the most important
> documents in the "Documents" menu seem to be inaccessible.  The
> "Information by Subject" "Data Sources by Service" and some other
> "meta-lists" are refusing to serve the documents.  Some sites may be
> inaccesible, but (for instance) I am seeing plenty of other stuff from
> info.cern.ch so why not these documents?

CERN (the source of those documents) had machine problems today.  I
see they're back up now (2:30am Central time).

> Has anyone prepared an initial document which has resources for K-12
> teachers and students?  How about for small businesses or independent
> researchers?  The Gopher interface is great, but you can't easily
> distinguish between full-text documents, book reviews, and so on.  The
> folks who were looking over my shoulder this afternoon were quite
> disappointed when much of "the good stuff" turned out to be course
> descriptions, not documents.

Others can maybe help there -- the global answer is that the Internet
isn't yet a library in any reasonable sense of the word is because
nobody's paying anyone to make it a library.  Hopefully through the
use of technology like WWW/WAIS/Gopher etc. this will one day happen.
But there are pockets of definite non-technical content here and
there.

> With respect to WAIS, I keep getting these WAIS pages that say <big
> type> foo.bar.baz is a WAIS server for some topic, but where do I go
> from there?  The "search keyword" is grayed out, even when the text
> says "a WAIS server which supports keyword searches on such and so".
> What might I be doing wrong?  Clicking in the "Search Keyword" area or
> actual box sometimes gets me a text prompt but it just beeps when I
> type!

Suggest you contact us directly (mosaic-x@ncsa.uiuc.edu).  Sounds like
a strange problem.

> Given the cynicism of much of today's youth, you can understand why I
> want to overcome some of these issues before the demo Friday morning!
> Any help is much appreciated!
> 
> One more question-- the school system in question may decide that it
> wants these (and other) tools but doesn't want to maintain their own
> Unix hosts, just to connect via Xterms or somesuch.  I have looked at
> the Mosaic copyrights and it looks like it would be legal for one of
> the commercial providers to put the binaries up or run a web server or
> whatever for the school system.  But what if the commercial provider
> wanted to let their regular customers use it too?  Would that still be
> legit, as long as their customers are buying an account, not buying
> Mosaic or any specific rights to use it?  I don't want to install this
> for some provider and then find out that I'm helping to violate UIUC's
> copyright!  Guidance on this would be appreciated....

Suggest you contact us directly wrt this too -- the threshold from our
side is that if a commercial concern is distributing and/or modifying
Mosaic in a commercial context, as part of commercial activities, then
it's probably be a good idea to come talk to us.  Everything else is
free (including internal company use, btw).

> Thanks for any help on any of these; probably best to send to me and
> not the list.  I'll be happy to summarize the URL info if I get any,
> and will certainly pass on any K-12 demo-style document I end up
> generating.

Great!

>  _Strata
> 
> M. Strata Rose
> Unix & Network Consultant
> strata@apple.com

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Thu Apr 29 13:59:05 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03855; Thu, 29 Apr 93 13:59:05 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20757; Thu, 29 Apr 1993 14:19:32 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA08424; Thu, 29 Apr 93 14:15:25 +0100
Date: Thu, 29 Apr 93 14:15:25 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304291315.AA08424@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: HMML -- More character entities?
Cc: TOM.R2D2@law.mail.cornell.edu
Reply-To: timbl@nxoc01.cern.ch



Tom Bruce broght up the question of allowing
entities for more than the ISOLatin1 set.
Anyone care to take on defining a reasonable set?
(Like not all unicode?)

We would need
	
	names from some standard,
	
	suggested translations into latin 1 equivalents
	for those without them?)

Tom's initial need was for section sign, pilcrow (paragraph mark),
mu and a few other Greek characters in common use outside Greek,
and the registered and copyright signs.

I am usingthe term "HMML" to refer to the next DTD following on from
HTML, to distinguidsh from HTML which I think should stick at latin1
for the sake of stability.

Tim

From timbl@www3.cern.ch  Thu Apr 29 14:01:20 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03890; Thu, 29 Apr 93 14:01:20 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22171; Thu, 29 Apr 1993 14:21:46 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA08430; Thu, 29 Apr 93 14:17:27 +0100
Date: Thu, 29 Apr 93 14:17:27 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304291317.AA08430@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Margaret.Isaacs@newcastle.ac.uk, Strata Rose <strata@apple.com>
Subject: W3 examples for K12 and training materials
Cc: www-talk@nxoc01.cern.ch, Jill.Foster@newcastle.ac.uk
Reply-To: timbl@nxoc01.cern.ch

This is a merging of a few answers to two questions.
Any more good pointers please send to the list.

Strata Rose <strata@apple.com> wrote:

> ...here can I find some good multimedia stuff for a demo
> of Mosaic to a local K-12 unified school district? 


Hypertext of the consitution of the US? link from
http://fatty.law.cornell.edu.:80/usr2/wwwtext/lii.table.html
find it from subjects->law.  US students are all supposed to thrive
on this, others may not be so excited!

The vatican exhibit is just incredible, and you have to take a tour  
there if you have time. URL is ftp://seq1.loc.gov/pub/vatican.exhibit
or find it under Subjects->Literature and Art.  Unfortunately there  
is no guiding hypertext... so look under exhibits and then under  
(say) music.  Bring up the Music.txt in one window, and on a cloned  
window keep the list of pictures hich you can bring up as you read  
through the text. These are some beautiful pictures, and a serious  
commentary.

[A volunteer to hypertext this and show them the result? These guys
need a few pointers in their text and a fast http server. But if
you don't mind directory listsings, its great as it is]

How about the CIA fact book as an atlas?  Find the index under  
subjects: geography. Look for a country, then try "world". Sorry, no  
maps.

Marc replied:

Hopefully others can help with more general recommendations, but I
suggest you take a look at.....

        http://www.ncsa.uiuc.edu/evl/Welcome.html

.....although there are some SGI-only images and animations in there,
it's got a lot of good, impressive, content-filled (I can say that
since I didn't create it) multi/hypermedia stuff that can be viewed  
on any color platform.



Margaret Isaacs wrote:

> I am preparing some exercises for a hands-on workshop on networked
> information retrieval. We will have VT100 interface only.  I am  
looking for
> a good example of the capability of WWW but have not been very  
successful
> in finding it. What I had in mind was following a hypertext chain  
of links
> through several actual documents - say from an item cited in a  
document to
> the document itself, and maybe another step or two on.


It is really difficult to know which line you should take as a demo,
there are so many things to show.  With a vt100 you probably want to  
use Lynx.  Pity you can't use the fancy stuff above!

One example:

follow

Subjects -> computing -> unix manuals -> sun manuals -> keyword  
search, find "time", -> time.1v

Now, point out:

1.	We have used a mixture of searchs and jumps to get where
	we wanted

2.	We now have some very useful links offered, including
	those back to the top of the manu pages for sun, and
	also a link to the equivalent page in the HP, pyramid, and
	ultrix manuals (useful for comparison!), and to other
	man pages called "time" in different sections of the sun
	manual.
	
3.	These links were all generated automatically by a program:
	noone had to write them.
	


From timbl@www3.cern.ch  Thu Apr 29 14:06:48 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03952; Thu, 29 Apr 93 14:06:48 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22709; Thu, 29 Apr 1993 14:27:15 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA08443; Thu, 29 Apr 93 14:23:09 +0100
Date: Thu, 29 Apr 93 14:23:09 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9304291323.AA08443@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Re: Postscript Behavior...
Reply-To: timbl@nxoc01.cern.ch



What's the problem?

Take a test case:

http://info.cern.ch/hypertext/WWW/Paper/www-server-guide.ps

This is a postscript document. I can read it with XMosaic (0.9), I  
can read it using:
WWW LineMode Browser version 2.04-beta (WWW Library 2.04)
on a next.

The CERN server is now at 2.04, but as far as I know the
document has been has been readable for some time.
There was a fix (the -DXMOSAIC_HACK library compilation option
mentioned in previous messages) which was introduced into
the library recently, but this does seem to solve the problem.
We will have to keep this -DXMOSAIC_HACK in until xmosaic
goes to v2.

If you have a document you can't pick up, then what it its URL?
Could be a server update would help.

Tim




From cardeci@lysator.liu.se  Thu Apr 29 14:52:14 1993
Return-Path: <cardeci@lysator.liu.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04726; Thu, 29 Apr 93 14:52:14 MET DST
Received: from lysator.liu.se by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01958; Thu, 29 Apr 1993 15:12:39 +0200
Received: from tistel.lysator.liu.se (130.236.254.12) by lysator.liu.se (ALPHA-6.36/6.16) id AA21238; Thu, 29 Apr 1993 15:12:35 +0200 
Received: by tistel.lysator.liu.se 
          (4.1/1.34/Lysator-3.1) id AA00478; Thu, 29 Apr 93 15:12:33 +0200
          (unknown)
Date: Thu, 29 Apr 93 15:12:33 +0200
From: cardeci@lysator.liu.se
Message-Id: <9304291312.AA00478@tistel.lysator.liu.se>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Tim Berners-Lee's message of Thu, 29 Apr 93 09:20:01 +0100 <9304290820.AA07682@www3.cern.ch>
Subject: info.cern.ch dropout yesterday

Don't we all love NFS... :)

From sanders@bsdi.com  Thu Apr 29 18:21:14 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08899; Thu, 29 Apr 93 18:21:14 MET DST
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16588; Thu, 29 Apr 1993 18:41:34 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA29221; Thu, 29 Apr 93 11:41:29 -0500
Message-Id: <9304291641.AA29221@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Standardizing new HTML features 
In-Reply-To: "(Arnold Bloemer)"'s message of 28 Apr 93 07:40:00.
Organization: Berkeley Software Design, Inc.
Date: Thu, 29 Apr 1993 11:41:29 -0500
From: Tony Sanders <sanders@bsdi.com>

> From "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
> > From marca@wintermute.ncsa.uiuc.edu Wed Apr 28 01:17:16 1993
> > ...
> > Also, I'm not certain that any multimedia data other than images needs
> > to be specifiable as inlined/included.  Things like audio and MPEG can
> > simply be pointed at from an anchor (as Mosaic does) and forked to
> > external viewers or processed internally, whichever the browser
> > prefers -- and with inlined images the whole thing will be iconic
> > anyway.
> 
> But it is much more impressive and intuitive, when you click on an
> image and it starts moving in place. Paradise Software Inc. have a demo
> which shows a hypermedia newspaper. In that demo there are two images 
> which serve as anchors to two movies. When you start the movies they 
> will run at the location of the images. I showed the demo to a couple 
> of people and all were very impressed.
There are two parts to this, auto-inlining and inlining on selection.

There is nothing to prevent browers from inlining on selection right now,
though it would be nice if you could pass a window id to xv and not have
to build in all that code.  Having browsers and external viewers cooperate
should be an easy project.  Any volunteers?

I think in 10 years auto-inlining anchors (for other than iconic purposes,
which is what <A><IMG...></A> really does) will be considered the GOTO of
hypertext.  Good document design should minimize them, but they are handy
when you are in deep shaving cream.

see also: http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html

It talks about REL=Embed which is pretty interesting for doing outlines.

> > I would certainly love to hear discussion about what to do with text
> > flow -- it's starting to become a popular request.
> I would like this feature also very much.
Wouldn't adding a <IMG ALIGN="flow"> hint do the job?  I haven't researched
all the different ways people like to flow text around images but I think
this would solve 80% of the problem (which is that people don't want all
that empty space).  I don't see anything preventing browsers from flowing
text right now.

--sanders

From murphy@dccs.upenn.edu  Thu Apr 29 20:40:36 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12048; Thu, 29 Apr 93 20:40:36 MET DST
Received: from NOC2.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10295; Thu, 29 Apr 1993 21:01:01 +0200
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA17754; Thu, 29 Apr 93 15:00:50 -0400
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA20002; Thu, 29 Apr 93 15:00:49 -0400
Posted-Date: Thu, 29 Apr 93 15:00:48 -0400
Message-Id: <9304291900.AA20002@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch
Subject: Anyone using xmosaic with MacX?
Reply-To: Linda Murphy <murphy@dccs.upenn.edu>
Cc: smithj@isc.upenn.edu
Date: Thu, 29 Apr 93 15:00:48 -0400
From: murphy@dccs.upenn.edu
X-Mts: smtp


Is anyone using MacX (an Xterminal emulator for macintoshes) as their
X-server for xmosaic?  If so, which xmosaic binary (sun, dec, alpha,
...)  are you using, and does it work reasonably well? 

Is this a reasonable thing to be doing or is it completely nuts :-) ?

--lam

From janssen@parc.xerox.com  Thu Apr 29 21:00:53 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12459; Thu, 29 Apr 93 21:00:53 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12478; Thu, 29 Apr 1993 21:18:38 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11634>; Thu, 29 Apr 1993 12:17:43 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 29 Apr 1993 12:17:35 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 29 Apr 1993 12:17:24 -0700 (PDT)
Message-Id: <Ufs2b4IB0KGWE3jHB8@holmes.parc.xerox.com>
Date: 	Thu, 29 Apr 1993 12:17:24 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, Tony Sanders <sanders@bsdi.com>
Subject: Re: Standardizing new HTML features
In-Reply-To: <9304291641.AA29221@austin.BSDI.COM>
References: <9304291641.AA29221@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 29-Apr-93 Re: Standardizing new HTML ..
Tony Sanders@bsdi.com (2146)

> though it would be nice if you could pass a window id to xv and not have
> to build in all that code.

I have a modified version of xv that supports this.  I'll clean it up
and send it out.

Bill

From janssen@parc.xerox.com  Thu Apr 29 23:46:30 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15895; Thu, 29 Apr 93 23:46:30 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09203; Fri, 30 Apr 1993 00:06:57 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11689>; Thu, 29 Apr 1993 15:06:45 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 29 Apr 1993 15:06:43 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 29 Apr 1993 15:06:41 -0700 (PDT)
Message-Id: <4fs55lMB0KGWE3jHhw@holmes.parc.xerox.com>
Date: 	Thu, 29 Apr 1993 15:06:41 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, Tony Sanders <sanders@bsdi.com>
Subject: Re: Standardizing new HTML features
In-Reply-To: <9304291641.AA29221@austin.BSDI.COM>
References: <9304291641.AA29221@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 29-Apr-93 Re: Standardizing new HTML ..
Tony Sanders@bsdi.com (2146)

> There is nothing to prevent browers from inlining on selection right now,
> though it would be nice if you could pass a window id to xv and not have
> to build in all that code.  Having browsers and external viewers cooperate
> should be an easy project.  Any volunteers?

Building viewers so that they can also operate on some pre-existing
window, instead of just creating their own, is an excellent idea.  I'm
always surprised when otherwise-wonderful viewers, such as Ghostscript
or xv, don't do this  from the start.  Probably just doesn't occur to
their authors.  Also, it seems tricky to do with most (all that I know
of) Xt-based toolkits.

Bill

From sanders@bsdi.com  Fri Apr 30 00:01:41 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16161; Fri, 30 Apr 93 00:01:41 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11243; Fri, 30 Apr 1993 00:22:08 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA00181; Thu, 29 Apr 93 17:22:06 -0500
Message-Id: <9304292222.AA00181@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Standardizing new HTML features 
In-Reply-To: Your message of Thu, 29 Apr 93 15:06:41 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 29 Apr 1993 17:22:05 -0500
From: Tony Sanders <sanders@bsdi.com>

> Building viewers so that they can also operate on some pre-existing
> window, instead of just creating their own, is an excellent idea.  I'm
> always surprised when otherwise-wonderful viewers, such as Ghostscript
> or xv, don't do this  from the start.  Probably just doesn't occur to
> their authors.  Also, it seems tricky to do with most (all that I know
> of) Xt-based toolkits.
Ghostscript 2.5.2 does this.
    GHOSTVIEW="__window_id__"
    DISPLAY="whatever"
    export GHOSTVIEW DISPLAY

Ghostview 1.4.1 uses this feature.
Now we just have to fix xloadimage, mpeg_play, (and you said you had a
fixed xv).

--sanders@bsdi.com

From janssen@parc.xerox.com  Fri Apr 30 00:36:55 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16714; Fri, 30 Apr 93 00:36:55 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19150; Fri, 30 Apr 1993 00:57:22 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11647>; Thu, 29 Apr 1993 15:57:09 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 29 Apr 1993 15:57:03 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 29 Apr 1993 15:56:49 -0700 (PDT)
Message-Id: <wfs5olAB0KGWQ3jQJU@holmes.parc.xerox.com>
Date: 	Thu, 29 Apr 1993 15:56:49 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, sanders@bsdi.com
Subject: Re: Standardizing new HTML features
In-Reply-To: <9304292222.AA00181@austin.BSDI.COM>
References: <9304292222.AA00181@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 29-Apr-93 Re: Standardizing new HTML ..
Tony Sanders@bsdi.com (636)

> Ghostscript 2.5.2 does this.
>     GHOSTVIEW="__window_id__"
>     DISPLAY="whatever"
>     export GHOSTVIEW DISPLAY

Clearly Ghostview talks to Ghostscript in some fashion.  Is the actual
communication protocol between the two documented in some fashion other
than the source code?

Bill


From sanders@bsdi.com  Fri Apr 30 00:47:18 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16834; Fri, 30 Apr 93 00:47:18 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20868; Fri, 30 Apr 1993 01:07:45 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA00428; Thu, 29 Apr 93 18:07:42 -0500
Message-Id: <9304292307.AA00428@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Standardizing new HTML features 
In-Reply-To: Your message of Thu, 29 Apr 93 15:56:49 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 29 Apr 1993 18:07:42 -0500
From: Tony Sanders <sanders@bsdi.com>

> > Ghostscript 2.5.2 does this.
> >     GHOSTVIEW="__window_id__"
> >     DISPLAY="whatever"
> >     export GHOSTVIEW DISPLAY
> 
> Clearly Ghostview talks to Ghostscript in some fashion.  Is the actual
> communication protocol between the two documented in some fashion other
> than the source code?
It opens a pipe and talks postscript to it I'm sure.

--sanders

From CSP1DWD@mvs.oac.ucla.edu  Fri Apr 30 01:21:36 1993
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17260; Fri, 30 Apr 93 01:21:36 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26338; Fri, 30 Apr 1993 01:42:05 +0200
Message-Id: <9304292342.AA26338@dxmint.cern.ch>
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 1013; Fri, 30 Apr 93 01:41:46 SET
Received: from UCLAMVS.BITNET (NJE origin MAILER@UCLAMVS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 5820; Fri, 30 Apr 1993 01:41:46 +0200
Date:    Thu, 29 Apr 93 16:42 PDT
To: Linda Murphy <murphy@dccs.upenn.edu>
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: Re: Anyone using xmosaic with MacX?
Cc: www-talk@nxoc01.cern.ch

>  Is anyone using MacX (an Xterminal emulator for macintoshes) as thei
>  X-server for xmosaic?  If so, which xmosaic binary (sun, dec, alpha,
>  ...)  are you using, and does it work reasonably well?

Yes, it works fine... I believe MacX is an X11R4 release of X and thus
not all fonts requested by Xmosaic are available (about 4 fonts in
total I think)... any Xmosaic client (sun, dec, etc) ought to work.
I depend on the IBM xmosaic client and it works fine... opening
telnet sessions does not work, "aixterm -v" is used for that and
it fails when it can't get the "vtsingle" font.

-- Denis


From janssen@parc.xerox.com  Fri Apr 30 01:57:25 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17715; Fri, 30 Apr 93 01:57:25 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00237; Fri, 30 Apr 1993 02:17:52 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11717>; Thu, 29 Apr 1993 17:17:17 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 29 Apr 1993 17:17:15 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 29 Apr 1993 17:17:08 -0700 (PDT)
Message-Id: <Afs704MB0KGW83jGQ_@holmes.parc.xerox.com>
Date: 	Thu, 29 Apr 1993 17:17:08 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, sanders@bsdi.com
Subject: Re: Standardizing new HTML features
In-Reply-To: <9304292307.AA00428@austin.BSDI.COM>
References: <9304292307.AA00428@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 29-Apr-93 Re: Standardizing new HTML ..
Tony Sanders@bsdi.com (366)

> > Clearly Ghostview talks to Ghostscript in some fashion.  Is the actual
> > communication protocol between the two documented in some fashion other
> > than the source code?
> It opens a pipe and talks postscript to it I'm sure.

Ah, I had hoped that you might actually know.  There is an additional
protocol using X Client Events that runs between ghostscript and
ghostview.  Also, the environment variable protocol you described seems
to be more complex; it's more like

    setenv GHOSTVIEW "<window-id-1>  <window-id-2>"

where <window-id-1> is the window on which ghostscript is supposed to
render, and <window-id-2> is the window to which ghostscript sends
events, in order to run this out-of-band additional protocol.  I believe
that

    setenv GHOSTVIEW "<window-id>"

will also work in some fashion, though I don't know to what extent the
protocol will be crippled.

Bill



From tom@begbick.law.cornell.edu  Fri Apr 30 11:24:47 1993
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22418; Fri, 30 Apr 93 11:24:47 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21091; Fri, 30 Apr 1993 11:45:17 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160571(1)>; Fri, 30 Apr 1993 05:45:09 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA09321; Fri, 30 Apr 93 05:36:40 EDT
Date: Fri, 30 Apr 1993 05:36:40 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9304300936.AA09321@begbick.law.cornell.edu.law.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Interapplication communication

Folks:

The talk about Ghostscript prompts me to raise a question... MS
Windows incorporates protocols for local communication between
applications (two of 'em, in fact).  They seem vaguely similar in
purpose to the protocols mentioned by the folks discussing
Ghostscript...

I would very much like to build some recognition of these into anchors, so that local apps
could be fired up/communicated with by some means beyond recognition
of file extensions (I have a particular purpose in mind which involves
feeding queries to a proprietary database client, but there are a few
billion more uses for such a thing).  Question is, what's the best way
to do the URL? I could invent something local to the Windows
environment, but it would seem that as there are analogues for other
platforms something general would be handy.  Or have I missed the
point, with this problem long since resolved under some other scheme?

Regards,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From dsr@hplb.hpl.hp.com  Fri Apr 30 17:20:20 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26956; Fri, 30 Apr 93 17:20:20 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12148; Fri, 30 Apr 1993 17:40:48 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 30 Apr 93 16:34:15 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA22173; Fri, 30 Apr 93 16:41:45 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9304301541.AA22173@manuel.hpl.hp.com>
Subject: Description Lists
To: marca@ncsa.uiuc.edu
Date: Fri, 30 Apr 93 16:41:43 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Marc,

In "http://www.ncsa.uiuc.edu:80/SDG/Software/MacSoftDesc.html" you have
used an unusual variant of description lists:

    DL>
    <DT> <I> Version: </I> 1.0
    <DT> <I> System requirements: </I>
    </DL>

There are <DT> tags without any corresponding <DD> tags. Currently, the
HTML spec seems to require each <DT> to be paired with a <DD>. Furthermore
there must be at least one <DT> in the list.

Now are you suggesting that we relax this requirement?
If so what should be permitted with in <DL> ... </DL>?

Best wishes,

Dave Raggett

From marca@wintermute.ncsa.uiuc.edu  Fri Apr 30 18:52:23 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28784; Fri, 30 Apr 93 18:52:23 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00482; Fri, 30 Apr 1993 19:12:52 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05542
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 30 Apr 93 12:12:50 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA20219; Fri, 30 Apr 93 12:15:10 -0500
Date: Fri, 30 Apr 93 12:15:10 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9304301715.AA20219@wintermute.ncsa.uiuc.edu>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: marca@ncsa.uiuc.edu, www-talk@nxoc01.cern.ch
Subject: Description Lists
In-Reply-To: <9304301541.AA22173@manuel.hpl.hp.com>
References: <9304301541.AA22173@manuel.hpl.hp.com>

Dave_Raggett writes:
> Marc,
> 
> In "http://www.ncsa.uiuc.edu:80/SDG/Software/MacSoftDesc.html" you have
> used an unusual variant of description lists:
> 
>     DL>
>     <DT> <I> Version: </I> 1.0
>     <DT> <I> System requirements: </I>
>     </DL>
> 
> There are <DT> tags without any corresponding <DD> tags. Currently, the
> HTML spec seems to require each <DT> to be paired with a <DD>. Furthermore
> there must be at least one <DT> in the list.
> 
> Now are you suggesting that we relax this requirement?
> If so what should be permitted with in <DL> ... </DL>?

Aaaaagh!  I didn't write that document.  Mosaic has been trained to be
very liberal about what goes into a DL just because various documents
already on the net were doing very strange things (like above) and now
I see that our own Publications group is doing them -- sigh.  But I
didn't do it myself.

Cheers,
Marc


From TONYJ@scs.slac.stanford.edu  Fri Apr 30 19:07:34 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28995; Fri, 30 Apr 93 19:07:34 MET DST
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02242; Fri, 30 Apr 1993 19:28:03 +0200
Date: Fri, 30 Apr 1993 10:27 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: Description Lists (and other unusual variations)
To: dsr@hplb.hpl.hp.com, marca@ncsa.uiuc.edu
Cc: www-talk@nxoc01.cern.ch
Message-Id: <CA8A0ACDE8E0012E@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"dsr@hplb.hpl.hp.com" , in%"marca@ncsa.uiuc.edu"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

>In "http://www.ncsa.uiuc.edu:80/SDG/Software/MacSoftDesc.html" you have
>used an unusual variant of description lists:

>    <DL>
>    <DT> <I> Version: </I> 1.0
>    <DT> <I> System requirements: </I>
>    </DL>

>There are <DT> tags without any corresponding <DD> tags. Currently, the
>HTML spec seems to require each <DT> to be paired with a <DD>. 
>Furthermore there must be at least one <DT> in the list.

Speaking of unusual variations....in 

http://www.ncsa.uiuc.edu/evl/cave/cave.html

I find....

   <ul>
   <li><h2> Stuff </h2>
   <li><h2> More Stuff </h2>
   </li>

elsewhere I have seen the complimentary

   <h1>This is <ul><li>some<li>stuff</ul></h1>

Clearly someone has found such constructs useful, but they seem to be against my 
feelings for what <h1>/<h2> mean, and are unlikely to produce the desired 
results on most existing browsers. 

Do people feel that constructs such as this should be supported? 

Presumably the DTD says something explicit about whether the above is legal HTML 
or not, but (hoepfully) most off the people producing HTML will not (want) to 
read the DTD, so I feel that (in addition to the DTD) a document that describes 
in a more informal way which combination of tags is likely to be portable across 
browsers is badly needed.

Tony

From jay@bogle.eitech.com  Fri Apr 30 22:41:44 1993
Return-Path: <jay@bogle.eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03566; Fri, 30 Apr 93 22:41:44 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01810; Fri, 30 Apr 1993 23:02:12 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA23409; Fri, 30 Apr 93 16:02:24 -0500
Received: from bogle.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA16871; Fri, 30 Apr 93 13:57:28 PDT
Message-Id: <9304302057.AA16871@eitech.com>
To: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Interapplication communication 
In-Reply-To: Your message of "Fri, 30 Apr 1993 05:36:40 EDT."
             <9304300936.AA09321@begbick.law.cornell.edu.law.cornell.edu> 
Date: Fri, 30 Apr 1993 13:57:23 -0700
From: Jay Glicksman <jay@bogle.eitech.com>

> Thomas R. Bruce writes:
>... so that local apps
>could be fired up/communicated with by some means beyond recognition
>of file extensions (I have a particular purpose in mind which involves

I think this is another place where variables are needed (cf. Jay
Weber's message of a few days ago). Then one could have URLs of the
form:

http://site:port/command?arg1+$var1+arg2+$var2

	Jay Glicksman
	jay@eitech.com

From marca@wintermute.ncsa.uiuc.edu  Sat May  1 04:51:31 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06750; Sat, 1 May 93 04:51:31 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14444; Sat, 1 May 1993 05:12:02 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18620
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 30 Apr 93 22:11:56 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:mason@bert.eecs.uic.edu id AA22008; Fri, 30 Apr 93 22:14:16 -0500
Date: Fri, 30 Apr 93 22:14:16 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305010314.AA22008@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: hardin@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu, mason@bert.eecs.uic.edu
Subject: 'xv 3.0' is out....
X-Md4-Signature: 10134c7c171c20844914e077bc95d7e0

....and it handles SGI RGB-format images, of which there are many in
http://www.ncsa.uiuc.edu/evl.  So you may want to set your Mosaic
rgbViewerCommand resource to point to the new 'xv' before browsing
through that document hierarchy....

Cheers,
Marc


From marca@wintermute.ncsa.uiuc.edu  Sun May  2 01:09:12 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12689; Sun, 2 May 93 01:09:12 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13909; Sun, 2 May 1993 01:29:44 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26263
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 1 May 93 18:29:43 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA25289; Sat, 1 May 93 18:32:06 -0500
Date: Sat, 1 May 93 18:32:06 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305012332.AA25289@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: nntp
X-Md4-Signature: dd1280ac784fd6dee485c3234b889dc9

Tim, my apologies if you've fixed this in libwww v2 already, but...

It seems that the reason Mosaic will present some of you with lists of
article headers of news groups just fine, but then refuse to read any
articles ("430 No article by message-id
<1993Feb3.134631.2976@ncsa.uiuc.edu>, sorry."), is that some nntp
servers out there are just plain broken.

How, you ask?  RFC 977 directs news servers to return articles
identified by article ID when sent a command of form:

        ARTICLE <1993Feb3.134631.2976@ncsa.uiuc.edu>

....and also when sent a command of form:

        ARTICLE 335

....where 335 is the article number.  Right?

Well, some servers only allow the latter method.  This seems strange.
Does anyone know what I'm missing here?

Thanks,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From joe@athena.mit.edu  Sun May  2 04:48:46 1993
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14111; Sun, 2 May 93 04:48:46 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10085; Sun, 2 May 1993 05:09:18 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA03423; Sat, 1 May 93 23:06:45 EDT
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA23084; Sat, 1 May 93 23:06:44 -0400
Date: Sat, 1 May 93 23:06:44 -0400
Message-Id: <9305020306.AA23084@theodore-sturgeon>
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch,
        tk-www@athena.mit.edu
Cc: tcl-archive@harbor.ecn.purdue.edu
Subject: Announcing tkWWW 0.7, the first WYWSIWYG X11 HTML editor


tkWWW Version 0.7 alpha (joe@athena.mit.edu)
--------------------------------------------
WHAT IS THIS?

-------------
World Wide Web (WWW) is a hypertext project which seeks to build a
world wide network of hypertext links.  There are several different
browsers for this system including a simple tty interface.  For a 
demo of the terminal browsers for WWW, telnet to the following sites:

 telnet info.cern.ch or telnet 128.141.201.74 (SWISS)
 telnet eies2.njit.edu or telnet 128.235.1.43 (USA [NJ])
 telnet vms.huji.ac.il or telnet 128.139.4.3  (ISRAEL)
 telnet info.funet.fi or telnet 128.214.6.100 (FINLAND)

 and login as "www"

Tk is an interpreted toolkit which allows one to build X11 applications
quickly and easily.

tkWWW is a Tk interface to (WWW).

it is very easy to make modifications and extensions to the system.
tkWWW is the first X11 browser with the ability to edit HTML!!!!!

What has changed since 0.6?
---------------------------
Rough WYWSIWYG editor!!!!!!!!!!! 
   (with help from Nathan Torkington <Nathan.Torkington@vuw.ac.nz>)
Bug fixes courtesy of Jon Hurley (jhn@biosym.com)
Uses www library version 2.0
Can now grab images over gopher
Added ability to start in iconic mode

Where is this?
--------------
tkWWW 0.7 can be anon ftp'ed from
   export.lcs.mit.edu:/contrib/tkWWW-0.7.tar.Z
   harbor.ecn.purdue.edu:/tcl/extensions/tkWWW-0.7.tar.Z
   info.cern.ch:/pub/WWW/src/tkWWW-0.7.tar.Z

Mailing list
------------
There is a mailing list devoted to discussions about tkWWW at 
 
   tk-www@athena.mit.edu

To get on this list, send e-mail to

   tk-www-request@athena.mit.edu

To report bugs, send e-mail to
  
   tk-www-bugs@athena.mit.edu



From marca@wintermute.ncsa.uiuc.edu  Sun May  2 06:58:51 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14601; Sun, 2 May 93 06:58:51 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24843; Sun, 2 May 1993 07:19:23 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA17408
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 2 May 93 00:19:21 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA25951; Sun, 2 May 93 00:21:43 -0500
Date: Sun, 2 May 93 00:21:43 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305020521.AA25951@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: NCSA WAIS gateway & Mosaic WAIS interface document
X-Md4-Signature: c6f7747a2f1e46b588ec679073ac5b17

The new Mosaic "WAIS interface" document is.....

http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Interfaces/wais/wais-interface.html

This points to the TMC and CNIDR directories of servers through the
NCSA gateway (www.ncsa.uiuc.edu:8001), as well as some other
interesting things, and will be the document corresponding to the menu
entry Documents->WAIS Interface in Mosaic 1.1.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From fishe@speedy.acns.nwu.edu  Sun May  2 22:29:29 1993
Return-Path: <fishe@speedy.acns.nwu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18907; Sun, 2 May 93 22:29:29 MET DST
Received: from speedy.acns.nwu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23045; Sun, 2 May 1993 22:50:02 +0200
Received: by speedy.acns.nwu.edu (NX5.67c/NX3.0M)
	id AA00724; Sun, 2 May 93 15:45:37 -0500
Date: Sun, 2 May 93 15:45:37 -0500
From: Carwil James <fishe@speedy.acns.nwu.edu>
Message-Id: <9305022045.AA00724@speedy.acns.nwu.edu>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: HP Apollo Client Software

Our RS/6000 workstations were just replaced by HP Apollo 715's, so  
XMosaic no longer works. Is there any client software which works on  
the Apollos (VUE environment)?

Thanks in advance,

Fish-E Carwil James


From HOLTZMAN%SJUVM.STJOHNS.EDU@stjohns.edu  Mon May  3 04:53:16 1993
Return-Path: <HOLTZMAN%SJUVM.STJOHNS.EDU@stjohns.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21815; Mon, 3 May 93 04:53:16 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07644; Mon, 3 May 1993 05:13:51 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 8127; Mon, 03 May 93 05:13:28 SET
Received: from SJUVM.STJOHNS.EDU (NJE origin MAILER@SJUVM) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 4970; Mon, 3 May 1993 05:13:28 +0200
Received: from SJUVM (NJE origin HOLTZMAN@SJUVM) by SJUVM.STJOHNS.EDU (LMail V1.1d/1.7f) with BSMTP id 5973; Sun, 2 May 1993 23:12:59 -0400
Date:         Sun, 02 May 93 23:10:17 EDT
From: "Michael S. Holtzman" <HOLTZMAN%SJUVM.BITNET@cearn.bitnet>
Organization: St. John's University
Subject:      Lib v2 for VM/CMS?
To: www-talk@nxoc01.cern.ch
Message-Id:   <930502.231017.EDT.HOLTZMAN@SJUVM>

Greetings.  Can anyone tell me if the V2 code for the WWW library and the
line mode browser will be updated for CMS -- I tried compiling the library
and I got a lot of name conflicts which are the results of (new) long names
not included in the  SHORT_NAMES re-definitions.

If no one is planning on doing this I would be willing to volunteer -- I
just don't want to re-invent the wheel.

Thanx in advance for the info...

--------------------------------------------------------------------
Michael S. Holtzman      St. John's University    HOLTZMAN@SJUVM
Mgr, Academic Systems    Perboyre Hall, Rm B14    MIKE000@SJUMUSIC
(718) 990-1637           Jamaica, NY 11439

From pflynn@curia.ucc.ie  Mon May  3 11:50:43 1993
Return-Path: <pflynn@curia.ucc.ie>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24851; Mon, 3 May 93 11:50:43 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12050; Mon, 3 May 1993 12:11:19 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 9229; Mon, 03 May 93 12:10:55 SET
Received: from IRUCCIBM.BITNET (NJE origin MAILER@IRUCCIBM) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 7556; Mon, 3 May 1993 12:10:55 +0200
Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id
 0645; Mon, 03 May 93 11:08:35 IST
Received: from curia.ucc.ie by IRUCCVAX.UCC.IE (PMDF #12095) id
 <01GXQIVFV6KW001E35@IRUCCVAX.UCC.IE>; Mon, 3 May 1993 11:07 GMT
Received: by curia.ucc.ie (4.1/SMI-4.1) id AA05900; Mon, 3 May 93 11:03:37 BST
Date: Mon, 3 May 93 11:03:37 BST
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re: support for setext, the structure-enhanced text format, in WWW
To: www-talk@nxoc01.cern.ch
Message-Id: <9305031003.AA05900@curia.ucc.ie>
X-Envelope-To: www-talk@nxoc01.cern.ch

Ian writes:

>   forgive me for barging in on like this, infrequent listener on
>   this list that I am, but I'd like you to cast an eye on a dis-
>   cussion now underway in alt.hypertext, comp.text.sgml and several
>   other crossposted groups, which may be of interest in regard to
>   adding an ability to the WWW line-browser to recognize and access
>   _implicitly_coded_ anchors in otherwise plaintext documents (the
>   setext graphic markup method).
>
>     Try this first:
>
> news:a7fd5104@random.se       18K, 309 lines
> news:a800bb38@random.se       24K, 507 lines
>
>     else
>
> file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a7fd5104@random.se
> file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a800bb38@random.se
>

I have found a problem in retrieving news thru both www (linemode) and
xmosaic. Both correctly pick up my news server name, and if I follow the
links from `By Type' thru `Network News' to a specific group, both programs
correctly list the articles, but cannot access the article texts, giving
me instead the message `Connecting to NewsHost ...' and then coming back
with `Back, Quit or Help:'

It is clear that both programs are expecting articles to be stored in files
with names set to the message-id. I have never encountered a system which
does this, and my own server runs plain vanilla nntp and Cnews, which puts
articles in files whose names are the article numbers (sequential, 1+).

As the www server is capable of finding the directory (and is presumably
grepping for 'Subject:' and piping the results back into HTML---or is it
actually opening each file in turn?) could not a simple addition to the code
see if the files are named (=message-ID) or numbered (=message-number) and
act accordingly?

If this is not possible, where do I find a news system which stores articles
under message-ID filenames instead?

///Peter

From timbl@www3.cern.ch  Mon May  3 13:03:13 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25366; Mon, 3 May 93 13:03:13 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24482; Mon, 3 May 1993 13:23:49 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA11797; Mon, 3 May 93 13:19:36 +0100
Date: Mon, 3 May 93 13:19:36 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305031219.AA11797@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: pflynn@curia.ucc.ie (Peter Flynn)
Subject: NTTP retrieval problem, was: support for setext, the structure-enhanced text format, in WWW
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


Peter,

Your www program is not contacting a www server at all. When the
document address specifies "news:..." the it talks NNTP.
NNTP says nothing about how articles are  stored, but allows
one to ask for them by Message-id.  Sounds like your newsreader
doesn't have the articles. There should be an error message.
Try
	www -v news:a7fd5104@random.se
to see what is going on.

Begin forwarded message:

Date: Mon, 3 May 93 11:03:37 BST
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Re: support for setext, the structure-enhanced text format,  
in WWW
To: www-talk@nxoc01.cern.ch
X-Envelope-To: www-talk@nxoc01.cern.ch

Ian writes:

>   forgive me for barging in on like this, infrequent listener on
>   this list that I am, but I'd like you to cast an eye on a dis-
>   cussion now underway in alt.hypertext, comp.text.sgml and several
>   other crossposted groups, which may be of interest in regard to
>   adding an ability to the WWW line-browser to recognize and access
>   _implicitly_coded_ anchors in otherwise plaintext documents (the
>   setext graphic markup method).
>
>     Try this first:
>
> news:a7fd5104@random.se       18K, 309 lines
> news:a800bb38@random.se       24K, 507 lines
>
>     else
>
>  
file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a7fd5104@random 
.se
>  
file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a800bb38@random 
.se
>

I have found a problem in retrieving news thru both www (linemode)  
and
xmosaic. Both correctly pick up my news server name, and if I follow  
the
links from `By Type' thru `Network News' to a specific group, both  
programs
correctly list the articles, but cannot access the article texts,  
giving
me instead the message `Connecting to NewsHost ...' and then coming  
back
with `Back, Quit or Help:'

It is clear that both programs are expecting articles to be stored in  
files
with names set to the message-id. I have never encountered a system  
which
does this, and my own server runs plain vanilla nntp and Cnews, which  
puts
articles in files whose names are the article numbers (sequential,  
1+).

As the www server is capable of finding the directory (and is  
presumably
grepping for 'Subject:' and piping the results back into HTML---or is  
it
actually opening each file in turn?) could not a simple addition to  
the code
see if the files are named (=message-ID) or numbered  
(=message-number) and
act accordingly?

If this is not possible, where do I find a news system which stores  
articles
under message-ID filenames instead?

///Peter


From mike@fionn.lbl.gov  Tue May  4 00:03:49 1993
Return-Path: <mike@fionn.lbl.gov>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07384; Tue, 4 May 93 00:03:49 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02909; Tue, 4 May 1993 00:24:26 +0200
Received: from fionn.lbl.gov by mcsun.EU.net with SMTP
	id AA05274 (5.65b/CWI-2.217); Mon, 3 May 1993 23:26:02 +0200
Received: by fionn.lbl.gov (4.1/1.39)
	id AA18856; Mon, 3 May 93 14:24:37 PDT
Message-Id: <9305032124.AA18856@fionn.lbl.gov>
From: mike@fionn.lbl.gov (Michael Helm)
Date: Mon, 3 May 1993 14:24:37 PDT
In-Reply-To: Carwil James <fishe@speedy.acns.nwu.edu>
       "HP Apollo Client Software" (May  2,  3:45pm)
Reply-To: mike@fionn.lbl.gov
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: Carwil James <fishe@speedy.acns.nwu.edu>, www-talk@nxoc01.cern.ch
Subject: Re: HP Apollo Client Software

On May 2,  3:45pm, Carwil James wrote:
> Our RS/6000 workstations were just replaced by HP Apollo 715's, so  
> XMosaic no longer works. Is there any client software which works on  

I run xmosaic on HPUX w/ few problems (don't bother trying to
open it on a Sun server -- only problem I know about).


From marca@wintermute.ncsa.uiuc.edu  Tue May  4 09:10:09 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11830; Tue, 4 May 93 09:10:09 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26796; Tue, 4 May 1993 09:30:44 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23814
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 4 May 93 02:30:40 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03541; Tue, 4 May 93 02:33:02 -0500
Date: Tue, 4 May 93 02:33:02 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305040733.AA03541@wintermute.ncsa.uiuc.edu>
To: pflynn@curia.ucc.ie (Peter Flynn)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: support for setext, the structure-enhanced text format, in WWW
In-Reply-To: <9305031003.AA05900@curia.ucc.ie>
References: <9305031003.AA05900@curia.ucc.ie>
X-Md4-Signature: b1782bfca1d5e54f8cc8633c8b8b16df

The upshot of this is that this is the same problem I sent mail to
www-talk about a few days ago.  Many news servers do not honor the RFC
977 (NNTP protocol spec) requirement to support fetching articles by
article ID -- they only allow fetching by group and message number.

This is a big, big problem.  There really aren't any answers, except
to have one's news admin switch to a working NNTP server (I'm not sure
which versions of what are working and broken, only that some servers
work and some don't).  URL's aren't currently designed to reference
articles by group and number, and as Tim pointed out this isn't really
feasible, since message number is a very transient property.

If anybody has any other ideas, please post them to the list....

Cheers,
Marc


Peter Flynn writes:
> I have found a problem in retrieving news thru both www (linemode)
> and xmosaic. Both correctly pick up my news server name, and if I
> follow the links from `By Type' thru `Network News' to a specific
> group, both programs correctly list the articles, but cannot access
> the article texts, giving me instead the message `Connecting to
> NewsHost ...' and then coming back with `Back, Quit or Help:'
> 
> It is clear that both programs are expecting articles to be stored
> in files with names set to the message-id. I have never encountered
> a system which does this, and my own server runs plain vanilla nntp
> and Cnews, which puts articles in files whose names are the article
> numbers (sequential, 1+).
> 
> As the www server is capable of finding the directory (and is
> presumably grepping for 'Subject:' and piping the results back into
> HTML---or is it actually opening each file in turn?) could not a
> simple addition to the code see if the files are named (=message-ID)
> or numbered (=message-number) and act accordingly?
> 
> If this is not possible, where do I find a news system which stores
> articles under message-ID filenames instead?


From emv@garnet.msen.com  Tue May  4 09:46:06 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12134; Tue, 4 May 93 09:46:06 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05206; Tue, 4 May 1993 10:06:42 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nqI0U-000EYqC; Tue, 4 May 93 04:05 EDT
Message-Id: <m0nqI0U-000EYqC@garnet.msen.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: pflynn@curia.ucc.ie (Peter Flynn), www-talk@nxoc01.cern.ch
Subject: Re: support for setext, the structure-enhanced text format, in WWW 
In-Reply-To: Your message of Tue, 04 May 93 02:33:02.
             <9305040733.AA03541@wintermute.ncsa.uiuc.edu> 
Date: Tue, 04 May 93 04:05:41 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

If you are looking to replace your NNTPD I'd recommend INN.  In
addition to being really quick, it has fine grained control on
who can and can't read news articles.  (For instance, it lets
me offer Reuters news access to single users on other machines.)

--Ed

From pflynn@curia.ucc.ie  Tue May  4 11:15:56 1993
Return-Path: <pflynn@curia.ucc.ie>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13169; Tue, 4 May 93 11:15:56 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23940; Tue, 4 May 1993 11:36:31 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 3644; Tue, 04 May 93 11:36:06 SET
Received: from IRUCCIBM.BITNET (NJE origin MAILER@IRUCCIBM) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 9197; Tue, 4 May 1993 11:36:06 +0200
Received: from IRUCCVAX.UCC.IE by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id
 4041; Tue, 04 May 93 10:34:15 IST
Received: from curia.ucc.ie by IRUCCVAX.UCC.IE (PMDF #12095) id
 <01GXRVMZ7ZY8001GL2@IRUCCVAX.UCC.IE>; Tue, 4 May 1993 10:23 GMT
Received: by curia.ucc.ie (4.1/SMI-4.1) id AA20126; Tue, 4 May 93 10:20:19 BST
Date: Tue, 4 May 93 10:20:19 BST
From: pflynn@curia.ucc.ie (Peter Flynn)
Subject: Broken nntp server support for article-ID retrieval
To: www-talk@nxoc01.cern.ch
Cc: twpierce@amhux1.amherst.edu
Message-Id: <9305040920.AA20126@curia.ucc.ie>
X-Envelope-To: twpierce@amhux1.amherst.edu, www-talk@nxoc01.cern.ch

marc (marca@wintermute.ncsa.uiuc.edu) writes on Tue May  4 08:27:34 1993

> The upshot of this is that this is the same problem I sent mail to
> www-talk about a few days ago.  Many news servers do not honor the RFC
> 977 (NNTP protocol spec) requirement to support fetching articles by
> article ID -- they only allow fetching by group and message number.
>
> This is a big, big problem.  There really aren't any answers, except
> to have one's news admin switch to a working NNTP server (I'm not sure
> which versions of what are working and broken, only that some servers
> work and some don't).  URL's aren't currently designed to reference
> articles by group and number, and as Tim pointed out this isn't really
> feasible, since message number is a very transient property.
>
> If anybody has any other ideas, please post them to the list....

A news guru colleague has pointed out here that my nntp server does
support retrieval by article-ID, it's just that it doesn't work...:-)
It seems my history file is broken, so I'm attempting repair (although
why this should be I cannot understand). My understanding is that this
failure is fairly widespread, but can someone please point me at a site
where retrieval thru www _does_ work, so I can institute some comparisons?

///Peter

> Peter Flynn writes:
> > I have found a problem in retrieving news thru both www (linemode)
> > and xmosaic. Both correctly pick up my news server name, and if I
> > follow the links from `By Type' thru `Network News' to a specific
> > group, both programs correctly list the articles, but cannot access
> > the article texts, giving me instead the message `Connecting to
> > NewsHost ...' and then coming back with `Back, Quit or Help:'
> >
> > It is clear that both programs are expecting articles to be stored
> > in files with names set to the message-id. I have never encountered
> > a system which does this, and my own server runs plain vanilla nntp
> > and Cnews, which puts articles in files whose names are the article
> > numbers (sequential, 1+).
> >
> > As the www server is capable of finding the directory (and is
> > presumably grepping for 'Subject:' and piping the results back into
> > HTML---or is it actually opening each file in turn?) could not a
> > simple addition to the code see if the files are named (=message-ID)
> > or numbered (=message-number) and act accordingly?
> >
> > If this is not possible, where do I find a news system which stores
> > articles under message-ID filenames instead?
>
>

From m.koster@nexor.co.uk  Tue May  4 18:50:40 1993
Return-Path: <m.koster@nexor.co.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21153; Tue, 4 May 93 18:50:40 MET DST
Received: from lancaster.nexor.co.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17363; Tue, 4 May 1993 19:11:11 +0200
Message-Id: <9305041711.AA17363@dxmint.cern.ch>
Received: from nexor.co.uk (actually vulcan.nexor.co.uk) 
          by lancaster.nexor.co.uk with SMTP (PP);
          Tue, 4 May 1993 18:11:03 +0100
To: www-talk@nxoc01.cern.ch
Subject: NeXor's Web and Warchie
Date: Tue, 04 May 1993 18:11:00 +0100
From: Martijn Koster <m.koster@nexor.co.uk>


Hi all,

I'm not sure this is the correct group for this, I only joined
a couple of days ago. But...

I have setup an experimental web service here on 

	http://web.nexor.co.uk/

It has the usual links to other places about, some sales info about
the company, and a link to Warchie: an archie gateway I wrote that
shows its findings as links (host, directory and file), and allows
substring and regexp searching too.

I'd appreciate any comments on either.

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A=Mark400; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NeXor Ltd@cn=Martijn Koster
URL: http://web.nexor.co.uk/mak/mak.html

From sanders@bsdi.com  Wed May  5 06:11:55 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01942; Wed, 5 May 93 06:11:55 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12557; Wed, 5 May 1993 06:32:31 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA10107; Tue, 4 May 93 21:42:38 -0500
Message-Id: <9305050242.AA10107@austin.BSDI.COM>
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Announcing version 1.0 of the perl HTTPD server
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Tue, 04 May 1993 21:40:08 -0500
From: Tony Sanders <sanders@bsdi.com>

Here is the server documentation:
    http://www.bsdi.com/server/httpd.html
Here is where the code lives:
    http://www.bsdi.com/server/
See this for the latest information:
    http://www.bsdi.com/server/overview.html

The whole server is only 50K of perl source.  The base server is only
410 lines (13K, that includes the directory browser).  The rest of the
bulk is 13K of documentation and 22K for the various gateways (1441 lines
total).

This server is based on the perl server developed at cs.indiana.edu
by Marc VanHeyningen.  See:
    http://cs.indiana.edu/perl-server/intro.html
    http://cs.indiana.edu/hyplan/mvanheyn.html
I did some work to make the base code more portable and then I've
been adding gateways like crazy.

I've been running it for several weeks now adding a little bit each night,
so it's fairly stable.  You can try out various feature by browsing our
server at http://www.bsdi.com/.  Please keep in mind that currently this
system is on a 56K line so if things are slow you might try back later.
I'll be moving it to a faster net at some point in the near future, but
it will be transparent to the user (it'll keep the www.bsdi.com name).

This server is NOT supported in any way but feel free to send me comments
or bug fixes.  Note that some of the gateways are designed to work on a
BSD/386 system and might require some porting to work on other systems
(the date gateway is a good example).  I've tried to provide some reasonable
documentation for the server so that it will be easier for people to hack
on it.  If you add any neat feature please let me know.

If you think of a good name for it let me know.

Features:
    The Date and Time Gateway
       See the data and time in any timezone (demo)

    The Finger Gateway (with faces support)
       Finger people (demo)

    The Directory Browser
       Include last mod time and size and file/directory indicator.
       Check out http://www.bsdi.com/server/ for an example.

    The Fortune Gateway
       Get a fortune cookie (demo)

    Calendar
       The current months calendar (or you can specify year or month/year)
       (demo)

    Restricted Access Directories
       restrict access by account number and IP address.

    Image Decoding
       Some tools to support image decoding when browsers are able to
       send the x, y coordinates of the mouse click when you select
       the image.  If you have xmosaic and would like an advance demo
       of this check out http://www.bsdi.com/demo/hypermedia.html.
       The patches required for xmosaic 1.0 are pointed to by that file.
       PLEASE, PLEASE, PLEASE, don't use them for production code.
       Only use them for this demo.  I'm hoping I can get support
       for this in xmosaic 1.1 (to do it right requires changing
       <IMG SRC...> to support something like <IMG ISMAP SRC...>
       to enable the new code only on images that support it.

    Directory Search
       Allows regexps on a whole directory hierarchy in a simple fashion.
       Quick enough for about 50 files or 1MB on low volume servers (1
       second search time on a 486DX2/66 running BSD/386).  Above that
       you need something like WAIS.

--sanders@bsdi.com

From montulli@stat1.cc.ukans.edu  Wed May  5 21:11:57 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14363; Wed, 5 May 93 21:11:57 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11091; Wed, 5 May 1993 21:32:37 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA19968; Wed, 5 May 1993 14:25:17 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9305051925.AA19968@stat1.cc.ukans.edu>
Subject: CWIS-L mailing list
To: www-talk@nxoc01.cern.ch
Date: Wed, 5 May 93 14:25:17 CDT
X-Mailer: ELM [version 2.3 PL2]

I would like to invite all active WWW developers and prophets to
join the CWIS-L Listserv mailing list.  CWIS-L is dedicated
to the discussion of the implementation and maintenance of CWIS's
around the world.  Many Universities and colleges are currently 
evaluating software for use in their CWIS.  There is currently a 
raging discussion about the positive and negative aspects of WWW 
and its benefits over Gopher.  If anyone wishes to give input to 
this discussion please sign up.

CWIS-L@WUVMD.BITNET  is the list.  I assume a normal listserv
signup request to listserv@wuvmd.bitnet will do the trick.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanvax.bitnet                                 *
  *                         Kuhub.cc.ukans.edu                             *
  *  Nothing difficult,     Ukanaix.cc.ukans.edu    ACS Computing Services *
  *   is ever easy!             913/864-0436           Lawrence, KS 66044  *
  *                                                                        *
  *          If the UNIX compress command had been named feather,          *
  *            all of my programs would be tar'd and feather'd.            *
  *		      (Perhaps they should be anyways?)                    *
  **************************************************************************

From marca@wintermute.ncsa.uiuc.edu  Wed May  5 21:42:00 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15178; Wed, 5 May 93 21:42:00 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14007; Wed, 5 May 1993 22:02:40 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA20261
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 5 May 93 15:02:39 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA10795; Wed, 5 May 93 15:05:02 -0500
Date: Wed, 5 May 93 15:05:02 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305052005.AA10795@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from drmacro@vnet.IBM.COM
X-Md4-Signature: 752065daba17e0609d9c89c0a57805d5

Forwarded from comp.text.sgml... 

------- Start of forwarded message -------
Newsgroups: comp.text.sgml
Disclaimer: This posting represents the poster's views, not those of IBM
From: drmacro@vnet.IBM.COM
Subject: Explicit Linking is Impossible
Date: Tue, 4 May 93 11:10:35 EDT

At relatively small scales, it is possible to create hypertext
where authors hand craft the links between various places, say
via typical IDREF mechanisms.  Given a "standard" document of
100 pages, one author can reasonably manage to create say 1000
links within that 100 pages.  We do it as a matter of course
within IBM.  Across a library of 10 such books, we can manage
crafting 100 links from each book to the other books, but just
barely.  The cost is the cost not of initially creating the
links, but of maintaining them as the documents change during
development.  This can just be managed within one library where
all the books are finished and delivered at about the same time.

The next order of magnitude up would be linking across libraries.
This is impossible once the number of cross-library links goes
above about 50 because of maintenance problems--there are simply
not enough hours in the day or people on the job to create, maintain,
and test these links.  The next order of magnitude up (cross-enterprise
linking) is so clearly impossible as to be not worth considering.
               ^^^^^^^^^^^^^^^^^^ [emphasis added -marc]

Thus my contention that explicit linking is impossible at large
scales.  Even if you apply tools at one order of magnitude to
make the impossible possible (say a database system to track
links and manage changes), the next order of magnitude increase
will be impossible.  With change management and tracking, the
human element cannot be eliminated and you quickly reach the
practical limit at which humans can manage change.

Note that within IBM, and specifically within the Networking
Systems line of business, we are now at the cross-library linking
stage.  Using the BookManager product, we are creating, by hand,
explicit hyperlinks between the NetView, VTAM, NCP, and related
product libraries.  We think we can manage a relatively small
number of links at this level, but there's no way we could do
it at any larger scale.  We need to move up to the next order
of magnitude (cross-enterprise linking), but we can't with the
explicit-link-based tools we have today.

Note that when I say explicit or hand-crafted links, I mean
only from the author's perspective.  Exoterica's experience
with the Cinemania project is instructive here.  If I understand
it correctly, they used declarative markup in the SGML source
to enable creation of all links associatively, and then bound
those links explicitly in the derived form that was actually
delivered.  From the author's viewpoint, all the links were
implicit, but from the final application's viewpoint, they
were all explicit.

The cost of hypertext is the cost of creating and maintaining
the links.  I don't have any numbers, but it's pretty clear
>from my experience with the extensive hypertext we've created
in Networking Systems, that the cost of maintenance is not
a linear function of the number of links, but increases dramatically
(geometrically?) with the number of links, compounded by the
degree to which the linked objects' schedules are not synchronized
and the life span of the linked objects.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-254-5160
IBM Corporation
Research Triangle Park, NC 27709
------- End of forwarded message -------

You know, if I didn't know any better, I'd say he probably works for
IBM.  (Well?  Didn't *you* lose $5 billion last year?)

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From aronsson@lysator.liu.se  Wed May  5 23:03:58 1993
Return-Path: <aronsson@lysator.liu.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16840; Wed, 5 May 93 23:03:58 MET DST
Received: from lysator.liu.se by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24563; Wed, 5 May 1993 23:24:39 +0200
Received: from bodil.lysator.liu.se (130.236.254.152) by lysator.liu.se (ALPHA-6.36/6.16) id AA23732; Wed, 5 May 1993 23:24:37 +0200 
Received: by bodil.lysator.liu.se (ALPHA-6.36/6.16) id AA06898; Wed, 5 May 1993 23:24:26 +0200 
Date: Wed, 5 May 1993 23:24:26 +0200
From: aronsson@lysator.liu.se
Message-Id: <199305052124.AA06898@bodil.lysator.liu.se>
To: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible]

In message <9305052005.AA10795@wintermute.ncsa.uiuc.edu>,
Marc Andreessen <marca@ncsa.uiuc.edu> wrote:
>Forwarded from comp.text.sgml... 

[forwarded message by Eliot Kimber, IBM, on the cost of hypertext]

>You know, if I didn't know any better, I'd say he probably works for
>IBM.  (Well?  Didn't *you* lose $5 billion last year?)

Marc, thanks for forwarding this message.  Perhaps I should start
reading comp.text.sgml.  I am quite new to all of this, so I don't
know what has been discussed, and what views you different people
might have.  My limited experience of writing HTML documents and
converting old plain text documents to HTML makes me agree with Eliot
Kimber's conclusions.

Adding and maintaining hypertext links up--back--forward between
chapters, sections and subsections is so easy, that I have already
automated it.  Adding hypertext links between a text and an alphabetic
index (or a dictionary) should be as easy, and just as easy to make
automatically.  But manually keeping track of hypertext links between
a text that I maintain and another text that someone else maintains,
would be next to impossible.

I don't know, Marc, what your seemingly sarcastic two line remark
means.  If you mean tbat maintaining hypertext links within large
collections of texts is easy and affordable, if you have good tools
for this, perhaps you could enlighten me and other people about this?

Thanks, Marc and NCSA, for X Mosaic.  Is there an NCSA HTML editor
too?  Today I have GNU Emacs.  I would like two Mosaic windows, and to
create hypertext links between the two documents by clicking a mouse
button.  If the destination document is maintained by someone else, he
should be notified that I have a link going there, so he doesn't
rename or reorganize his document without notifying me again.

From emv@garnet.msen.com  Thu May  6 00:05:29 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18019; Thu, 6 May 93 00:05:29 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02364; Thu, 6 May 1993 00:26:09 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nqrsc-000EZYC; Wed, 5 May 93 18:23 EDT
Message-Id: <m0nqrsc-000EZYC@garnet.msen.com>
To: aronsson@lysator.liu.se
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: Your message of Wed, 05 May 93 23:24:26.
             <199305052124.AA06898@bodil.lysator.liu.se> 
Date: Wed, 05 May 93 18:23:58 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

It's not necessary to make really deep explicit links to other
people's hypertext; often times it's enough to pre-load a search that
takes people near the right place.  E.g. you don't say "page 342 of
ISBN 1-56592-027-9" you say "Look up the section on environment
variables in the O'Reilley MH book".

Authors do this all the time - if you can assume a good index (or do
automatic indexing and be prepared for some slop) you can get quite a
bit of the effort done.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)


From marca@wintermute.ncsa.uiuc.edu  Thu May  6 00:36:42 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18330; Thu, 6 May 93 00:36:42 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07286; Thu, 6 May 1993 00:57:23 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA04987
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 5 May 93 17:57:22 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11610; Wed, 5 May 93 17:59:45 -0500
Date: Wed, 5 May 93 17:59:45 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305052259.AA11610@wintermute.ncsa.uiuc.edu>
To: aronsson@lysator.liu.se
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible]
In-Reply-To: <199305052124.AA06898@bodil.lysator.liu.se>
References: <199305052124.AA06898@bodil.lysator.liu.se>
X-Md4-Signature: 8a574e00e7c06ea8fed0ca1db836db44

aronsson@lysator.liu.se writes:
> I don't know, Marc, what your seemingly sarcastic two line remark
> means.  If you mean tbat maintaining hypertext links within large
> collections of texts is easy and affordable, if you have good tools
> for this, perhaps you could enlighten me and other people about
> this?

It was just a joke... fyi, I'm an ex-IBM'er, and it amuses me greatly
to see the "we can do anything, and if we can't, it's not possible"
mentality still in action.

No, I don't think that maintaining hypertext links within large
collections of texts is currently easy and quote-unquote affordable,
and I don't have any magic tools, but that has nothing to do with
whether or not such a task is "impossible".  Limitations of current
technology should not be extrapolated to judge possibility or
impossibility; I would have thought the Wright brothers taught us that
principle some time ago.

Pardon, however, the humor, 
Marc


From aronsson@lysator.liu.se  Thu May  6 01:01:11 1993
Return-Path: <aronsson@lysator.liu.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18607; Thu, 6 May 93 01:01:11 MET DST
Received: from lysator.liu.se by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09557; Thu, 6 May 1993 01:21:52 +0200
Received: from bodil.lysator.liu.se (130.236.254.152) by lysator.liu.se (ALPHA-6.36/6.16) id AA02455; Thu, 6 May 1993 01:21:51 +0200 
Received: by bodil.lysator.liu.se (ALPHA-6.36/6.16) id AA07208; Thu, 6 May 1993 01:21:40 +0200 
Date: Thu, 6 May 1993 01:21:40 +0200
From: aronsson@lysator.liu.se
Message-Id: <199305052321.AA07208@bodil.lysator.liu.se>
To: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible]

In message <m0nqrsc-000EZYC@garnet.msen.com>,
Edward Vielmetti <emv@garnet.msen.com> wrote:

>                  ; often times it's enough to pre-load a search that
>takes people near the right place.  E.g. you don't say "page 342 of
>ISBN 1-56592-027-9" you say "Look up the section on environment
>variables in the O'Reilley MH book".

What exactly does "pre-load a search" mean, and how do I implement
this in an HTML document?  Say that I want to refer to the WWW
Provider's Style Guide by Tim Berners-Lee at CERN, for the section
about how big to make each document.  Now, all of you readers of
www-talk can find this manually, and have probably already read that
text, but that is not why someone invented hypertext and the
world-wide web.  How do I do this without explicitly saying
href="http://info.cern.ch/hypertext/WWW/Provider/Style/DocSize.html"?

What if Tim and his WWW service moves from CERN to a new place?  What
if Tim decides to rename "WWW/Provider/Style" to "WWWSTYLE.DIR"?  I
don't say that he would, but he certainly could, and that would be
like pulling the rug away from under my feet.  Would I fall and would
that hurt?  If someone can pull this rug, why should I stand on it?

I would be happier to refer to an ISBN number, because then I only
specify the publisher, and not the library where I found the book, and
there would be an organization for registering new ISBN numbers that
would stop an author from changing a documents name.

There are already number series for books (ISBN) and serials (ISSN).
What I seem to ask for is ISHN, or an International Standard for
Hypertext Numbers.  These would have to be longer than ISBN numbers,
because they would not only refer to books, but also to sections and
paragraphs within a book.  An author would register an ISHN for each
section or paragraph of his book, and other authors could only refer
to these numbers.  After that, the author must not change his book.
This sounds too complicated to me, so lets hear some better solutions!

From sanders@bsdi.com  Thu May  6 01:14:06 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18760; Thu, 6 May 93 01:14:06 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10901; Thu, 6 May 1993 01:34:44 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA01420; Wed, 5 May 93 18:34:41 -0500
Message-Id: <9305052334.AA01420@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: aronsson@lysator.liu.se's message of Wed, 05 May 93 23:24:26 +0200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 05 May 1993 18:34:40 -0500
From: Tony Sanders <sanders@bsdi.com>

aronsson@lysator.liu.se's message of Wed, 05 May 93 23:24:26 +0200.
> might have.  My limited experience of writing HTML documents and
> converting old plain text documents to HTML makes me agree with Eliot
> Kimber's conclusions.
...
> automatically.  But manually keeping track of hypertext links between
> a text that I maintain and another text that someone else maintains,
> would be next to impossible.

Use indirection, make the anchors say "the part of the foobar manual about
blat" and then have a database that translates them to actual HREF's and/or
computes them on the fly.  There is no magic wand or silver bullet to
solve these problems, but you can make it easier to maintain when something
goes away.  In the local arena you can use backrefs to manage changes,
not so easy with global documents (though DOCid's and HTTP2 will solve
some of the problems).

There is nothing wrong with adding a layer of software beteen HTML
and whatever documents you are storing to make life easier.

Part of problem lies in the approach.  Hypertext is designed as a
distributed information management system (how else can you expect to put
a yottabyte of data online :-), and they are trying to do everything local
and then publish this whole big thing.  No doubt they are having problems.
No doubt that the problem they are trying to solve is hard.  The fact that
link complexity is non-linear isn't a new problem.  Every system that has
relationships has this problem, including human interaction.  This is the
big company/project problem and you can use some of the same techniques
to minimize its impact.

In summary, I agree that massive explicit linking is impossible, but it
isn't desirable either.  I like what Edward Vielmetti, just said about
it, he sums it up better than I.  Yes, there is a need for tools in this
area, keep in mind this is a VERY young technology (you can tell becuase
hypertext still means something, unlike older technologies like
Object-Oriented programming which have ceased to have any real meaning).
To me it's not hypertext if it's not interactive (authoring tools!) and
we aren't quite there yet.

> Thanks, Marc and NCSA, for X Mosaic.  Is there an NCSA HTML editor
> too?  Today I have GNU Emacs.  I would like two Mosaic windows, and to
tkWWW has editing functions (you can add links on the fly) but it needs
work before it's "production" quality.  The problem is that HTTP2 isn't
in place yet so you can't send the changes back to the server anyway.

An ex-IBMer also (moved 4 times in three years) ;-)

--sanders@bsdi.com

From sanders@bsdi.com  Thu May  6 01:19:50 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18882; Thu, 6 May 93 01:19:50 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11972; Thu, 6 May 1993 01:40:30 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA01485; Wed, 5 May 93 18:40:28 -0500
Message-Id: <9305052340.AA01485@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: Your message of Thu, 06 May 93 01:21:40 +0200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 05 May 1993 18:40:28 -0500
From: Tony Sanders <sanders@bsdi.com>

> There are already number series for books (ISBN) and serials (ISSN).
> What I seem to ask for is ISHN, or an International Standard for
> Hypertext Numbers.  These would have to be longer than ISBN numbers,
> because they would not only refer to books, but also to sections and
> paragraphs within a book.  An author would register an ISHN for each
> section or paragraph of his book, and other authors could only refer
> to these numbers.  After that, the author must not change his book.
> This sounds too complicated to me, so lets hear some better solutions!
This is what DOCid's are.  A namespace like DNS where you register
documents.  Someone just has to do it.

--sanders

From marca@wintermute.ncsa.uiuc.edu  Thu May  6 02:17:39 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19414; Thu, 6 May 93 02:17:39 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18054; Thu, 6 May 1993 02:38:20 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA10868
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 5 May 93 19:38:18 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11863; Wed, 5 May 93 19:40:41 -0500
Date: Wed, 5 May 93 19:40:41 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305060040.AA11863@wintermute.ncsa.uiuc.edu>
To: aronsson@lysator.liu.se
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible]
In-Reply-To: <199305052321.AA07208@bodil.lysator.liu.se>
References: <199305052321.AA07208@bodil.lysator.liu.se>
X-Md4-Signature: 58796e3912b6228e8a912a0f31d1891c

aronsson@lysator.liu.se writes:
> What if Tim and his WWW service moves from CERN to a new place?
> What if Tim decides to rename "WWW/Provider/Style" to
> "WWWSTYLE.DIR"?  I don't say that he would, but he certainly could,
> and that would be like pulling the rug away from under my feet.
> Would I fall and would that hurt?  If someone can pull this rug, why
> should I stand on it?
> 
> I would be happier to refer to an ISBN number, because then I only
> specify the publisher, and not the library where I found the book,
> and there would be an organization for registering new ISBN numbers
> that would stop an author from changing a documents name.
> 
> There are already number series for books (ISBN) and serials (ISSN).
> What I seem to ask for is ISHN, or an International Standard for
> Hypertext Numbers.

A large part of what you're talking about is coming, in the form of
the Uniform Resource Name or whatever it ends up being called.
Distributed hypertext is still in its infancy; be patient... (or
better yet, keep contributing ideas and criticisms).

Cheers,
Marc


From marca@wintermute.ncsa.uiuc.edu  Thu May  6 02:24:46 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19507; Thu, 6 May 93 02:24:46 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18508; Thu, 6 May 1993 02:45:26 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11256
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 5 May 93 19:45:25 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11878; Wed, 5 May 93 19:47:47 -0500
Date: Wed, 5 May 93 19:47:47 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305060047.AA11878@wintermute.ncsa.uiuc.edu>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: <9305052334.AA01420@austin.BSDI.COM>
References: <9305052334.AA01420@austin.BSDI.COM>
X-Md4-Signature: b783c2829df1af93ea7df85184d8fd62

Tony Sanders writes:
> > Thanks, Marc and NCSA, for X Mosaic.  Is there an NCSA HTML editor
> > too?  Today I have GNU Emacs.  I would like two Mosaic windows, and to
> tkWWW has editing functions (you can add links on the fly) but it needs
> work before it's "production" quality.  The problem is that HTTP2 isn't
> in place yet so you can't send the changes back to the server anyway.

Just a note: transparent addition of hyperlinks is one of my top
priorities for Mosaic this summer (they will initially be handled the
same way as personal annotations are now, and then extended along with
personal annotations into group/community/world sharing and
collaboration).  I'm planning on using the same user interface
Intermedia uses/used, btw (select the text of the hyperlink in one
window/document, choose "Start Link" from the menubar, select the text
for the target of the hyperlink in another window/document, choose
"Complete Link" from the menubar).  Anyone have better ideas?
(Something drag'n'drop might be nice...)

Also, I don't yet have a plan in place for tracking positions in
documents for this -- initially I'll probably use a combination of
character position plus context, so Mosaic will at least be able to
tell you when a hyperlink you made previously has become invalid due
to the text changing (it will then append it to the file, just like
annotations are now) -- unless a better idea comes along.  Suggestions
welcome...

> An ex-IBMer also (moved 4 times in three years) ;-)

Yow!  Still own stock??

Marc


From sanders@bsdi.com  Thu May  6 02:45:07 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19748; Thu, 6 May 93 02:45:07 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22484; Thu, 6 May 1993 03:05:47 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA01715; Wed, 5 May 93 20:05:45 -0500
Message-Id: <9305060105.AA01715@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: More about DOCid's and HTTP2
In-Reply-To: Your message of Thu, 06 May 93 01:52:24 +0200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 05 May 1993 20:05:45 -0500
From: Tony Sanders <sanders@bsdi.com>

I got this out-of-band:
> Thanks for pointing out "DOCid's" and "HTTP2".  Are there any
> documents about this in the web?  Do you have the full link names?  Is
> the topic discussed anywhere else than www-talk?  Other www-talk
> readers would probably be interested in the answers.

http://info.cern.ch:80/hypertext/WWW/Protocols/HTTP/HTTP2.html
http://info.cern.ch/hypertext/WWW/DesignIssues/FunctionTraverse.html

these talk about UDI's a little:
http://info.cern.ch/hypertext/WWW/DesignIssues/DosDonts.html 
http://info.cern.ch/hypertext/WWW/Administration/DataModel.html

I couldn't find much that talks about DOCid's directly (there isn't much
because they don't exist yet :-).  Anyone know where some docs are that
talk about this?  I've seen them but couldn't find them right now.

I thought about writing a perl script that retrieves and greps http
documents from ~/.mosaic-global-history but then I realized there are over
1200 in my history file, whew.

<INFORMATION>
Here are my top 5 servers (out of 101):
  68 www.bsdi.com		(my server)
  81 hoohoo.ncsa.uiuc.edu	(xmosaic)
  85 cs.indiana.edu		(where my server code came from)
  95 www.ncsa.uiuc.edu		(xmosaic)
 236 info.cern.ch		(WWW HQ)

as computed by:
------- cut: server-hist --------
#!/usr/bin/perl -n
next unless /^file:/ || /^ftp:/ || /^gopher:/ || /^http:/ || /^telnet:/;
next if /\?/;		# queries don't count
s,^[^/]*//,,; s,[:/].*,,; s,\.$,,; y/A-Z/a-z/; print;
----------------------------
server-hist ~/.mosaic-global-history | sort | uniq -c | sort -n | tail -5
</INFORMATION>

<PROJECT IDEA>
Someone should make a server where you can mail your .mosaic-global-history
file and it will munge it into some stats that we can view on the Web.
</PROJECT>

--sanders@bsdi.com

From sanders@bsdi.com  Thu May  6 05:44:58 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21223; Thu, 6 May 93 05:44:58 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09690; Thu, 6 May 1993 06:05:38 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA02220; Wed, 5 May 93 23:05:36 -0500
Message-Id: <9305060405.AA02220@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: DOCids
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 05 May 1993 23:05:36 -0500
From: Tony Sanders <sanders@bsdi.com>

I found a reference to get you started.

http://info.cern.ch/hypertext/WWW/DesignIssues/Naming.html

--sanders@bsdi.com

From emv@garnet.msen.com  Thu May  6 05:54:22 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21298; Thu, 6 May 93 05:54:22 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09953; Thu, 6 May 1993 06:15:03 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nqxMF-000EYxC; Thu, 6 May 93 00:14 EDT
Message-Id: <m0nqxMF-000EYxC@garnet.msen.com>
To: aronsson@lysator.liu.se
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: Your message of Thu, 06 May 93 01:21:40.
             <199305052321.AA07208@bodil.lysator.liu.se> 
Date: Thu, 06 May 93 00:14:55 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

  
  What exactly does "pre-load a search" mean, and how do I implement
  this in an HTML document?  Say that I want to refer to the WWW
  Provider's Style Guide by Tim Berners-Lee at CERN, for the section
  about how big to make each document.  Now, all of you readers of
  www-talk can find this manually, and have probably already read that
  text, but that is not why someone invented hypertext and the
  world-wide web.  How do I do this without explicitly saying
  href="http://info.cern.ch/hypertext/WWW/Provider/Style/DocSize.html"?
  
Let's say that we had the equivalent of "archie" or "veronica" for
WWW.  Call it "spidey".  Then you could say
	href="spidey://spidey.msen.com:5000/DocSize.html"
(to match by file name) or	
	href="spidey://spidey.msen.com:5000/timbl+style+docsize"
or maybe even
	href="spidey://spidey.msen.com:5000/ISBN=2-012523-096-3+docsize"

Search #1 is the equivalent of the archie "-e" exact search.

Search #2 is the equivalent of a WAIS or Gopher search, with some
keywords; you can imagine a slightly enhanced version if you know that
the database is somehow structured.

Search #3 is what you would do if you do if major World Wide Web
collections had International Standard Book Numbers, and shows a
reference to an index in a book.

Each of these are probabilistic, but they should *both* get the user
close enough to the document to make it possible for them to find it
on ther own *and* not be immediately obsolete once the document
changes or moves.

(you hope)

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)

ps if you use "spidey" please give me credit :)

From emv@garnet.msen.com  Thu May  6 05:59:40 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21321; Thu, 6 May 93 05:59:40 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10786; Thu, 6 May 1993 06:20:20 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nqxRN-000EYxC; Thu, 6 May 93 00:20 EDT
Message-Id: <m0nqxRN-000EYxC@garnet.msen.com>
To: aronsson@lysator.liu.se
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: Your message of Thu, 06 May 93 01:21:40.
             <199305052321.AA07208@bodil.lysator.liu.se> 
Date: Thu, 06 May 93 00:20:13 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

  There are already number series for books (ISBN) and serials (ISSN).

ISSN numbers are useful and easy enough to get.  They are not as
useful as they could be because they are too short, too unstructured,
and because you don't have to pay for them.  There is a payment
mechanism keyed on ISSN numbers - in the US, the "Copyright Clearance
Center" - but it's done at the article level and is widely ignored.

ISBN numbers cost money, but not that much; you can put a number on a
document for not more than a buck or two, much less in quantity.
People on this list (O'Reilley in particular) already have them.  All
we need is a few more network publishers to get up to speed and we'll
be set.  ISBN numbers in the USA show up in "Books In Print" - if you
want to have Tim's "WWW Provider's Style Guide" show up in Books In
Print you better be prepared to send someone a copy (on disk or on
paper) if they decide to order it at the listed price :)

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)


From aronsson@lysator.liu.se  Thu May  6 08:48:28 1993
Return-Path: <aronsson@lysator.liu.se>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22492; Thu, 6 May 93 08:48:28 MET DST
Received: from lysator.liu.se by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00197; Thu, 6 May 1993 09:09:09 +0200
Received: from rune.lysator.liu.se (130.236.254.23) by lysator.liu.se (ALPHA-6.36/6.16) id AA07156; Thu, 6 May 1993 09:09:07 +0200 
Received: by rune.lysator.liu.se 
          (4.1/1.34/Lysator-3.1) id AA06447; Thu, 6 May 93 09:09:06 +0200
          (unknown)
Date: Thu, 6 May 93 09:09:06 +0200
From: aronsson@lysator.liu.se
Message-Id: <9305060709.AA06447@rune.lysator.liu.se>
To: emv@garnet.msen.com
Subject: Re: forwarded... [Explicit Linking is Impossible]
Cc: www-talk@nxoc01.cern.ch

Yes, the solution you suggest (spidey) could work.  While the present
scheme is like "go to the Royal Library in Stockholm, 2nd floor, take
to the left, walk 20 meters, turn to the right, there it is on the
3rd shelf, 15th book from the left, page 257.", the spidey scheme is
like "I think that John Shakespare wrote something about dreaming in
the middle of the summer".  I would still prefer ISBN numbers.  When
will spidey be up and running?

Lars Aronsson
     Aronsson@Lysator.LiU.SE

From news@newssrv.edvz.univie.ac.at  Thu May  6 11:14:00 1993
Return-Path: <news@newssrv.edvz.univie.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23951; Thu, 6 May 93 11:14:00 MET DST
Received: from mailsrv.edvz.univie.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24784; Thu, 6 May 1993 11:34:41 +0200
Received: from newssrv.edvz.univie.ac.at by email.univie.ac.at 
          with SMTP (PP-mailsrv) id <12278-0@email.univie.ac.at>;
          Thu, 6 May 1993 11:34:34 +0200
Received: by newssrv.edvz.univie.ac.at id AA16326 (5.65c8/IDA-1.4.4 
          for www-talk@info.cern.ch); Thu, 6 May 1993 11:12:08 +0200
Original-Received: from 
                   GATEWAY by newssrv with netnews for www-talk@info.cern.ch 
                   (www-talk@info.cern.ch)
Pp-Warning: Illegal Received field on preceding line
To: www-talk@nxoc01.cern.ch
Date: Thu, 6 May 1993 09:09:10 GMT
Message-Id: <1993May6.090910.28846@email.tuwien.ac.at>
Organization: Inst. f. Informationssysteme, TU Wien
From: email!w2!elmar@mailsrv.edvz.univie.ac.at (Praktikant)
Sender: News/Mail-Gateway@newssrv.edvz.univie.ac.at
Reply-To: elmar@infosys.tuwien.ac.at
Subject: Problems with httpd
X-Charset: ASCII
X-Char-Esc: 29


I compiled the httpd-server from CERN (version 2.04) on a sun-sparcstation 1+
with SUN/OS 4.1.3.

I started it from the command line with:

	httpd -R -v -p 3767

When I wanted to test the server with

	www http://w2.infosys.tuwien.ac.at:3767\
		/home/w11/elmar/www/WWW/Commands.html

the server printed the following on the screen:


New anchor 4c240 has hash 99 and address
	`/home/w11/elmar/www/WWW/Commands.html' 
HTAccess: loading document
	/home/w11/elmar/www/WWW/Commands.html
HTFile: can't stat
	/home/w11/elmar/WWW///home/w11/elmar/www/WWW/Commands.html
HTAccess: Opening
	`/home/w11/elmar/WWW///home/w11/elmar/www/WWW/Commands.html'
		gives -1
FTP: Looking for /home/w11/elmar/www/WWW/Commands.html
HTTPAccess: Can't find internet node name `'.
TCP: Error 2 in `errno' after call to FTP file load() failed.
        No such file or directory
HTAccess: Can't access `/home/w11/elmar/www/WWW/Commands.html'


Therefore I checked the file 'HTFile.c' and found that the filename is put
together in line 306 (function 'HTLocalName'):

	sprintf(result, "%s/WWW/%s/%s%s", home, access, host, path);
	
When I deleted this line and returned only the path, the server gave back
the information to the client which displayed it on the screen.

Because I have no debugger here, I couldn't test if this change will have
some unwanted consequences. Any ideas?

	Elmar

From timbl@www3.cern.ch  Thu May  6 15:46:20 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27584; Thu, 6 May 93 15:46:20 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05340; Thu, 6 May 1993 16:07:01 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA17697; Thu, 6 May 93 16:02:43 +0100
Date: Thu, 6 May 93 16:02:43 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305061502.AA17697@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: elmar@infosys.tuwien.ac.at
Subject: Re: Problems with httpd
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



Sorry, you can't operate with no rules at all now.
Operation is defined by the first in priority of:

1.	-r <file> option, where <file> exists.

2.	a directory name on the command line, in which
	case a default rule file is assumed which just maps
	everything into that directory

3.	A rule file httpd.conf if that exists

4.	If no rule file exists and no directory name,
	a default rule file will be assumed which exports
	the directory /Public as in (2).

Operation without a rule file does not work as the path
sent is not a complete url, and the rule file must map
to a URL starting with file: .

I have fixed the online documentation to reflect that
the -R option should not be used.  (It was a
security hole anyway, as was documented!)

Tim

From fheyligh%vnet3.vub.ac.be@cc1.kuleuven.ac.be  Thu May  6 15:55:01 1993
Return-Path: <fheyligh%vnet3.vub.ac.be@cc1.kuleuven.ac.be>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27774; Thu, 6 May 93 15:55:01 MET DST
Received: from cc1.kuleuven.ac.be by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05975; Thu, 6 May 1993 16:15:35 +0200
Received: from rc1.vub.ac.be by cc1.kuleuven.ac.be (IBM VM SMTP V2R2) with TCP;
   Thu, 06 May 93 16:14:43 +0200
Received: from vnet3.vub.ac.be by rc1.vub.ac.be (4.1/RC1-930416)
	id AA13916; Thu, 6 May 93 16:15:23 +0100
Received: from [134.184.35.101] (pespmc1) by vnet3.vub.ac.be (4.1/VUB.920213)
	id AA22574; Thu, 6 May 93 16:15:18 +0200
Message-Id: <9305061415.AA22574@vnet3.vub.ac.be>
Date: Thu, 6 May 1993 16:16:57 +0100
To: www-talk@nxoc01.cern.ch
From: fheyligh@vnet3.vub.ac.be (Francis Heylighen)
Subject: Interface for link adding

marca@ncsa.uiuc.edu (Marc Andreessen):
>Just a note: transparent addition of hyperlinks is one of my top
>priorities for Mosaic this summer (they will initially be handled the
>same way as personal annotations are now, and then extended along with
>personal annotations into group/community/world sharing and
>collaboration).  I'm planning on using the same user interface
>Intermedia uses/used, btw (select the text of the hyperlink in one
>window/document, choose "Start Link" from the menubar, select the text
>for the target of the hyperlink in another window/document, choose
>"Complete Link" from the menubar).  Anyone have better ideas?
>(Something drag'n'drop might be nice...)

It might be simpler if you don't have to select "Complete link" from the
menubar, since the default expectation is that, apart from navigation
commands, the command following "Start Link" will anyway be "Complete
Link". Why not simply let the user press "return" or "enter" or something
like that once the destination has been selected? Something similar is used
in HyperCard: when you choose "Start Link" a little dialog window appears
on your screen which remains there while you navigate to the destination
(in the same or another window), and then you choose "Link" or "Cancel"
from the dialog. It does not make much difference with the scheme Marc
proposes, but slightly decreases the complexity of remembering and
selecting the "Complete link" command.

Drag and drop would also be nice, but the problem is that you would first
have to select the destination anchor on which the source anchor should be
dropped. Otherwise the system would not know whether you want to link to
the whole document, window, section, sentence, or word... Having to make
the selection beforehand would obviate the advantage of drag and drop
editing. You might avoid this by proposing a default selection for the
destination, e.g. the sentence in which you drop, but that would make the
default system rather inflexible.

A perhaps simpler possibility is that the text  being selected as a source
anchor S would be highlighted in a particular way (e.g. selecting with the
mouse by double-clicking or by clicking with the shift key), indicating the
entering of the "link mode". When another text chunk D somewhere else would
be selected the system would by default assume that you want to link the
former to the latter, and propose the dialog "Link S to D?" with "OK" or
"Cancel". Graphically this might also be represented by an arrow or line
starting from the source text and moving with the mouse to the destination
text being selected. The presence of the arrow would denote "link mode",
and as long as that mode is on, any selection would automatically be
interpreted as a destination anchor.

_______________________________________________________________________
Dr. Francis Heylighen                                Systems Researcher
PO, Free University of Brussels, Pleinlaan 2, B -1050 Brussels, Belgium
Phone:+32-2-6412525; Fax:+32-2-6412489; Email: fheyligh@vnet3.vub.ac.be


From sanders@bsdi.com  Thu May  6 18:06:51 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00340; Thu, 6 May 93 18:06:51 MET DST
Errors-To: sanders@bsdi.com
Received: from [137.39.95.2] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28064; Thu, 6 May 1993 18:27:31 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA03205; Thu, 6 May 93 11:27:21 -0500
Message-Id: <9305061627.AA03205@austin.BSDI.COM>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded... [Explicit Linking is Impossible] 
In-Reply-To: aronsson@lysator.liu.se's message of Thu, 06 May 93 09:09:06 +0200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 06 May 1993 11:27:21 -0500
From: Tony Sanders <sanders@bsdi.com>

> Yes, the solution you suggest (spidey) could work.  While the present
> scheme is like "go to the Royal Library in Stockholm, 2nd floor, take
> to the left, walk 20 meters, turn to the right, there it is on the
> 3rd shelf, 15th book from the left, page 257.", the spidey scheme is
> like "I think that John Shakespare wrote something about dreaming in
> the middle of the summer".  I would still prefer ISBN numbers.  When
> will spidey be up and running?

You can embed WAIS searches in URL's which is really the same thing.
Also, my server has a search package included so you can do this
pretty easily (some assembly required).

For an example the following directory is searchable.
    http://www.bsdi.com/info/lawsuit/
and you could embed a query in a link
    http://www.bsdi.com/ifno/lawsuit?frey
will pop you into a menu of press releases by Donnalyn Frey.

--sanders@bsdi.com

From timbl@www3.cern.ch  Thu May  6 18:13:08 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00483; Thu, 6 May 93 18:13:08 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29822; Thu, 6 May 1993 18:33:50 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA18254; Thu, 6 May 93 18:29:33 +0100
Date: Thu, 6 May 93 18:29:33 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305061729.AA18254@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: drmacro@ralvm13.vnet.ibm.com
Subject: Re: Explicit Linking is Impossible
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Forwarded from comp.text.sgml... 

> From: drmacro@vnet.IBM.COM
> Date: Tue, 4 May 93 11:10:35 EDT
> 

> At relatively small scales, it is possible to create hypertext
> where authors hand craft the links between various places, say
> via typical IDREF mechanisms 

> [...] This is impossible once the number of cross-library links  
goes
> above about 50 because of maintenance problems--there are simply
> not enough hours in the day or people on the job to create,  
maintain,
> and test these links.  The next order of magnitude up  
(cross-enterprise
> linking) is so clearly impossible as to be not worth considering.

You have a goood point of the scalability of the web.  This has been
made by some people here who have the same wories.  A solution which
works in software systems is to have, in any work, a set of anchors
which are explicitly declared "public" just like a global
declaration of a routine.  This declation means that the author
will maintain that (named) entry point.  It may be that the server
will want to keep a table of entry points to map them onto real  
places, and indeed in the HTTP2 protocol there is a specified but
unimlplemented by anyone yet as far as I know (SBUAYAFAIK,
vapourware for short) facility for an HTTP server to return a new
URL as a name server, instead of the document.

Other anchors whch are not declared public would not be linkable to
outside the document. This would be a convention which you could
enforce locally.

This scheme scales quite well, as for any size entity (article,
chapter, book, shelf, department, library...) there would be,
independent of its internal size, a fixed number of global entry  
points, so the problem scales as log N ie better than the
organisation which wrote it. (Not a dig at IBM but a comment
on hierarchical management perhaps)


Ed's system of referiing to searches in the index
"Look up the section on environment
variables in the O'Reilley MH book"
is similar, though heuristic if you don't contract with
ORA that they there will always be a section on envirnonment
variables in the book.

Tim Berners-Lee
CERN

From timbl@www3.cern.ch  Thu May  6 18:41:35 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01054; Thu, 6 May 93 18:41:35 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04450; Thu, 6 May 1993 19:02:17 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA18281; Thu, 6 May 93 18:57:59 +0100
Date: Thu, 6 May 93 18:57:59 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305061757.AA18281@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: ec@pms240.pms.ford.com (Iain O'Cain)
Subject: Re: Newsgroup forming?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Xref: dxcern news.announce.newgroups:3199 news.groups:65638  
comp.infosystems:1246
Path: dxcern!mcsun!uunet!bounce-back
From: fine@news.cis.ohio-state.edu (Thomas A Fine)
Newsgroups: news.announce.newgroups,news.groups,comp.infosystems
Subject: RESULT: comp.infosystems.www passes 375:10
Followup-To: news.groups
Date: 4 May 1993 20:00:13 -0400
Organization: Ohio State University Computer and Information Science
Lines: 396
Sender: tale@rodan.UU.NET
Approved: tale@uunet.uu.net
Message-ID: <1s702dINNb22@rodan.UU.NET>

The vote to create comp.infosystems.www passed by both the required  
2/3
minimum and by the required 100 votes difference.

Yes votes:  375
No votes:    10

The following is a list of people who voted NO:

  10  04/02 bobw@procase.com  

   2  03/26 cline@usceast.cs.scarolina.edu  

   4  03/26 ejo@kaja.gi.alaska.edu  

   9  04/02 emcguire@intellection.com  

   3  03/26 hmpetro@mosaic.uncc.edu  

   6+ 03/26 lau@ai.sri.com  

   8  03/30 news@frednet.com  

   1  03/26 rick@crick.ssctr.bcm.tmc.edu  

   7  03/28 stu@valinor.mythical.com  

   5  03/26 werner@soe.berkeley.edu  


The following is a list of people who voted YES:

 294  04/02 "0000-Admin(0000)" <root@chausey.inria.fr> 

 124  03/29 "Dave Hastings, OUCS" <daveh@vax.ox.ac.uk> 

 230  03/30 "David E. Martin" <dem@hep.net> 

  88  03/28 "Ed Costello" <costello@vnet.IBM.COM> 

 227  03/30 "Ferran Jorba (UAB)" <G_JORBA@cc.uab.es> 

 371  04/13 "H&kon W Lie howcome@hal.nta.no" <Haakon.Lie@nta.no> 

  78  03/28 "John Ladwig" <jladwig@soils.umn.edu> 

 193  03/29 "Johnson, Vicki@IESD/" <VLJ@MSM.EPRI.COM> 

 269  03/31 "Lubos Pavlicek" <PAVLICEK@nb.vse.cs> 

 160  03/29 "Mark H. Wood" <IMHW400@INDYVAX.IUPUI.EDU> 

 120  03/29 "Michael Mehl" <mehl@dfki.uni-sb.de> 

  35  03/26 "Michael O'Henly" <mohenly@malahat.library.uvic.ca> 

 169  03/29 "Patrick W. Matlock (DCS)" <pmatlock@usg.uwaterloo.ca> 

 344  04/07 "Peter Lister, Cranfield Computer Centre"  
<ccprl@xdm001.ccc.cranfie
 350  04/07 "Peter Marshall CCS UWO" <peter@julian.uwo.ca> 

 318  04/03 "Robbin R. Hough" <hough@vela.acs.oakland.edu> 

 197  03/30 "Roland Yeo" <ry@ntu.ac.sg> 

 187  03/29 "Sam C. Nicholson !!" <scion@netimage.com> 

  99  03/28 "Stephen E. Bacher" <seb@draper.com> 

 204  03/30 "Timo Harmo - SocSci U of Helsinki"  
<HARMO@valt.helsinki.fi> 

 339  04/06 "Tony Johnson (415) 926 2278"  
<TONYJ@SCS.SLAC.STANFORD.EDU> 

 200  03/29 "Wije Wathugala, Asst. Professor, Civil Eng., LSU"  
<CEWIJE@LSUVAX.S
 346  04/07 "William C. Green" <W.Green@utexas.edu> 

  58  03/27 "William M. Perry" <wmperry@apricot.ucs.indiana.edu> 

 379  04/19 <Gerd-Harald.Knauf@cdc2.rrzn.uni-hannover.dbp.de> 

 154  03/29 Adrian Howard <adrianh@cogs.sussex.ac.uk> 

 365  04/09 Alan P Barrett <barrett@daisy.ee.und.ac.za> 

 135  03/29 Alan_Blair.McLean_CSD@xerox.com 

 203  03/29 Albert-Lunde@nwu.edu (Albert Lunde) 

  60  03/27 Aleksandar Totic <totic@milton.cs.uiuc.edu> 

 351  04/08 Alexis Rosen <alexis@Panix.Com> 

 108  03/29 Anthony Baxter <anthony@aaii.oz.au> 

 360  04/08 Anthony David Smith <tonys@ariel.ucs.unimelb.EDU.AU> 

 185  03/29 Anthony Tomasic <tomasic@DB.Stanford.EDU> 

 167  03/29 Ari Lemmke <arl@cs.hut.fi> 

 381  04/20 Arthur Secret <secret@hpwww> 

 372  04/13 Bebo White <BEBO@SLACVM.SLAC.Stanford.EDU> 

 337  04/06 Ben Whitaker <benw@chemistry.leeds.ac.uk> 

 145  03/29 Benedikt Homann <bene@cs.tu-berlin.de> 

  61  03/27 Betsy Coles (2) <ECL4BH2@MVS.OAC.UCLA.EDU> 

  54  03/27 Bill Dueber <wdueber@cs.indiana.edu> 

 117  03/29 Bill Wohler <wohler@hw1175.sap-ag.de> 

 266  03/31 Bob Bagwill <bagwill@swe.ncsl.nist.gov> 

 149  03/29 Bob Jackson <jackson@stsci.edu> 

 306  04/02 Bob Sutterfield <bob@MorningStar.Com> 

 226  03/30 Brian Harrington <brian@musicbox.mse.jhu.edu> 

  62  03/27 Bryan Cardoza <Bryan_Cardoza@Novell.COM> 

 270  03/31 CCGARCIA@MIZZOU1.missouri.edu 

  93  03/28 Chip Canty <ccanty@world.std.com> 

 121  03/29 Chris Adie <cja@castle.edinburgh.ac.uk> 

 374  04/13 Christopher McRae <mcrae@lib.ucsf.EDU> 

 155  03/29 Cricket Liu <cricket@winnie.corp.hp.com> 

 126  03/29 D.T.Shield@compsci.liverpool.ac.uk 

 173  03/29 Dave Garver <garver@zorro.cecer.army.mil> 

 250  03/31 Dave_Raggett <dsr@hplb.hpl.hp.com> 

 246  03/30 David Datta <datta@cs.uwp.edu> 

 166  03/29 David Lowe <lowe@cs.ubc.ca> 

  51  03/27 David Muir Sharnoff <muir@idiom.berkeley.ca.us> 

 190  03/29 Dirk Herr-Hoyman <hoymand@joe.uwex.edu> 

 199  03/29 Donald Acton <acton@cs.ubc.ca> 

 205  03/30 Dudu Rashty +972-2-584848 <RASHTY@vms.huji.ac.il> 

   6  03/26 Ed Wilts 389-3430 <EWILTS@galaxy.gov.bc.ca> 

 211  03/30 Eelco van Asperen <evas@cs.few.eur.nl> 

  85  03/28 Eric Prestemon <ecp2z@hopper.acs.virginia.edu> 

 223  01/01 Esko Rahiala <era@lesti.hut.fi> 

 247  03/30 FSSPR@acad3.alaska.edu 

  19  03/26 FTP-Email Gateway <ftpmail@grasp1.univ-lyon1.fr> 

 111  03/29 George Phillips <phillips@cs.ubc.ca> 

 334  04/06 Gerald Fowler <gfowler@wilkins.iaims.bcm.tmc.edu> 

   7  03/26 Glyn Simpson <G.Simpson@bham.ac.uk> 

 116  03/29 Grant Denkinson <gwd10@geog.nott.ac.uk> 

 175  03/29 Greg Isett <GWI@rip.hrb.com> 

 159  03/29 Guido.van.Rossum@cwi.nl 

 228  03/30 Guy Cardwell <gcardwel@okazaki.acs.uci.edu> 

 342  04/08 Harald Tveit Alvestrand  
<harald.t.alvestrand@delab.sintef.no> 

 312  04/02 Harri K Salminen <Harri.Salminen@funet.fi> 

 213  03/30 Hiroaki Ikeda <ikeda@hike.te.chiba-u.ac.jp> 

 101  03/28 James Powell <jpowell@borg.lib.vt.edu> 

 170  03/29 Jamie Blustein <jamie@csd.uwo.ca> 

  29  03/26 Jeff Hayward <J.Hayward@utexas.edu> 

 225  03/30 Jeff Zucker <jz27@cunixf.cc.columbia.edu> 

 315  04/02 Jeffrey E. Dooley <dooley@well.sf.ca.us> 

 373  04/13 Jim Ault <aultj@rpi.edu> 

  55  03/27 Jim Davis <davis@DRI.cornell.edu> 

  75  03/28 Joerg MESSER <joerg@iiasa.ac.at> 

 164  03/29 John Price-Wilkin <jpw@sansfoy.lib.virginia.edu> 

   5  03/26 John Vollbrecht <vollbrec@europa.eng.gtefsd.com> 

  71  03/28 Jon Knight <J.P.Knight@lut.ac.uk> 

  90  03/28 Jon William Dunn <jwd@owlnet.rice.edu> 

 375  04/14 Jonathan Kochmer {NWNet} <jonathan@nwnet.net> 

 327  04/06 Juergen Christoffel <jc@slim.gmd.de> 

 292  04/01 Julio Perez <julio@umich.edu> 

 112  03/29 Jyrki Kuoppala <jkp@cs.hut.fi> 

  11  03/26 Kari Sutela <sutela@utu.fi> 

 308  04/02 Karl Fox <karl@MorningStar.Com> 

  23  03/26 Keith Porterfield <kwp@avalanche.com> 

 333  04/06 Ken Rossen <kenr@isc.com> 

 182  03/29 Ken Schroder <schroder@diamond.bbn.com> 

 367  04/11 Kim Toms <kim@MorningStar.Com> 

  80  03/28 L L Campbell <campbell@bach.udel.edu> 

 244  03/30 Larry Masinter <masinter@parc.xerox.com> 

 241  03/31 Lars H}kedal <larsha@ifi.uio.no> 

  77  03/28 Lars-Gunnar Olsson <Lars-Gunnar.Olsson@data.slu.se> 

 194  03/30 Len.Makin@mel.dit.csiro.au 

 218  03/30 Luc Ottavj <Luc.Ottavj@sophia.inria.fr> 

 210  03/30 M Cuthbertson <M.Cuthbertson@lut.ac.uk> 

  52  03/27 M S Bennet <msb2@doc.ic.ac.uk> 

 129  03/29 Malcolm.Harper@prg.oxford.ac.uk 

  50  03/27 Marc VanHeyningen <mvanheyn@cs.indiana.edu> 

 216  03/30 Marcus Roberts <mjr@computer-science.nottingham.ac.uk> 

 243  03/30 Mark Alexander Davis-Craig <mad@merit.edu> 

 268  03/31 Mark Courtenay <mark@galadriel.bt.co.uk> 

 131  03/29 Mark Krause <mkrause@mitre.org> 

 245  03/31 Mark Prior <mrp@itd.adelaide.edu.au> 

  10  03/26 Markus Stumpf <stumpf@informatik.tu-muenchen.de> 

 114  03/29 Martijn Koster <m.koster@nexor.co.uk> 

  74  03/28 Martin Hamilton <M.T.Hamilton@lut.ac.uk> 

 332  04/06 Matt Crawford <crawdad@munin.fnal.gov> 

 271  03/31 Matt Heffron <heffron@emilia.css.beckman.com> 

  64+ 03/27 Matt Rollefson <draphsor@deathstar.stanford.edu> 

 303  04/02 Matthew Lewis <matthew@ic.uva.nl> 

 314  04/02 Michael Clarkson<mike@cmm.ensmp.fr> 

 198  03/30 Michael Francis Ledwidge <leddo@minnie.cs.su.oz.au> 

 290  04/01 Michael Quinn <MJQUINN@pucc.Princeton.EDU> 

 275  03/31 Michele Evard <mevard@media.mit.edu> 

 279  04/01 Mike Brudenell <pmb1@tower.york.ac.uk> 

 125  03/29 Mike Stok <mike@meiko.com> 

  92  03/28 Morris Balamut <balamut@morris.hac.com> 

 355  04/05 N F Drakos <nikos@cbl.leeds.ac.uk> 

  86  03/28 Natalie Glance <glance@parc.xerox.com> 

  32  03/27 Nathan Torkington <Nathan.Torkington@vuw.ac.nz> 

 115  03/29 Nick Williams <njw@cs.city.ac.uk> 

 224  03/30 Ove Hansen <ohansen@europe.cisco.com> 

 188  03/29 PSAGASER@apsc.com (Patrick Sagaser) 

  43  03/26 Paul Jones <pjones@mento.oit.unc.edu> 

 287  04/01 Paul Zhu <paulzhu@ruby.ils.unc.edu> 

 325  04/06 Pekka.Nikander@ajk.tele.fi 

 171  03/29 Penny Bertrang <pbertran@lionheart.berkeley.edu> 

 286  04/01 Perry Sze-Din Cheng <pscheng@owlnet.rice.edu> 

 215  03/30 Peter Orbaek <poe@daimi.aau.dk> 

 163  03/29 Petri Ojala <ojala@funet.fi> 

 137  03/29 Phil Jensen <jensen@groucho.cc.fsu.edu> 

 331  04/06 Phil Julian <julian@unx.sas.com> 

 153  03/29 R J Williams <rodw@cbl.leeds.ac.uk> 

 369  04/12 RUTH@FNDA20.FNAL.GOV 

  94  03/28 RWWMAINT@msu.edu (Richard W Wiggins) 

 100  03/28 Ran Atkinson <atkinson@tengwar.itd.nrl.navy.mil> 

 338  04/06 Richard Hintz <OPSRJH@uccvma.ucop.edu> 

 353  04/04 Rik Fleuren <rik@sci.kun.nl> 

 195  03/30 Rik Harris <rik@daneel.rdt.monash.edu.au> 

  31  03/26 Rob Lanphier <lanphi872@snake.cs.uidaho.edu> 

  98  03/28 Rob Raisch <raisch@ora.com> 

 238  03/31 Roland Schuetzner <roli@cosy.sbg.ac.at> 

 295  04/01 Ron Tapia <tapia@centauri.unm.edu> 

 363  04/08 Rose Marie Holt <rmholt@u.washington.edu> 

 146  03/29 Rosemary Walsh <rose@MITL.COM> 

 234  03/30 Sascha Wildner <swildner@channelz.GUN.de> 

 354  04/05 Schneider Christian <cschneid@pws2.itr.ch> 

 254  03/31 Sean Sebastian Batt <sean@cheops.anu.edu.au> 

  15  03/26 Sheryl Erez <erez@cac.washington.edu> 

 298  04/02 Sieberath@scil.ucl.ac.be (Roald Sieberath) 

  41  03/26 Simon Spero <ses@sunsite.unc.edu> 

 300  04/02 Somers@sisc.ucl.ac.be (Francis Somers) 

 212  03/30 Steen Linden <Steen.Linden@uni-c.dk> 

 258  03/31 Stella O'Brien <S.M.O-brien@lut.ac.uk> 

 272  03/31 Stephen Hebditch <steveh@orbital.demon.co.uk> 

 307  04/02 Steve Neruda <neruda@MorningStar.Com> 

 232  03/30 Steve Peltz <peltz@cerl.uiuc.edu> 

  39  03/26 Steve Putz <putz@parc.xerox.com> 

 107  03/28 Steve Romig <romig@cis.ohio-state.edu> 

 347  04/07 Steve Sullivan <steve.sullivan@ucop.edu> 

  69  03/28 Steve.Cavrak@UVM.EDU 

 179  03/29 Terry Coatta <coatta@cs.ubc.ca> 

 221  03/30 Terry Tautz <terry@RandomAccess.com> 

 143  03/29 Terry West <terry@kiwi.rand.org> 

 278  04/01 Thierry Dautcourt <Thierry.Dautcourt@loria.fr> 

 139  03/29 Thomas A. Fine <fine@cis.ohio-state.edu> 

  97  03/28 Tom Zillner <tzillner@milkyway.wils.wisc.edu> 

  67  03/28 Tony Catone <catone@compstat.wharton.upenn.edu> 

 283  04/01 Torre Wenaus <wenaus@pdsf.ssc.gov> 

 207  03/30 Ulrich Pfeifer  
<pfeifer@schroeder.informatik.uni-dortmund.de> 

 361  04/08 Una Smith <smith-una@YALE.EDU> 

 322  04/05 Wayne.Gramlich@Eng.Sun.COM (Wayne C. Gramlich) 

 343  04/07 adams@tnt.uni-hannover.de (Martin Adams) 

 103  03/29 adrian vanzyl <adrianv@brain.vifp.monash.edu.au> 

 359  04/08 ahi@nada.kth.se 

 288  04/01 ajt@proteus.com (Arthur J Thomas) 

  26  03/26 al@cs.brown.edu (Andre Lehovich) 

  89  03/28 aldrich@sunrise.Stanford.EDU (Jeff Aldrich) 

  56  03/27 andy@vistachrome.com (Andrew Finkenstadt) 

 330  04/06 aronson@nlm.nih.gov (Jules P. Aronson) 

 123  03/29 ashley@chaz.demon.co.uk (Charles Ashley) 

 168  03/29 bbendick@GAS.uug.Arizona.EDU (Brett L Bendickson ) 

 133  03/29 bcalvert@cadsun.corp.mot.com 

 206  03/29 bellegj@storm.CS.ORST.EDU 

  96  03/28 bense@heart3.UCSD.EDU (Booker C. Bense) 

 297  04/02 bernhard@tnt.uni-hannover.de (Ronald Bernhardt) 

 305  04/02 bloemer@tnt.uni-hannover.de (Arnold Bloemer) 

 326  04/06 blume@tnt.uni-hannover.de (Torsten Blume) 

 324  04/05 bob@simple.sat.tx.us (Bob Friesenhahn) 

 296  04/02 bolle@tnt.uni-hannover.de (Johanna Bolle) 

 189  03/29 brent@uful07.phys.ufl.edu 

  47  03/26 brian@piano.grot.starconn.com (Brian Smithson) 

 152  03/29 briand@ncsa.uiuc.edu (Briand T. Sanderson) 

  49  03/26 brighton@pixar.com (Bill Carson) 

 158  03/29 broccol@csdsun1a.arlut.utexas.edu (Jonathan Abbey) 

 362  04/08 carr@acsu.buffalo.edu (Dave Carr) 

 147  03/29 chen@cds001.cebaf.gov 

 132  03/29 chris.wbst139@xerox.com 

 256  03/31 chris@fuzzball.demon.co.uk (Chris Flecher) 

 313  04/02 cjoslyn@bingsuns.cc.binghamton.edu (Cliff Joslyn) 

 109  03/29 clare@uniwa.uwa.edu.au (Clare Johnstone) 

  79  03/28 cowboy@trans.csuohio.edu (Joe Rosenfeld) 

 184  03/29 cwong@cs.cornell.edu (Christopher Yoong-Meng Wong) 

 259  03/30 dack@permanet.org (dack) 

 127  03/29 damouth@wrc.xerox.com (David E. Damouth) 

  44  03/26 dan@engr.LaTech.edu (Daniel Len Schales) 

 299  04/02 dave@soil.gsfc.nasa.gov (David Graham) 

  33  03/26 dave@telco-nac.com (David Cornejo) 

 162  03/29 david@albertina (David M. M. de Matos) 

 368  04/12 david@staff.udc.upenn.edu (R. David Murray) 

 138  03/29 dbigwood@locus.nalusda.gov (Doug Bigwood) 

 276  04/01 dehning@tnt.uni-hannover.de (Oliver Dehning) 

  27  03/26 devet@adv.win.tue.nl (Arjan de Vet) 

 144  03/29 dmjones@theory.lcs.mit.edu (David M. Jones) 

 281  04/01 dmosher@nyx.cs.du.edu (David Mosher) 

 222  03/30 drb@MATH.AMS.ORG (Drew Burton) 

   8  03/26 dsr@lns598.TN.CORNELL.EDU 

 202  03/29 dweber@ncsa.uiuc.edu (Daniel Weber) 

 349  04/07 dweiss@ciis.mitre.org (Diane Weiss) 

  68  03/28 dwells@fits.CV.NRAO.EDU (Don Wells) 

 352  04/03 dxw@uhics.ics.Hawaii.Edu (Dadong Wan) 

 267  03/31 edler@tnt.tnt.uni-hannover.de 

  30  03/26 edsr!jem@uunet.UU.NET (John E. Mendenhall) 

 289  04/01 ellis@nova (R. Stewart Ellis) 

  59  03/27 eostrom@nic.gac.edu (Erik C. Ostrom) 

 192  03/29 eric johnson <ejohnson@enuxha.eas.asu.edu> 

 257  03/31 falken@tnt.uni-hannover.de (Lutz Falkenhagen) 

 358  04/08 felix@erm2.u-strasbg.fr (felix KOOP) 

 130  03/29 fheyligh@vnet3.vub.ac.be (Francis Heylighen) 

 102  03/28 fishe@casbah.acns.nwu.edu (Carwil James) 

 113  03/29 franks@ntrc.ntu.ac.sg (Frank Siebenlist) 

 106  03/28 fredb@Calvin.EDU (Fred Bremmer) 

 366  04/11 friedric@darmstadt.gmd.de (Manuel Friedrich) 

  38  03/26 fwp@CC.MsState.Edu (Frank Peters) 

 263  03/31 gerken@tnt.tnt.uni-hannover.de 

 317  04/02 ggw@wolves.Durham.NC.US (Gregory G. Woodbury) 

  22  03/26 gondwana@basalt.mit.edu (Matthias Georg Imhof) 

 134  03/29 gprisco@estax3.wm.estec.esa.nl (Giulio Prisco - WMA) 

 261  03/31 grau@tnt.uni-hannover.de (Oliver Grau) 

  48  03/27 gsc@coombs.anu.edu.au (Sean Case) 

  65  03/28 gss@iil.intel.com (Sheaffer Gad) 

  16  03/26 gwb@umd5.umd.edu 

  63  03/27 hardin@ncsa.uiuc.edu (Joseph Hardin) 

 236  03/30 hasley@dad.bgsu.edu (John Hasley) 

 301  04/02 hb@info.ucl.ac.be (Hubert Broze) 

  91  03/28 heifetz!utacfd!awful!akf (Andrew Fullford) 

  14  03/26 heiko@chemie.fu-berlin.de (Heiko Schlichting) 

 328  04/06 heinboke@tnt.uni-hannover.de (Andreas Heinbokel) 

 178  03/29 huff@MCCLB0.MED.NYU.EDU (Edward J. Huff) 

 242  03/31 hugues@dorilys.gna.org (Hugues Lafarge) 

  81  03/28 hutchins@acf4.NYU.EDU (hutchins) 

 309  04/02 imad@farnsworth.mit.edu 

  72  03/28 j-germuska@nwu.edu (Joe Germuska) 

 336  04/06 jasonc@pk.com (Jason Coombs) 

  53  03/27 jbotz@orixa.mtholyoke.edu (Jurgen Botz) 

  40  03/26 jbrowne@ncsa.uiuc.edu (Zep fanatic) 

 321  04/05 jbuck@ohm.Berkeley.EDU (Joe Buck) 

 345  04/07 jd@ssru.city.ac.uk (John Douglas) 

 340  04/06 jknowles@binky.arc.nasa.gov (Jim Knowles) 

 253  03/31 jmt@eitech.com (Marty Tenenbaum) 

  17  03/26 joe@Athena.MIT.EDU 

 323  04/06 js@uci.agh.edu.pl (Jaroslaw Strzalkowski) 

 140  03/29 jst@lauri.oulu.fi (Juha Stalnacke) 

 364  04/08 jsuttor@netcom.com (Jeff Suttor) 

 378  04/19 jzp@gene.UMMED.EDU (Joseph Z. Provo) 

 161  03/29 karl@sugar.NeoSoft.Com (Karl Lehenbauer) 

 377  04/16 kbarger@ACC.HAVERFORD.EDU (Kyle Barger) 

  12  03/26 kchang@ncsa.uiuc.edu (Kenneth Chang) 

 180  03/29 kehoe@fortuity.sf.ca.us (Daniel Miles Kehoe) 

 176  03/29 kevin@bullwinkle.ssc.gov (Kevin Dunn) 

 150  03/29 kevin@scic.intel.com (Kevin Altis) 

 219  03/30 kieran@world.std.com (Aaron L Dickey) 

 128  03/29 klt@kt8127.b23a.ingr.com (Kermit Tensmeyer) 

 273  03/31 koch@tnt.uni-hannover.de (Reinhard Koch) 

 148  03/29 koellner@Csa6.LBL.Gov (Werner Koellner, LBL) 

  28  03/26 koreth@hyperion.com (Steven Grimm) 

 214  03/30 kossakow@rzdspc4.informatik.uni-hamburg.de (Klaus-Peter  
Kossakowski
 280  04/01 kozarev@tnt.uni-hannover.de (Aleksandra Kozarev) 

 382  04/19 kravcik@mff.uniba.cs (Milos Kravcik) 

  45  03/26 lebaron@inrs-telecom.uquebec.ca (Gregory LeBaron) 

 316  04/02 lepore@insane.sanders.lockheed.com (Lee Lepore) 

 110  03/29 loreto@sarin.it (GianlucaLoReto) 

 252  03/31 luigi@berlioz.crs4.it (Luigi Filippini) 

   9  03/26 lwv26@cas.org (Larry W. Virden, x2487) 

 249  03/31 malcolm@nutmeg.cs.ntu.edu.au (Malcolm Caldwell) 

  36  03/26 marca@ncsa.uiuc.edu (Marc Andreessen) 

 357  04/05 mariani@tnt.uni-hannover.de (Andrea Mariani) 

 310  04/02 martinez@tnt.uni-hannover.de (Geovanni Martinez) 

 181  03/29 matwood@peruvian.cs.utah.edu (Mark Atwood) 

 191  03/29 mcb@net.bio.net (Michael C. Berch) 

 376  04/15 mcclanah@dlgeo.cr.usgs.gov 

 370  04/12 mcharity@hq.LCS.MIT.EDU (Mitchell N Charity) 

 311  04/02 meyer@tnt.uni-hannover.de (Ralf Meyer) 

 105  03/28 mfolk@ncsa.uiuc.edu 

 320  04/05 mike@inti.lbl.gov (Michael Helm) 

 172  03/29 mitch@ella.mills.edu (Mitch Gass) 

  42  03/26 mitra@pandora.sf.ca.us (Mitra) 

 156  03/29 montulli@stat1.cc.ukans.edu (Lou Montulli) 

 380  04/19 morrisey@bach.wpafb.af.mil (Matt Morrisey) 

 183  03/29 morrison@ccs.carleton.ca (Greg Morrison) 

 255  03/31 mountaz@lri.fr 

 264  03/31 muenkel@tnt.uni-hannover.de (Heiko Muenkel) 

 233  03/30 murphy@dccs.upenn.edu 

  83  03/28 mycroft@gnu.ai.mit.edu 

  46  03/26 ned1@Ra.MsState.Edu (Nathan Doss) 

 201  03/29 neilb@borris.eece.unm.edu 

 302  04/02 nholtz@civeng.carleton.ca (Neal Holtz) 

 118  03/29 nishida@draken.src.ricoh.co.jp 

 329  04/06 oliver@smectos.gang.umass.edu (David Oliver) 

  25  03/26 owens@cookiemonster.cc.buffalo.edu (Bill Owens) 

 122  03/29 paolo petta <paolo@mail4.ai.univie.ac.at> 

 260  03/31 pestel@oscar.tnt.uni-hannover.de (Ulrike Pestel) 

  21  03/26 peterson@choctaw.csc.ti.com (Bob Peterson) 

 220  03/30 pkramer@unlinfo.unl.edu (Paul Kramer) 

 142  03/29 plewe@geog.buffalo.edu (Brandon Plewe) 

 231  03/30 prechelt@ira.uka.de 

 282  04/01 rabin@noao.edu 

  82  03/28 randy@psg.com (Randy Bush) 

 136  03/29 rbntjc@RohmHaas.Com 

 341  04/06 rcsmith@sed.csc.com (Ray Smith) 

  37  03/26 redman@ncsa.uiuc.edu 

 251  03/31 reinpost@info.win.tue.nl (Reinier Post) 

 151  03/29 rhca80@melton.sps.mot.com (Henry Melton) 

 248  03/30 richard@vanbc.wimsey.com (Richard Pitt) 

  34  03/26 riddle@is.rice.edu (Prentiss Riddle) 

 335  04/06 robp@anubis.network.com (Rob Peglar) 

 304  04/02 rodgers@nlm.nih.gov (Richard Rodgers) 

 285  04/01 roeber@axpvms.cern.ch (Frederick G.M. Roeber 01-Apr-1993  
1753) 

 240  03/30 rogerh@dynamis.uucp (Roger Harmston) 

  73  03/28 rossini@hsph.harvard.edu (Anthony Rossini) 

  13  03/26 rsk@gynko.circ.upenn.edu (Rich Kulawiec) 

 319  04/04 sbk@netcom.com 

  95  03/28 sbyrnes@rice.edu (Steven Byrnes) 

 265  03/31 schnier@tnt.uni-hannover.de (Thorsten Schnier) 

  24  03/26 scn@farnsworth.mit.edu (Suzanne Chambliss Neil) 

 209  03/30 sendall@dxpt01.cern.ch (Mike Sendall) 

 119  03/29 sharon@acri.fr (Sharon Peleg) 

 186  03/29 shenton@troll.gsfc.nasa.gov (Chris Shenton) 

 157  03/29 sp Campbell <S.P.Campbell@lut.ac.uk> 

  84  03/28 spok@GS1.SP.CS.CMU.EDU 

 235  03/30 spot@HOPELESS.MESS.CS.CMU.EDU 

  70  03/28 sridhar@asuvax.eas.asu.edu (Sridhar Venkataraman) 

 262  03/31 stauder@tnt.uni-hannover.de (Juergen Stauder) 

 291  04/02 stmeyer@tnt.uni-hannover.de (Dirk Steinmeyer) 

 274  03/31 tesuito@afterlife.ncsc.mil (Terry Suitor) 

 141  03/29 tim@ben.dciem.dnd.ca (Tim Pointing) 

  20  03/26 tim@canon.co.uk (Tim F O'Donoghue) 

 229  03/30 tmclaren@ncsa.uiuc.edu (Terrence M. McLaren) 

 237  03/30 toast <DHIRMES@hamp.hampshire.edu> 

  57  03/27 tom loos <tloos@papaya.ucs.indiana.edu> 

 284  04/01 tom@begbick.law.cornell.edu (Thomas R. Bruce) 

  87  03/28 tromo@keckiris.rice.edu 

 208  03/30 troyer@ips.id.ethz.ch 

 217  03/30 turner@farnsworth.mit.edu 

 177  03/29 utnereader@MR.Net (Griff Wigley) 

 196  03/29 valentin+@pitt.edu (Shawn V. Hernan) 

 356  04/05 vorpahl@tnt.uni-hannover.de (Joerg Vorpahl) 

 165  03/29 weber@eitech.com (Jay C. Weber) 

 239  03/30 wei@swindle.Berkeley.EDU (Pei Y. Wei) 

 104  03/28 wjm@feenix.metronet.com (Bill Middleton) 

  76  03/28 yandros@Athena.MIT.EDU 

  66  03/28 youchan@yokohama.se.fujitsu.co.jp (Youichi Watanabe) 

  18  03/26 zconcept@netcom.com (Mike Peeler) 

 174  03/29 zippy@ccwf.cc.utexas.edu (Jack Lund) 

 

From mvanheyn@cs.indiana.edu  Thu May  6 18:43:12 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01115; Thu, 6 May 93 18:43:12 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04570; Thu, 6 May 1993 19:03:53 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA15650; Thu, 6 May 1993 12:03:52 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: ww-talk@nxoc01.cern.ch
Subject: The official WWW Hand Gesture
Cc: wdueber@cs.indiana.edu, tloos@cs.indiana.edu
Date: Thu, 06 May 1993 12:02:29 -0500
Message-Id: <15540.736707749@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu
Resent-To: www-talk@nxoc01.cern.ch
Resent-Date: Thu, 06 May 1993 12:03:51 -0500
Resent-Message-Id: <15647.736707831@moose.cs.indiana.edu>
Resent-From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>

Discovered by accident earlier today....

Hold your hand (the right one works best) up, and curl your pinky
down.  Three fingers are now sticking up.

Spread them apart (if you keep them together, you look like a Boy Scout.)

Now, it makes the letter "W" stand out reasonably clearly.  Plus,
you're sticking up 3 fingers, so it represents the number 3.  So it's
a W!  It's a 3!  It's W3!  What more could anybody possibly ask for in
an official WWW hand gesture?

Someobdy needs to develop a secret WWW handshake based on this.

- Marc

--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
Life is like a sewer.  What you get out of it depends on what you put
into it.
		- Tom Lehrer

From timbl@www3.cern.ch  Thu May  6 18:43:13 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01119; Thu, 6 May 93 18:43:13 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04578; Thu, 6 May 1993 19:03:55 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA18296; Thu, 6 May 93 18:59:40 +0100
Date: Thu, 6 May 93 18:59:40 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305061759.AA18296@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: aronsson@lysator.liu.se
Subject: forwarded... [Explicit Linking is Impossible]
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Wed, 5 May 1993 23:24:26 +0200
> From: aronsson@lysator.liu.se

> [..]  If the destination document is maintained by someone else, he
> should be notified that I have a link going there, so he doesn't
> rename or reorganize his document without notifying me again.

In HTTP there is another SBNIBAYAFAIK feature that the client can
quote the "referee" (ie link source) when following a link. The
features is designed to allow backward links to be built up as the
forward links are followed.

> Date: Thu, 6 May 1993 01:21:40 +0200
> From: aronsson@lysator.liu.se

 

> What exactly does "pre-load a search" mean, and how do I implement
> this in an HTML document?

If there exists an index which covers the area (like if I got around
to WAIS-idnexing all of that, you would quote something like

	http://info.cern.ch/hypertext?style

and point the reader at the results of a wais serach for style in
the database.

> What if Tim and his WWW service moves from CERN to a new place?   
What
> if Tim decides to rename "WWW/Provider/Style" to "WWWSTYLE.DIR"?

	A big difference between the http deamon and the ftp daemon
	is the document name to filename mapping. Though I wish
	I had named the documents "/InformationSystems..." rather
	than "/hypertext", I won't change the document names even
	if I move the files. I will write a server which maps the  
document names into their new places. In fact, already you are
	spared making references to
	"/Net/dxcern/userd/timbl/hypertext..." thanks to the
	mapping.  Look at the mapping as a local name server so that
	within the server the path is in fact a name not an address.

	[Of course filenames aren't addresses either. I wouldn't like
	to have to count how many mappings occur before we get to
	the disk track/sector/cylinder numbers.]

> If someone can pull this rug, why should I stand on it?


	If I want to, I cn turn the server off. But I don't want to.
	It is in my interests to maintain the pointers.
	
> I would be happier to refer to an ISBN number, because then I only
> specify the publisher, and not the library where I found the book,  
and
> there would be an organization for registering new ISBN numbers  
that
> would stop an author from changing a documents name.

Have you joined uri@bunyip.com to talk about naming and addressing
of document resources?  If not, you might like to. Mail uri-request  
of course not the list.

Tim

From TONYJ@scs.slac.stanford.edu  Thu May  6 19:28:03 1993
Return-Path: <TONYJ@scs.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01798; Thu, 6 May 93 19:28:03 MET DST
Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11737; Thu, 6 May 1993 19:48:44 +0200
Date: Thu, 6 May 1993 10:48 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: Newsgroup forming?
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Message-Id: <8473CA6BD8E00273@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: timbl@nxoc01.CERN.CH, www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"timbl@nxoc01.CERN.CH"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

What will be the relationship between www-talk and 
comp.infosystems.www once it is formed. Will the newsgroup replace 
www-talk?...or should both continue? It the latter then what is the 
difference in their purpose, or should we just cross-post everything?

TonyJ

From jgrass@cnri.reston.va.us  Thu May  6 20:01:55 1993
Return-Path: <jgrass@cnri.reston.va.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02629; Thu, 6 May 93 20:01:55 MET DST
Received: from CNRI.Reston.VA.US by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18579; Thu, 6 May 1993 20:22:37 +0200
Received: from kelso.cnri.reston.va.us by CNRI.Reston.VA.US id aa18205;
          6 May 93 14:17 EDT
To: www-talk@nxoc01.cern.ch
Subject: Re: Newsgroup forming? 
In-Reply-To: Your message of "Thu, 06 May 1993 10:48:00 PDT."
             <8473CA6BD8E00273@SCS.SLAC.STANFORD.EDU> 
Date: Thu, 06 May 1993 14:14:21 -0400
From: "Judith E. Grass" <jgrass@cnri.reston.va.us>
Message-Id:  <9305061417.aa18205@CNRI.Reston.VA.US>


TONYJ@scs.slac.stanford.edu asks...
>>	What will be the relationship between www-talk and 
>>	comp.infosystems.www once it is formed. Will the newsgroup replace 
>>	www-talk?...or should both continue? It the latter then what is the 
>>	difference in their purpose, or should we just cross-post everything?

Well, consider that some of us don't have access to Usenet and the
news groups, so if the mailing list disappears, we disappear. (Believe it
or not, CNRI... home of the Internet Society is one such place).

		-- Judy Grass,  Corp. for National Research Initiatives



From putz@parc.xerox.com  Thu May  6 20:06:51 1993
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02753; Thu, 6 May 93 20:06:51 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18854; Thu, 6 May 1993 20:27:32 +0200
Received: from spoggles.parc.xerox.com ([13.1.102.87]) by alpha.xerox.com with SMTP id <11637>; Thu, 6 May 1993 11:27:02 PDT
Received: by spoggles.parc.xerox.com id <2445>; Thu, 6 May 1993 11:26:55 -0700
Date: 	Thu, 6 May 1993 11:26:42 PDT
Sender: Steve Putz <putz@parc.xerox.com>
From: Putz.parc@xerox.com
Subject: Re: Newsgroup forming?
In-Reply-To: <8473CA6BD8E00273@SCS.SLAC.STANFORD.EDU>
To: Tony Johnson <TONYJ@scs.slac.stanford.edu>
Cc: www-talk@nxoc01.cern.ch
Message-Id: <93May6.112655pdt.2445@spoggles.parc.xerox.com>

I look forward to reading comp.infosystems.www INSTEAD of www-talk.
I hope to be able to unsubscribe from www-talk (unless the amount
of traffic on it goes way down).

Steve Putz
Xerox PARC

From pandora@fernwood.mpk.ca.us  Thu May  6 20:52:02 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03691; Thu, 6 May 93 20:52:02 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28058; Thu, 6 May 1993 21:12:39 +0200
Received: by fernwood.mpk.ca.us; id AA02259; Thu, 6 May 93 11:52:27 -0700
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: Re: The official WWW Hand Gesture
Organization: Pandora Systems
Date: Thu, 6 May 1993 18:41:42 GMT
Message-Id: <C6MBxI.Iu6@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL9]
References: <15540.736707749@moose.cs.indiana.edu>
Apparently-To: www-talk@nxoc01.cern.ch

At IETF last month we came up with the official hand gesture for
Internet, Combining the symbol for i, the symbol for net, and the symbol
for friends, it is formed by hooking the two pinkys together. 

(Do I have it right Tim?)

- Mitra


From pandora@fernwood.mpk.ca.us  Thu May  6 20:54:45 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03754; Thu, 6 May 93 20:54:45 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28188; Thu, 6 May 1993 21:15:17 +0200
Received: by fernwood.mpk.ca.us; id AA02377; Thu, 6 May 93 11:54:08 -0700
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: Re: Newsgroup forming?
Organization: Pandora Systems
Date: Thu, 6 May 1993 18:44:31 GMT
Message-Id: <C6MC28.J0G@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL9]
References: <8473CA6BD8E00273@SCS.SLAC.STANFORD.EDU>
Apparently-To: www-talk@nxoc01.cern.ch

I vote to link the newsgroup and mailing list, the wais discussion has
become far less usefull now it is spread over the list wais-talk and the
group comp.infosystems.wais, not to mention two (or maybe three) z39.50
mailing lists.

- Mitra


From raisch@ora.com  Thu May  6 21:28:31 1993
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04482; Thu, 6 May 93 21:28:31 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04007; Thu, 6 May 1993 21:49:11 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA15856; Thu, 6 May 1993 15:49:08 -0400
Date: Thu, 6 May 1993 15:47:59 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Re: Explicit Linking is Impossible
To: timbl@nxoc01.cern.ch
Cc: drmacro@ralvm13.vnet.ibm.com, www-talk@nxoc01.cern.ch
In-Reply-To: <9305061729.AA18254@www3.cern.ch>
Message-Id: <Pine.3.03.9305061558.G18320-8100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hmmm... If we assume a write-only document universe, doesn't this deal with
this problem?  All published links become PUBLIC until deprecated.  </rr>



From raisch@ora.com  Thu May  6 22:37:20 1993
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06015; Thu, 6 May 93 22:37:20 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18929; Thu, 6 May 1993 22:58:00 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA24208; Thu, 6 May 1993 16:57:58 -0400
Date: Thu, 6 May 1993 16:57:40 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Sender: Rob Raisch <raisch@ora.com>
Reply-To: Rob Raisch <raisch@ora.com>
Subject: Re: Explicit Linking is Impossible
To: timbl@nxoc01.cern.ch, drmacro@ralvm13.vnet.ibm.com,
        www-talk@nxoc01.cern.ch
In-Reply-To: <Pine.3.03.9305061558.G18320-8100000@ruby.ora.com>
Message-Id: <Pine.3.03.9305061614.K18320-9100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Thu, 6 May 1993, Rob Raisch wrote:

> 
> Hmmm... If we assume a write-only document universe, doesn't this deal with
> this problem?  All published links become PUBLIC until deprecated.  </rr>
> 
> 

I seem to have meant to say, "....assume a write-once, read mostly document
universe..."

Thanks for pointing that out.  </rr>









From wmperry@mango.ucs.indiana.edu  Fri May  7 00:39:22 1993
Return-Path: <wmperry@mango.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07767; Fri, 7 May 93 00:39:22 MET DST
Received: from mango.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12423; Fri, 7 May 1993 01:00:04 +0200
Message-Id: <9305062300.AA12423@dxmint.cern.ch>
Received: by mango.ucs.indiana.edu
	(5.65c/9.4jsm) id AA19652; Thu, 6 May 1993 18:00:02 -0500
Date: Thu, 6 May 1993 18:00:02 -0500
From: "William M. Perry" <wmperry@mango.ucs.indiana.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: Release .3b of The WWW Browser For Emacs

Hey folks,
  Its time to announce yet another release of my World Wide Web
browser for emacs.  This will be the last release for a while, as I am
contemplating a major rewrite as an independent project for school.
(Better image support, real parser, et al)
  
  The files can be gotten from:
file://moose.cs.indiana.edu/pub/elisp/w3/w3.tar.Z  for the main files
file://moose.cs.indiana.edu/pub/elisp/w3/extras.tar.Z for the support files
file://moose.cs.indiana.edu/pub/elisp/w3/DOCS.[dvi|ps] for some documentation

  If you'd just like to check out the documentation, look at:
http://moose.cs.indiana.edu:80/elisp/w3/docs.html - it is the start of a
documentation tree for the browser.  I'm also working on a latexinfo
version of the documentation, but its slow going. :)

  As always, happy emacsing, and please send me a mail message if you pick
up the package.  Also, please mail any and all bug reports/fixes and URLS
that break my browser to wmperry@indiana.edu - I'll try to get back to you
as soon as possible.

Thanks,
   Bill P.

-------------------------------------------------------------------------------

  I'm calling this .3b - here is a list of the major changes from the last
public release (.1?b or some such):

Mon May  3 08:16:35 1993  William M. Perry  (wmperry@indiana.edu)
* Can now print the url under point - no key binding yet.
* Added the ability to store a gopher link into the hotlist - thanks
  to scott snyder <snyder@fnald0.fnal.gov> for patching gopher-mode to
  support this.  No key binding yet.
* Added the 'links' menu back into lucid emacs.

Fri Apr 30 11:56:57 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed a problem with viewing local files with w3-viewer-alist

Thu Apr 29 11:43:13 1993  William M. Perry  (wmperry@indiana.edu)
* w3-fetch now defaults to the url of the current document if the
  document you invoke it from is in w3-mode.
* Added ability to find links of just #link - doesn't need to reload
  the whole document.
* Applied several patches fro Alastair Burt (burt@dfki.uni-kl.de)
  * Better updating of menu bar in Lucid
  * Updates the interal w3-hotlist when you delete a hotlist entry
  * Problem with the w3-viewer-alist - it tried to play
    Something.Thesaurus
* Fixed problems with w3-graphics-converter-alist, and lots of
  problems with the w3-hypertext-extns.
* Fixed problem with finding files for dired-mode - would still try to
  do the viewing, etc.

Wed Apr 28 07:23:56 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed problem with dired-ing remote ftp files.  Removed lots of
  useless if file-directory-p [...], and just did a find-file - let
  ange-ftp and dired take care of it - they know how better.
* Fixed problem where w3-epoch-frob-resources would not set the
  defaults if no Xresources were specified - thanks to Luis Miguel
  Silveira (lms@rle-vlsi.mit.edu) for noticing it.
* Changed the w3-delimit-links variable so that you can specify
  'linkname as its value, and have the old style "Link text
  here[link#here]" style of showing links.  Nil shows nothing,
  non-nil, non-linkname shows [[ & ]] around link text.

Tue Apr 27 15:37:18 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed problem in gopher handling - if no port was specified, it
  would get completely confused.

Mon Apr 26 17:06:33 1993  William M. Perry  (wmperry@indiana.edu)
* v.2b
* Fixed problem with putting remote dirs into dired-mode with a bad
  default-filename.  Thanks to Larry Masinter
  (masinter@parc.xerox.com) for noticing, and for the fix.
* Added newest nntp.el to the extras tar file
* Fixed problem where w3-current-last-buffer was not set correctly
  when reading news.
* Added support for news: links - single articles as well as whole
  groups are supported.

Sun Apr 25 15:36:55 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed recursive make install bug - thanks to Larry Masinter
  (masinter@parc.xerox.com) for noticing it.
* Fixed problem with no default gopher object type.  Thanks to Larry
  Masinter (masinter@parc.xerox.com) for noticing it.
* Fixed problem with no default gopher port.
* Fixed the auto-documenter so that it would insert "M-x <funcname>"
  if no bindings were found in the keymap. Thanks to Larry Masinter
  (masinter@parc.xerox.com) for noticing it.
* Fixed problem with w3-file not passing to a viewer correctly.

Thu Apr 22 13:22:53 1993  William M. Perry  (wmperry@indiana.edu)
* Fixed the handling of URL#link finding . . . depends on which
  emacs you are using, due to the weirdness of zones, etc, in each.
* Split the files up again.  Figure with >2000 lines, it should be
  done. :)
* No longer need w3-links-list - store all relevant information in the
  data segment of a zone.  Changed every function to use this new
  structure.

Wed Apr 21 08:24:35 1993  William M. Perry  (wmperry@indiana.edu)
* Added variables w3-use-html2latex, w3-html2latex-prog, and
  w3-html2latex-args.  If w3-use-html2latex is non-nil, then
  w3-html2latex-prog is called in a subprocess with the flags defined
  by w3-html2latex-args, with the html source as standard input.
  Default is to do my (bad) regular expression matching to convert.

Tue Apr 20 08:51:19 1993  William M. Perry  (wmperry@indiana.edu)
* Can now specify regular expressions as the car of
  w3-viewer-assoc-list 
* fixed problem where epoch would not defvar the styles - just moved
  them out of w3-epoch-frob-resources, and it works.  Weird.
* Fixed several bugs in the w3-convert-html-to-latex function - now
  handles addresses and &amp; correctly.
* Fixed yet another dumb bug in the insertion of <PLAINTEXT> in
  non-hypertext documents.
* Added w3-member, instead of builtin (or predefined) member, since
  some definitions don't use equal for comparison like they are
  supposed to.

-- William M. Perry (wmperry@indiana.edu) --
'Who finds a thought that enables him to obtain a slightly deeper glimpse into
 the eternal secrets of nature has been given great grace.'
    - Albert Einstein

From timbl@www3.cern.ch  Fri May  7 09:19:00 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12968; Fri, 7 May 93 09:19:00 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13420; Fri, 7 May 1993 09:39:43 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA18793; Fri, 7 May 93 09:35:26 +0100
Date: Fri, 7 May 93 09:35:26 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305070835.AA18793@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Cynthia Clark <cclark@cnri.reston.va.us>, mitra@pandora.sf.ca.us,
        clw@merit.edu
Subject: Re: The official WWW Hand Gesture
Cc: www-talk@nxoc01.cern.ch, wdueber@cs.indiana.edu, tloos@cs.indiana.edu
Reply-To: timbl@nxoc01.cern.ch


> From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
> To: ww-talk@nxoc01.cern.ch
> Date: Thu, 06 May 1993 12:02:29 -0500
> 

> Discovered by accident earlier today....
> 

> Hold your hand (the right one works best) up, and curl your pinky
> down.  Three fingers are now sticking up.
> 

> Spread them apart (if you keep them together, you look like a Boy  
Scout.)
> 

> Now, it makes the letter "W" stand out reasonably clearly.  Plus,
> you're sticking up 3 fingers, so it represents the number 3.  So  
it's
> a W!  It's a 3!  It's W3!  What more could anybody possibly ask for  
in
> an official WWW hand gesture?
> 

> Someobdy needs to develop a secret WWW handshake based on this.
> 

> - Marc

	This reminds me of the IETF meeting (resaurant BOF) at
	which the official sign language sign for "Internet" was
	constructed.  It was based on the "I" sign  (little finger
	of main hand only up?) and included suggestions of "wire"
	(two little fingers meeting in the middle tip to tip
	in a straight line?) and "friend" (two little fingers
	linked). It was something like little fingers tip to tip
	rotated back and forth one against the other.
	I may have got this all wrong -- Cynthia you
	can correct me.  I don't know whether it made it to RFC
	status yet.
	
	As for WorldWideWeb,  it sounds like it matches similar
	criteria.  It is based on W (middle three fingers only
	up, palm away from you). I don't know what "3" is.
	(Three fingers together?)
	Maybe to distinguish "WorldWideWeb" from "W" it has to be
	be modified a bit -- perhaps the three fingers of one
	hand (W) meeting the three fingers of the other hand (3)
	reminicent of Internet, connection, wire.  If something
	suggesting "knowlegde" and/or sharing could be snuck in
	there then that would be all the better. Is the sign for
	"W" backwards (palm toward you) already taken?
	
	Cynthia: WWW is an information-sharing system for the
	Internet, in case you haven't come across it (which I hope
	you will, as I'd like to see all the Internet Drafts and RFCs
	available on it.)
	
	Tim Berners-Lee

	

From marca@wintermute.ncsa.uiuc.edu  Fri May  7 12:38:23 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14781; Fri, 7 May 93 12:38:23 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28255; Fri, 7 May 1993 12:59:04 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05863
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 7 May 93 05:58:53 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:uri@bunyip.com id AA16795; Fri, 7 May 93 06:01:16 -0500
Date: Fri, 7 May 93 06:01:16 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305071101.AA16795@wintermute.ncsa.uiuc.edu>
To: aronsson@lysator.liu.se
Cc: uri@bunyip.com, www-talk@nxoc01.cern.ch
Subject: Re:  Spaces or %20 in URLs
In-Reply-To: <9305070626.AA09710@rudolf.lysator.liu.se>
References: <9305070626.AA09710@rudolf.lysator.liu.se>

aronsson@lysator.liu.se writes:
>     Yesterday night, I scanned the entire World-Wide Web (well,
> almost) to find out something about this.  All I found was that WWW
> URLs exist and URNs probably do not.  Are the other names (URI, UDI,
> DocIDs) synonyms for URLs?  Is there an easy explanation to this
> confusion?

Some materials are in...

        ftp://sifon.cc.mcgill.ca/pub/Network/uri

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Fri May  7 15:32:30 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17410; Fri, 7 May 93 15:32:30 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09298; Fri, 7 May 1993 15:53:13 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA19208; Fri, 7 May 93 15:48:56 +0100
Date: Fri, 7 May 93 15:48:56 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305071448.AA19208@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: PUBLIC DOMAIN CERN WWW SOFTWARE
Cc: iiir@merit.edu, Library of the Future <virtual@indycms.bitnet>,
        wbroad@nysernet.org, LIBREF <LIBREF-L@kentvm.bitnet>,
        lis-link@mailbase.ac.uk, MegaByte University <MBU-L@ttuvm1.bitnet>,
        Network Trainers Discussion List <NETTRAIN@ubvm.cc.buffalo.edu>,
        nir@mailbase.ac.uk, CWIS-L%WUVMD.BITNET@cearn.bitnet,
        Public-Access Computer Systems Forum <PACS-L@uhupvm1.bitnet>,
        unite@mailbase.ac.uk, uri@bunyip.com, wg-isus@rare.nl
Reply-To: timbl@nxoc01.cern.ch




	World-Wide Web Software Put Into Public Domain
	===============================================

A declaration that the basic World-Wide Web software from CERN is in  
the public domain has been signed by H. Weber, CERN's Director for  
Administration and W. Hoogland, Director for Computing.

The declaration, signed on 30 April 1993, makes it clear that this
is not a precedent for CERN software. It states, "CERN's intention
is to further compatibility, common practices, and standards in
networking and computer supported collaboration."

The declaration covers the "libwww" common code library, the line  
mode browser (www) and the W3 server (httpd).

The World-Wide Web (W3) is a global information system with a
easy point-and click interface. It provides access to almost all
existing Internet-based information as well as a whole new world
of data presented to the user as multimedia hypertext.  By a sequence  
of hypertext jumps and text searches, anyone can find his way though  
the mass of information available all over the world.

The High Energy Physics community, of which CERN is a European  
center, already uses W3 extensively.  In all there are more than 70
servers around the world providing data using special W3 protocols,
including such diverse areas as hypertext of US law from the Legal  
Information Institute at Cornell University, to the "Thesaurus  
Linguarum Hiberniae" collection of medaeval Irish manuscripts from  
University College, Cork.

Software for making servers is part of that put into the public  
domain by CERN. The other part is the "client" software which allows
the reader to move seamlessly through this data and also all the  
existing data on servers using existing "FTP", "WAIS", "Gopher", and
network news protocols. There are more than 14 different client  
programs for different computing platforms, written by people from
institues in many countries.  "The existence of a common, public  
domain kernel of software to handle the protocols will ensure
compatibility, and prevent people having to 'reinvent the wheel'",
says CERN's Tim Berners-Lee, W3's creator.

The W3 project is a success story of international collaboration.
The National Center for Supercomputer Applications (NCSA) in
Illinois have been a powerful force, producing a popular "Mosaic"
client for workstations, and other contributions have come from many
other universities throughout the world.  In the US, the Web is seen  
as an answer to the Clinton administration's call for a National  
Information Infrastructure. It is growing fast. "Traffic we see on  
our CERN server has more than doubled every four months for the last  
two years", says Berners-Lee, "and of course there is a new server  
every few days".

"With the Web, we are sharing knowledge," says Berners-Lee, "without
discrimination as to who or where in the world you are."  The W3
developers look forward to a time when the Internet, and so the Web,  
will be accessible from homes and high schools anywhere.  As well as  
an opening up of research centers and government, they are looking  
for a sharing of ideas and educational material for all tastes and  
ages.

Ends.


__________________________________________________________________

Tim Berners-Lee                       timbl@info.cern.ch
World Wide Web team leader	
CERN, CN Division                     Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155




From jpowell@borg.lib.vt.edu  Fri May  7 16:57:33 1993
Return-Path: <jpowell@borg.lib.vt.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19688; Fri, 7 May 93 16:57:33 MET DST
Received: from borg.lib.vt.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29298; Fri, 7 May 1993 17:18:16 +0200
Received: by borg.lib.vt.edu (NX5.67c/NX3.0M)
	id AA04928; Fri, 7 May 93 11:16:37 -0400
Date: Fri, 7 May 93 11:16:37 -0400
From: James Powell <jpowell@borg.lib.vt.edu>
Message-Id: <9305071516.AA04928@borg.lib.vt.edu>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: volunteer to proof a paper for technical accuracy

I'm writing an article which I plan to submit to a library/computing journal  
such as _Online_ or _Computers in Libraries_ for publication.  The working  
title of the article is "Adventures in Hypertext: Creating an electronic  
hypertext library."  I'd like to find one or two people who would proofread the  
paper for technical accuracy.  Contact me via e-mail if interested.  Thanks.

---
James Powell >>> Library Automation, University Libraries, VPI&SU
             >>> JPOWELL@VTVM1.CC.VT.EDU 

	     >>> jpowell@borg.lib.vt.edu - NeXTMail welcome here
	     >>> Owner of VPIEJ-L, a discussion list for Electronic
	     >>> Journals

From germuska@antioch.acns.nwu.edu  Fri May  7 17:42:59 1993
Return-Path: <germuska@antioch.acns.nwu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20793; Fri, 7 May 93 17:42:59 MET DST
Received: from antioch.acns.nwu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11696; Fri, 7 May 1993 18:03:43 +0200
Received: by antioch.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA08105; Fri, 7 May 93 11:03:33 CDT
From: germuska@antioch.acns.nwu.edu (Joe Germuska)
Message-Id: <9305071603.AA08105@antioch.acns.nwu.edu>
Subject: Informal Server Announcement
To: www-talk@nxoc01.cern.ch
Date: Fri, 7 May 1993 11:03:32 -0500 (CDT)
Reply-To: j-germuska@nwu.edu (Joe Germuska)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1773      

This is a rather informal announcement of a rather informal web-server,
located at http://www.acns.nwu.edu/

I'm running the NCSA .3(beta) release of httpd, and have gotten the feeling
that non-Mosaic products don't get along all that well with it, but that's
one reason why I'm announcing -- to find out how true that is.  But I use
XMosaic, and have some inlined images and stuff -- that's really the
platform I'm creating for.

Of course, the real reason I'm announcing is that I want people to come
over and visit and tell me what they think!  Like I said, very informal,
but I could use some feedback about how things work and look...

Currently, we have:
* a sprouting collection of Jazz information grepped from
	rec.music.bluenote
* the SURFPUNK Technical Journal archives
* the space where the BLINK electronic journal archives will be  (our first
	issue goes out next week)

I'm also talking to Pete Ashdown, author of the XDZebra Techno Music
reviews about hypertexting and presenting his back-issues and future
stuff...  And, if anyone else has stuff they've been wanting to see
archived, and I find it interesting enough to stare at for hours of
hypertexting, we might make something of it...

Most of the files aren't very hyper-text-y yet, but as I find time and get
ideas, I'll work on it -- if any of you see ideas for good links or other
structural things, I'd appreciate word...

Thanks,
	Joe Germuska
	Administrator, www.acns.nwu.edu W3 server


-- 
joe germuska | j-germuska@nwu.edu | Network Response Center
ACNS-Distributed Systems Services, Northwestern University
Ceci n'est pas une signature.

-- 
joe germuska | j-germuska@nwu.edu | Network Response Center
ACNS-Distributed Systems Services, Northwestern University
Ceci n'est pas une signature.

From bobs@sco.com  Fri May  7 17:53:54 1993
Return-Path: <bobs@sco.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21036; Fri, 7 May 93 17:53:54 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14096; Fri, 7 May 1993 18:14:36 +0200
Received: by mcsun.EU.net via EUnet
	id AA06507 (5.65b/CWI-2.217); Fri, 7 May 1993 18:14:34 +0200
Received: from sco.sco.COM by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20968; Fri, 7 May 93 12:08:14 -0400
Received: from scotty.sco.COM by sco.sco.COM
	id aa07498; Fri, 7 May 93 9:09:23 PDT
From: Bob Stayton <bobs@sco.com>
X-Mailer: SCO System V Mail (version 3.2)
To: www-talk@nxoc01.cern.ch
Subject: subscribe
Date: Fri, 7 May 93 9:07:15 PDT
Message-Id:  <9305070907.aa17830@scotty.sco.COM>
Source-Info:  From (or Sender) name not authenticated.

Please add me to the www-talk subscription. Thanks.

bobs
Bob Stayton                                 425 Encinal Street
Technical Publications                      Santa Cruz, CA  95060
The Santa Cruz Operation, Inc.              (408) 425-7222
                                            ...!uunet!sco!bobs
Little known fact:
"Since communism has lost all intellectual respectibility,
except on U.S. college campuses, it has been repackaged
under the name of environmentalism"

    - Creators Syndicate columnist Walter Williams as printed
      in the Indianapolis Star, 26 Dec 91.

From murphy@dccs.upenn.edu  Fri May  7 19:07:14 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22698; Fri, 7 May 93 19:07:14 MET DST
Received: from NOC2.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29755; Fri, 7 May 1993 19:27:57 +0200
Received: from LAM.DCCS.UPENN.EDU by noc2.dccs.upenn.edu
	id AA27322; Fri, 7 May 93 13:27:55 -0400
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA23826; Fri, 7 May 93 13:27:52 -0400
Date: Fri, 7 May 93 13:27:52 -0400
From: murphy@dccs.upenn.edu
Posted-Date: Fri, 7 May 93 13:27:52 -0400
Message-Id: <9305071727.AA23826@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch, gopher-news@boombox.micro.umn.edu
Subject: The gateway to Whois servers
Reply-To: murphy@scotty.dccs.upenn.edu


I have a question about the gateway to whois, the items in this gopher
menu: gopher.tc.umn.edu 70 1/Phone Books/WHOIS Searches

The question is: Does the use of this gateway really have to _double_
the usage of a Whois server?  I've noticed that for many months now,
the SAME EXACT query would come into the Penn whois server within
seconds of each other, but from two different hosts.

Between approximately 11:44 AM and 12:54 PM (a little over an hour)
today, the log shows these lines (as well as a bunch of others which
were all from on-campus hosts, so I've omitted them):

736789471    1     1     3  morrison             GOPHER.ND.EDU
736789477    2     1     3  morrison             MOZART.HELIOS.ND.EDU
736790867    1     3     1  williams, scott      GOPHER.ND.EDU
736790870    1     3     1  williams, scott      LAFCOL.LAFAYETTE.EDU
736790903    2     1     1  chance               GOPHER.ND.EDU
736790905    1     1     1  chance               LAFCOL.LAFAYETTE.EDU
736790930    2     3     0  smith, amos          GOPHER.ND.EDU
736790933    1     3     0  smith, amos          LAFCOL.LAFAYETTE.EDU
736791061    2     1     0  Alstair Ling         GOPHER.ND.EDU
736791078    4     1     0  Alstair Ling         ERNIE.PRINCETON.EDU
736791110    2     1     2  Ling                 GOPHER.ND.EDU
736791114    1     1     2  Ling                 ERNIE.PRINCETON.EDU
736793362    2     1     0  anthropology         GOPHER.ND.EDU
736793369    2     1     0  anthropology         ARX.ADP.WISC.EDU
736793606    2     1     2  keane                GOPHER.ND.EDU
736793609    1     1     2  keane                WINGRA.ADP.WISC.EDU
736793694    1     1     0  philadelphia         GOPHER.ND.EDU
736793697    1     1     0  philadelphia         WINGRA.ADP.WISC.EDU
 
Using Whois servers in this fashion is quite inefficient, and
irresponsible.  At the moment, whois queries are not terribly
expensive for us, but if they were, the gateway usage of this machine
would be crushing our server.  Please explain why the gateway behaves
so strangely, and what plans there are to fix this problem.

--lam

From brian@eitech.com  Fri May  7 20:01:14 1993
Return-Path: <brian@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23693; Fri, 7 May 93 20:01:14 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11474; Fri, 7 May 1993 20:21:57 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA29767; Fri, 7 May 93 13:21:50 -0500
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA06721; Fri, 7 May 93 11:17:02 PDT
Date: Fri, 7 May 93 11:17:02 PDT
From: brian@eitech.com (Brian Smithson)
Message-Id: <9305071817.AA06721@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: The official WWW Hand Gesture

----- Begin Included Message -----
	
	As for WorldWideWeb,  it sounds like it matches similar
	criteria.  It is based on W (middle three fingers only
	up, palm away from you). I don't know what "3" is.
	(Three fingers together?)
	Maybe to distinguish "WorldWideWeb" from "W" it has to be
	be modified a bit -- perhaps the three fingers of one
	hand (W) meeting the three fingers of the other hand (3)
	reminicent of Internet, connection, wire.  If something
	suggesting "knowlegde" and/or sharing could be snuck in
	there then that would be all the better. Is the sign for
	"W" backwards (palm toward you) already taken?
	
----- End Included Message -----

How about this:

- You hold your middle three fingers ("W" and "3") out with palm facing
  down (information source).

- Another person holds middle three fingers out with palm facing up
  (information need).

- Both people meet and interlace the fingers ("web").

- Each person holds their other hand out similarly, but with the palm facing
  in the opposite direction

- Seek out other people with which to randomly interconnect.

- Repeat until it's world-wide. :-)

-- 
-Brian Smithson
 brian@eitech.com

From paolo@venedig.ai.univie.ac.at  Fri May  7 20:18:49 1993
Return-Path: <paolo@venedig.ai.univie.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24085; Fri, 7 May 93 20:18:49 MET DST
Received: from moskau.ai.univie.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16300; Fri, 7 May 1993 20:39:27 +0200
Received: by moskau.ai.univie.ac.at id AA02255
  (5.65c8/IDA-1.4.4 for www-talk@info.cern.ch); Fri, 7 May 1993 20:38:42 +0200
From: paolo petta <paolo@venedig.ai.univie.ac.at>
Message-Id: <199305071838.AA02255@moskau.ai.univie.ac.at>
Subject: WWW-WAIS gateway for 2.05 Daemon?????
To: www-talk@nxoc01.cern.ch
Date: Fri, 7 May 1993 20:38:39 +0200
X-Mailer: ELM [version 2.3 PL11]

Ok, after a day's search, I give up:

where can I find WAISGate.c and ParseWSRC.c mentioned in the
CommonMakefile of the 2.05 daemon distribution?

(I found //info.cern.ch/hypertext/WWW/Daemon/Implementation/WAISGate.c,
but am not sure if this is the right version, and where is the
ParseWSRC bit, anyway?)

Thanks!

pAolo
-- 
paolo petta                                            +43-1-5336112(Tel)
Austrian Research Inst. for Artificial Intelligence    +43-1-5320652(Fax)
Schottengasse 3, A-1010 Vienna, Austria, Europe     paolo@ai.univie.ac.at 

From sanders@bsdi.com  Fri May  7 20:23:55 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24213; Fri, 7 May 93 20:23:55 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16532; Fri, 7 May 1993 20:44:29 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA09263; Fri, 7 May 93 13:44:19 -0500
Message-Id: <9305071844.AA09263@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Another click-on-an-image demo is available
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 07 May 1993 13:44:19 -0500
From: Tony Sanders <sanders@bsdi.com>

This one is a bit more practical than the astronaut.  It puts up a little
book icon at the bottom of the page and you can use it to select UP,
FORWARD, or BACK in the text.  To be fully functional (so it knows were
you clicked on the icon) you need the xmosaic-1.0-image-hack patches
available from the demo page.

I'm thinking about how to do auto-indexing because there is no point in
doing this by hand (esp with my weird syntax for this).  It'll probably
be database driven with an HTML+ interperter in the server that takes
something like
>>>INDEX_ME<<<
in the document and sticks the index info there.  Any thoughts?  My
next project towards this goal is file type mapping in &send_file;
so it'll take foo.xxx and run it through a specified filter that
converts it to html (for dumping databases, doing interpreted menus,
and on the fly indexing).

The demo is at:

http://www.bsdi.com/demo/bookmark/index.html

The code is http://www.bsdi.com/server/bookmark.pl
The image data is http://www.bsdi.com/images/bookmark/

I haven't documented this in the server docs yet.  I will before 1.1.

Enjoy!

--sanders@bsdi.com

From gehmeyr@forwiss.uni-passau.de  Mon May 10 10:18:21 1993
Return-Path: <gehmeyr@forwiss.uni-passau.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18572; Mon, 10 May 93 10:18:21 MET DST
Received: from forwiss.uni-passau.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09744; Mon, 10 May 1993 10:39:07 +0200
Received: from aragorn.forwiss.uni-passau.de (aragorn) by forwiss with SMTP id AA26883
  (5.65c+/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Mon, 10 May 1993 10:39:01 +0200
Received: by aragorn.forwiss.uni-passau.de id AA06335
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Mon, 10 May 1993 10:38:43 +0200
From: Andreas Gehmeyr <gehmeyr@forwiss.uni-passau.de>
Message-Id: <199305100838.AA06335@aragorn.forwiss.uni-passau.de>
Subject: Whole Internet
To: www-talk@nxoc01.cern.ch
Date: Mon, 10 May 1993 10:38:42 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 366       

Has anyone written down the references (using HTML) in Chapter "Resources on the Internet" in "The whole Internet", written by Ed Krol (nutshell handbook)?
If so, where could I get it?
Thanx,
Andi 
-- 
 "I have something to say:       |      Andreas Gehmeyr, FORWISS Passau
  It's better to burn out,       |      gehmeyr@forwiss.uni-passau.de
  than to fade away!"

From gehmeyr@forwiss.uni-passau.de  Mon May 10 10:45:06 1993
Return-Path: <gehmeyr@forwiss.uni-passau.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18769; Mon, 10 May 93 10:45:06 MET DST
Received: from forwiss.uni-passau.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01578; Mon, 10 May 1993 11:05:28 +0200
Received: from aragorn.forwiss.uni-passau.de (aragorn) by forwiss with SMTP id AA27139
  (5.65c+/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Mon, 10 May 1993 11:04:59 +0200
Received: by aragorn.forwiss.uni-passau.de id AA06381
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Mon, 10 May 1993 11:04:42 +0200
From: Andreas Gehmeyr <gehmeyr@forwiss.uni-passau.de>
Message-Id: <199305100904.AA06381@aragorn.forwiss.uni-passau.de>
Subject: The Whole Internet - Resource?
To: www-talk@nxoc01.cern.ch
Date: Mon, 10 May 1993 11:04:41 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 368       


Has anyone written down the references (using HTML) in Chapter "Resources on the Internet" in "The whole Internet", written by Ed Krol (nutshell handbook)?
If so, where could I get it?
Thanx,
Andi 
-- 
 "I have something to say:       |      Andreas Gehmeyr, FORWISS Passau
  It's better to burn out,       |      gehmeyr@forwiss.uni-passau.de
  than to fade away!"


From dsr@hplb.hpl.hp.com  Mon May 10 18:08:52 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25638; Mon, 10 May 93 18:08:52 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12605; Mon, 10 May 1993 18:29:40 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 10 May 93 17:22:55 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA06565; Mon, 10 May 93 17:30:43 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305101630.AA06565@manuel.hpl.hp.com>
Subject: Does anyone use <BLOCKQUOTE>?
To: www-talk@nxoc01.cern.ch
Date: Mon, 10 May 93 17:30:42 BST
Mailer: Elm [revision: 66.36.1.1]

I am drafting an extended verion of the HTML standard and would
like to know if anyone is using the <BLOCKQUOTE> element for quoted
paragraphs. This element has a name greater than 8 characters
which could cause problems with some SGML parsers.

Would anyone object if we changed the tag name to "QUOTE" ?

Cheers,

Dave Raggett

From jfg@lsd.ch  Mon May 10 18:21:56 1993
Return-Path: <jfg@lsd.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25910; Mon, 10 May 93 18:21:56 MET DST
Received: from chsun.chuug.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16476; Mon, 10 May 1993 18:42:38 +0200
Received: from lsd.ch by chsun.eunet.ch (5.65c8/1.34)
	id AA04625; Mon, 10 May 1993 18:42:51 +0200
Received: from prospero by lsd.ch (NX5.67c/NeXT-2.0)
	id AA00876; Mon, 10 May 93 10:52:10 +0200
From: lsd.ch!jfg@lsd.ch (Jean-Francois Groff)
Message-Id: <9305100852.AA00876@lsd.ch>
Received: by prospero. (NX5.67c/NX3.0X)
	id AA04786; Mon, 10 May 93 10:52:08 +0200
Date: Mon, 10 May 93 10:52:08 +0200
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Interesting conf!  IANET'93 (see at end) statements due May 15!
Reply-To: Jean-Francois Groff <info.cern.ch!jfg@lsd.ch>

 I grabbed this on the wais-talk mailing list. See at end : "Research  
Workshop on Information Access and the Networks", to be held after  
the conference, on July 1st. Someone should go there to represent  
World-Wide Web. Reply quickly: statements of interest are due May 15!

------- Forwarded Message

Return-Path: fox
Date: Sat, 8 May 93 14:08:17 -0400
From: fox (Edward A. Fox)
To: nelip
Subject: interesting conference - note IANET'93 workshop, tutorials

                                  ACM
                               SIGIR '93
         16th International Conference on Research and Development 

                        in Information Retrieval 


                         Pittsburgh, PA, USA
                         June 27-July 1, 1993

                       In co-operation with ACM:
                AICA-GLIR (Italy)        BCS-IRSG (UK)
                DD (Denmark)             GI (Germany)
                            INRIA (France)

             PRELIMINARY PROGRAM AND REGISTRATION INFORMATION


       The annual ACM SIGIR conference is the primary international  
meeting
for the presentation of research and development in information  
retrieval (IR).
The conference will be valuable to those interested in the theory of  
information
retrieval as well as those responsible for system design, testing and 

evaluation.  Topics include association methods, query processing,  
data and 

file structures, DBMS integration, structured text, inference  
networks, 

interface issues,and natural language processing.

       This year the conference will be held in Pittsburgh, PA, USA,  
within 

easy reach of major east coast centers.  The city centre conference  
site 

overlooks the three rivers, providing access to parks, restaurants  
and 

shopping, cultural amenities and sporting events. 


       Pre-conference tutorials will cover both beginning and  
advanced topics.
The main program consists of contributed papers as well as panel  
sessions and
demonstrations.  There will be two post-conference research  
workshops, 

User Interfaces for Online Public Access Catalogs, and Information 

Access and the Networks.

       Conference highlights include:

Sunday     *   Tutorials
           *   Reception
Monday     *   Keynote address:  Bruce Buchanan
           *   Text REtrieval Conference (TREC) overview
Tuesday    *   Panel session: NLP for Information Management
           *   Cruise and Banquet on Pittsburgh's Three Rivers
Wednesday  *   Demonstrations
           *   Reception
Thursday   *   Post-conference research workshops:  

                  User Interfaces for Online Public Access Catalogs
                  Information Access and the Networks
                    (see details at very end of this message)
           *   Tour of Frank Lloyd Wright's Fallingwater
           *   Tour and Open House at Carnegie Mellon University

Full conference registration includes technical sessions,
proceedings, conference banquet, lunch at the SIGIR annual meeting,
and two receptions. 


Conference Organization:

Chair:             Edie Rasmussen, University of Pittsburgh

Program Chairs:    Robert Korfhage, University of Pittsburgh
                   Peter Willett,  University of Sheffield

Tutorial Chairs:   Donna Harman, National Institute of Standards and  
Technology
                   Joan Morrissey, University of Windsor

Program Committee: Ijsbrand Jan Aalbersberg - Philips Research  
Laboratories
                   Maristella Agosti - Universita' di Padova
                   Abraham Bookstein - University of Chicago
                   Christine Borgman - UCLA
                   Giorgio Brajnik - Universita' di Udine
                   Chris Buckley - Cornell University
                   Yves Chiaramella - LGI-IMAG
                   Kenneth Church - Bell Laboratories
                   Richard Fowler - University of Texas - Pan  
American
                   Ophir Frieder - George Mason University
                   Norbert Fuhr - Universitaet Dortmund
                   Michael Gordon - University of Michigan
                   Peter Ingwersen - Royal School of Librarianship,  
Copenhagen
                   Kalervo Jarvelin - University of Tampere
                   Marcia D. Kerchner - The MITRE Corporation
                   Kui Lam Kwok - Queens College, CUNY
                   D. Lucarella - CRA-ENEL
                   David Lewis - AT&T Bell Laboratories
                   Sung H. Myaeng - Syracuse University
                   Michael Nelson - University of Western Ontario
                   Kai A. Olsen - Molde College, Norway
                   A. Stephen Pollitt - University of Huddersfield
                   Lisa Rau - GE Research and Development Center
                   Stephen E. Robertson - The City University, London
                   Ernst Schuegraf - St. Francis Xavier University,  
Nova Scotia
                   Alan F. Smeaton - Dublin City University
                   Linda C. Smith - University of Illinois
                   Padmini Srinivasan - University of Iowa
                   Craig Stanfill - Thinking Machines Corporation
                   Keith van Rijsbergen - Glasgow University
                   Jean-Luc Vidick - Telinfo, Brussels


                                SIGIR '93 PROGRAM

                                    Tutorials  

                              Sunday, June 27, 1993

  AM:  Introduction to Information Retrieval
         Keith van Rijsbergen, University of Glasgow
       Developing Information Retrieval Applications using Object  
Database                

       Technology
          David J. Harper, University of Glasgow
       Trends in Multimedia Development           

          Alan Griffiths, University of Sheffield

   PM:  Natural Language Processing for Information Retrieval
          David Lewis and Elizabeth Liddy, AT&T Bell Labs. & Syracuse  
University
        Information Retrieval and Databases
          Norbert Fuhr, University of Dortmund, Germany
        Non-Textual Compression in Full-Text IR Systems
          Shmuel T. Klein, Bar-Ilan University, Israel

                              Technical Sessions
  

                              Monday, June 28, 1993

Session 1:  Keynote Address, From Data to Information: Where is the  
Knowledge?
              Bruce Buchanan, University of Pittsburgh

Session 2:  Inference Networks
              David Haines & W. Bruce Croft, Relevance Feedback and  
Inference 

                Networks
              P.D. Bruza & L.C. van der Gaag, Efficient  
Context-Sensitive 

                Plausible Inference for Information Disclosure
              Kostas Tzeras & Stephan Hartmann, Automatic Indexing  
Based on 

                Bayesian Inference Networks

Session 3:  Donna Harman, Overview of the First Text REtrieval  
Conference (TREC)

Session 4:  Full Text Analysis
              Gerard Salton, J. Allan, & Chris Buckley, Approaches to  
Passage 

                Retrieval in Full Text Information Systems
              Marti A. Hearst & Christian Plaunt, Subtopic  
Structuring for 

                Full-Length Document Access
              Chris D. Paice & Paul A. Jones, The Identification of  
Important 

                Concepts in Highly Structured Technical Papers

Session 5:  Compression & Signature Files
              A. Bookstein, S.T. Klein, and Timo Raita, Is Huffman  
Coding Dead?
              Gordon Linoff & Craig Stanfill, Compression of Indexes  
with Full 

                Positional Information in Very Large Text Databases
              Deniz Aktug & Fazli Can, Analysis of Multiterm Queries  
in a 

                Dynamic Signature File Organization

                             Tuesday, June 29, 1993

Session 6:  Association Methods
              S.K.M. Wong & Y.J. Cai, Computation of Term  
Associations by a 

                Neural Network
              Rodrigo A. Botafogo, Cluster Analysis for Hypertext  
Systems
              Douglass R. Cutting, David R. Karger, & Jan O.  
Pedersen, 

                Constant Interaction-Time Scatter-Gather Browsing of  
Very Large
                Document Collections

Session 7:  Query Expansion
              Peter G. Anick & Rex A. Flynn, Integrating a Dynamic  
Lexicon with 

                a Dynamic Full-Text Retrieval System
              Efthimis N. Efthimiadis, A user-centred evaluation of  
ranking 

                algorithms for interactive query expansion.
              Yonggang Qiu & Hans-Peter Frei, Concept Based Query  
Expansion

Session 8:  Linguistic Analysis
              Ellen M. Voorhees, Using WordNet to Disambiguate Word  
Senses for 

                Text Retrieval
              Julian Kupiec, MURAX:  A Robust Linguistic Approach for  
Question          

                Answering Using an On-Line Encyclopedia
              Robert Krovetz, Viewing Morphology as an Inference  
Process

Session 9:  Structured Text
              Michael Fuller, Eric Mackie, Ron Sacks-David, & Ross  
Wilkinson, 

                Coherent Answers for a Large Structured Document  
Collection
              Pekka Kilpelinen & Heikki Mannila, Retrieval from  
hierarchical
                texts by partial patterns

Session 10: Panel on Natural Language Processing for Information  
Management
              David Evans, Lessons from the CLARIT project
              Jaime G. Carbonell, Lessons from TIPSTER/ SHOGUN/JANUS
              Sergei Nirenburg, Lessons from PANGLOSS

Session 11: Processing for Japanese Text
              Yasushi Ogawa, Ayako Bessho, & Masako Hirose, Simple  
Word Strings
                as Compound Keywords:  An Indexing and Ranking Method  
for 

                Japanese Texts
              Hideo Fujii & W. Bruce Croft, A Comparison of Indexing  
Techniques
                for Japanese Text Retrieval

                          Wednesday, June 30, 1993

Session 12: Interface Issues
              Edward A. Fox, Robert K. France, Eskinder Sahle, Amjad  
Daoud, &
                Ben E. Cline, Development of a Modern OPAC:  From  
REVTOLC to
                MARIAN
              Daniel E. Rose, Richard Mander, Tim Oren, Dulce B.  
Poncelen, Gitta 

                Salomon, & Yin Yin Wong, Content Awareness in a File  
System
                Interface:  Implementing the 'Pile' Metaphor for  
Organizing
                Information
              Gert Schmeltz Pedersen, A Browser for Bibliographic  
Information 

                Retrieval, Based on an Application of Lattice Theory

Session 13: Mathematical Models
              Yiming Yang & Christopher G. Chute, An Application of  
Least 

                Squares Fit Mapping to Text Information Retrieval
              Joon Ho Lee, Won Yong Kim, Myoung Ho Kim, & Yoon Joon  
Lee, 

                On the Evaluation of Boolean Operators in the  
Extended
                Boolean Retrieval Framework
              Carlo Meghini, Fabrizio Sebastiani, Umberto Straccia & 

                Costantion Thanos, A Model of Information Retrieval  
based on a
                Terminological Logic

Session 14: DBMS/IR integration
              Norbert Fuhr, A Probabilistic Relational Model for the 

                Integration of IR and Databases
              Peter Schuble, SPIDER:  A Multiuser Information  
Retrieval System
                for Semistructured and Dynamic Data

Session 15: Query Processing and Evaluation
              David Hull, Evaluation and Relevance Feedback
              Nicholas J. Belkin, C. Cool, W. Bruce Croft, & James P.  
Callan, 

                Effect of Multiple Query Representations on  
Information
                Retrieval System Performance
              James P. Callan & W. Bruce Croft, Evaluation of Query  
Processing 

                Strategies Using the TIPSTER Collection

Demonstrations (concurrent with sessions)
              Coordinator: Philip J. Smith

                             Thursday, July 1, 1993                       

 

                     Post-conference research workshops: 

                                            

             User Interfaces for Online Public Access Catalogs

                    Information Access and the Networks
(see more information on this at the very end of this entire message)

                                   Tours:
            Tour and Open House at Carnegie Mellon University
                     Frank Lloyd Wright's Fallingwater

                       REGISTRATION INFORMATION 


Registration Fees:

  Conference:             Before May 15          After May 15
     ACM Members               $250.                 $275.
     Non Members                300.                  325.
     Full Time Students         100.                  110.
     One Day                    100.                  100.
   Tutorials:                   

     ACM Members                130.                  200.
     Non Members                150.                  225.
     Full Time Students         100.                  110.             

   Workshops                     50.                   50.
   Tours                         20.                   20.

Conference Hotel 


All sessions will be held at The Pittsburgh Hilton & Towers.   
Reservations 

at the conference rate ($95.00 plus tax per night for a single or  
double room)
can be made by calling 412-391-4600 (or 1-800-HILTONS within the  
U.S.), and 

asking for the Association for Computing Machinery SIGIR group rate.   
The
deadline for reservations is May 27th.  Reservations made after the  
deadline 

are subject to availability and may be billed at a higher rate.   
Cancellations
made less than 48 hours prior to arrival will incur a charge for one  
night's 

lodging. 


Air Travel to Pittsburgh

USAir has been designated the official carrier for the attendees of  
the 

conference.  USAir offers an exclusive low fare for attendees, which  
will 

offer a 5% discount off First Class and any published USAir  
promotional round
trip fare.  A 10% discount off unrestricted coach fares will apply  
with 7 day 

advance reservations and ticketing required.  These discounts are  
valid
providing all rules and restrictions are met and are applicable for  
travel 

from the Continental United States, Bahamas, Canada and San Juan, PR. 

Convention discounts are not combined with other discounts or  
promotions.  

Additional restrictions may apply on international travel.  These  
convention 

discounts are valid between June 25 and July 2, 1993.  To obtain the  
convention
discount, attendees or their travel agent should call USAir's Meeting  
and 

Convention Reservation Office at 1-800-334-8644, 8:00 a.m. to 9:00  
p.m. EST.  

Refer to gold file no. 13400020.

           FOR FURTHER PROGRAM AND REGISTRATION INFORMATION CONTACT:

                      SIGIR '93 Conference Secretariat
                  School of Library and Information Science
                         University of Pittsburgh
                         Pittsburgh, PA 15260, USA
         

                tel:  (412) 624-9459; fax: (412) 648-7001
                        email:  sigir@lis.pitt.edu

- - - - - - -- - - - - ----- - - - -- - - - - - - -  -- - - - - - --  
- 

               PRE-CONFERENCE TUTORIALS
                 Sunday, June 27, 1993

       SIGIR tutorials provide an opportunity to learn the basics
of IR or to learn about a new or specialized area from experts in
the field.  This year, six half-day tutorials are available prior
to the main program, held in parallel sessions during the morning
and afternoon.  Separate registration is required for tutorials.


             Morning Tutorials: 8:30 a.m. - 12:30 p.m.

               Introduction to Information Retrieval

            Keith van Rijsbergen, University of Glasgow

       This tutorial will enable participants to reach an
understanding of the science and engineering underlying
information retrieval research and development.  It is aimed at
anyone who wants to:
(a)    do research in IR but has little or no basic knowledge in
       the subject;
(b)    examine the state of research and development in IR for
       commercial purposes;
(c)    teach IR at advanced undergraduate or postgraduate level but
       has no prior knowledge;
(d)    think about IR but has rarely thought about it before and
       does not know where to start.
The tutorial will answer the following questions:
(a)    What is IR?
(b)    What are sensible models for IR?
(c)    How to measure things in IR.
(d)    What impact has IR research had on the existing technology? 

The tutorial will include a demonstration of a current system. 

The reward for participants a feel for the excitement of
state-of-the-art in IR!

       Keith van Rijsbergen was born in Holland in 1943.  He was
educated in Holland, Indonesia, Namibia and Australia. He took a
degree in mathematics at the University of Western Australia. As
a graduate he spent two years tutoring in mathematics while
studying computer science. In 1972 he completed a Ph.D. in
computer science at Cambridge University. After almost three
years of lecturing in information retrieval and artificial
intelligence at Monash University he returned to the Cambridge
Computer Laboratory to hold a Royal Society Information Research
Fellowship. In 1980 he was appointed to the chair of computer
science at University College Dublin; from there he moved in 1986
to the Glasgow University where he is now, and indeed is head of
department.

       Since about 1969 his research has been devoted to
information retrieval, covering both theoretical and experimental
aspects. He has specified several theoretical models for IR and
seen some of them from the specification and prototype stage
through to production. His current research is concerned with the
design of appropriate logics to model the flow of information. He
is also involved in several Esprit projects concentrating on the
engineering issues associated with the building of IR systems. He
is a fellow of the IEE and a member of the BCS. In 1993 he was
appointed Editor-in-Chief of The Computer Journal. He has also
recently been appointed a member of the Advisory Committee for
GMD in Germany.


    Developing Information Retrieval Applications using Object    

                       Database Technology

              David J. Harper, University of Glasgow

       The field of information retrieval (IR) has yielded a range
of techniques for efficiently and effectively storing and
retrieving information items based on their text content.  The
utility of many application systems could be greatly enhanced by
employing these techniques. Examples of such applications include
office information systems, hypertext systems, and advanced
information systems for government and industry.  In this
tutorial we describe how modern IR techniques, namely automatic
indexing and best-match retrieval, can be efficiently implemented
and conveniently delivered to application developers 

using object-oriented design and object database technology.  We
examine some sample applications and thereby demonstrate that the
resultant IR framework, which takes the form of a class library,
is both useable and extensible by application developers.  We
argue that our approach has a number of advantages over
traditional mechanisms of delivery such as standalone packages
and conventional programming language libraries.  The tutorial
is aimed at software designers and engineers who want to employ
modern IR techniques within application systems, academics and
researchers who are interested in implementing, experimenting
with or prototyping IR systems, and managers wanting to assess
the benefits of implementing IR applications using object
database technology.  Basic knowledge of IR and database concepts
is assumed.  A brief introduction to object-oriented concepts and
object database technology will be provided.

       David J. Harper is a lecturer in the Department of Computing
Science, University of Glasgow, Scotland.  He is a principal
investigator in Glasgow on the EEC-funded ESPRIT project
Comandos, which is concerned with the construction and management
of distributed open systems, and he leads a major research stream
on object data management services. His other research interests
include information retrieval systems, object-oriented design and
programming, formal specification of database systems, and office
information systems.  

He received his B.Sc.(Hons) in Computer Science from Monash
University, Australia, in 1973 and his Ph.D. in Computing Science
from the University of Cambridge, England, in 1980.

              Trends in Multimedia Development

           Alan Griffiths, University of Sheffield


       New products and applications for multimedia are being
announced almost daily and there is a considerable hype over what
is still a commercially insecure field with ill-defined standards
and user groups.  This tutorial will provide a stimulating
overview of multimedia and will discuss a wide range of examples
including computer-assisted-learning (CAL), image banks,
electronic books and virtual reality. The currently available
multimedia products and services will be examined to look for
trends in development and these will be extrapolated into the
future to propose products and services which will take advantage
of the hardware, software and intellect combinations to create
imaginative learning and information environments. This
enthusiastic view will be tempered by discussing the very real,
and unresolved, problems in designing large multimedia systems.
The aims of the
tutorial are:
(a)    To provide an overview of current and future trends in
       multimedia;
(b)    To provide thought-provoking possibilities for information
       products incorporating multimedia;
(c)    To stimulate discussion on how information retrieval
       techniques can and are being implemented into multimedia
       products.

       The attendees for this tutorial will be people interested in
the stimulating prospects that multimedia offers, but not
necessarily specialists in the field. Multimedia will not provide
a solution to information retrieval but it can provide front-end
systems which use the algorithms and techniques outlined
elsewhere in the conference.

       Alan Griffiths is an independent consultant working in the
areas of database and multimedia design, and is also a part-time
lecturer in multimedia at the Department of Information Studies,
University of Sheffield, England. Over the past ten years he has
completed consultancies for a diverse group of clients ranging
from heavy industry to public sector organizations. These clients
have included Birmingham City Council, the Council for British
Archaeology, Hewlett Packard, various parts of the British
government, Basil Blackwells, Bridon Ropes and the Health &
Safety Executive. His hazardous chemical software, produced for
the Health & Safety Executive, is marketed by HMSO and used
world-wide. His presentations on multimedia have been given to
academic groups, software houses, companies and the public in
England, France, Italy, Canada and Mexico.


            Afternoon Tutorials: 1:30 - 5:30 p.m.

        Natural Language Processing for Information Retrieval

     David Lewis and Elizabeth Liddy, AT&T Bell Laboratories and
                      Syracuse University

     Our subject is the application of natural language
processing (NLP) methods to information retrieval (IR) systems. 

We will discuss the characteristics of human language that make
IR difficult, and will provide an extensive treatment of both NLP
methods and their non-NLP alternatives for addressing these
characteristics.  We will also discuss the newer area of using IR
components to aid NLP systems.  This tutorial should be of
interest both to researchers interested in past work and current
research directions, and to application developers and managers
who need to choose practical strategies for immediate
implementation.  Linguistic examples will be drawn primarily from
English and Japanese, with a scattering from other languages.  A
bibliography on NLP and IR will be distributed.

       David D. Lewis (lewis@research.att.com) is a Member of
Technical Staff at AT&T Bell Laboratories in Murray Hill, NJ,
where his research areas are IR, NLP, machine learning, and their
intersections.  Lewis has implemented a variety of experimental
and operational IR and NLP systems, as well as being an organizer
for several large scale evaluations of such software.

       Elizabeth D. Liddy (liddy@suvm.syr.edu) is an assistant
professor in the School of Information Studies at Syracuse
University, where her research areas are discourse linguistics,
semantic disambiguation, and the use of natural language
processing in information systems.  She is a co-principal
investigator on the DR-LINK project funded under the DARPA
Tipster initiative on text retrieval and filtering.


            Information Retrieval and Databases

       Norbert Fuhr, University of Dortmund, Germany

       Besides basic database functions such as concurrency,
recovery, security and integrity, future IR systems will also
need data modelling concepts for coping with structured documents
and powerful query languages in order to ask for any kind of
object in the database (for example authors, affiliations,
journals). On the other hand, database systems are required to
handle textual attributes and to provide appropriate text
retrieval facilities. This tutorial will present specific
database concepts which are important for both types
of systems.

       After a short introduction to basic database concepts, three
major lines of research will be considered:  modelling data
structure (relational and  NF2 models); modelling  structure  and 

behavior (object-oriented databases); and modelling uncertainty
(Fuzzy, Bayesian and Dempster-Shafer approaches).  For each of
these approaches, examples for their application to IR problems
will be presented.

       The target audience is those who have basic knowledge in IR
and now want to learn about the database aspects of the field.
The course would be most useful for people designing or building
IR or database systems.

       Norbert Fuhr is professor in the computer science department
of the University of Dortmund, Germany.  He holds a diploma and
doctorate in Computer Science from the Technical University of
Darmstadt.  He is well-known for his theoretical and experimental
work on probabilistic IR models.  Recently, his research
interests have focused
on the application of IR methods to factual databases and the
integration of IR and database systems.


        Non-Textual Compression in Full-Text IR Systems
          

           Shmuel T. Klein, Bar-Ilan University, Israel

       Data compression has received increased attention lately,
resulting in a large number of recent publications in this area.
The tutorial presents an overview of these recent developments.
We shall first classify the various types of files that appear in
a full-text
retrieval system. The focus will be on the auxiliary structured
files, such as dictionaries, concordances and various forms of
bitmaps, (which may significantly enhance the retrieval
algorithms) and will present state of the art approaches for
compressing them. The tutorial
is intended for researchers, designers and users of large textual
IR systems. By the end of the tutorial, the participant should be
able, for a given file, to choose the appropriate compression
technique and design his/her own encoding and decoding routines.

       Shmuel T. Klein received his Ph.D. from the Weizmann
Institute of Science in Israel. He then spent three years at the
University of Chicago and is now at Bar-Ilan University in
Israel. Dr. Klein has worked on two of the world's largest
natural language full-text information retrieval systems: the
Responsa Project at Bar-Ilan University (in Hebrew),
and the Tresor de la Langue Francaise at the University of
Chicago (in French), and has published several papers on various
aspects of compression in IR systems.
- -- - - - - - - - ---more on IANET '93- - - ---- -
                 INFORMATION ACCESS AND THE NETWORKS
              A Research Workshop (held after SIGIR'93)
                  July 1, 1993  ---  Pittsburgh, PA

Information access involving networks is one of the most important
growth areas in the broad field of information technology.  User
demand has caused a massive growth in the size of the Internet and  
the
amount of information accessible on it.  This has made it imperative
to develop new technologies to provide an infrastructure for this new
information space.  This workshop will bring together researchers and
developers to discuss network-based information services in both
general and specific terms, drawing upon those attending ACM SIGIR  
'93
and the communities related to:
        * Archie
        * Digital Libraries
        * Gopher
        * HyperPage
        * Knowbots
        * NCSA Mosaic
        * NNTP/Usenet
        * Prospero
        * Veronica
        * WAIS
        * WWW (WorldWideWeb)
        * Z39.50
along with other related initiatives, protocols, systems, and  
services.

Attendees will include persons with an active interest in
network-based information systems and relevant research.

Presentations will include design and implementation of
client-server architectures, resource discovery, distributed file
systems and services, development of integrated network tools, and  
innovative 

applications of more basic technologies, such as bulletin board  
systems and 

electronic mail.

The workshop format involves a plenary session from 8:30-11:30 a.m.
with invited speakers, each of them addressing a major theme in the
area of wide-area networking. After some discussion, the workshop  
will
break up into groups, starting with a working lunch.  The  
organization
of these groups and assignment of participants to them will be based
on a short interest statement provided by each participant.

The workshop will conclude with brief summary presentations by
group leaders.  Notes from the plenary talks and interest
statements will be provided to attendees and made available
for online access after the workshop.

In addition to discussion of the initiatives, protocols, systems, and
services listed above, other topics of interest include:
         * scaling - to handle more users, more databases or  
documents,
                 bigger databases, larger data items (e.g.,  
multimedia)
         * efficiency - algorithms, data structures,
                simulations, experiments
         * effectiveness - evaluation methods, studies, designs
         * interfaces - platforms, user needs, development methods,
                 evaluations, integration with other applications
         * limitations and future plans for enhancement
         * progress in developing standards or using existing ones
         * technical details relating to protocols, implementations
         * user studies, application surveys, innovative uses
         * integration - plans, designs, requirements,  
implementations
                 of systems to integrate information access over
                 the networks
         * novel applications using network-enabled information  
access
                 technology.

If you are interested in attending, please prepare a 1-page statement
of interest, covering your background, experience, and topics of
interest.  Priority, in case of limited space, will be given to SIGIR
attendees and those who have submitted interest statements.

The Program Committee includes:
        George Brett, CNIDR
        Edward Fox, Chair (of workshop, SIGIR), Virginia Tech
        Jose-Marie Griffiths, U. Tenn.
        Brewster Kahle, WAIS Inc.
        Clifford Lynch, U. California
        Craig Stanfill, Thinking Machines
        Craig Summerhill, Coalition for Networked Information
        Chris Tomer, Co-chair and local arrangements coordinator

Interest statements should be submitted by May 15.  They may  
accompany 

registration forms or be sent directly to:
        Chris Tomer
        School of Library and Information Science
        University of Pittsburgh
        Pittsburgh, PA 15260, USA
        tel: (412) 624-9448; fax: (412) 648-7001
        email: ianet@lis.pitt.edu

Further information is available from:
        Ed Fox, (fox@fox.cs.vt.edu; foxea@vtcc1.bitnet) or 

        Chris Tomer (ianet@lis.pitt.edu)
                                   

                Cost for this one-day session is $50,
               which includes coffee breaks and lunch.

------- End of Forwarded Message



From dsr@hplb.hpl.hp.com  Mon May 10 18:41:55 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26265; Mon, 10 May 93 18:41:55 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19246; Mon, 10 May 1993 19:02:44 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 10 May 93 17:55:56 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA06581; Mon, 10 May 93 18:03:44 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305101703.AA06581@manuel.hpl.hp.com>
Subject: Tables and HTML+
To: raisch@ora.com
Date: Mon, 10 May 93 18:03:42 BST
Cc: dale@ora.com, www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Rob,

I was hoping you could give me the benefit of the views of O'Reilly and
Associates on some features that we could put into the extended standard for
HTML. In particular, I would like some input on how much information is
needed to specify tables.

It seems to me that tables can be characterised as follows:

    o   tables consist of headers, rows and columns

    o   tables often have dividing lines (single and double lines)

    o   alignment of cell data, e.g. left, right, on decimal point, ...

    o   tables can be nested (breaking a cell up into a nested table)

How important do you guys think it is to give the author detailed control
over things like dividing lines and cell alignment?

I would be very interested if you have any thoughts as to how HTML should
handle tables and the level of detail to aim for. We want to keep HTML
reasonably simple while hitting most peoples needs. As experienced publishers
of technical material where do you think we should take HTML?

Many thanks,

Dave Raggett

From grobe@ukanaix.cc.ukans.edu  Mon May 10 21:27:31 1993
Return-Path: <grobe@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29495; Mon, 10 May 93 21:27:31 MET DST
Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14271; Mon, 10 May 1993 21:48:22 +0200
Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA25038; Mon, 10 May 1993 14:49:43 -0500
From: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
Message-Id: <9305101949.AA25038@ukanaix.cc.ukans.edu>
Subject: html-link-made
To: www-talk@nxoc01.cern.ch
Date: Mon, 10 May 93 14:49:41 CDT
X-Mailer: ELM [version 2.3 PL2]

readers:

chapter 6 of the march 15, 1993 version of "Hypertext Markup Language
(HTML)" by Berners-Lee and Connolly discusses "Link Relationship values."

i have several questions about this chapter:

first, what is its status? are there browsers in use that recognize
these link attribute values? have any of these attributes been promoted
to be part of the standard?  are they likely to become part of the
standard? if so, when and under what authority?

second, if browsers ignore attribute values that they do not recognize, why
must these "experimental" values be preceded with "X-".

third, are there any example documents showing the use of these values?

fouth, is the value "Made" correctly described in this chapter?
the chapter says that Made means that the:

   Person (etc) described by node A is author of, or is responsible for B

where A is the source document and B is the destination document. however, 
the chapter also says that one use for the value is "for sending
mail to authors," and it seems to me that Made would be more useful if
A and B were reversed in the definition above.
that is, it seems more useful for a document to contain a pointer to a file
describing an author where the link relationship would be "Made" with
the understanding that the person described in B is the author of A.
can someone clarify this (what seems to me to be a) discrepancy?

fifth, since we are looking for a way to connect html documents with
their authors or responsible authorities, the value Made appears to be
a possible approach.  but, i would be interested in knowing any other
conventions for recording such information that may be planned or under
discussion.  i would actually prefer (at least intuitively) to have
a tag defined for the document <head> section that could be used to
record responsibility for the document.  for example, <owner> could
be defined and have name, organization, and e-mail address as attributes.
our browser could then pick up the owner e-mail address for posting
comments from users reading a particular file directly to the owner.
in particular, we might have the following tag 
     <owner name="Michael Grobe" e-mail="grobe@kuhub.cc.ukans.edu">
comments?

:michael grobe
academic computing services
the university of kansas




From marca@wintermute.ncsa.uiuc.edu  Tue May 11 07:16:04 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05879; Tue, 11 May 93 07:16:04 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05498; Tue, 11 May 1993 07:36:55 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA07362
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 11 May 93 00:36:53 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA24089; Tue, 11 May 93 00:39:19 -0500
Date: Tue, 11 May 93 00:39:19 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305110539.AA24089@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: forwarded sans comment
X-Md4-Signature: 35b665a3dc1dd8da04d0e27a8e99292d

From: drmacro@vnet.IBM.COM
Date: Mon, 10 May 93 09:32:59 EDT
Newsgroups: comp.text.sgml,alt.hypertext
Subject: Re: WWW and Hytime (was Explicit Linking is Impossible)
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.1

It's clear from these postings that the WWW system is pretty
sophisticated and has many of the functional attributes one would
expect in a HyTime-based system, including sophisticated query links,
various addressing methods, and so on.  I would urge the the WWW folks
to consider recasting the WWW in HyTime terms.  By using HyTime
constructs to define hyperlinks and other WWW functions, the WWW
system would become compatible with all other HyTime-conforming
systems.  It would, for example, make the WWW able to manage
hyperlinks to and from document in any DTD that used HyTime-compliant
hyperlink elements, meaning, for example, that both OSF-DOC and
IBMIDDoc documents could be integrated into a WWW system without
change to the documents themselves.  It's unlikely that I would add
support for WWW-specific link elements that were not HyTime compliant
to IBMIDDoc, but it is highly likely that I would add support for
WWW-specific addressing notations in IBMIDDoc implementations if WWW
used HyTime for hyperlinks.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-254-5160
IBM Corporation
Research Triangle Park, NC 27709


From emv@garnet.msen.com  Tue May 11 08:48:08 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06399; Tue, 11 May 93 08:48:08 MET DST
Received: from [148.59.1.11] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19578; Tue, 11 May 1993 09:08:58 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nsoS1-000EZiC; Tue, 11 May 93 03:08 EDT
Message-Id: <m0nsoS1-000EZiC@garnet.msen.com>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: forwarded sans comment 
In-Reply-To: Your message of Tue, 11 May 93 00:39:19.
             <9305110539.AA24089@wintermute.ncsa.uiuc.edu> 
Date: Tue, 11 May 93 03:08:33 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

(I put my 2c in there already - HyTime is from all indications a
typical ISO kludge "standard" with no real world experience, and
one would be ill-advised to drop everything else and take it up
lock stock and barrel....)

From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 11 11:13:06 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08301; Tue, 11 May 93 11:13:06 MET DST
Received: from [138.250.1.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18204; Tue, 11 May 1993 11:33:54 +0200
Received: by xdm001 
	id AA17418; Tue, 11 May 93 10:33:34 +0100
Received: by xdm039 (5.57/4.7) id AA14460; Tue, 11 May 93 10:33:32 +0100
Message-Id: <9305110933.AA14460@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Automatic reply in HTML
Reply-To: p.lister@cranfield.ac.uk
Date: Tue, 11 May 93 10:33:30 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

This functionality was suggested by a colleague; it sounds good to me.

We would like to publish our prospectus in HTML. At the back of the
printed copies of the prospectus, ther are details of how to contact
Cranfield by post or email for further information on particular courses.

In the HTML version, it would be nice to have a URL like

<a HREF="mailto:course-info@cranfield.ac.uk/Name: \nAddress: \nCourse:
\nref: \n">Send an enquiry</a>

This would have the effect that when the anchor is activated, clients
display a window (initialised with the optional text following the "/".
When finished, the user confirms the contents, and the client sends a
mail message to the address shown.

This URL equates to a paper reply-paid card; it is an invitation to
reply automatically with no hassle or need to use local resources. A
more general form of this URL might well include telnet or any other
remote service which requires may need initial information. If
variables can be used, then one could include the sender's details in
the initial text.

It occurs to me that code already exists to do this in Xmosaic, as
Whine (or Mail Developers as it is now). If you fancy adding a new URL
type that kicks off the whine code, Marc, that would be a very nice demo.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From timbl@www3.cern.ch  Tue May 11 11:46:26 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08608; Tue, 11 May 93 11:46:26 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25739; Tue, 11 May 1993 12:07:16 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02689; Tue, 11 May 93 12:02:01 +0100
Date: Tue, 11 May 93 12:02:01 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305111102.AA02689@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: p.lister@cranfield.ac.uk, uri@
Subject: Mail addresses as URLs
Cc: www-talk@nxoc01.cern.ch, ccprl@xdm001.ccc.cranfield.ac.uk
Reply-To: timbl@nxoc01.cern.ch



This is not the first time a mail address has been suggested as a URL
and I think it is so useful that it should go in.

It IS the first time that mail header fields have been suggested as  
part of the URL.  I am not so sure about that one -- it would have to
be well defined.

I like the idea of the mail address, as I can see a sophisticated  
browser not just opening a mail send window, but representing the
mail endpoint with for example a list of mail messages which the guy  
has written.  Creating a link between
a document and the "person" would mail the document to the person,
just as creating a link between a document and a newsgroup would
post the document, etc..

In this case the additional fields in the URL would rather confuse
things, as they wouldn't in fact define a more specific mail  
location, they would be more of a template or a script.  I would
prefer to see that sort of thing handled properly with forms in HMML.

What to you URI folks think of this? The simplest form is
to specify

	mailto:user@host

where the LHS is a regular Internet mail address.

* This would nicely integrate mail address servers, as a form for  
returning mail address info

* The To: and From: fields of messages would be treatable
as hypertext links, just as the Newsgroup: and Reference: fields
are now.

* A link type <LINK REL="AUTHOR" HREF="bloggs@acme.com"> would be
 a formal way of attributing responsability.
 

* etc etc

I think this would be pretty neat, really useful, not too much sweat.
What do you think?

<A HREF="mailto:timbl@info.cern.ch">Tim</A>

____________________________________________________________________
Peter's original message was to www-talk, I enclose it for those
only on the uri list. 

Begin forwarded message:

To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Automatic reply in HTML
Reply-To: p.lister@cranfield.ac.uk
Date: Tue, 11 May 93 10:33:30 BST
From: "Peter Lister, Cranfield Computer Centre"  
<ccprl@xdm001.ccc.cranfield.ac.uk>

This functionality was suggested by a colleague; it sounds good to  
me.

We would like to publish our prospectus in HTML. At the back of the
printed copies of the prospectus, ther are details of how to contact
Cranfield by post or email for further information on particular  
courses.

In the HTML version, it would be nice to have a URL like

<a HREF="mailto:course-info@cranfield.ac.uk/Name: \nAddress:  
\nCourse:
\nref: \n">Send an enquiry</a>

This would have the effect that when the anchor is activated, clients
display a window (initialised with the optional text following the  
"/".
When finished, the user confirms the contents, and the client sends a
mail message to the address shown.

This URL equates to a paper reply-paid card; it is an invitation to
reply automatically with no hassle or need to use local resources. A
more general form of this URL might well include telnet or any other
remote service which requires may need initial information. If
variables can be used, then one could include the sender's details in
the initial text.

It occurs to me that code already exists to do this in Xmosaic, as
Whine (or Mail Developers as it is now). If you fancy adding a new  
URL
type that kicks off the whine code, Marc, that would be a very nice  
demo.

Peter Lister                                     
p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext  
2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875


From tom@begbick.law.cornell.edu  Tue May 11 11:51:12 1993
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08634; Tue, 11 May 93 11:51:12 MET DST
Received: from [132.236.56.6] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26096; Tue, 11 May 1993 12:12:04 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160513(2)>; Tue, 11 May 1993 06:11:19 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA00362; Tue, 11 May 93 06:02:18 EDT
Date: Tue, 11 May 1993 06:02:18 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9305111002.AA00362@begbick.law.cornell.edu.law.cornell.edu>
To: p.lister@cranfield.ac.uk
Cc: www-talk@nxoc01.cern.ch, ccprl@xdm001.ccc.cranfield.ac.uk
In-Reply-To: "Peter Lister, Cranfield Computer Centre"'s message of Tue, 11 May 93 10:33:30 BST <9305110933.AA14460@xdm039>
Subject: Automatic reply in HTML

Peter:

I've already implemented something akin to your mailto: URL in Cello,
though not as detailed.  My method may be slightly more in line with
URL syntax (or it may not, who knows) and looks like:

       mailto://some.mail.host.dom/somebody

The behavior is for a mail form to pop up with the user's
(preconfigured in the MS-Windows equivalent of a .rc file) e-mail
address as sender, and with somebody@some.mail.host.dom as the
recipient.  I thought it unnecessarily complicated to try to specify
the content of the message beyond this....

Incidentally, this works quite nicely with any kind of doc (such as
text returned from a CSO/qi server) which contains 'actionable' email
addresses, and provides a nice way to do staff directories and such.

Regards,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From timbl@www3.cern.ch  Tue May 11 12:09:36 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08789; Tue, 11 May 93 12:09:36 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29251; Tue, 11 May 1993 12:30:28 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02806; Tue, 11 May 93 12:25:16 +0100
Date: Tue, 11 May 93 12:25:16 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305111125.AA02806@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: John.Ockerbloom@gs1.sp.cs.cmu.edu
Subject: Re: WWW: Local file handling
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Tim bl:
> 

> ... as in the server to allow mappings to be made.
> You can now run [from next release 2.05 on] www as
> 

>         www -r  www.conf
> where www.conf contains lines like
> 

> pass    wais://*                http://info.cern.ch:8001/*
> pass    file://fred.cmu.edu/*   file:/afs/cs.cmu.edu/*
> pass    ftp://ftp.cnu.edu/pub/* file:/ftp/pub/*
> 

> for example.  The rule file is not very powerful, not full regexp,
> but it is more flexible than just tackling the file: case.
> 

> ----
> 

> This will be quite useful; thanks! (In particular, it's quite  
useful
> for mirrored sites.  For instance, I may want requests for a HTTP
> server in New Zealand to go to some mirrored site closer to home,  
for
> instance.)
> 

> > At least in
> the version of the WWW library that Mosaic uses, the URL
> "file:/afs/cs.cmu.edu..." does NOT read from the local filesystem,
> but rather from the last filesystem accessed.

That sounds very strange. That is not how it should work.  The
parser should clear the host field if "file:" is present. If the
field is clear, then local access it assumed.  The relative names
are hierarchical, not a matrix -- you can't pick up a hostname
from another protcol for example.

> So if I'm in an FTP
> directory at Bellcore, and then try to jump to a "file:/afs/cs..."
> URL, it will attempt to find the file at Bellcore, rather than back
> on my local filesystem.  (If Mosaic is handling this case  
incorrectly,
> and really *should* be reading from the local filesystem, let me  
know.)

It sounds as though there is some difference in behaviour.  This will
go away when Mosaic picks up the new library.
 

> (Currently I use a hack to force local filesystem lookup, as under  
Mosaic
>  the URL "file:///afs/cs.cmu.edu..." seems to force a check of the  
local
>  filesystem due to the empty host name.  But this isn't something
>  defined in the HTML specification, and in fact I think it doesn't  
work
>  for other WWW browsers.)

Sounds as though they have used their own code for URL parsing.

> As far as I can tell, the only way currently to unequivocally refer  
to
> a file on a local filesystem in an absolute URL is to include the  
name
> of the host the program is executing on (using whatever  
capitalization
> scheme the name-lookup routine prefers) in the URL.  A static rule
> file will not fix this problem unless there's a rule file for every
> machine the program runs on.  And in this environment, we run  
Mosaic
> and other WWW tools on a large variety of workstations.

There is of course one good reson for explicitly declaring the  
hostname for a local file: that is, in order that people on other
machines which don't have it don't get confused.  The URLs are
supposed to be quatable anywhere. If you use a hostname, then even
if the file is not retrievable from off that host, then at least
a foreign person following the link will get an reasonable error.
Th eidea of a URL is that if one perosn quotes it and the other  
person follows it, then they will be talking about the same object.
If one guy says "look in file /rtc/printcap on line 100"
and th eother guy does so, they get confused. The reference
doesn't work.

How about in your case, if you have a whole cluster or campus which
has the same file system, invent a name for it or use one master
hostname.  This would appear in all the absolute links.  The
rule file would then map it to a local name

map file://cluster.cmu.edu/* file:///*

This can be ina cluster-wide rule file.
I have put in the dummy name "localhost" (not case sensitive)
into the next release,
so this can be made more explicit.  It will be equivalent to an
empty host field.

Tim

> John Ockerbloom
> 


From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 11 15:09:02 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11342; Tue, 11 May 93 15:09:02 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29956; Tue, 11 May 1993 15:29:47 +0200
Received: by xdm001 
	id AA20891; Tue, 11 May 93 14:29:40 +0100
Received: by xdm039 (5.57/4.7) id AA14995; Tue, 11 May 93 14:29:35 +0100
Message-Id: <9305111329.AA14995@xdm039>
To: timbl@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
In-Reply-To: Your message of "Tue, 11 May 93 11:36:26 BST." <9305111036.AA18497@xdm001>
Reply-To: p.lister@cranfield.ac.uk
Date: Tue, 11 May 93 14:29:31 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

Tim sez:

> location, they would be more of a template or a script.  I would
> prefer to see that sort of thing handled properly with forms in HMML.

Absolutely. I didn't intend the initial mail contents to be a "mail
header" far from it, I simply suggest that a way of filling in a form
as well as posting arbitrary mail is a definite requirement. If there
is (to be) a proper form spec, let's use that, though it will have to
clearly documented how a filled in form is to be translated to a text
mail message. Using MIME mail is NOT satisfactory, as the system should
work when the mail recipient is not MIME aware.

Peter

PS: Tim, where's the URL list you refer to? Did you receive mail from
me in April about your URL doc? If not I'll join the URL list and
re-send it to that.

From davis@dri.cornell.edu  Tue May 11 15:17:29 1993
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11433; Tue, 11 May 93 15:17:29 MET DST
Received: from WILLOW.TC.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03346; Tue, 11 May 1993 15:38:20 +0200
Received: by willow.tc.cornell.edu id AA26710
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Tue, 11 May 1993 09:38:17 -0400
Date: Tue, 11 May 1993 09:38:17 -0400
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199305111338.AA26710@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Automatic reply in HTML


I agree the functionality is useful.  I am not sure that
a special purpose URL is desirable.  Perhaps a more
general approach is possible.  Consider that reply mail
contains aspects of general purpose form-filling queries
(which we've discussed, and which even Gopher has already)
and has also been implemented at least once by Nathaniel
Borenstein in AtomicMail (a Lisp-subset for making email
messages with programmable but safe side effects.  reply mail
was one of the key purposes of AtomicMail.  alas, it is proprietary
to Bellcore as I understand it, though he is working on a new
and better version which will be presented as an RFC.)

So though I have no specific syntactic proposal to make I
suggest reply mail might be either
 1) a special case of general programmatic invocation
 2) a special case of form-filling-queries

On the other hand I recognize the trend of late in WWW to
implement special purpose features in an adhoc manner without
trying to design the ultimate feature set; and this may even
be a good idea given our lack of experience in the matter.

From timbl@www3.cern.ch  Tue May 11 15:23:53 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11515; Tue, 11 May 93 15:23:53 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04008; Tue, 11 May 1993 15:44:43 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03475; Tue, 11 May 93 15:39:27 +0100
Date: Tue, 11 May 93 15:39:27 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305111439.AA03475@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: p.lister@cranfield.ac.uk
Subject: URI mailing list pointer
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


	The W3 address format, known by the IETF as the
	"Uniform Resource Locator", is discussed on the
	"Uniform Resource Identifier" mailing list,  at
	uri@bunyip.com.  Mail to uri-request@bunyip.com
	to be put onto it or taken off it.  I have CC'd
	the last two relevant www-talk messages to it.

Tim

From timbl@www3.cern.ch  Tue May 11 16:31:04 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12762; Tue, 11 May 93 16:31:04 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18116; Tue, 11 May 1993 16:51:57 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03707; Tue, 11 May 93 16:46:44 +0100
Date: Tue, 11 May 93 16:46:44 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305111546.AA03707@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
Subject: HTML link "Made" relationship
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

> From: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
> To: www-talk@nxoc01.cern.ch
> Date: Mon, 10 May 93 14:49:41 CDT
 

> chapter 6 of the march 15, 1993 version of "Hypertext Markup  
Language
> (HTML)" by Berners-Lee and Connolly discusses "Link Relationship  
values."
> 

> i have several questions about this chapter:

> first, what is its status? are there browsers in use that recognize
> these link attribute values? have any of these attributes been  
promoted
> to be part of the standard?  are they likely to become part of the
> standard? if so, when and under what authority?

They have not been promoted to part of the standard, but if they
are tested they could be.  RFCs don't become standards without
implementations.  No browsers that I know of implement them though
many people have expressed great enthusiasm.  The thing will go
in RFC direction, the authority will therefore be IANA and the IETF
or whatever officially is the authority in the nwo (IAB? ISoc?)

> second, if browsers ignore attribute values that they do not  
recognize, why
> must these "experimental" values be preceded with "X-".

This scheme (which is used for many Internet standards) means
that ifyou invent a scheme which puts a certain semantics on
a new relationship, you can guarrantee that the scheme won't break
because someone just happens to use it for something else with
different semantics.  During the test phase, you can't be SURE
that noone else thought of the same X-relation, and that their
documents will totally confuse your software.  (though it is
unlikely especially with a this list running)

> third, are there any example documents showing the use of these  
values?


Nope (correct me?).  [[Historical note:  The first hypertext system I  
wrote used typed links.  An interesting result was
that though I had initially imagined that the number of link
types would grow without bound, in fact I settled down with a
dozen or so having all the semantics there seemed to be
beteween the things I was making notes about]].

> fouth, is the value "Made" correctly described in this chapter?
> the chapter says that Made means that the:
> 

>    Person (etc) described by node A is author of, or is responsible  
for B
> 

> where A is the source document and B is the destination document.  
however, 

> the chapter also says that one use for the value is "for sending
> mail to authors," and it seems to me that Made would be more useful  
if
> A and B were reversed in the definition above.
> that is, it seems more useful for a document to contain a pointer  
to a file
> describing an author where the link relationship would be "Made"  
with
> the understanding that the person described in B is the author of  
A.
> can someone clarify this (what seems to me to be a) discrepancy?

Every link type can be used in a REL attribute or in a REV
attribute (or in some -- non acyclic -- cases conceivably both).
The REV attribute is just the same, but the direction is
reversed.  This saves having to have a convention for
naming reverse link types such as "made-by".
 

> fifth, since we are looking for a way to connect html documents  
with
> their authors or responsible authorities, the value Made appears to  
be
> a possible approach.  but, i would be interested in knowing any  
other
> conventions for recording such information that may be planned or  
under
> discussion.  i would actually prefer (at least intuitively) to have
> a tag defined for the document <head> section that could be used to
> record responsibility for the document.  for example, <owner> could
> be defined and have name, organization, and e-mail address as  
attributes.
> our browser could then pick up the owner e-mail address for posting
> comments from users reading a particular file directly to the  
owner.
> in particular, we might have the following tag 

>      <owner name="Michael Grobe" e-mail="grobe@kuhub.cc.ukans.edu">
> comments?


Whilest any useful additions to HTML for HMML are open to
discussion now, I would like to see more generic forms used.
This is because HTML is not an application-specific document
type, it is in fact a great big compromise which allows enough
fairly generic structures to represent most things anyone wants.
If "owner" can be represented as a generic relationship, between
a document and a person, with a particular type, then I would
prefer the generic form to be used rather than a specific tag  
invented.  I think this will make processing easier, also expansion,
and keep the DTD small.

<LINK REV=MADE HREF="whois:S=Grobe;G=Michael;O=Ukans">

Here is one example of something which is
easier to do is a web traversal filtered by relationships. Consider
"Give me a list of (and fire :-) all the people who have MADE  
software which is USED BY this program and for which there is no  
document which DESCRIBES that software" 

or, "Print out all documents which this document recursively INCLUDES
to any depth", and so on.

> :michael grobe
> academic computing services
> the university of kansas
 


Tim Berners-Lee
CERN


From timbl@www3.cern.ch  Tue May 11 16:48:28 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13073; Tue, 11 May 93 16:48:28 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22283; Tue, 11 May 1993 17:09:21 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03736; Tue, 11 May 93 17:04:07 +0100
Date: Tue, 11 May 93 17:04:07 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305111604.AA03736@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Mail addresses as URLs
Cc: www-talk@nxoc01.cern.ch, uri@bunyip.com
Reply-To: timbl@nxoc01.cern.ch


> Date: Tue, 11 May 1993 10:13:49 -0400 (EDT)
> From: John C Klensin <KLENSIN@infoods.mit.edu>
> 

> Tim,
> 

> I think the idea of permitting an email address is reasonable,  
although
> it brings us another step closer to a uniform human locator, as in  
"if
> 'mailto' then why not 'faxto', 'telephoneto', 'postto' and so on.

Yes.  I guess we have to be a little more definite about the object
which is being located.  I prefer to see the web as something with
a state which one can alter, rather than a recipe book scripts behind  
the buttons.  The
"mailto:" URL suggests the well defined concept of a mailbox which
may or may not contain documents and may or may not have
restricted access. Perhaps "mailbox:" would be better than "mailto:".
Moving a document into somone's mail box is just like moving a
file into a directory: it is an operation with pre- and  
postconditions.  It just happens that mail uses a particular
protocol which is optimised for particular operations,
has a wide penetration, etc., but can otherwise be treated
with the same user interface metaphor as news and retrieval.

"telephoneto" like "telnet" doesn't fit into that model, and
so is less usefully integrated.

> However you are going to need to be extremely careful about syntax.   
The 

> correct model should be able to accomodate _any_ valid RFC822  
address,
> implying not only "mailto:usermailbox@domain" but including the 

>   Personal Name <usermailbox@domain>
> form and several others.  


Is there not a subsyntax for the usermailbox@domain bit, with the
comment personal Name removed?  It would have the example of being
a little closer to something which one can test for equality.

> RFC1327 forms of X.400 addresses projected into the RFC822  
environment
> also mean that we need to be very careful about quoting and  
structure,
> since those addresses are heavily solidus (/)-laden.

Yes. I had intended to keep "=" in the URL spec
so that it could be used to map /attribute=value/ such as x400.
If you directly quote an RFC822 address, then you run across
the fact MIME uses = instead of %, and all kinds of things.
Would it be possible to remove all RFC822 quoting and apply
URL escaping as a reversable and well-defined transformation
which would presvent the horrible results of layered escaping?
 

> This makes me quite hesitant about forms like Thomas Bruce's
>        mailto://some.mail.host.dom/somebody
> because it implies that we will need to very carefully work out and
> document transformation rules for all of the different variations  
of
> RFC822 addresses into and out of this format.  It would be easier,  
and
> safer, to use RFC822 addresses in as literal a form as possible, so  
we
> could just refer to that document and its descendants.


I agree completely.  Tom's format was designed to look as like
as possible to http URLs, but there is in the
news:artic@leid a precedent for exactly the same reasons for
keeping the original as uncorrupted as possible.

>    --john
> 


 Tim

From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 11 17:56:04 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13893; Tue, 11 May 93 17:56:04 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06044; Tue, 11 May 1993 18:16:48 +0200
Received: by xdm001 
	id AA25445; Tue, 11 May 93 17:16:41 +0100
Received: by xdm039 (5.57/4.7) id AA15294; Tue, 11 May 93 17:16:35 +0100
Message-Id: <9305111616.AA15294@xdm039>
To: timbl@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: Re: WWW: Local file handling 
In-Reply-To: Your message of "Tue, 11 May 93 11:47:09 BST."
             <9305111047.AA18691@xdm001> 
Date: Tue, 11 May 93 17:16:32 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

The discussion about local files prompts me to ask - how does one
distinguish between ones own local ftp area (which is what the outside
world sees when following a file URL), and the local file system
mounted under root (which is what a client program like xmosaic sees)?.
How do I refer to my own ftp area?

As far as I can see, no URL should refer to different mechanisms in
different contexts. Lets have ftp: (use ftp ONLY) and file: (local file
system ONLY, further use discouraged). I don't want an afs: URL,
because it's equivalent to file: if you're an AFS site, and useless if
you aren't. OK, AFS sites (we are one) can mount each others file
systems, but it's NOT a preferred method of allowing the world access
to info that we want to make public. 

Peter

From pandora@fernwood.mpk.ca.us  Tue May 11 19:02:28 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15023; Tue, 11 May 93 19:02:28 MET DST
Received: from [130.93.1.2] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21413; Tue, 11 May 1993 19:23:19 +0200
Received: by fernwood.mpk.ca.us; id AA01401; Tue, 11 May 93 10:26:46 -0700
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: Re: No subject entered
Organization: Pandora Systems
Date: Tue, 11 May 1993 16:29:23 GMT
Message-Id: <C6vF50.Eoy@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL9]
References: <9305111329.AA14995@xdm039>
Apparently-To: www-talk@nxoc01.cern.ch


One good reason for being able to specify more of the header can be seen
by this discussion, where the Subject line has been different in almost
any message.  It would be nice to be able to specify at least the
subject line. 

- Mitra


From dcmartin@lib.ucsf.edu  Tue May 11 19:06:33 1993
Return-Path: <dcmartin@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15118; Tue, 11 May 93 19:06:33 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21657; Tue, 11 May 1993 19:27:24 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA25890; Tue, 11 May 93 10:23:29 PDT
Message-Id: <9305111723.AA25890@knowman.lib.ucsf.EDU>
From: dcmartin@ckm.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch, marca@ncsa.uiuc.edu
In-Reply-To: Your message of Tue, 11 May 93 17:16:32 +0000
	<9305111616.AA15294@xdm039> 
Subject: Re: WWW: Local file handling 
Date: Tue, 11 May 93 10:26:33 MDT
Sender: dcmartin@lib.ucsf.edu

I have been toying with a similar idea, how to keep track of documents
which you would like to have in a "hotlist," but are more numerous and
require more structure filing, e.g. like UNIX files in the filesystem.

What I have done is modify some code in gui2.c which allows local files
that are "opened" from the File "Open local..." menu item to be symbolic
links which point nowhere, but include the URL, e.g.

% ln -s http://www.ncsa.uiuc.edu/evl/cave/cave.html .

which creates the symbolic link cave.html.  The patch is quite simple
and is included.  There needs to be additional work done to allow the
user to specify the name on the command line, e.g.

% xmosaic cave.html

and have the additional test of a local symbolic link encoding a URL and
to the file browser to show such entries (it might be nice to even
identify such entries as URL's).

In addition, some consideration should be given for allowing a third
party, e.g. the LookingGlass software, to send a message to Mosaic
asking it to load a local file.

My $0.02.

dcm
--------
"Peter Lister, Cranfield Computer Centre" writes:

The discussion about local files prompts me to ask - how does one
distinguish between ones own local ftp area (which is what the outside
world sees when following a file URL), and the local file system
mounted under root (which is what a client program like xmosaic sees)?.
How do I refer to my own ftp area?

As far as I can see, no URL should refer to different mechanisms in
different contexts. Lets have ftp: (use ftp ONLY) and file: (local file
system ONLY, further use discouraged). I don't want an afs: URL,
because it's equivalent to file: if you're an AFS site, and useless if
you aren't. OK, AFS sites (we are one) can mount each others file
systems, but it's NOT a preferred method of allowing the world access
to info that we want to make public. 

Peter

From dcmartin@lib.ucsf.edu  Tue May 11 19:06:44 1993
Return-Path: <dcmartin@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15124; Tue, 11 May 93 19:06:44 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21661; Tue, 11 May 1993 19:27:30 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA25897; Tue, 11 May 93 10:24:10 PDT
Message-Id: <9305111724.AA25897@knowman.lib.ucsf.EDU>
From: dcmartin@ckm.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch, marca@ncsa.uiuc.edu
In-Reply-To: Your message of Tue, 11 May 93 17:16:32 +0000
	<9305111616.AA15294@xdm039> 
Subject: WWW: Local file handling (PATCH)
Date: Tue, 11 May 93 10:27:14 MDT
Sender: dcmartin@lib.ucsf.edu

*** gui2.c-orig	Sat Apr 17 22:52:44 1993
--- gui2.c	Tue May 11 10:12:54 1993
***************
*** 258,284 ****
  
  /* ---------------------- mo_post_open_local_window ----------------------- */
  
  static XmxCallback (open_local_win_cb)
  {
!   char *fname;
!   char *url;
!   mo_window *win = mo_fetch_window_by_id (XmxExtractUniqid ((int)client_data));
  
!   XtUnmanageChild (win->open_local_win);
!   fname = (char *)malloc (128 * sizeof (char));
    
!   XmStringGetLtoR (((XmFileSelectionBoxCallbackStruct *)call_data)->value,
!                    XmSTRING_DEFAULT_CHARSET,
!                    &fname);
! 
!   url = (char *)malloc 
!     ((strlen (fname) + strlen (shortmachine) + 16) * sizeof (char));
!   sprintf (url, "file://%s%s\0", shortmachine, fname);
!   if (url[strlen(url)-1] == '/')
!     url[strlen(url)-1] = '\0';
!   mo_load_window_text (win, url, NULL);
! 
!   return;
  }
  
  mo_status mo_post_open_local_window (mo_window *win)
--- 258,292 ----
  
  /* ---------------------- mo_post_open_local_window ----------------------- */
  
+ #include <sys/param.h>
+ 
  static XmxCallback (open_local_win_cb)
  {
!     char	buf[MAXPATHLEN];
!     int		bufsiz = 0;
!     char*	fname;
!     char*	url;
!     mo_window*	win = mo_fetch_window_by_id(XmxExtractUniqid((int)client_data));
  
!     XtUnmanageChild (win->open_local_win);
!     fname = (char *)malloc (128 * sizeof (char));
    
!     XmStringGetLtoR (((XmFileSelectionBoxCallbackStruct *)call_data)->value,
! 		     XmSTRING_DEFAULT_CHARSET,
! 		     &fname);
!     if ((bufsiz = readlink(fname, &buf)) > 0) {
! 	url = (char*) malloc((bufsiz + 1) * sizeof(char));
! 	buf[bufsiz] = (char) NULL;
! 	(void) strcpy(url, buf);
!     } else {
! 	url = (char*) malloc((strlen (fname) + strlen (shortmachine) + 16) * 
! 			     sizeof (char));
! 	sprintf (url, "file://%s%s\0", shortmachine, fname);
! 	if (url[strlen(url)-1] == '/')
! 	    url[strlen(url)-1] = '\0';
!     }
!     mo_load_window_text (win, url, NULL);
!     return;
  }
  
  mo_status mo_post_open_local_window (mo_window *win)

From KLENSIN@infoods.mit.edu  Tue May 11 19:36:49 1993
Return-Path: <KLENSIN@infoods.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15691; Tue, 11 May 93 19:36:49 MET DST
Received: from INFOODS.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29008; Tue, 11 May 1993 19:57:40 +0200
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
 <01GY0SGODSS000064V@INFOODS.UNU.EDU>; Tue, 11 May 1993 13:57:13 EDT
Date: Tue, 11 May 1993 13:57:13 -0400 (EDT)
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Mail addresses as URLs
In-Reply-To: <9305111604.AA03736@www3.cern.ch>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch, uri@bunyip.com
Message-Id: <737143033.452103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: timbl@NXOC01.CERN.CH, www-talk@NXOC01.CERN.CH
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <MultiNet-MM(330)+TOPSLIB(156)+PMDF(4.2)@INFOODS.UNU.EDU>

>well defined concept of a mailbox which
>may or may not contain documents and may or may not have
>restricted access. Perhaps "mailbox:" would be better than "mailto:".
>Moving a document into somone's mail box is just like moving a
>file into a directory: it is an operation with pre- and  
>postconditions.

Maybe.  I'm not sure how far the distinction is important, but you can't
externally specify delivery to my actual mailbox, nor can you determine
how many of those I have and how your message will be routed by filters
I impose on incoming mail.  All you get with a "mailbox name" is an
abstraction with which you can deliver something to my host's mail user
agent; after that, what happens to it is a local responsibility/issue
that is traditionally not subject to Internet protocols.

>"telephoneto" like "telnet" doesn't fit into that model, and
>so is less usefully integrated.
   Actually, if you are trying to deliver an audio entity, or have
text-to-speech capability, they are pretty similar in theory (the
practice is different because we tend to attach different tools to
mailboxes, but you can't predict this from the protocols).  Whether a
telephone number addresses an individual or a group can't be determined
in the general case.  Whether the message is recorded or discarded after
first reading/hearing is a local matter, as are a series of possible
forwarding and diversion operations.

>Is there not a subsyntax for the usermailbox@domain bit, with the
>comment personal Name removed?  

  First, just to clarify for those who aren't used to the syntax (or who
have seen it for years and not paid attention)...
     (this is a comment)   It is, from a protocol standpoint, noise that
can be discarded without loss of important information.
     The personal name ("phrase" in RFC822-speak) isn't a comment, it is
part of the address.  Mail systems have some obligation to preserve it
(a rule often broken) and not map it into a comment or vice versa
(thereby destroying or inventing information--also often broken).  In
environments at the periphery of the network, where mailboxes cost
money, personal names are often used to differentiate among users of the
same mailbox and post-delivery dispatching arranged on that basis.
    But, yes, one could eliminate the personal-name part as not machine-
addressable.  But there are still a number of variant forms.

>It would have the example of being
>a little closer to something which one can test for equality.
   Not much.   One of the intermittent interesting questions in email-
land is "how do I look down a list of addresses and eliminate
duplicates".  The general answer is "can't".  There are two problems,
both of which related to the mailbox-abstraction issues discussed above.
The first is that there are religious debates about whether
   Joe <someuser@somehost>     and
   Mary <someuser@somehost>    are the same
The machine-processable mailbox strings are the same, but "Joe" and
"Mary" tend to think they are different.

The second is that there is really nothing you can test for equality
anyway.  I've just done a quick count and probably forgotten a few, but
I've got at least eight addresses (different apparent mailboxes on
different apparent hosts) that cause mail to appear in the vicinity of
klensin@infoods.unu.edu, plus one that causes _most_ of the mail sent to
it to appear here, but which keeps the rest.  It takes far more
information than the mail system "owns" and will tell you to deduce the
relationships.

>Would it be possible to remove all RFC822 quoting and apply
>URL escaping as a reversable and well-defined transformation
>which would presvent the horrible results of layered escaping?
  At the risk of being cynical, it depends on the standards of quality
to which you can hold implementors of URL systems and, to the degree to
which humans have to see or type these things, those people.  If the
quality is comparable to what we have experienced with email, it is
hopeless--the quoting conventions in RFC822 are not implemented
correctly by a painful number of systems (and they've had a decade to
get it right).

  --john

From mvanheyn@cs.indiana.edu  Tue May 11 19:59:40 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16095; Tue, 11 May 93 19:59:40 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02801; Tue, 11 May 1993 20:20:32 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA01634; Tue, 11 May 1993 13:20:30 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Mail addresses as URLs 
In-Reply-To: Your message of "Tue, 11 May 1993 13:57:13 -0400."
             <737143033.452103.KLENSIN@INFOODS.UNU.EDU> 
Date: Tue, 11 May 1993 13:20:29 -0500
Message-Id: <1632.737144429@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: John C Klensin
>>well defined concept of a mailbox which
>>may or may not contain documents and may or may not have
>>restricted access. Perhaps "mailbox:" would be better than "mailto:".
>>Moving a document into somone's mail box is just like moving a
>>file into a directory: it is an operation with pre- and  
>>postconditions.

Presumably this is going to be specific to address formats of the
general form we all know and love, "smtp://cs.indiana.edu/mvanheyn"
seems to me the most consistent and unambiguous method for specifying
my mail address.  I think calling something "mail" or "mailto" is
rather unclear, since the number of different ways to specify mail
routing and the like is greater than one.  We already have silly
ambiguity with "file:" being both local file reference and FTP; let's
not do that again with mail.

--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
GUIs are great at representing everything except relationships involving
the word "many".
		- Larry Wall

From guido@cwi.nl  Tue May 11 21:55:11 1993
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18799; Tue, 11 May 93 21:55:11 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06396; Tue, 11 May 1993 22:16:04 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA25264 (5.65b/3.8/CWI-Amsterdam); Tue, 11 May 1993 22:16:02 +0200
Received: by voorn.cwi.nl with SMTP
	id AA02577 (5.65b/3.8/CWI-Amsterdam); Tue, 11 May 1993 22:16:01 +0200
Message-Id: <9305112016.AA02577=guido@voorn.cwi.nl>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Mail addresses as URLs 
In-Reply-To: Your message of "Tue, 11 May 1993 13:20:29 MDT."
             <1632.737144429@moose.cs.indiana.edu> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Tue, 11 May 1993 22:16:00 +0200
Sender: Guido.van.Rossum@cwi.nl

> Presumably this is going to be specific to address formats of the
> general form we all know and love, "smtp://cs.indiana.edu/mvanheyn"
> seems to me the most consistent and unambiguous method for specifying
> my mail address.  I think calling something "mail" or "mailto" is
> rather unclear, since the number of different ways to specify mail
> routing and the like is greater than one.  We already have silly
> ambiguity with "file:" being both local file reference and FTP; let's
> not do that again with mail.

On the contrary (as I argued before), rfc-822 mail addresses are
independent of routing!  E.g. at our site all outgoing mail from a
workstation is first moved onto the central mail server machine which
takes care of delivery using whatever method it sees fit.  In fact
most of our users won't even recognize "smtp" as the name of a mail
delivery protocol.

In general different sites may have different mechanisms to deliver
mail, but the same mail address works for all (ideally, anyway).

Also note that the "host" part of a mail address needn't be the name
of a real host -- it is just a mail domain.  The use of
"smtp://host/user" smells too much of direct delivery at a particular
host, while in fact the proper way to send mail is to hand it to a
local agent that knows what's right...

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>


From mcrae@lib.ucsf.edu  Tue May 11 22:34:54 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19552; Tue, 11 May 93 22:34:54 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18836; Tue, 11 May 1993 22:55:45 +0200
Received: from rossini.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA27120; Tue, 11 May 93 13:54:06 PDT
Message-Id: <9305112054.AA27120@knowman.lib.ucsf.EDU>
To: www-talk@nxoc01.cern.ch
Subject: More about mail URL's/tags
Date: Tue, 11 May 93 13:59:41 MDT
From: Christopher McRae <mcrae@lib.ucsf.edu>


Regarding the issue of embedding email pointers within documents:

  I would like to see some sort of mechanism for including within an
email "form" information about the context from which the meesage was
sent.  For example, as the recipient of such a message, I might want
to know how/where it was generated.  Suppose the same pointer/tag was
embedded in multiple documents, I might want to know that a particular
message was sent from document A so I can go back and change the
reference if necessary/appropriate.  Or perhaps I'd like to know that
over 80% of such messages were being generated from document A and only
10% from document B; then I might be more inclined to spend time on
developing A than B.
  Which header field would be most appropriate to put this info?  News
uses the "Followup-To" header for an analogous purpose; it tells you
the context within which the message was generated.
Chris
-----------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From strick@versant.com  Tue May 11 23:37:51 1993
Return-Path: <strick@versant.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20420; Tue, 11 May 93 23:37:51 MET DST
Received: from [192.70.173.43] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02148; Tue, 11 May 1993 23:58:43 +0200
Received: from osc.osc.com (osc.VERSANT.COM) by versant.com (4.1/SMI-4.1)
	id AA11908; Tue, 11 May 93 15:06:19 PDT
Received: by osc.osc.com (4.1/SMI-4.1)
	id AA25489; Tue, 11 May 93 15:06:15 PDT
Message-Id: <9305112206.AA25489@osc.osc.com>
Subject: Re: The official WWW Hand Gesture
To: timbl@nxoc01.cern.ch
Date: Tue, 11 May 93 15:06:14 PDT
From: henry strickland <strick@versant.com>
Cc: cclark@cnri.reston.va.us, mitra@pandora.sf.ca.us, clw@merit.edu,
        www-talk@nxoc01.cern.ch, wdueber@cs.indiana.edu, tloos@cs.indiana.edu
In-Reply-To: <9305070835.AA18793@www3.cern.ch>; from "Tim Berners-Lee" at May 7, 93 9:35 am

# From timbl@www3.cern.ch  Fri May  7 09:26:37 1993
#
# 	As for WorldWideWeb,  it sounds like it matches similar
# 	criteria.  It is based on W (middle three fingers only
# 	up, palm away from you). I don't know what "3" is.
# 	(Three fingers together?)
# 	Maybe to distinguish "WorldWideWeb" from "W" it has to be
# 	be modified a bit -- perhaps the three fingers of one
# 	hand (W) meeting the three fingers of the other hand (3)
# 	reminicent of Internet, connection, wire.  If something

In ASL, if you shake W's towards each other, you get "war".
( a push-pull sort of conflict sign, with W's for war. )
Accurate as the connotations might be, you might avoid that
for the official sign.

I suggest don't try to make cute puns a language unless you are FLUENT
in it -- or you may get more than you asked for.  Depending on exactly
how the internet sign was done, I could see more similarities to "pain"
than to "friend".  I think I would have modified it to be more like
"story" with "wire" handshapes.  Would have retained the initial "i"
handshape, which is nice.


I'm hearing, and I'm not fluent in signs, but I'll suggest the following anyway.

If you want a sign for WWW, a very easy one is also very natural, and
that is simply to sign W W W.  When a single letter, (particularly one
with a handshape like W) is repeated, you don't open and close your
hand three times to make the W's -- rather you lean the W forward and
down, fingers straight out almost horizontal, and kind of bounce
downward thrice, each time a little to the (right-handed) signer's
right from where the previous one bounced.  The third time down, you
hold it there a moment, and don't bounce it back up.  This
leaning-forward and boucing-to-the-signer's-right is readily understood
to mean repitition.

It would be like the sign for the number "22" or "33", except thrice,
and in ASL the number 3 uses the thumb, index, and middle fingers,
whereas the W uses the three middle fingers. 

It has the advantage that a deaf person who does not know your
secret code sign for WWW would still see "WWW", just as if you said
"WWW" to a hearing person who did not know what WWW means, but could
recognize it later, or plug it into context hearing "World Wide Web".
("World" uses "W" handshapes, and "Wide" can.  I don't know web. )

The only danger I can see with "WWW" is some similarity to "world war
2" or "world war 3".  The context of this proper noun is different
enough from that proper noun that it's probably not a problem.




The best signs come not down from above, bestowed graciously on the
deaf by a hearing authority, but rather trickle up from below, from the
actual communities and their living languages...  and there should
be some deaf communities somewhere on the net, but I'm ignorant where.


				strick

				henry strickland
				strick@osc.versant.com


From mvanheyn@cs.indiana.edu  Wed May 12 06:55:26 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24548; Wed, 12 May 93 06:55:26 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29390; Wed, 12 May 1993 07:16:20 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA07647; Wed, 12 May 1993 00:16:19 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Mail addresses as URLs 
In-Reply-To: Your message of "Tue, 11 May 1993 22:16:00 +0200."
             <9305112016.AA02577=guido@voorn.cwi.nl> 
Date: Wed, 12 May 1993 00:16:18 -0500
Message-Id: <7645.737183778@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: 
>> Presumably this is going to be specific to address formats of the
>> general form we all know and love, "smtp://cs.indiana.edu/mvanheyn"
>> seems to me the most consistent and unambiguous method for specifying
>> my mail address.  I think calling something "mail" or "mailto" is
>> rather unclear, since the number of different ways to specify mail
>> routing and the like is greater than one.  We already have silly
>> ambiguity with "file:" being both local file reference and FTP; let's
>> not do that again with mail.
>
>On the contrary (as I argued before), rfc-822 mail addresses are
>independent of routing!  E.g. at our site all outgoing mail from a
>workstation is first moved onto the central mail server machine which
>takes care of delivery using whatever method it sees fit.  In fact
>most of our users won't even recognize "smtp" as the name of a mail
>delivery protocol.
>
>In general different sites may have different mechanisms to deliver
>mail, but the same mail address works for all (ideally, anyway).

Hmmm... I'll agree that "smtp" is too specific and a bit ill thought
out.  However, I believe that "mail" or "mailto" or the like is too
general.  Something like "rfc822" could be a bit clearer, albeit
rather cryptic.  There has to be a better way.

(Most users I know wouldn't know "rfc822" any more than "smtp", I
acknowledge, but oh well.)
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
De Gaulle remark[s ...] about the American "will to power, cloaking itself in
idealism."  By now, this will to power is not so much cloaked in idealism as
it is drowned in fatuity.		- Chomsky

From marca@wintermute.ncsa.uiuc.edu  Wed May 12 07:13:30 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24634; Wed, 12 May 93 07:13:30 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02231; Wed, 12 May 1993 07:34:24 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA07739
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 12 May 93 00:34:12 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA10169; Wed, 12 May 93 00:36:33 -0500
Date: Wed, 12 May 93 00:36:33 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305120536.AA10169@wintermute.ncsa.uiuc.edu>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch, uri@bunyip.com
Subject: Re: Mail addresses as URLs 
In-Reply-To: <7645.737183778@moose.cs.indiana.edu>
References: <7645.737183778@moose.cs.indiana.edu>
	<9305112016.AA02577=guido@voorn.cwi.nl>
X-Md4-Signature: 6a8c281afa193d40d0e707f58a8364ad

General comments...

smtp is not only cryptic but also not wholly appropriate -- one never
gets information *from* smtp the protocol, and the act of simply
firing off a mail message via the system mailer doesn't really have
anything to do with smtp anyway.

mailto is the most appropriate one I can think of -- mail should be
reserved for reading mailboxes, for if and when that becomes an issue.

It makes little sense to mangle the address into something like
mailto://ncsa.uiuc.edu/marca; what happens with nonstandard addresses
such as uunet!foobaz!bar@cs.utexas.edu or foobar%foobaz@glom.com or
some of the more cryptic addresses (e.g., gatewayed through Sprintmail
-- anyone seen one of those yet?  strange stuff...) that are starting
to pop up?  Sure, there can be mappings established, but why bother?

Cheers,
<a href="mailto:marca@ncsa.uiuc.edu">Marc</a>


From sanders@bsdi.com  Wed May 12 08:31:58 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25255; Wed, 12 May 93 08:31:58 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14925; Wed, 12 May 1993 08:52:51 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA02528; Wed, 12 May 93 01:52:48 -0500
Message-Id: <9305120652.AA02528@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: HTTPD Server
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 12 May 1993 01:52:48 -0500
From: Tony Sanders <sanders@bsdi.com>

I finally picked a name for my server code: Plexus

Plexus Version 1.1.1.1 is available through http://www.bsdi.com/

I integrated the SpaceWalk and Bookmark demos in the source release and
did a lot of cleanup.  Note that the demos moved because of this (I'll
leave pointers to them in the old locations for a while), check out
the home page http://www.bsdi.com/ for pointers.

The documentation is in better shape also.  I've started to split it out
into many files.  I need to add the bookmark stuff, flesh out the internals
part and talk about writing new gateways.

In case you are new to this list I've included some basics about Plexus.

It's great for playing around with new server ideas because you can
prototype them quickly in perl and the server can load them each time they
are accessed so you don't have to restart the server a hundred times.
When you are happy with them you can load them at startup for better
performance.

Plexus Features
---------------

Plexus is an HTTP server writen in perl that includes the
following features:

    Date and Time Gateway
	Displays the date and time using 61 different timezone translations.

    Finger Gateway
	Finger people and print out relevant faces.

    Directory Browser
	Sorted, last modification stamp, file size, and directory indictor.
	Allows HTML headers and footers.  User can specify filters using
	search keyword.

    Fortune
	Print out a fortune from the fortune database.

    Calendar
	Prints out calendars by month and year, will also do whole years.

    Restricted Access Directories
	Restricte access by account number and IP address.

    Image Decoding Libaray
	Find objects in images using bitmasks.

    Directory Search
	Search directory trees using perl regular expressions.

    Bookmark
	Iconic UP, FORW, and BACK using image decoding library and menus
	embedded in the URL.

--sanders@bsdi.com

From cclark@cnri.reston.va.us  Wed May 12 15:12:14 1993
Return-Path: <cclark@cnri.reston.va.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29633; Wed, 12 May 93 15:12:14 MET DST
Received: from ietf.cnri.reston.va.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18352; Wed, 12 May 1993 15:33:03 +0200
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05946;
          12 May 93 9:23 EDT
To: henry strickland <strick@versant.com>
Cc: timbl@nxoc01.cern.ch, cclark@cnri.reston.va.us, mitra@pandora.sf.ca.us,
        clw@merit.edu, www-talk@nxoc01.cern.ch, wdueber@cs.indiana.edu,
        tloos@cs.indiana.edu
Subject: Re: The official WWW Hand Gesture 
In-Reply-To: Your message of "Tue, 11 May 93 15:06:14 PDT."
             <9305112206.AA25489@osc.osc.com> 
Date: Wed, 12 May 93 09:23:00 -0400
From: Cynthia Clark <cclark@cnri.reston.va.us>
Message-Id:  <9305120923.aa05946@IETF.CNRI.Reston.VA.US>


 > In ASL, if you shake W's towards each other, you get "war".
 > ( a push-pull sort of conflict sign, with W's for war. )
 > Accurate as the connotations might be, you might avoid that
 > for the official sign.

 > I suggest don't try to make cute puns a language unless you are FLUENT
 > in it -- or you may get more than you asked for.  Depending on exactly
 > how the internet sign was done, I could see more similarities to "pain"
 > than to "friend".  I think I would have modified it to be more like
 > "story" with "wire" handshapes.  Would have retained the initial "i"
 > handshape, which is nice.

 > If you want a sign for WWW, a very easy one is also very natural, and
 > that is simply to sign W W W.  When a single letter, (particularly one
 > with a handshape like W) is repeated, you don't open and close your
 > hand three times to make the W's -- rather you lean the W forward and
 > down, fingers straight out almost horizontal, and kind of bounce
 > downward thrice, each time a little to the (right-handed) signer's
 > right from where the previous one bounced.  The third time down, you
 > hold it there a moment, and don't bounce it back up.  This
 > leaning-forward and boucing-to-the-signer's-right is readily understood
 > to mean repitition.

 > It would be like the sign for the number "22" or "33", except thrice,
 > and in ASL the number 3 uses the thumb, index, and middle fingers,
 > whereas the W uses the three middle fingers. 

 > It has the advantage that a deaf person who does not know your
 > secret code sign for WWW would still see "WWW", just as if you said
 > "WWW" to a hearing person who did not know what WWW means, but could
 > recognize it later, or plug it into context hearing "World Wide Web".
 > ("World" uses "W" handshapes, and "Wide" can.  I don't know web. )

 > The only danger I can see with "WWW" is some similarity to "world war
 > 2" or "world war 3".  The context of this proper noun is different
 > enough from that proper noun that it's probably not a problem.

 > The best signs come not down from above, bestowed graciously on the
 > deaf by a hearing authority, but rather trickle up from below, from the
 > actual communities and their living languages...  and there should
 > be some deaf communities somewhere on the net, but I'm ignorant where.


As a deaf person myself, I'm fluent in both ASL and English sign languages.
I had an interesting conversation with Tim Berners-Lee, Chris Weider, 
Mitra, Steven Foster and Naomi Courter.  We actually invented a new sign 
for "Internet" - just like what Tim mentioned earlier.   The sign has the 
combination as a "network", "friend" and "wire".

I've been thinking about WWW something similiar, but to "distribute
information worlwide on-line".  Perhaps we could get together again
at Amsterdam if anyone interested in sharing ideas to create a new sign 
for WWW.

I agree that we could avoid anything "war" or "cutesy".

Cheers,

Cynthia Clark




From germuska@antioch.acns.nwu.edu  Wed May 12 18:24:34 1993
Return-Path: <germuska@antioch.acns.nwu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03797; Wed, 12 May 93 18:24:34 MET DST
Received: from antioch.acns.nwu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02719; Wed, 12 May 1993 18:45:28 +0200
Received: by antioch.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA12920; Wed, 12 May 93 11:45:26 CDT
From: germuska@antioch.acns.nwu.edu (Joe Germuska)
Message-Id: <9305121645.AA12920@antioch.acns.nwu.edu>
Subject: Formatting Options in HTML?
To: www-talk@nxoc01.cern.ch
Date: Wed, 12 May 1993 11:45:24 -0500 (CDT)
Reply-To: j-germuska@nwu.edu (Joe Germuska)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 977       

Hmmm... I'm looking, and I don't see HTML tags for some simple markup
features like, for example, <CENTER> or <FLUSHRIGHT>

Now this may be because HTML is, as a subset of SGML, not supposed to be so
specific about formatting.  But to create aesthetically pleasing documents,
one needs a little more than flush-left/ragged right text!  It seems that
center and flush right (and maybe even justified) could all be interpreted
by any client to fit the appropriate display size, and it'd make for a
little variety in HTML docs as well...

Also, I'm sure it's there, but I haven't run into it -- is there a
canonical list of HTML tags?  That isn't the DTD but something more
friendly to look at?  

Thanks,
	Joe

PS Thanks all who have submitted comments on http://www.acns.nwu.edu/ --
and the rest of you, please come on over!
-- 
joe germuska | j-germuska@nwu.edu | Network Response Center
ACNS-Distributed Systems Services, Northwestern University
Ceci n'est pas une signature.

From dcmartin@lib.ucsf.edu  Wed May 12 19:31:40 1993
Return-Path: <dcmartin@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04857; Wed, 12 May 93 19:31:40 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15818; Wed, 12 May 1993 19:52:33 +0200
Received: from [128.218.15.236] by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA00781; Wed, 12 May 93 10:50:37 PDT
Message-Id: <9305121750.AA00781@knowman.lib.ucsf.EDU>
From: dcmartin@ckm.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: Guido.van.Rossum@cwi.nl
Cc: Marc VanHeyningen <mvanheyn@cs.indiana.edu>, www-talk@nxoc01.cern.ch
In-Reply-To: Your message of Tue, 11 May 93 22:16:00 +0100
	<9305112016.AA02577=guido@voorn.cwi.nl> 
Subject: Re: Mail addresses as URLs 
Date: Wed, 12 May 93 10:49:42 MDT
Sender: dcmartin@lib.ucsf.edu

Agreed.

dcm
--------
Guido.van.Rossum@cwi.nl writes:

> Presumably this is going to be specific to address formats of the
> general form we all know and love, "smtp://cs.indiana.edu/mvanheyn"
> seems to me the most consistent and unambiguous method for specifying
> my mail address.  I think calling something "mail" or "mailto" is
> rather unclear, since the number of different ways to specify mail
> routing and the like is greater than one.  We already have silly
> ambiguity with "file:" being both local file reference and FTP; let's
> not do that again with mail.

On the contrary (as I argued before), rfc-822 mail addresses are
independent of routing!  E.g. at our site all outgoing mail from a
workstation is first moved onto the central mail server machine which
takes care of delivery using whatever method it sees fit.  In fact
most of our users won't even recognize "smtp" as the name of a mail
delivery protocol.

In general different sites may have different mechanisms to deliver
mail, but the same mail address works for all (ideally, anyway).

Also note thatthe "host" part of a mail address needn't be the name
of a real host -- it is just a mail domain.  The use of
"smtp://host/user" smells too much of direct delivery at a particular
host, while in fact the proper way to send mail is to hand it to a
local agent that knows what's right...

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>


From marca@wintermute.ncsa.uiuc.edu  Wed May 12 19:58:40 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05524; Wed, 12 May 93 19:58:40 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19270; Wed, 12 May 1993 20:19:34 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28142
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 12 May 93 13:19:32 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA04510; Wed, 12 May 93 13:21:50 -0500
Date: Wed, 12 May 93 13:21:50 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305121821.AA04510@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, uri@bunyip.com
Cc: marca@ncsa.uiuc.edu
Subject: Re: Mail addresses as URLs (clarification)
X-Md4-Signature: 7c12472133d45b386aaaf43f4a28c178

I previously wrote:
> >some of the more cryptic addresses (e.g., gatewayed through Sprintmail
> >-- anyone seen one of those yet?  strange stuff...) that are starting
> >to pop up?  Sure, there can be mappings established, but why bother?

....which apparently caused some misunderstandings.  My point, which I
thought was clear, was that email addresses, including
Sprintmail/X.400 addresses, should be left alone and not arbitrarily
rearranged as part of a 'mailto' or 'smtp' URL.  That is,
marca@ncsa.uiuc.edu should be:

        mailto:marca@ncsa.uiuc.edu

and not:
        
        mailto://ncsa.uiuc.edu/marca

and a Sprintmail address like (just to make one up)
/PN=joe.blow/FOO=bar/BLAZ=blech/ARGH=urgh@sprint.com should be:

        mailto:/PN=joe.blow/FOO=bar/BLAZ=blech/ARGH=urgh@sprint.com

and not:

        mailto://sprint.com//PN=joe.blow/FOO=bar/BLAZ=blech/ARGH=urgh

or:

        mailto://sprint.com/ARGH=urgh/BLAZ=blech/FOO=bar/PN=joe.blow

or whatever.

Again, my point was: email addresses (including Sprintmail/X.400)
GOOD, rearranging email addresses BAD.

Hope that clears things up.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From sanders@bsdi.com  Wed May 12 20:39:34 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06288; Wed, 12 May 93 20:39:34 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29197; Wed, 12 May 1993 21:00:26 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA04168; Wed, 12 May 93 14:00:24 -0500
Message-Id: <9305121900.AA04168@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Mail addresses as URLs (clarification) 
In-Reply-To: Marc Andreessen's message of Wed, 12 May 93 13:21:50 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 12 May 1993 14:00:23 -0500
From: Tony Sanders <sanders@bsdi.com>

Just a thought, couldn't the broswer allow selection of <ADDRESS>...</ADDRESS>
fields and pop up a mail dialog with that data in the To: field?  Or something
along those lines?

Maybe I don't fully understand the problem you are trying to solve
(please educate me if that is the case).

--sanders
Omit needless features -- paraphrasing William Strunk Jr.

From fine@cis.ohio-state.edu  Wed May 12 21:22:54 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07092; Wed, 12 May 93 21:22:54 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08312; Wed, 12 May 1993 21:43:49 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA08513; Wed, 12 May 93 15:43:45 -0400
Date: Wed, 12 May 93 15:43:45 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305121943.AA08513@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: comp.infosystems.www
X-Mailer: Perl Mail System v1.2


We have a newsgroup.  (At least it's shown up here).  Does anyone
(who knows what they're getting into) want to volunteer to do a
bidirectional gateway for this mailing list?  Also, how many people
out there would need such a gateway (i.e. no access to USENET)?

	tom


From timbl  Wed May 12 22:40:17 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08909; Wed, 12 May 93 22:40:17 MET DST
Date: Wed, 12 May 93 22:40:17 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9305122040.AA08909@ nxoc01.cern.ch >
To: j-germuska@nwu.edu
Subject: Re: Formatting Options in HTML?
Cc: www-talk@nxoc01.cern.ch

You are dead right, HTML is not supposed to be specific
about formatting.  If we started with justification, where would
it end?  (Actually, we started with <I> for italic, but there
it ended.) 

Notice that even the line mode browser centers H1 headings
and right justifies ADDRESS sections for example.
I think that Mosaic for X doesn't because the text widget
used doesn't have any justification or tabbing.  
There is no reason why a browser should not have the
justufication style user-defined for each element.
Cello allows you to tailor a lot of things, maybe that,
(checks.) Not on my preprealpha version.

There have been a lot of advantges in sticking to the
logical markup rule.  It has allowed lots of browsers
to be creative and flexible in presentation, and
has allowed for example TeX to be generated intelligently
from a set of HTML documents.  If explicit markup had been
there, it would not have been possible.

Tim BL

From timbl  Wed May 12 22:51:15 1993
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09268; Wed, 12 May 93 22:51:15 MET DST
Date: Wed, 12 May 93 22:51:15 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9305122051.AA09268@ nxoc01.cern.ch >
To: sanders@bsdi.com
Subject: Re: Mail addresses as URLs (clarification)
Cc: www-talk@nxoc01.cern.ch

The ADDRESS tag is used for formatting things in an addres-like
way.  people use it for all kinds of stuff email and paper mail
addresses, etc etc.  It is a visible thing, not a hidden link.

There are many more uses of the mailto: URL.

	From sanders@bsdi.com Wed May 12 20:39:49 1993
	Return-Path: <sanders@bsdi.com>
	Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
		id AA06288; Wed, 12 May 93 20:39:34 MET DST
	Errors-To: sanders@bsdi.com
	Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
		id AA29197; Wed, 12 May 1993 21:00:26 +0200
	Received: from localhost by austin.BSDI.COM (5.67/1.37)
		id AA04168; Wed, 12 May 93 14:00:24 -0500
	Message-Id: <9305121900.AA04168@austin.BSDI.COM>
	To: www-talk@nxoc01.cern.ch
	Subject: Re: Mail addresses as URLs (clarification) 
	In-Reply-To: Marc Andreessen's message of Wed, 12 May 93 13:21:50 CDT.
	Errors-To: sanders@bsdi.com
	Reply-To: sanders@bsdi.com
	Organization: Berkeley Software Design, Inc.
	Date: Wed, 12 May 1993 14:00:23 -0500
	From: Tony Sanders <sanders@bsdi.com>

	Just a thought, couldn't the broswer allow selection of <ADDRESS>...</ADDRESS>
	fields and pop up a mail dialog with that data in the To: field?  Or something
	along those lines?

	Maybe I don't fully understand the problem you are trying to solve
	(please educate me if that is the case).

	--sanders
	Omit needless features -- paraphrasing William Strunk Jr.


From totic@milton.cs.uiuc.edu  Wed May 12 23:34:12 1993
Return-Path: <totic@milton.cs.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10321; Wed, 12 May 93 23:34:12 MET DST
Received: from milton.cs.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04307; Wed, 12 May 1993 23:55:08 +0200
Received: by milton.cs.uiuc.edu id AA29066
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 12 May 1993 16:53:54 -0500
From: Aleksandar Totic <totic@milton.cs.uiuc.edu>
Message-Id: <199305122153.AA29066@milton.cs.uiuc.edu>
Subject: Re: Formatting Options in HTML?
To: www-talk@nxoc01.cern.ch
Date: Wed, 12 May 93 16:53:50 CDT
In-Reply-To: <9305122040.AA08909@ nxoc01.cern.ch >; from "Tim Berners-Lee" at May 12, 93 10:40 pm
X-Mailer: ELM [version 2.3 PL11]

> You are dead right, HTML is not supposed to be specific
> about formatting.  If we started with justification, where would
> it end?  (Actually, we started with <I> for italic, but there
> it ended.) 

I agree that HTML should not be specific about formatting. But it
would be good if there were better guidelines about how browsers
should implement formatting instructions. This is because writers of
hypertext make some assumptions about how will their text be
presented. For example, when should carriage returns be inserted into
text? Many writers assume that CR is inserted automatically before
each header line, and do not put it in there explicitly. Now, someone
else might want to make a list item appear in the header style, like
this: 
 <LI><H1> This item should attract attention </H1>

The formatter that inserted CR before each header would add an
unintended CR when header starts, and line would come out like this:

 o
This item should attract attention

instead of like this:

 o This item shoud attract attention

To correct this problem, the parser could either not insert CR before
the header, or use a rule of thumb like "do not insert CR before
header when you are in the line item".

I am thinking about adding such rules to my parser. But then whoever
edits documents and uses my parser to look at them, and then sees
their text displayed differently on another parser, will complain.

If there are no guidelines, the writers might just settle down for the
simplest formatting. I would prefer some kind of standard, so that
people who desire some variety in their text could get it.

Aleks


From raisch@ora.com  Thu May 13 01:37:44 1993
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12427; Thu, 13 May 93 01:37:44 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28320; Thu, 13 May 1993 01:58:40 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA21334; Wed, 12 May 1993 19:58:34 -0400
Date: Wed, 12 May 1993 19:54:46 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Re: Formatting Options in HTML?
To: Joe Germuska <j-germuska@nwu.edu>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305121645.AA12920@antioch.acns.nwu.edu>
Message-Id: <Pine.3.03.9305121944.A12880-a100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



Although it's not quite polished enough to share, the Digital Media Group
within O'Reilly and Assoc. is working on a proposal and library to support
stylistic hints or suggestions which can be available to a browser which
would like to attempt to render a document as close as possible to the
publisher's original intent.

I just thought I would mention that there is some hope on the horizon. 
Fear not!  I'll try to polish what we have up quickly so that we can get
the community involved.  </rr>



From marca@wintermute.ncsa.uiuc.edu  Thu May 13 02:43:33 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13008; Thu, 13 May 93 02:43:33 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08644; Thu, 13 May 1993 03:04:29 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA01023
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Wed, 12 May 93 20:04:25 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:j-germuska@nwu.edu id AA17339; Wed, 12 May 93 20:06:48 -0500
Date: Wed, 12 May 93 20:06:48 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305130106.AA17339@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
Cc: j-germuska@nwu.edu, www-talk@nxoc01.cern.ch
Subject: Re: Formatting Options in HTML?
In-Reply-To: <9305122040.AA08909@ nxoc01.cern.ch >
References: <9305122040.AA08909@ nxoc01.cern.ch >
X-Md4-Signature: 5ef28352bad7e2564b236c631529f214

Tim Berners-Lee writes:
> Notice that even the line mode browser centers H1 headings and right
> justifies ADDRESS sections for example.  I think that Mosaic for X
> doesn't because the text widget used doesn't have any justification
> or tabbing.  There is no reason why a browser should not have the
> justufication style user-defined for each element.

Mosaic (i.e. the HTML widget) had centering at one point, but it
wasn't used because we thought headers looked better without.  At some
point we'll do full style sheets, and have it as an option...

(However, that does raise the question of what it means to have
headers embedded in other elements, and if that's even allowable, as
has been bandied about here in the past.)

Marc


From janssen@parc.xerox.com  Thu May 13 04:15:42 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13710; Thu, 13 May 93 04:15:42 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24862; Thu, 13 May 1993 04:36:36 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11996>; Wed, 12 May 1993 19:36:28 PDT
Received: by holmes.parc.xerox.com id <16149>; Wed, 12 May 1993 19:36:12 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 12 May 1993 19:36:00 -0700 (PDT)
Message-Id: <0fwPEE4B0KGWBBYNou@holmes.parc.xerox.com>
Date: 	Wed, 12 May 1993 19:36:00 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, fine@cis.ohio-state.edu
Subject: Re: comp.infosystems.www
In-Reply-To: <9305121943.AA08513@soccer.cis.ohio-state.edu>
References: <9305121943.AA08513@soccer.cis.ohio-state.edu>

Excerpts from ext.WorldWideWeb: 12-May-93 comp.infosystems.www
fine@cis.ohio-state.edu (271)

> Does anyone
> (who knows what they're getting into) want to volunteer to do a
> bidirectional gateway for this mailing list?

Please don't set up a bi-directional gateway.  Just forward this list to
the newsgroup.  Having to discard umpteen messages from various gawkers
at different educational sites is one of the fastest ways to kill an
interesting list.  Having to send to the mailing list (and having to
find out what the mailing list is) provides a small but useful filter on
input noise.

Bill

From janssen@parc.xerox.com  Thu May 13 04:18:57 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13742; Thu, 13 May 93 04:18:57 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25666; Thu, 13 May 1993 04:39:53 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11993>; Wed, 12 May 1993 19:39:39 PDT
Received: by holmes.parc.xerox.com id <16149>; Wed, 12 May 1993 19:39:33 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 12 May 1993 19:39:23 -0700 (PDT)
Message-Id: <UfwPHPMB0KGW1BYOFH@holmes.parc.xerox.com>
Date: 	Wed, 12 May 1993 19:39:23 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, j-germuska@nwu.edu (Joe Germuska)
Subject: Re: Formatting Options in HTML?
In-Reply-To: <9305121645.AA12920@antioch.acns.nwu.edu>
References: <9305121645.AA12920@antioch.acns.nwu.edu>

Rather than add things like <CENTER> and <FLUSH-RIGHT> to the HTML
document, it seems that this sort of thing should be decided by the user
in their browser.  That is, probably most text should be filled and both
right and left justified by default, unless the user specifies
otherwise.  The user should be able to specify things like this for
different region-types of all documents, not for specific regions of
specific documents.

Bill

From alien%postman.essex.ac.uk@essex.ac.uk  Thu May 13 10:02:01 1993
Return-Path: <alien%postman.essex.ac.uk@essex.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16329; Thu, 13 May 93 10:02:01 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26542; Thu, 13 May 1993 10:08:37 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Thu, 13 May 1993 10:08:18 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Thu, 13 May 1993 10:06:15 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Thu, 13 May 1993 10:06:07 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Thu, 13 May 1993 10:06:00 +0200
Date: Thu, 13 May 1993 10:06:00 +0200
X400-Originator: alien <alien@postman.essex.ac.uk>
X400-Recipients: www-talk@NXOC01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<1390.9305130806@vulcan.essex.ac]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Formatting Op...
From: Adrian F Clark <alien@postman.essex.ac.uk>
Message-Id: <1390.9305130806@vulcan.essex.ac.uk.essex.ac.uk>
To: www-talk@nxoc01.cern.ch
In-Reply-To: <9305122040.AA08909@ nxoc01.cern.ch >
Subject: Formatting Options in HTML?

On Wed, 12 May 93 22:40:17 MET DST, timbl%NXOC01.CERN.CH@uk.ac.essex.mailhost said:

t> There have been a lot of advantges in sticking to the
t> logical markup rule.  It has allowed lots of browsers
t> to be creative and flexible in presentation, and
t> has allowed for example TeX to be generated intelligently
t> from a set of HTML documents.  If explicit markup had been
t> there, it would not have been possible.

People might be interested to know that a couple of colleagues and I
have successfully produced a hypertext/multimedia previewer for TeX,
and a LaTeX style file to encapsulate these features.  The mark-up is
still logical in nature, though no longer SGML of course.  This means
that centred and flushed text is possible -- and mathematics, which is
important for my purposes.  And images, sound, video, and even limited
interaction with the underlying system.

As things stand, the hypertext is not compatible with WWW but, as soon
as I feel I understand WWW and HTML, I'll have a go at a previewer
that uses a compatible hypertext mechanism.  However, I don't see how
I could make it compatible with existing previewers: the features
offered by (La-)TeX are significantly greater, as far as I can tell,
than those available in any existing WWW viewer.

..Adrian

 Dr Adrian F. Clark                                   JANET: alien@uk.ac.essex
 INTERNET: alien%uk.ac.essex@nsfnet-relay.ac.uk          FAX: (+44) 206-872900
 BITNET: alien%uk.ac.essex@ac.uk              PHONE: (+44) 206-872432 (direct)
 Dept ESE, University of Essex, Wivenhoe Park, Colchester, Essex, C04 3SQ, UK.

From timbl@www3.cern.ch  Thu May 13 10:08:19 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16437; Thu, 13 May 93 10:08:19 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01908; Thu, 13 May 1993 10:29:16 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05839; Thu, 13 May 93 10:24:01 +0100
Date: Thu, 13 May 93 10:24:01 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305130924.AA05839@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Aleksandar Totic <totic@milton.cs.uiuc.edu>
Subject: Re: Formatting Options in HTML?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> From: Aleksandar Totic <totic@milton.cs.uiuc.edu>
> Subject: Re: Formatting Options in HTML?

> I agree that HTML should not be specific about formatting. But it
> would be good if there were better guidelines about how browsers
> should implement formatting instructions.

I have added some "Typical rendering" instructions to the
descriptions of headings, lists, P, ADDRESS, etc., in the HTML
description linked to
http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
which might help.

> This is because writers of
> hypertext make some assumptions about how will their text be
> presented. For example, when should carriage returns be inserted  
into
> text? Many writers assume that CR is inserted automatically before
> each header line, and do not put it in there explicitly

Absolutely.  Those conversant with SGML realise that the H1 means
"this is a heading, do everything which is appropriate"
which implies paragraph break, maybe a new page if H1 is printed on  
paper, a big font, numbering maybe (not on the screen, please, but  
perhaps on paper), centering maybe, and lots of luverly white
space all over to make it stand out and easyto read, and an entry in  
a table of contents anyone might be generating, plus extra weighting  
of all the heading words in any full text index anyone might be  
generating. Much more than a font change, folks.

> Now, someone
> else might want to make a list item appear in the header style,  
like
> this: 

>  <LI><H1> This item should attract attention </H1>


Aaagh.  Look at the DTD:  Not allowed.  Why? because it doesn't
make sense.  The heading isn't a style, its a heading.  Putting an H1
in a list is like putting an engine on a fruit tree.

The elements H1..H6, ADDRESS, UL, DL, BLOCKQUOTE imply paragraph  
break and a special paragraph style.  Do not confuse these with the
character highlighting elements, listed separately, such as EM, (and  
A) which do NOT cause a beak or define paragraph style.

> If there are no guidelines, the writers might just settle down for  
the
> simplest formatting. I would prefer some kind of standard, so that
> people who desire some variety in their text could get it.

Ok, could you look at what there is and tell me where it is  
inadequate? Thanks
 

> Aleks
 

Tim


From bloemer@tnt.uni-hannover.dbp.de  Thu May 13 15:28:17 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20805; Thu, 13 May 93 15:28:17 MET DST
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29143; Thu, 13 May 1993 14:49:26 +0200
Received: by ixgate.gmd.de id AA25790; Thu, 13 May 93 14:48:26 +0200
Date: 13 May 93 12:48 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: www-talk@nxoc01.cern.ch
Message-Id: <RFC-822:>
Subject: TeXinfo Gateway

RFC-822-HEADERS:
Cc: bloemer

==================
Does anybody know how to get the source code for the TeXinfo Gateway, 
which is installed at ohio-state ?

I couldn't find it on info.cern.ch.

Arnold


________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49 511 762-5333           D-3000 Hannover 1
phone:  +49 511 762-5320           Germany
________________________________________________________________________________






From timbl@www3.cern.ch  Thu May 13 16:59:50 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22792; Thu, 13 May 93 16:59:50 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14592; Thu, 13 May 1993 11:15:17 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05938; Thu, 13 May 93 11:10:03 +0100
Date: Thu, 13 May 93 11:10:03 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305131010.AA05938@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Adrian F Clark <alien@postman.essex.ac.uk>
Subject: Hyper Tex viewer
Cc: www-talk@nxoc01.cern.ch, goossens@crnvma.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Thu, 13 May 1993 10:06:00 +0200
> From: Adrian F Clark <alien@postman.essex.ac.uk>

> People might be interested to know that a couple of colleagues and  
I
> have successfully produced a hypertext/multimedia previewer for  
TeX,
> and a LaTeX style file to encapsulate these features.


This sounds very interesting. Not least, because we have a lot of TeX
and a lot of math.  Does the previewer operate on TeX files directly,
or does it need precompiling to dvi?

Obvioulsy one can convert HTML to TeX but not back.  The most  
important thing for you to stick to is the W3 addressing (URL)
syntax for the links.  This will allow your TeX documents to
be part of the web, wherever they are.

WWW servers have the possibility of providing alternative
representations depending on the capabilities of the client.
It might be interesting to look at automatic conversion of
HyperLaTex documents to HTML, with aplogies inserted
in place of equations, so that one an have universal readership
of a document with HTML, with those who can display the TeX
using that.

> The mark-up is
> still logical in nature, though no longer SGML of course.  This  
means
> that centred and flushed text is possible -- and mathematics, which  
is
> important for my purposes.  And images, sound, video,

This sounds like extensions to TeX!  I assume you point to or
embedd foreign objects like JPEG etc. Correct?

> and even limited
> interaction with the underlying system.

O-Oh... security problems?  Same applies, but for JPEG read
scipt?

> As things stand, the hypertext is not compatible with WWW but, as  
soon
> as I feel I understand WWW and HTML, I'll have a go at a previewer
> that uses a compatible hypertext mechanism.  However, I don't see  
how
> I could make it compatible with existing previewers: the features
> offered by (La-)TeX are significantly greater, as far as I can  
tell,
> than those available in any existing WWW viewer.

Certainly the author has more control over format, and can achieve
many more things.  The reader loses control over the format, unless
he can tweak standardized TeX macros which are used by the document.

Will you be able to produce a wysiwyg editor?

> ..Adrian


Tim Berners-Lee

From dsr@hplb.hpl.hp.com  Thu May 13 17:19:18 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23433; Thu, 13 May 93 17:19:18 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02685; Thu, 13 May 1993 12:09:05 +0200
Received: from otter.hpl.hp.com by hplb.hpl.hp.com; Thu, 13 May 93 11:02:01 +0100
Received: by otter.hpl.hp.com
	(16.6/15.6+ISC) id AA00329; Thu, 13 May 93 11:07:18 +0100
From: Dave Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305131007.AA00329@otter.hpl.hp.com>
Subject: Re: Mail addresses as URLs
To: www-talk@nxoc01.cern.ch
Date: Thu, 13 May 93 11:07:18 BST
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, davis@dri.cornell.edu
Mailer: Elm [revision: 66.25]

In <9305111102.AA02689@www3.cern.ch> Tim discusses email & URLs:

Tim's suggested format for email URL:

>        mailto:user@host

Seems fine to me, except I would prefer the prefix "email:", as in

        <A TITLE="add www-announce" HREF="email:listserv@info.cern.ch">

I too am doubtful about including the mail headers as part of the URL,
but note that the optional TITLE attribute for anchors can be used to
specify a title field. Clicking this link would bring up a mail-window
(e.g. "xterm elm listserv@info.cern.ch") so that the user can then
type the body of the message and modify the headers.

Peter Lister's suggestion for the equivalent of a "paper reply-paid card"
with boxes to be filled out by the customer, would be a good fit for a
form, invoked by clicking the link. In this case the form would be specified
as a separate document, which when completed is mailed rather than being
sent back to the server.

> * The To: and From: fields of messages would be treatable
> as hypertext links, just as the Newsgroup: and Reference: fields
> are now.

Good idea.

> * A link type <LINK REL="AUTHOR" HREF="bloggs@acme.com"> would be
>  a formal way of attributing responsability.

This is not at neat - the parser needs to know that REL="AUTHOR" implies
that the HREF is an email address. It would be more straightforward to
stick to the previous format and require the presence of the "email:" prefix.

        <LINK REL="AUTHOR" HREF="email:bloggs@acme.com">

Jim Davis comments:

> So though I have no specific syntactic proposal to make I
> suggest reply mail might be either
>  1) a special case of general programmatic invocation
>  2) a special case of form-filling-queries

> On the other hand I recognize the trend of late in WWW to
> implement special purpose features in an adhoc manner without
> trying to design the ultimate feature set; and this may even
> be a good idea given our lack of experience in the matter.

Jim, there is no need to implement special purpose features for this. We will
be able to handle forms in a general way with HMML and the new HTRQ and HTTP
protocols. The addition of "email:" (or mailto) to the URL format is
a logical extension.

Cheers,

Dave Raggett

n.b. Jim, I am currently drafting a proposed standard for HMML (aka HTML+)
     and will distribute the results real soon now. Send your input to
     me c/o www-talk discussion group.

From cailliau@cernnext.cern.ch  Thu May 13 17:23:42 1993
Return-Path: <cailliau@cernnext.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23566; Thu, 13 May 93 17:23:42 MET DST
Received: from www2.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12263; Thu, 13 May 1993 17:44:37 +0200
From: cailliau@cernnext.cern.ch
Received: by www2.cern.ch (NX5.67c/NX3.0S)
	id AA05736; Thu, 13 May 93 17:44:19 +0200
Date: Thu, 13 May 93 17:44:19 +0200
Message-Id: <9305131544.AA05736@www2.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Mac WWW version 1.00
Cc: www1.ext@dxcern.cern.ch

There is a version of a Mac browser now available as a  
self-extracting archive on info.cern.ch in pub/www/bin/mac
Consult the README file too.
This browser does not have all features for all persons.
We hope to steadily improve it.
Note that you MUST install MacTCP version 1.1.1 or later because of a  
bug in earlier versions.

Robert Cailliau / Nicola Pellow

From murray@sco.com  Thu May 13 18:22:02 1993
Return-Path: <murray@sco.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24893; Thu, 13 May 93 18:22:02 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10628; Thu, 13 May 1993 15:35:02 +0200
Received: by mcsun.EU.net via EUnet
	id AA27140 (5.65b/CWI-2.217); Thu, 13 May 1993 15:34:59 +0200
Received: from sco.sco.COM by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA28687; Thu, 13 May 93 09:34:26 -0400
Received: from scocan.scocan.sco.COM by sco.sco.COM
	id ac22075; Thu, 13 May 93 6:34:06 PDT
Received: from dali.scocan.sco.COM by scocan.scocan.sco.COM id aa09226;
          13 May 93 9:30 EDT
Subject: subscribe
To: www-talk@nxoc01.cern.ch
Date: Thu, 13 May 1993 09:30:32 -0400 (EDT)
From: Murray Maloney <murray@sco.com>
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 611       
Message-Id:  <9305130930.aa18185@dali.scocan.sco.COM>

Please add me to the www-talk subscription. Thanks.

Murray



===========================================================================
---------------------------------------------------------------------------
Murray C. Maloney			Internet:  murray@sco.com
Manager, Technical Publications		Uucp:	   ...uunet!sco!murray
SCO Canada, Inc.			Phone:	   (416) 922-1937
130 Bloor Street West, 10th Floor	Fax:	   (416) 922-2704
Toronto, Ontario, Canada  M5S 1N5	
===========================================================================
---------------------------------------------------------------------------

From marca@wintermute.ncsa.uiuc.edu  Thu May 13 19:27:04 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26517; Thu, 13 May 93 19:27:04 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22205; Thu, 13 May 1993 19:48:01 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA13028
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 13 May 93 12:47:59 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14934; Thu, 13 May 93 12:50:25 -0500
Date: Thu, 13 May 93 12:50:25 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305131750.AA14934@wintermute.ncsa.uiuc.edu>
To: Adrian F Clark <alien@postman.essex.ac.uk>
Cc: www-talk@nxoc01.cern.ch
Subject: Formatting Options in HTML?
In-Reply-To: <1390.9305130806@vulcan.essex.ac.uk.essex.ac.uk>
References: <1390.9305130806@vulcan.essex.ac.uk.essex.ac.uk>
	<9305122040.AA08909@ nxoc01.cern.ch >
X-Md4-Signature: acbdaada63f8b5bab59fece5c2bf3f00

Adrian F Clark writes:
> People might be interested to know that a couple of colleagues and I
> have successfully produced a hypertext/multimedia previewer for TeX,
> and a LaTeX style file to encapsulate these features.  The mark-up is
> still logical in nature, though no longer SGML of course.  This means
> that centred and flushed text is possible -- and mathematics, which is
> important for my purposes.  And images, sound, video, and even limited
> interaction with the underlying system.
> 
> As things stand, the hypertext is not compatible with WWW but, as soon
> as I feel I understand WWW and HTML, I'll have a go at a previewer
> that uses a compatible hypertext mechanism.  However, I don't see how
> I could make it compatible with existing previewers: the features
> offered by (La-)TeX are significantly greater, as far as I can tell,
> than those available in any existing WWW viewer.

Is it available?

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From fine@cis.ohio-state.edu  Thu May 13 20:04:51 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27407; Thu, 13 May 93 20:04:51 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24441; Thu, 13 May 1993 20:25:48 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA01070; Thu, 13 May 93 14:25:44 -0400
Date: Thu, 13 May 93 14:25:44 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305131825.AA01070@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: comp.infosystems.www
X-Mailer: Perl Mail System v1.2


Good news!  I've convinced my news admin to set up the gateway.  What I'd
like to do now is have a fast informal vote on various possibilities.
Please vote on only one proposal.

Proposal 1.
  No gateway, let the mailing list die.
  Vote here if you are planning on reading the newsgroup and unsubscribing
  from the mailing list.  Note that there will be at least a one-direction
  gateway; I just wonder how may people won't care if it is there.

Proposal 2.
  Bi-directional gateway.
  Vote here if you have no USENET access whatsoever and want to use the
  mailing list as an interface to the newsgroup

Proposal 3.
  One-directional gateway. (from mailing list to newsgroup)
  Vote here if you can read USENET, but not post, or if you want the
  mailing list to become a small subset of the newsgroup, so you won't
  have to read the newsgroup.

Proposal 4.
  One-directional gateway plus newsgroup archiving under the Web.
  Vote here for a compromise between Prop 2 and Prop 3.

Proposal 5.
  One and a half directional gateway.  Articles are sent from mailing
  list to newsgroup.  Digests of articles are sent from newsgroup to
  mailing list.
  Vote here if for reasons I can't imagine.  Well, maybe if you
  are a uucp site, with no USENET or Web access.  Yuck.

           tom

From janssen@parc.xerox.com  Fri May 14 02:17:14 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04196; Fri, 14 May 93 02:17:14 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10964; Fri, 14 May 1993 02:38:00 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12042>; Thu, 13 May 1993 17:37:42 PDT
Received: by holmes.parc.xerox.com id <16149>; Thu, 13 May 1993 17:37:31 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 13 May 1993 17:37:30 -0700 (PDT)
Message-Id: <kfwib_wB0KGWRBYTwy@holmes.parc.xerox.com>
Date: 	Thu, 13 May 1993 17:37:30 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, fine@cis.ohio-state.edu
Subject: Re: comp.infosystems.www
In-Reply-To: <9305131825.AA01070@soccer.cis.ohio-state.edu>
References: <9305131825.AA01070@soccer.cis.ohio-state.edu>

Either 4 or 5 would be great, 1 or 3 would be OK, 2 would not be good.

Bill

From dsr@hplb.hpl.hp.com  Fri May 14 11:17:14 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08534; Fri, 14 May 93 11:17:14 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08903; Fri, 14 May 1993 11:38:06 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 14 May 93 10:31:12 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA15463; Fri, 14 May 93 10:39:06 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305140939.AA15463@manuel.hpl.hp.com>
Subject: Re: HTML+ and printed books
To: sanders@bsdi.com
Date: Fri, 14 May 93 10:39:04 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Tony,

> Has much thought gone into features needed to have data be both online
> and used to print books.  When you are using a hypertext browser you
> want one view of the data and when you print a book you'll need another.

Thanks for pointing this out. Quite often I am browsing through some part of
the web and would like to print out a whole chunk. Unfortunately, while it is
simplicity itself to print the current document, it is really tough to print
out a collection of related material, involving multiple documents.

If we can address this issue well, it will also make it much easier to put
books and technical documentation etc. onto the web. By addressing the needs
of publishers the Web itself will become more pervasive.

You suggest:

> The most obvious thing to add would be:
>    <ONLINE>click the mouse or select item</ONLINE>
>    <PRINTED>see page such and such</PRINTED>
> But I have a strong feeling this isn't the correct way to solve the problem.

The issue you mention of how authors refer to hypertext links can be solved
through guidelines to authors on how to write such references in a form
suitable for both online and paper media. Tim has already written on this
in "http://info.cern.ch:80/hypertext/WWW/Provider/Style/Printable.html".

Perhaps we need some structuring elements which determine how a group of
related documents can be sequenced into a form suitable for printing, along
with a way of automatically generating a table of contents, and an index.
Hypertext links could then be converted into the appropriate page/section
references.

The obvious structuring element corresponds to the contents list, e.g.

        <CONTENTS>
            <A HREF ="doc1.html">Introduction to home brewing</A>
            <A HREF ="doc2.html">Equipment Needed</A>
            <A HREF ="doc1.html">The basic skills</A>
            <A HREF ="doc1.html">Popular recipes</A>
        </CONTENTS>

i.e. in SGML terms:  <!ELEMENT CONTENTS (A+)>

This would be placed somewhere convenient with links back from other
documents using the <LINK> element, e.g.
                                                    "Previous" and "Next"
        <LINK REL="CONTENTS" HREF="contents.html">   relationships could
                                                     also be useful here.

This would allow the browser to work out how to print the material as a book
from any one of the constituent documents. At worst, The index can be
generated automatically from analysing the document text for key phrases.
Better still, would be to have markup which identifies key words or phrases.
The header and inline emphasis tags are potential candidates, but I think
we should add a new tag to support professional quality indexing.

What do you think?

Regards,

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From bloemer@tnt.uni-hannover.dbp.de  Fri May 14 11:32:32 1993
Return-Path: <bloemer@tnt.uni-hannover.dbp.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08681; Fri, 14 May 93 11:32:32 MET DST
Received: from ixgate.gmd.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11836; Fri, 14 May 1993 11:53:11 +0200
Received: by ixgate.gmd.de id AA17170; Fri, 14 May 93 11:52:16 +0200
Date: 14 May 93  9:52 
From: "(Arnold Bloemer)" <bloemer@tnt.uni-hannover.dbp.de>
To: fine@cis.ohio-state.edu
Message-Id: <RFC-822:>
Subject: Re: comp.infosystems.www

RFC-822-HEADERS:
Cc: www-talk@info.cern.ch, bloemer

==================
A one-way gateway will raise a severe problem.

Imagine that you read in News an announcement of x, post a followup 
and assume that it will reach x, but x doesn't read news and so will
not get it.

I would like to switch to the Newsgroup and unsubscribe from the
mailing list because I want to reduce my mail traffic. But
I still want to fully participate in the discussions on www-talk.

It will be a severe mistake if the experts will talk on www-talk
and leave the users or potential users alone on the newsgroup.

The World Wide Web needs Users to become a successful project.

The already mentioned bad example is WAIS. I don't follow the
newsgroup any more because I also noticed, that the real experts
have there own discussion group and seldom answer questions on
the newsgroup.

So I would like to see:

- that the mailing lists dies completely and there is no gateway at all

  Proposal 1, without explanation

or

- that there is a bidirectional gateway.

  Poposal 2, but I have usenet

or

- there is a bidirectional gateway and users of the mailing-list
  can subscribe to a digestified mailing-list, where they get one
  summary mail per day. That is how the Khoros Group solved the 
  problem of large mail traffic.

  Proposal 6, new one

Arnold

________________________________________________________________________________

Dipl.-Ing. Arnold Bloemer	   Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
bloemer@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49 511 762-5333           D-3000 Hannover 1
phone:  +49 511 762-5320           Germany
________________________________________________________________________________


From dsr@hplb.hpl.hp.com  Fri May 14 11:59:57 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08993; Fri, 14 May 93 11:59:57 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16761; Fri, 14 May 1993 12:20:52 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 14 May 93 11:13:52 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA16614; Fri, 14 May 93 11:21:43 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305141021.AA16614@manuel.hpl.hp.com>
Subject: DL Compact
To: timbl@dxcern.cern.ch
Date: Fri, 14 May 93 11:21:41 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

How should HTML+ (aka HMML) handle compact lists?

        <OL COMPACT>    or      <OLC>
        <UL COMPACT>    or      <ULC>
        <DL COMPACT>    or      <DLC>

Can you let me have your opinions please?

Also what about a means for specifying an explicit string in place
of the standard bullet for unordered lists, e.g. <LI LABEL="a)">?

Best wishes,

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From dsr@hplb.hpl.hp.com  Fri May 14 12:17:55 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09220; Fri, 14 May 93 12:17:55 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22113; Fri, 14 May 1993 12:38:52 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 14 May 93 11:31:56 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA16628; Fri, 14 May 93 11:39:51 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305141039.AA16628@manuel.hpl.hp.com>
Subject:  Re: Formatting Options in HTML?
To: totic@milton.cs.uiuc.edu
Date: Fri, 14 May 93 11:39:49 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Aleksandar Totic says (Wed, 12 May 93 16:53:50 CDT)

> Now, someone else might want to make a list item appear in the header style,
> like this: 
>
>         <LI><H1> This item should attract attention </H1>

Actually Aleksandar, headers are *NOT* currently permitted in <LI> list
elements. Instead you should use the emphasis tags.

Should we change this for HTML+ (aka HMML)?

Cheers,

Dave Raggett

From romig@cis.ohio-state.edu  Fri May 14 14:57:08 1993
Return-Path: <romig@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11473; Fri, 14 May 93 14:57:08 MET DST
Received: from [128.146.12.10] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25486; Fri, 14 May 1993 15:17:59 +0200
Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA02421; Fri, 14 May 93 09:17:36 -0400
Date: Fri, 14 May 93 09:17:36 -0400
From: Steve Romig <romig@cis.ohio-state.edu>
Message-Id: <9305141317.AA02421@brachiosaur.cis.ohio-state.edu>
To: bloemer@tnt.uni-hannover.dbp.de
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: "(Arnold Bloemer)"'s message of 13 May 93 12:48  <RFC-822:>
Subject: TeXinfo Gateway

You mean the emacs info gateway?  That's a modified version of the one
written by Eelco van Asperen <evas@cs.few.eur.nl>.  Our version is
available by anon ftp in ftp.cis.ohio-state.edu in /pub/www/cis.tar.Z
(along with the rest of our scripts).  You might need to pick up
yagrip.pl (a getopt package for Perl), its in the same directory.

--- Steve

From nikos@cbl.leeds.ac.uk  Fri May 14 17:39:10 1993
Return-Path: <nikos@cbl.leeds.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15151; Fri, 14 May 93 17:39:10 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06891; Fri, 14 May 1993 18:00:09 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Fri, 14 May 1993 17:59:41 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Fri, 14 May 1993 17:58:12 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Fri, 14 May 1993 17:57:37 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Fri, 14 May 1993 17:57:38 +0200
Date: Fri, 14 May 1993 17:57:38 +0200
X400-Originator: nikos@cbl.leeds.ac.uk
X400-Recipients: www-talk@info.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<10937.9305141557@cbl.leeds.ac.u]
X400-Content-Type: P2-1984 (2)
Content-Identifier: tex2html
From: N F Drakos <nikos@cbl.leeds.ac.uk>
Message-Id: <10937.9305141557@cbl.leeds.ac.uk>
To: www-talk <www-talk@nxoc01.cern.ch>
Subject: tex2html

Hi,

some time ago we found it necessary to convert some of our
Latex documents into HTML. The result of this was a crude
translator from a small subset of Latex commands to HTML.

For more information see:
http://cbl.leeds.ac.uk/nikos/tex2html/tex2html.html

Here is an extract from the above document:

A full translation from Latex to HTML (or SGML) is NOT possible. 
Having said that it is possible to translate Latex commands which have
direct equivalents in HTML and treat the rest of the document as
unformatted ascii text. This works for ``undemanding'' documents which
do NOT make use of equation, picture or table environments, or
user-defined commands and styles. 

The translator was created to address specific needs and it
sometimes handles some commands in a very subjective way. Although
this makes it less general than it perhaps ought to be, some of its
functionality may still be of general use. 

Nikos Drakos,
Computer Based Learning Unit, University of Leeds.


From brennan@hal.com  Fri May 14 17:45:50 1993
Return-Path: <brennan@hal.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15299; Fri, 14 May 93 17:45:50 MET DST
Received: from HAL.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08507; Fri, 14 May 1993 18:06:48 +0200
Received: from hysteria.hal.com by hal.com (4.1/SMI-4.1.1)
	id AA08745; Fri, 14 May 93 09:06:46 PDT
Received: by hysteria.hal.com (4.1/SMI-4.1.2)
	id AA17867; Fri, 14 May 93 11:06:43 CDT
Date: Fri, 14 May 93 11:06:43 CDT
From: brennan@hal.com (Dave Brennan)
Message-Id: <9305141606.AA17867@hysteria.hal.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML+ and printed books
In-Reply-To: <9305140939.AA15463@manuel.hpl.hp.com>
References: <9305140939.AA15463@manuel.hpl.hp.com>

>>>>> On Fri, 14 May 93 10:39:04 BST, Dave_Raggett <dsr@hplb.hpl.hp.com> said:

> Perhaps we need some structuring elements which determine how a group of
> related documents can be sequenced into a form suitable for printing,
                                                              ^^^^^^^^

And browsing.  As you mentioned, this would give you the ability for "next"
and "previous" type on-line browsing.  In addition you could view and
navigate through the TOC on-line.  I feel that using this kind of
information in an on-line browser can really help to reduce the "lost in
hyperspace" problem.

> The obvious structuring element corresponds to the contents list, e.g.
>
>    <CONTENTS> 
>      <A HREF ="doc1.html">Introduction to home brewing</A>
>      <A HREF ="doc2.html">Equipment Needed</A> 
>      <A HREF ="doc1.html">The basic skills</A>
>      <A HREF ="doc1.html">Popular recipes</A>
>    </CONTENTS>

Would these be top level headings?  I think a level indication is
appropriate in this case, so instead you'd have entries like:

>      <A HREF ="doc1.html"><H1>Introduction to home brewing</H1></A>

> This would be placed somewhere convenient with links back from other
> documents using the <LINK> element
>
>  <LINK REL="CONTENTS" HREF="contents.html"> 

While this make sense in a printed world where each chapter (node) only
appears in one book (for the most part), it doesn't make sense in the
hypertext world where a node can potentially occur in as many books as
people can dream up.  It would be up to the browser software to keep track
of the current book or books that you're browsing through.  The model would
be that an on-line book is just another "view" into the information space.
I think that this is a powerful and useful notion.

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

From montulli@stat1.cc.ukans.edu  Fri May 14 17:52:33 1993
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15461; Fri, 14 May 93 17:52:33 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10301; Fri, 14 May 1993 18:13:32 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA29949; Fri, 14 May 1993 11:06:08 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9305141606.AA29949@stat1.cc.ukans.edu>
Subject: Re: comp.infosystems.www
To: fine@cis.ohio-state.edu (Thomas A. Fine)
Date: Fri, 14 May 93 11:06:07 CDT
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305131825.AA01070@soccer.cis.ohio-state.edu>; from "Thomas A. Fine" at May 13, 93 2:25 pm
X-Mailer: ELM [version 2.3 PL2]

> 
> 
> Good news!  I've convinced my news admin to set up the gateway.  What I'd
> like to do now is have a fast informal vote on various possibilities.
> Please vote on only one proposal.
> 
> Proposal 2.
>   Bi-directional gateway.
>   Vote here if you have no USENET access whatsoever and want to use the
>   mailing list as an interface to the newsgroup
> 
I definitely, definitely, definitely do not want to have to use USENET!
Mail is much more handy to read and use, and it tends to get to people
MUCH faster than USENET!
We can provide the gateway if necessary!

:lou

From kehoe@fortuity.sf.ca.us  Fri May 14 20:12:11 1993
Return-Path: <kehoe@fortuity.sf.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18751; Fri, 14 May 93 20:12:11 MET DST
Received: from uu6.psi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03743; Fri, 14 May 1993 20:33:05 +0200
Received: by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
        id AA28284 for ; Fri, 14 May 93 14:20:14 -0400
Received: by fortuity.sf.ca.us (NX5.67c/NeXT-1.0+/DMK030591)
	id AA00657; Fri, 14 May 93 11:15:54 -0700
Date: Fri, 14 May 93 11:15:54 -0700
From: kehoe@fortuity.sf.ca.us (Daniel Miles Kehoe)
Message-Id: <9305141815.AA00657@fortuity.sf.ca.us>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: brennan@hal.com (Dave Brennan)
Subject: Re: HTML+ and printed books
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch

Dave Raggett suggests:

> Perhaps we need some structuring elements which determine how a 

> group of related documents can be sequenced into a form suitable 

> for printing, along with a way of automatically generating a table 

> of contents, and an index.

If a browser were able to automatically generate a table of contents  
(T.O.C.), you'd have all you need to print a book.

Consider FrameMaker. To generate a T.O.C. in Frame, one specifies  
which "paragraph formats" (as Frame calls its markup tags) to include  
in an automatically generated T.O.C.

If a user were to ask a browser to search for and list a  
user-specified set of tags (such as headers), and if the user could  
then select which items to include/exclude in the T.O.C., the user  
could have his/her own custom book.

But how does the user specify the limits of the search? All the Web?  
This raises the spectre of the web-roaming cyberbots discussed  
earlier. Or matches to keywords found in headers throughout the Web?  
This becomes WAIS-like. Or local nodes only? There's an issue here of  
what constitutes a "group of related documents": the author's intent?  
Or the reader's interest?

It's interesting to consider that printing a book and searching the  
Web might be closely related issues. I've come to believe that a book  
is not a document, but rather a point of access to an organized  
collection of documents. I'd be happy to elaborate out-of-thread...

>From this point of view, it seems a bad idea to include "structuring  
elements" inside documents that tie them together for printing (if  
that's what you were suggesting), though there's no harm in  
encouraging authors to provide one or more T.O.C.'s (or encouraging  
readers to contribute their own T.O.C.'s).

Daniel Kehoe
contributing editor, NeXTWORLD magazine; and co-author, 

"Taking the Next Step: The Buyers' Guide to NEXTSTEP Computing"
 

From grobe@ukanaix.cc.ukans.edu  Fri May 14 20:53:27 1993
Return-Path: <grobe@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19726; Fri, 14 May 93 20:53:27 MET DST
Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10383; Fri, 14 May 1993 21:14:26 +0200
Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA28557; Fri, 14 May 1993 14:16:04 -0500
From: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
Message-Id: <9305141916.AA28557@ukanaix.cc.ukans.edu>
Subject: Re: Formatting Options in HTML?
To: www-talk@nxoc01.cern.ch
Date: Fri, 14 May 93 14:15:58 CDT
X-Mailer: ELM [version 2.3 PL2]


in regard to the question of supporting centering and right justification
and compact in html (and with apologies to anyone who gets
redundant copies):

i am a new user of html, and an old user of roff.  my first reaction
to html was "what a weak formatting language."  as i thought more
about displaying documents on a wide variety of clients, however, i
began to understand better what markup without formatting was about
and thought "what a clever idea to let clients use whatever capabilities
they have to display what needs to be displayed."  as i prepared
my first document (which is a quick reference to html by the way), i
was frequently frustrated by not being able to get things to look
quite right.  in particular, <dl> didn't seem to want to cooperate
with my aesthetic (nor did <dl compact>.)  finally, i realized that
it was the renderer, not html, that was not cooperating; html provided
a suitably defined <dl> structure, but the renderer was making 
decisions i didn't like.

extrapolating just a bit from this line of experience, i concluded that
an html renderer (or www client) should allow the READER to
define how to render html constructs.  for example, the reader should
be able to define the typeface, indentation, line spacing, and characters
used for bullets (if any) at each level of a nested <ul>. in addition,
the reader should be able to change this rendering while viewing a particular
page.  in this context, the centering and right justification questions
seem to become a matter of reader choice. the reader may choose to have
the client center headers and right justify text, or not.

having prepared documents for years, i have spent a lot of
time trying to pick display formats that convey information clearly.
it is something of a relief to imagine moving the display format
responsibility away from the information provider to the information 
consumer (not the client program, but the reader herself), who should
actually be able to do a better job of it, since each reader knows
or can discover her own preferences (provided, of course, that the
client gives them the capability). 

from this perspective the "compact" of <dl compact> is even something
of an encroachment into the responsibilities of the renderer/reader.

as i mentioned, i am new to html, so this may be old hat to the www
community, but it may also serve to remind veteran users of the
learning process experienced by new users.

:michael grobe
academic computing services
the university of kansas




From martyg%Csa2.LBL.Gov@lbl.bitnet  Fri May 14 21:06:49 1993
Return-Path: <martyg%Csa2.LBL.Gov@lbl.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20096; Fri, 14 May 93 21:06:49 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11969; Fri, 14 May 1993 21:27:49 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 5328; Fri, 14 May 93 21:27:07 SET
Received: from Lbl.Bitnet (NJE origin MAILER@LBL) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 8611; Fri, 14 May 1993 21:27:07 +0200
Received: from Csa2.LBL.Gov by Csa3.LBL.Gov via INTERNET ;
          Fri, 14 May 93 12:27:37 PDT
Date:     Fri, 14 May 93 12:27:20 PDT
From: martyg%Lbl.BITNET@cearn.bitnet (Martin Gelbaum)
Reply-To: MGelbaum%Lbl.BITNET@cearn.bitnet
Message-Id: <930514122411.20c47b2f@Csa2.LBL.Gov>
Subject:  Ported NCSA Mosaic for X to VAX/VMS
To: mosaic-x%ncsa.uiuc.edu%Csa2.LBL.Gov%Lbl.BITNET@cearn.bitnet,
        www-talk@nxoc01.cern.ch
Cc: HHHolmes%Lbl.BITNET@cearn.bitnet, wokoellner%Lbl.BITNET@cearn.bitnet,
        MGelbaum%Lbl.BITNET@cearn.bitnet

        To whom it may concern:
        I ported the NCSA Mosaic for X to VAX/VMS this week.
        VMS: V5.5-2; VAX C V3.2-044; DECwindows/Motif version 1.1;
Multinet version 3.2; George Carrette's (gjc@mitech.com) port of
the R5 Athena widgets; VAX 6000-610.
        Made appropriate MMS files.
        Added capability to preview PostScript files accessed
through Gopher to both the UNIX and VMS versions.
        If this is of some use, please let me know
the best way to cooperate with the authors.
        Thank you for your patience and cooperation.
                                                Martin Gelbaum
                                                LBL Computing Resources
                                                MGelbaum@lbl.gov
                                                +1-510-486-4749

From brennan@hal.com  Fri May 14 21:52:54 1993
Return-Path: <brennan@hal.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21094; Fri, 14 May 93 21:52:54 MET DST
Received: from HAL.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18319; Fri, 14 May 1993 22:13:52 +0200
Received: from hysteria.hal.com by hal.com (4.1/SMI-4.1.1)
	id AA18095; Fri, 14 May 93 13:13:39 PDT
Received: by hysteria.hal.com (4.1/SMI-4.1.2)
	id AA18914; Fri, 14 May 93 15:13:37 CDT
Date: Fri, 14 May 93 15:13:37 CDT
From: brennan@hal.com (Dave Brennan)
Message-Id: <9305142013.AA18914@hysteria.hal.com>
To: kehoe@fortuity.sf.ca.us (Daniel Miles Kehoe)
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Subject: Re: HTML+ and books
In-Reply-To: <9305141815.AA00657@fortuity.sf.ca.us>
References: <9305141815.AA00657@fortuity.sf.ca.us>

On the issue of automatically generating a TOC, I don't think it would be
very easy to generate a coherent book TOC, even given a set of nodes to uses
as a basis.  You'd have the headings, but how would you order them?  I
suppose a program could try and decide upon some kind of structure/ordering
from the links in the nodes, but it wouldn't be easy.  The best use of some
kind of automated TOC generator might just be to give a human somewhere to
start from.  In a program like Frame, the task is a lot easier because you
are already starting with a limited set of information that has a linear
ordering and (supposedly) meaningful elements from which to generated the
TOC.

I don't see books as something that the user can just conjure when he or she
is trying to track down some information.  There's better ways to handle
that kind of interaction requirement.  I see books as something that are
authored by someone, much like a node is written.  The cool thing about this
is that this would make it possible for people to easily write "virtual
books" based on existing information.  Of course, they may wish to add some
nodes of their own while they're at it to tie everything together.  But the
large existing base of information is going to make organizing and finding
information easier than ever.

> It's interesting to consider that printing a book and searching the Web
> might be closely related issues.

It sure is!  The interesting part is that the same basic organizational
information can be used in both cases.

> I've come to believe that a book is not a document, but rather a point
> of access to an organized collection of documents. 

Exactly my point.  In a meta-sense, though, even a book is a document,
albeit at a higher level of abstraction.  Carrying this one step further,
who's to say I can't put together a "library" that contains bunch of books.
I still like to picture it as "views" on the information.  You've got access
to a giant collection of (mostly) unstructured information, and by looking
at it through one or more views the information can become much more useful.

> From this point of view, it seems a bad idea to include "structuring
> elements" inside documents that tie them together for printing (if that's
> what you were suggesting), though there's no harm in encouraging authors
> to provide one or more T.O.C.'s (or encouraging readers to contribute
> their own T.O.C.'s).

Yes, that's just what I was suggesting.  Although it is more convenient
to have that information available, I'm afraid of the limitations that
it implies.  And if you can't already guess, I'd be all for encouraging
anyone and everyone to contribute their own TOCs.

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

From germuska@antioch.acns.nwu.edu  Fri May 14 22:35:06 1993
Return-Path: <germuska@antioch.acns.nwu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21925; Fri, 14 May 93 22:35:06 MET DST
Received: from antioch.acns.nwu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24816; Fri, 14 May 1993 22:56:05 +0200
Received: by antioch.acns.nwu.edu (4.1/SMI-ACNS-1.08)
	id AA02534; Fri, 14 May 93 15:55:51 CDT
From: germuska@antioch.acns.nwu.edu (Joe Germuska)
Message-Id: <9305142055.AA02534@antioch.acns.nwu.edu>
Subject: Re: Formatting Options in HTML?
To: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
Date: Fri, 14 May 1993 15:55:49 -0500 (CDT)
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305141916.AA28557@ukanaix.cc.ukans.edu> from "Michael Grobe" at May 14, 93 02:15:58 pm
Reply-To: j-germuska@nwu.edu (Joe Germuska)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1268      

Michael Grobe wrote:
> extrapolating just a bit from this line of experience, i concluded that
> an html renderer (or www client) should allow the READER to
> define how to render html constructs.  for example, the reader should

Exactly!  (he says, blushing and hoping no one realizes that he was the one
who started this thread from the opposite side of the field... :-)

No, but I get it now, and would very much like to see this kind of
customizability added to web browsers, especially (of course) XMosaic --
especially mostly because a GUI offers so many more formatting options and
XMosaic is my GUI browser of choice...

That reminds me -- can HTML authors declare new tags?  It would seem far
too complicated for clients to deal with newly introduced styles, but
perhaps, with customizable displays, the client could just add unfamiliar
styles to the "style index", and the user could make changes as desired...
(remember I know next to nothing about the implementation of Web clients,
so if this is outrageous, please be gentle :-)  

	Joe
(who again invites people to critique http://www.acns.nwu.edu/)

-- 
joe germuska | j-germuska@nwu.edu | Network Response Center
ACNS-Distributed Systems Services, Northwestern University
Ceci n'est pas une signature.

From pandora@fernwood.mpk.ca.us  Sat May 15 01:49:41 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25134; Sat, 15 May 93 01:49:41 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21087; Sat, 15 May 1993 02:10:40 +0200
Received: by fernwood.mpk.ca.us; id AA12524; Fri, 14 May 93 17:14:08 -0700
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: Re: comp.infosystems.www
Organization: Pandora Systems
Date: Sat, 15 May 1993 00:07:56 GMT
Message-Id: <C71KD8.FML@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL9]
References: <9305141606.AA29949@stat1.cc.ukans.edu>
Apparently-To: www-talk@nxoc01.cern.ch

I'd vote for 1 myself, since I definately prefer it in news to mail, (in
fact I read it on a locally gatewayed copy of the list). But lets set up
the bidirectional feed if even a few poor souls cant get Usenet.  

Please please, make the gateway bidirectional.  Dont let people write
here thinking they are writing to the whole of the audience, only to
find that half the readers wont see their message.   If you want to do
that, then let us know so we can set the newsgroup to moderated and feed
anything written here (in the group) to the list instead.

- Mitra


From RASHTY@hujivms.bitnet  Sat May 15 14:07:26 1993
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28686; Sat, 15 May 93 14:07:26 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29079; Sat, 15 May 1993 14:28:28 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 6430; Sat, 15 May 93 14:27:45 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 1930; Sat, 15 May 1993 14:27:45 +0200
Received: by HUJIVMS (HUyMail-V6l); Sat, 15 May 93 15:28:11 +0300
Date:     Sat,  15 May 93 15:28 +0300
Message-Id: <15050093152811@HUJIVMS>
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch, yehavi@dxmint.cern.ch
Subject:  VMS SEARCH SERVERS

Hello All,

I have written two new VMS SEARCH gateways.

The first one is a regular Search server and the second is a phone search
server.

This servers can execute VMS search (like grep) commands and return a
hypertext pointer of the files found with match.
(The phone search server return the items found in each file as plaintext)

The search have AND and OR capabilities (currently just OR or Just AND).

What this server means is that it is possible to search all the *local* node
tree or define any part of the local node for searching.

I will put it in anonymous ftp www.huji.ac.il cd WWW/VMS_SEARCH

I think that it will be good if someone will do the same for Unix grep.

**
**      this server accepts the following:
**      http://node/SEARCH/intro_file_name%search_area?keylist
**      http://node/SEARCH/intro_file_name%search_area?
**      http://node/SEARCH/search_area?keylist
**      http://node/SEARCH/search_area?
**      where
**	- intro_file_name: Is an introduction file describing the search
**	- search_area: Is a VMS description of the files to search, it
**	      can be any of the following : disk:[...]*.*,disk:[user]*.ext ...
**      - keylist: Is a combination of words separated by : for OR
**           or & for AND (can't mix OR with AND YET @@), for example
**           A:B:C (A OR B OR C), A&B&C (A AND B AND C)
**	     @@ NOT PERMITTED YET !!! (A:B&C)
**
**	Important: The directory in which the server run must be with o:rwd
**	so the search result can be written and letter read and delete.
**
**      Bugs:
**	- Can't mix AND with OR


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:                                                      **** Thanks !! **** :
: Dudu Rashty                Rashty@Vms.Huji.Ac.Il         __o     o__     :
: Computation Center         Bitnet:Rashty@HUJIVMS       _ \<,_   _.>/ _   :
: The Hebrew University      Phone:  +972-2-584397      (_)/ (_) (_) \(_)  :
: Jerusalem 91904, ISRAEL.   Fax:    +972-2-527349       D    u    d    u  :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From sanders@bsdi.com  Sat May 15 16:14:54 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29386; Sat, 15 May 93 16:14:54 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19721; Sat, 15 May 1993 16:35:54 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA13537; Sat, 15 May 93 09:35:51 -0500
Message-Id: <9305151435.AA13537@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: VMS SEARCH SERVERS 
In-Reply-To: Dudu Rashty +972-2-584848's message of Sat, 15 May 93 15:28:00 +0300.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Sat, 15 May 1993 09:35:51 -0500
From: Tony Sanders <sanders@bsdi.com>

> I think that it will be good if someone will do the same for Unix grep.
I already have see http://www.bsdi.com/server/doc/plexus.html under
Directory Search.

--sanders

From howcome@nta.no  Mon May 17 00:34:53 1993
Return-Path: <howcome@nta.no>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11042; Mon, 17 May 93 00:34:53 MET DST
Received: from hal.nta.no by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01065; Mon, 17 May 1993 00:55:53 +0200
Received: from earth.nta.no by hal.nta.no with SMTP id AA04880
  (5.65c/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Mon, 17 May 1993 00:55:23 +0200
Date: Mon, 17 May 1993 00:55:23 +0200
Message-Id: <199305162255.AA04880@hal.nta.no>
Received: by earth.nta.no (4.1/SMI-4.1)
	id AA01587; Mon, 17 May 93 00:55:22 +0200
To: grobe@ukanaix.cc.ukans.edu
Cc: www-talk@nxoc01.cern.ch, howcome@nta.no
In-Reply-To: Michael Grobe's message of Fri, 14 May 93 14:15:58 CDT <9305141916.AA28557@ukanaix.cc.ukans.edu>
Subject: Formatting Options in HTML?
From: "H&kon W Lie  howcome@hal.nta.no"  <Haakon.Lie@nta.no>

mike grobe wrote:

   extrapolating just a bit from this line of experience, i concluded that
   an html renderer (or www client) should allow the READER to
   define how to render html constructs.  for example, the reader should
   ..

   it is something of a relief to imagine moving the display format
   responsibility away from the information provider to the information 
   consumer (not the client program, but the reader herself), who should
   actually be able to do a better job of it, since each reader knows

While I welcome the shift of emphasis from the information provider to
the consumer, the outlined policy has one major flaw: the presentation
becomes very boring. Yes, I like to be able to decide the font size
and family, but no -- I do not want to make presentation decisions
for every page I open. Consequently, all the H3 headlines I read are
18pt helvetica.

Newspapers, on the other hand, are very conscious when selecting fonts
for headlines. The more important the articleis, the bigger font size
is used. If the content is "soft", a serif font is selected etc. So,
the visual presentation of information can not be entirely separated
from the content. 

The conflict between the content of presentation and the preferences
of the reader has not been properly addressed yet. Either, the format
determines the final form presentation 100% (e.g. dtp formats), or the
responsibility is handed over to the reader/client application (e.g. html).

A better approach would be to let the information provider and the
consumer (represented by the client program) negotiate the final form
presentation. The information provider should be allowed to suggest
that "this piece of text is best presented using a hard font and
justified text". The client application could respond that, "yes, my
reader doesn't mind hard fonts, but absolutely hates justified text so
I'll go for ragged right instead". Etc etc.

All that is needed for the above outlined presentation scheme to
become possible is to make room for optional presentation hints when
defining a format. There goes my vote..

-h&kon

H&kon W Lie, Norwegian Telecom Research, howcome@hal.nta.no





From tom@begbick.law.cornell.edu  Mon May 17 03:59:26 1993
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12485; Mon, 17 May 93 03:59:26 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24533; Mon, 17 May 1993 04:20:30 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <160540(1)>; Sun, 16 May 1993 22:20:25 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA01244; Sun, 16 May 93 22:11:23 EDT
Date: Sun, 16 May 1993 22:11:23 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9305170211.AA01244@begbick.law.cornell.edu.law.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Naive question: successive <ADDRESS> tags

Gang:

Seems a little late in the game for me to be asking this question, but
what is the proper interpretation of successive <ADDRESS> tags not
separated by a <P> or something else which would force a newline/ new
para? Is the assumption that they will fill in from the right, ie.
with last <ADDRESS>text</ADDRESS> at the right margin, last-1 to its
left, etc.? or is a newline implied by the as it were necessity of
placing both at the right margin?

(I've just turned up a buglet and am hoping for the easy way out :-(
).

  Tom.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From ccprl@xdm001.ccc.cranfield.ac.uk  Mon May 17 15:14:56 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17996; Mon, 17 May 93 15:14:56 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07698; Mon, 17 May 1993 15:35:55 +0200
Received: by xdm001 
	id AA14357; Mon, 17 May 93 10:56:53 +0100
Received: by xdm039 (5.57/4.7) id AA12072; Mon, 17 May 93 10:55:01 +0100
Message-Id: <9305170955.AA12072@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Page Breaks and Tables of Contents in HTML
Reply-To: p.lister@cranfield.ac.uk
Date: Mon, 17 May 93 10:54:59 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

I would like a page break in HTML, e.g. <page> would tell a viewer to
display text following this point as if it came from another HTML
document (though it is NOT desirable that any other functions would be
limited in this way, e.g. searches). There would be a method (probably
an anchor automtically generated by the viewer) for moving on to the
next page, or back to the beginning.

To go along with this, a table of contents would be nice (i.e. an
automatically generated table of intra-document reference anchors), so
that users can warp straight to the relevant text from the beginning of
the document without having to search through a large file (whether via
a search function or by eye).

All of this functionality happens now, it's just that books have to be
divided into separate files for each chapter manually, and have a hand
crafted TOC. All I ask is that the hooks be put in place for this to be
done by the viewer. Since most systems do generate mulit-page documents
in a single file, HTML translators are made a bit more awkward if the
translator has to open a new file (and insert anchors) or kludge (like
I do) by inserting a line of dashes.

Again, XMosaic already has much of the functionality there, as the
Motif text widget forces page breaks. Maybe OSF's design constraint
wouldn't look so bad if we could structure HTML more like a real book.
I find a document so big that it forces an XMosaic page break is *very* unfriendly.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From ccprl@xdm001.ccc.cranfield.ac.uk  Mon May 17 15:15:56 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18025; Mon, 17 May 93 15:15:56 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07739; Mon, 17 May 1993 15:36:58 +0200
Received: by xdm001 
	id AA14158; Mon, 17 May 93 10:32:37 +0100
Received: by xdm039 (5.57/4.7) id AA11995; Mon, 17 May 93 10:28:58 +0100
Message-Id: <9305170928.AA11995@xdm039>
To: cbs%uk.ac.earn-relay::com.hp.hpl.hplb::dsr@cchub.decnet.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: Re: DL Compact 
In-Reply-To: Your message of "Fri, 14 May 93 15:07:05 BST."
             <9305141407.AA19804@xdm001> 
Date: Mon, 17 May 93 10:28:57 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> How should HTML+ (aka HMML) handle compact lists?
>
> <OL COMPACT>    or      <OLC>

<OL COMPACT>, with <OL C> as an acceptable abbreviation

> Also what about a means for specifying an explicit string in place
> of the standard bullet for unordered lists, e.g. <LI LABEL="a)">?

Is this supposed to affect the label for the current instance, or all
following  list items? I would prefer 

<LISTLABEL="a)">

which would recommend a label to the viewer for all future <ul>s

Have we considered

<OLLABEL3 ="%d1.%d2.%d3>>">, which would make all <OL> subsublists be labelled

4.1.3>> Index entry

%dn being replaced by the sequence number at level n. (1=list, 2=sublist,...)

To take this to it's logical conclusion, why not reduce <ul> and <ol>
(even <dl>?) to a generic list type with definable labelling
strategies. There would be one or two common ones (corresponding to the
existing UL and OL, and maybe others a, b, c.... and i, ii, iii.... ),
but specifics can be defined by the document author. It occurs to me
that legal documents would benefit from automatic labelling of things
as Section (a), subsection iii(f). Or maybe not.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875


From ccprl@xdm001.ccc.cranfield.ac.uk  Mon May 17 15:41:24 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18586; Mon, 17 May 93 15:41:24 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10780; Mon, 17 May 1993 16:02:25 +0200
Received: by xdm001 
	id AA19493; Mon, 17 May 93 15:02:21 +0100
Received: by xdm039 (5.57/4.7) id AA14823; Mon, 17 May 93 15:02:12 +0100
Message-Id: <9305171402.AA14823@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Is HTTP necessary??
Reply-To: p.lister@cranfield.ac.uk
Date: Mon, 17 May 93 15:02:07 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

I'm about to attend a meeting with various non-tech staff from other
departments about how best to publish their info. They seem to be
strongly in favour of Gopher - probably because they haven't had much
news of any alternative from their "normal" sources, because they're
aware of how widespread Gopher is, and because they've heard that it's
easy to set up.

I shall extol the virtues of Xmosaic, and HTML documents, while
assuring them that anything they want to publish can go into Gopher,
and also that they'll be able to get at Gopherspace, Veronica, etc via
XMosaic (or www on a terminal).

However, the more I think about it, the harder it is to justify HTTP
and httpd. If I can get at all my HTML docs from within Gopher space,
why bother? All the refs from local HTML docs to other http places will
work OK (won't they??), and I can provide a trivial default page for
httpd (so that the existing WWW community who know us that way are happy).

The mapping functionality of httpd can be useful, but does it do much
that can't be achieved by bunging symbolic links in a Gopher directory?
OK, so one can map different filename formats and that has been useful
here, if not vital. However, directory browsing is *not* nice with
httpd if I have to tag every directory with .www_browsable; I want
inexpert users to be able to publish information, and I forsee problems
if they need to do anything "unexpected" like that.

HTML is great, but is HTTP worth it? I'm want practical details, so
don't send me philosophical waffle or flame me for being a traitor to
WWW, cos I'm not. Yes, I know that there are rumours that Gopher is to
become proprietary. Unfortunately, while I regard that as bad, others
here may regard it as *good*; the idea of paying for a support contract
makes them feel warm, and secure, despite what experience should by now
have taught us.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From marca@wintermute.ncsa.uiuc.edu  Tue May 18 01:23:18 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28808; Tue, 18 May 93 01:23:18 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01951; Tue, 18 May 1993 01:44:23 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22793
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 17 May 93 18:43:48 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:ccprl@xdm001.ccc.cranfield.ac.uk id AA01779; Mon, 17 May 93 18:45:55 -0500
Date: Mon, 17 May 93 18:45:55 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305172345.AA01779@wintermute.ncsa.uiuc.edu>
To: p.lister@cranfield.ac.uk
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: Is HTTP necessary??
In-Reply-To: <9305171402.AA14823@xdm039>
References: <9305171402.AA14823@xdm039>
X-Md4-Signature: ab967f10b900e2de6e5d56e45d3bfd85

"Peter Lister, Cranfield Computer Centre" writes:
> The mapping functionality of httpd can be useful, but does it do
> much that can't be achieved by bunging symbolic links in a Gopher
> directory?  OK, so one can map different filename formats and that
> has been useful here, if not vital. However, directory browsing is
> *not* nice with httpd if I have to tag every directory with
> .www_browsable; I want inexpert users to be able to publish
> information, and I forsee problems if they need to do anything
> "unexpected" like that.

That is one particular httpd -- at least one other that I know of
(NCSA httpd) and I assume others (BSDI's, etc.) always support
directory browsing.

> HTML is great, but is HTTP worth it? I'm want practical details, so
> don't send me philosophical waffle or flame me for being a traitor
> to WWW, cos I'm not. 

HTTP is very lightweight and very simple, which facilitates extremely
fast server implementations for document query and retrieval.  This
will be significant for serving many people simultaneously vs Gopher
or FTP.

It can also be argued that HTTP is more flexible, as servers can be
trivially constructed to handle a wide variety of specialized data
retrieval functions.  (For instance, a colleague wrote an HTTP 'xgraph
server' the other night that accepts URL's that contain multiple sets
of {x,y} coordinates and returns documents containing inlined images
that have the points plotted out using the guts from xgraph for the
graphics -- try that with the Gopher protocol.)

> Yes, I know that there are rumours that Gopher is to become
> proprietary. Unfortunately, while I regard that as bad, others here
> may regard it as *good*; the idea of paying for a support contract
> makes them feel warm, and secure, despite what experience should by
> now have taught us.

Well, this is a whole 'nuther issue.  The only thing I want to point
out right now is that there's no reason you can't pay for a support
contract for any protocol/server, including FTP, NNTP, or whatever.
And besides, it shouldn't have to be an either/or proposition -- look
at freeWAIS (CNIDR) and WAIS Inc.  And besides, Gopher will likely
still be freely available to non-commercial users, and besides, if
not, others will be doing Gopher servers that will be (if Gopher is in
fact worth doing this for; no comment from me on that one).  And
besides, blah blah blah...

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From brian@eitech.com  Tue May 18 01:45:52 1993
Return-Path: <brian@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28979; Tue, 18 May 93 01:45:52 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04310; Tue, 18 May 1993 02:06:53 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA14576; Mon, 17 May 93 19:06:12 -0500
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA05536; Mon, 17 May 93 17:01:47 PDT
Date: Mon, 17 May 93 17:01:47 PDT
From: brian@eitech.com (Brian Smithson)
Message-Id: <9305180001.AA05536@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: Is HTTP necessary??
Cc: p.lister@cranfield.ac.uk

"Peter Lister, Cranfield Computer Centre" writes:

> HTML is great, but is HTTP worth it? I'm want practical details, so
> don't send me philosophical waffle or flame me for being a traitor
> to WWW, cos I'm not. 

Here's a practical detail, one which pushed me over the edge to setting
up an http server for internal uses.  I wanted to be able to refer to
documents (via hyperlinks) which were rooted somewhere, rather than having
to do a lot of messy stuff like "href=../../../foo/bar.html".  I found it much
easier to use "href=http://site/foo/bar.html"

From brian@eitech.com  Tue May 18 01:58:45 1993
Return-Path: <brian@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29094; Tue, 18 May 93 01:58:45 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04590; Tue, 18 May 1993 02:19:50 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA14622; Mon, 17 May 93 19:19:15 -0500
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA05566; Mon, 17 May 93 17:14:52 PDT
Date: Mon, 17 May 93 17:14:52 PDT
From: brian@eitech.com (Brian Smithson)
Message-Id: <9305180014.AA05566@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: Is HTTP necessary??
Cc: p.lister@cranfield.ac.uk

Oops. I didn't finish the thought before mistakenly delivering the message! :-(
Let me try that again...

"Peter Lister, Cranfield Computer Centre" writes:

> HTML is great, but is HTTP worth it? I'm want practical details, so
> don't send me philosophical waffle or flame me for being a traitor
> to WWW, cos I'm not. 

Here's a practical detail, one which pushed me over the edge to setting
up an http server for internal uses.  I wanted to be able to refer to
documents (via hyperlinks) which were rooted somewhere, rather than having
to do a lot of messy stuff like "href=../../../foo/bar.html".  I found it much
easier to use "href=http://host.domain/foo/bar.html".  It can also be 
a lot easier to maintain.

One could use ftp instead of http, but http is a bit more permissive about
following symbolic links (e.g. outside of ~ftp, for example).

-Brian

From marca@wintermute.ncsa.uiuc.edu  Tue May 18 08:26:35 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02494; Tue, 18 May 93 08:26:35 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15416; Tue, 18 May 1993 08:47:42 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA20523
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 18 May 93 01:47:40 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03223; Tue, 18 May 93 01:50:10 -0500
Date: Tue, 18 May 93 01:50:10 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305180650.AA03223@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: IMG extension for Mosaic 1.1
X-Md4-Signature: b7085a5cc74060fac894bc348f629949

This is a pre-announcement that Mosaic 1.1 will include support for
Tony Sanders' ISMAP attribute as part of IMG elements (see
http://www.bsdi.com/server/walk/walk.html for details) as an HTML
extension.  

I realize that this is another unplanned change that I'm making
without getting a consensus or having it added to the spec or
whatever.  I also realize that, as with the IMG tag, it may be used
fairly widely in documents on the net even though it's not part of the
HTML spec, possibly making those documents not as friendly to other
browsers (although I hear the next Midas will support this, and
really, it's not that complex to add to an existing image-capable
browser).

There are three reasons I'm going ahead and adding support for it to
Mosaic anyway: (a) as it happens, I need to support this capability
internally for certain things in any case, (b) this adds a lot of
power and flexibility to browser interaction without too much overhead
or complexity on either client or server side, and (c) there is simply
no other way to get the same effect, due to a lack of an appropriate
CGM-style hypermedia graphics description language for use in the Web
that would support things like overview diagrams of document sets and
geographical maps with documents tied to different regions, and we
need this functionality in general.

So I hope I don't make anyone too unhappy; if anyone has thoughts or
comments, I'd like to hear 'em...

Marc


From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 18 13:37:33 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05662; Tue, 18 May 93 13:37:33 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04667; Tue, 18 May 1993 13:58:37 +0200
Received: by xdm001 
	id AA21169; Tue, 18 May 93 12:58:27 +0100
Received: by xdm039 (5.57/4.7) id AA21861; Tue, 18 May 93 12:58:23 +0100
Message-Id: <9305181158.AA21861@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Footnotes
Reply-To: p.lister@cranfield.ac.uk
Date: Tue, 18 May 93 12:58:20 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

Hello again

We have quite a few documents which contain footnotes, i.e. links to
short clarifications or definitions which don't break the flow of the
main text. Other browsers generally display them separately from the
main text in pop-up windows, but they remain part of the document, not
a separate file.

I'm trying to translate these documents into HTML. Any chance of a
footnote tag in HTML to make life easier?

Pro tem, I'll probably shove them at the end after a separator, and put
intra document links there and back, but I can't help thinking there's
a more elegant way.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From fine@cis.ohio-state.edu  Wed May 19 02:57:26 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20865; Wed, 19 May 93 02:57:26 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14331; Wed, 19 May 1993 03:18:34 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA25999; Tue, 18 May 93 21:18:30 -0400
Date: Tue, 18 May 93 21:18:30 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305190118.AA25999@soccer.cis.ohio-state.edu>
To: fine@cis.ohio-state.edu, www-talk@nxoc01.cern.ch
Subject: Results of quick vote
X-Mailer: Perl Mail System v1.2


The results are below.  Unfortunately, there was no clear winner.
Things can generally be divided into two camps: those who want
the mailing list to only exist for those people with some sort of
access problem, and those who want the mailing list to serve a separate
purpose from the newsgroup.  These two ideas aren't at all compatible.

Let me say at this point what will be set up.  There WILL be an archive
of the newsgroup, with a Web interface, maintained at this site.  I'm
in the process of setting it up now.  So it will be possible for people
with no access to usenet to READ the stuff thru the web.

Now for my opinion.  Traffic thus far on the newsgroup has been light.
While there has been a lot of noise, this will be reduced as soon as an
FAQ is ready, and as soon as people stop seeing the newgroup message.
Hopefully this will be more true here than in other groups because they
(newbies) will have the thrill of reading the FAQ thru the web, so they
can play with the software rather than annoy us with questions.

I very much agree with the notion that for a successful web, we have to
get the newbies involved.  As it is, the mailing list is seeing some of
this anyway, and I think the mailing list is to big to handle.  If
we really really want separate channels for such discussions, I'd suggest
we do one of the following:

  1. add another (moderated) newsgroup - comp.infosystems.www.tech
    (who wants to moderate it?)
      or
  2. create a separate mailing list for same.

comments?


>Proposal 1.
>  No gateway, let the mailing list die.
>  Vote here if you are planning on reading the newsgroup and unsubscribing
>  from the mailing list.  Note that there will be at least a one-direction
>  gateway; I just wonder how may people won't care if it is there.

12 votes

>Proposal 2.
>  Bi-directional gateway.
>  Vote here if you have no USENET access whatsoever and want to use the
>  mailing list as an interface to the newsgroup

9 votes

>Proposal 3.
>  One-directional gateway. (from mailing list to newsgroup)
>  Vote here if you can read USENET, but not post, or if you want the
>  mailing list to become a small subset of the newsgroup, so you won't
>  have to read the newsgroup.

1 vote

>Proposal 4.
>  One-directional gateway plus newsgroup archiving under the Web.
>  Vote here for a compromise between Prop 2 and Prop 3.

9 votes

>Proposal 5.
>  One and a half directional gateway.  Articles are sent from mailing
>  list to newsgroup.  Digests of articles are sent from newsgroup to
>  mailing list.
>  Vote here if for reasons I can't imagine.  Well, maybe if you
>  are a uucp site, with no USENET or Web access.  Yuck.

2 votes

From fine@cis.ohio-state.edu  Wed May 19 03:05:22 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20943; Wed, 19 May 93 03:05:22 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15232; Wed, 19 May 1993 03:26:31 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA26044; Tue, 18 May 93 21:26:29 -0400
Date: Tue, 18 May 93 21:26:29 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305190126.AA26044@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: newsgroup faq
X-Mailer: Perl Mail System v1.2

I'm going to build an FAQ.  Please send me questions you think will be
asked frequently, preferably with answers.  Keep the answers SHORT.
About one XMosaic screen is a good measure. :-)

Here is a list of questions I expect to include already:

Introduction/glossary
---------------------
What is WWW?
What is hypertext?
What is HTML?
What is a URL?
What is Gopher?
What is WAIS?
What is SGML?
What is MIME?
What is HTPS?

General
-------
How do I pronounce it?
Is this newsgroup archived?
Where did this all start?

Philosophy/Flame topics
-----------------------
Why shouldn't there be real formatting control in HTML?
Why is it important to comply with SGML?
Why shouldn't we keep adding neat things to HTML?

Software
--------
What browsers are out there?
Are there any editors out there?
Is there software to convert XXX to html?
Is there software to convert html to XXX?
To do list

XMosaic
-------
How do I get better key bindings in the text and textfield windows



From fine@cis.ohio-state.edu  Wed May 19 03:19:32 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21082; Wed, 19 May 93 03:19:32 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17097; Wed, 19 May 1993 03:40:41 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA26122; Tue, 18 May 93 21:40:38 -0400
Date: Tue, 18 May 93 21:40:38 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305190140.AA26122@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Update: Usenet FAQ project
X-Mailer: Perl Mail System v1.2


Check out http://www.cis.ohio-state.edu/hypertext/faq/usenet/top.html
(or just go to Ohio State's home page, and click on "Usenet FAQs").

Coming soon:
  automatic linking to all RFCs, man pages, http references, and gopher
  references.  Linking to other FAQs will be supported but will require
  cooperation of the FAQ maintainers.

  WAIS index.

Coming later:
  An additional ordering based on newsgroup hierarchy.

        tom

From dsr@hplb.hpl.hp.com  Wed May 19 12:24:18 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24931; Wed, 19 May 93 12:24:18 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25975; Wed, 19 May 1993 12:45:26 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 19 May 93 11:38:25 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA03145; Wed, 19 May 93 11:46:29 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305191046.AA03145@manuel.hpl.hp.com>
Subject: Re: Formatting Options in HTML?
To: www-talk@nxoc01.cern.ch
Date: Wed, 19 May 93 11:46:27 BST
Mailer: Elm [revision: 66.36.1.1]

Bill Jansen (Wed, 12 May 1993 19:39:23 PDT) says:

> Rather than add things like <CENTER> and <FLUSH-RIGHT> to the HTML
> document, it seems that this sort of thing should be decided by the user
> in their browser.  That is, probably most text should be filled and both
> right and left justified by default, unless the user specifies
> otherwise.  The user should be able to specify things like this for
> different region-types of all documents, not for specific regions of
> specific documents.

I agree with Bill in leaving the style settings to the browser.
The long term success of HTML and WWW will depend on our resisting
the temptation to add style information to HTML. This is critically
important to supporting a wide range of document types, and continued
presentation independance on a wide and evolving range of platforms.
Have you see the screen sizes on PDAs?

We have a chance to come up with a ubiquitous world beating standard.
This will depend on presentation independence, lightweight processing
demands and our skill at understanding people's real needs for a wide
range of on-line and paper documents.

Dave Raggett

From dsr@hplb.hpl.hp.com  Wed May 19 12:57:19 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25264; Wed, 19 May 93 12:57:19 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01359; Wed, 19 May 1993 13:18:27 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 19 May 93 12:11:25 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA11610; Wed, 19 May 93 12:19:27 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305191119.AA11610@manuel.hpl.hp.com>
Subject: Re: HTML+ and printed books
To: dale@ora.com
Date: Wed, 19 May 93 12:19:26 BST
Cc: sanders@bsdi.com, raisch@ora.com, dmh@openmail.corp.hp,
        www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Tony Sanders writes:

>> Has much thought gone into features needed to have data be both online
>> and used to print books.  When you are using a hypertext browser you
>> want one view of the data and when you print a book you'll need another.

Dale Dougherty replies:

> My sense is that this is really too big a problem to be handled
> at the HTML-level.  At some point, we have to distinguish between
> a DTD such as Docbook used to maintain information for 
> multiple purposes and a DTD like HTML used primarly for delivery.

I would be really interested in having a look at the Docbook DTD,
and some of the background assumptions and motivation for this work.
Can you give me a pointer to where I can get further information?

When viewing an HTML document, I find it a common experience to want
to print out part of the web, not just this particular document.
Supporting a model of how retrievable chunks form a larger whole would
permit this. Furthermore, it would permit authors to exploit peoples
familiarity with printed material as an additional navigation model
to basic hypertext. Authors will need to bear in mind that the documents
will also be read on paper media, and avoid reference to clicking etc.

For this reason, I am currently studying how we could represent such
models effectively in HTML+, and analysing a wide variety of fiction,
reference books, magazines, newspapers and technical documentation.
The guiding principles are:

    o   superset of the current HTML DTD

    o   presentation independance (no style info)

    o   easy/fast to process with modest programs

    o   offline compilation of indexes/contents

    o   support the needs of a wide as possible
        range of on-line and printed material

The results so far are very encouraging. Provided you don't mind seeing
work at an early and incomplete stage, you may be interested in looking
at "ftp://hplose.hpl.hp.com/pub/dtd2.html". I would be very interested
in collaborating on this work.

Best wishes,

Dave Raggett,

p.s. Tony, I am including change bars in the draft proposal for HTML+

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From dsr@hplb.hpl.hp.com  Wed May 19 14:23:58 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26355; Wed, 19 May 93 14:23:58 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15582; Wed, 19 May 1993 14:45:06 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 19 May 93 13:38:05 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12545; Wed, 19 May 93 13:46:05 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305191246.AA12545@manuel.hpl.hp.com>
Subject: Re: HTML+ and printed books
To: brennan@hal.com
Date: Wed, 19 May 93 13:46:03 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

>> The obvious structuring element corresponds to the contents list, e.g.
>>
>>    <CONTENTS> 
>>      <A HREF ="doc1.html">Introduction to home brewing</A>
>>      <A HREF ="doc2.html">Equipment Needed</A> 
>>      <A HREF ="doc1.html">The basic skills</A>
>>      <A HREF ="doc1.html">Popular recipes</A>
>>    </CONTENTS>

> Would these be top level headings?  I think a level indication is
> appropriate in this case, so instead you'd have entries like:

>     <A HREF ="doc1.html"><H1>Introduction to home brewing</H1></A>

No, it would be an abuse of the concept of what a header is. To specify
the level of each entry you really need another mechanism.

 (By the way your example is bad practice - the header tags
  should include the anchor element - not the other way round)

I have been studying fiction, reference books, various types of technical
documentation, magazines and newspapers to get a deeper understanding of
what presentation independent markup is needed. It now seems to me that
A more explicit mechanism is needed which includes tags for chapters,
sections, and subsections etc. The analysis looks really encouraging and
I am working out how to fit it into the DTD.

> While this make sense in a printed world where each chapter (node) only
> appears in one book (for the most part), it doesn't make sense in the
> hypertext world where a node can potentially occur in as many books as
> people can dream up.  It would be up to the browser software to keep track
> of the current book or books that you're browsing through.  The model would
> be that an on-line book is just another "view" into the information space.
> I think that this is a powerful and useful notion.

I remember discussing this point with Tim Berners Lee in a trip to CERN last
year. Users will want to exploit the table of contents view and the ability
to print out collected chunks from arbitary points. This suggests the need
to define links from the currently viewed document to such elements.

Hypertext links from outside into particular sections of an on-line book
are normally consistent with the notion of following references between
books - it doesn't change what the user expects to get printed. It is only
in the case where you have books which "borrow" sections from other books
that the trouble occurs.

Reconciling these two models can be achieved by:

    a)  normal links don't change the "standard" association between
        a retrievable chunk and an on-line book/magazine/newspaper etc.
        as defined by <LINK REL="CONTENTS" HREF="contents.html">

    b)  links which have the effect of borrowing sections from other
        books are special and override the "standard" association.

These special links could be designated by the REL attribute in the <A> tag.

  e.g.    <a rel="borrow" href="http://foo/bar">A borrowed section</A>

Best wishes,

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com


From dsr@hplb.hpl.hp.com  Wed May 19 14:43:59 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26672; Wed, 19 May 93 14:43:59 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19321; Wed, 19 May 1993 15:05:07 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 19 May 93 13:58:05 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12571; Wed, 19 May 93 14:06:08 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305191306.AA12571@manuel.hpl.hp.com>
Subject: Re: Formatting Options in HTML?
To: wei@xcf.berkeley.edu
Date: Wed, 19 May 93 14:06:06 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Thanks Pei for your comments:

>>>         <LI><H1> This item should attract attention </H1>
>> Actually Aleksandar, headers are *NOT* currently permitted in <LI> list
>> elements. Instead you should use the emphasis tags.

> But what if you want ``a list of headers''? I don't see anything wrong 
> with that concept, and so I'd rather not see it restricted. Yes, in 
> this particular case (just to attract attention) I would agree that
> <EMPH> be used. But I still don't see why <H*> should be restricted,
> especially given that <H*> can be between paragraphs and all that, anyway.

The problem with allowing headers in lists, is what do they mean.
When compiling a table of contents, the header level is valuable to
how you structure the contents. Headers inside lists would seem to be
subservient to one which aren't - but how do you compare them?

> BTW, short names like <QUOTE> (insteadof <QUOTEBODY>) is probably a
> good idea... just to avoid having to redeclare NAMELENGTH thing...

Thanks.

Dave

From dsr@hplb.hpl.hp.com  Wed May 19 14:53:18 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26881; Wed, 19 May 93 14:53:18 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21024; Wed, 19 May 1993 15:14:26 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 19 May 93 14:07:25 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12583; Wed, 19 May 93 14:15:29 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305191315.AA12583@manuel.hpl.hp.com>
Subject: can HTML authors declare new tags?
To: www-talk@nxoc01.cern.ch
Date: Wed, 19 May 93 14:15:28 BST
Mailer: Elm [revision: 66.36.1.1]

Joe Germuska writes:

> That reminds me -- can HTML authors declare new tags?  It would seem far
> too complicated for clients to deal with newly introduced styles, but
> perhaps, with customizable displays, the client could just add unfamiliar
> styles to the "style index", and the user could make changes as desired...
> (remember I know next to nothing about the implementation of Web clients,
> so if this is outrageous, please be gentle :-)  

Actually the ability to extend HTML with specific semantic tags would
be useful for a variety of applications. At its most straightforward
the extra tags would be simply ignored by HTML browsers, but would be
very useful for special purpose indexing or database interfaces. Such
extensions should be declared using the appropriate SGML elements
e.g. <!ENTITY>, <!ELEMENT> and <!ATTLIST>.

Best wishes,

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From gehmeyr@forwiss.uni-passau.de  Wed May 19 15:00:28 1993
Return-Path: <gehmeyr@forwiss.uni-passau.de>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26981; Wed, 19 May 93 15:00:28 MET DST
Received: from forwiss.uni-passau.de by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22337; Wed, 19 May 1993 15:21:31 +0200
Received: from turgon.forwiss.uni-passau.de (turgon) by forwiss with SMTP id AA03885
  (5.65c+/IDA-1.4.4 for <www-talk@nxoc01.cern.ch>); Wed, 19 May 1993 15:21:24 +0200
Received: by turgon.forwiss.uni-passau.de id AA06220
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 19 May 1993 15:21:11 +0200
From: Andreas Gehmeyr <gehmeyr@forwiss.uni-passau.de>
Message-Id: <199305191321.AA06220@turgon.forwiss.uni-passau.de>
Subject: image-problems
To: www-talk@nxoc01.cern.ch
Date: Wed, 19 May 1993 15:21:10 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 457       

Hi all,
Since I've installed the http-Daemon, I've got Problems with 
inlined Images (I'm using XMosaic 1.0). Whenever I'm referencing
with file:, everything is fine. If I'm using the Daemon, I get
the Standard-XMosaic Logo instead.
What's gone wrong?
Sorry, if it's a faq!
Servus,
Andi 

-- 
 "I have something to say:       |      Andreas Gehmeyr, FORWISS Passau
  It's better to burn out,       |      gehmeyr@forwiss.uni-passau.de
  than to fade away!"

From dsr@hplb.hpl.hp.com  Wed May 19 15:28:33 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27496; Wed, 19 May 93 15:28:33 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27453; Wed, 19 May 1993 15:49:41 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 19 May 93 14:42:39 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12870; Wed, 19 May 93 14:50:39 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305191350.AA12870@manuel.hpl.hp.com>
Subject: Re:  HTML DTD
To: dianew@sco.com
Date: Wed, 19 May 93 14:50:37 BST
Cc: bobs@sco.com, www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> Marc Andreessen mentioned that you were working on the HTML DTD and
> that you might be able to answer some of my questions regarding
> the future direction of HTML.  Specifically, are there any plans
> to directly support any of the following features in HTML:
        
>         - Graphics (ie., similar to the <IMG> extension that
>           the NCSA folks are using in Mosaic)

Yes. Current thinking is to adopt the NCSA's <IMG> element, perhaps with
some additional attributes, and to also have an element for inline icons.

>         - Super- and subscripts

Can you tell me what you want these for. Footnotes and cross references
are best handled in other ways, while a full treatment of mathematical
equations is outside the scope of HTML and best handled by embedding
figures.

>         - Non-breakable spaces (outside of <PRE> sections).
>           Eg., to keep a phrase within a sentence from being
>           split across lines.

Good idea.

>         - Support for popup windows (ie., specifying that a
>           piece of text or a graphic should appear in a separate
>           popup window)

The approach I am considering is to allow for information to be specified
as being outside the linear flow of the document. If you look at magazines
you will see that such floating panels are common place for illustrations,
background material, and advertisements.

> Actually, any general information that you can provide regarding
> current and future plans for HTML would be greatly appreciated.

If you don't mind looking at work in progress (incomplete and inconsistent)
try looking at ftp://hplose.hpl.hp.com/pub/dtd2.html

Best wishes,

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From cja@castle.edinburgh.ac.uk  Wed May 19 16:03:04 1993
Return-Path: <cja@castle.edinburgh.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28173; Wed, 19 May 93 16:03:04 MET DST
Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03984; Wed, 19 May 1993 16:24:07 +0200
Via: uk.ac.edinburgh.castle; Wed, 19 May 1993 15:14:31 +0100
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HTML+ and printed books
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Cc: www-talk@nxoc01.cern.ch
Date: Wed, 19 May 93 15:14:25 WET DST
Message-Id: <9305191514.aa26173@castle.ed.ac.uk>

Dave Raggett writes:

> When viewing an HTML document, I find it a common experience to want
> to print out part of the web, not just this particular document.
> Supporting a model of how retrievable chunks form a larger whole would
> permit this.

I think there are two aspects to this:

(A) Identifying a subset of the Web - a number of asssociated HTML
    documents (and other non-text data).

(B) Processing this set in some way - eg printing it, indexing it,
    searching it, perhaps mailing it to someone while preserving the
    links within the set, etc.

For (A), the set could be determined by the author (eg, someone who
publishes a manual on the web as a set of HTML documents).
The set could also be determined by the reader, who may say "Include all
documents no more than N links away from this one".  Or more generally,
you could add an attribute to a link giving a "relevance number"
decrement: the user could specify an initial relevance count, and the
set would be all documents which could be reached from the currently
displayed one without reducing the relevance count to 0.  I think
this is appropriate for much of the information presently on the Web,
and is more realistic than expecting readers to write their own TOCs.

The actual processing of the set of documents needs some extra
information - eg, printing requires sequence information (available from
a TOC).  In some ways, it would be nice to separate the subsetting (A)
from the extra information needed for processing (B).  But its not
obvious how to achieve that.

How about more than one level of TOCs? A manual chapter could have its
own TOC, which would be linked to from the overall manual TOC.  Many
Microsoft programming manuals are structured like this.  This would
shorten the main TOC and would also give the reader the option of
printing out the whole manual or just one chapter.

> The results so far are very encouraging. Provided you don't mind seeing
> work at an early and incomplete stage, you may be interested in looking
> at "ftp://hplose.hpl.hp.com/pub/dtd2.html". I would be very interested
> in collaborating on this work.

I would like to help - but hplose.hpl.hp.com won't cooperate: it says
"Connection timed out".  Can you mail the DTD?

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom


From dcmartin@lib.ucsf.edu  Wed May 19 18:43:33 1993
Return-Path: <dcmartin@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01681; Wed, 19 May 93 18:43:33 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04843; Wed, 19 May 1993 19:04:29 +0200
Received: from [128.218.15.236] by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA23513; Wed, 19 May 93 10:02:02 PDT
Message-Id: <9305191702.AA23513@knowman.lib.ucsf.EDU>
From: dcmartin@ckm.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@lib.ucsf.edu
In-Reply-To: Your message of Wed, 19 May 93 12:19:26 +0000
	<9305191119.AA11610@manuel.hpl.hp.com> 
Subject: Re: HTML+ and printed books 
Date: Wed, 19 May 93 10:01:40 MDT
Sender: dcmartin@lib.ucsf.edu

Well, just to throw my $0.02 into the works, I saw such a technique
utilized under Microsoft Cinemania.  They used a broken underline vs. a
solid underline to indicate additional material directly related to the
document being browsed vs. another document.  They used this distinction
to allow for document pop-up windows to display associated material
(e.g. footnotes).

I gather from your explanation that document components or "meta"
documents are needed to determine the scope of the material which should
be printed.  I agree in principle, but would also like to present the
possibility of utilizing relevance ranking to determine the scope of
material received or printed, i.e. find document A, tell the system to
print, the system would locate all other documents "similar to" that
document and present them to you hierarchically (optionally) and then
allow you to trim the tree either explicity or implicitly (via
specifying a relevance cut-off).

Again, my $0.02.

dcm
--------
Dave_Raggett writes:

Tony Sanders writes:

>> Has much thought gone into features needed to have data be both online
>> and used to print books.  When you are using a hypertext browser you
>> want one view of the data and when you print a book you'll need another.

Dale Dougherty replies:

> My sense is that this is really too big a problem to be handled
> at the HTML-level.  At some point, we have to distinguish between
> a DTD such as Docbook used to maintain information for 
> multiple purposes and a DTD like HTML used primarly for delivery.

I would be really interested in having a look at the Docbook DTD,
and some of the background assumptions and motivation for this work.
Can you give me a pointer to where I can get further information?

When viewing an HTML document, I find it a common experience to want
to print out part of the web, not just this particular document.
Supporting a model of how retrievable chunks form a larger whole would
permit this. Furthermore, it would permit authors to exploit peoples
familiarity withprinted material as an additional navigation model
to basic hypertext. Authors will need to bear in mind that the documents
will also be read on paper media, and avoid reference to clicking etc.

For this reason, I am currently studying how we could represent such
models effectively in HTML+, and analysing a wide variety of fiction,
reference books, magazines, newspapers and technical documentation.
The guiding principles are:

o   superset of the current HTML DTD

o   presentation independance (no style info)

o   easy/fast to process with modest programs

o   offline compilation of indexes/contents

o   support the needs of a wide as possible
range of on-line and printed material

The results so far are very encouraging. Provided you don't mind seeing
work at an early and incomplete stage, you may be interested in looking
at "ftp://hplose.hpl.hp.com/pub/dtd2.html". I would be very interested
in collaborating on this work.

Best wishes,

Dave Raggett,

p.s. Tony, I am including change bars in the draft proposal for HTML+

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From emv@garnet.msen.com  Wed May 19 18:44:41 1993
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01703; Wed, 19 May 93 18:44:41 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05414; Wed, 19 May 1993 19:05:44 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0nvraH-000EZqC; Wed, 19 May 93 13:05 EDT
Message-Id: <m0nvraH-000EZqC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: spatial wais server + www point-to-a-picture stuff
Date: Wed, 19 May 93 13:05:41 EDT
From: Edward Vielmetti <emv@garnet.msen.com>

It would certainly be useful if the WAIS "spatial indexing" work
could be dovetailed nicely with the existing World Wide Web
browsers taht support direct point-and-click selection on images.

This looks like a good time to get involved in those efforts,

--Ed


------- Forwarded Message

Date: Wed, 19 May 1993 08:52:39 -0400
From: ddnebert@dsdnqvarsa.er.usgs.GOV (Douglas D. Nebert (x5691))
Message-Id: <9305191252.AA16426@dsdnqvarsa.er.usgs.GOV>
To: wais-talk@think.com, zip@cnidr.org
Cc: ebouck@dsdnqvarsa.er.usgs.GOV
Subject: Planning for the future

We are ready to integrate the spatial indexing and search functions into
the WAIS code, so that rather than be an add-on it would be another  command-
line option in waisindex and would be evaluated as a word condition, preferably 
using the boolean constructs that have been added by gilbert@uibio.

Our choices are 1) integrate with the b5 code with extensions and no copyright
concerns, 2) integrate with the freeWAIS code and dovetail with Z39.50 (92)
or 3) write our own indexer and server that take cohesive portions of code
from b5 but make it easier to follow and be more extensible.

What is the best path to take to make the spatial processing code portable
so that it can be used now and also with the 1992 compliant server?  The main
programmer we have working on this is getting increasingly disenchanted with
the code noting that it is not easily extensible -- a feature that should
be pursued in new versions of the WAIS code.  We also need someone with 
discipline to collate and 'sanitize' the code so it looks like it was written
by one author in a highly structured way.  I had expected this with freeWAIS
but it did not happen.

Word is/was that the search engine will be completely rewritten to anticipate
the 1992 Z39.50 compliance.  Is this already being done?  How will it be
rewritten and how will its features be coordinated with contributing authors?
Or will it just be rewritten to accommodate attribute searching but be left
mostly as-is?  Who is doing this?

What is the best investment of our effort in the next couple of months?  

Doug Nebert

[Replace this line with your message]


------- End of Forwarded Message


From sanders@bsdi.com  Wed May 19 19:19:58 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02664; Wed, 19 May 93 19:19:58 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11773; Wed, 19 May 1993 19:41:01 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA04120; Wed, 19 May 93 12:40:51 -0500
Message-Id: <9305191740.AA04120@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: MIME and HTRQ/V1.0 question
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 19 May 1993 12:40:51 -0500
From: Tony Sanders <sanders@bsdi.com>

When returning a document of unknown content what should the header
format say?

Options as I see it are:

1   Content-type: text/plain\n\n[raw data]

2   Context-type: text/html\n\n<PLAINTEXT>\n[raw data]
    [Is <PLAINTEXT> being depreciated?]

3   Context-type: application/binary [for binary files and]
    Context-type: text/plain [for text files]

I'm assuming option #3 unless I hear otherwise.  It will work well
if browers do something like <PLAINTEXT> for text/plain and
pop up a save file dialog for application/binary.

Marc: How is Mosaic going to handle things like .cave files?
are there going to be MIME types added for stuff like this?
Here are my current plans.
    # XXX: need to make tar, uu, z, and Z be encodings
    #
    $ext{'aiff'}  = $ext{'AIFF'}  = 'application/binary';
    $ext{'au'}    = $ext{'AU'}    = 'application/binary';
    $ext{'snd'}   = $ext{'SND'}   = 'application/binary';
    $ext{'cave'}  = $ext{'CAVE'}  = 'application/binary';
    $ext{'dvi'}   = $ext{'DVI'}   = 'application/dvi';
    $ext{'evlm'}  = $ext{'EVLM'}  = 'application/binary';
    $ext{'gif'}   = $ext{'GIF'}   = 'image/binary';
    $ext{'html'}  = $ext{'HTML'}  = 'text/html';
    $ext{'jpeg'}  = $ext{'JPEG'}  = 'image/jpeg';
    $ext{'jpg'}   = $ext{'JPG'}   = 'image/jpeg';
    $ext{'mime'}  = $ext{'MIME'}  = 'application/binary';
    $ext{'movie'} = $ext{'MOVIE'} = 'application/binary';
    $ext{'mpeg'}  = $ext{'MPEG'}  = 'application/binary';
    $ext{'mpg'}   = $ext{'MPG'}   = 'application/binary';
    $ext{'ps'}    = $ext{'PS'}    = 'application/postscript';
    $ext{'rgb'}   = $ext{'RGB'}   = 'application/binary';
    $ext{'rtf'}   = $ext{'RTF'}   = 'application/binary';
    $ext{'tar'}   = $ext{'TAR'}   = 'application/binary';
    $ext{'hqx'}   = $ext{'HQX'}   = 'application/binary';
    $ext{'uu'}    = $ext{'UU'}    = 'application/binary';
    $ext{'tex'}   = $ext{'TEX'}   = 'application/binary';
    $ext{'tiff'}  = $ext{'TIFF'}  = 'application/binary';
    $ext{'tif'}   = $ext{'TIF'}   = 'application/binary';
    $ext{'txt'}   = $ext{'TXT'}   = 'application/binary';
    $ext{'text'}  = $ext{'TEXT'}  = 'application/binary';
    $ext{'xbm'}   = $ext{'XBM'}   = 'image/xbitmap';
    $ext{'xwd'}   = $ext{'XWD'}   = 'image/xwindowdump';
    $ext{'z'}     = $ext{'Z'}     = 'application/binary';      # different!
I also need to figure out how to the the encoding stuff work
for MIME.  Guess I need to study the RFC for a while.

Comments/suggestions?  lemme know

--sanders@bsdi.com

From janssen@parc.xerox.com  Wed May 19 20:08:44 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03813; Wed, 19 May 93 20:08:44 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17348; Wed, 19 May 1993 20:29:53 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11878>; Wed, 19 May 1993 11:29:41 PDT
Received: by holmes.parc.xerox.com id <16149>; Wed, 19 May 1993 11:29:32 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 19 May 1993 11:29:20 -0700 (PDT)
Message-Id: <4fybm0cB0KGW96cKsP@holmes.parc.xerox.com>
Date: 	Wed, 19 May 1993 11:29:20 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, sanders@bsdi.com
Subject: Re: MIME and HTRQ/V1.0 question
In-Reply-To: <9305191740.AA04120@austin.BSDI.COM>
References: <9305191740.AA04120@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 19-May-93 MIME and HTRQ/V1.0 question
Tony Sanders@bsdi.com (2518)

> 3   Context-type: application/binary [for binary files and]
>     Context-type: text/plain [for text files]

I presume a binary file is any that contains an octet outside the values
[00H..7FH]?  In that case, sounds reasonable to me.  Remember that
text/plain really means "text/plain; charset=us-ascii".

Bill

From marca@wintermute.ncsa.uiuc.edu  Wed May 19 20:45:47 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04658; Wed, 19 May 93 20:45:47 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23842; Wed, 19 May 1993 21:06:56 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14786
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 19 May 93 14:06:55 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA09898; Wed, 19 May 93 14:09:24 -0500
Date: Wed, 19 May 93 14:09:24 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305191909.AA09898@wintermute.ncsa.uiuc.edu>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: MIME and HTRQ/V1.0 question
In-Reply-To: <9305191740.AA04120@austin.BSDI.COM>
References: <9305191740.AA04120@austin.BSDI.COM>
X-Md4-Signature: 9619b9ebc0c140d0b204ada8d5393a5d

Tony Sanders writes:
> When returning a document of unknown content what should the header
> format say?
> 
> Options as I see it are:
> 
> 1   Content-type: text/plain\n\n[raw data]
> 
> 2   Context-type: text/html\n\n<PLAINTEXT>\n[raw data]
>     [Is <PLAINTEXT> being depreciated?]
> 
> 3   Context-type: application/binary [for binary files and]
>     Context-type: text/plain [for text files]

Yes (3).  When in complete doubt, punt to an octet-stream.

> I'm assuming option #3 unless I hear otherwise.  It will work well
> if browers do something like <PLAINTEXT> for text/plain and
> pop up a save file dialog for application/binary.
> 
> Marc: How is Mosaic going to handle things like .cave files?
> are there going to be MIME types added for stuff like this?

I figure application/x-cave will be enough.  People outside NCSA/EVL
probably don't need to think about this particular one, its presence
in the Mosaic code notwithstanding, but the same issue will come up
repeatedly all over the place and the answer should almost always be
an experimental (x-) MIME content subtype.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From sanders@bsdi.com  Thu May 20 00:37:44 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09642; Thu, 20 May 93 00:37:44 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26441; Thu, 20 May 1993 00:58:54 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA07480; Wed, 19 May 93 17:58:51 -0500
Message-Id: <9305192258.AA07480@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: HTTP/V1.0 support in Plexus ready for testing
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 19 May 1993 17:58:51 -0500
From: Tony Sanders <sanders@bsdi.com>

Ok, I've got my server running the latest Plexus that supports HTTP/V1.0.
It seems to work ok with Mosaic 1.0 (using HTTP/V0.9) and tkWWW 0.8 (using
HTTP/V1.0).  I'll continue to learn about MIME and tweek the Content stuff.
Please give it a whirl and let me know if you have any problems.

    http://www.bsdi.com/

The source is in http://www.bsdi.com/server/Plexus-2.0.tar.Z and
http://www.bsdi.com/server/ but you should probably wait for 2.1
so it'll be more stable.  I also need to update the docs, consider
V2.0 beta code for now.

BTW: Thanks to joe@Athena.MIT.EDU for the idea about putting
the context-type in %ext.

--sanders@bsdi.com

From mcrae@lib.ucsf.edu  Thu May 20 01:00:27 1993
Return-Path: <mcrae@lib.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09979; Thu, 20 May 93 01:00:27 MET DST
Received: from knowman.lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29378; Thu, 20 May 1993 01:21:36 +0200
Received: from theodoric.lib.ucsf.EDU by knowman.lib.ucsf.EDU (4.1/GSC4.21)
	id AA25124; Wed, 19 May 93 16:19:09 PDT
Message-Id: <9305192319.AA25124@knowman.lib.ucsf.EDU>
To: www-talk@lib.ucsf.edu
Subject: Re: HTML+ and printed books 
In-Reply-To: Your message of "Wed, 19 May 93 10:01:40 MDT."
             <9305191702.AA23513@knowman.lib.ucsf.EDU> 
Date: Wed, 19 May 93 16:23:11 MDT
From: "Christopher J. McRae" <mcrae@lib.ucsf.edu>


Dave Raggett writes:
|  Perhaps we need some structuring elements which determine how a 
|  group of related documents can be sequenced into a form suitable 
|  for printing, along with a way of automatically generating a table 
|  of contents, and an index.

In response, Daniel Kehoe writes:
|  >From this point of view, it seems a bad idea to include "structuring  
|  elements" inside documents that tie them together for printing (if  
|  that's what you were suggesting), 

  I agree that the idea of "structuring elements" specific to printing is
a bad idea.  It seems to be just another way of sneaking presentation
information into the DTD, something which many seem to agree is a bad idea.
  
  There are many different possible approaches to searching the web and
extracting subsets of it for various purposes.  As architects of the hypertext
infrastructure, our job is to provide an information architecture rich enough
to support any search/pruning method.  We should avoid imposing any particular
interpretation upon the information, but rather enable others to apply their
own interpretations as they see fit.  The author of a document may choose to
publish one or more default organizations along with the information itself,
and readers may choose to select an alternate organization.  So, all we need
in HTML is a *general* way of specifying relationships between documents, which
is what we already have in the REL attribute. 

  Note that the list of HTML link relationships is not part of the HTML
standard (see http://info.cern.ch/hypertext/WWW/MarkUp/Relationships.html).
This is good and allows for different standard "sets" of relationship values
to be defined and used.  I am reminded of the "element sets" referred to as
part of ANSI Z39.50 (ISO 10162/10163).  That standard does not require that all
clients or servers support any specific element set.  Rather, each registered
element set has a unique name; the client and server neogiate on the element
set(s) to be used in a session. Several archetypal element sets are defined for
well-defined domains such as bibliographic references, but the protocol itself
does not limit the definition of element sets in general.  In fact, Z39.50
servers can use ASN.1 to describe element sets to clients who would otherwise
not recognize those sets.

  Similarly, relationship-sets could be defined for some archetypal forms
which we all use and understand (journals, books, programs, etc.).  For
instance, while we certainly would like the capability to break out the
chapters and other components of a book, it doesn't make sense to speak
of a "chapter" of an animation any more than it does to reference a "frame"
of a book.  So, we use different sets of relationship attributes for different
types of data.  Perhaps we should add a relationship-set specification to the
document header. Something like,

<HEADER> <REL-SET NAME="US Book 153.5"> </HEADER>

If we allowed relationship-set specification within an anchor tag, then we
could support the use of mulitple relationship-sets within a single document.
For example,

<A HREF="http://foo/bar" REL-SET="CERN" REL="Made,REV">Dr. Elmer J. Fudd</A>
<A HREF="http://foo/bar" REL-SET="ISO-Journal 101" REL="ABSTRACT">Abstract</A>
ARTICLE TEXT HERE
<A HREF="http://foo/bar" REL-SET="US-MARC" REL="BIBLIO">References</A>

Of course, once we start using different relationship sets, a client may come
across a document containing relationships which it doesn't know about.  This
could be solved using ASN.1 just as is done in Z39.50.  
   
  An alternative approach would be to use multiple DTD's. Why not just
incorporate generic SGML parsing into the browsers and have many "variants" of
HTML.   We could provide a mechanism in the protocol for requesting the URL of
the DTD corresponding to the structure of some other URL and then use that DTD
to interpret the incoming document.  That is, when the user activates a link
to some document, we contact the server specified in the HREF of that link and
rather than requesting the item referenced in the URL, we request the DTD
describing the tags contained in the referenced item.  The server then would
either return the DTD, or a URL for that DTD.  Once we have parsed and perhaps
cached the DTD, we would then request the referenced item and process it
accordingly.  (I hope my ignorance of SGML isn't showing too badly here)

Chris
------------------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From PAC@ib.rl.ac.uk  Thu May 20 09:49:23 1993
Return-Path: <PAC@ib.rl.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14494; Thu, 20 May 93 09:49:23 MET DST
Received: from crnvmb.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06377; Thu, 20 May 1993 10:10:35 +0200
Message-Id: <9305200810.AA06377@dxmint.cern.ch>
Received: from CERNVM.CERN.CH by CERNVM.CERN.CH (IBM VM SMTP V2R2)
   with BSMTP id 7705; Thu, 20 May 93 10:11:21 SET
Received: from UKACRL.BITNET (NJE origin MAILER@UKACRL) by CERNVM.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 9232; Thu, 20 May 1993 10:11:21 +0200
Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 8362; Thu,
 20 May 93 09:12:20 BST
X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender.
Received: from UK.AC.RL.IB (PAC) by UK.AC.RL.IB (Mailer R2.07) with BSMTP id
 3770; Thu, 20 May 93 09:12:20 BST
Date:     Thu, 20 May 93 08:56:33 BST
From: PAC@ib.rl.ac.uk
Subject:  WWW Front page for RAL
To: www-talk@nxoc01.cern.ch


The Rutherford Appleton Labratory has introduced a World Wide Web service
to provide access to site information and services.


URL:    http://www.rl.ac.uk/rutherford.html


If you have any problems or queries please mail to


              www-master@letterbox.rl.ac.uk


Paul Cahill
Applications and User Support Group
Rutherford Appleton Lab.
OXON,UK

From mvanheyn@cs.indiana.edu  Thu May 20 20:00:47 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23269; Thu, 20 May 93 20:00:47 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10863; Thu, 20 May 1993 20:21:58 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA00456; Thu, 20 May 1993 13:21:53 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: feednews@news.cs.indiana.edu, www-talk@nxoc01.cern.ch
Newsgroups: comp.infosystems.www,cs.techrpt
Subject: New service: The Unified CS TR Index
Distribution: world
Organization: Computer Science Dept, Indiana University
Date: Thu, 20 May 1993 13:21:53 -0500
Message-Id: <454.737922113@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Announcing the availability of an experimental new service within the
World Wide Web (WWW), the Unified Computer Science Technical Report
Index.

WHAT IT IS

It's pretty simple, really.  A daemon runs and pulls index files from
many various FTP sites which archive tech reports (and similar
material.)  At present, 39 FTP sites are included in the index, with
over 1,400 reports included; both of these numbers are growing rather
rapidly.  This information is then converted into entries for each
tech report with hypertext anchors to the TR itself, producing a
really big file.  This file is then searchable for keywords by a
Simple Index Keyword Search (SIKS).  I believe it represents a
potentially nicer general interface to this informational resources
than existing methods (e.g. WAIS pointers to ftp sites).  It certainly
is not the ultimate information browsing tool, but I hope it may push
the migration towards such a little.

Note that this index only maintains pointers to papers that are
available online by a simple mouse click within XMosaic; following a
link will not entail walking to your local library or sending somebody
a check.  I do not know of any other indexing system for CS papers
which is this large and which easily allows direct network access to
the documents themselves.

HOW TO USE IT

The URL is:

    http://cs.indiana.edu/cstr/search

LIMITATIONS

This is still highly experimental, but I wanted to mention its
existence to the world so people can start to play around with it.

I'm sure there are some sites that archive TRs and the like that
aren't included in the TR listings I got my hands on.  I'm not even
done looking through the listings I have yet, so please don't bombard
me with random names of archive sites not yet indexed just now unless
you are the maintainer of one.

There are a lot of different archive sites, and thus there are a lot
of different file formats for the indexes.  Some sites don't have an
index at all.  Some sites have file structures that are not easy to
grok.  The daemon I have written understands several different types
of indexing, but does so in a rather crude way; thus, the results are
typically functional but may not always look pretty.  If you don't
like this, then you'll have to go out and persuade every site that
archives TRs to agree on a standardized index file format.  Good luck;
should take about 10 years. :-) If you would just like one specific
site (say, yours) to look a little nicer, write some code in perl to
do so and send it to me and I'll see what I can do.

Obviously, if an FTP site happens to be down when the index is made,
its stuff won't be in there.  Other errors (e.g. typos in index files)
can cause problems, but I can't really fix them.  Since the index file
is so large, obviously I don't check all (or even very many) of the
entries in it.

There are some sites with rather non-helpful filenames.  For example,
the Xmosaic browser will automatically pop up a PostScript previewer
if the filename ends with .ps (or .ps.Z or the like); however, some
sites have PostScript files without that name.  Not much I can do
about that.

Anyway, give it a try.  Feel free to send constructive criticisms,
praise, or lavish gifts.

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted

I'm married, I program computers, and I'm a grad student.  If that
doesn't give me permission to look like a slob, I don't know what does.

From pandora@fernwood.mpk.ca.us  Fri May 21 01:54:48 1993
Return-Path: <pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00184; Fri, 21 May 93 01:54:48 MET DST
Received: from fernwood.mpk.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06758; Fri, 21 May 1993 02:16:00 +0200
Received: by fernwood.mpk.ca.us; id AA00985; Thu, 20 May 93 17:10:41 -0700
Newsgroups: list.www-talk,comp.infosystems.gopher,list.uri
Path: mitra
From: mitra@path.net (Mitra)
Subject: Gopher path to URL mapping?
Organization: Pandora Systems
Date: Thu, 20 May 1993 23:20:15 GMT
Message-Id: <C7CM5s.8yK@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.1 PL9]
Apparently-To: www-talk@nxoc01.cern.ch

I'm looking for a mapping from gopher paths to URL's and in particular
wonder how xMosaic, and in general WWW handles it, at first I thought
it could be done by simplistically going  

	gopher://<site>:<port>/<path>

but although this works to retrieve files and menus, it fails for the
type 7 query, this takes two forms - either with or without a search
term. 

I believe it was proposed that with a search term it should read 

	gopher://<site>:<port>/<path>?<searchterm>

but then what does a term without a query look like. 

	gopher://<site>:<port>/<path>

wont work because there is no way for a client to know that it needs to
prompt the user for a search term, or does WWW always obtain a type from
somewhere other than the URL?

- Mitra



From rik@daneel.rdt.monash.edu.au  Fri May 21 02:17:49 1993
Return-Path: <rik@daneel.rdt.monash.edu.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00422; Fri, 21 May 93 02:17:49 MET DST
Received: from daneel.rdt.monash.edu.au by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11917; Fri, 21 May 1993 02:38:58 +0200
Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
	id AA25269; Fri, 21 May 93 10:38:24 +1000
Message-Id: <9305210038.AA25269@daneel.rdt.monash.edu.au>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: New service: The Unified CS TR Index 
In-Reply-To: Your message of "20 May 93 13:21:53 EST."
             <454.737922113@moose.cs.indiana.edu> 
Date: Fri, 21 May 93 10:38:22 +1100
From: Rik Harris <rik@daneel.rdt.monash.edu.au>
X-Mts: smtp

> WHAT IT IS
> 
> It's pretty simple, really.  A daemon runs and pulls index files from
> many various FTP sites which archive tech reports (and similar
> material.)  At present, 39 FTP sites are included in the index, with
> over 1,400 reports included; both of these numbers are growing rather
> rapidly.  This information is then converted into entries for each
> tech report with hypertext anchors to the TR itself, producing a
> really big file.  This file is then searchable for keywords by a
> Simple Index Keyword Search (SIKS).  I believe it represents a
> potentially nicer general interface to this informational resources
> than existing methods (e.g. WAIS pointers to ftp sites).  It certainly
> is not the ultimate information browsing tool, but I hope it may push
> the migration towards such a little.

You might like to check out:

http://www.vifp.monash.edu.au/techreports/sitelist.html

It is the first run at converting my technical reports archive list
(posted regularly to comp.doc.techreports, news.answers, etc) to html.
It's also available as a WAIS database (cs-techreport-archives).
Ideally, I'd like to maintain it in html, and convert it to text for
posting, but I never seem to get enough time.  It contains about 140
ftp sites that I've collected that appear to archive technical
reports.

I also maintain a WAIS database of abstracts from technical reports
(cs-techreport-abstracts).  The format I use is being used now by
several sites, so they can get their data into the database very
quickly (daily automatic checks).  The rest of the abstracts I have
either formatted manually, or written a perl script to convert (where
the conversion looks like it will be useful in the future), with more
and more of a leaning towards writing scripts (who cares if I've got 40
scripts lying around, and never used again?  Besides, I'm a
Perlaholic :-).  For information on the format, see:

ftp://daneel.rdt.monash.edu.au/pub/techreports/sites/README

and on the whole project in:

ftp://daneel.rdt.monash.edu.au/pub/techreports/README

The database contains nearly 7000 reports, with over 2000 abstracts
from about 70 universities and research organisations.

My grand plan has been to have the entire database searchable,
returning a group of abstracts, with a hypertext link to the paper
itself, or if it's not available via ftp, a "mailto:" that will allow
the "contact" for that paper to be emailed a request for the paper.
This will all be done in W3, I've been converted :-)

I can see some common stuff here, so perhaps we could talk about
combining our efforts Marc (in private email, of course).

have fun,
rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au
+61 3 560-3265 (AH & ans.mach)      +61 3 565-3227 (BH)
Faculty of Computing and Information Technology,
Clayton Campus, Monash University, Australia

From sanders@bsdi.com  Fri May 21 07:39:11 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03082; Fri, 21 May 93 07:39:11 MET DST
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01373; Fri, 21 May 1993 08:00:21 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA11177; Fri, 21 May 93 01:00:18 -0500
Message-Id: <9305210600.AA11177@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: MIME content headers
Organization: Berkeley Software Design, Inc.
Date: Fri, 21 May 1993 01:00:16 -0500
From: Tony Sanders <sanders@bsdi.com>

FYI: here is what I have so for generating MIME content headers.
e.g., foo.tar.Z.uu gets:
    Content-encoding: x-uuencode; x-compress
    Content-type: archive/tar
Does this sound about right now?  Are multiple Content-encoding's allowed
(and should I use commas or semicolons for the seperator)?

#
# Case sensitive; these are from Mosaic 1.0 and TkWWW 0.8
# Unknown data gets either application/octet-stream or text/plain
#
# MIME Content-type: application audio image text video archive
#
$ext{'ai'}    = $ext{'AI'}    = 'application/postscript';
$ext{'aiff'}  = $ext{'AIFF'}  = 'audio/x-aiff';
$ext{'au'}    = $ext{'AU'}    = 'audio/basic';
$ext{'dmp'}   = $ext{'DMP'}   = 'image/x11-dump';
$ext{'cave'}  = $ext{'CAVE'}  = 'image/x-cave';
$ext{'dvi'}   = $ext{'DVI'}   = 'application/dvi';
$ext{'eps'}   = $ext{'EPS'}   = 'application/postscript';
$ext{'evlm'}  = $ext{'EVLM'}  = 'image/x-elvm';
$ext{'gif'}   = $ext{'GIF'}   = 'image/gif';
$ext{'hqx'}   = $ext{'HQX'}   = 'image/x-hqx';                  # ???
$ext{'html'}  = $ext{'HTML'}  = 'text/html';
$ext{'jpeg'}  = $ext{'JPEG'}  = 'image/jpeg';
$ext{'jpg'}   = $ext{'JPG'}   = 'image/jpeg';
$ext{'latex'} = $ext{'LATEX'} = 'application/latex';
$ext{'m'}     = $ext{'M'}     = 'text/plain';
$ext{'mime'}  = $ext{'MIME'}  = 'www/mime';
$ext{'movie'} = $ext{'MOVIE'} = 'video/x-movie';
$ext{'mpeg'}  = $ext{'MPEG'}  = 'video/mpeg';
$ext{'mpg'}   = $ext{'MPG'}   = 'video/mpeg';
$ext{'pnm'}   = $ext{'PNM'}   = 'image/portable-anymap';
$ext{'pbm'}   = $ext{'PBM'}   = 'image/portable-bitmap';
$ext{'pgm'}   = $ext{'PGM'}   = 'image/portable-graymap';
$ext{'ppm'}   = $ext{'PPM'}   = 'image/portable-pixmap';
$ext{'ps'}    = $ext{'PS'}    = 'application/postscript';
$ext{'ras'}   = $ext{'RAS'}   = 'image/cmu-raster';
$ext{'rgb'}   = $ext{'RGB'}   = 'image/x-rgb';
$ext{'rtf'}   = $ext{'RTF'}   = 'application/x-rtf';
$ext{'snd'}   = $ext{'SND'}   = 'audio/basic';
$ext{'tex'}   = $ext{'TEX'}   = 'application/tex';
$ext{'texi'}  = $ext{'TEXI'}  = 'application/texinfo';
$ext{'text'}  = $ext{'TEXT'}  = 'text/plain';
$ext{'tif'}   = $ext{'TIF'}   = 'image/x-tiff';                 # tiff???
$ext{'tiff'}  = $ext{'TIFF'}  = 'image/x-tiff';
$ext{'txt'}   = $ext{'TXT'}   = 'text/plain';
$ext{'x11'}   = $ext{'X11'}   = 'image/x11-dump';
$ext{'xbm'}   = $ext{'XBM'}   = 'image/xbitmap';                # x-bitmap???
$ext{'xwd'}   = $ext{'XWD'}   = 'image/xwindowdump';
$ext{'shar'}  = $ext{'SHAR'}  = 'archive/shar';
$ext{'tar'}   = $ext{'TAR'}   = 'archive/tar';

#
# MIME Content-encoding: x-compress x-zip x-uuencode
#
$encoding{'uu'} = $encoding{'UU'} = 'x-uuencode';
$encoding{'z'}  = 'x-zip';
$encoding{'Z'}  = 'x-compress';

    +--+
    |  |____   --------------------------------------------------------------
  __|       |  Tony Sanders                  Development and Customer Support
  \         |  sanders@BSDI.COM              Berkeley Software Design, Inc.
   \/\  * _/                                 1801 Wells Branch Parkway, #2111
      \_ /                                   Austin, TX  78728
        \|

From sanders@bsdi.com  Mon May 24 03:10:05 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06380; Mon, 24 May 93 03:10:05 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08917; Mon, 24 May 1993 03:31:23 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA16744; Sun, 23 May 93 20:31:20 -0500
Message-Id: <9305240131.AA16744@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: FYI: Plexus 2.1 is now available
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Sun, 23 May 1993 20:31:20 -0500
From: Tony Sanders <sanders@bsdi.com>

via anon ftp to www.bsdi.com:pub/Plexus-2.1.tar.Z or
http://www.bsdi.com/server/doc/Plexus.html
Demos of server features can be reached at http://www.bsdi.com/ (I keep
meaning to put links to all of them in the server docs, some are but not all).

It supports HTTP/1.0 pretty well now (I think).  I'll have to wait and
see what browsers start supporting before I add many more features in this
area.  I've updated the docs quite a bit (since the insides changed some).
I think it's a lot cleaner now plus I've fixed quite a few hidden bugs.
I moved a bunch of config options into the config file (things had crept
back into the source over time).  Right now it ignores Accept: and
Accept-Encoding: because the browsers I've seen so far don't send
this information correctly.

Here is an example 1.0 reply header from Plexus 2.1:
    HTTP/1.0 200 Document follows
    Date: Monday, 24-May-93 00:49:16 GMT
    Server: plexus/2.1
    MIME-version: 1.0
    Last-modified: Sunday, 23-May-93 20:42:02 GMT
    Content-type: text/html
Which brings up the question of Date format.  The Date format you see is
RFC850 (as specified by the current HTTP spec).  Any reason we aren't
using RFC822 as modified by RFC 1123 format that MIME specifies for it's
dates (Mon, 24 May 1993 00:49:16 +0000)?

What are you browser writers thinking about supporting wrt HTTP/1.0 request
headers (e.g., see the kerberos proposal below)?  We need to think about
how to implement the ChargeTo: and Authorization: headers in a generic
way so the browser can easily support different styles.  I would
like to see From:, User-Agent:, and Referer: being used (currently
I've only seen "Accept: text/plain" and "Authorization: user xxx").

If the browser just forked an external program with it's stdout pointing
to the network and let it send whatever headers it needed that might work
(what arguments would it need? maybe just the URL).  However, this might be
too inefficient.  I think the right way to do it is build the
browser on top of some extensible language (lisp, tcl, forth)
but that's not always an option.

I'll probably be doing another release in the near future (hopefully with
the kerberos stuff mostly done).  Here is my current proposal for the
kerberos additions, the XXX part needs work.  I haven't figured out what
unique thing to encode and send with each request to verify the client.

Ideas/comments welcome.

--sanders@bsdi.com

---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ----

Proposal for kerberosIV Authentication using HTTP/1.0

I am considering this scheme for adding kerberos authentication to
existing Web software (other ideas are welcome).  The purpose of this
proposal is to solicit input from users and browser developers about
what they would like and hopefully to agree on something so that
browser writers can implement it and everyone can start using it.

Steps that require user interaction are marked with a ``*''.

Initial browser-server interaction:

    * 1) The user requests a document that is restricted (unknown to her
	 or the browser).
      2) The browser sends the request as currently to the server.
      3) The server returns ``402 Payment Required'' with the Cost: field
	 filled in.  For now assume ``Cost: 0''.  Also, the server would
	 return an X-kerberosIV: field with it's Instance@Realm information
	 e.g., ``X-kerberosIV: web.userid@BSDI.COM''.
    * 4) The browser detects the 402 error code and intiates a dialog
	 containing the information from the Cost: field and requests
	 the password which is used to authenticate the user in the
	 servers Realm and get a ticket for the servers Instance.
      5) The browser then reissuse the request sending along a header
	 ``Authorization: kerberosIV-1/x-ticket,x-ident''.  The x-ticket
	 and x-indent specify additional headers for the server to check
	 for the kerberos information.  x-ticket: contains an ASCII
	 encoded ticket for the server; x-ident contains a short message
	 encrypted with the session key and converted to ASCII (see Note 1).
      6) Server verifies client information and sends the requested document.
         The Content-encoding: field would be used to specify the document
         encoding (if any).  X-kerberosIV-safe for authenticated documents or
         X-kerberosIV-private for encrypted documents.

Secondary browser-server interaction:

    * 7) The user requests a restricted document 
      8) browser detects server and sends cached authentication information
      9) server returns document, unless cached information is invalid then
         go back to step 3.

Note 1: This is to prevent message replay.
    XXX: What should go in this message?  Needs to be unique for each request,
    XXX: and encrypted with the session id.

Thanks to Nick Williams for hashing out this idea in email with me.

From m.koster@nexor.co.uk  Mon May 24 10:09:44 1993
Return-Path: <m.koster@nexor.co.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09646; Mon, 24 May 93 10:09:44 MET DST
Received: from lancaster.nexor.co.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08784; Mon, 24 May 1993 10:31:02 +0200
Message-Id: <9305240831.AA08784@dxmint.cern.ch>
Received: from nexor.co.uk (actually vulcan.nexor.co.uk) 
          by lancaster.nexor.co.uk with SMTP (PP);
          Mon, 24 May 1993 09:30:52 +0100
To: www-announce@nxoc01.cern.ch, www-talk@nxoc01.cern.ch, m.koster@nexor.co.uk
Subject: UPDATE: Warchie
Date: Mon, 24 May 1993 09:30:47 +0100
From: Martijn Koster <m.koster@nexor.co.uk>


Version 1.2 of Warchie, a World Wide Web to Archie gateway,
has been installed and tested on the NeXor Server:

    http://web.nexor.co.uk/welcome.html

This new version has an option of sorting the archie results by
date, and has matured from a single file program into a full
distribution. It has been running happily over the last couple
of weeks, and I've had no complaints (then again, I've had no
comments at all :-)

What I'm looking for is people to run it near CERN and in the
States (or anywhere else!): that would reduce network bandwidth
and improve performance... anybody want to give it a try?
For details see http://web.nexor.co.uk/warchie/setup.html

Incidentally, does anybody know where in the web a URL

	http://web.nexor.co.uk:1993/archie HTTP/1.0 <-- NO!

appears? I keeps popping up in my logs, but it is invalid in the
context of Warchie... If you want a link to a Warchie server use
one listed in

	http://web.nexor.co.uk/warchie/servers.html

Any comments/suggestions are more than appreciated.

-- Martijn


Disclaimer: I do not speak for my company, only for myself.
See also: http://web.nexor.co.uk/disclaimer.html

__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A=Mark400; 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

From ccprl@xdm001.ccc.cranfield.ac.uk  Mon May 24 11:54:08 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10834; Mon, 24 May 93 11:54:08 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00781; Mon, 24 May 1993 12:15:22 +0200
Received: by xdm001 
	id AA24509; Mon, 24 May 93 11:14:49 +0100
Received: by xdm039 (5.57/4.7) id AA03202; Mon, 24 May 93 11:14:42 +0100
Message-Id: <9305241014.AA03202@xdm039>
To: sanders@bsdi.com, www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: FYI: Plexus 2.1 is now available 
In-Reply-To: Your message of "Mon, 24 May 93 10:00:51 BST."
             <9305240900.AA23134@xdm001> 
Date: Mon, 24 May 93 11:14:40 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

>     * 4) The browser detects the 402 error code and intiates a dialog
>	 containing the information from the Cost: field and requests
>	 the password which is used to authenticate the user in the
> 	 servers Realm and get a ticket for the servers Instance.

A yes/no confirmation dialog is useful if there is a real cost, but the
browser should never see the password.

1) Kerberos should normally be invisible to users; there should be a
TGT whenever the user is logged in.
2) AFS kerberos uses a different password->key mapping, so you'd have a
problem with AFS sites. (Problem #1; how do you tell apart sites using
AFS Kerberos? We use AFS with MIT Kerberos).
3) It's bad policy for users to get into the habit of entering their
passwords into programs other than passwd, kinit and login.

we'd be happy to try a Kerberised client and server, as authenticated
info serving is something of a wish here.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From ccprl@xdm001.ccc.cranfield.ac.uk  Mon May 24 12:32:09 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11264; Mon, 24 May 93 12:32:09 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09731; Mon, 24 May 1993 12:53:27 +0200
Received: by xdm001 
	id AA25179; Mon, 24 May 93 11:53:20 +0100
Received: by xdm039 (5.57/4.7) id AA03553; Mon, 24 May 93 11:53:15 +0100
Message-Id: <9305241053.AA03553@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: DECwrite -> HTML PERL script
Reply-To: p.lister@cranfield.ac.uk
Date: Mon, 24 May 93 11:53:12 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

I have written a crude but effective script which takes SGML output
from DECwrite and groks it into HTML. It's a first pass, and not
comprehensive, but it has got a few existing DECwrite docs into WWW OK.

The easy stuff is just direct translation, but because DECwrite handles
nested lists different to HTML, there's a lot of code devoted to them.
I've also got it to put footnotes at the bottom of the page, and
rebuild a table of contents. DECwrite SGML, would you believe, outputs
the page refs in a TOC as the actual page numbers as per A4 paper. :-(

The script is at http://www.cranfield.ac.uk/test/decw2html

If any DECwriters out there try it, do let me know. Ta.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From m.koster@nexor.co.uk  Mon May 24 14:31:22 1993
Return-Path: <m.koster@nexor.co.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12956; Mon, 24 May 93 14:31:22 MET DST
Received: from lancaster.nexor.co.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02674; Mon, 24 May 1993 14:52:38 +0200
Message-Id: <9305241252.AA02674@dxmint.cern.ch>
Received: from nexor.co.uk (actually vulcan.nexor.co.uk) 
          by lancaster.nexor.co.uk with SMTP (PP);
          Mon, 24 May 1993 13:51:56 +0100
To: Martijn Koster <m.koster@nexor.co.uk>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: UPDATE: Warchie
In-Reply-To: Your message of "Mon, 24 May 1993 09:30:47 BST."
Date: Mon, 24 May 1993 13:51:49 +0100
From: Martijn Koster <m.koster@nexor.co.uk>


Earlier today I wrote:

> Incidentally, does anybody know where in the web a URL
> 
> 	http://web.nexor.co.uk:1993/archie HTTP/1.0 <-- NO!
> 
> appears? I keeps popping up in my logs, but it is invalid in the
> context of Warchie... 

Nick Williams pointed out to me that the "HTTP/1.0" bit that causes
Warchie to treat it as an invalid URL is in fact valid HTTP.
So it probably isn't in a document but in a browser somewhere.
Anyway, I had a look the various specs and changed Warchie so it
ignores further words after the URL.
Thanks Nick!

-- Martijn

Disclaimer: I do not speak for my company, only for myself.
See also: http://web.nexor.co.uk/disclaimer.html
----------
Internet: m.koster@nexor.co.uk
X-400: C=GB; A=Mark400; 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

From sanders@bsdi.com  Mon May 24 17:00:54 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15975; Mon, 24 May 93 17:00:54 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07485; Mon, 24 May 1993 17:22:06 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA17895; Mon, 24 May 93 10:22:03 -0500
Message-Id: <9305241522.AA17895@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: FYI: Plexus 2.1 is now available 
In-Reply-To: Your message of Mon, 24 May 93 11:14:40 BST.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 24 May 1993 10:22:02 -0500
From: Tony Sanders <sanders@bsdi.com>

> >     * 4) The browser detects the 402 error code and intiates a dialog
> >	 containing the information from the Cost: field and requests
> >	 the password which is used to authenticate the user in the
> > 	 servers Realm and get a ticket for the servers Instance.
> 
> A yes/no confirmation dialog is useful if there is a real cost, but the
> browser should never see the password.
> 
> 1) Kerberos should normally be invisible to users; there should be a
> TGT whenever the user is logged in.
Yes, for a single realm.  The problem is that with the Web you are reading
documents from all over (many possible realms).  Are you going to require
that the user kinit in a shell window for each document at a different
site (possibly having to exit the browser each time for line-mode browsers
with no job control)?

> 2) AFS kerberos uses a different password->key mapping, so you'd have a
> problem with AFS sites. (Problem #1; how do you tell apart sites using
> AFS Kerberos? We use AFS with MIT Kerberos).
It would have to be a different protocol  I chose kerberosIV-1 as the name
of this protocol, another might be kerberosAFS-1, there would also be
kerberosV-1 and maybe even kerberosIV-2.

> 3) It's bad policy for users to get into the habit of entering their
> passwords into programs other than passwd, kinit and login.
I cannot think of any other reasonable solution with the current
technology (and I'm not interested in rolling my own).

> we'd be happy to try a Kerberised client and server, as authenticated
> info serving is something of a wish here.
great

--sanders

From ccprl@xdm001.ccc.cranfield.ac.uk  Mon May 24 18:52:04 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17957; Mon, 24 May 93 18:52:04 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26140; Mon, 24 May 1993 19:13:21 +0200
Received: by xdm001 
	id AA10465; Mon, 24 May 93 18:13:15 +0100
Received: by xdm039 (5.57/4.7) id AA05975; Mon, 24 May 93 18:12:15 +0100
Message-Id: <9305241712.AA05975@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: FYI: Plexus 2.1 is now available 
In-Reply-To: Your message of "Mon, 24 May 93 17:03:20 BST."
             <9305241603.AA02755@xdm001> 
Date: Mon, 24 May 93 18:12:14 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> Yes, for a single realm.  The problem is that with the Web you are reading
> documents from all over (many possible realms).  Are you going to require
> that the user kinit in a shell window for each document at a different
> site (possibly having to exit the browser each time for line-mode browsers
> with no job control)?

I'm not "requiring" it, Kerberos is. How many Kerberos realms you are
known to? I'm known to only 2 (possibly 3). Cross realm authentication
doesn't work yet. I may indeed look at lots of docs at lots of sites
around the net, but I am not known to most of the Kerberi in the world,
and I am certainly not in any way privileged elsewhere in the world.
The reason I (and I suspect most people in the world) want
authenticated WWW is so that privileged folk at a site can read
confidential docs and lock the rest of the world out. When proper
cross-realm authentication is in widespread use, no-one will have to
enter passwords to get a foreign ticket anyway.

As to job control, line mode browsers start telnet happily enough, so
they can run kinit the same way.

> It would have to be a different protocol  I chose kerberosIV-1 as the name
> of this protocol, another might be kerberosAFS-1, there would also be
> kerberosV-1 and maybe even kerberosIV-2.

But it's NOT a different protocol!! AFS Kerberos is the same procotol
as MIT Kerberos. The only difference is in clients which translate
passwords to keys - kinit, kpasswd and login. It just confuses matters
to treat them differently. The easiest solution is a Kerberos client
which understands both, which is invisible to HTTP.

> I cannot think of any other reasonable solution with the current
> technology (and I'm not interested in rolling my own).

Neither can I. However, I'm trying to be realistic; after 3 years of
looking after a Kerberos authenticated system, I think I know it fairly
well. I don't think you can get round this problem. Any "roll your own"
solution is useless unless everyone ELSE has it!

I'd guess that browser writers don't want to put Kerberos functionality
into their software - far easier to just run kinit/klog or the local
X11 ticket manager/password changer. Tyro users see the interface that
they're used to, rather than a line mode "dialog box".

Kerberos functionality in plexus is great, but won't be used unless
there are Kerberos aware browsers, so let's not make life difficult for
browser writers by insisting they re-invent wheels. I'd prefer them to
devote their talents to making the Web look nicer.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From raisch@ora.com  Mon May 24 19:32:45 1993
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18770; Mon, 24 May 93 19:32:45 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02251; Mon, 24 May 1993 19:53:54 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA16463; Mon, 24 May 1993 13:52:48 -0400
Date: Mon, 24 May 1993 12:40:56 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Re: FYI: Plexus 2.1 is now available 
To: Tony Sanders <sanders@bsdi.com>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305241522.AA17895@austin.BSDI.COM>
Message-Id: <Pine.3.03.9305241254.E29106-c100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Mon, 24 May 1993, Tony Sanders wrote:

> > 1) Kerberos should normally be invisible to users; there should be a
> > TGT whenever the user is logged in.
> Yes, for a single realm.  The problem is that with the Web you are reading
> documents from all over (many possible realms).  Are you going to require
> that the user kinit in a shell window for each document at a different
> site (possibly having to exit the browser each time for line-mode browsers
> with no job control)?

	Well, this is the problem.  The solution is not to use something like
Kerberos to authenticate a user to a publisher, since Kerberos does not scale to
the level we are going to need on the Global Internet.

	The easy solution is to support the idea of "authentication servers"
where the user is a member or subscriber to an authentication server which is
responsible to identify the particular user to potential publishers.  The
publisher is a subscriber to the same or a different authentication server (and
in this case, we assume that the authentication servers have a trusted method to
share the burden.)

	Let me try a real world example:

	aUser subscribes to AuthenticationServer-A.		
			(happens only once)

	aUser authenticates herself to AuthenticationServer-A via Kerberos.
			(happens once per session)

	aUser is now ready to receive documents.
	-----------------------------------------------------
	aPublisher subscribes to AuthenticationServer-B.
			(happens only once)

	aPublisher authenticates itself to AuthenticationServer-B.
			(happens when publisher reboots)

	aPublisher is now ready for business.
	-----------------------------------------------------
	aUser wishes to retrieve aDocument from aPublisher

	aUser requests aDocument from aPublisher
		-- Along with the request goes something along the lines of:
			AuthAgency	AuthMethod	UserCredentials
			----------	----------	---------------
			Server-A	Kerberos        [HOSTNAME] 
							[USERNAME] 
							[KERB-TICKET]  (opaque data)

			a URA (Uniform Resource Authenticator) might look like:
			Kerberos://Server-A/hostname/username/kerb-ticket

	aPublisher checks with AuthenticationServer-B for aUser's credentials

	AuthenticationServer-B does not recognize aUser

	AuthenticationServer-B contacts AuthenticationServer-A and requests
	credentials for aUser

	AuthenticationServer-A returns the proper credentials and...

	well, you get the picture....


	The idea here is that Kerberos by itself is not an authentication
service.  It is a mechanism which can be used to develop such a service.

	I would assume that all the AuthenticationServers might use Kerberos to
share info between them, and that all the Users might use Kerberos to
authenticate themselves to the AuthenticationServers.  Of course, there is room
for more and less robust mechanisms as well, depending on the publisher's needs.

	There needs to be a major infrastructure of authenticating and authorizing
capabilities on the Internet to support "publishing."  It is not simply a
question of client/server (consumer/producer) because the model does not scale.

> > 3) It's bad policy for users to get into the habit of entering their
> > passwords into programs other than passwd, kinit and login.
> I cannot think of any other reasonable solution with the current
> technology (and I'm not interested in rolling my own).

	Ahhhh... but I am.  <smile>  O'Reilly is hoping to take a lead here, and
we are actively developing an document which outlines the problems and proposes
a solution.  We are also developing a testbed application, and will ultimately
make this available to other publishers and the network at large.

	Anyone interested in particpating, (at this point, in a discussion, but
perhaps in the beta-release), should drop me a line.

	</rr>



From sanders@bsdi.com  Mon May 24 20:34:16 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19899; Mon, 24 May 93 20:34:16 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09486; Mon, 24 May 1993 20:55:33 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA18522; Mon, 24 May 93 13:55:31 -0500
Message-Id: <9305241855.AA18522@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Kerberos authentication for HTTP/1.0
In-Reply-To: Peter Lister's message of Mon, 24 May 93 18:12:14 BST.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 24 May 1993 13:55:30 -0500
From: Tony Sanders <sanders@bsdi.com>

> As to job control, line mode browsers start telnet happily enough, so
> they can run kinit the same way.
This is fine, I only said the browser should detect failure due to Payment
Required (code 402) and initiate a dialog that requests the password, I
didn't say you couldn't exec kinit to do the work.  I just don't want the
user to have to type in the kinit request by hand each time he changes
realms (even if only once, the browser and its helpers are free to deal
with this however is best, including caching TGT's for different realms).
If a user is already kinit'ed to the required realm the browser should
not have to do anything, again it's up to the browser and its helpers
to do the right thing.  You also need a way to generate the additional
headers on each request using some external program (because you can't
keep sending the same headers and avoid replay).

It is up to the browser writers to do this in a generic way so they can
support multiple authentication schemes.  It would probably help if the
server returned a header like Accept-Authentication: with a list of the
authentication protocols it accepts.  Tim BL, do you want to address this
in the HTTP spec?

Another way to attack the problem is just inject the raw authentication
protocol in the stream at some point (hand off the socket to an
external program and let it do all the work).  Tim: is this allowed?  What
do you think about it?  I don't think it would break anything since it
would only happen if both the client and server agreed on the
Authentication: protocol.  Comments?

I hope to do some prototyping at some point in the next few weeks.

FYI: the problem I'm trying to solve is not so much local access to
documents (you could simply check IP address for that and get most of what
you need) but rather the purchasing of books and other services over the
Internet.

--sanders

From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 25 10:37:45 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29871; Tue, 25 May 93 10:37:45 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09914; Tue, 25 May 1993 10:59:06 +0200
Received: by xdm001 
	id AA05842; Tue, 25 May 93 09:58:59 +0100
Received: by xdm039 (5.57/4.7) id AA10944; Tue, 25 May 93 09:58:55 +0100
Message-Id: <9305250858.AA10944@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Authentication of published docs
In-Reply-To: Your message of "Mon, 24 May 93 19:17:48 BST."
             <9305241817.AA13007@xdm001> 
Date: Tue, 25 May 93 09:58:54 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> There needs to be a major infrastructure of authenticating and authorizing
> capabilities on the Internet to support "publishing."  It is not simply a
> question of client/server (consumer/producer) because the model does not scale.

Well put. At Cranfield we are interested in the first instance in
restricting a small area of our web to privileged local users only;
simple Kerberos 4 will do that fine. In the future, however, we
definitely want electronic subscription to journals etc, which requires
widespread the authentication described. However.....

> The idea here is that Kerberos by itself is not an authentication
> service.  It is a mechanism which can be used to develop such a service.

No. What you just described was (effectively) cross-realm
authentication, and the authentication in your example *did* happen via Kerberos!!

ServerB has to contact serverA, and ask it for credentials for aUser.
ServerB can only trust those credentials if the servers trust each
other (or at least B trusts A), so each must hold a key for the other's
TGT service. This requires that their administrators communicate the
keys out-of-band (just like a new user being verbally told their inital password).

It's impractical for every Kerberos server to exchange tickets with
every other, so there needs to be a hierarchy, just like the domain
name scheme (especially since kerberos realms are conventionally
domains name UPPERCASED) - so, if want to authenticate to ORA, I do so
by a multi-hop authentication - cranfield shares keys with a UK auth
server, which shares keys with a US auth server, which shares keys with
ORA. As a detail, the actual servers themselves don't actually talk;
like DNS, each passes a reference and a ticket back to the client,
which then talks to the next server in the chain.

Cross-realm authentication is well understood, and is not limited to
electronic publishing. However, I think the lack of an application
which needs cross-realm authentication has limited it's use and not
justified large-scale organisation. Hopefully, WWW is that app. If they
aren't doing so, I implore ORA not to re-invent this particular Kerberos wheel.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 25 10:52:45 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00176; Tue, 25 May 93 10:52:45 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12339; Tue, 25 May 1993 11:14:06 +0200
Received: by xdm001 
	id AA06196; Tue, 25 May 93 10:13:55 +0100
Received: by xdm039 (5.57/4.7) id AA10959; Tue, 25 May 93 10:13:50 +0100
Message-Id: <9305250913.AA10959@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: Kerberos authentication for HTTP/1.0 
In-Reply-To: Your message of "Mon, 24 May 93 20:13:42 BST."
             <9305241913.AA14966@xdm001> 
Date: Tue, 25 May 93 10:13:48 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> This is fine, I only said the browser should detect failure due to Payment
> Required (code 402) and initiate a dialog that requests the password, I
> didn't say you couldn't exec kinit to do the work.  I just don't want the

OK, fair enough. But you didn't say I could, and I'm usually right to
assume (omission in description) -> (lack of function) (e.g. when
reading vendorhype).

> FYI: the problem I'm trying to solve is not so much local access to
> documents (you could simply check IP address for that and get most of what
> you need) but rather the purchasing of books and other services over the
> Internet.

I appreciate that you're interested in publishing. So am I, but I have
a more immediate requirement which ordinary Kerberos will satisfy. I
want to restrict certain document to certain INDIVIDUALS, but allow
those individuals to use ANY workstation (even at a remote site). IP
address filtering won't do that. I don't want simple Kerberos
functionality to be delayed for months while the rest of the community
argues about the finer point of widespread publication.

If this sounds really negative, it's not meant to be. I loudly applaud
the efforts of the folk who are doing this! :-)   :-0 :-0 :-0 (3 cheers)

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From ccprl@xdm001.ccc.cranfield.ac.uk  Tue May 25 15:13:30 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03740; Tue, 25 May 93 15:13:30 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26083; Tue, 25 May 1993 15:34:50 +0200
Received: by xdm001 
	id AA14969; Tue, 25 May 93 14:34:46 +0100
Received: by xdm039 (5.57/4.7) id AA12736; Tue, 25 May 93 14:34:42 +0100
Message-Id: <9305251334.AA12736@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Poetry and Maths
Reply-To: p.lister@cranfield.ac.uk
Date: Tue, 25 May 93 14:34:40 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

Much opinion seems to be that line and page breaks are against the
spirit of HTML. I disagree, as I think there are cases where some
information of this sort is vital to a document.

It came to me last night that the obvious example is poetry. To quote a
poem in an HTML document, how does the WWW suggest that HTML should get
the line breaks in the right place? <p> is suitable between verses, but
between lines. I really don't see that adding <newline> will cause
problems. Similarly, I think that page breaks between poems are
entirely suitable; all the anthologies I possess are one (maximum 2)
poems per page, and there's alot of whitespace.

BTW, would it make a difference using &NEWLINE; and &NEWPAGE; elements
instead of tags? I can't comment on the pros and cons, but I note that
e.g. DECwrite SGML uses elements, not tags.

Sigh. Here come the flames. :-)

This brought me on to mathematical expressions. There is real
requirement for these in technical documents, and at the moment all I
can do is include a bitmapped image screen dump in a document, or link
a dvi document containing a compiled TeX expression and hope that the
browsing end has xdvi. Not good when the TeX source is circa twenty
bytes. What's the general opinion?

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From marca@wintermute.ncsa.uiuc.edu  Tue May 25 15:32:35 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04129; Tue, 25 May 93 15:32:35 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00805; Tue, 25 May 1993 15:53:53 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12934
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 25 May 93 08:53:29 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:ccprl@xdm001.ccc.cranfield.ac.uk id AA25709; Tue, 25 May 93 08:55:55 -0500
Date: Tue, 25 May 93 08:55:55 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305251355.AA25709@wintermute.ncsa.uiuc.edu>
To: p.lister@cranfield.ac.uk
Cc: ccprl@xdm001.ccc.cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: Poetry and Maths
In-Reply-To: <9305251334.AA12736@xdm039>
References: <9305251334.AA12736@xdm039>
X-Md4-Signature: 7c1d6d8f982e7f780782aa032a47c595

"Peter Lister, Cranfield Computer Centre" writes:
> This brought me on to mathematical expressions. There is real
> requirement for these in technical documents, and at the moment all I
> can do is include a bitmapped image screen dump in a document, or link
> a dvi document containing a compiled TeX expression and hope that the
> browsing end has xdvi. Not good when the TeX source is circa twenty
> bytes. What's the general opinion?

The general opinion, I think, is that TeX's syntax should be used.
That equates to a LOT of work.  Anyone feeling particularly wealthy
today?

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From fine@cis.ohio-state.edu  Tue May 25 16:25:30 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05231; Tue, 25 May 93 16:25:30 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09478; Tue, 25 May 1993 16:46:51 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA12339; Tue, 25 May 93 10:46:38 -0400
Date: Tue, 25 May 93 10:46:38 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305251446.AA12339@soccer.cis.ohio-state.edu>
To: p.lister@cranfield.ac.uk, www-talk@nxoc01.cern.ch
Subject: More than just HTML (was Re: Poetry and Maths)
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
X-Mailer: Perl Mail System v1.2


There's been lot's of discussion of late about all the wonderful
things we can put in HTML, to make it do this, or that, or the other
wonderful feature.  To format or not to format.  Include images.
Include tables.  Include widgets.  Sound, movies, sensaround, free
food, etc.

I really think we're going the wrong way here.  HTML was always meant
to be a small, even minimal document type.  The promised strong point
of the web would be multiple document types, all tied together within
a structure of HTML documents.

HTML only provides the framework by which lots of other document types
are accessed.  You want to do lot's of neat TeX things?  Use TeX.  You
want to do something with integrated text and graphics?  Use Postscript.
You want to define a single document as a collection of different
things?  MIME does this for you.  On the other hand, if we make it a
de facto requirement that everything available thru the web must be
HTML, I think we limiting ourselves severely (and being somewhat
egotistical).

MIME is supposed to be where all of our work is going right now.  By
developing a good MIME document viewer, and a good transport mechanism,
we can do all this (and come up with interface to read MIME mail and news
while we're at it).  And we set up a system which can be easily extended
to document types that haven't even been designed yet.

Last, let me make another pitch for HTPS.  HyperText PostScript.  HTML
provides the structure, and other document types provide the data.  But
sometimes it'd be nice to have the structure and the data all together.
It would be trivial to add an operator to postscript which defines anchors
as arbitrary paths associated with URLs.  That should satisfy most anyone's
desire for arbitrarily composed documents.  If anyone is interested in
implementing this, contact me, I have some good ideas.

         tom

From nholtz@civeng.carleton.ca  Tue May 25 16:59:39 1993
Return-Path: <nholtz@civeng.carleton.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06140; Tue, 25 May 93 16:59:39 MET DST
Received: from alfred.ccs.carleton.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16502; Tue, 25 May 1993 17:20:58 +0200
Received: from zonker.cascade.carleton.ca by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA03529; Tue, 25 May 93 11:21:07 EDT
Received: by zonker.cascade.carleton.ca (5.61/5.17)
	id AA06301; Tue, 25 May 93 11:15:49 -0400
From: nholtz@civeng.carleton.ca (Neal Holtz)
Message-Id: <9305251515.AA06301@zonker.cascade.carleton.ca>
Subject: Re: Poetry and Maths
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Tue, 25 May 93 11:15:47 EDT
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305251355.AA25709@wintermute.ncsa.uiuc.edu>; from "Marc Andreessen" at May 25, 93 8:55 am
X-Mailer: ELM [version 2.3 PL11]

Marc Andreessen writes:
> 
> "Peter Lister, Cranfield Computer Centre" writes:
> > This brought me on to mathematical expressions. There is real
> > requirement for these in technical documents, and at the moment all I
> > can do is include a bitmapped image screen dump in a document, or link
> > a dvi document containing a compiled TeX expression and hope that the
> > browsing end has xdvi. Not good when the TeX source is circa twenty
> > bytes. What's the general opinion?
> 
> The general opinion, I think, is that TeX's syntax should be used.
> That equates to a LOT of work.  Anyone feeling particularly wealthy
> today?

Not that this will be trivial, but I was wondering about the possibilities
of a \TeX{} ``server'' -- a hacked up version of TeX that would accept
a few bytes and hand you back a DVI fragment.  THere is a lot of code
around for rendering that to a bitmap.  I haven't looked at the TeX source,
but it can't be a huge job (:-).  There are of course lots of questions,
such as what kind of TeX environment to assume, how much of the DVI file
actually has to be sent, etc.  

The biggest question is -- will the performance be adequate? TeX is a bit
sluggish to get going, particularly, I suspect, if started from inetd for
each twenty byte formula.

I am very interested in this because of the potential use of HTML browsers
for building codes and structural design standards.  These documents
typically have a lot of mathematical expressions -- a typical clause
is 1/2 page long and contains a formula of some sort.

I also want the formula to be ``active'', i.e. usable in a calculator-like
fashion.  For ideas on what this might look like, see MathCAD for Windows.
I have a Master's student now looking at it -- over the next month or two
we hope to float some proposals around.  I would be pleased to hear from
anyone that has doen some similar thinking.  I might be able to supply
a bit more detailed abstract in a week or two, if anyone is interested
in more details of the proposal.  I have been toying with these ideas
for ten years or so, so I have a fair understanding about whats required
on the computation side.


-- 
Prof. Neal Holtz,  Dept. of Civil Eng.,  Carleton University,  Ottawa,  Canada
Internet: nholtz@civeng.carleton.ca  Ph: (613)788-2600x5797 Fax: (613)788-3951

From nholtz@civeng.carleton.ca  Tue May 25 17:15:31 1993
Return-Path: <nholtz@civeng.carleton.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06527; Tue, 25 May 93 17:15:31 MET DST
Received: from alfred.ccs.carleton.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19928; Tue, 25 May 1993 17:36:52 +0200
Received: from zonker.cascade.carleton.ca by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA04426; Tue, 25 May 93 11:36:17 EDT
Received: by zonker.cascade.carleton.ca (5.61/5.17)
	id AA06319; Tue, 25 May 93 11:30:59 -0400
From: nholtz@civeng.carleton.ca (Neal Holtz)
Message-Id: <9305251530.AA06319@zonker.cascade.carleton.ca>
Subject: Re: More than just HTML (was Re: Poetry and Maths)
To: fine@cis.ohio-state.edu (Thomas A. Fine)
Date: Tue, 25 May 93 11:30:56 EDT
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305251446.AA12339@soccer.cis.ohio-state.edu>; from "Thomas A. Fine" at May 25, 93 10:46 am
X-Mailer: ELM [version 2.3 PL11]

Thomas A. Fine writes:
>
> I really think we're going the wrong way here.  HTML was always meant
> to be a small, even minimal document type.  The promised strong point
> of the web would be multiple document types, all tied together within
> a structure of HTML documents.
>
There is certainly a danger of a very good idea becoming bloated with
too many things.  On the other hand, as one example ...
 
> HTML only provides the framework by which lots of other document types
> are accessed.  You want to do lot's of neat TeX things?  Use TeX. 

The kind of documents I am most interested in are about 50\% math
and 50\% text with {\em lots} of cross-references.  It is important
that the math appear in-line with the document.  A typical unit (node)
is 1/2 page.  I worry about performance if, for example, the math
portion is farmed out to TeX/xdvi for rendering, and I wonder whether
an acceptable cacheing scheme can be found (perhaps it can).

I was attracted to HTML for this purpose because of the nice tools
that are now available, in contrast to other mechanisms.

-- 
Prof. Neal Holtz,  Dept. of Civil Eng.,  Carleton University,  Ottawa,  Canada
Internet: nholtz@civeng.carleton.ca  Ph: (613)788-2600x5797 Fax: (613)788-3951

From marca@wintermute.ncsa.uiuc.edu  Tue May 25 17:28:25 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06800; Tue, 25 May 93 17:28:25 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20823; Tue, 25 May 1993 17:49:47 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23764
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 25 May 93 10:48:23 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:fine@cis.ohio-state.edu id AA26090; Tue, 25 May 93 10:50:52 -0500
Date: Tue, 25 May 93 10:50:52 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305251550.AA26090@wintermute.ncsa.uiuc.edu>
To: nholtz@civeng.carleton.ca (Neal Holtz)
Cc: fine@cis.ohio-state.edu (Thomas A. Fine), www-talk@nxoc01.cern.ch
Subject: Re: More than just HTML (was Re: Poetry and Maths)
In-Reply-To: <9305251530.AA06319@zonker.cascade.carleton.ca>
References: <9305251446.AA12339@soccer.cis.ohio-state.edu>
	<9305251530.AA06319@zonker.cascade.carleton.ca>
X-Md4-Signature: 745850d21d48255deeddd36ee9b73d4e

If we could actually come up with something that blends TeX with HTML
it would win us a *lot* of users who are ready to switch _today_ in
order to get the advantages of online hypermedia.  Unfortunately, I
think the complexity plus the corresponding workload involved in
creating and supporting tools to actually use such a format are
prohibitive in the near term.  (What's my point?  I'm not sure I have
one...)

Marc


From dsr@hplb.hpl.hp.com  Tue May 25 18:37:30 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08236; Tue, 25 May 93 18:37:30 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04554; Tue, 25 May 1993 18:58:50 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 25 May 93 17:51:37 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA13601; Tue, 25 May 93 17:59:51 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305251659.AA13601@manuel.hpl.hp.com>
Subject: Re HMML?
To: wei@xcf.berkeley.edu
Date: Tue, 25 May 93 17:59:49 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Pei,

> Say, how is it going with HTML2/HMML DTD? Are you building on top of
> HMML or HTML DTD? In a few days Im getting back to HMML DTD thing again,
> so Im interested in your progress on the DTD.

Thanks for your interest, and for sending me your DTD. I really like the
change to the container model, and other SGML experts have told me that as a
rule, it is much better for verification purposes. A separate advantage is
that it allows you to make link destinations pick out a much wider variety of
containers than the <A NAME=foo> element, which is restricted to text and
inline emphasis.

My main objective is backwards compatibility with existing HTML. The change
to the container model shouldn't effect such documents. Another objective is
to provide support for groupings of HTML documents that form on-line books,
magazines, journals and conference proceedings etc. The idea here is to
provide presentation independent markup as a basis for:

    o   indexing based upon markup (title/author/subject, topics, ...)
    o   familiar navigation model (tables of contents, indexes, ...)
    o   printing related information (not just the current document)
    o   importing books, etc into the web

These extensions must be compatible with being able to parse HTML+ efficiently
using modest programs (unlike HyTime!). I am currently analysing a wide range
of paper material to see whether these documents can be adequately described
using just a few new tags.

Some things are clearly too arbitary, and would need to be described as
embedded figures using another format, e.g. Postscript or Computer Graphics
Metafile.

Other extensions to HTML add:

    o   tables (as an extension to definition lists)
    o   embedded images/drawings (Mosaic's <IMG> tag + ISMAP)
    o   forms (input fields and selection menus)
    o   nested lists
    o   change bars
    o   floating panels
    o   a few new semantic tags for indexing purposes

It would also be great to add support for annotations of various kinds, with
forward references from documents to responses etc. Further work is needed to
clarify the implications for the markup language. Anyone like to take this on?

You can see the current state of the DTD in:

    ftp://15.254.100.100/pub/hmml.dtd

Please remember that it is still at an early stage of development, so don't
expect too much consistency or completeness right now. Comments are welcome.

I appologise to those people who couldn't get access to hplose.hpl.hp.com
and have asked our support people to get it registered with the name server.

Let me know if you still can't access this file.

If we can get this right, the opportunity is there to make the Web as common
place as FTP is now. What will the effects (and problems) be when there are
millions of servers?

Best wishes,

    Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From mvanheyn@cs.indiana.edu  Tue May 25 19:05:19 1993
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08649; Tue, 25 May 93 19:05:19 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08345; Tue, 25 May 1993 19:26:41 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA10470; Tue, 25 May 1993 12:26:39 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch, feednews@news.cs.indiana.edu
Newsgroups: comp.infosystems.www
Subject: Re: FYI: Plexus 2.1 is now available 
In-Reply-To: Your message of "Mon, 24 May 1993 12:40:56 -0400."
             <Pine.3.03.9305241254.E29106-c100000@ruby.ora.com> 
Date: Tue, 25 May 1993 12:26:38 -0500
Message-Id: <10467.738350798@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Rob Raisch
>> > 1) Kerberos should normally be invisible to users; there should be a
>> > TGT whenever the user is logged in.
>> Yes, for a single realm.  The problem is that with the Web you are reading
>> documents from all over (many possible realms).  Are you going to require
>> that the user kinit in a shell window for each document at a different
>> site (possibly having to exit the browser each time for line-mode browsers
>> with no job control)?
>
>	Well, this is the problem.  The solution is not to use something like
>Kerberos to authenticate a user to a publisher, since Kerberos does not scale 
>to
>the level we are going to need on the Global Internet.
>
> [much more stuff by many people about kerberos deleted]

The biggest problem I have with scaling kerberos to this level is the
amount to which trust also must be scaled.  A high-level
authentication server which is responsible for providing
authentication for a lot of other servers would be responsible for a
lot of commercial traffic, and thus it's not difficult to imagine
circumstances in which it would be worth a very large amount of money
to compromise it.  What agency/organization do you trust to be so free
of possible corruption and security breaches to guard these high-level
authentication servers that could govern hundreds of millions of
dollars in commercial traffic?

Someone correct me if I'm wrong, but I don't believe kerberos allows
for non-deniability of orgin, which is exactly what is needed for this
kind of an application (i.e. publisher A needs to prove that request I
must have been sent from user B, and could not have been forged by
publisher A, even with the cooperation of authentication authority Q.
Otherwise they can do the electronic equivalent to forging your
signature on credit-card slips, and there's no way to prove whether
user B or publisher A is lying when they disclaim wrongdoing.)

For this kind of thing, I still think PEM is the way to go, as it will
be made interoperable with MIME (which HTTP already uses, a nontrivial
win) quite soon.  (Unless, of course, things like electronic cash
actually start being available and used.)  The only serious question
is whether the better stopgap is to use kerberos for the time being or
to use symmetric-key PEM until asymmetric becomes useful (which may
not be until the patents run out in a few years, sigh.)

(By the way, this is also going to the newsgroup.  I generally am
hesitant to post to the mailing list because I'm really sick of bounce
messages.)

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted

The cultural elite are neither!
(Or at least they're certainly not the latter.)

From marca@wintermute.ncsa.uiuc.edu  Wed May 26 03:53:35 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17545; Wed, 26 May 93 03:53:35 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09119; Wed, 26 May 1993 04:14:58 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02807
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 25 May 93 21:14:56 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA02085; Tue, 25 May 93 21:17:30 -0500
Date: Tue, 25 May 93 21:17:30 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305260217.AA02085@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Vatican library interface
X-Md4-Signature: 4537602bc411298fc7c723dfe588a369

An updated version of a hypermedia interface to the Library of
Congress's Vatican Library exhibit is at:

http://www.ncsa.uiuc.edu/SDG/Experimental/vatican.exhibit/Vatican.exhibit.html

The work was done by hoesel@chem.rug.nl (frans van hoesel); we're just
providing the server space...

Cheers,
Marc


From dale@ora.com  Wed May 26 05:01:48 1993
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18314; Wed, 26 May 93 05:01:48 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16871; Wed, 26 May 1993 05:23:09 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA16902; Tue, 25 May 1993 23:22:46 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
	id AA03134; Tue, 25 May 1993 20:22:42 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
	id AA03569; Tue, 25 May 1993 20:24:06 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9305252024.ZM3567@cider.west.ora.com>
Date: Tue, 25 May 1993 20:24:05 -0700
In-Reply-To: Dave_Raggett <dsr@hplb.hpl.hp.com>
        "Re HMML?" (May 25,  5:59pm)
References: <9305251659.AA13601@manuel.hpl.hp.com>
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: Re HMML?
Cc: www-talk@nxoc01.cern.ch

On May 25,  5:59pm, Dave_Raggett wrote:

>My main objective is backwards compatibility with existing HTML. The change
>to the container model shouldn't effect such documents. Another objective is

I'd like to see some discussion about HMML being backwards
compatible with HTML.  I think it's a mistake to set that up as
a design objective.  It also raises questions about how WWW parsers
are going to work in the future.  I would prefer to see HTML as
a frozen thing; and HMML as the next generation.  HMML documents should
identify themselves using a document type declaration and parsers
should look for this information.  

Once HMML becomes available, new documents should conform to
HMML, not HTML.  Support for HTML continues for already
existing documents.  

Also, because HTML documents currently don't have to conform
to the HTML DTD, you have a lot more variety out there than
you expect.  It won't be easy for HMML to provide a useful
level of validation and grandfather the any-which-way-it-fits
HTML documents.

>to provide support for groupings of HTML documents that form on-line books,
>magazines, journals and conference proceedings etc. The idea here is to
>provide presentation independent markup as a basis for:
>
>    o   indexing based upon markup (title/author/subject, topics, ...)
>    o   familiar navigation model (tables of contents, indexes, ...)
>    o   printing related information (not just the current document)
>    o   importing books, etc into the web
>
>These extensions must be compatible with being able to parse HTML+ efficiently
>using modest programs (unlike HyTime!). I am currently analysing a wide range
>of paper material to see whether these documents can be adequately described
>using just a few new tags.

There are two things wrapped together in the above paragraphs.
First, you'd like HMML markup to be rich enough and stable
enough so that the WWW software can reliably produce the 
listed behaviors.  The second is that these behaviors are
necessary to support more complex document models.  What
we really want are the behaviors, not necessarily the complex
document models.

As I see it, HMML should be designed for effective delivery 
of documents in WWW; it should be a distribution format, not
a source, or authoring, format.   If you want to do the latter,
WWW would do best by taking the approach that it accept 
any arbitrary SGML DTD.  That may happen,
one day, but it doesn't seem like the best approach today.
The main point is that I don't want to create and
manage information in HMML;  I want to use a full SGML DTD
that allows me to create and manage my information for multiple
uses, including printing or distribution in other systems. 
I can filter from the richer, SGML DTD to HMML for distribution
on the Web.  Thus, HMML should be a useful subset of the
functionality required to deliver hypermedia documents over
networks.

Just to give an example, an authoring DTD might be concerned
with the semantic difference between COMMAND and FILENAME.  In
the HMML, we need not preserve that semantic distinction, and
we can call them the same thing.  I have seen one approach in
which all these elements were just classified as in-line
elements, and an attribute was used to preserve the original
element name.  Thus, COMMAND and FILENAME might both be distilled
into the element "INLINE", distinguishing it from things like
paragraphs, lists, and examples that are different types of
text blocks.

If we don't design HMML as a distribution format, the HMML DTD will grow and
grow to include new tags for new document types.  
Look at the AAP DTD and you will see something that tries
to support lots of different document models.  The Docbook DTD has
a more limited scope but it is still reasonably large.  Short of
supporting any arbitrary DTD, we will find it difficult, I think,
to create an HMML DTD that serves complex document models you
describe. 

HMML should still describe the logical components
of documents independent of a particular presentation.  However,
we should be concerned with presentation and distribution issues in
HMML, and define the appropriate mechanisms for doing it. In designing HMML,
we should largely concern ourselves with distilling the variety of different
document types into a simpler, limited format for distribution on the net
and presentation under a variety of different browsers. 

-- 

Dale Dougherty 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

UUCP:	uunet!ora!dale     Internet :   dale@ora.com


From dsr@hplb.hpl.hp.com  Wed May 26 14:08:34 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23220; Wed, 26 May 93 14:08:34 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19389; Wed, 26 May 1993 14:29:56 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 26 May 93 13:22:39 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA02564; Wed, 26 May 93 13:28:11 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305261228.AA02564@manuel.hpl.hp.com>
Subject: HTRQ and Kerberos
To: sanders@bsdi.com
Date: Wed, 26 May 93 13:28:09 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Tony Sanders writes (Sun, 23 May 1993)

> What are you browser writers thinking about supporting wrt HTTP/1.0 request
> headers (e.g., see the kerberos proposal below)?  We need to think about
> how to implement the ChargeTo: and Authorization: headers in a generic
> way so the browser can easily support different styles.  I would
> like to see From:, User-Agent:, and Referer: being used (currently
> I've only seen "Accept: text/plain" and "Authorization: user xxx").

I am successfully using the Authorization field within Hewlett Packard
for providing restricted access to Web documents:

Two formats:

    a)  Authorization: user fred:secret
    b)  Authorization: user fred

When the browser gets error code 401 (unauthorized) it asks the user
for a username and password. This is then included as (a) in all subsequent
queries to the same server (same protocol, port and host name). By default
the browser always sends the user name as (b) which it obtains from the
environment variable "USER". This avoid the need for users to type
anything if they are known to the server via the .rhosts or /etc/hosts.equiv
mechanism.

This approach matches our needs well, and corresponds to the standard level of
security offered with FTP, rlogin and telnet. Its really great to see someone
extending this to support Kerberos!

I have also been studying the privacy enhanced mail proposals and the general
field of authentication and encryption based on public key techniques. These
techniques require the setup of registration authorities that permit you to
look up the public key for any person on the system.

Such an approach would allow servers to use the registered public key of a
client to check that a request indeed originated from that client.
Furthermore it would allow clients to be certain that a document obtained
from a server is indeed by whom it claims to be and hasn't been altered in
anyway whatsoever.

To do this we will need to define authentication formats for both HTRQ
and MIME headers. This needs to be done in concert with other groups in
the Internet. Is anyone interested in picking this up?

Regards,

Dave Raggett

From marca@wintermute.ncsa.uiuc.edu  Wed May 26 16:49:07 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27196; Wed, 26 May 93 16:49:07 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22719; Wed, 26 May 1993 17:10:32 +0200
Received: from uxc.cso.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23849
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 26 May 93 10:10:19 -0500
Received: from wintermute.ncsa.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA25991
  (5.67a8/IDA-1.5); Wed, 26 May 1993 00:25:35 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:dsr@hplb.hpl.hp.com id AA02741; Wed, 26 May 93 00:25:52 -0500
Date: Wed, 26 May 93 00:25:52 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305260525.AA02741@wintermute.ncsa.uiuc.edu>
To: dale@ora.com (Dale Dougherty)
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Subject: Re: Re HMML?
In-Reply-To: <9305252024.ZM3567@cider.west.ora.com>
References: <9305251659.AA13601@manuel.hpl.hp.com>
	<9305252024.ZM3567@cider.west.ora.com>
	<dsr@hplb.hpl.hp.com>
X-Md4-Signature: 39366bb395ff437f7eb123bc969d33ef

Dale Dougherty writes:
> >My main objective is backwards compatibility with existing HTML.
> >The change to the container model shouldn't effect such documents.
> >Another objective is
> 
> I'd like to see some discussion about HMML being backwards
> compatible with HTML.  I think it's a mistake to set that up as a
> design objective.  It also raises questions about how WWW parsers
> are going to work in the future.  I would prefer to see HTML as a
> frozen thing; and HMML as the next generation.  HMML documents
> should identify themselves using a document type declaration and
> parsers should look for this information.
> 
> Once HMML becomes available, new documents should conform to HMML,
> not HTML.  Support for HTML continues for already existing
> documents.

I agree -- this is a good thing to discuss.  I think HTML is
expendable if HMML can be better without having anything to do with
it.  (Whether that's the case or not, I'm not sure.  I'd guess it is.)

Cheers,
Marc


From dsr@hplb.hpl.hp.com  Wed May 26 17:35:27 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28333; Wed, 26 May 93 17:35:27 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02089; Wed, 26 May 1993 17:56:47 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 26 May 93 16:49:23 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA03031; Wed, 26 May 93 16:54:56 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305261554.AA03031@manuel.hpl.hp.com>
Subject: Re: Poetry and Maths
To: www-talk@nxoc01.cern.ch
Date: Wed, 26 May 93 16:54:54 BST
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Mailer: Elm [revision: 66.36.1.1]

> Much opinion seems to be that line and page breaks are against the
> spirit of HTML. I disagree, as I think there are cases where some
> information of this sort is vital to a document.

> It came to me last night that the obvious example is poetry. To quote a
> poem in an HTML document, how does the WWW suggest that HTML should get
> the line breaks in the right place? <p> is suitable between verses, but
> between lines. I really don't see that adding <newline> will cause
> problems. Similarly, I think that page breaks between poems are
> entirely suitable; all the anthologies I possess are one (maximum 2)
> poems per page, and there's alot of whitespace.

Yes its nice to know that other people are interested in markup for poetry
too! My suggestion is a new tag <POEM> which preserves line breaks and
that browsers are recommended to use a left indent. The <p> tag is
permitted in <POEM> ... </POEM> along with inline emphasis.

As for maths etc. I feel that we should encourage embedding of specialised
formats in the same spirit as pictures. That way HTML remains simple, while
making it practical to independently evolve other formats for specialised
purposes.

HTML MUSTN'T BECOME ALL THINGS TO ALL PEOPLE!

Dave Raggett

From dsr@hplb.hpl.hp.com  Thu May 27 10:34:01 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13185; Thu, 27 May 93 10:34:01 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23862; Thu, 27 May 1993 10:55:25 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Thu, 27 May 93 09:48:06 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA11337; Thu, 27 May 93 09:53:36 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305270853.AA11337@manuel.hpl.hp.com>
Subject: Re: More than just HTML (was Re: Poetry and Maths)
To: nholtz@civeng.carleton.ca
Date: Thu, 27 May 93 9:53:34 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Neal Holtz writes (in response to Thomas A. Fine):

>> HTML only provides the framework by which lots of other document types
>> are accessed.  You want to do lot's of neat TeX things?  Use TeX. 

> The kind of documents I am most interested in are about 50\% math
> and 50\% text with {\em lots} of cross-references.  It is important
> that the math appear in-line with the document.  A typical unit (node)
> is 1/2 page.  I worry about performance if, for example, the math
> portion is farmed out to TeX/xdvi for rendering, and I wonder whether
> an acceptable cacheing scheme can be found (perhaps it can).

> I was attracted to HTML for this purpose because of the nice tools
> that are now available, in contrast to other mechanisms.

It seems to important that there is a simple and efficient way of embedding
equations in HTML documents. I very much like the interface for
interactively specifying equations in Microsoft Word on the PC - however
this is quite a lot of effort to implement.

My suggestion is that we follow the approach taken with the PC and allow
object level embedding in HTML. This basically means you keep HTML small
and simple while allowing people to embed figures etc. in a foreign format.
The embedding uses a link like Mosaic's <IMG> tag. The embedded data can
be sent along with the main document using MIME's multipart capability.
This approach also allows simple browsers to negotiate the format, so
that the server can be asked to render equations into bitmaps etc.

This approach avoids the danger of HTML being continuously extended to
support an every increasing variety of needs. By decoupling HTML
from special purpose formats, I believe that the latter can evolve
faster and more effectively, than if they were tied to revisions to HTML
itself. 

That said, I am drafting a proposal for HTML+ (a superset of HTML) and
would be happy to draft ideas for supporting equations in a presentation
independent format. I don't think we should tie ourselves to Tex's approach,
but should take the good ideas from a wide variety of sources: Tex, eqn,
Microsoft Word, Mac, ...

Comments please!

Best wishes,

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com



From dsr@hplb.hpl.hp.com  Thu May 27 11:11:08 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13611; Thu, 27 May 93 11:11:08 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02163; Thu, 27 May 1993 11:32:30 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Thu, 27 May 93 10:25:11 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA15764; Thu, 27 May 93 10:30:46 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9305270930.AA15764@manuel.hpl.hp.com>
Subject: Re: RE dtd2.html
To: terry@ora.com
Date: Thu, 27 May 93 10:30:45 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Terry,

Thank you for your comments on "DTD2.html". I am still at an early stage in 
developing this, and am very appreciative of input at this stage.

> + FLYLEAF seems misnamed to me.  As its contents are adequately
>        contained within FRONT, you can just let this 
>        info float withing FRONT.  Then the title page can be
>        assembled from the FRONT info.

When you browse through a bookstore, you work through a kind of hierarchy:

    a)  the generic classification of this
        part of the store e.g. SF, or Languages

    b)  the information on the spine of the books

    c)  the cover page - title, subtitle, illustration, ...

    d)  On opening a book the flyleaf often contains a
        useful summary of what the book is about

    e)  You may next look at the contents before
        browsing rapidly through the book itself.

It seemed a promising idea to try and support this kind of behaviour
for on-line media. For instance you could see reduced pictures of
the covers of several books at once. This hierarchy would also
serve in searchable catalogs of available material.

The idea of the FLYLEAF tag was to provide markup that captures
part of this hierarchy.

> + AUTHOR and EDITOR may occur more than once.

Thanks.

>  + LEGAL, like FLYLEAF, probably isn't needed.

You may be right here - I note that the ISBN number appears in a
variety of places in printed matter.

>  + Are you contemplating nestable SECTIONs?

Yes.

> + I am not sure that STRONG, B, I, and U are desirable as
>    elements.  These formatting characteristics ought to
>    get applied to elements on the basis of their meaning.
>    But that's a rather SGML point of view; you may wish
>    to allow this slop room for WWW.

I don't like them either. They are present in HTML to support
importing (scanned) documents for which a filter has no way of deciding
the original meaning.

> + PRE is not really a paragraph type, as the contents of
>    such sections need not be paras.

My mistake. The <P> tag isn't allowed in the PRE element anyway.

> + MENU seems to be simply a subset of UL, and could be eliminated.

It crept into HTML at an early stage and I would prefer <UL COMPACT>
but will have to keep MENU for backwards compatibility.

> + IMG needs some TYPE attribute.

The type is usually defined by the referenced data, preferably as a MIME
type or failing that on the basis of the file suffix or the presence of a
well known pattern at the start of the data.

> On the whole this is a compact DTD and looks workable (though only
> real testing can prove that).  How is it related to HMML?

Thanks!

HMML is the name of an internal and experimental DTD developed by
Pei Wei. However, things became confused when Tim Berners Lee started
using "HMML" for the proposed replacement for the original HTML DTD.
To avoid confusion I am calling the new DTD "HTML+" which also emphasises
that it is a superset of the current format.

Can you help me with a simple SGML problem? I have searched through
Goldfarb's handbook, but can't find how to specify attributes which
don't need values, as in <DL COMPACT>. Do you have any ideas?

Many thanks,

Dave Raggett

p.s. Thanks for your earlier comments on tables. I am now thinking
    about extending definition lists to support tables with optional
    title, and column headers, and limited adjustment/width info
    for efficient rendering.

From murphy@dccs.upenn.edu  Thu May 27 15:24:42 1993
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17140; Thu, 27 May 93 15:24:42 MET DST
Received: from NOC4.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25062; Thu, 27 May 1993 15:46:08 +0200
Received: from LAM.DCCS.UPENN.EDU by noc4.dccs.upenn.edu
	id AA25833; Thu, 27 May 93 09:46:05 -0400
Return-Path: <murphy@dccs.upenn.edu>
Received: by lam.dccs.upenn.edu
	id AA03278; Thu, 27 May 93 09:46:04 -0400
Posted-Date: Thu, 27 May 93 09:46:03 -0400
Message-Id: <9305271346.AA03278@lam.dccs.upenn.edu>
To: www-talk@nxoc01.cern.ch
Cc: litwack@dccs.upenn.edu
Subject: Keeping HTML Simple & Format negotiation between Browser & Server
Date: Thu, 27 May 93 09:46:03 -0400
From: murphy@dccs.upenn.edu
X-Mts: smtp


There's been a discussion on www-talk about how complex HTML should
become -- and the building opinion seems to be: keep HTML simple, and
allow more complicated formats to be embedded "in-line" in the HTML,
and negotiated between the server and the client.

Dave Raggett:
>> My suggestion is that we follow the approach taken with the PC and allow
>> object level embedding in HTML. This basically means you keep HTML small
>> and simple while allowing people to embed figures etc. in a foreign format.
>> The embedding uses a link like Mosaic's <IMG> tag. The embedded data can
>> be sent along with the main document using MIME's multipart capability.
>> This approach also allows simple browsers to negotiate the format, so
>> that the server can be asked to render equations into bitmaps etc.
>> 
>> This approach avoids the danger of HTML being continuously extended to
>> support an every increasing variety of needs. By decoupling HTML
>> from special purpose formats, I believe that the latter can evolve
>> faster and more effectively, than if they were tied to revisions to HTML
>> itself. 
>> 
>> That said, I am drafting a proposal for HTML+ (a superset of HTML) and
>> would be happy to draft ideas for supporting equations in a presentation
>> independent format. I don't think we should tie ourselves to Tex's approach,
>> but should take the good ideas from a wide variety of sources: Tex, eqn,
>> Microsoft Word, Mac, ...
>> 
>> Comments please!
>> 
>> Best wishes,
>> 
>> Dave Raggett,

So for example, the client could send a list of pre-defined formats to
the server (e.g. IMG, TeX, PostScript, etc), and then the server can
choose among different formats of the same item embedded in the
document to give the client what it can handle.  Sometimes, the server
might not be able to convert the one of the things that the client
(browser) can deal with, and then it's up to the browser to display an
intelligent message about it, perhaps even giving the user information
so he can find software for his desktop environment which DOES deal
with that format.

Elements needed:

1) an ever-growing dictionary of pre-defined format names and
agreement on what those format names mean.  It has to be ever-growing
because it's a fact of life -- there's always going to be new types of
data formats coming onto the scene.  The server and the browser
(client) both need access to this dictionary, perhaps getting a new
version of it every once in a while (either automatically, or perhaps
upon the user's request)

2) The document format (HTML, HMML, whatever) needs to accomodate
documents which have multiple items in it, which could be different
types, such as an embedded graph and a mathematical formula.  AND each
of the items themselves COULD be expressed in a number of different
format types.  The information which the two alternatives convey would
not have to be exactly equivalent -- sometimes a picture is worth a
thousand words!  But if text is all your device can display, you might
settle for the words.  The person who maintains the document can put
both text & image in the document, and the image would be displayed if
possible.

3) Either:

a) The protocol which the server and the client use must allow the
client to tell the server which pre-defined format types it can deal
with, and then the server can send back a version of the document
which contains those types.
  OR
b) The protocol has no negotiation; the server sends back the entire
document and the client can sort it out.  This COULD be costly in
terms of network bandwidth and computing resources at the desktop...
  OR
c) Is there another alternative?


4) Whichever way is chosen for #3, the browser (client) needs a
lot of information in it about what the desktop environment is like
(e.g. it can display postscript by starting up XPostScriptViewer
with arguments "-f <filename> -mono", it can display bitmap images
by starting up "xv <filename>", it can display bitmap images
by starting up GIFFER,  etc).


5) The user will probably want to be able to customize how the browser
chooses desktop applications (e.g. he installs a new image viewer, or
a device driver & software for sound playback).


The complexity of how to translate and display these "foreign" formats
could then be shifted to the OTHER applications in the desktop
environment, and kept out of the browser, and out of HTML.


Problems with this model:

1) If the browser starts up another application to handle a portion of
   the document in a foreign format, what happens if that item in the
   document was SUPPOSED to be in-line with other portions of the
   document?  How does the browser pull it back into the display of
   the document and make it part of the whole?

   Perhaps 
   a) There's a way to tell the application to dump the results into a
   file or a pipe, which the browser then reads & incorporates into
   the document or

   b) HTML accomodates embedded binary data, with a tag introducing it
   as sound, or a bitmap image, or whatever, and an integer which says
   how long the binary data stream is in bytes.  But I believe the
   assumption here is that the server MUST know about the devices that
   are at the desktop in order to generate, e.g. a reasonable image.


2) What if one wants to put hot-spots (links) into one of these
   foreign format objects?  For example, suppose one wants the user to
   be able to point & client on a portion of the mathematical formula,
   which is linked to another mathematical formula (or a graph, or a
   piece of text, etc) which more fully explains it?


________________________________________________________________________
|                                                                      |
| Linda A Murphy                       Internet: murphy@dccs.upenn.edu |
| Network Engineering       Data Communications and Computing Services |
| University of Pennsylvania                            (215) 898-9534 |
|______________________________________________________________________|

From weber@eitech.com  Thu May 27 17:21:20 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19852; Thu, 27 May 93 17:21:20 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09366; Thu, 27 May 1993 17:42:42 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA22156; Thu, 27 May 93 10:41:39 -0500
Received: from bd.eitech.com ([192.100.58.27]) by eitech.com (4.1/SMI-4.1)
	id AA23382; Thu, 27 May 93 08:37:23 PDT
Message-Id: <9305271537.AA23382@eitech.com>
X-Sender: weber@eitech
Date: Thu, 27 May 1993 08:43:09 -0800
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
From: weber@eitech.com (Jay Weber)
Subject: Re: More than just HTML (was Re: Poetry and Maths)
Cc: www-talk@nxoc01.cern.ch
X-Mailer: <PC Eudora Version 1.1a5>

At 09:53 AM 5/27/93 BST, Dave_Raggett wrote:
>My suggestion is that we follow the approach taken with the PC and allow
>object level embedding in HTML. This basically means you keep HTML small
>and simple while allowing people to embed figures etc. in a foreign format.
>The embedding uses a link like Mosaic's <IMG> tag.

Good idea, that's a very important hook.  Can we end up making IMG just
a special case, or at least just an alias?

>The embedded data can
>be sent along with the main document using MIME's multipart capability.

Right, this will be significantly more efficient for some retrieval
mechanisms (especially when authentication and authorization is involved),
and a little nicer for servers to organize their documents.

How do you plan on doing this in HTML+?  Sounds like the first part
will be text/html, where the anchors reference other parts.  The reference
can be done by defining a URL access type of "part", e.g. HREF=part:XXX
where XXX is a Content-id.

>This approach also allows simple browsers to negotiate the format, so
>that the server can be asked to render equations into bitmaps etc.

This is somewhat in conflict with bundling as multiparts, since the
negotiation would need to be when asking for the compound document
(which is before the browser expects to get a specific obscure type).

Jay Weber
EIT


From timbl@www3.cern.ch  Thu May 27 17:59:12 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20763; Thu, 27 May 93 17:59:12 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12133; Thu, 27 May 1993 18:20:38 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA08251; Thu, 27 May 93 18:14:22 +0100
Date: Thu, 27 May 93 18:14:22 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305271714.AA08251@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: RE dtd2.html
Cc: terry@ora.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Terry:
> > + I am not sure that STRONG, B, I, and U are desirable as
> >    elements.  These formatting characteristics ought to
> >    get applied to elements on the basis of their meaning.
> >    But that's a rather SGML point of view; you may wish
> >    to allow this slop room for WWW.

Dave:
> I don't like them either. They are present in HTML to support
> importing (scanned) documents for which a filter has no way of  
deciding
> the original meaning.


HTML and HTML have a status in between a formatting language and a
spacific application.  As a delivery language for very wide
use, the tags must be generic thimselves.  STRONG emphasis
or EMphasis is not a formatting instruction, it is semantic.
But it is not as semantic as PROHIBITION or
LOCSHELFNUMBER or MICASHEETTHICKNESS.

HTML+ must like HTML refrain from falling into eiter trap,
of being too related to markup, or of being too related
to a specific application.  FLYLEAF sounds very booklike
to me.  Perhaps we should ask ourselves what the logical
significance (rather than paper representation) of a flyleaf
is.  Normally it is a summary, much like a WAIS source file's
"description:". It is free, and provided by the publisher
to entice the reader in.  If we make it less booklike
then we can use it for say databases and cyberspace
manicure parlours as well as books.  If you can can see how
to describe something without the book analogy, then you will
have something more flexible for the future. As who knows
what ORA will be publishig in  a few years' time? :-)

Tim


From weber@eitech.com  Thu May 27 18:13:45 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21057; Thu, 27 May 93 18:13:45 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13102; Thu, 27 May 1993 18:35:09 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA24029; Thu, 27 May 93 11:34:08 -0500
Received: from bd.eitech.com ([192.100.58.27]) by eitech.com (4.1/SMI-4.1)
	id AA23627; Thu, 27 May 93 09:29:57 PDT
Message-Id: <9305271629.AA23627@eitech.com>
X-Sender: weber@eitech
Date: Thu, 27 May 1993 09:35:44 -0800
To: murphy@dccs.upenn.edu, www-talk@nxoc01.cern.ch
From: weber@eitech.com (Jay Weber)
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
Cc: litwack@dccs.upenn.edu
X-Mailer: <PC Eudora Version 1.1a5>

At 09:46 AM 5/27/93 -0400, murphy@dccs.upenn.edu wrote:
>Elements needed:
>
>1) an ever-growing dictionary of pre-defined format names and
>agreement on what those format names mean.  It has to be ever-growing
>because it's a fact of life -- there's always going to be new types of
>data formats coming onto the scene.  The server and the browser
>(client) both need access to this dictionary, perhaps getting a new
>version of it every once in a while (either automatically, or perhaps
>upon the user's request)

That's easy, MIME types are registered with the Internet Naming Authority,
IANA.

>2) The document format (HTML, HMML, whatever) needs to accomodate
>documents which have multiple items in it, which could be different
>types, such as an embedded graph and a mathematical formula.  AND each
>of the items themselves COULD be expressed in a number of different
>format types.

I'll wave the MIME flag again and point out that MIME has a modular
bundling mechanism -- the embedded object can be of type multipart/mixed.

>  The information which the two alternatives convey would
>not have to be exactly equivalent -- sometimes a picture is worth a
>thousand words!  But if text is all your device can display, you might
>settle for the words.  The person who maintains the document can put
>both text & image in the document, and the image would be displayed if
>possible.

MIME again!  The MIME type multipart/alternative allows you to specify
a series of alternative objects, ordered by preference.

More HTML enthusiasts should check out MIME.

Jay Weber
EIT


From dale@ora.com  Thu May 27 18:59:13 1993
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22008; Thu, 27 May 93 18:59:13 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15662; Thu, 27 May 1993 19:20:39 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA10163; Thu, 27 May 1993 13:20:34 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA17220; Thu, 27 May 1993 10:20:33 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9305271020.ZM17218@rock.west.ora.com>
Date: Thu, 27 May 1993 10:20:32 -0700
In-Reply-To: Tim Berners-Lee <timbl@www3.cern.ch>
        "Re: RE dtd2.html" (May 27,  6:14pm)
References: <9305271714.AA08251@www3.cern.ch>
X-Mailer: Z-Mail (2.1.0 10/27/92)
To: timbl@nxoc01.cern.ch, Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: RE dtd2.html
Cc: terry@ora.com, www-talk@nxoc01.cern.ch

I agree that flyleaf sounds like a bad idea.  In fact,
Dave's navigational steps that lead to choosing a book
in a bookstore is not a good guide to describing the
logical structure of the information.  As Tim says,
Summary or Abstract describes adequately what the information
means; how it used or arranged are aspects of application,
whether defined in the app interface, style sheet or user's
navigational actions.    

-- 
Dale Dougherty (dale@ora.com) 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

From janssen@parc.xerox.com  Thu May 27 19:21:45 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22385; Thu, 27 May 93 19:21:45 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17155; Thu, 27 May 1993 19:43:11 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12258>; Thu, 27 May 1993 10:42:01 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 27 May 1993 10:42:00 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 27 May 1993 10:41:55 -0700 (PDT)
Message-Id: <Qg1DpX0B0KGW0vnLYy@holmes.parc.xerox.com>
Date: 	Thu, 27 May 1993 10:41:55 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: terry@ora.com, Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: RE dtd2.html
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9305270930.AA15764@manuel.hpl.hp.com>
References: <9305270930.AA15764@manuel.hpl.hp.com>

Excerpts from ext.WorldWideWeb: 27-May-93 Re: RE dtd2.html
Dave_Raggett@hplb.hpl.hp (3410)

> > + I am not sure that STRONG, B, I, and U are desirable as
> >    elements.  These formatting characteristics ought to
> >    get applied to elements on the basis of their meaning.
> >    But that's a rather SGML point of view; you may wish
> >    to allow this slop room for WWW.

> I don't like them either. They are present in HTML to support
> importing (scanned) documents for which a filter has no way of deciding
> the original meaning.

This justification doesn't sound terribly good.  If we can't infer the
meaning of the font changes, perhaps translating the scanned document to
HTML is inappropriate; perhaps the scanned document should be stored in
TeX or Postscript or GIF, depending on what other image characteristics
of the document seem important.  Or perhaps the font change information
should simply be discarded on conversion to HTML, as it does not
translate to meaning.

Or perhaps the right way to think of these is to apply the output rules,
in reverse.  That is, the user can specify how <EMPH> is to be formatted
on output; similarly, perhaps the user could specify how bold font is to
be interpreted on input.

Bill


From sanders@bsdi.com  Thu May 27 20:23:33 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23744; Thu, 27 May 93 20:23:33 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20101; Thu, 27 May 1993 20:44:45 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA26568; Thu, 27 May 93 13:44:37 -0500
Message-Id: <9305271844.AA26568@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: RE dtd2.html 
In-Reply-To: Bill Janssen's message of Thu, 27 May 93 10:41:55 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 27 May 1993 13:44:37 -0500
From: Tony Sanders <sanders@bsdi.com>

In-reply-to: Bill Janssen's message of Thu, 27 May 93 10:41:55 PDT.
> Excerpts from ext.WorldWideWeb: 27-May-93 Re: RE dtd2.html
> Dave_Raggett@hplb.hpl.hp (3410)
> > > + I am not sure that STRONG, B, I, and U are desirable as
> > >    elements.  These formatting characteristics ought to
> > I don't like them either. They are present in HTML to support
> > importing (scanned) documents for which a filter has no way of deciding
> > the original meaning.
> This justification doesn't sound terribly good.  If we can't infer the
> meaning of the font changes, perhaps translating the scanned document to
> HTML is inappropriate; perhaps the scanned document should be stored in
> TeX or Postscript or GIF, depending on what other image characteristics
> of the document seem important.  Or perhaps the font change information
> should simply be discarded on conversion to HTML, as it does not
> translate to meaning.

I use them for preserving man page formatting _^HX_^HY_^HZ gets translated
to <I>XYZ</I>.  If you don't like them and believe they are void of content
then simply ignore them in your browser.  I believe that since HTML is
more of a delivery vechicle than a formal markup language they are required
because HTML cannot be all things to all people.  I VERY much agree that
tags should be semantic but in a delivery format I think you need to leave
a little room for slop.

If you remove <I> and <B> what will happen instead of using TeX or whatever
people will use stuff like <CITE> (or whatever formats nice in their browser)
where it is inappropriate (assuming you removed <EM> and <STRONG> for
the same reasons).

If you resort to an external format how are you going to deal with hypertext
links?  I may not be able to figure out why foo was in italics but I can
sure as heck generate a hypertext link to man pages from text like
``foo(1)''.

--sanders

From janssen@parc.xerox.com  Thu May 27 20:53:32 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24310; Thu, 27 May 93 20:53:32 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21507; Thu, 27 May 1993 21:14:59 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12257>; Thu, 27 May 1993 12:14:51 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 27 May 1993 12:14:39 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 27 May 1993 12:14:29 -0700 (PDT)
Message-Id: <0g1FAJoB0KGWMvnEZx@holmes.parc.xerox.com>
Date: 	Thu, 27 May 1993 12:14:29 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, sanders@bsdi.com
Subject: Re: RE dtd2.html
In-Reply-To: <9305271844.AA26568@austin.BSDI.COM>
References: <9305271844.AA26568@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 27-May-93 Re: RE dtd2.html Tony
Sanders@bsdi.com (1875)

> If you don't like them and believe they are void of content
> then simply ignore them in your browser.

Well, that's not a terrible solution, but I still don't like it.  If the
man page formatting means something, it should be translated to what it
means.  If it doesn't, it should be dropped.  In either case, having
constructs like <I> in HTML will only lead to more cases of this same
problem; that is, you have some formatting (underlines, italics, bold)
in your document, but you don't know why.

Bill

From broccol@csdsun1a.arlut.utexas.edu  Thu May 27 21:03:57 1993
Return-Path: <broccol@csdsun1a.arlut.utexas.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24458; Thu, 27 May 93 21:03:57 MET DST
Received: from csdsun1b.arlut.utexas.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21861; Thu, 27 May 1993 21:24:56 +0200
Received: by csdsun1a.arlut.utexas.edu (4.1/Alliant-5.0)
	id AA07689; Thu, 27 May 93 14:24:29 CDT
Date: Thu, 27 May 93 14:24:29 CDT
From: broccol@csdsun1a.arlut.utexas.edu (Jonathan Abbey)
Message-Id: <9305271924.AA07689@csdsun1a.arlut.utexas.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server

Linda Murphy (murphy@dccs.upenn.edu) wrote:
| Subject: Keeping HTML Simple & Format negotiation between Browser & Server
| Date: Thu, 27 May 93 09:46:03 -0400
| From: murphy@dccs.upenn.edu
| 
| There's been a discussion on www-talk about how complex HTML should
| become -- and the building opinion seems to be: keep HTML simple, and
| allow more complicated formats to be embedded "in-line" in the HTML,
| and negotiated between the server and the client.
| 
| [...]
|
| Problems with this model:
| 
| 1) If the browser starts up another application to handle a portion of
|    the document in a foreign format, what happens if that item in the
|    document was SUPPOSED to be in-line with other portions of the
|    document?  How does the browser pull it back into the display of
|    the document and make it part of the whole?
The Macintosh and Microsoft Windows systems are moving toward compound
document architectures, as is X11R6.  This shouldn't be an
insurmountable problem.
With X, one could look at an imbedded object, try to determine its
appropriate size, then ask a renderer to image a file into a
sub-window inside the browser's viewing area.
| 
| 
| 2) What if one wants to put hot-spots (links) into one of these
|    foreign format objects?  For example, suppose one wants the user to
|    be able to point & client on a portion of the mathematical formula,
|    which is linked to another mathematical formula (or a graph, or a
|    piece of text, etc) which more fully explains it?
| 
This is the biggest argument for always providing a canonical image
representation of non-plain-textual data.
My dream for ultimate flexibility in the browser would be for the
server and the browser be able to negotiate the browser's needs for a
canonical, viewable image of the document. 
1) The browser would ask what size the image (or paper, or whatever)
   is designed to be viewed at.
2) The server would report the designated image size, along with a
   summary of its capacity for generating other image sizes.
3) The browser would request an image of whatever parameters best suit the
   available display.
4) The server would either
 - Image the document according to the browser's specifications,
   caching it for future retrieval by browser's with similar needs.
 or 
 - Send the one image closest to the browser's requirements for that
   document if no dynamic image generation were possible
Each link in the image would consist of:
 -  a union of rectangles designating the boundary of the link
 -  a URL
 -  a set of flags, perhaps including one indicating whether the link
    should be decorated by the browser, or whether the link is already 
    decorated in the image
5) The browser would scale the image if necessary (obviously it would
   be preferable for the server to be able to generate an image that
   is best suited for the browser, but if not the browser would scale
   the image and the corresponding regions down), then present it to
   the user.
This way, links could be provided in a reliable fashion within ANY
kind of complex data, and exterior viewers could be used to do a
better job of imaging a particular kind of data to other output
devices at the browser's disposal.  E.g., a PostScript document would
be available on screen at an appropriate resolution with links
included, and the same document (or a version of the document that
didn't have the links decorated) could be sent to a file or a printer.
It might even be possible to provide the same set of links with
something that is imaged at the browser's side if there is a
definitive representation for that data type that can be relied on.
Something similar could be done with sound files by
providing a start and stop time for a particular link.  Video files
likewise, with start, stop and a union of rectangles.
--
Jonathan Abbey
broccol@csdsun1a.arlut.utexas.edu
Applied Research Laboratories
The University of Texas at Austin



From sanders@bsdi.com  Thu May 27 21:48:29 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25239; Thu, 27 May 93 21:48:29 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23373; Thu, 27 May 1993 22:08:45 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA26764; Thu, 27 May 93 15:08:30 -0500
Message-Id: <9305272008.AA26764@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server 
In-Reply-To: Your message of Thu, 27 May 93 14:24:29 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 27 May 1993 15:08:29 -0500
From: Tony Sanders <sanders@bsdi.com>

Keep it simple being the key phrase:

> Each link in the image would consist of:
>  -  a union of rectangles designating the boundary of the link
>  -  a URL
>  -  a set of flags, perhaps including one indicating whether the link
>     should be decorated by the browser, or whether the link is already 
>     decorated in the image
My prefered scheme for selection of links in external objects is just send
the x,y coordinates of the selection to the server and let it deal with
it however is best.  This is how the current selection stuff works for
<IMG ISMAP>.  This lets you backend with whatever you need (like maybe
WAIS spatial indexing) without hardcoding anything in the client.

This scheme has the advantages of being easy on the browser, simple to
implement, low network overhead, it fits in with the existing HTTP
protocol (even HTTP/0.9) and it's working today:

    http://www.bsdi.com/server/walk/walk.html
	Is a demo of exactly this scheme (requires Mosaic 1.0 with the
	patches pointed to in the document, Mosaic 1.1 will have this
	built-in).  Text-only browsers need to start doing something about
	<IMG> like [Sorry, image not available].

    http://www.bsdi.com/server/bookmark/demo.html
	Is another demo of image selection with a pratical side.

The HTML looks like:
    <A HREF="http://server/path><IMG SRC="..." ISMAP></A>
and upon selection the browser sends:
    http://server/path?x,y
where x and y are simply the mouse coords (or whatever) relative to the
image origin (prior to any mucking around by the browser like scaling).
If the browser doesn't support ISMAP then the URL http://server/path is
sent just like normal and the server would simply return a normal HTML
document that has textual anchors for each item you can select from the
image.

The same scheme could work for any external format with a little
cooperation from the viewer.

--sanders

From sanders@bsdi.com  Thu May 27 23:35:24 1993
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27480; Thu, 27 May 93 23:35:24 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27819; Thu, 27 May 1993 23:56:50 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA27052; Thu, 27 May 93 16:56:43 -0500
Message-Id: <9305272156.AA27052@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: errors in HTTP stream
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 27 May 1993 16:56:43 -0500
From: Tony Sanders <sanders@bsdi.com>

If I'm in the middle of sending an HTML document and I get a server error
how should this be handled? The problem is when we have already generated
the HTTP status line and the mime headers and sent part of the document
before we know about the error.

   HTTP/1.0 200 Document Follows
   MIME-version: 1.0
   ...
   <error happens here>

Right now I just sort of barf some HTML at the client, that includes an
error message, and hope it does the right thing (you might be in the middle
of a header or something).

I know that in general this isn't a big problem (the user figures out
something went wrong soon enough) but it seems like we should be able to
do this a little cleaner.

I was thinking about something like <ERROR>...</ERROR>, which could then
contain relevant facts about the error and local problem reporting
procedures if it was a server error.  Clever clients would move the
error to the top and keep all other data intact just in case it's useful
in spite of the error.

You might even use </BODY><ERROR>...</ERROR> so that clients could
resync on the </BODY> in case they are inside of a <H1> or something,
this might make the parser a little easier.

Comments?

--sanders

From terry@ora.com  Fri May 28 00:10:49 1993
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28094; Fri, 28 May 93 00:10:49 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29417; Fri, 28 May 1993 00:32:17 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA15457; Thu, 27 May 1993 18:32:13 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA21008; Thu, 27 May 1993 15:32:12 -0700
Message-Id: <199305272232.AA21008@ora.com>
From: Terry Allen <terry@ora.com>
Date: Thu, 27 May 1993 15:32:11 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: HMTL+ DTD remarks

Regarding Tim BL's remark earlier today that STRONG has meaning,
I was wrong to lump it in with B, I, and U, which I'd like to
see dropped.  But let me deprecate STRONG on typographic 
grounds.  As very little writing routinely uses extra emphasis,
we don't have an established font change that indicates such
extra emphasis.  I think you're most likely to see italics
for emphasis and italic all caps for extra emphasis in today's
printed books.  If that degree of extra emphasis is satisfactory,
it is within the reach of authors with the STRONG tag.

If it is desired to distinguish between different fonts in the
original (scanned) document, when the reason those fonts were
used is unknown, it wouldn't it be less taxing to use a REMAP
attribute (<EMPHASIS REMAP="wasbolditalic">)?  

As for FLYLEAF, let me suggest calling all this front matter 
stuff META.  One might want to insist on some minimal order
in it, such as that the title come first.  Tim's right---no
knowing what we'll be publishing in a few years.  HTML+ might
be used for technical papers, recipes, or cartoons.  



Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From WIGGINS@msu.edu  Fri May 28 06:03:51 1993
Return-Path: <WIGGINS@msu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02268; Fri, 28 May 93 06:03:51 MET DST
Received: from ibm.cl.msu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09144; Fri, 28 May 1993 06:25:19 +0200
Message-Id: <9305280425.AA09144@dxmint.cern.ch>
Received: from MSU.BITNET by msu.edu (IBM VM SMTP V2R2) with BSMTP id 4549;
   Fri, 28 May 93 00:25:21 EDT
Received: by MSU (Mailer R2.08 PTF008) id 7935; Fri, 28 May 93 00:25:21 EDT
Date:         Fri, 28 May 93 00:23:29 EDT
From: Richard W Wiggins <WIGGINS@msu.edu>
Subject:      Index of documents throughout WWW-space?
To: www-talk@nxoc01.cern.ch

Is there any sort of index of documents on the Web?  Not a
hand-made list, but rather a searchable keyword index a la
Veronica (and Jughead) for Gopherspace?  User selects the
index, enters a keyword (or boolean phrase), gets back a
"document" with a list of all the documents that match.

Thanks much.

/Rich Wiggins, Gopher Coordinator, Michigan State U

From hoesel@chem.rug.nl  Fri May 28 11:03:07 1993
Return-Path: <hoesel@chem.rug.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05300; Fri, 28 May 93 11:03:07 MET DST
Received: from rugch4.chem.rug.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20860; Fri, 28 May 1993 11:24:33 +0200
Received: from rugnm6.chem.rug.nl by rugch4.chem.rug.nl with SMTP
	(16.8/16.2) id AA02350; Fri, 28 May 93 11:22:28 +0200
Received: from Xtreme.chem.rug.nl by rugnm6.chem.rug.nl via SMTP (920330.SGI/920922.WK)
	for @rugch4.chem.rug.nl:www-talk@nxoc01.cern.ch id AA16505; Fri, 28 May 93 11:29:36 GMT
Received: by Xtreme (920330.SGI/920502.SGI)
	for @rugch4.chem.rug.nl:www-talk@nxoc01.cern.ch id AA00865; Fri, 28 May 93 11:26:20 +0200
Date: Fri, 28 May 93 11:26:20 +0200
From: hoesel@chem.rug.nl (frans van hoesel)
Message-Id: <9305280926.AA00865@Xtreme>
To: www-talk@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server


keep it simple being the key phrase (tony Sanders wrote)
and advertised his scheme for doing x,y mouse coordinate transfers

I'm new to this mailing list, and I strongly feel the need for feedback
of which part of the image has been clicked on (not neccesarely into
rectanle divided), but I would like to make it simple for writers
of documents too... 

Having the scheme of tony means that I, as provider of the document
have to write some horrible script for deciding if the mouse click
was inside my circle on the image or outside.

As I don't know all the arguments that were used in favour or against his
scheme, I can imagen some 'new' ones here:

1) not terrible simple for the document provider,
2) no feedback possible on the browserside
   (if the browser would no that a certain part of the image is linked
    to some document, it could highlight it whenever the use puts its
    mouse over it... this has the advantage that If I presented to user
    with a picture of some buildings, but only two of them are linked,
    the user would not get frustrated while clicking on the other buildings)
3) a 'simple' solution in my view is a document that would allow
   pictures to be overlayed on top of each other, with a certain picture
   color transferred into transparant (white, and black are two usefull
   choices, but any color should be selectable)

-- just my blurb

- frans




From timbl@www3.cern.ch  Fri May 28 17:13:12 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11216; Fri, 28 May 93 17:13:12 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18155; Fri, 28 May 1993 17:34:41 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA14688; Fri, 28 May 93 17:28:22 +0100
Date: Fri, 28 May 93 17:28:22 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9305281628.AA14688@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: p.lister@cranfield.ac.uk
Subject: Re: Is HTTP necessary??
Cc: www-talk@nxoc01.cern.ch, ccprl@xdm001.ccc.cranfield.ac.uk
Reply-To: timbl@nxoc01.cern.ch


> Date: Mon, 17 May 93 15:02:07 BST
> From: "Peter Lister" <ccprl@xdm001.ccc.cranfield.ac.uk>
> 


[...]
> However, the more I think about it, the harder it is to justify  
HTTP
> and httpd. If I can get at all my HTML docs from within Gopher  
space,
> why bother?

Of course that doesn't mean that all the gopher clients will be
able to read them, they will get rather confused if they aren't
www clients just using the gopher protocol.  Gopher clients  can't  
handle HTML (or they would be WWW clients almost).

> All the refs from local HTML docs to other http places will
> work OK (won't they??), and I can provide a trivial default page  
for
> httpd (so that the existing WWW community who know us that way are  
happy).
> 

> The mapping functionality of httpd can be useful, but does it do  
much
> that can't be achieved by bunging symbolic links in a Gopher  
directory?
> OK, so one can map different filename formats and that has been  
useful
> here, if not vital. However, directory browsing is *not* nice with
> httpd if I have to tag every directory with .www_browsable; I want
> inexpert users to be able to publish information, and I forsee  
problems
> if they need to do anything "unexpected" like that.

What what what?  Sounds out of date. There was always a command line  
option -dy to allow ALL directories to be browsed (-dn allowed none,  
and -ds was the selctive option which checked .www_browsable).
Nowadays -dy is the default if you just run the daemon.


> HTML is great, but is HTTP worth it? I'm want practical details, so
> don't send me philosophical waffle or flame me for being a traitor  
to
> WWW, cos I'm not. 

...

Don't confuse the protocol with the implementatins of the server.
There are some very sexy server implementations giving access
to databases in a very rich way which you just couldn't do with
Gopher.  The full pwer of the format negoctiation is still to
be used by really powerful servers... but don't knock the protcol
or the model for the software.  There are a lot of servers.  I
hear there is one coming out for the Mac too.   The practical problem
will be chosing one.

Here are some arguments.  You want the option of hypertext because
it is a better interface for your readers and they deserve nothing
less.  If you provide hypertext using a gopher server you will be  
being rather weird and won't gain you much.  (Anyone doing this to  
date?).

BTW I noticed that the gopher daemon seems to respond to HTTP  
requests, but mishandles full HTTP requests -- so Gopher servers
are almost HTTP servers -- it just takes a small bug fix and you  
could use them.  Don't know to which servers this applies.  You can
try www 


Tim


From broccol@csdsun1a.arlut.utexas.edu  Fri May 28 17:35:45 1993
Return-Path: <broccol@csdsun1a.arlut.utexas.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11724; Fri, 28 May 93 17:35:45 MET DST
Received: from csdsun1b.arlut.utexas.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24950; Fri, 28 May 1993 17:57:14 +0200
Received: by csdsun1a.arlut.utexas.edu (4.1/Alliant-5.0)
	id AA25243; Fri, 28 May 93 10:56:52 CDT
Date: Fri, 28 May 93 10:56:52 CDT
From: broccol@csdsun1a.arlut.utexas.edu (Jonathan Abbey)
Message-Id: <9305281556.AA25243@csdsun1a.arlut.utexas.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server

---------  Received message begins Here  ---------

In response to:

> From sanders@bsdi.com Thu May 27 15:33:24 1993
> Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server 
> In-Reply-To: Your message of Thu, 27 May 93 14:24:29 CDT.
> Organization: Berkeley Software Design, Inc.
> Date: Thu, 27 May 1993 15:08:29 -0500
> From: Tony Sanders <sanders@bsdi.com>
> 
> My prefered scheme for selection of links in external objects is just send
> the x,y coordinates of the selection to the server and let it deal with
> it however is best.  This is how the current selection stuff works for
> <IMG ISMAP>.  This lets you backend with whatever you need (like maybe
> WAIS spatial indexing) without hardcoding anything in the client.
> 
> This scheme has the advantages of being easy on the browser, simple to
> implement, low network overhead, it fits in with the existing HTTP
> protocol (even HTTP/0.9) and it's working today:

It's easy on the browser, but devilishly difficult on the server.  With a
list of bounding rectangles for a link, it is possible for the links to be
saved in a static file along with the document they apply to, without any need
for an active process to mediate the clicks.  This way, hyperlinked images can
be stored on, e.g., ftp servers, or cached locally.  

In addition, with the bounding rectangles associated with a particular link,
the browser doesn't need to contact the server to follow a link, and it becomes
possible for the browser to provide feedback when the pointer is moved onto a link.

A list of bounding rectangles need not be onerous on the network, particularly in
comparison to the size of the images to begin with.

> The same scheme could work for any external format with a little
> cooperation from the viewer.

Ditto the bounding rectangles scheme.

A generic point and click scheme could be significantly better for things like
mathematical graphing systems, where the server can do a reverse map of the click
to a point in some transformed space.  This could be a good thing.

Perhaps we could have both systems?

Jonathan Abbey
Applied Research Laboratories
University of Texas, Austin

From fine@cis.ohio-state.edu  Fri May 28 17:48:16 1993
Return-Path: <fine@cis.ohio-state.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11981; Fri, 28 May 93 17:48:16 MET DST
Received: from soccer.cis.ohio-state.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27389; Fri, 28 May 1993 18:09:45 +0200
Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA14526; Fri, 28 May 93 12:09:42 -0400
Date: Fri, 28 May 93 12:09:42 -0400
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-Id: <9305281609.AA14526@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Is HTTP necessary??
X-Mailer: Perl Mail System v1.2


Here's one for you.  Steve and I were talking today about reading mail
and news thru xmosaic (because it's turning into the nicest MIME reader
available).  But xmosaic doesn't deal with keeping track of your
mail, or news (nor would you want it to).

So you fire up a server on your own machine, which deals with your
mail, parses your newsrc, and serves articles/email to xmosaic with
lots of things converted into links.

Let's see you do that with gopher.

	 tom


From wei@xcf.berkeley.edu  Sat May 29 01:48:09 1993
Return-Path: <wei@xcf.berkeley.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21612; Sat, 29 May 93 01:48:09 MET DST
Received: from xcf.Berkeley.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10705; Sat, 29 May 1993 02:09:39 +0200
Received: by xcf.Berkeley.EDU (5.65/XCF-1.34)
	id AA19076; Fri, 28 May 93 17:10:03 -0700
Date: Fri, 28 May 93 17:10:03 -0700
From: wei@xcf.berkeley.edu (Pei Y. Wei)
Message-Id: <9305290010.AA19076@xcf.Berkeley.EDU>
To: hoesel@chem.rug.nl, www-talk@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server

Something like ISMAP is what you'd want for applications like, say,
a cartographic service, where the user could select an area (mouseDown
for x0,y0, mouseUp for x1,y1), and have the selected area sent to the
server, which will return the image (or vectors) for the new area.
And in the future (with common availability of 3D pointing devices :-) 
this should be easily extensible to 3D-space selection. 

This sort of application would be tedious (probably impossible for 3D case)
and clumsy to implement with the area-overlay-buttons approach.

However, one could think of lots of other applications where it would 
be easier and more appropriate to use area-overlay-buttons. Just look at
the numerous HyperCard stackwares that use ``invisible fields'' to
implement highly neat effects. This approach, however hard-coded but
no more than ``HREF='' is hard-coded, has the benefits of no necessary
dependence on a server.

So, as I've indicated to Tony before off www-talk, I feel that both are
necessary and have their respective uses. In HMML (my working version 
anyway-- have to sync it with Dave), there's a FIGURE tag which could 
be used in the following ways (fictitious services):

As with <IMG>:

	<FIGURE SRC="http://smithsonian.gov/gallery/irises.gif" 
		TYPE="image/gif">

Includes a figure specific caption:

	<FIGURE SRC="http://smithsonian.gov/gallery/irises.gif" 
		TYPE="image/gif">
	  <FIGCAP>Irises, 1889, Vincent Van Gogh</FIGCAP>
	</FIGURE>

Includes the actual figure data:

	<FIGURE TYPE="application/tex">
	  <FIGDATA>
	  ...the actual TeX notation...
	  </FIGDATA>
	</FIGURE>

An example of ISMAP usage -- server generates and returns the selected
topographic region in postscript form:

	<FIGURE SRC="http://usgs.gov/maps/topographic.ps"
		TYPE="application/postscript"
		ISMAP>

An example of invisible/see-thru buttons overlaying an image -- face.gif
is visible, and has two invisible area oriented anchors pointing to 
eyes.gif and mouth.gif respectively. Probably unnecessary, but WIDTH & 
HEIGHT could be specified to handle scaling. Also, perhaps <FIGA> should
simply be <A>. :

	<FIGURE SRC="http://sesame-st.org/whatis/face.gif" TYPE="image/gif"
		WIDTH=100 HEIGHT=100>
	  <FIGA HREF="http://sesame-st.org/whatis/eyes.gif" TYPE="image/gif"
		x0=20 y0=10 x1=80 y1=30>
	  <FIGA HREF="http://sesame-st.org/whatis/mouth.gif" TYPE="image/gif"
		x0=40 y0=70 x1=60 y1=80>
	  <FIGCAP>Spy a face</FIGCAP>
	</FIGURE>


I would, and I'm sure Dave would, appreciate constructive arguments 
for or against <FIGURE> as described above. It's of course still very 
open to suggestions at this point.


Pei Y. Wei
O'Reilly & Associates
Digital Media Group
pei@ora.com

From marca@wintermute.ncsa.uiuc.edu  Sat May 29 02:57:21 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22237; Sat, 29 May 93 02:57:21 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27790; Sat, 29 May 1993 03:18:51 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA17572
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 28 May 93 20:23:36 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:hoesel@chem.rug.nl id AA14188; Fri, 28 May 93 20:21:18 -0500
Date: Fri, 28 May 93 20:21:18 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305290121.AA14188@wintermute.ncsa.uiuc.edu>
To: wei@xcf.berkeley.edu (Pei Y. Wei)
Cc: hoesel@chem.rug.nl, www-talk@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
In-Reply-To: <9305290010.AA19076@xcf.Berkeley.EDU>
References: <9305290010.AA19076@xcf.Berkeley.EDU>
X-Md4-Signature: 9c6ff689c25e9ed2469e65a92de102db

Pei Y. Wei writes:
> However, one could think of lots of other applications where it would 
> be easier and more appropriate to use area-overlay-buttons. Just look at
> the numerous HyperCard stackwares that use ``invisible fields'' to
> implement highly neat effects. This approach, however hard-coded but
> no more than ``HREF='' is hard-coded, has the benefits of no necessary
> dependence on a server.

I agree.

> An example of invisible/see-thru buttons overlaying an image -- face.gif
> is visible, and has two invisible area oriented anchors pointing to 
> eyes.gif and mouth.gif respectively. Probably unnecessary, but WIDTH & 
> HEIGHT could be specified to handle scaling. Also, perhaps <FIGA> should
> simply be <A>. :
> 
> 	<FIGURE SRC="http://sesame-st.org/whatis/face.gif" TYPE="image/gif"
> 		WIDTH=100 HEIGHT=100>
> 	  <FIGA HREF="http://sesame-st.org/whatis/eyes.gif" TYPE="image/gif"
> 		x0=20 y0=10 x1=80 y1=30>
> 	  <FIGA HREF="http://sesame-st.org/whatis/mouth.gif" TYPE="image/gif"
> 		x0=40 y0=70 x1=60 y1=80>
> 	  <FIGCAP>Spy a face</FIGCAP>
> 	</FIGURE>

Looks good to me.  Two comments: my gut feeling is that coordinates
should be in pixel space, and that if the browser scales the image it
should readjust any transmitted coordinates to match when the user
actually selects something.  And, I think it should be possible
to specify more than one rectangle per "FIGA" (e.g...

 	  <FIGA HREF="http://sesame-st.org/whatis/mouth.gif" TYPE="image/gif"
 		COORDS="40-60,70-80;90-100,120-130">

...or something similar).

Cheers,
Marc


From hoesel@chem.rug.nl  Sat May 29 14:27:37 1993
Return-Path: <hoesel@chem.rug.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25307; Sat, 29 May 93 14:27:37 MET DST
Received: from rugch4.chem.rug.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23808; Sat, 29 May 1993 14:49:08 +0200
Received: from rugnm6.chem.rug.nl by rugch4.chem.rug.nl with SMTP
	(16.8/16.2) id AA03487; Sat, 29 May 93 14:47:08 +0200
Received: from Xtreme.chem.rug.nl by rugnm6.chem.rug.nl via SMTP (920330.SGI/920922.WK)
	for @rugch4.chem.rug.nl:www-talk@nxoc01.cern.ch id AA17283; Sat, 29 May 93 14:54:20 GMT
Received: by Xtreme (920330.SGI/920502.SGI)
	for @rugch4.chem.rug.nl:www-talk@nxoc01.cern.ch id AA00471; Sat, 29 May 93 14:51:03 +0200
From: hoesel@chem.rug.nl (frans van hoesel)
Message-Id: <9305291251.AA00471@Xtreme>
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
To: www-talk@nxoc01.cern.ch
Date: Sat, 29 May 1993 14:51:02 +0100 (MDT)
In-Reply-To: <9305290121.AA14188@wintermute.ncsa.uiuc.edu> from "Marc Andreessen" at May 28, 93 08:21:18 pm
X-Mailer: ELM [version 2.4 PL5]
Content-Type: text
Content-Length: 2339      

Marc wrote:
> 
> Pei Y. Wei writes:
> > However, one could think of lots of other applications where it would 
> > be easier and more appropriate to use area-overlay-buttons. Just look at
> > the numerous HyperCard stackwares that use ``invisible fields'' to
> > implement highly neat effects. This approach, however hard-coded but
> > no more than ``HREF='' is hard-coded, has the benefits of no necessary
> > dependence on a server.
> 
> I agree.
> 

So do I (for what it's worth)

> > An example of invisible/see-thru buttons overlaying an image -- face.gif
> > is visible, and has two invisible area oriented anchors pointing to 
> > eyes.gif and mouth.gif respectively. Probably unnecessary, but WIDTH & 
> > HEIGHT could be specified to handle scaling. Also, perhaps <FIGA> should
> > simply be <A>. :
> > 
> > 	<FIGURE SRC="http://sesame-st.org/whatis/face.gif" TYPE="image/gif"
> > 		WIDTH=100 HEIGHT=100>
> > 	  <FIGA HREF="http://sesame-st.org/whatis/eyes.gif" TYPE="image/gif"
> > 		x0=20 y0=10 x1=80 y1=30>
> > 	  <FIGA HREF="http://sesame-st.org/whatis/mouth.gif" TYPE="image/gif"
> > 		x0=40 y0=70 x1=60 y1=80>
> > 	  <FIGCAP>Spy a face</FIGCAP>
> > 	</FIGURE>
> 
> Looks good to me.  Two comments: my gut feeling is that coordinates
> should be in pixel space, and that if the browser scales the image it
> should readjust any transmitted coordinates to match when the user
> actually selects something.  And, I think it should be possible
> to specify more than one rectangle per "FIGA" (e.g...
> 
>  	  <FIGA HREF="http://sesame-st.org/whatis/mouth.gif" TYPE="image/gif"
>  		COORDS="40-60,70-80;90-100,120-130">
> 
> ...or something similar).
> 

And if you could add a keyword like TRANSPARENT=0 to specifiy that the
color with index 0 should be transparent I would be even more happy.

This would allow very easy creation of a HREF that is *exactly* only to
mouth and not some collection of rectangles!!!!!

And it's easy for the server too: only one rectangle (the size of the image)
and it only needs a check for the color, if it is not the transparant color,
then follow the link.

It also allows for non-rectangular images inside a document (allthough the
bounding box would be rectangular.

Alternatively, one could send a simple b/w image to specify the
mouth *exactly* and don't use transparant at all

- frans




From marca@wintermute.ncsa.uiuc.edu  Sun May 30 12:46:00 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02528; Sun, 30 May 93 12:46:00 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02979; Sun, 30 May 1993 13:07:31 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16366
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 30 May 93 06:05:37 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:kell@seq1.loc.gov id AA20745; Sun, 30 May 93 06:08:08 -0500
Date: Sun, 30 May 93 06:08:08 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9305301108.AA20745@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: kell@seq1.loc.gov, gwe3409@atc.boeing.com, vincenti@zodiac.rutgers.edu,
        john.ockerbloom@gs1.sp.cs.cmu.edu, roger.hayes@east.sun.com,
        hoesel@chem.rug.nl, harmo@valt.helsinki.fi
Subject: Vatican Library interface
X-Md4-Signature: 2d86186b1e1e2f934198a6f89629da53

I've done some tweaking to the Vatican Library interface we're serving
from www.ncsa.uiuc.edu (originally by Frans van Hoesel with
contributions by John Ockerbloom); the changes include...

  o All images referenced by the interface are now served via http 
    from www.ncsa.uiuc.edu, not via ftp from seq1.loc.gov.
  o All images are now in GIF format (full 256-color, same size).
  o Some tweaks to the exhibit text for readability, typos, etc.

The goal of the changes was to increase performance at the client end.
I am also considering reducing the size of all the images to 1280x1024
or less, since xv is not fast at scaling images down to size.

Also, I see LOC is in the process of putting up a 1492 exhibit on
seq1.loc.gov, and that the old Soviet archive is still sitting there
waiting for a hypermedia interface (hint hint hint :-).

Finally, if you didn't catch it the first time around, the URL for the
interface we're serving is...

http://www.ncsa.uiuc.edu/SDG/Experimental/vatican.exhibit/Vatican.exhibit.html

Enjoy,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Tue Jun  1 04:37:56 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20440; Tue, 1 Jun 93 04:37:56 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10275; Tue, 1 Jun 1993 04:59:33 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24806
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 31 May 93 21:59:32 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA25749; Mon, 31 May 93 22:02:09 -0500
Date: Mon, 31 May 93 22:02:09 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306010302.AA25749@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: ebina@ncsa.uiuc.edu
Subject: Mosaic 1.1 prerelease available for testing
X-Md4-Signature: 5d415bc5cfd95e49a3b69f9772d9abf1

Any sucker^H^H^H^H^H^H fine upstanding person out there in netland who
wants to have a go at a prerelease of NCSA Mosaic for X version 1.1
can pick it up thusly:

file://ftp.ncsa.uiuc.edu/Mosaic/beta/xmosaic-1.1-pre1.tar.Z
                                 .../xmosaic-sun.Z
                                 .../xmosaic-sun-lresolv.Z
                                 .../xmosaic-sgi.Z
                                 .../xmosaic-ibm.Z

Assuming I haven't broken anything while compiling and packaging up
the release over a 2400-baud line from a Mac, all known bugs are fixed
and no new ones are introduced.  Comments and bug reports to
mosaic-x@ncsa.uiuc.edu will be gratefully accepted.

See http://www.ncsa.uiuc.edu/SDG/Mosaic/Docs/help-on-version-1.1.html
for a list of changes since version 1.0.

Thanks in advance for any feedback,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From marca@wintermute.ncsa.uiuc.edu  Tue Jun  1 05:16:54 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20978; Tue, 1 Jun 93 05:16:54 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14160; Tue, 1 Jun 1993 05:38:31 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA26802
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 31 May 93 22:38:29 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA26004; Mon, 31 May 93 22:41:06 -0500
Date: Mon, 31 May 93 22:41:06 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306010341.AA26004@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: group annotation server guinea pigs?
X-Md4-Signature: 44c0b08ffdb1de4f5152ed728875978a

We could use a few guinea pigs to try out our in-progress group
annotation server for Mosaic.  If you're interested, please let me
know.

The current group annotation support is very simple (one group per
group annotation server, one group annotation server per Mosaic
session, no security except through obscurity), since it's mostly a
proof of concept, but it does work and Mosaic 1.1 has built-in
client-side support.

Suggestions as to future functionality and user interface components
for same are welcome.

(How it works: every time you access a document in Mosaic, the group
annotation server [if you're using one] is queried with the URL of the
document you're viewing; if any group annotations exist for that
document, the group annotation server returns to Mosaic corresponding
hyperlinks which are inlined into the document just like personal
annotations.  So the assumption is that you've got a fast local net
and group annotation server host.  In the Mosaic Annotate and Audio
Annotate window there are option menus that let you select 'Personal'
or 'Workgroup' each time you make an annotation; for the latter,
Mosaic sends the annotation over a socket to the group annotation
server.)

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Tue Jun  1 13:00:39 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24745; Tue, 1 Jun 93 13:00:39 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17527; Tue, 1 Jun 1993 13:22:15 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00732; Tue, 1 Jun 93 13:14:39 +0100
Date: Tue, 1 Jun 93 13:14:39 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306011214.AA00732@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: wei@xcf.berkeley.edu (Pei Y. Wei)
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
Cc: hoesel@chem.rug.nl, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



On ISMAP vs Figure Anchors.
==========================

I agree that bot the ISMAP technique of returning coordinates to a  
server, and the FIGA (HMML) technique of overlaying anchors on
pictures have uses.  I feel that in fact their application areas
are quite separate.

It would be infuriating to have a ISMAP server which had some
areas selectable and others not, where you got back an error
message if you clicked in the wrong place.  But on the other hand,
a good cyberspace web will have nodes on which you can click anywhere
to change your point of view.

So let's specify both. Now for protocols.

	PLEASE KEEP OTHER INFO OUT OF LINKS

The ISMAP attribute has the problem that
it includes information in the link which ought to be
sent from the server when the map is retrieved.  I would
suggest a methodname "SPACEJUMP" say in the Allowed: return
field.  This allows the server to tag things as spacejumpable
however you ahve got to them.  If for example you convert
a URN ionto a URL and retrieve the document, then you get
a spacejumpable version.  If you have a graphics machine.
Some documents may become spacejumpable.  Having to put information
like that in the links is bad because

1.	It is duplication of information which implies
	incorrect information.

2.	It may change with time.

3.	It may be a function of client and server
	capabilities.
	
The same applied to the "type=immage/gif" which has been
suggested and Pei mentioned.  PLEASE DON"T put type information
into the link!  PLEASE use the full protcocol, using the libwww
or otherwise.

	Scale coordinates please
	
I would point out too that we can forsee smart servers which will
for example, as a function of the client, automatically generate or  
select
a 800*600 GIF to send instead of a 1200*1000 JPEG.  This will make
transfers onto low-res and/or low-bandwidth clients much faster.
It will be completely automatic. It means that ISMAP coordinates
should be scaled to say 0 - 1.0 in the size of the picture,
as pixels won't have much meaning.  Same applies of course anyway
to postscript pictures which have no concept of pixel size.


There's my 2c for today.

	Tim

From ccprl@xdm001.ccc.cranfield.ac.uk  Tue Jun  1 13:08:50 1993
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24838; Tue, 1 Jun 93 13:08:50 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18525; Tue, 1 Jun 1993 13:30:25 +0200
Received: by xdm001 
	id AA28525; Tue, 1 Jun 93 12:30:18 +0100
Received: by xdm039 (5.57/4.7) id AA12120; Tue, 1 Jun 93 12:30:14 +0100
Message-Id: <9306011130.AA12120@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Line breaks and multibody douments
In-Reply-To: Your message of "Wed, 26 May 93 17:23:17 BST."
             <9305261623.AA05834@xdm001> 
Date: Tue, 01 Jun 93 12:30:12 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

Well, I knew everyone would disagree with me. Thank you for doing so politely.

I'd like to make it clear that I do *NOT* suggest line breaks and / or
page breaks to annoy people, nor because I have a specific interest in
poetry (though I do). Dave Raggett suggested a <poem> tag, and as I saw
no smiley, I assume he was at least semi-serious. IMHO, the idea sucks.
T V Raman made a similar comment about representing the high-level
structure of a poems, but I would claim that that is not the business of HTML.

The general philsophy is to be "Keep HTML minimal". I agree, and concur
with the idea of embedding e.g. GIF and TeX. You are right, Dave, that
HTML must not be all things to all men. I would add "or anyone for that
matter". So - let us maintain the high-level representations of our
docs (e.g. poetry) in our authoring systems, and then PUBLISH them as
HTML. Some poetry is published on e.g. audio tape, but the vast
majority is published on paper and obeys the conventions of line
breaks, verse breaks, page breaks etc, even though the author may
COMPOSE it in very different terms that just don't come across when
reading it. My feeling is that HTML should provide low-level PUBLISHING
functions, but not aetherial concepts or <poem> tags.

My best suggestion is an argument to <pre> ; e.g. <pre monofont> and
<pre normalfont>. Or maybe <pre style="em">, where the style argument
can be any valid text style tag or "plain"? This allows me to separate
the lines of my address (or poem) properly, introduces no extra tags,
and <pre> with no argument can default to the normal meaning of
"monospaced, to suit a listing or programming example".

OK, on to "page breaks". Or since, this kind of terminology seems to
offend people, may I suggest "multibody files"? It occurs to me that a
special "page break" tag is unneccesary. All we need is a well
established method of handling multiple <body></body> pairs in one file.

* Browsers can search across a whole set of short bodies
* Browsers don't have to try to whack the whole of an enormous file onto a text 
  widget. XMosaic already has to break large files into "pages", so it seems 
  like a good idea to make the "pages" more logical.
* Most authors and (the tools they use) consider multiple chapters of one 
  document to logically belong in one file.
* Most readers don't read large documents from page one and progress to the end

An obvious example is a technical manual or a Usenet FAQ. All I want to
see is the index and/or table of contents, then the chapter or section
which answers my question. I don't want to wait for vast quantities of
gunk to be mapped into a window ESPECIALLY if it contains inlined
images (e.g. the Vatican library document index). Just show me the
section which is relevent. OK, if I then want to browse down the index,
fine, but let it be my choice.

It's possible that these things are solved better by Dave Raggett's
html2 DTD, but I can't get to hplose.hpl.hp.com. Care to give us the IP
address while your netbods set up the name, Dave?

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From dsr@hplb.hpl.hp.com  Tue Jun  1 18:30:44 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00536; Tue, 1 Jun 93 18:30:44 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27859; Tue, 1 Jun 1993 18:52:21 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA03259 (5.65b/CWI-2.220); Tue, 1 Jun 1993 18:52:12 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 1 Jun 93 15:22:39 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA10286; Tue, 1 Jun 93 15:28:21 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306011428.AA10286@manuel.hpl.hp.com>
Subject: Re  STRONG, B, I, and U
To: janssen@parc.xerox.com
Date: Tue, 1 Jun 93 15:28:20 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

>> I don't like them either. They are present in HTML to support
>> importing (scanned) documents for which a filter has no way of deciding
>> the original meaning.

> This justification doesn't sound terribly good.  If we can't infer the
> meaning of the font changes, perhaps translating the scanned document to
> HTML is inappropriate; perhaps the scanned document should be stored in
> TeX or Postscript or GIF, depending on what other image characteristics
> of the document seem important.  Or perhaps the font change information
> should simply be discarded on conversion to HTML, as it does not
> translate to meaning.

I think this is perhaps a bit extreme, and in practice most people would
prefer some preservation of italic emphasis etc.  (an empirical question)

> Or perhaps the right way to think of these is to apply the output rules,
> in reverse.  That is, the user can specify how <EMPH> is to be formatted
> on output; similarly, perhaps the user could specify how bold font is to
> be interpreted on input.

Perhaps we ought to use <EMPH> for all inline emphasis! This gets around
the problem in dealing with every growing categories for different needs.
You then would see elements like:

        <EMPH tag="author">H. G. Wells</EMPH>

The Web could then have an evolving set of well known categories.
Unrecognised categories would simply be ignored by the browser. Users
would also be able to change how the browser renders each category.

Dave Raggett

From dsr@hplb.hpl.hp.com  Tue Jun  1 18:34:07 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00627; Tue, 1 Jun 93 18:34:07 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28075; Tue, 1 Jun 1993 18:55:43 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA03410 (5.65b/CWI-2.220); Tue, 1 Jun 1993 18:55:31 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 1 Jun 93 15:09:20 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA10274; Tue, 1 Jun 93 15:15:03 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306011415.AA10274@manuel.hpl.hp.com>
Subject: Re: RE dtd2.html
To: dale@ora.com
Date: Tue, 1 Jun 93 15:15:01 BST
Cc: terry@ora.com, www-talk@nxoc01.cern.ch, timbl@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> I agree that flyleaf sounds like a bad idea.  In fact,
> Dave's navigational steps that lead to choosing a book
> in a bookstore is not a good guide to describing the
> logical structure of the information.  As Tim says,
> Summary or Abstract describes adequately what the information
> means; how it used or arranged are aspects of application,
> whether defined in the app interface, style sheet or user's
> navigational actions. 

Thanks for the comments everyone. I am now considering how
to represent the structure in a more abstract manner using
attributes to carry has-part, has-property information.
This would allow generic markup to support evolving structures
for books, magazines and cyber-docs!

Thanks in particular to Tim for pointing me in this direction.
I hope to come back with some more details soon.

Best wishes,

Dave Raggett

From dsr@hplb.hpl.hp.com  Tue Jun  1 18:36:12 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00687; Tue, 1 Jun 93 18:36:12 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28238; Tue, 1 Jun 1993 18:57:48 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA03506 (5.65b/CWI-2.220); Tue, 1 Jun 1993 18:57:42 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 1 Jun 93 15:32:46 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA10450; Tue, 1 Jun 93 15:38:28 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306011438.AA10450@manuel.hpl.hp.com>
Subject: <IMG> and ISMAP (again)
To: sanders@bsdi.com
Date: Tue, 1 Jun 93 15:38:27 BST
Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> My prefered scheme for selection of links in external objects is just send
> the x,y coordinates of the selection to the server and let it deal with
> it however is best.  This is how the current selection stuff works for
> <IMG ISMAP>.  This lets you backend with whatever you need (like maybe
> WAIS spatial indexing) without hardcoding anything in the client.

> This scheme has the advantages of being easy on the browser, simple to
> implement, low network overhead, it fits in with the existing HTTP
> protocol (even HTTP/0.9) and it's working today:

Just when I thought we had settled the matter!

Tim BL reminded me on the phone why this approach can't work in general.
Pixels only make sense for image data NOT for drawings, equations etc.
This means that we really do have to consider scaling the mouse click
coordinates. Tim suggests we use real numbers with 0 to 1.0 for each
axis (assuming square borders) with the upper left as (0, 0).

Dave Raggett

From dsr@hplb.hpl.hp.com  Tue Jun  1 18:38:48 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00737; Tue, 1 Jun 93 18:38:48 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28426; Tue, 1 Jun 1993 19:00:24 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA03501 (5.65b/CWI-2.220); Tue, 1 Jun 1993 18:57:31 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 1 Jun 93 14:30:37 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA03048; Tue, 1 Jun 93 14:36:21 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306011336.AA03048@manuel.hpl.hp.com>
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
To: murphy@dccs.upenn.edu
Date: Tue, 1 Jun 93 14:36:19 BST
Cc: www-talk@nxoc01.cern.ch, litwack@dccs.upenn.edu
Mailer: Elm [revision: 66.36.1.1]

Many thanks for your comments on embedding foreign formats in HTML.
(Message-Id: <9305271346.AA03278@lam.dccs.upenn.edu>, Thu, 27 May)

> So for example, the client could send a list of pre-defined formats to
> the server (e.g. IMG, TeX, PostScript, etc), and then the server can
> choose among different formats of the same item embedded in the
> document to give the client what it can handle.  Sometimes, the server
> might not be able to convert the one of the things that the client
> (browser) can deal with, and then it's up to the browser to display an
> intelligent message about it, perhaps even giving the user information
> so he can find software for his desktop environment which DOES deal
> with that format.

...

The new version of HTTP (HTRQ/V1.0) does indeed specify how clients
can signal the server which formats they can support, although I don't
know of anyone using this facility as yet.

The use of separate viewers works but is somewhat clumsy right now.
I like the way that Windows on the PC supports runtime linking
with DLLs. This allows applications to load support for particular
formats only when it is needed, and to unload it afterwards.

A simple route forward for the Unix environment would be to write
stdin/stdout filters which output bitmaps (pixmaps). Maybe we can get
people to sign up to write some public domain filters for common
formats. Browsers could then accommodate new formats by mapping the
format name to the filter (with command line arguments for attributes).

The next choice is whether HTML should permit embedded data directly as part
of the document itself. A well defined escaping mechanism would permit
both ascii and binary data: e.g.

    <embed type="text/eqn">X = sum from 1 to N of 1/Y^N</embed>

The simplest approach is to escape the "<" character, e.g. by inserting
a "\" character before any "<" character that occurs in the data (you
would also need to insert "\" before any occurrence of "\" itself).

Servers could still support format negotiation, sending different versions
of the document as appropriate.


What do you think?

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From dsr@hplb.hpl.hp.com  Tue Jun  1 18:41:37 1993
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00834; Tue, 1 Jun 93 18:41:37 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28625; Tue, 1 Jun 1993 19:03:12 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA03706 (5.65b/CWI-2.220); Tue, 1 Jun 1993 19:02:54 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 1 Jun 93 15:00:15 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA10262; Tue, 1 Jun 93 15:05:54 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306011405.AA10262@manuel.hpl.hp.com>
Subject: Re: More than just HTML (was Re: Poetry and Maths)
To: eitech!weber@dxmint.cern.ch
Date: Tue, 1 Jun 93 15:05:53 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

>> The embedded data can
>> be sent along with the main document using MIME's multipart capability.

> How do you plan on doing this in HTML+?  Sounds like the first part
> will be text/html, where the anchors reference other parts.  The reference
> can be done by defining a URL access type of "part", e.g. HREF=part:XXX
> where XXX is a Content-id.

I think that the HREFs should use the standard URL for the document, and the
MIME subheader for the image (or whatever) should include a field specifying
the URL for the subpart, e.g.

        Source: http://info.cern.ch/hyptext/WWW/lep.jpg

The current spec for the HTTP doesn't give a suitable field, although
Message-id is a near miss (defined according to RFC 850). I don't like the
idea of HREF=part:XXX etc. as this means you couldn't send the main document
by itself.

I would also like a try out simple approach to embed foreign data directly,
as this would much more convenient for inline equations etc.

Regards,

Dave Raggett

From weber@eitech.com  Tue Jun  1 19:39:15 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02131; Tue, 1 Jun 93 19:39:15 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13237; Tue, 1 Jun 1993 19:59:22 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA23480; Tue, 1 Jun 93 12:58:05 -0500
Received: from bd.eitech.com ([192.100.58.27]) by eitech.com (4.1/SMI-4.1)
	id AA05255; Tue, 1 Jun 93 10:52:37 PDT
Message-Id: <9306011752.AA05255@eitech.com>
X-Sender: weber@eitech
Date: Tue, 01 Jun 1993 10:58:22 -0800
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
From: weber@eitech.com (Jay Weber)
Subject: Re: More than just HTML (was Re: Poetry and Maths)
Cc: www-talk@nxoc01.cern.ch
X-Mailer: <PC Eudora Version 1.1a5>

At 03:05 PM 6/1/93 BST, Dave_Raggett wrote:
>>> The embedded data can
>>> be sent along with the main document using MIME's multipart capability.
>
>> How do you plan on doing this in HTML+?  Sounds like the first part
>> will be text/html, where the anchors reference other parts.  The reference
>> can be done by defining a URL access type of "part", e.g. HREF=part:XXX
>> where XXX is a Content-id.
>
>I think that the HREFs should use the standard URL for the document, and the
>MIME subheader for the image (or whatever) should include a field specifying
>the URL for the subpart, e.g.
>
>        Source: http://info.cern.ch/hyptext/WWW/lep.jpg

Good idea, this is much better than a "part" access type.

>The current spec for the HTTP doesn't give a suitable field, although
>Message-id is a near miss (defined according to RFC 850).

Is it a near-miss because of special characters?  I.e., the content-id
of a part uses the same syntax as a message-id, which must be

   "<" local-part "@" domain ">"

The local-part is just a dot-separated series of words which must be
unique for that domain.  So if the entire content-id is not suitable
as a field in an URL, we can just use the local-part; it will still
be straightforward for the server to resolve which MIME-part is being
addressed.

Jay Weber
EIT


From janssen@parc.xerox.com  Tue Jun  1 20:17:55 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02958; Tue, 1 Jun 93 20:17:55 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24727; Tue, 1 Jun 1993 20:39:33 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11934>; Tue, 1 Jun 1993 11:39:11 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 1 Jun 1993 11:38:56 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue,  1 Jun 1993 11:38:52 -0700 (PDT)
Message-Id: <og2u8w8B0KGWI_JhA9@holmes.parc.xerox.com>
Date: 	Tue, 1 Jun 1993 11:38:52 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: wei@xcf.berkeley.edu (Pei Y. Wei), timbl@nxoc01.cern.ch
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
Cc: hoesel@chem.rug.nl, www-talk@nxoc01.cern.ch
In-Reply-To: <9306011214.AA00732@www3.cern.ch>
References: <9306011214.AA00732@www3.cern.ch>

Excerpts from ext.WorldWideWeb: 1-Jun-93 Re: Keeping HTML Simple & F..
Tim Berners-Lee@www3.cer (2157)

> ISMAP coordinates
> should be scaled to say 0 - 1.0 in the size of the picture,

Excellent point.

Bill

From janssen@parc.xerox.com  Tue Jun  1 20:45:37 1993
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03599; Tue, 1 Jun 93 20:45:37 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00622; Tue, 1 Jun 1993 21:07:14 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11968>; Tue, 1 Jun 1993 12:06:54 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 1 Jun 1993 12:06:48 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue,  1 Jun 1993 12:06:34 -0700 (PDT)
Message-Id: <og2uWusB0KGW8_JVJL@holmes.parc.xerox.com>
Date: 	Tue, 1 Jun 1993 12:06:34 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: janssen@parc.xerox.com, Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: Re STRONG, B, I, and U
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306011428.AA10286@manuel.hpl.hp.com>
References: <9306011428.AA10286@manuel.hpl.hp.com>

Excerpts from ext.WorldWideWeb: 1-Jun-93 Re STRONG, B, I, and U
Dave_Raggett@hplb.hpl.hp (1477)

> I think this is perhaps a bit extreme, and in practice most people would
> prefer some preservation of italic emphasis etc.  (an empirical question)

I agree.  My only point is that the markup format which preserves such
italic emphasis should not be HTML, it should be something else, perhaps
Adobe Acrobat (or whatever they've renamed it to).

> Perhaps we ought to use <EMPH> for all inline emphasis! This gets around
> the problem in dealing with every growing categories for different needs.
> You then would see elements like:

>         <EMPH tag="author">H. G. Wells</EMPH>

> The Web could then have an evolving set of well known categories.
> Unrecognised categories would simply be ignored by the browser. Users
> would also be able to change how the browser renders each category.

I think I see a smiley here, but it's not such a silly idea.  I've been
working on something similar, a procedural markup scheme in which the
reason for the markup occurs along with the markup.

Bill


From weber@eitech.com  Tue Jun  1 21:37:30 1993
Return-Path: <weber@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04634; Tue, 1 Jun 93 21:37:30 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18307; Tue, 1 Jun 1993 21:59:02 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA25050; Tue, 1 Jun 93 14:57:47 -0500
Received: from bd.eitech.com ([192.100.58.27]) by eitech.com (4.1/SMI-4.1)
	id AA05939; Tue, 1 Jun 93 12:53:47 PDT
Message-Id: <9306011953.AA05939@eitech.com>
X-Sender: weber@eitech
Date: Tue, 01 Jun 1993 12:59:32 -0800
To: www-talk@nxoc01.cern.ch
From: weber@eitech.com (Jay Weber)
Subject: HTTP ACCEPT field and MIME types
X-Mailer: <PC Eudora Version 1.1a5>

I was looking through a draft HTTP 2.0 spec (may be as old as 7-Dec-92)
and noticed a potential problem with the ACCEPT request field.  One puts
a comma-separated list of MIME types as the field value.  The problem is
that MIME types can involve parameters, and some parameters may be
crucial to a client's acceptance of the type.  For example, an old
example from the MIME spec is:

                 Content-Type:  application/octet-stream;
                      name=foo.tar.Z; type=tar;
                      conversions="x-encrypt,x-compress"

This example is extreme, since application/octet-stream is usually a
no-brainer for clients, but the presence of these parameters makes it
pretty UNIX specific.  You can image other examples, such as a "lossiness"
parameter on image/jpeg, that would impact portability of the type.

Anyway, if we include parameters in MIME typing, then a comma-separated
syntax doesn't work too well.  An easy fix would be to allow multiple
ACCEPT fields in the header, with one MIME type per field.  I don't see
an HTTP stance on multiple fields, and this treatment of multiple
fields would be consistent with RFC 822 (the To: field, for example).
How about it (Tim)?

In general, HTTP 2.0 is pretty cool.  Is an RFC coming soon (or here)?

Jay Weber
EIT


From marca@wintermute.ncsa.uiuc.edu  Wed Jun  2 10:09:49 1993
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12801; Wed, 2 Jun 93 10:09:49 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15978; Wed, 2 Jun 1993 10:31:27 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA21654
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 2 Jun 93 03:31:24 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA00685; Wed, 2 Jun 93 03:33:58 -0500
Date: Wed, 2 Jun 93 03:33:58 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306020833.AA00685@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: mosaic-x@ncsa.uiuc.edu
Subject: Mosaic 1.1 prerelease 2 available for testing
X-Md4-Signature: 62eb5fb5909426350544bfe42a8e8cc0

Brave souls can try out Mosaic 1.1, prerelease 2...

file://ftp.ncsa.uiuc.edu/Mosaic/beta/xmosaic-1.1-pre2.tar.Z
                                 .../xmosaic-sun.Z
                                 .../xmosaic-sun-lresolv.Z
                                 .../xmosaic-sgi.Z
                                 .../xmosaic-ibm.Z

A few things have been tweaked since prerelease 1, and everything
seems solid.  If no new bug reports come in, this will become the
actual 1.1 release.

See http://www.ncsa.uiuc.edu/SDG/Mosaic/Docs/help-on-version-1.1.html
for a list of changes since version 1.0.

Thanks much in advance for any feedback,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From timbl@www3.cern.ch  Wed Jun  2 11:55:54 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13858; Wed, 2 Jun 93 11:55:54 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10153; Wed, 2 Jun 1993 12:17:33 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01270; Wed, 2 Jun 93 12:09:55 +0100
Date: Wed, 2 Jun 93 12:09:55 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306021109.AA01270@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
Cc: murphy@dccs.upenn.edu, www-talk@nxoc01.cern.ch, litwack@dccs.upenn.edu
Reply-To: timbl@nxoc01.cern.ch


> From: Dave_Raggett <dsr@hplb.hpl.hp.com>
> Date: Tue, 1 Jun 93 14:36:19 BST

> > So for example, the client could send a list of pre-defined  
formats to
> > the server (e.g. IMG, TeX, PostScript, etc), and then the server  
can
> > choose among different formats of the same item embedded in the
> > document to give the client what it can handle.
> ...

> The new version of HTTP (HTRQ/V1.0) does indeed specify how clients
> can signal the server which formats they can support, although I  
don't
> know of anyone using this facility as yet.

	The httpd server 2.0 and above and all browsers using the www
	library 2.0 and above support this feature.  The server
	at CERN for example supports it.  If you run the www
	line mode brwser even with DISPLAY set to point to an
	X display it will launch ghostview or xv.  So will (I
	suppose) tkWWW for example.  XMosaic doesn't do it but will
	one day, when a lot of confusion will cease.
	
	On the server side, in the current implementation, the
	dummy suffix ".multi" means "Whatever file of this name
	and any suffix which I can handle and you think best".
	
	There are a few examples in the test file
	http://info.cern.ch/hypertext/WWW/Test/Overview.html
	
	Tim Berners-Lee

From timbl@www3.cern.ch  Wed Jun  2 14:22:53 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15758; Wed, 2 Jun 93 14:22:53 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13095; Wed, 2 Jun 1993 14:44:32 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01357; Wed, 2 Jun 93 14:37:05 +0100
Date: Wed, 2 Jun 93 14:37:05 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306021337.AA01357@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: HTML+ DTD in ftp://info.cern.ch/pub/www/dev/htmlplus.dtd
Reply-To: timbl@nxoc01.cern.ch


From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Date: Wed, 2 Jun 93 13:01:14 BST

Hi Tim,

I have uploaded the latest copy of my DTD for HTML+ into
[tbl moved it into:]

    "ftp://info.cern.ch/pub/www/dev/htmlplus.dtd"


The new DTD reflects recent discussions:

    o   One tag for all inline emphasis
    o   FIG tag similar to Pei's (but no TYPE attribute)
    o   EMBED tag for foreign data (simple equations etc.)
    o   DL lists extended for tables with optional hints
    o   INPUT and SELECT form interaction elements

I don't know how in SGML to specify a tag which may or may not
have an endtag depending on its attribute values. Because of
this I have used two tags for images:

[I think (hope?) that this it is impossible to change
 the EMPTY charactistic of an element as a function of the
 attributes.  Would severly complicate parsing -Tim]
 

    a)  <FIG> ...</FIG> for captioned images
    b)  <ICON> for small inline graphics without captions

[...]

Cheers,

Dave Raggett


From terry@ora.com  Wed Jun  2 18:00:48 1993
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19857; Wed, 2 Jun 93 18:00:48 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07849; Wed, 2 Jun 1993 18:22:25 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA16660; Wed, 2 Jun 1993 12:22:17 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA27852; Wed, 2 Jun 1993 09:22:15 -0700
Message-Id: <199306021622.AA27852@ora.com>
From: Terry Allen <terry@ora.com>
Date: Wed, 2 Jun 1993 09:22:15 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: RE htmlplus.dtd of 1 June

Thanks to Dave Raggett for making this available.  It is 
shaping up nicely.  A few comments:

PANEL is like a Sidebar; it floats, as FIGs may.  It seedms
to me that there needs to be a default anchor point (not
the ANCHOR element, necessarily, just an anchor) for floats,
such that one can say the object may be placed at that point
or after, but not before.  

The same issue of anchor points pertains to <P MARGIN>, a
marginal note.  Unless these have anchors in the text to
which they pertain, they can be placed only by sticking them
right into that text.  This is how I do my footnotes in Tex,
but it isn't the clearest thing to read when you look at the
file.  

I am confused by INPUT and the remark that it goes to make
up Forms.  Would someone please give an example of usage?

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From timbl@www3.cern.ch  Wed Jun  2 18:02:23 1993
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19897; Wed, 2 Jun 93 18:02:23 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08157; Wed, 2 Jun 1993 18:24:03 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01622; Wed, 2 Jun 93 18:16:33 +0100
Date: Wed, 2 Jun 93 18:16:33 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306021716.AA01622@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: weber@eitech.com (Jay Weber)
Subject: Re: HTTP ACCEPT field and MIME types
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

Jay,

A good point about the commas in the Accept: field.  I hadn't noticed  
that MIME qualified the type with parameters sometimes.  It seems  
there is something strange in the example you give

                 Content-Type:  application/octet-stream;
                      name=foo.tar.Z; type=tar;
                      conversions="x-encrypt,x-compress"

that means that the MIME typing isn't coping -- in particular here  
the content-encoding field isn't coping.

There are several TBC areas in the latest version (any version) which
need to be filled in before its an RFC.  (An ID first maybe). And  
there must of course be working implementations. The libwww uses
the Accept: field. It in fact sends one field per content-type.
It's not obvious how to distinguish between w3 parameters and MIME
parameters to a type.  Maybe we don't have to.

request:
	Accept: image/gif; q=0.8; width=1200; height=100; colous=256;
response:
	Content-Type: image/gif; width=800; height=400; colours=10;
	
Tim

	

From cja@castle.edinburgh.ac.uk  Thu Jun  3 11:13:34 1993
Return-Path: <cja@castle.edinburgh.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05006; Thu, 3 Jun 93 11:13:34 MET DST
Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22393; Thu, 3 Jun 1993 11:35:14 +0200
Via: uk.ac.edinburgh.castle; Thu, 3 Jun 1993 10:33:38 +0100
To: www-talk@nxoc01.cern.ch
Subject: Networking Multimedia Applications
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Date: Thu, 3 Jun 93 10:33:25 WET DST
Message-Id: <9306031033.aa14345@castle.ed.ac.uk>

You may be interested in the following IETF BOF session.  If you intend
coming along, please let me know.  (The secretariat need an estimate of
numbers so they can allocate a suitably-sized room.)


                          IETF Meeting in Amsterdam

                               BOF Session on

                      NETWORKING MULTIMEDIA APPLICATIONS

               (currently scheduled for Tuesday 13 July, 1930-2200)


The ready availability of user-friendly multimedia authoring tools such
as Authorware Professional, Asymmetrix Multimedia Toolbook, Macromind
Director and many more, has stimulated much interest in multimedia
within the user community.  Sophisticated interactive multimedia
applications are being developed in many disparate subjects and for a
wide range of purposes.  Users are now beginning to ask us, as network
technologists, "how can I make my multimedia application available to
others across the network?".

In a parallel development, existing client-server network information
retrieval tools are being enhanced with multimedia handling features. 
Gopher+ for instance has been designed with multimedia data firmly in
mind.  The World Wide Web project is currently defining a new version of
its hypertext markup language, to be called HMML - HyperMedia Markup
Language - which includes multimedia support.

A third strand of activity is the emergence of network technologies
capable of carrying audio and video data across the network, initially
driven by multimedia conferencing applications.  Network technologies
such as ATM and protocols such as RTP are potentially capable of
handling isochronous multimedia data in an effective way. 

This BOF session will focus on issues which link these three strands. 
Particular questions to be addressed are:

* What are user requirements in terms of responsiveness, and what demands
  this places on the network and server system, and how these might
  be mitigated.

* The prospects for making existing interactive multimedia applications
  available over the network - eg by writing conversion tools from
  proprietary formats to a suitable open format.

* To what extent can existing network information retrieval tools such as
  Gopher, WWW, WAIS be used for sophisticated multimedia applications?
  What about the tools emerging from the research community such as
  AthenaMuse 2 (MIT), Microcosm (U of Southampton), HyperG (U of Graz)?
  Do we need another tool, or can we build on what we have?

* How can such tools be enhanced to take advantage of isochronous
  data streams?

* What relevance do standards such as HyTime and MHEG have?

The BOF is intended to test interest in the subject, to define issues
that need resoving, and to see whether a WG can be formed to work on
those issues. 


Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom




From daemon  Fri Jun  4 14:47:35 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01082; Fri, 4 Jun 93 14:47:37 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01078; Fri, 4 Jun 93 14:47:35 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09093; Fri, 4 Jun 1993 15:09:20 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03331; Fri, 4 Jun 93 15:09:40 +0100
Date: Fri, 4 Jun 93 15:09:40 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306041409.AA03331@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: WAIS gateway fixed
Reply-To: timbl@nxoc01.cern.ch


[I hope the www-talk alias will now (a) work -- if you got
this it does and (b) not send back errors to those
who contribute.]

The WAIS gateways at http://info.cern.ch:8001/ has been
fixed so that it now caches source documents again,
and so can display descriptions of WAIS databases as you hit
them, so long as at some point it has seen a source file
for the database in question.  The list of source files is
now building up as people use the gateways.

The next release of the library (when tested and released) will
include this feature for all clients which include direct access
to WAIS as a compile time option. The cache will be
stored by default in /usr/wsrc rather than /usr/lib/wais as before.

Tim BL


From daemon  Fri Jun  4 20:37:36 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09027; Fri, 4 Jun 93 20:37:38 MET DST
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09023; Fri, 4 Jun 93 20:37:36 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00162; Fri, 4 Jun 1993 20:59:19 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA24957; Fri, 4 Jun 1993 14:59:15 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
	id AA24587; Fri, 4 Jun 1993 11:59:12 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
	id AA01156; Fri, 4 Jun 1993 12:00:36 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9306041200.ZM1154@cider.west.ora.com>
Date: Fri, 4 Jun 1993 12:00:35 -0700
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: www-talk@nxoc01.cern.ch
Subject: HTML Doctype Declaration

In order to validate a SGML file, it must have
a DOCTYPE declaration, pointing to the SGML DTD.
Here's an example:

<!DOCTYPE HTML SYSTEM "/work/dmg/dtds/html/orahtml.dtd" >

Now, I know that the WWW parser does not need this
information because it does not actually read
a DTD.  However, if one is validating HTML files with an SGML parser,
which is the right thing to do at some point, the SGML parser needs
this line.  It would be nice to depend upon the HTML parser
to at least know to ignore it. 

In Xmosaic, for instance, this line is displayed on the screen.  
I'm not sure how the other browsers handle it.  

Dale

-- 

Dale Dougherty 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

UUCP:	uunet!ora!dale     Internet :   dale@ora.com


From daemon  Fri Jun  4 23:39:37 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13141; Fri, 4 Jun 93 23:39:40 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13137; Fri, 4 Jun 93 23:39:37 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12293; Sat, 5 Jun 1993 00:01:22 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12710
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 4 Jun 93 17:01:20 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA08142; Fri, 4 Jun 93 17:03:57 -0500
Date: Fri, 4 Jun 93 17:03:57 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306042203.AA08142@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: forwarded message from Carl Malamud
X-Md4-Signature: 62ee53e95e4e4083b18037ecbce41fe3

WWW'ers and in particular HTML'ers should listen to this, if
possible... he has particularly interesting comments about SGML and
markup.

Marc

------- Start of forwarded message -------
From: carl@malamud.com (Carl Malamud)
To: announce@malamud.com
Subject: Cliff Lynch, Geek of the Week
Date: Fri, 4 Jun 93 09:07:43 EDT

Station: Internet Multicasting Service
Channel: Internet Talk Radio
Program: Geek of the Week
Release: June 4, 1993 
Content: Cliff Lynch

On this week's "Geek of the Week," 

     Carl Malamud interviews Cliff Lynch, one of the most thoughtful
participants in the race to move libraries and publishers onto 
electronic publishing platforms.  Lynch received his Ph.D. in database
systems and is currently the Director of Library Automation for the 
University of California.  Lynch's most amazing accomplishment is the
amount of travel he puts in, far outstripping anybody this interviewer
has ever met in his ability to attend any and all events where a consensus
needs to be forged.  His tireless activities have been instrumental
in bringing the networking and library communities together.

     In this interview, Cliff Lynch discusses online publishing, looking
at the issue of SGML as a markup language and examining the question of 
presentation integrity versus the desire for revisable form documents.
Lynch also discusses the Z39.50 protocol, the scaling of very large
databases, the democratization of publishing, and the role of the
Coalition for Networked Information.

     Geek of the Week is sponsored by O'Reilly & Associates and by 
Sun Microsystems. 

     Network connectivity is provided by UUNET Technologies.

ITR Program Files: 
  
Size             Name                      Description
=========        ======================    ===================
4,154,544        060493_geek_01_ITR.au     Cliff Lynch, Part 1
5,852,291        060493_geek_02_ITR.au     Cliff Lynch, Part 2
3,036,814        060493_geek_03_ITR.au     Cliff Lynch, Part 3
4,579,710        060493_geek_04_ITR.au     Cliff Lynch, Part 4
  252,858        060493_geek_05_ITR.au     Legal Stuff
4,004,486        060493_geek_06_ITR.au     Cliff Lynch, Part 5
                 060493_geek_ITR.readme    (This File)

For information about Internet Talk Radio, send mail to info@radio.com.
For information about Internet Town Hall, stand by for more details.
For a listing of some distribution sites, send mail to sites@radio.com.
------- End of forwarded message -------


From daemon  Sat Jun  5 03:34:44 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15964; Sat, 5 Jun 93 03:34:46 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15960; Sat, 5 Jun 93 03:34:44 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26206; Sat, 5 Jun 1993 03:56:29 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA20686
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 4 Jun 93 20:56:27 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA08890; Fri, 4 Jun 93 20:59:03 -0500
Date: Fri, 4 Jun 93 20:59:03 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306050159.AA08890@wintermute.ncsa.uiuc.edu>
To: dale@ora.com (Dale Dougherty)
Cc: www-talk@nxoc01.cern.ch
Subject: HTML Doctype Declaration
In-Reply-To: <9306041200.ZM1154@cider.west.ora.com>
References: <9306041200.ZM1154@cider.west.ora.com>
X-Md4-Signature: 565310639040f79b9532b479bda828de

Dale Dougherty writes:
> In order to validate a SGML file, it must have
> a DOCTYPE declaration, pointing to the SGML DTD.
> Here's an example:
> 
> <!DOCTYPE HTML SYSTEM "/work/dmg/dtds/html/orahtml.dtd" >
> 
> Now, I know that the WWW parser does not need this
> information because it does not actually read
> a DTD.  However, if one is validating HTML files with an SGML parser,
> which is the right thing to do at some point, the SGML parser needs
> this line.  It would be nice to depend upon the HTML parser
> to at least know to ignore it. 
> 
> In Xmosaic, for instance, this line is displayed on the screen.  

NOT in 1.1.  Are we clairvoyant, or what?  :-)

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Sat Jun  5 04:54:27 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16485; Sat, 5 Jun 93 04:54:30 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16481; Sat, 5 Jun 93 04:54:27 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08663; Sat, 5 Jun 1993 05:16:12 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22955
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Fri, 4 Jun 93 22:16:10 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA10442; Fri, 4 Jun 93 22:18:46 -0500
Date: Fri, 4 Jun 93 22:18:46 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306050318.AA10442@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: NCSA Mosaic for X 1.1 available.
X-Md4-Signature: b11704fdb173816811103a11d78e4708

Version 1.1 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is now available:

file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-source/xmosaic-1.1.tar.Z
                            .../xmosaic-binaries/xmosaic-sun.Z
                            .../xmosaic-binaries/xmosaic-sun-lresolv.Z
                            .../xmosaic-binaries/xmosaic-sgi.Z
                            .../xmosaic-binaries/xmosaic-ibm.Z
                            .../xmosaic-binaries/xmosaic-dec.Z
                            .../xmosaic-binaries/xmosaic-alpha.Z
                            .../xmosaic-diffs/xmosaic-1.0-1.1-diffs.Z

NCSA Mosaic provides a consistent and easy-to-use hypermedia-based
interface into a wide variety of networked information sources,
including Gopher, WAIS, World Wide Web, NNTP/Usenet news, Techinfo,
FTP, local filesystems, Archie, finger, Hyper-G, HyTelnet, TeXinfo,
telnet, tn3270, and more.

This release of NCSA Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).
  DECstation 5000-200 (Ultrix).
  DEC Alpha (OSF/1).

Rumor has it that Mosaic will compile on systems like:

  Hewlett Packard HP/UX 7.x, 8.x, 9.x.
  Dell SVR4
  Sun Solaris 2.x
  SCO Open Desktop
  Harris Nighthawk
  NeXT BSD

Documentation is available online.

Changes since 1.0 include:

 o Hotkeys in document view windows.  
 o Color leaks and glitches in inlined image support fixed.  
 o Support for TMPDIR environment variable, as well as resource 
   tmpDirectory and command-line flag -tmpdir, for specifying
   location of tmp directory for transient data files.  
 o Added GUI-supported modification of hotlist entry titles.  
 o Added ISMAP tag support to IMG tag (courtesy Tony Sanders).  
 o CSO phonebook support (courtesy Lou Montulli).  
 o Added printing/saving straight to PostScript (courtesy Ameet A.  Raval).
   No support for images yet, though.  
 o Fixed typo in Motif 1.2 support in HTML widget.  
 o Fixed typo (nothing was broken, just caused it to be a little slow
   sometimes) in document page handling.  
 o Two spaces between sentences in pretty selections now.  
 o SGML comments are now ignored.  
 o Updated copyright notice.  
 o Documentation hyperlinks point straight to new NCSA server.  
 o Mosaic can now be remotely controlled via signals by a parent process;
   e.g., to allow use as a browser for context-sensitive help from another
   application.  More information coming...  
 o Default rgbViewerCommand is now 'xv' on non-SGI platforms, since xv
   3.0 now handles SGI RGB files.  
 o New WAIS interface document, pointing to NCSA gateway.  
 o URL of document is now sent in 'Mail To...' messages.  
 o <cite> now supported.  
 o <blockquote> now supported.  
 o <var> now uses italics.  
 o Fixed rare parsing/layout coredumps.  
 o Fixed rare pretty selection coredumps.  
 o Fixed stupid memory and file-handling glitches; made hotlist and other
   config file-handling much more robust.  
 o Properly handle (nuke) newlines in titles and URL's now.  
 o Fixed rare stupid coredumps in Motif lists.  
 o No more coredump when saving/printing/mailing empty file.  
 o Mosaic now has no default geometry resource value.  Initial window
   placement and toplevel dialog placement will be entirely according to
   your window manager's settings.  
 o Added resource percentVerticalSpace to allow customization of the space
   between paragraphs, between headers and paragraphs, etc.  in the HTML
   widget.  
 o Fixed coredump when starting Mosaic with home page a directory with
   no slashes in the specification.  
 o Added recognition of '.gz' for gzip'd files, as per GNU change.  
 o Fixed glitch with X bitmaps served by Gopher servers as inlined images.  
 o Added editres support.  
 o Added Motif 1.2 tearoff menu support.  
 o Better DEC Alpha OSF/1 support.  
 o Better Dell SVR4 support.  
 o A few more source cleanups for NeXT support.  
 o Reorganized Documents menu and added new options to Help menu.  
 o Added support for group annotation server (not yet available).  
 o Cleaned up src/Makefile (some).  
 o Suffixes .dump and .saveme are now recognized and trigger binary
   file dump to local disk.  
 o Busy cursor now shows up more often, like it should.  
 o HDF files are now recognized and passed to Collage via Collage's -load
   option, which isn't yet in a released version.  
 o Miscellaneous bug fixes and cleanups.  

Comments, questions, and bug reports should be sent to
mosaic-x@ncsa.uiuc.edu.  Thanks in advance for any feedback you can
provide.

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From daemon  Mon Jun  7 10:58:48 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06174; Mon, 7 Jun 93 10:58:51 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06170; Mon, 7 Jun 93 10:58:48 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27287; Mon, 7 Jun 1993 11:20:36 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 7 Jun 93 10:12:58 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00664; Mon, 7 Jun 93 10:18:52 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306070918.AA00664@manuel.hpl.hp.com>
Subject: Super- and subscripts in HTML+
To: bobs@sco.com
Date: Mon, 7 Jun 93 10:18:50 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Bob Stayton, Technical Publications at The Santa Cruz Operation, Inc.
has requested that we include support for subscripts and superscripts:

> We use superscripts primarily for trademark attribution
> (e.g., TM and r-circle), as well as in a few instances of
> mathematical exponents within a sentence.  We also use
> subscripts as a mathematical index on certain man pages.  I
> wasn't asking for a full treatment of mathematical
> equations, which I agree should be handled as embedded
> figures.  But a simple exponent within a sentence should
> not be forced into being a graphic in my opinion.  The
> formatting is relatively simple (move up or down a
> half line until turned off), and would seem to be
> within the scope of the simple formatting done
> in WWW clients.

I have just added these as presentation styles to the inline emphasis tag:

        There has been a lot of interest lately in
        mc<emph tag="super">2</emph>.
i.e                                                  2
        There has been a lot of interest lately in mc .

        (HP-speak for measurement, computation and communication)

The suggestions for rendering emphasis are:

    a)  allow users to tailor the display via user prefernces
        e.g. italic, bold, underline, highlight, super/subscript

    b)  default to italic or highlighted text for unrecognised types


These changes will make their way to the CERN copy soonish.

Regards,

Dave Raggett

p.s. Does anyone mind if I change the generic emphasis tag from EMPH to EM?

From daemon  Tue Jun  8 11:43:29 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28027; Tue, 8 Jun 93 11:43:31 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28023; Tue, 8 Jun 93 11:43:29 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29581; Tue, 8 Jun 1993 12:05:21 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA06827; Tue, 8 Jun 93 12:05:21 +0200
Date: Tue, 8 Jun 93 12:05:21 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306081005.AA06827@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: 2.06 release of libwww, www and httpd
Reply-To: timbl@nxoc01.cern.ch



	New release of libwww
	
A new release of libwww, the public domain code library for
W3 clients and servers, is now available as
<ftp://info.cern.ch/pub/www/src/WWW*2.06.tar.Z>

Also released at the same time is the httpd HTTP server,
and the "www" line mdoe browser.

Changes are documented in the web.  The main ones are:

- Improved handling of WAIS access, including caching of
   wais server descriptions in /usr/wsrc.

- Directory listings (server anmd client) for local files
  are now separated into subdirectories and files,
  and sorted alphabetically.

A number of bugs have been removed.  Binaries
of www and httpd are available for Sun, Decstation,
HP, rs6000, next

From daemon  Wed Jun  9 00:44:27 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15211; Wed, 9 Jun 93 00:44:31 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15206; Wed, 9 Jun 93 00:44:27 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20462; Wed, 9 Jun 1993 01:06:20 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12096>; Tue, 8 Jun 1993 16:05:59 PDT
Received: by holmes.parc.xerox.com id <16134>; Tue, 8 Jun 1993 16:05:56 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue,  8 Jun 1993 16:05:56 -0700 (PDT)
Message-Id: <Mg5FhI4B0KGW1N2W9Q@holmes.parc.xerox.com>
Date: 	Tue, 8 Jun 1993 16:05:56 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, timbl@nxoc01.cern.ch
Subject: Re: 2.06 release of libwww, www and httpd
In-Reply-To: <9306081005.AA06827@www3.cern.ch>
References: <9306081005.AA06827@www3.cern.ch>

When I use www_2.06 to retrieve a document, for example

	www_2.06 -source
ftp://ds.internic.net/internet-drafts/1327-tutorial.2.ps >/tmp/foo.ps

each line of the resulting file seems to have an `extra' carriage-return
character appended to it.  That is, if I retrieve the same document via
ftp, there is no such carriage return on each line.  Is there some
switch or resource which will defeat this behaviour (at least under
UNIX)?  Trying "-n" doesn't seem to help.

Bill

From daemon  Wed Jun  9 09:14:43 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20666; Wed, 9 Jun 93 09:14:45 MET DST
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20662; Wed, 9 Jun 93 09:14:43 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20472; Wed, 9 Jun 1993 09:36:38 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 8903; Wed, 09 Jun 93 09:36:59 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 8391; Wed, 9 Jun 1993 09:36:58 +0200
Received: by HUJIVMS (HUyMail-V6l); Wed, 09 Jun 93 10:36:27 +0300
Date:     Wed,  9 Jun 93 10:36 +0300
Message-Id: <09060093103626@HUJIVMS>
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch
Subject:  www for windows

Hi, I have picked it up.
Sorry  if it is allready posted here before.

 Dudu.



>>>From: Thomas R. Bruce <trb2@cornell.edu>
>>
>> (Cross-posted to many lists and groups.  Please forgive necessary
>> duplications)
>>
>> Folks:
>>
>> This is an announcement of Beta Release 0.1 of Cello, a multipurpose
>> Net browser for Microsoft Windows 3.1
>>
>> Features:
>>
>> --WWW(HTTP/HTML) browser, with user-configurable colors
>> and fonts.
>> --Full-featured Gopher (though unfortunately not yet Gopher+)
>> client, including a hyper-ized CSO which permits (sorta dumb)
>> SMTP mailing.
>> --Transparent access (via WWW) to FTP, HyTelNet, Telnet, etc.
>> etc. ad infinitum.
>> --Graphics and PostScript viewing and sound playing via
>> MSWindows Associations...feature, using add-on, shareware
>> viewers such as SNDTOOL, GV057, and the Windows version of
>> GhostScript.
>> --Ad-hoc Telnet, FTP, and Gopher sessions.
>> --SLIP/PPP support with dialup scripting language.
>> --Supports wide range of LAN configurations via Distinct
>> TCP/IP runtime stack.
>>
>> Things you should know:
>>
>> -- Hardware:
>> Cello needs a Windows 3.1-capable machine with enhanced mode
>> and (preferably) swapping enabled.  It is hungry for extended RAM.
>>
>> -- Software:
>> Cello depends (for now...we're working on a Winsock version) on the
>> Distinct TCP/IP runtime stack.  The LII has licensed the use of a
>> runtime version of this software for use by US academic institutions
>> for a period of one year, starting June 1, after which we will
>> renegotiate the license.  Commercial organizations and non-academic
>> users are strongly urged to contact Distinct directly at
>> mktg.distinct.com.
>>
>> The Distinct software adds enormous functionality to the package,
>> including SLIP/PPP support with scripting, and configuration for
>> many types of LAN and networking layers.
>> We are working on a Winsock version which will be available
>> without restriction later this summer.
>>
>> --How to get it:
>>
>> FTP to fatty.law.cornell.edu, the /pub/LII/Cello subdirectory.  The
>> distribution is in multiple files.  At a minimum, you will need
>>
>> README.1ST, which contains unpacking instructions.
>> CELLO.ZIP, which contains the executable and Help application
>> DIS.ZIP, which contains the runtime stack.
>>
>> Optionally, you should also get:
>>
>> VIEWERS.ZIP, which contains a graphics viewer and sound player for
>> use with Cello.
>>
>> GSWIN.ZIP, which contains the Windows version of GhostScript.
>>
>> PLEASE NOTE that fatty is but an humble little Sparc and you can
>> bring it to its knees fairly easily, so if you have another source for
>> the GhostScript stuff please spare me and everyone else by going to
>> the alternate source; the file is 2+ MB.
>>
>> Installation:
>>
>> Installation is performed by following the instructions in
>> README.1ST, then using the online help.  Additional support is
>> available from a listserv list called appropriately enough CELLO-L.
>> To subscribe, send a message to listserv@fatty.law.cornell.edu with
>> the one-liner:
>>
>>          sub cello-l your full name
>>
>> in the body of the message.  cello-l is watched by the developer and
>> by a few folks who graciously assisted in alpha testing and who
>> know more about the software's treacherous behavior than its
>> author; the listowner is Will Sadler at Indiana University Law School.
>> We are also working on an archive of installation hints and tricks.
>> Please try to take it easy on comp.infosystems.www; Tim already has
>> too much to deal with (grin).
>>
>> Who'n'heck are these guys?:
>>
>> The Legal Information Institute, operating under the auspices of the
>> Cornell Law School, is an entity set up to distribute legal information
>> in hypertextual form by various means, including the Net.  Since
>> there wasn't a Web client for the platform used most by lawyers and
>> legal academics, we took it into our (ill-advised) heads to write one.
>> This is it, almost.  For further information: lii@fatty.law.cornell.edu.
>>
>> Regards,
>> Tb.
>>
>>
>>
>> Thomas R. Bruce
>> Thomas_Bruce@cornell.edu
>>
>> Legal Information Institute
>> Cornell Law School

From daemon  Wed Jun  9 15:55:06 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26696; Wed, 9 Jun 93 15:55:09 MET DST
Return-Path: <cshotton@oac.hsc.uth.tmc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26692; Wed, 9 Jun 93 15:55:06 MET DST
Received: from oac.hsc.uth.tmc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27411; Wed, 9 Jun 1993 16:17:01 +0200
Message-Id: <9306091417.AA27411@dxmint.cern.ch>
Received: from oac2.hsc.uth.tmc.edu by oac.hsc.uth.tmc.edu with SMTP
	(1.37.109.4/16.2) id AA15117; Wed, 9 Jun 93 09:12:27 -0500
Date: Wed, 9 Jun 1993 09:20:30 -0600
To: www-talk@nxoc01.cern.ch
From: cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton)
Subject: Building XMosaic 1.1 on HP/UX 9.0

Here are a few observations about building XMosaic 1.1 on HP/UX 9.0 or 9.01
that may help speed up the process for others. 

First, NO changes are required to any of the source in the XMosaic
distribution, but there are some changes needed in the Makefiles and in
some of HP/UX's locations for include files. Here's the summary:

Building libwww:
----------------
Nothing really has to change here for 9.0. Simply uncomment the appropriate
lines in the Makefile. Under 9.0, a new compiler option has been added,
"-Ae", which takes the place of "-Aa -D_HPUX_SOURCE", but libwww builds
fine the way it is.

Building libhtmlw:
------------------
This was the problem child. HP/UX 9.0 includes Motif 1.2, which needs X11R5
as well. This version of Motif quickly fills up the C Preprocessor's symbol
table, so the OTHERFLAGS variable needs to be changed as follows:

OTHERFLAGS = -W p,-H256000 -DMOTIF1_2 -I/usr/include/Motif1.2 \
              -I/usr/include/X11R5

The "-W p, -H256000" passes the "-H" option through to the C preprocessor,
allocating more space in the symbol table.

The X11R5/Motif 1.2 combination also eliminates the X11/Xmu directory from
the include tree. I found that it was necessary to create a symbolic link
in the /usr/include/X11R5/X11 directory named Xmu that was linked to
/usr/include/X11R4/X11/Xmu. This got things to build, but it seems like it
shouldn't be necessary. If someone knows a better way to get this to work,
please let me know.

Building xmosaic:
-----------------

Only 2 lines needed changing for HP/UX in the Makefile to get xmosaic to
build. The CFLAGS line is changed to:

 CC = cc -Aa -D_HPUX_SOURCE -I/usr/include/Motif1.2 -I/usr/include/X11R5

The X_LIBS line is changed to:

X_LIBS = -L/usr/lib/Motif1.2 -lXm -L/usr/lib/X11R5 -L/usr/lib/X11R4 -lXmu \
         -lXt -lX11
--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                             \ 
Assistant Director, Academic Computing     \   "Are we there yet?"
U. of Texas Health Science Center Houston   \ 
cshotton@oac.hsc.uth.tmc.edu  (713) 794-5650 \ 
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_-


From daemon  Thu Jun 10 21:03:01 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00929; Thu, 10 Jun 93 21:03:03 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00925; Thu, 10 Jun 93 21:03:01 MET DST
Received: from [140.186.65.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15628; Thu, 10 Jun 1993 21:24:49 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA29410; Thu, 10 Jun 1993 15:24:24 -0400
Date: Thu, 10 Jun 1993 15:24:24 -0400
From: raisch@ora.com (Rob Raisch)
Message-Id: <199306101924.AA29410@ora.com>
To: www-talk@nxoc01.cern.ch
Subject: <TITLE>Current Server Work at O'Reilly....</TITLE>


>Newsgroups: comp.infosystems.www
>Path: ora.com!raisch
>From: raisch@ora.com (Rob Raisch)
>Subject: <TITLE>Current Server Work at O'Reilly....</TITLE>
>Message-ID: <C882F3.LxH@ora.com>
>Organization: O'Reilly & Associates, Inc.
>Date: Sun, 6 Jun 1993 22:57:02 GMT

	We have a project which will use WWW to deliver a product from ORA to
users who have 'subscribed.'  This will be a free product, but we will need
to collect information from the user-base to be able to generate demographics
which will ultimately pay for the project (we hope.)  (BTW, can't talk about
it, wait for the 'official' announcement.)

	I've made modifications to the NCSA server code to support two features
of the new HTTP protocol spec which will allow us to log who is accessing this
'product.'  I've added support for the 'From:' and 'User_Agent:' fields in
server queries to know who is asking and what they are using to retrieve.

	It has occured to me that there are some decisions a server might make, 
given a very little information regarding the browser the user is using.

	I would like to propose the following format for the 'User_Agent:'
field, and see what people think:

	User_Agent: NAME VERSION CAPABILITIES

	Where the name and version would be defined by the browser maker, 
and the CAPABILITIES would come from a list like:

		TEXT 		(does this really need to be said?)
		INLINE_GIF	(gifs inlined ala mosaic)
		GIF,JPG,PS 	(various graphics)
		GHOSTVIEW
		MOUSE
		AUDIO,VIDEO	(supports audio or videofiles)
		MAIL,NEWS,FTP	(supports these local services)
		FAST		(on an ETHER connection)
		SLOW		(on a SLIP dialup)
		... 		(many possible capabilities to be defined)


	The theory here is that documents can be rewritten 'on the fly' to
reference only those capabilities which the user has at hand.

	Further assume that I have a method of managing documents locally which 
return portions of a document based on capability metrics.

	For example:

	I am a user, using Lynx on a VTxxx.  When I make a request to the 
server, Lynx also sends:

		User_Agent: Lynx 1.06 TEXT MAIL NEWS

since these are the capabilities which Lynx running on my host supports.

	The server then retrieves the following document

------------------------------------------------------------------------------
<HTML>
<HEAD>
<TITLE>This is a document</TITLE>
</HEAD>
<BODY>

#ifdef GRAPHICS

#	ifdef GIF

	<IMG HREF=(some gif file)>

#	elif JPG

	<IMG HREF=(some jpg file)>

#	endif

#else
	There is an inline graphic here which cannot be rendered 
	locally.  It can be retrieved by hand as:

#	ifdef FTP

	ftp://hostname/dir/file

#	elif MAIL

	"/dir/file" from hostname

	by using the the ftp->mail gateway at Hostname with the 
	following commands:
		Get blahblahblahblahblah
#	endif


#endif

</BODY>
</HTML>
-----------------------------------------------------------------------------

	(For the non-developers in the audience, the #-commands are from the
standard Unix C language pre-processor.)

	And makes the proper macro expansion to send the best document
back to meet the requirements of the User_Agent.

	I would get, on the browser end, something which looked like:

-----------------------------------------------------------------------------
<HTML>
<HEAD>
<TITLE>This is a document</TITLE>
</HEAD>
<BODY>
	There is an inline graphic here which cannot be rendered 
	locally.  It can be retrieved by hand as: "/dir/file" from hostname

	by using the the ftp->mail gateway at Hostname with the 
	following commands: Get blahblahblahblahblah
</BODY>
</HTML>

-----------------------------------------------------------------------------

	Note that the macro document never leaves the system, only the 
particular rewritten version which answers the needs of the reader.

	Thoughts?  --</rr>

From daemon  Thu Jun 10 21:02:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00913; Thu, 10 Jun 93 21:02:54 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00904; Thu, 10 Jun 93 21:02:40 MET DST
Received: from [140.186.65.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15575; Thu, 10 Jun 1993 21:24:07 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA29318; Thu, 10 Jun 1993 15:23:20 -0400
Date: Thu, 10 Jun 1993 15:23:20 -0400
From: raisch@ora.com (Rob Raisch)
Message-Id: <199306101923.AA29318@ora.com>
To: www-talk@nxoc01.cern.ch
Subject: Request for Comments: STYLESHEETS

Forwarded from comp.infosystems.www newsgroup:  (Sheesh, this is what comes
from not following the conversation regarding gatewaying the list to the 
group and vice versa.  <grin>)

</rr>
-------------------------------------------------------------------------
O'Reilly & Associates would like to solicit comments from the WWW online 
community on the following proposal to include support for 'stylesheets' 
in HTML documents.

	Date:		June 6 1993

	Title:		Stylesheets for HTML

	Author:		Robert Raisch
			Manager, Online Systems
			O'Reilly & Associates

	Abstract:

		Many interesting documents in the WWWeb are now being
		designed to support features or attributes of specific
		browsers/renderers.  While this is not, in itself, a
		bad thing, the optimal state would be one where the
		document carried with it information which allowed 
		browsers to make 'appropriate' decisions which were
		aligned with the intent of the original author.

		This RFC proposes an easily parsable format to deliver
		stylistic information along with Web documents.  While
		the actual format of this information is of little 
		general interest to the Web community, an attempt has 
		been made to support a simple subset of generally useful 
		style HINTS or SUGGESTIONS.  This is not meant to be an 
		exhaustive list and suggestions for improvement would 
		be most welcome.

		In no way should this proposal be considered an attempt
		to stipulate *required* behavior.  The sole purpose of
		the included format is to suggest behavior which will
		allow a browser to render a specific document in a form
		which more closely resembles the document as envisioned
		by it's creator.

	The author is indebted to the Global Network Navigator Project and
	Digital Media and Design Groups of O'Reilly and Associates.

	Please direct comments to the newsgroup, or to 'raisch@ora.com'

--------------------------------------------------------------------------
NOTE:

	The format described is supported in libWStyle, a stylesheet parser
	library which will be released to the WWW developer community, REAL
	SOON NOW.

	This document will be made available through the Web.  Due to 
	the nature of certain discussions on the net, it is published here 
	as a plain text document.  Apologies to Web purists.  </rr>

--------------------------------------------------------------------------


WWW HTML STYLE GUIDE RECOMMENDATIONS		- Robert Raisch
						  O'Reilly & Associates
						  02 June 1993


Need
----

	There is a need within the WWW to be able to specify rendering
specific information along with the content tagging in a WWW document.
It is not appropriate to use HTML for this purpose, since one of the 
first principles of HTML is to encode objects within a document, not how 
they might be rendered in a particular environment.


Executive Summary -- The Short Form
-----------------------------------

	o	HTML documents would include a LINK STYLE tag which would 
		point to a stylesheet associated with the current
		document.

	o	Stylesheet literate browsers or renderers would use this
		tag to retrieve the actual stylesheet.

	o	Multiple stylesheets could be used per document to include
		stylistic changes.  Once a new stylesheet was loaded it
		would hide, not overwrite, the previous stylesheet.  The
		previous stylesheet would become visible once an empty
		LINK STYLE tag was encountered.

	o	Stylesheets are defined in a easy to parse, compact form
		to minimize the time required to retrieve and interpret
		them.

	o	Styles are suggestions or hints about behavior, not rules.



What we're doing here
---------------------

	This document is an attempt to codify those rendering aspects
which would be most useful in the specification of an HTML object.  This is
not meant to be an exhaustive list of rendering possibilities, nor is it 
a set of "rules set in stone" which must be obeyed.  Rather, this is really 
a set of HINTS or SUGGESTIONS to the renderer which might be used to display 
particular HTML objects in the fashion the author of a document originally 
intended.

	It is suggested that renderers which cannot adhere to some style
specified in this document might make an attempt to remain true to the
spirit of the author's original intent.  (Few renderers short of a true
X-terminal will be able to implement the full set of styles defined here.)

	An example of this might be the use of a 'o' (small-oh) to represent 
the 'round mark', or the interpretation of a color style specifying red on 
white characters as a "reverse video" or "blinking" attribute on terminals 
which do not support color.

	
The Styles
----------

	The styles defined specify the recommended behavior of HTML objects
in terms of:

	Category			Style Name
	-----------------------		----------
	character rendering		font
	object justification		justify
	page layout			column
	break behavior			break
	special marks			mark
	vertical object layout		vert
	horizontal object layout	indent
	links contained in objects	link


	Each style has a number of arguments or attributes which can be
specified per HTML object, and in the general case, as a default for all
HTML objects which are not further refined.


Stylesheet Identification 
-------------------------

	HTML specifies a header element called <LINK> which can be used for a
wide variety of purposes.  I suggest that the following form be followed:

	<LINK STYLE={URL}>

	It is expected that stylesheet literate browsers would retrieve the
stylesheet from it's URL, and use the information contained therein to make
appropriate rendering decisions.  (See Appendix II and III)



-----------------------------------------------------------------------------
 Definition of Recommended Styles, Attributes and Values
-----------------------------------------------------------------------------

font(family,spacing,size,weight,slant,foreground,background,line,longname)(fo) 

	Describes the characteristics of character representation.

(fa)	family= 	FAMILY  (ti,he,sy,ty)			 DEFAULT:ti

		Describes the 'subjective' style of a font.  This is not
		meant as a font name, per se.  Rather it is a suggestion 
		of a particular style of character representation.
		Recommended values are: 

			times,		-- in the style of Serif Times Roman
			helvetica, 	-- in the style of Sans Serif Helvetica
			system, 	-- default system font style
			typewriter	-- default "tty" font style

(sp)	spacing=	SPACING	(mo,pr)				 DEFAULT:mo

		Describes the intra-character spacing rule for a particular
		character representation.  Recommended values are:

			monospaced, 	-- each character takes up same space
			proportional	-- each character takes up diff space

(si)	size=		UNITS 	point size 			 DEFAULT:14

		Describes the size of the character representation in
		general UNITS, which could be interpreted as a typographic
		'point' size.  Recommended values are: 1-n

(we)	weight=		WEIGHT  (ul,li,me,de,bo)		 DEFAULT:me

		Describes the general weight of a character representation
		in the following recommended terms:

			ultralight, 	-- lightest
			light, 		-- lighter than "normal"
			medium, 	-- "normal" weight
			demibold, 	-- heavier than "normal"
			bold		-- heaviest

(sl)	slant=		SLANT   (ro,it,ob)			 DEFAULT:ro

		Describes the slant or angle of a character representation
		in the following terms:

			roman,		- normal upright representation
			italic,		- forward inclination
			oblique		- backward inclination (???)

(fo)	foreground=	COLOR					 DEFAULT:''

		Describes the recommended foreground color representation
		for a character.  Colors are specified as 'inherit', text
		names, (eg. black, white, magenta), or as RGB color 
		values in hexidecimal, (eg. 0x000000, 0xffffff, 0xff00ff)
		
(ba)	background=	COLOR					 DEFAULT:''

		Describes the recommended background color representation
                for a character.  Colors are specified as 'inherit', text
                names, (eg. black, white, magenta), or as RGB color 
                values in hexidecimal, (eg. 0x000000, 0xffffff, 0xff00ff)

(li)	line=		LINE    (no,un,th,ov)			 DEFAULT:no

		Describes the recommended representation of attendant 
		lines in the character style.  Recommended values are:

			none,		-- no line highlighting object
			under,		-- line under object (underline)
			through,	-- line through object (strikeout)
			over		-- line over object (overline)

(nu)	number=		UNITS	number of lines			 DEFAULT:1

		Describes the recommended number of attendant lines in
		the character style.  Recommended values are: 1-n

(lo)	longname=	STR	platform specific font name	 DEFAULT:''

		Describes, in a platform specific fashion, the recommended
		font name for a character representation.  A possible 
		value might be:

		-adobe-courier-bold-r-normal--0-190-75-75-m-110-iso8859-1

-----------------------------------------------------------------------------

justify(style,hyphen,kern) (ju)

	Describes the characteristics of character and line justification.

(st)	style=		JUST style of justification (no,le,ce,ri,fu) DEFAULT:le

		Describes the recommended justification of an object.
		Recommended values are:

			none, 		-- no justification (PRE)
			left, 		-- justify object to the left
			center, 	-- center object
			right, 		-- justify object to the right
			full		-- fully justify object

(hy)	hyphen		BOOL words can be hyphenated if possible DEFAULT:0

		Describes the recommendation that words which cross line
		boundaries may be hyphenated to better represent the 
		object.  Recommended values are either:

			 FALSE (0) or TRUE (not FALSE)

(ke)	kern		BOOL words can be kerned if possible     DEFAULT:0

		Describes the recommendation that characters may be kerned
		to better represent the object.  Recommended values are 
		either: 

			FALSE (0) or TRUE (not FALSE)

-----------------------------------------------------------------------------

column(num) (co)

	Describes the characteristics of columnar layout.

(nu)	num=		UNITS	number of columns to display	 DEFAULT:1

		Describes the maximal number of legal columns.  Recommended
		values are:  1-n

(wi)	width=		UNITS	width of a column		 DEFAULT:0

		Describes the maximal number of UNITS per column. In the
		case of a text object, UNITS might represent characters,
		while in the context of a graphical object, UNITS could
		represent picture elements (pixels.)  Recommended values
		are: 1-n

-----------------------------------------------------------------------------

break(location,object) (br)

	Describes the suggested behavior of an object in terms of it's
	"breakability."  (Break in the sense that the current object is
	broken, and the cursor or point of attention returns to the left-
	most point of reference.)

(st)	style=		BREAK	how to break (be, af)		 DEFAULT:af

		Describes the recommended style of breakage for the
		object.  Recommended values are:

			before,		-- break appears before object
			after		-- break appears after object

(ob)	object=		OBJ	what to break (no,it,li,ch)	 DEFAULT:no

		Describes the recommended element of the object upon
		which to break.  (For example, paragraphs traditionally
		break upon the paragraph itself (item), while titles
		or headers break upon each line.  Recommended values 
		are:  

			none, 		-- do not break
			item, 		-- break on the object itself
			line, 		-- break on each logical line
			character	-- break on each character
						(included for completeness)

-----------------------------------------------------------------------------

mark(object,preceed,before,replace,succeed,after) (ma)

	Describes a mark or signal which can appear with an object.

	(NOTE: a "mark" can be specified in a number of ways.  Recommended
	values for the mark are:
		none,		-- no not mark
		{string},	-- text which marks the object
		{icon},		-- a graphical element or icon
		arabic,		-- arabic numerals
		alpha,		-- alphabetic numerals
		roman,		-- roman numerals
		vert,		-- vertical bar
		horz,		-- horizontal bar
		round,		-- bullet or circle
		square,		-- square mark
		check,		-- check mark
		star,		-- star or asterix
		north,		-- northward pointing arrow
		south,		-- southward pointing arrow
		east,		-- eastward pointing arrow
		west		-- westward pointing arrow

	It is recommended that numeric marks (arabic,alpha,roman) be
	incremented based on each instance of a particular object, eg.
	the first instance of an object with the 'alpha' style of mark
	could be marked with 'A', and the succeeding elements markes
	with 'B', 'C', 'D', etc.  It is also recommended that upon a
	change of mark, eg. from alpha to roman, could reset the 
	current counter.
	)

(ob)	object=		OBJ	what to mark (no,it,li,ch)	 DEFAULT:no

		Describes what element within an object gets the mark.
		Recommended values are:

			none,			(as above)
			item,
			line,
			character
	
(pr)	preceed=	MARK	preceeding mark			 DEFAULT:no

		Describes the mark or signal which could appear before
		the previously mentioned element.

(be)	before=		UNITS	space btw mark and item		 DEFAULT:0

		Describes the recommended amount of space before an object 
		the mark appears.  (A UNIT takes on different interpretation
		depending on the context, textual or graphical.) Recommended
		values are: 1-n.


(re)	replace=	MARK	mark which replaces content	 DEFAULT:no

		Describes the mark or signal which could replace the 
		previously mentioned element.

(su)	succeed=	MARK	succeeding mark			 DEFAULT:no

		Describes the mark or signal which could appear after
		the previously mentioned element.

(af)	after=		UNITS	space btw item and mark		 DEFAULT:0

		Describes the recommended amount of space after an object 
		the mark appears.  (A UNIT takes on different interpretation
		depending on the context, textual or graphical.) Recommended
		values are: 1-n.

-----------------------------------------------------------------------------

vert(before,after,spacing,offset) (ve)

	Describes the characteristics of an object in terms of vertical
	geometry.

(be)	before=		UNITS	vertical space before object	 DEFAULT:0

		Describes the amount of space in UNITS before an object.
		(UNITS takes on different meaning depending on current
		context.  See "column.width")

(af)	after=		UNITS	vertical space after item	 DEFAULT:0

		Describes the amount of space in UNITS after an object.
		(UNITS takes on different meaning depending on current
		context.  See "column.width")

(le)	leading=	UNITS	vertical spacing between lines	 DEFAULT:0

		Describes the amount of space in UNITS between objects.
		(UNITS takes on different meaning depending on current
		context.  See "column.width")

(of)	offset=		UNITS	vertical spacing from baseline	 DEFAULT:0

		Describes the amount of space in UNITS between an object
		and the baseline.  (Allows supscripting and superscripting.)
		(UNITS takes on different meaning depending on current
		context.  See "column.width")


-----------------------------------------------------------------------------

indent(left,right,first) (in)

	Describes the characteristics of an object in terms of horizontal
	geography.

(le)	left=		UNITS	horizontal space before item	 DEFAULT:0

		Describes the amount of space, in UNITS, before or to the
		left of the object.

(ri)	right=		UNITS	horizontal space after item	 DEFAULT:0

		Describes the amount of space, in UNITS, after or to the
		right of the object.

(fi)	first=		UNITS	indent for object		 DEFAULT:0

		Describes the amount of space, in UNITS, before the first
		line of an object.


-----------------------------------------------------------------------------

link(location,mark,line,number,before,after,hide) (li)

	Describes the special characteristics of a link or selectable
	object.

(lo)	location=	TOKEN	(no,in,ri,le)			 DEFAULT:of

		Describes where a link might appear.  Recommended values
		are: 

			none,		-- suppress link marking
			inline,		-- mark links inline
			right,		-- mark links in right margin
			left,		-- mark links in left margin
			start,		-- collect links at start of object
			end		-- collect links at end of object

(ma)	mark=		MARK	mark to display as link		 DEFAULT:no

		Describes the mark to display, highlighting this link.
		(See mark previously for explanation of mark types.)

(li)	line=		LINE    (no,un,th,ov)			 DEFAULT:un

		Describes the line characteristics of a link.  Recommended
		values are: 

			none,		-- no line highlighting link
			under,		-- line under object (underline)
			through,	-- line through object (strikeout)
			over		-- line over object (overline)

(nu)	number=		UNITS	number of lines			 DEFAULT:1

		Describes the number of lines to use to highlight a link.
		Recommended values are: 1-n

(be)	before=		MARK	mark to display before link	 DEFAULT:no

		Describes the mark to display before the link.  (See mark
		previously for explanation of mark types.)

(af)	after=		MARK	mark to display after link	 DEFAULT:no

		Describes the mark to display after the link.  (See mark
		previously for explanation of mark types.)

(hi)	hide=		BOOL	hide link content		 DEFAULT:0

		Describes the intent to hide the content of a link.  This
		is included to handle the possibility of an object having
		a graphical mark which signifies a link where the actual
		textual component of the link (the text held between the <A>
		and it's matching </A>) is not intended to be displayed.  
		On a text-only display, the graphic might be ignored and 
		the text might be displayed in it's place. Recommended
		values are: 

			FALSE (0) and TRUE (not FALSE)

-----------------------------------------------------------------------------



APPENDIX I
EXAMPLE STYLESHEET FOR AN IMAGINARY HTML DOCUMENT
-----------------------------------------------------

# DEFAULT for all succeeding objects..

@DEFAULT fo(fa=ti,sp=pr,si=14,we=me,sl=ro,fo=in,bo=in,li=no,nu=1,fn='')
ju(st=le,hy=0,ke=0) co(nu=1,wi=80) br(lo=af,ob=it) 
ma(ob=it,pr=no,be=0,re=no,su=no,af=0) 
ve(be=0,af=0,sp=0,of=0) in(le=0,ri=0,fi=0)
li(lo=in,ma=no,li=un,nu=1,be=no,af=no,hi=0)

# TITLE object style (font size becomes 24)
@TITLE fo(si=24) 

# BODY object style (font family becomes helvetica, font size becomes 18)
@BODY fo(fa=he,si=18) 

# PARAGRAPH SEPERATOR object style (break after item, vertical space after =1)
@P br(lo=af,ob=it) ve(af=1)

# Headers
@H1 fo(si=32,we=bo) ve(be=1,af=2) @H2 fo(si=24,we=bo) ve(be=1,af=2)
@H3 fo(si=18,we=bo) ve(be=1,af=2) @H4 fo(si=16,we=bo) ve(be=1,af=2)
@H5 fo(si=14,we=bo) ve(be=1,af=2) @H6 fo(si=12,we=bo) ve(be=1,af=2)

# Some List Stuff
@UL in(le=5)
@LI ma(pr=ro,be=4) in(le=10,ri=10) 

# Standards
@B fo(we=bo) @I fo(sl=it) @U fo(li=un, nu=1)

# Anchors with some colour
@A fo(fo='yellow',ba='black')


-----------------------------------------------------------------------------

APPENDIX II
Stylesheet Layout and Parsing Considerations	--	(TECHNICAL DETAIL)
--------------------------------------------

	An example stylesheet follows the discussion of the various styles,
and details the recommended layout of a stylesheet.

	Each element of the stylesheet is uniquely marked and the name of 
each style and style attribute has been chosen to be unique to the first 
two letters, which makes parsing the style-sheet a simple task.

Parsing Rule #1:

	Lines which do not have as their first non-whitespace character
	either an '@' which signals the beginning of a new object definition 
	or an alphabetic [a-zA-Z], will be ignored to the end of the line.

Parsing Rule #2:

	Next we throw out all the newlines and scan the remaining buffer.
	An '@' (at-sign) signals the beginning of a new HTML object definition.

Parsing Rule #3:
	
	After the '@' and possible intervening whitespace, we expect the name 
	of an HTML object (eg. TITLE, H1, B, STRONG, etc.)

Parsing Rule #4:

	After the name, and intervening whitespace, we expect at least two
	characters which signal the beginning of a style. Legal values are:
		fo, ju, co, br, ma, ve, in, li

Parsing Rule #5:

	After the two character style specifier, scan to the '(' (open-paren)
	and ignore intervening data or whitespace.

... (I think you get the idea, but I'll fill this in later if necessary)

-----------------------------------------------------------------------------


APPENDIX III
Use of Stylistic Hints or Suggestions - Typical Scenario -- (MUY TECHNICAL!!)
--------------------------------------------------------

	A renderer which understands the <LINK STYLE> tag would use the URL
to retrieve the stylesheet, and run it through the WWW style library,
(libStyle.a -- to be supplied, currently in development.)

	Once the stylesheet has been loaded, when an HTML element is 
encountered within the document, the renderer has the option of calling the
style library, asking for advice on how to render the specific element.

For example:	(scans all styles and renderer sets attributes)

		***Renderer begins to scan document***

		***Renderer recognizes <LINK STYLE={URL}>***

		  loadStyleSheet( {URL});

		***Renderer sees a <TITLE> tag in the document***

		  current = firstStyle( styles = queryStyleSheet( TITLE));

		  while( current) {

		    switch( styleName( current)) {

		      case FONT: {
			while( nextAttr( current)) {

			  switch( attr) {

			    case FAMILY:
			      switch( attrValue(attr)) {

				case TIMES:
					***Renderer decides what to do here***
				case HELVETICA:
				case SYSTEM:
				case TYPEWRITER:
				default:
			      }
			    case SPACING:
			    case SIZE:
			    case WEIGHT:
			    case SLANT:
			    case FOREGROUND:
			    case BACKGROUND:  
			    case LINE:
			    case LONGNAME:
			    default:
			  }
			}
			break;
		      }
		      case JUSTIFY:
			break;
		      case COLUMNS:
			break;
		      case BREAK:
			break;
		      case MARK:
			break;
		      case VERTICAL:
			break;
		      case INDENT:
			break;
		      case LINK:
			break;
		      default:
			***Ignore -- Illegal style***
		    }
		    current = nextStyle( styles);
		  }


Another example:	(renderer sets attributes only for styles needed)

		***Renderer begins to scan document***

		***Renderer recognizes <LINK STYLE={URL}>***

		  loadStyleSheet( {URL});

		***Renderer sees a <TITLE> tag in the document***

			switch( getValue(TITLE, FONT, FAMILY)) {
			*** renderer decides what to do here***
				case UNKNOWN:	
				case TIMES:
				case HELVETICA:
				case SYSTEM:
				case TYPEWRITER:
			}

		***Renderer sees a <H1> tag in the document***

			switch( getValue( H1, BREAK, STYLE)) {
				case UNKNOWN:
				case BEFORE:
				case AFTER:
			}

		  etc.



From daemon  Fri Jun 11 01:14:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07100; Fri, 11 Jun 93 01:14:04 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07096; Fri, 11 Jun 93 01:14:02 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25543; Fri, 11 Jun 1993 01:36:00 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA17132; Thu, 10 Jun 1993 18:28:38 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306102328.AA17132@stat1.cc.ukans.edu>
Subject: <TITLE>Current Server Work at O'Reilly....</TITLE> (fwd)
To: www-talk@nxoc01.cern.ch
Date: Thu, 10 Jun 93 18:28:38 CDT
X-Mailer: ELM [version 2.3 PL2]

> 
> 	The theory here is that documents can be rewritten 'on the fly' to
> reference only those capabilities which the user has at hand.
> 
> 	Further assume that I have a method of managing documents locally which 
> return portions of a document based on capability metrics.
> 
> 	For example:
> 
> 	I am a user, using Lynx on a VTxxx.  When I make a request to the 
> server, Lynx also sends:
> 
> 		User_Agent: Lynx 1.06 TEXT MAIL NEWS
> 
> since these are the capabilities which Lynx running on my host supports.
> 
> 	The server then retrieves the following document
> 
> ------------------------------------------------------------------------------
> <HTML>
> <HEAD>
> <TITLE>This is a document</TITLE>
> </HEAD>
> <BODY>
> 
> #ifdef GRAPHICS
> 
> #	ifdef GIF
> 
> 	<IMG HREF=(some gif file)>
> 
> #	elif JPG
> 
> 	<IMG HREF=(some jpg file)>
> 
> #	endif
> 
> #else
> 	There is an inline graphic here which cannot be rendered 
> 	locally.  It can be retrieved by hand as:
> 
> #	ifdef FTP
> 
> 	ftp://hostname/dir/file
> 
> #	elif MAIL
> 
> 	"/dir/file" from hostname
> 
> 	by using the the ftp->mail gateway at Hostname with the 
> 	following commands:
> 		Get blahblahblahblahblah
> #	endif
> 
> 
> #endif
> 
> </BODY>
> </HTML>


I don't think that this would be a good way of accomplishing your goals.
The ".multi" extension used to serve documents of varying types would
be a better approach to the problem.   If a link <img src="dinosaur.multi">
was used the client would attempt to retrieve it telling the server
what types it can handle.  In the Lynx case it would say it could handle
".txt" types and could recieve a text description of the image in question.
Xmosaic would respond with ".gif" and ".xbm" types and would receive the
image.  Other browsers may choose to download the picture and use an 
external viewer to show the image and put a text box in to show where
the picture should have appeared.  If an acceptable type is not available
then the client should respond with an appropriate message explaining
the problem, and pointing out that an image should have appeared "here".

I have been meaning to make Lynx image "aware" but have not had the 
time to do so yet.

:lou 
montulli@ukanaix.cc.ukans.edu

From daemon  Fri Jun 11 08:04:25 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15805; Fri, 11 Jun 93 08:04:27 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15801; Fri, 11 Jun 93 08:04:25 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AB27617; Fri, 11 Jun 1993 08:26:23 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22353
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 11 Jun 93 01:26:22 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA08775; Fri, 11 Jun 93 01:29:02 -0500
Date: Fri, 11 Jun 93 01:29:02 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306110629.AA08775@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Using Mosaic by remote control
X-Md4-Signature: 0c5fd1296b5942283dc9f1dc02726057

Documentation on Mosaic 1.1's remote control functionality is
available now in...

http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/remote-control.html

...the text is below.

I'm interested to see how people use this and to get feedback on how
it can be improved.

Thanks,
Marc


Using Mosaic by Remote Control
******************************

NCSA Mosaic (version 1.1 or later) can be operated by remote
control.  This means that an application -- any application --
can directly operate Mosaic, by specifying documents on the
network to view, directing it to open new windows, etc.  

How It Works
============

Mosaic has a signal handler for the "extra", normally unused
signal called SIGUSR1.  When that signal is received by a running
Mosaic process, the signal handler determines its process ID or 
pid (via the getpid() call) and derives a config filename: 

        /tmp/xmosaic.pid

So, for example, if the running Mosaic's pid is 1343, the config
filename is: 

        /tmp/xmosaic.1343

This config file is assumed to contain two lines of text: 

 o The first line is a directive, either goto (which means jump
   right to a document) or newwin (which means open a new
   window and use that window to display a document).  
 o The second line is the URL of the document to download
   and view.  

So, an example config file that tells Mosaic to view document 
file://ftp.ncsa.uiuc.edu/ in an already-open window is: 

goto
file://ftp.ncsa.uiuc.edu/

(Note that a goto command will cause the document to be viewed in the
most-recently-used document view window, if a Mosaic session has
multiple open windows.)

How To Use It
=============

One way to use this capability is to take advantage of Mosaic's
interaction and display functionality to provide cheap and
low-overhead online, possibly context-sensitive help for other
applications.  The first time help is requested in your application,
fork off a new Mosaic process with a command-line argument
corresponding to the appropriate help document, which can of
course be pulled over the network in real time or retrieved from
the local disk.  Subsequent help requests can use the running
Mosaic process by writing a config file (the Mosaic process ID is
returned from the initial fork() call) and using the kill() call
to send a SIGUSR1.  

Another use is Mosaic as a general hypermedia display engine for
mail readers, news readers, HTML editors, and similar
applications.  For example, we're currently building capabilities
into the Emacs html-mode.el package developed by one of the
Mosaic authors (marca@ncsa.uiuc.edu) to provide transparent
HTML previewing via a single keystroke.  Other people are
putting hooks into existing mail and news handlers.  More
information will be available when it's available.  

Future Possibilities
====================

Have any ideas for future possibilities along these lines?  We're
thinking both in terms of what can be done with this method as
well as more advanced capabilities involving two-way network
communication for the future.  Drop us a line if you have any
interesting thoughts.  

Acknowledgements
================

Thanks much to Ken Evans (evans@phebos.aps.anl.gov) who
suggested the concept and contributed initial code.  

mosaic-x@ncsa.uiuc.edu 


From daemon  Fri Jun 11 10:34:13 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17380; Fri, 11 Jun 93 10:34:15 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17376; Fri, 11 Jun 93 10:34:13 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13842; Fri, 11 Jun 1993 10:56:11 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 11 Jun 93 09:48:26 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00997; Fri, 11 Jun 93 09:54:24 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306110854.AA00997@manuel.hpl.hp.com>
Subject: Re: Style sheets for HTML
To: raisch@ora.com
Date: Fri, 11 Jun 93 9:54:22 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Dear Rob,

First a few words on what I am doing ...

I am drafting the DTD for HTML+ which will be the successor to HTML. The
new standard will be largely compatible with HTML but will standardise
features such as embedded images, figures and add new ones such as tables,
and forms. You can look at the current state of the DTD (work in progress)
at "ftp://info.cern.ch/pub/www/dev/htmlplus.dtd.txt". I hope to finalise
the HTML+ standard this summer, and issue it formally as an RFC.

We would very much like to ensure the new standard meets the needs for a
generic, lightweight, presentation independent delivery format for publishers
and the Internet community at large. Terry Allen, editor of the Digital Media
Group has already been very helpful, and I would like to encourage other
members of O'Reilly & Associates to contribute their views too.

I read your style sheet proposal with great interest, and will add the
"style" attribute to the LINK tag attribute definition in the DTD.

Have you considered allowing multiple stylesheets to cover different uses?
This would mean that you could specify one style for printing and another for
online use. You might want to go further and distinguish between X windows,
PC's and palmtops.

My suggestion is that the LINK element takes another attribute which specifies
the intended media, e.g.

        <LINK style="http://ora.com/styles/paper_a4" media="paper/A4">
        <LINK style="http://ora.com/styles/paper_B5" media="paper/B5">
        <LINK style="http://ora.com/styles/xwindows" media="xwindows">        

Multiple such elements could be included in each HTML+ document.

Note that the media attribute value can encode further parameters - paper
size in the above example. By defining the media attribute as taking a CDATA
value, we can allow for new types of media without needing to change the DTD.

Comments please?

Dave Raggett,

-----------------------------------------------------------------------------
Hewlett Packard Laboratories,           +44 272 228046
Bristol, England                        dsr@hplb.hpl.hp.com

From daemon  Fri Jun 11 12:45:22 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18680; Fri, 11 Jun 93 12:45:24 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18676; Fri, 11 Jun 93 12:45:22 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09574; Fri, 11 Jun 1993 13:07:20 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA11007; Fri, 11 Jun 93 13:07:15 +0200
Date: Fri, 11 Jun 93 13:07:15 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306111107.AA11007@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: montulli@stat1.cc.ukans.edu (Lou Montulli)
Subject: Re: Support for CSO and gopher type 2
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch




What is the status of the CSO protocol?  Should we

	(a) 	Include it in the libWWW access code to allow all W3
		clients to use it
		
	(b) 	Make a gateway so that the existing 100 CSO
		servers are
		accessible
	
	(c) 	Get someone to write an HTTP server for the CSO
		database so that all CSO servers should be
		upgraded?

There aren'tany I know of over here, someone please fill me in on
CSO history?

	Tim
	
Begin forwarded message:

From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Date: Sat, 13 Mar 93 15:18:26 CST

As many of you may know, Gopher file type 2 is a CSO nameserver 

interface.  All of the WWW clients that I have seen do not support
this file type.  Why not?

A page similar to the Gopher index page could be displayed,
with some additional instructions on how to construct a query.

For instance:  To search on all fields simply say "query STRING"
	       To search on a particular field like a name field
	       say "query name=STRING"

The client simply has to send an extra "\nquit\n" to complete the
query, or cut off the connection when the string "200:Ok" or
"501:No matches to your query." is sent by the server. 


Considering the fact that there are over 100 CSO servers available
for these queries, doesn't it seem necessary to support them?

Maybe a new url type is in order:
	"cso://cso.univ.edu:105/"

:lou

From daemon  Fri Jun 11 12:56:51 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18904; Fri, 11 Jun 93 12:56:53 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18900; Fri, 11 Jun 93 12:56:51 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10571; Fri, 11 Jun 1993 13:18:49 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02183
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Fri, 11 Jun 93 06:18:40 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:montulli@stat1.cc.ukans.edu id AA09459; Fri, 11 Jun 93 06:21:22 -0500
Date: Fri, 11 Jun 93 06:21:22 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306111121.AA09459@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch
Cc: montulli@stat1.cc.ukans.edu (Lou Montulli), www-talk@nxoc01.cern.ch
Subject: Re: Support for CSO and gopher type 2
In-Reply-To: <9306111107.AA11007@www3.cern.ch>
References: <9306111107.AA11007@www3.cern.ch>
X-Md4-Signature: 25e6c2d5d855634ff87e4cde57b2e1ef

Mosaic 1.1 support CSO servers through Gopher via an addition to
HTGopher.c in the stock libwww; the code was contributed by, let's
see, can't quite remember his name, comes from a flat state but it's
not Illinois or Iowa... hmmm... *scratch scratch*...

I vote we support it that way.

Marc


From daemon  Fri Jun 11 17:52:43 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25686; Fri, 11 Jun 93 17:52:45 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25682; Fri, 11 Jun 93 17:52:43 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07799; Fri, 11 Jun 1993 18:14:43 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA17855; Fri, 11 Jun 1993 11:07:27 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306111607.AA17855@stat1.cc.ukans.edu>
Subject: Re: Support for CSO and gopher type 2
To: www-talk@nxoc01.cern.ch
Date: Fri, 11 Jun 93 11:07:26 CDT
In-Reply-To: <9306111121.AA09459@wintermute.ncsa.uiuc.edu>; from "Marc Andreessen" at Jun 11, 93 6:21 am
X-Mailer: ELM [version 2.3 PL2]

> 
> Mosaic 1.1 support CSO servers through Gopher via an addition to
> HTGopher.c in the stock libwww; the code was contributed by, let's
> see, can't quite remember his name, comes from a flat state but it's
> not Illinois or Iowa... hmmm... *scratch scratch*...
> 
> I vote we support it that way.      [CSO support in the WWWlibrary]
> 
> Marc
> 
It's not that flat.  As a matter of fact I live at the top of a great
big hill.  (yaaaah, that's the ticket.  With my wife Morgan Fairchild... ;)

I vote the same way.  (big suprise!)

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!     Jurassic Park - The Movie     *
  **************************************************************************

From daemon  Fri Jun 11 20:10:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29185; Fri, 11 Jun 93 20:11:00 MET DST
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29181; Fri, 11 Jun 93 20:10:58 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28401; Fri, 11 Jun 1993 20:32:55 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0o4DuG-000EagC; Fri, 11 Jun 93 14:32 EDT
Message-Id: <m0o4DuG-000EagC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: Gopher support in X Mosaic, cosmetic suggestion
Date: Fri, 11 Jun 1993 14:32:51 -0400
From: Edward Vielmetti <emv@garnet.msen.com>

I'd like to make a teeny tiny suggestion as to how Gophers should look
in X Mosaic.

Currently if you connect to a gopher you get a title in the Document Title
part of the screen, but only a "select one of" headline in the main
screen.  This is kind of, well, not terribly attractive.  

Putting the Document Title in the main gopher screen in a nice bold-faced
font would do some good, I think.

If/when "gopher+" appears, there are some other nice things that could
be put in to spruce up the normal gopher menu appearance, e.g. some of
the "g+" attributes map pretty well to the standard parts of the screen
layouts of most web screens.

(Just got mosaic running on BSDI, it's awesome folks - now I want to
go back and re-do some of the mucking around I did with gopher...)

--Ed

From daemon  Fri Jun 11 20:14:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29291; Fri, 11 Jun 93 20:14:21 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29287; Fri, 11 Jun 93 20:14:19 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29442; Fri, 11 Jun 1993 20:36:18 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576760-1>; Fri, 11 Jun 1993 14:36:05 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA03086; Fri, 11 Jun 93 14:25:51 EDT
Date: Fri, 11 Jun 1993 14:25:51 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306111825.AA03086@begbick.law.cornell.edu.law.cornell.edu>
To: montulli@stat1.cc.ukans.edu
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Lou Montulli's message of Fri, 11 Jun 93 11:07:26 CDT <9306111607.AA17855@stat1.cc.ukans.edu>
Subject: Support for CSO and gopher type 2

I vote with Lou and Marc.  No surprise there, I expect.

Tb.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Fri Jun 11 21:24:17 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00791; Fri, 11 Jun 93 21:24:22 MET DST
Return-Path: <torben%Hawaii.Edu@galaxy.net.hawaii.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00785; Fri, 11 Jun 93 21:24:17 MET DST
Received: from galaxy.net.Hawaii.Edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07279; Fri, 11 Jun 1993 21:46:07 +0200
Received: from foralie.net.hawaii.edu ([132.160.3.1]) by galaxy.net.Hawaii.Edu with SMTP id <119754>; Fri, 11 Jun 1993 09:43:44 -1000
Date: 	Fri, 11 Jun 1993 09:44:08 -1000
From: Torben Noerup Nielsen <torben@hawaii.edu>
Sender: Torben Noerup Nielsen <torben@hawaii.edu>
Subject: Re: Style sheets for HTML
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: raisch@ora.com, www-talk@nxoc01.cern.ch
In-Reply-To: <9306110854.AA00997@manuel.hpl.hp.com>
Message-Id: <MailManager.739827848.151.torben@foralie.net.hawaii.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dave,

I realize this has come up before, but how about really doing something about
equation support? There are lots of documents I would like to put into the
Web, but without support for embedded equations, it's really quite difficult.
Something simple like eqn support would be great. And eqn shouldn't be all
that hard to parse either.....

Thanks, Torben

P.S. What would be particularly nice is to be able to use anchors to jump to
other equations....


From daemon  Sat Jun 12 01:47:04 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05269; Sat, 12 Jun 93 01:47:06 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05264; Sat, 12 Jun 93 01:47:04 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07990; Sat, 12 Jun 1993 02:09:03 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11714>; Fri, 11 Jun 1993 17:08:55 PDT
Received: by holmes.parc.xerox.com id <16134>; Fri, 11 Jun 1993 17:08:44 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Fri, 11 Jun 1993 17:08:36 -0700 (PDT)
Message-Id: <0g6Fu48B0KGW5geexr@holmes.parc.xerox.com>
Date: 	Fri, 11 Jun 1993 17:08:36 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: timbl@www3.cern.ch
Subject: CR not stripped properly on FTP transfers
Cc: www-talk@nxoc01.cern.ch

OK, I think I see the problem.

1)  HTFTP.c always uses ASCII mode FTP transfers.

2)  In ASCII mode transfers of UNIX source documents, most UNIX ftp
servers always put a CR before every LF.

[Note:  It's not clear under what conditions this *should* be done (On
UNIX, every file is in some sense a binary file, interpretable only by
an "understanding" program.  On other system, say VMS, the notion of
"line" is in the file system for line-oriented files, and VMS FTP
servers might choose, for non-line-oriented files being transmitted in
ASCII mode, not to put CR before every line feed, but just at the end of
every block, or not at all (after all, no "lines").).  The RFC for FTP
says:

>         3.1.1.1.  ASCII TYPE

>             This is the default type and must be accepted by all FTP
>             implementations.  It is intended primarily for the transfer
>             of text files, except when both hosts would find the EBCDIC
>             type more convenient.

>             The sender converts the data from an internal character
>             representation to the standard 8-bit NVT-ASCII
>             representation (see the Telnet specification).  The receiver
>             will convert the data from the standard form to his own
>             internal form.

>             In accordance with the NVT standard, the <CRLF> sequence
>             should be used where necessary to denote the end of a line
>             of text.  (See the discussion of file structure at the end
>             of the Section on Data Representation and Storage.)

Since HTFTP never seems to transmit the STRU command, we assume that the
file is transferred with structure "file-structure", which means,
according to the RFC, that

>          3.1.2.1.  FILE STRUCTURE

>             File structure is the default to be assumed if the STRUcture
>             command has not been used.

>             In file-structure there is no internal structure and the
>             file is considered to be a continuous sequence of data
>             bytes.

The TELNET RFC (which I believe is still 854; does something later
obsolete it?) says about CR and LF,

>       Therefore, the sequence "CR LF" must be treated as a single "new
>       line" character and used whenever their combined action is
>       intended; the sequence "CR NUL" must be used where a carriage
>       return alone is actually desired; and the CR character must be
      avoided in other contexts.

So my reading would be that for UNIX files being transmitted with mode =
"ASCII" and structure = "file-structure", the sender would have to put a
NUL character after every CR, and should *not* put a CR in front of any
LF, since there really are no "lines of text" in the UNIX file system.

This is probably why I'm not a net.wizard.

end Note]

3)  WWW should then change CR-LF pairs to simple LF, but there is no
routine which does this (HTCopyNoCR discards *all* CR's, which is OK for
text documents (usually), but not for binary documents like tar files). 
There's also no easy way in HTFormat.c to "think" about this, because
it's a characteristic of the input stream, not of the input format
(which is something more like "www/mime").

4)  Because of this, "binary" documents are copied to the output with
HTCopy, which does not strip any characters, even the ones which
*should* be stripped.

So the problem is that the actions of the FTP protocol are not being
reversed anywhere.  This particular trait is a characteristic of the
transfer protocol being used, not of the document's input format or of
the transfer-encoding.  Seems like the right thing to do is to remove
the simple file_number model used in HTFormat.c, and replace it with an
input stream, which could then be specialized as necessary to remove the
actions of the transfer protocol, if necessary.  Another possibility
would be to always use BINARY mode transfers in the FTP module (since
that's what HTFormat.c seems to expect), and add CR if necessary in the
WWW library.  Perhaps both of these should be implemented.

Bill

From daemon  Sat Jun 12 02:06:05 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05476; Sat, 12 Jun 93 02:06:09 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05471; Sat, 12 Jun 93 02:06:05 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09269; Sat, 12 Jun 1993 02:28:05 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA17610
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 11 Jun 93 19:27:51 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:timbl@www3.cern.ch id AA10547; Fri, 11 Jun 93 19:30:30 -0500
Date: Fri, 11 Jun 93 19:30:30 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306120030.AA10547@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: timbl@www3.cern.ch, www-talk@nxoc01.cern.ch
Subject: CR not stripped properly on FTP transfers
In-Reply-To: <0g6Fu48B0KGW5geexr@holmes.parc.xerox.com>
References: <0g6Fu48B0KGW5geexr@holmes.parc.xerox.com>
X-Md4-Signature: a14e1f217f0221962aee4a271e77e14f

Bill Janssen writes:
> [...] Another possibility would be to always use BINARY mode
> transfers in the FTP module (since that's what HTFormat.c seems to
> expect) [...]

One of the changes I made to libwww version 1 (well, 0.9-something)
for Mosaic was exactly that.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Sat Jun 12 03:00:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05957; Sat, 12 Jun 93 03:00:09 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05951; Sat, 12 Jun 93 03:00:02 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15780; Sat, 12 Jun 1993 03:22:01 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11849>; Fri, 11 Jun 1993 18:21:39 PDT
Received: by holmes.parc.xerox.com id <16134>; Fri, 11 Jun 1993 18:21:34 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Fri, 11 Jun 1993 18:21:21 -0700 (PDT)
Message-Id: <Eg6GyF0B0KGW9gefwF@holmes.parc.xerox.com>
Date: 	Fri, 11 Jun 1993 18:21:21 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: timbl@www3.cern.ch, Bill Janssen <janssen@parc.xerox.com>
Subject: Re: CR not stripped properly on FTP transfers
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <0g6Fu48B0KGW5geexr@holmes.parc.xerox.com>
References: <0g6Fu48B0KGW5geexr@holmes.parc.xerox.com>

Yes, changing HTFTP to use image mode for transfers seems to work well. 
Now tar file transfers work OK with -source.

But note that this quick (and dirty) fix has its own problems.  In
particular, if I fetch a text file from a Mac FTP server (or any ftp
server that doesn't use LF in its new-line string), the file will
contain CR where there should be LF.  It's a shame we don't have two
different URL schemes for FTP:  one (say binaryftp:foo) would be for
binary documents, and the other (say, textftp:foo) would be for text
documents.

Here's my version of HTFTP.c/HTFTPLoad() [note that it also has patches
for our Internet gateway scheme, please ignore them]:

/*	Retrieve File from Server
**	-------------------------
**
** On entry,
**	name		WWW address of a file: document, including hostname
** On exit,
**	returns		Socket number for file if good.
**			<0 if bad.
*/
PUBLIC int HTFTPLoad
ARGS4 (
  CONST char *,			name,
  HTParentAnchor *,		anchor,
  HTFormat,			format_out,
  HTStream *,			sink
)
{
    BOOL isDirectory = NO;
    int status;
    int retry;			/* How many times tried? */
    HTFormat format;
    int transferType;
#define	ASCIITransferType	1
#define IMAGETransferType	2
    
    for (retry=0; retry<2; retry++) {	/* For timed out/broken connections */
    
	status = get_connection(name);
	if (status<0) return status;

#ifdef LISTEN
	status = get_listen_socket();
	if (status<0) return status;
    
#ifdef REPEAT_PORT
/*	Inform the server of the port number we will listen on
*/
	{
	    status = response(port_command);
	    if (status !=2) {		/* Could have timed out */
		if (status<0) continue;		/* try again - net error*/
		return -status;			/* bad reply */
	    }
	    if (TRACE) fprintf(stderr, "FTP: Port defined.\n");
	}
#endif
#else	/* Use PASV */
/*	Tell the server to be passive
*/
	{
	    char *p;
	    int reply, h0, h1, h2, h3, p0, p1;	/* Parts of reply */
	    status = response("PASV%c%c", CR, LF);
	    if (status !=2) {
		if (status<0) continue;		/* retry or Bad return */
		return -status;			/* bad reply */
	    }
	    for(p=response_text; *p; p++)
		if ((*p<'0')||(*p>'9')) *p = ' ';	/* Keep only digits */
	    status = sscanf(response_text, "%d%d%d%d%d%d%d",
		    &reply, &h0, &h1, &h2, &h3, &p0, &p1);
	    if (status<5) {
		if (TRACE) fprintf(stderr, "FTP: PASV reply has no inet address!\n");
		return -99;
	    }
	    passive_port = (p0<<8) + p1;
	    if (TRACE) fprintf(stderr, "FTP: Server is listening on port %d\n",
		    passive_port);
	}

/*	Open connection for data:
*/
	{
	    struct sockaddr_in soc_address;
	    int status = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
	    if (status<0) {
		(void) HTInetStatus("socket for data socket");
		return status;
	    }
	    data_soc = status;
	    
#ifdef IGATEWAY
	    Cannot use PASV with IGATEWAY with this code as written
#endif
	    soc_address.sin_addr.s_addr = control->addr;
	    soc_address.sin_port = htons(passive_port);
	    soc_address.sin_family = AF_INET;	    /* Family, host order  */
	    if (TRACE) fprintf(stderr,  
		"FTP: Data remote address is port %d, inet %d.%d.%d.%d\n",
			(unsigned int)ntohs(soc_address.sin_port),
			(int)*((unsigned char *)(&soc_address.sin_addr)+0),
			(int)*((unsigned char *)(&soc_address.sin_addr)+1),
			(int)*((unsigned char *)(&soc_address.sin_addr)+2),
			(int)*((unsigned char *)(&soc_address.sin_addr)+3));
    
	    status = connect(data_soc, (struct sockaddr*)&soc_address,
		    sizeof(soc_address));
	    if (status<0){
		(void) HTInetStatus("connect for data");
		NETCLOSE(data_soc);
		return status;			/* Bad return */
	    }
	    
	    if (TRACE) fprintf(stderr, "FTP data connected, socket %d\n", data_soc);
	}
#endif /* use PASV */
	status = 0;
        break;	/* No more retries */

    } /* for retries */
    if (status<0) return status;	/* Failed with this code */
    
/*	Ask for the file:
*/    
    {
        char *filename = HTParse(name, "", PARSE_PATH + PARSE_PUNCTUATION);
	char command[LINE_LENGTH+1];
	int retrieveStatus;
	
	if (!*filename) StrAllocCopy(filename, "/");
	sprintf(command, "TYPE I%c%c", CR, LF);
	status = response(command);
	if (status == 1)
	  transferType = IMAGETransferType;
	else
	  transferType = ASCIITransferType;
	sprintf(command, "RETR %s%c%c", filename, CR, LF);
	format = HTFileFormat(filename);
	status = response(command);
	if (status != 1) {  /* Failed : try to CWD to it */
	  if (transferType == IMAGETransferType)
	    /* change back to ASCII */
	    {
	      sprintf(command, "TYPE A%c%c", CR, LF);
	      status = response(command);
	      transferType = ASCIITransferType;
	    }
	  sprintf(command, "CWD %s%c%c", filename, CR, LF);
	  status = response(command);
	  if (status == 2) {  /* Successed : let's NAME LIST it */
	    isDirectory = YES;
	    sprintf(command, "NLST%c%c", CR, LF);
	    status = response (command);
	  }
	}
	free(filename);
	if (status != 1) return -status;		/* Action not started */
    }

#ifdef LISTEN
/*	Wait for the connection
*/
    {
	struct sockaddr_in soc_address;
        int	soc_addrlen=sizeof(soc_address);
	status = accept(master_socket,
			(struct sockaddr *)&soc_address,
			&soc_addrlen);
	if (status<0)
	    return HTInetStatus("accept");
	CTRACE(tfp, "TCP: Accepted new socket %d\n", status);
	data_soc = status;
    }
#else
/* @@ */
#endif
    if (isDirectory) {
	return read_directory (anchor, name, format_out, sink);
      /* returns HT_LOADED or error */
    } else {
	HTParseSocket(format, format_out,
		anchor, data_soc, sink);

	HTInitInput(control->socket);
	/* Reset buffering to control connection DD 921208 */
    
	status = NETCLOSE(data_soc);
	if (TRACE) fprintf(stderr, "FTP: Closing data socket %d\n", data_soc);
	if (status<0) (void) HTInetStatus("close");	/* Comment only */
	data_soc = -1;	/* invalidate it */
	
	status = response(NIL);		/* Pick up final reply */
	if (status!=2) return HTLoadError(sink, 500, response_text);

	if (transferType == IMAGETransferType)
	  /* change back to ASCII */
	  {
	    char command[10];

	    sprintf(command, "TYPE A%c%c", CR, LF);
	    status = response(command);
	  }
		
	return HT_LOADED;
    }       
} /* open_file_read */
/*	Retrieve File from Server
**	-------------------------
**
** On entry,
**	name		WWW address of a file: document, including hostname
** On exit,
**	returns		Socket number for file if good.
**			<0 if bad.
*/
PUBLIC int HTFTPLoad
ARGS4 (
  CONST char *,			name,
  HTParentAnchor *,		anchor,
  HTFormat,			format_out,
  HTStream *,			sink
)
{
    BOOL isDirectory = NO;
    int status;
    int retry;			/* How many times tried? */
    HTFormat format;
    int transferType;
#define	ASCIITransferType	1
#define IMAGETransferType	2
    
    for (retry=0; retry<2; retry++) {	/* For timed out/broken connections */
    
	status = get_connection(name);
	if (status<0) return status;

#ifdef LISTEN
	status = get_listen_socket();
	if (status<0) return status;
    
#ifdef REPEAT_PORT
/*	Inform the server of the port number we will listen on
*/
	{
	    status = response(port_command);
	    if (status !=2) {		/* Could have timed out */
		if (status<0) continue;		/* try again - net error*/
		return -status;			/* bad reply */
	    }
	    if (TRACE) fprintf(stderr, "FTP: Port defined.\n");
	}
#endif
#else	/* Use PASV */
/*	Tell the server to be passive
*/
	{
	    char *p;
	    int reply, h0, h1, h2, h3, p0, p1;	/* Parts of reply */
	    status = response("PASV%c%c", CR, LF);
	    if (status !=2) {
		if (status<0) continue;		/* retry or Bad return */
		return -status;			/* bad reply */
	    }
	    for(p=response_text; *p; p++)
		if ((*p<'0')||(*p>'9')) *p = ' ';	/* Keep only digits */
	    status = sscanf(response_text, "%d%d%d%d%d%d%d",
		    &reply, &h0, &h1, &h2, &h3, &p0, &p1);
	    if (status<5) {
		if (TRACE) fprintf(stderr, "FTP: PASV reply has no inet address!\n");
		return -99;
	    }
	    passive_port = (p0<<8) + p1;
	    if (TRACE) fprintf(stderr, "FTP: Server is listening on port %d\n",
		    passive_port);
	}

/*	Open connection for data:
*/
	{
	    struct sockaddr_in soc_address;
	    int status = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
	    if (status<0) {
		(void) HTInetStatus("socket for data socket");
		return status;
	    }
	    data_soc = status;
	    
#ifdef IGATEWAY
	    Cannot use PASV with IGATEWAY with this code as written
#endif
	    soc_address.sin_addr.s_addr = control->addr;
	    soc_address.sin_port = htons(passive_port);
	    soc_address.sin_family = AF_INET;	    /* Family, host order  */
	    if (TRACE) fprintf(stderr,  
		"FTP: Data remote address is port %d, inet %d.%d.%d.%d\n",
			(unsigned int)ntohs(soc_address.sin_port),
			(int)*((unsigned char *)(&soc_address.sin_addr)+0),
			(int)*((unsigned char *)(&soc_address.sin_addr)+1),
			(int)*((unsigned char *)(&soc_address.sin_addr)+2),
			(int)*((unsigned char *)(&soc_address.sin_addr)+3));
    
	    status = connect(data_soc, (struct sockaddr*)&soc_address,
		    sizeof(soc_address));
	    if (status<0){
		(void) HTInetStatus("connect for data");
		NETCLOSE(data_soc);
		return status;			/* Bad return */
	    }
	    
	    if (TRACE) fprintf(stderr, "FTP data connected, socket %d\n", data_soc);
	}
#endif /* use PASV */
	status = 0;
        break;	/* No more retries */

    } /* for retries */
    if (status<0) return status;	/* Failed with this code */
    
/*	Ask for the file:
*/    
    {
        char *filename = HTParse(name, "", PARSE_PATH + PARSE_PUNCTUATION);
	char command[LINE_LENGTH+1];
	int retrieveStatus;
	
	if (!*filename) StrAllocCopy(filename, "/");
	sprintf(command, "TYPE I%c%c", CR, LF);
	status = response(command);
	if (status == 1)
	  transferType = IMAGETransferType;
	else
	  transferType = ASCIITransferType;
	sprintf(command, "RETR %s%c%c", filename, CR, LF);
	format = HTFileFormat(filename);
	status = response(command);
	if (status != 1) {  /* Failed : try to CWD to it */
	  if (transferType == IMAGETransferType)
	    /* change back to ASCII */
	    {
	      sprintf(command, "TYPE A%c%c", CR, LF);
	      status = response(command);
	      transferType = ASCIITransferType;
	    }
	  sprintf(command, "CWD %s%c%c", filename, CR, LF);
	  status = response(command);
	  if (status == 2) {  /* Successed : let's NAME LIST it */
	    isDirectory = YES;
	    sprintf(command, "NLST%c%c", CR, LF);
	    status = response (command);
	  }
	}
	free(filename);
	if (status != 1) return -status;		/* Action not started */
    }

#ifdef LISTEN
/*	Wait for the connection
*/
    {
	struct sockaddr_in soc_address;
        int	soc_addrlen=sizeof(soc_address);
	status = accept(master_socket,
			(struct sockaddr *)&soc_address,
			&soc_addrlen);
	if (status<0)
	    return HTInetStatus("accept");
	CTRACE(tfp, "TCP: Accepted new socket %d\n", status);
	data_soc = status;
    }
#else
/* @@ */
#endif
    if (isDirectory) {
	return read_directory (anchor, name, format_out, sink);
      /* returns HT_LOADED or error */
    } else {
	HTParseSocket(format, format_out,
		anchor, data_soc, sink);

	HTInitInput(control->socket);
	/* Reset buffering to control connection DD 921208 */
    
	status = NETCLOSE(data_soc);
	if (TRACE) fprintf(stderr, "FTP: Closing data socket %d\n", data_soc);
	if (status<0) (void) HTInetStatus("close");	/* Comment only */
	data_soc = -1;	/* invalidate it */
	
	status = response(NIL);		/* Pick up final reply */
	if (status!=2) return HTLoadError(sink, 500, response_text);

	if (transferType == IMAGETransferType)
	  /* change back to ASCII */
	  {
	    char command[10];

	    sprintf(command, "TYPE A%c%c", CR, LF);
	    status = response(command);
	  }
		
	return HT_LOADED;
    }       
} /* open_file_read */

From daemon  Sat Jun 12 14:56:54 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10166; Sat, 12 Jun 93 14:56:57 MET DST
Return-Path: <M.T.Hamilton@lut.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10162; Sat, 12 Jun 93 14:56:54 MET DST
Received: from genie.lut.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20407; Sat, 12 Jun 1993 15:18:55 +0200
Message-Id: <9306121318.AA20407@dxmint.cern.ch>
Received: from genie.lut.ac.uk by genie.lut.ac.uk id <19459-0@genie.lut.ac.uk>;
          Sat, 12 Jun 1993 14:23:11 +0100
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion
To: www-talk@nxoc01.cern.ch
Date: Sat, 12 Jun 1993 14:23:10 +0100 (BST)
In-Reply-To: <m0o4DuG-000EagC@garnet.msen.com> from "Edward Vielmetti" at Jun 11, 93 07:32:51 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 402
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Sender: M.T.Hamilton@lut.ac.uk

Said Ed:

/ Currently if you connect to a gopher you get a title in the Document Title
/ part of the screen, but only a "select one of" headline in the main
/ screen.  This is kind of, well, not terribly attractive.

How about in-lined images of the gopher object types?  It's a bit
difficult to navigate when you have to guess which button is an 
index, and which is a directory, and ... :-)

Martin


From daemon  Sun Jun 13 00:20:14 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15420; Sun, 13 Jun 93 00:20:16 MET DST
Return-Path: <WIGGINS@msu.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15416; Sun, 13 Jun 93 00:20:14 MET DST
Received: from ibm.cl.msu.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13843; Sun, 13 Jun 1993 00:42:17 +0200
Resent-Message-Id: <9306122242.AA13843@dxmint.cern.ch>
Message-Id: <9306122242.AA13843@dxmint.cern.ch>
Received: from MSU.BITNET by msu.edu (IBM VM SMTP V2R2) with BSMTP id 2574;
   Sat, 12 Jun 93 18:42:24 EDT
Received: by MSU (Mailer R2.08 PTF008) id 1261; Sat, 12 Jun 93 18:42:24 EDT
Resent-Date:  Sat, 12 Jun 93 18:40:01 EDT
Resent-From: Richard W Wiggins <WIGGINS@msu.edu>
Resent-To: www-talk@nxoc01.cern.ch
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion
To: www-talk@nxoc01.cern.ch
Date: Sat, 12 Jun 1993 14:23:10 +0100 (BST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 402
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>

Hear hear!  The Gopher client for the Next is a good model in this
respect.

/Rich Wiggins, Gopher Coordinator, Michigan State U

(PS -- hmmm... Gopher discussions in the Mime group, Gopher-related
suggestions for Mosaic in the WWW group -- maybe the IIIR dream
is taking hold!)

----------------------------Original message----------------------------
Said Ed:

/ Currently if you connect to a gopher you get a title in the Document Title
/ part of the screen, but only a "select one of" headline in the main
/ screen.  This is kind of, well, not terribly attractive.

How about in-lined images of the gopher object types?  It's a bit
difficult to navigate when you have to guess which button is an
index, and which is a directory, and ... :-)

Martin

From daemon  Sun Jun 13 01:09:15 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15688; Sun, 13 Jun 93 01:09:16 MET DST
Return-Path: <cshotton@oac.hsc.uth.tmc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15684; Sun, 13 Jun 93 01:09:15 MET DST
Received: from oac.hsc.uth.tmc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17813; Sun, 13 Jun 1993 01:31:17 +0200
Message-Id: <9306122331.AA17813@dxmint.cern.ch>
Received: from oacpslip2.hsc.uth.tmc.edu by oac.hsc.uth.tmc.edu with SMTP
	(1.37.109.4/16.2) id AA13620; Sat, 12 Jun 93 18:26:35 -0500
Date: Sat, 12 Jun 1993 18:32:14 -0600
To: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
From: cshotton@oac.hsc.uth.tmc.edu
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion
Cc: www-talk@nxoc01.cern.ch

>----------------------------Original message----------------------------
>Said Ed:
>
>/ Currently if you connect to a gopher you get a title in the Document Title
>/ part of the screen, but only a "select one of" headline in the main
>/ screen.  This is kind of, well, not terribly attractive.
>
>How about in-lined images of the gopher object types?  It's a bit
>difficult to navigate when you have to guess which button is an
>index, and which is a directory, and ... :-)

Seems to me people are addressing the wrong end of the pipe with regard to
gopher support. XMosaic shouldn't have to do anything in particular with
gopher info. Shouldn't it really be up to the HTTP server (or gateway) to
present gopher information in a more palatable form? It's a very minor
change to NCSA's HTTP server to get it to put out nice looking gopher
listings with in-lined images, etc. for example.

To do this, all you have to do is modify a few of the fprintf lines in the
spew_and_free_array subroutine inside http_gopher.c.
-----------------------------------------------------------------------
Chuck Shotton
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."


From daemon  Sun Jun 13 10:28:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18327; Sun, 13 Jun 93 10:29:01 MET DST
Return-Path: <M.T.Hamilton@lut.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18323; Sun, 13 Jun 93 10:28:59 MET DST
Received: from avarice.lut.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02198; Sun, 13 Jun 1993 10:51:02 +0200
Message-Id: <9306130851.AA02198@dxmint.cern.ch>
Received: from genie.lut.ac.uk by avarice.lut.ac.uk 
          id <01969-0@avarice.lut.ac.uk>; Sun, 13 Jun 1993 09:55:19 +0100
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion
To: www-talk@nxoc01.cern.ch
Date: Sun, 13 Jun 1993 09:55:18 +0100 (BST)
In-Reply-To: <28569.9306122330@hpd.lut.ac.uk> from "cshotton@oac.hsc.uth.tmc.edu" at Jun 12, 93 06:32:14 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 494
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Sender: M.T.Hamilton@lut.ac.uk

Chuck said:

/ Seems to me people are addressing the wrong end of the pipe with regard to
/ gopher support. XMosaic shouldn't have to do anything in particular with
/ gopher info. Shouldn't it really be up to the HTTP server (or gateway) to
/ present gopher information in a more palatable form? It's a very minor
/ change to NCSA's HTTP server to get it to put out nice looking gopher
/ listings with in-lined images, etc. for example.

Woah!  What happened to my bandwidth ?!? :-) 

Martin.


From daemon  Sun Jun 13 12:01:38 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18620; Sun, 13 Jun 93 12:01:40 MET DST
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18616; Sun, 13 Jun 93 12:01:38 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09186; Sun, 13 Jun 1993 12:23:42 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA28041 (5.65b/3.8/CWI-Amsterdam); Sun, 13 Jun 1993 12:23:41 +0200
Received: by voorn.cwi.nl with SMTP
	id AA04219 (5.65b/3.8/CWI-Amsterdam); Sun, 13 Jun 1993 12:23:41 +0200
Message-Id: <9306131023.AA04219=guido@voorn.cwi.nl>
To: cshotton@oac.hsc.uth.tmc.edu
Cc: Martin Hamilton <M.T.Hamilton@lut.ac.uk>, www-talk@nxoc01.cern.ch
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion 
In-Reply-To: Your message of "Sat, 12 Jun 1993 18:32:14 MDT."
             <9306122331.AA17813@dxmint.cern.ch> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Sun, 13 Jun 1993 12:23:40 +0200
Sender: Guido.van.Rossum@cwi.nl

> Seems to me people are addressing the wrong end of the pipe with regard to
> gopher support. XMosaic shouldn't have to do anything in particular with
> gopher info. Shouldn't it really be up to the HTTP server (or gateway) to
> present gopher information in a more palatable form? It's a very minor
> change to NCSA's HTTP server to get it to put out nice looking gopher
> listings with in-lined images, etc. for example.
> 
> To do this, all you have to do is modify a few of the fprintf lines in the
> spew_and_free_array subroutine inside http_gopher.c.

Huh?  As far as I know there is no gateway involved when www clients
like XMosaic access Gopher servers: support for the Gopher protocol is
built in the client.  (There may be a gateway in existence
nevertheless, but it must be intended only for access through clients
that don't know the Gopher protocol yet.)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From daemon  Sun Jun 13 12:10:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18648; Sun, 13 Jun 93 12:10:13 MET DST
Return-Path: <M.T.Hamilton@lut.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18644; Sun, 13 Jun 93 12:10:12 MET DST
Received: from avarice.lut.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10222; Sun, 13 Jun 1993 12:32:15 +0200
Message-Id: <9306131032.AA10222@dxmint.cern.ch>
Received: from genie.lut.ac.uk by avarice.lut.ac.uk 
          id <00469-0@avarice.lut.ac.uk>; Sun, 13 Jun 1993 11:36:29 +0100
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion
To: Guido.van.Rossum@cwi.nl
Date: Sun, 13 Jun 1993 11:36:28 +0100 (BST)
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306131023.AA04219=guido@voorn.cwi.nl> from "Guido.van.Rossum@cwi.nl" at Jun 13, 93 12:23:40 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 948
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Sender: M.T.Hamilton@lut.ac.uk

Thus spake Guido :

/ Huh?  As far as I know there is no gateway involved when www clients
/ like XMosaic access Gopher servers: support for the Gopher protocol is
/ built in the client.  (There may be a gateway in existence
/ nevertheless, but it must be intended only for access through clients
/ that don't know the Gopher protocol yet.)

I think he's talking about the NCSA httpd - see below - Martin

  OVERVIEW OF GOPHER SUPPORT
  --------------------------
 
      As of beta release .3, this server will automatically generate
  HTML listings of a gopher directory without going through gopherd.
  This means that . files which are links are processed, and .cap files
  are processed. Any request which begins with /gopher-data will be
  considered a gopher request if gopher is turned on. Therefore, mapping
  /gopher-data to the location of your server's data will allow you to
  access /gopher-data and get a gopher listing in return.
 

From daemon  Sun Jun 13 19:44:38 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21178; Sun, 13 Jun 93 19:44:40 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21174; Sun, 13 Jun 93 19:44:38 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25638; Sun, 13 Jun 1993 20:06:41 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA12715; Sun, 13 Jun 1993 14:06:19 -0400
Date: Sun, 13 Jun 1993 13:51:46 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Re: Style sheets for HTML
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306110854.AA00997@manuel.hpl.hp.com>
Message-Id: <Pine.3.03.9306131345.J23070-c100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 11 Jun 1993, Dave_Raggett wrote:

> I read your style sheet proposal with great interest, and will add the
> "style" attribute to the LINK tag attribute definition in the DTD.

	Cool.

> Have you considered allowing multiple stylesheets to cover different uses?
> This would mean that you could specify one style for printing and another for
> online use. You might want to go further and distinguish between X windows,
> PC's and palmtops.
> 
> My suggestion is that the LINK element takes another attribute which specifies
> the intended media, e.g.
> 
>         <LINK style="http://ora.com/styles/paper_a4" media="paper/A4">
>         <LINK style="http://ora.com/styles/paper_B5" media="paper/B5">
>         <LINK style="http://ora.com/styles/xwindows" media="xwindows">        
> 
> Multiple such elements could be included in each HTML+ document.
> 
> Note that the media attribute value can encode further parameters - paper
> size in the above example. By defining the media attribute as taking a CDATA
> value, we can allow for new types of media without needing to change the DTD.
> 
> Comments please?

Hmmmm.... I would rather carry this information in the stylesheet itself. 
I seems rather wasteful to me to have 5 or 6 media links in the same
document.

I would suggest though that this is not of general use.  The stylesheet,
as proposed is really a collection of hints or suggestions for the
renderer to make decisions to best represent the content of a document in
a style which most meets the original intent of the author.

As such, there are general regions of responsibility which I feel we can
suggest complience with, (fonts, indents, etc.), and other more specific
areas which quickly become "a maze of twisty little suggestions, all alike."
I do not think that we really need nor want to specify this to the level
of the actual media used to realize the document.

I believe that it is up to the individual renderer to make the "proper
decisions" regarding the differences in printing in phosphors or ink, and
how a document looks on different page sizes.

Comments?  Am I off base here?  

</rr>



From daemon  Sun Jun 13 23:44:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22816; Sun, 13 Jun 93 23:44:59 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22812; Sun, 13 Jun 93 23:44:56 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14535; Mon, 14 Jun 1993 00:06:58 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA25937; Sun, 13 Jun 1993 18:06:55 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA09176; Sun, 13 Jun 1993 15:06:54 -0700
Message-Id: <199306132206.AA09176@ora.com>
From: Terry Allen <terry@ora.com>
Date: Sun, 13 Jun 1993 15:06:53 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: dsr@hplb.hpl.hp.com
Subject: Some HTML+ remarks
Cc: www-talk@nxoc01.cern.ch

This is a belated response to a few points in Dave Raggett's post  
<9306041049.AA16099@manuel.hpl.hp.com> of Fri, 4 Jun 93. 
Sorry to be so slow. 

>> is Terry Allen
> is Dave Raggett

>> PANEL is like a Sidebar; it floats, as FIGs may.  It seedms
>> to me that there needs to be a default anchor point (not
>> the ANCHOR element, necessarily, just an anchor) for floats,
>> such that one can say the object may be placed at that point
>> or after, but not before.
>Given that you can name most elements with the ID attribute and use 
>that as the basis for a link, it seems reasonable to use this for 
>anchoring panels, e.g.
>                <PANEL AT="p34">
>With your suggested semantics that the panel may be placed at that 
>point or after, but not before.

Elegant.

>> The same issue of anchor points pertains to <P MARGIN>, a
>> marginal note.  Unless these have anchors in the text to
>> which they pertain, they can be placed only by sticking them
>> right into that text.  
>My assumed semantics was that any text following after the margin 
>note definition would start at the same line as the start of the 
>margin note in the same way that DT and DD are currently treated by 
>most browsers.
>Footnotes can be handled using the EMPH tag, e.g. 
>        The UK is now considering CDMA <EMPH TAG="FOOTNOTE">
>         An abbreviation for Code Division Multiple Access - a
>         spread spectrum technique devised for the military.</EMPH>
>        for the third generation of mobile telephony.
>This approach has two benefits:
>    o   the footnote is anchored by virtue of where it is defined
>        and doesn't require an additional attribute
>    o   browsers can render the footnote text inline, e.g. in
>        brackets, or as a kind of pop-up link (dotted underlines?),
>        or at the bottom of the page if a paged imaging model
>        (rather than a scrolled model) is in use.

This is fine; I hadn't been thinking of dumb character terminals.
A minor point: there has to be some mechanism
for dealing with marginal notes that overlap:  you could have
two footnotes on the same line, or two long marginal notes
only a few lines apart.

>> I am confused by INPUT and the remark that it goes to make
>> up Forms.  Would someone please give an example of usage?
> [long and intriguing response deleted]

I liked the form example, and intend to try it out.
Keep up the good work!

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Mon Jun 14 07:22:43 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25514; Mon, 14 Jun 93 07:22:45 MET DST
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25510; Mon, 14 Jun 93 07:22:43 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16974; Mon, 14 Jun 1993 07:44:48 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0o57LQ-000EakC; Mon, 14 Jun 93 01:44 EDT
Message-Id: <m0o57LQ-000EakC@garnet.msen.com>
To: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Cc: Guido.van.Rossum@cwi.nl, www-talk@nxoc01.cern.ch
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion 
In-Reply-To: Your message of "Sun, 13 Jun 93 11:36:28 BST."
             <9306131032.AA10222@dxmint.cern.ch> 
Date: Mon, 14 Jun 1993 01:44:34 -0400
From: Edward Vielmetti <emv@garnet.msen.com>

> this server will automatically generate HTML listings of a gopher directory
> without going through gopherd.

Very interesting.  I'm using the "gn" gopher server here; is there a
similar server already built to handle its "menu" files?  (If not, 
hm, should be easy enough to build...)

From daemon  Mon Jun 14 08:32:10 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25924; Mon, 14 Jun 93 08:32:12 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25920; Mon, 14 Jun 93 08:32:10 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23827; Mon, 14 Jun 1993 08:54:14 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03946
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 14 Jun 93 01:54:03 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Guido.van.Rossum@cwi.nl id AA15806; Mon, 14 Jun 93 01:56:44 -0500
Date: Mon, 14 Jun 93 01:56:44 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306140656.AA15806@wintermute.ncsa.uiuc.edu>
To: Edward Vielmetti <emv@garnet.msen.com>
Cc: Guido.van.Rossum@cwi.nl, Martin Hamilton <M.T.Hamilton@lut.ac.uk>,
        www-talk@nxoc01.cern.ch
Subject: Re: Gopher support in X Mosaic, cosmetic suggestion 
In-Reply-To: <m0o57LQ-000EakC@garnet.msen.com>
References: <9306131032.AA10222@dxmint.cern.ch>
	<m0o57LQ-000EakC@garnet.msen.com>
X-Md4-Signature: 5a0f8ad877ce9b00ba148ad3b4910bdf

Edward Vielmetti writes:
> > this server will automatically generate HTML listings of a gopher directory
> > without going through gopherd.
> 
> Very interesting.  I'm using the "gn" gopher server here; is there a
> similar server already built to handle its "menu" files?  (If not, 
> hm, should be easy enough to build...)

Yup, should be pretty easy -- the other Gopher stuff in the NCSA
server was done by a skilled undergrad in a couple of days.
(Unfortunately, he's off writing 3DO software for the summer...
traitor.)

We are planning on putting Gopher visual type indication right in
Mosaic; the bitmaps will be built into the source code so the
performance hit should be negligible and, as was pointed out, they
will be present when talking directly to Gopher servers (by far the
most popular way to tie into Gopher directory hierarchies).

Marc


From daemon  Mon Jun 14 10:46:52 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27108; Mon, 14 Jun 93 10:46:55 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27104; Mon, 14 Jun 93 10:46:52 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14035; Mon, 14 Jun 1993 11:08:57 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01588; Mon, 14 Jun 93 11:08:28 +0200
Date: Mon, 14 Jun 93 11:08:28 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306140908.AA01588@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Damian Cugley <Damian.Cugley@prg.ox.ac.uk>
Subject: Re: SPaces and Tabs in HTML documents
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>Date: Sun, 13 Jun 1993 15:21:03 +0200
>To: timbl@nxoc01.cern.ch
>
>So far as I can tell, the HTML specification makes no mention of how
>duplicated spaces and tabs are to be treated in HTML documents.

You are right.  Actually tabs are mentioned in the PRE part, but
nowhere else.   The general understanding (before Mosaic) was that

	- Multiple spaces should be respected as such (for example
	  some people like them around punctuation) and should not
	  be used for prettying up the source.
	  

	- Tabs should not be used outside PRE

	- Within PRE, tabs are normal unix
		(>0 spaces to multiple of 8)

I would like to specify that multiple spaces be interpreted as such.
Would this be a big problem for anyone?
  

  There are a number of documents on the net which look very weird  
with non-mosaic browsers -- when I come across a bad one, I  
occasionally mail the author.

In a year's time I expect much more HTML to be generated from wysiwyg  
editors, and so the question of eth readability of the source won't
be relevant.

Of course, you can put in all the source pretty formatting you like
but if you once touch it with a wysiwyg editor, you'll probably lose  
it all anyway.


>    <p> Also, the two browsers have different ideas about whether  
the
>	ADDRESS tag marks a new paragraph or not -- www puts the  
address
>	flush right in a new paragraph, Mosaic simply switches to a
>	different typeface.

There is in the hypertext document (and in the draft internet draft)
a "typical rendering" defined for each of these elements.  Browsers
are not obliged to use this rendering. In the case of Mosaic, as far
as I can see, nothing is ever justified other than left-justfied.
That may be just the desiner's choice or a constraint of the  
implementation.  It doesn't make them an invalid W3 browser, just
not a typical one.  (Even though there may be -- untill Cello gets
seriouslsy deployed -- more XMosaics than anything other W3 clients)

The ideal would be to make the styles user-configurable, with the
"typical rendering" and the designer's personal favorites
as an options.

> Damian

Tim

From daemon  Mon Jun 14 11:16:26 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27368; Mon, 14 Jun 93 11:16:29 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27364; Mon, 14 Jun 93 11:16:26 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19579; Mon, 14 Jun 1993 11:38:27 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 14 Jun 93 10:30:38 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00563; Mon, 14 Jun 93 10:36:42 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306140936.AA00563@manuel.hpl.hp.com>
Subject: HTML+ support for eqn & Postscript
To: torben@hawaii.edu, janssen@parc.xerox.com
Date: Mon, 14 Jun 93 10:36:40 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Torben Nielsen says:

> I realize this has come up before, but how about really doing something about
> equation support? There are lots of documents I would like to put into the
> Web, but without support for embedded equations, it's really quite difficult.
> Something simple like eqn support would be great. And eqn shouldn't be all
> that hard to parse either.....

Bill Janssen chips in with:

> And I really like to send encapsulated Postcript in my documents... 
> Having ghostscript should make the parsing and layout easy!

Well both of these will be possible with the HTML+ DTD, by using the capability
to embed foreign formats inline in the HTML+ source, e.g.

        <H2>A example of an equation</H2>

        <EMBED TYPE="text/eqn">zeta (s) ~=~ sum from k=1 to inf
         k sup -s ~~~ (Re s &gt; 1) </EMBED>

The browser identifies the format of the embedded data from the "type"
attribute, specified as a MIME content type. Certain characters need to
be escaped using entity definitions, e.g. ">" by "&gt;" in the example.

Building in support for a range of formats has the danger of leading to
very large programs for browsers. This could be avoided by using a common
API for rendering foreign formats, e.g. as functions that take a sequence
of bytes and return a pixmap.

Browsers can then be upgraded to display new formats without changing their
code at all. All you would need is a way of binding the MIME content type
to the function name for that format, e.g. via X resources or a config file.
The functions could be implemented as separate programs driven via pipes and
stdin/stdout or as dynamically linked library modules (Windows DLLs).

How does that sound?

Dave

p.s. you can also put the foreign data in a separate file referenced by a URL.

From daemon  Mon Jun 14 11:21:54 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27422; Mon, 14 Jun 93 11:21:56 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27418; Mon, 14 Jun 93 11:21:54 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20057; Mon, 14 Jun 1993 11:43:58 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09285
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Mon, 14 Jun 93 04:43:47 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Damian.Cugley@prg.ox.ac.uk id AA16011; Mon, 14 Jun 93 04:46:28 -0500
Date: Mon, 14 Jun 93 04:46:28 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306140946.AA16011@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch
Cc: Damian Cugley <Damian.Cugley@prg.ox.ac.uk>, www-talk@nxoc01.cern.ch
Subject: Re: SPaces and Tabs in HTML documents
In-Reply-To: <9306140908.AA01588@www3.cern.ch>
References: <9306140908.AA01588@www3.cern.ch>
X-Md4-Signature: 864bd29e50af0e75ac95965a8459430d

Tim Berners-Lee writes:
> >So far as I can tell, the HTML specification makes no mention of how
> >duplicated spaces and tabs are to be treated in HTML documents.
> 
> You are right.  Actually tabs are mentioned in the PRE part, but
> nowhere else.   The general understanding (before Mosaic) was that
> 
> 	- Multiple spaces should be respected as such (for example
> 	  some people like them around punctuation) and should not
> 	  be used for prettying up the source.
> 
> 	- Tabs should not be used outside PRE
> 
> 	- Within PRE, tabs are normal unix
> 		(>0 spaces to multiple of 8)

The general understanding before Mosaic??  The general understanding
we were under was that redundant spaces, newlines, tabs, etc. were not
significant, and that's the way Mosaic treats 'em.  The concept that
multiple spaces should be respected as such is new to me -- where in
the online info was this stated?

> I would like to specify that multiple spaces be interpreted as such.
> Would this be a big problem for anyone?

Isn't it a violation of the SGML philosophy that we've all spent so
much blood, sweat, and tears trying to adhere to?

If we're going to start down this path, I'd like to see a line
containing nothing but whitespace to be considered an implicit
paragraph separator (<p>), as in LaTeX.

> >    <p> Also, the two browsers have different ideas about whether the
> >	ADDRESS tag marks a new paragraph or not -- www puts the address
> >	flush right in a new paragraph, Mosaic simply switches to a
> >	different typeface.
> 
> There is in the hypertext document (and in the draft internet draft)
> a "typical rendering" defined for each of these elements.  Browsers
> are not obliged to use this rendering. In the case of Mosaic, as far
> as I can see, nothing is ever justified other than left-justfied.
> That may be just the desiner's choice or a constraint of the  
> implementation.  It doesn't make them an invalid W3 browser, just
> not a typical one.  (Even though there may be -- untill Cello gets
> seriouslsy deployed -- more XMosaics than anything other W3 clients)

It was a choice, made at least partially because documents can be
wider than the available window space, causing a horizontal scrollbar
to show up and info on the right side of the document to be hidden until
the window is scrolled.  Didn't seem reasonable that information
should be shoved over where one might not even be able to see it.

> The ideal would be to make the styles user-configurable, with the
> "typical rendering" and the designer's personal favorites
> as an options.

Agreed.

Marc


From daemon  Mon Jun 14 12:48:18 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28329; Mon, 14 Jun 93 12:48:20 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28325; Mon, 14 Jun 93 12:48:18 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03451; Mon, 14 Jun 1993 13:10:21 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 14 Jun 93 12:02:32 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00666; Mon, 14 Jun 93 12:08:38 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306141108.AA00666@manuel.hpl.hp.com>
Subject: Re: SPaces and Tabs in HTML documents
To: timbl@nxoc01.cern.ch
Date: Mon, 14 Jun 93 12:08:36 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> You are right.  Actually tabs are mentioned in the PRE part, but
> nowhere else.   The general understanding (before Mosaic) was that

>         - Multiple spaces should be respected as such (for example
>           some people like them around punctuation) and should not
>           be used for prettying up the source.

>         - Tabs should not be used outside PRE

> I would like to specify that multiple spaces be interpreted as such.
> Would this be a big problem for anyone?

This doesn't sound right to me. Like Mosaic, I too, treat whitespace
as separators, and ignore how many spaces, carriage returns, newlines
or tabs there are.

Showing more space after punctuation is a rendering issue and should
be left to the reader's preference.

Dave Raggett

From daemon  Mon Jun 14 13:00:01 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28445; Mon, 14 Jun 93 13:00:05 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28441; Mon, 14 Jun 93 13:00:01 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05048; Mon, 14 Jun 1993 13:22:06 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01844; Mon, 14 Jun 93 13:21:36 +0200
Date: Mon, 14 Jun 93 13:21:36 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306141121.AA01844@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Pierre Barthelemy <Pierre.Barthelemy@sophia.inria.fr>
Subject: Latest NSFnet trends -- PS chart
Cc: wg-isus@rare.nl, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> I'm looking for statistical informations about Gopher and WWW :
> number of servers, countries, network traffic, ...
> Thanks in advance.

	There are currently around 75 registered HTTP hosts.
	When I last looked there were 113 WAIS hosts registered.
	
	You might find the graph of NSF backbone usage interesting.
	(appended).  FTP data is much bigger than any of these.
	
	Note that the chart shows HTTP protocol traffic (on
	port 80 only).  W3 clients talk
	all the protocols shown.  Some of the Gopher (and FTP)
	traffic is from W3 clients such as Mosaic. Difficult
	to know how much.
_________________________________________________________________
Begin forwarded message:

Date: Mon, 14 Jun 93 00:41:09 -0400
From: Richard W. Wiggins <rww@mugwump.cl.msu.edu>

WAIS *declines* in usage, both relatively and absolutely; WWW grows
drmatically, from .066% of packets to .143%.  Gopher keeps growing
too, of course.

My guess is that Gopher and WWW front ends are masking some WAIS  
usage.
But users are probably choosing browsing over WAIS searches as well.

/rich

%!PS-Adobe-3.0
%%Creator: Windows PSCRIPT
%%Title: NIRTREND.XLC
%%BoundingBox: 18 9 593 784
%%DocumentNeededResources: (atend)
%%DocumentSuppliedResources: (atend)
%%Pages: (atend)
%%BeginResource: procset Win35Dict 3 1
/Win35Dict 290 dict def Win35Dict begin/bd{bind def}bind def/in{72
mul}bd/ed{exch def}bd/ld{load def}bd/tr/translate ld/gs/gsave ld/gr
/grestore ld/M/moveto ld/L/lineto ld/rmt/rmoveto ld/rlt/rlineto ld
/rct/rcurveto ld/st/stroke ld/n/newpath ld/sm/setmatrix  
ld/cm/currentmatrix
ld/cp/closepath ld/ARC/arcn ld/TR{65536 div}bd/lj/setlinejoin ld/lc
/setlinecap ld/ml/setmiterlimit ld/sl/setlinewidth ld/scignore false
def/sc{scignore{pop pop pop}{0 index 2 index eq 2 index 4 index eq
and{pop pop 255 div setgray}{3{255 div 3 1 roll}repeat  
setrgbcolor}ifelse}ifelse}bd
/FC{bR bG bB sc}bd/fC{/bB ed/bG ed/bR ed}bd/HC{hR hG hB sc}bd/hC{
/hB ed/hG ed/hR ed}bd/PC{pR pG pB sc}bd/pC{/pB ed/pG ed/pR ed}bd/sM
matrix def/PenW 1 def/iPen 5 def/mxF matrix def/mxE matrix def/mxUE
matrix def/mxUF matrix def/fBE false def/iDevRes 72 0 matrix  
defaultmatrix
dtransform dup mul exch dup mul add sqrt def/fPP false def/SS{fPP{
/SV save def}{gs}ifelse}bd/RS{fPP{SV restore}{gr}ifelse}bd/EJ{gsave
showpage grestore}bd/#C{userdict begin/#copies ed end}bd/FEbuf 2  
string
def/FEglyph(G  )def/FE{1 exch{dup 16 FEbuf cvrs FEglyph exch 1 exch
putinterval 1 index exch FEglyph cvn put}for}bd/SM{/iRes ed/cyP ed
/cxPg ed/cyM ed/cxM ed 72 100 div dup scale dup 0 ne{90 eq{cyM exch
0 eq{cxM exch tr -90 rotate -1 1 scale}{cxM cxPg add exch tr +90  
rotate}ifelse}{cyP
cyM sub exch 0 ne{cxM exch tr -90 rotate}{cxM cxPg add exch tr -90
rotate 1 -1 scale}ifelse}ifelse}{pop cyP cyM sub exch 0 ne{cxM cxPg
add exch tr 180 rotate}{cxM exch tr 1 -1 scale}ifelse}ifelse 100 iRes
div dup scale 0 0 transform .25 add round .25 sub exch .25 add round
.25 sub exch itransform translate}bd/SJ{1 index 0 eq{pop pop/fBE  
false
def}{1 index/Break ed div/dxBreak ed/fBE true def}ifelse}bd/ANSIVec[
16#0/grave 16#1/acute 16#2/circumflex 16#3/tilde 16#4/macron  
16#5/breve
16#6/dotaccent 16#7/dieresis 16#8/ring 16#9/cedilla 16#A/hungarumlaut
16#B/ogonek 16#C/caron 16#D/dotlessi 16#27/quotesingle 16#60/grave
16#7C/bar 16#82/quotesinglbase 16#83/florin 16#84/quotedblbase 16#85
/ellipsis 16#86/dagger 16#87/daggerdbl 16#89/perthousand 16#8A/Scaron
16#8B/guilsinglleft 16#8C/OE 16#91/quoteleft 16#92/quoteright 16#93
/quotedblleft 16#94/quotedblright 16#95/bullet 16#96/endash 16#97
/emdash 16#99/trademark 16#9A/scaron 16#9B/guilsinglright 16#9C/oe
16#9F/Ydieresis 16#A0/space 16#A4/currency 16#A6/brokenbar  
16#A7/section
16#A8/dieresis 16#A9/copyright 16#AA/ordfeminine 16#AB/guillemotleft
16#AC/logicalnot 16#AD/hyphen 16#AE/registered 16#AF/macron  
16#B0/degree
16#B1/plusminus 16#B2/twosuperior 16#B3/threesuperior 16#B4/acute  
16#B5
/mu 16#B6/paragraph 16#B7/periodcentered 16#B8/cedilla  
16#B9/onesuperior
16#BA/ordmasculine 16#BB/guillemotright 16#BC/onequarter  
16#BD/onehalf
16#BE/threequarters 16#BF/questiondown 16#C0/Agrave 16#C1/Aacute  
16#C2
/Acircumflex 16#C3/Atilde 16#C4/Adieresis 16#C5/Aring 16#C6/AE 16#C7
/Ccedilla 16#C8/Egrave 16#C9/Eacute 16#CA/Ecircumflex 16#CB/Edieresis
16#CC/Igrave 16#CD/Iacute 16#CE/Icircumflex 16#CF/Idieresis 16#D0/Eth
16#D1/Ntilde 16#D2/Ograve 16#D3/Oacute 16#D4/Ocircumflex 16#D5/Otilde
16#D6/Odieresis 16#D7/multiply 16#D8/Oslash 16#D9/Ugrave 16#DA/Uacute
16#DB/Ucircumflex 16#DC/Udieresis 16#DD/Yacute 16#DE/Thorn  
16#DF/germandbls
16#E0/agrave 16#E1/aacute 16#E2/acircumflex 16#E3/atilde  
16#E4/adieresis
16#E5/aring 16#E6/ae 16#E7/ccedilla 16#E8/egrave 16#E9/eacute 16#EA
/ecircumflex 16#EB/edieresis 16#EC/igrave 16#ED/iacute  
16#EE/icircumflex
16#EF/idieresis 16#F0/eth 16#F1/ntilde 16#F2/ograve 16#F3/oacute  
16#F4
/ocircumflex 16#F5/otilde 16#F6/odieresis 16#F7/divide 16#F8/oslash
16#F9/ugrave 16#FA/uacute 16#FB/ucircumflex 16#FC/udieresis  
16#FD/yacute
16#FE/thorn 16#FF/ydieresis ] def/reencdict 12 dict  
def/IsChar{basefontdict
/CharStrings get exch known}bd/MapCh{dup IsChar not{pop/bullet}if
newfont/Encoding get 3 1 roll put}bd/MapDegree{16#b0/degree IsChar{
/degree}{/ring}ifelse MapCh}bd/MapBB{16#a6/brokenbar  
IsChar{/brokenbar}{
/bar}ifelse MapCh}bd/ANSIFont{reencdict begin/newfontname  
ed/basefontname
ed FontDirectory newfontname known not{/basefontdict basefontname  
findfont
def/newfont basefontdict maxlength dict def basefontdict{exch dup/FID
ne{dup/Encoding eq{exch dup length array copy newfont 3 1 roll  
put}{exch
newfont 3 1 roll put}ifelse}{pop pop}ifelse}forall newfont/FontName
newfontname put 127 1 159{newfont/Encoding get exch/bullet put}for
ANSIVec aload pop ANSIVec length 2 idiv{MapCh}repeat MapDegree MapBB
newfontname newfont definefont pop}if newfontname end}bd/SB{FC/ULlen
ed/str ed str length fBE not{dup 1 gt{1 sub}if}if/cbStr ed/dxGdi ed
/y0 ed/x0 ed str stringwidth dup 0 ne{/y1 ed/x1 ed y1 y1 mul x1 x1
mul add sqrt dxGdi exch div 1 sub dup x1 mul cbStr div exch y1 mul
cbStr div}{exch abs neg dxGdi add cbStr div exch}ifelse/dyExtra ed
/dxExtra ed x0 y0 M fBE{dxBreak 0 BCh dxExtra dyExtra str  
awidthshow}{dxExtra
dyExtra str ashow}ifelse fUL{x0 y0 M dxUL dyUL rmt ULlen fBE{Break
add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if fSO{x0
y0 M dxSO dySO rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt  
cyUL
sl [] 0 setdash st gr}if n/fBE false def}bd/font{/name ed/Ascent ed
0 ne/fT3 ed 0 ne/fSO ed 0 ne/fUL ed/Sy ed/Sx ed 10.0 div/ori ed -10.0
div/esc ed/BCh ed name findfont/xAscent 0 def/yAscent Ascent  
def/ULesc
esc def ULesc mxUE rotate pop fT3{/esc 0 def xAscent yAscent mxUE  
transform
/yAscent ed/xAscent ed}if [Sx 0 0 Sy neg xAscent yAscent] esc mxE
rotate mxF concatmatrix makefont setfont [Sx 0 0 Sy neg 0 Ascent]  
mxUE
mxUF concatmatrix pop fUL{currentfont dup/FontInfo  
get/UnderlinePosition
known not{pop/Courier findfont}if/FontInfo get/UnderlinePosition get
1000 div 0 exch mxUF transform/dyUL ed/dxUL ed}if fSO{0 .3 mxUF  
transform
/dySO ed/dxSO ed}if fUL fSO or{currentfont dup/FontInfo  
get/UnderlineThickness
known not{pop/Courier findfont}if/FontInfo get/UnderlineThickness get
1000 div Sy mul/cyUL ed}if}bd/min{2 copy gt{exch}if pop}bd/max{2 copy
lt{exch}if pop}bd/CP{/ft ed{{ft 0  
eq{clip}{eoclip}ifelse}stopped{currentflat
1 add setflat}{exit}ifelse}loop}bd/patfont 10 dict def patfont begin
/FontType 3 def/FontMatrix [1 0 0 -1 0 0] def/FontBBox [0 0 16 16]
def/Encoding StandardEncoding def/BuildChar{pop pop 16 0 0 0 16 16
setcachedevice 16 16 false [1 0 0 1 .25 .25]{pat}imagemask}bd end/p{
/pat 32 string def{}forall 0 1 7{dup 2 mul pat exch 3 index put dup
2 mul 1 add pat exch 3 index put dup 2 mul 16 add pat exch 3 index
put 2 mul 17 add pat exch 2 index put pop}for}bd/pfill{/PatFont  
patfont
definefont setfont/ch(AAAA)def X0 64 X1{Y1 -16 Y0{1 index exch M ch
show}for pop}for}bd/vert{X0 w X1{dup Y0 M Y1 L st}for}bd/horz{Y0 w
Y1{dup X0 exch M X1 exch L st}for}bd/fdiag{X0 w X1{Y0 M X1 X0 sub dup
rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup rlt st}for}bd/bdiag{X0 w
X1{Y1 M X1 X0 sub dup neg rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup
neg rlt st}for}bd/AU{1 add cvi 15 or}bd/AD{1 sub cvi -16  
and}bd/SHR{pathbbox
AU/Y1 ed AU/X1 ed AD/Y0 ed AD/X0 ed}bd/hfill{/w iRes 37.5 div round
def 0.1 sl [] 0 setdash n dup 0 eq{horz}if dup 1 eq{vert}if dup 2  
eq{fdiag}if
dup 3 eq{bdiag}if dup 4 eq{horz vert}if 5 eq{fdiag bdiag}if}bd/F{/ft
ed fm 256 and 0 ne{gs FC ft 0 eq{fill}{eofill}ifelse gr}if fm 1536
and 0 ne{SHR gs HC ft CP fm 1024 and 0 ne{/Tmp save def pfill Tmp  
restore}{fm
15 and hfill}ifelse gr}if}bd/S{PenW sl PC st}bd/m matrix def/GW{iRes
12 div PenW add cvi}bd/DoW{iRes 50 div PenW add cvi}bd/DW{iRes 8 div
PenW add cvi}bd/SP{/PenW ed/iPen ed iPen 0 eq iPen 6 eq or{[] 0  
setdash}if
iPen 1 eq{[DW GW] 0 setdash}if iPen 2 eq{[DoW GW] 0 setdash}if iPen
3 eq{[DW GW DoW GW] 0 setdash}if iPen 4 eq{[DW GW DoW GW DoW GW] 0
setdash}if}bd/E{m cm pop tr scale 1 0 moveto 0 0 1 0 360 arc cp m  
sm}bd
/AG{/sy ed/sx ed sx div 4 1 roll sy div 4 1 roll sx div 4 1 roll sy
div 4 1 roll atan/a2 ed atan/a1 ed sx sy scale a1 a2 ARC}def/A{m cm
pop tr AG m sm}def/P{m cm pop tr 0 0 M AG cp m sm}def/RRect{n 4 copy
M 3 1 roll exch L 4 2 roll L L cp}bd/RRCC{/r ed/y1 ed/x1 ed/y0 ed/x0
ed x0 x1 add 2 div y0 M x1 y0 x1 y1 r arcto 4{pop}repeat x1 y1 x0 y1
r arcto 4{pop}repeat x0 y1 x0 y0 r arcto 4{pop}repeat x0 y0 x1 y0 r
arcto 4{pop}repeat cp}bd/RR{2 copy 0 eq exch 0 eq or{pop pop RRect}{2
copy eq{pop RRCC}{m cm pop/y2 ed/x2 ed/ys y2 x2 div 1 max def/xs x2
y2 div 1 max def/y1 exch ys div def/x1 exch xs div def/y0 exch ys div
def/x0 exch xs div def/r2 x2 y2 min def xs ys scale x0 x1 add 2 div
y0 M x1 y0 x1 y1 r2 arcto 4{pop}repeat x1 y1 x0 y1 r2 arcto  
4{pop}repeat
x0 y1 x0 y0 r2 arcto 4{pop}repeat x0 y0 x1 y0 r2 arcto 4{pop}repeat
m sm cp}ifelse}ifelse}bd/PP{{rlt}repeat}bd/OB{gs 0 ne{7 3 roll/y ed
/x ed x y translate ULesc rotate x neg y neg translate x y 7 -3  
roll}if
sc B fill gr}bd/B{M/dy ed/dx ed dx 0 rlt 0 dy rlt dx neg 0 rlt cp}bd
/CB{B clip n}bd/ErrHandler{errordict dup maxlength exch length gt
dup{errordict begin}if/errhelpdict 12 dict def errhelpdict  
begin/stackunderflow(operand stack underflow)def
/undefined(this name is not defined in a dictionary)def/VMerror(you  
have used up all the printer's memory)def
/typecheck(operator was expecting a different type of operand)def
/ioerror(input/output error occured)def end{end}if errordict begin
/handleerror{$error begin newerror{/newerror false def showpage 72
72 scale/x .25 def/y 9.6 def/Helvetica findfont .2 scalefont setfont
x y moveto(Offending Command = )show/command load{dup type/stringtype
ne{(max err string)cvs}if show}exec/y y .2 sub def x y moveto(Error =  
)show
errorname{dup type dup( max err string )cvs show( : )show/stringtype
ne{( max err string )cvs}if show}exec errordict begin errhelpdict  
errorname
known{x 1 add y .2 sub moveto errhelpdict errorname get show}if end
/y y .4 sub def x y moveto(Stack =)show ostack{/y y .2 sub def x 1
add y moveto dup type/stringtype ne{( max err string )cvs}if  
show}forall
showpage}if end}def end}bd end
%%EndResource
/SVDoc save def
%%EndProlog
%%BeginSetup
Win35Dict begin
ErrHandler
statusdict begin 0 setjobtimeout end
statusdict begin statusdict /jobname (NIRTREND.XLC) put end
/oldDictCnt countdictstack def {}stopped
{ countdictstack oldDictCnt lt { Win35Dict begin }
{1 1 countdictstack oldDictCnt sub {pop end } for } ifelse } if
/oldDictCnt countdictstack def {letter
}stopped
{ countdictstack oldDictCnt lt { Win35Dict begin }
{1 1 countdictstack oldDictCnt sub {pop end } for } ifelse } if
[
{mark 1.0 1.0 .98 .9 .82 .68 .56 .48 .28 .1 .06 .0 counttomark dup 3  
add -1 roll exch 2 sub mul dup floor cvi dup 3 1 roll sub exch dup  3  
add index exch 2 add index dup 4 1 roll sub mul add counttomark 1 add  
1 roll  cleartomark } bind
/exec load currenttransfer /exec load] cvx settransfer
/setresolution where { pop 300 300 setresolution } if
%%EndSetup
%%Page: 1 1
%%PageResources: (atend)
SS
0 90 25 12 798 1100 300 SM
32 0 0 46 46 0 0 0 42 /Times-Roman /font32 ANSIFont font
0 0 0 fC
gs 2850 2250 189 75 CB
1141 2268 947 ( Data from  
ftp://nic.merit.edu/nsfnet/statistics/1993/) 947 SB
gr
255 255 255 fC
/fm 256 def
2291 1750 M 844 156 715 -92 -804 -197 -755 133 4 PP
1 F
n
732 1686 M -715 92 1 838 725 2 -11 -932 4 PP
1 F
n
1447 1594 M -844 -156 -13 997 858 -3 -1 -838 4 PP
1 F
n
1 lc
1 lj
0 0 0 pC
0 1 SP
2291 1750 M 844 156 715 -92 -804 -197 -755 133 4 PP
S
n
732 1686 M -715 92 1 838 725 2 -11 -932 4 PP
S
n
1447 1594 M -844 -156 -13 997 858 -3 -1 -838 4 PP
S
n
gs 805 198 732 1686 CB
732 1686 M 804 197 1 PP
S
n
gr
gs 1 20 732 1686 CB
732 1686 M 0 19 1 PP
S
n
gr
gs 1 21 905 1728 CB
905 1728 M 0 20 1 PP
S
n
gr
gs 1 20 1095 1775 CB
1095 1775 M 0 19 1 PP
S
n
gr
gs 1 20 1304 1826 CB
1304 1826 M 0 19 1 PP
S
n
gr
gs 1 20 1536 1883 CB
1536 1883 M 0 19 1 PP
S
n
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Italic /font31 ANSIFont font
0 0 0 fC
gs 2672 1540 278 539 CB
709 1830 106 (Jan-93) 106 SB
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Italic /font31 ANSIFont font
gs 2672 1540 278 539 CB
882 1875 108 (Feb-93) 108 SB
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Italic /font31 ANSIFont font
gs 2672 1540 278 539 CB
1072 1930 117 (Mar-93) 117 SB
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Italic /font31 ANSIFont font
gs 2672 1540 278 539 CB
1281 1972 108 (Apr-93) 108 SB
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Italic /font31 ANSIFont font
gs 2672 1540 278 539 CB
1513 2040 119 (May-93) 119 SB
gr
gs 756 134 1536 1750 CB
2291 1750 M -755 133 1 PP
S
n
gr
gs 1 20 1536 1883 CB
1536 1883 M 0 19 1 PP
S
n
gr
gs 1 20 1810 1835 CB
1810 1835 M 0 19 1 PP
S
n
gr
gs 1 20 2060 1791 CB
2060 1791 M 0 19 1 PP
S
n
gr
gs 1 20 2291 1750 CB
2291 1750 M 0 19 1 PP
S
n
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Bold /font29 ANSIFont font
gs 2672 1540 278 539 CB
1653 1988 101 (WAIS) 101 SB
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Bold /font29 ANSIFont font
gs 2672 1540 278 539 CB
1915 1955 114 (WWW) 114 SB
gr
32 -2700 -2700 38 38 0 0 0 34 /Times-Bold /font29 ANSIFont font
gs 2672 1540 278 539 CB
2155 1923 124 (Gopher) 124 SB
gr
gs 20 1 2291 1750 CB
2291 1750 M 19 0 1 PP
S
n
gr
gs 20 1 2292 1641 CB
2292 1641 M 19 0 1 PP
S
n
gr
gs 20 1 2294 1531 CB
2294 1531 M 19 0 1 PP
S
n
gr
gs 20 1 2295 1421 CB
2295 1421 M 19 0 1 PP
S
n
gr
gs 20 1 2297 1311 CB
2297 1311 M 19 0 1 PP
S
n
gr
gs 20 1 2298 1200 CB
2298 1200 M 19 0 1 PP
S
n
gr
gs 20 1 2300 1089 CB
2300 1089 M 19 0 1 PP
S
n
gr
gs 20 1 2301 978 CB
2301 978 M 19 0 1 PP
S
n
gr
gs 20 1 2303 865 CB
2303 865 M 19 0 1 PP
S
n
gr
gs 20 1 2304 753 CB
2304 753 M 19 0 1 PP
S
n
gr
32 0 0 33 33 0 0 0 30 /Times-Bold /font29 ANSIFont font
gs 2672 1540 278 539 CB
2314 1732 17 (0) 17 SB
gr
gs 2672 1540 278 539 CB
2316 1622 152 (50,000,000) 152 SB
gr
gs 2672 1540 278 539 CB
2317 1513 169 (100,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2319 1403 169 (150,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2320 1293 169 (200,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2321 1182 169 (250,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2323 1071 169 (300,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2324 959 169 (350,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2326 847 169 (400,000,000) 169 SB
gr
gs 2672 1540 278 539 CB
2328 735 169 (450,000,000) 169 SB
gr
255 255 255 fC
0 0 0 hC
/fm 1280 def
<55aa55aa55aa55aa> p
2110 805 M 10 -979 -154 27 -12 953 156 -1 4 PP
1 F
S
n
1263 1618 M -837 -166 -10 979 244 -142 220 -65 201 -134 183 -116 -1  
-356 7 PP
1 F
S
n
<77dd77dd77dd77dd> p
1028 1647 M -179 -36 -161 22 181 34 159 -20 4 PP
1 F
S
n
1207 1683 M -195 -22 -164 24 198 20 161 -22 4 PP
1 F
S
n
1402 1705 M -215 -17 -165 25 216 16 164 -24 4 PP
1 F
S
n
1617 1722 M -237 11 -167 26 239 -12 165 -25 4 PP
1 F
S
n
1854 1711 M 1 -116 -167 29 -1 113 167 -26 4 PP
1 F
S
n
1028 1648 M -825 -179 -1 116 237 -11 215 17 195 22 179 36 0 -1 7 PP
1 F
S
n
/fm 256 def
776 1655 M -174 -32 -173 23 177 30 170 -21 4 PP
1 F
S
n
950 1687 M -191 -38 -176 25 194 36 173 -23 4 PP
1 F
S
n
1141 1725 M -210 -30 -180 27 214 28 176 -25 4 PP
1 F
S
n
1351 1755 M -233 -72 -182 31 235 68 180 -27 4 PP
1 F
S
n
1584 1827 M 0 -47 -182 32 0 46 182 -31 4 PP
1 F
S
n
776 1680 M -808 -194 0 47 233 72 210 30 191 38 174 32 0 -25 7 PP
1 F
S
n
32 0 0 46 46 0 0 0 43 /Times-Bold /font29 ANSIFont font
0 0 0 fC
gs 796 76 1216 585 CB
1222 597 784 (Internet Information Tools UsageTrends) 784 SB
gr
1 #C
statusdict begin /manualfeed false store end
EJ RS
%%PageTrailer
%%PageResources: font Times-Bold
%%+ font Times-Italic
%%+ font Times-Roman
%%Trailer
SVDoc restore
end
%%Pages: 1
% TrueType font name key:
%    MSTT31c08e = 206fDTimes New RomanF00000026000002bc0000
%    MSTT31c09b = 206fDTimes New RomanF00000026000001900001
%    MSTT31c0a8 = 206fDTimes New RomanF0000002e000002bc0000
%    MSTT31c0b5 = 206fDTimes New RomanF00000021000002bc0000
%    MSTT31c0c2 = 206fDTimes New RomanF0000002e000001900000
%    MSTT31c0cf = 206fDTimes New RomanF00000026f57401900001
%    MSTT31c0dc = 206fDTimes New RomanF00000026f57402bc0000
%%DocumentSuppliedResources: procset Win35Dict 3 1

%%DocumentNeededResources: font Times-Bold
%%+ font Times-Italic
%%+ font Times-Roman

%%EOF



From daemon  Mon Jun 14 15:44:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02165; Mon, 14 Jun 93 15:45:02 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02160; Mon, 14 Jun 93 15:44:59 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02636; Mon, 14 Jun 1993 16:07:04 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22447
  (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Mon, 14 Jun 93 09:06:39 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:rww@mugwump.cl.msu.edu id AA17259; Mon, 14 Jun 93 09:09:15 -0500
Date: Mon, 14 Jun 93 09:09:15 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306141409.AA17259@wintermute.ncsa.uiuc.edu>
To: timbl@nxoc01.cern.ch
Cc: Richard W. Wiggins <rww@mugwump.cl.msu.edu>, wg-isus@rare.nl,
        www-talk@nxoc01.cern.ch
Subject: Latest NSFnet trends -- PS chart
In-Reply-To: <9306141121.AA01844@www3.cern.ch>
References: <9306141121.AA01844@www3.cern.ch>
X-Md4-Signature: 76dec4491cdfa0276e6651c16d8cedc4

Tim Berners-Lee writes:
> Begin forwarded message:
> 
> Date: Mon, 14 Jun 93 00:41:09 -0400
> From: Richard W. Wiggins <rww@mugwump.cl.msu.edu>
> 
> WAIS *declines* in usage, both relatively and absolutely; WWW grows
> drmatically, from .066% of packets to .143%.  Gopher keeps growing
> too, of course.

Wouldn't it make more sense to go by bytes rather than packets, as a
more accurate reflection of how much data is actually being shipped
across?

Just curious,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Mon Jun 14 17:16:38 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04379; Mon, 14 Jun 93 17:16:41 MET DST
Return-Path: <Damian.Cugley@prg.ox.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04375; Mon, 14 Jun 93 17:16:38 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17837; Mon, 14 Jun 1993 17:38:43 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Mon, 14 Jun 1993 17:38:22 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Mon, 14 Jun 1993 17:34:47 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:34:32 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:35:21 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:35:17 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:35:17 +0200
Date: Mon, 14 Jun 1993 17:35:17 +0200
X400-Originator: Damian.Cugley@prg.oxford.ac.uk
X400-Recipients: www-talk@NXOC01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9306141535.AA00686@boothp1.ecs.]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: SPaces an...
From: Damian.Cugley@prg.ox.ac.uk
Message-Id: <9306141535.AA00686@boothp1.ecs.ox.ac.uk>
To: www-talk@nxoc01.cern.ch
Subject: Re: SPaces and Tabs in HTML documents

> I would like to specify that multiple spaces be interpreted as such.
> Would this be a big problem for anyone?

As a general attitude to spacing, I still think that Knuth got it
right with TeX [TeXbook, p.46]: by default newlines, tabs and spaces
are treated as equivalent, multiple spaces are collapsed, spaces and
tabs at the starts of lines are ignored, and extra space after
punctuation is handled separately.  (TeX is a typesetter, and spacing
punctuation in one-space units would be too coarse.)  Knuth's thinking
was that if you can't see the difference on the screen then it should
not make a difference to the final output.

On the other hand, there are two reasons not to adopt Knuth's
conventions verbatim: first, your hands are likely tied by SGML
compatibility; second, you are working in a fairly clunky character
medium rather than fine typesetting.  If the spacing is done in units
of a normal inter-word space, then indicating a double-wdith space
with two space characters *is* an expedient convention.  (Especially
as HTML has no way of distinguishing an end-of-sentence full stop from
an abbreviation-indicating fill stop.)

That said, being able to rigidly indent the text of a document with
markup can greatly improve its legibility -- with TeX documents I
indent the text one tab stop, leaving the macros that generate
headings and delimit regions of text in column 0.  This makes the
structure of the document easier to follow.  (It also prevents UNIX
sendmail from inserting ">" characters before "From".)  The same
applies to HTML documents, excapt that if the text is indented, only
Mosaic can display them properly.

You could specify that any number of whitespace characters (SP, HT,
LF, CR) may follow the CR or LF marking the end of a line, and they're
all ignored (except in PRE elements, of course).  This would mean that
indentation of text lines is ignored, as well as any blank lines (even
ones with spaces on them).  Doubled spaces after sentences would be
preserved.  This should be easy to implement, and allows people like
me to format their text pretty much as they would like.

Damian

From daemon  Mon Jun 14 17:37:23 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04824; Mon, 14 Jun 93 17:37:25 MET DST
Return-Path: <Damian.Cugley@prg.ox.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04375; Mon, 14 Jun 93 17:16:38 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17837; Mon, 14 Jun 1993 17:38:43 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Mon, 14 Jun 1993 17:38:22 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Mon, 14 Jun 1993 17:34:47 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:34:32 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:35:21 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:35:17 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Mon, 14 Jun 1993 17:35:17 +0200
Date: Mon, 14 Jun 1993 17:35:17 +0200
X400-Originator: Damian.Cugley@prg.oxford.ac.uk
X400-Recipients: www-talk@NXOC01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9306141535.AA00686@boothp1.ecs.]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: SPaces an...
From: Damian.Cugley@prg.ox.ac.uk
Message-Id: <9306141535.AA00686@boothp1.ecs.ox.ac.uk>
To: www-talk@nxoc01.cern.ch
Subject: Re: SPaces and Tabs in HTML documents

> I would like to specify that multiple spaces be interpreted as such.
> Would this be a big problem for anyone?

As a general attitude to spacing, I still think that Knuth got it
right with TeX [TeXbook, p.46]: by default newlines, tabs and spaces
are treated as equivalent, multiple spaces are collapsed, spaces and
tabs at the starts of lines are ignored, and extra space after
punctuation is handled separately.  (TeX is a typesetter, and spacing
punctuation in one-space units would be too coarse.)  Knuth's thinking
was that if you can't see the difference on the screen then it should
not make a difference to the final output.

On the other hand, there are two reasons not to adopt Knuth's
conventions verbatim: first, your hands are likely tied by SGML
compatibility; second, you are working in a fairly clunky character
medium rather than fine typesetting.  If the spacing is done in units
of a normal inter-word space, then indicating a double-wdith space
with two space characters *is* an expedient convention.  (Especially
as HTML has no way of distinguishing an end-of-sentence full stop from
an abbreviation-indicating fill stop.)

That said, being able to rigidly indent the text of a document with
markup can greatly improve its legibility -- with TeX documents I
indent the text one tab stop, leaving the macros that generate
headings and delimit regions of text in column 0.  This makes the
structure of the document easier to follow.  (It also prevents UNIX
sendmail from inserting ">" characters before "From".)  The same
applies to HTML documents, excapt that if the text is indented, only
Mosaic can display them properly.

You could specify that any number of whitespace characters (SP, HT,
LF, CR) may follow the CR or LF marking the end of a line, and they're
all ignored (except in PRE elements, of course).  This would mean that
indentation of text lines is ignored, as well as any blank lines (even
ones with spaces on them).  Doubled spaces after sentences would be
preserved.  This should be easy to implement, and allows people like
me to format their text pretty much as they would like.

Damian

From daemon  Mon Jun 14 18:01:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05234; Mon, 14 Jun 93 18:01:42 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05229; Mon, 14 Jun 93 18:01:39 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25329; Mon, 14 Jun 1993 18:23:44 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02170; Mon, 14 Jun 93 18:23:12 +0200
Date: Mon, 14 Jun 93 18:23:12 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306141623.AA02170@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: SPaces and Tabs in HTML documents
Cc: Damian Cugley <Damian.Cugley@prg.ox.ac.uk>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>Date: Mon, 14 Jun 93 04:46:28 -0500
>From: marca@ncsa.uiuc.edu (Marc Andreessen)

>Tim Berners-Lee writes:
>> ...The general understanding (before Mosaic) was that
>> 	- Multiple spaces should be respected as such (for example
>> 	  some people like them around punctuation) and should not
>> 	  be used for prettying up the source.
...
>The general understanding before Mosaic??  The general understanding
>we were under was that redundant spaces, newlines, tabs, etc. were  
not
>significant, and that's the way Mosaic treats 'em.  The concept that
>multiple spaces should be respected as such is new to me -- where in
>the online info was this stated?

There was obviously a general MISunderstanding!  My fault, should
have got it clearer at the time. This was when Dan Connolly was
our "SGML cop". As I remember, his conclusion was that multiple
spaces were weird things to put in, but if someone wanted to put
them in, then they should be given more space as a result.

>> I would like to specify that multiple spaces be interpreted as  
such.
>> Would this be a big problem for anyone?

It seems to be a problem for Mosaic and for Dave.

>Isn't it a violation of the SGML philosophy that we've all spent so
>much blood, sweat, and tears trying to adhere to?

I don't think so... SGML allows you to define the significance of the
data.  I know the IBM mainframe SGML implementation here took two
spaces as two spaces.

>If we're going to start down this path, I'd like to see a line
>containing nothing but whitespace to be considered an implicit
>paragraph separator (<p>), as in LaTeX.

I see your argument.  Newlines led to a horrible discussion about
what was expected in HTML.

>> >    <p> Also, the two browsers have different ideas about whether  
the
>> >	ADDRESS tag marks a new paragraph or not -- www puts the  
address
>> >	flush right in a new paragraph, Mosaic simply switches to a
>> >	different typeface.
...
>It was a choice, made at least partially because documents can be
>wider than the available window space, causing a horizontal  
scrollbar
>to show up and info on the right side of the document to be hidden  
until
>the window is scrolled.  Didn't seem reasonable that information
>should be shoved over where one might not even be able to see it.

They can be wider... but Misaic is normally very clever at
sizing them to the screen size.  Its only preformatted bits which  
force a wide document.  It would be useful if the default  
preformatted font was chosen such that 80 characters fitted within
the default window width.  As it is one normally starts Mosaic
and then has to stretch it the moment a plain ascii document comes  
up.

Dan's remark on www-talk on 8 Jan 93 was:
"Is anyone distressed by the situation where some browsers compress
multiple spaces [in typeset paragraphs] into one, and some do not?  
I'm not.
I'd say "Don't do that" to the fool who put multiple spaces in
his source."

Well, I'm not too fussy about this, but an agreement is essential.
I can change the behaviour of the parser in the library if  we
all agree.

PROPOSED CHANGE then:

All white space to be shrunk to one space outside PRE
sections.   Anyone object?

Tim

From daemon  Mon Jun 14 18:19:33 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05720; Mon, 14 Jun 93 18:19:35 MET DST
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05714; Mon, 14 Jun 93 18:19:33 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28297; Mon, 14 Jun 1993 18:41:35 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA23874; Mon, 14 Jun 1993 12:41:22 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA13650; Mon, 14 Jun 1993 09:41:20 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9306140941.ZM13648@rock.west.ora.com>
Date: Mon, 14 Jun 1993 09:41:19 -0700
In-Reply-To: Tim Berners-Lee <timbl@www3.cern.ch>
        "Re: SPaces and Tabs in HTML documents" (Jun 14,  6:23pm)
References: <9306141623.AA02170@www3.cern.ch>
X-Mailer: Z-Mail (2.1.0 10/27/92)
To: timbl@nxoc01.cern.ch, marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: SPaces and Tabs in HTML documents
Cc: Damian Cugley <Damian.Cugley@prg.ox.ac.uk>, www-talk@nxoc01.cern.ch,
        terry@ora.com, kramer@ora.com

I object to collapsing spaces everywhere outside of PRE.
I agree that coding multiple spaces is not a wise thing
to do, but I must believe that lacking better solutions,
we need spaces.  Where this has caused us problems in
Xmosaic is in documents that have an inline image followed
on the same line by text.  There's no good way to get proper
spacing between the image and the first character.
We have introduced some bad coding to get around the lack
of horizontal spacing, and I don't like that approach.

I forget the HTML tag used for Program Listings, whether we
use CODE or EXAMPLE, but this is another case where spaces
are significant. 

-- 
Dale Dougherty (dale@ora.com) 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

From daemon  Mon Jun 14 18:31:17 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05981; Mon, 14 Jun 93 18:31:19 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05977; Mon, 14 Jun 93 18:31:17 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29784; Mon, 14 Jun 1993 18:53:23 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576713-3>; Mon, 14 Jun 1993 12:53:16 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA04051; Mon, 14 Jun 93 12:43:08 EDT
Date: Mon, 14 Jun 1993 12:43:08 -0400
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306141643.AA04051@begbick.law.cornell.edu.law.cornell.edu>
To: www-talk@nxoc01.cern.ch, fatty!cello-l@dxmint.cern.ch,
        fatty!teknoids@dxmint.cern.ch, law-lib@ucdavis.ucdavis.edu
Subject: Beta version .2 of Cello...

...is out. To pick it up, download cello.zip from the /pub/LII/Cello
directory on fatty.law.cornell.edu.  The previous version is in
/pub/LII/Cello/beta01, though why anyone would care is an open question.

The .2 version repairs the following problems:

1) Improper handling of <PRE> documents, reported by Alert Cellist Lou Montulli.
2) Improper handling of situations where telnet hosts would stack
inverse video attributes on top of bold, blink, etc (though why anyone
would do this I don't know).
3) A few miscellaneous memory-handling problems, including a tendency
to hang when telnetting to AIX hosts.
4) Inability to use anything other than a local DOS file as a home
page, reported by Alert Cellist Michael Mealling.
5) Assorted errors and omissions in the Help application, including
specific information encouraging the use of NDIS drivers with ATT StarLan.

It adds the following features:

1) Ability to access a resource directly by typing in the URL (thanks
to Alert Cellist and All-Round WWW Guy TimBL).
2) See 4) above.


Regards,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Mon Jun 14 18:41:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06282; Mon, 14 Jun 93 18:41:50 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06277; Mon, 14 Jun 93 18:41:47 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00542; Mon, 14 Jun 1993 19:03:52 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA25753; Mon, 14 Jun 1993 13:03:46 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA14177; Mon, 14 Jun 1993 10:03:44 -0700
Message-Id: <199306141703.AA14177@ora.com>
From: Terry Allen <terry@ora.com>
Date: Mon, 14 Jun 1993 10:03:43 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: Spaces outside PRE

I differ from Dale on this: extra white space should be 
collapsed outside of PRE.  A sentence  that    happens to be  typed this
way shouldn't be formatted differently than one that is spaced normally.
The reason is that you then have to pay excruciating attention to these
spaces. 
        
I do notice that there seems to be no way to get white space when you
want it in xmosaic, so there needs to be some provision for that.  But
double spaces are not the way.  
        
Tabs are also another matter.  Perhaps their effectiveness should be 
restricted to a tabbing environment.  Some examples from the group of
how people would like to use tabs outside of PRE would be helpful to
this discussion.

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Mon Jun 14 18:56:35 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06580; Mon, 14 Jun 93 18:56:37 MET DST
Return-Path: <thorpe@ncsc.org>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06576; Mon, 14 Jun 93 18:56:35 MET DST
Received: from doppler.ncsc.org by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02249; Mon, 14 Jun 1993 19:18:38 +0200
Received: by doppler.ncsc.org (4.1/tas-concert/8-12-92)
	id AA24988; Mon, 14 Jun 93 13:18:32 EDT
From: Steve Thorpe <thorpe@ncsc.org>
Message-Id: <9306141718.AA24988@doppler.ncsc.org>
Subject: Please unsubscribe thorpe@ncsc.org
To: www-talk@nxoc01.cern.ch
Date: Mon, 14 Jun 93 13:18:31 EDT
X-Mailer: ELM [version 2.3 PL0]

Thank you.

----------------------------------------------------------------
   Steve Thorpe, Application Visualization System Specialist
International AVS Center, North Carolina Supercomputing Center
PO Box 12889   3021 Cornwallis Rd, RTP, NC 27709   avs@ncsc.org
----------------------------------------------------------------

From daemon  Mon Jun 14 19:03:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06701; Mon, 14 Jun 93 19:03:42 MET DST
Return-Path: <torben%Hawaii.Edu@galaxy.net.hawaii.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06697; Mon, 14 Jun 93 19:03:40 MET DST
Received: from galaxy.net.Hawaii.Edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03448; Mon, 14 Jun 1993 19:25:45 +0200
Received: from foralie.net.hawaii.edu ([132.160.3.1]) by galaxy.net.Hawaii.Edu with SMTP id <119841>; Mon, 14 Jun 1993 07:23:26 -1000
Date: 	Mon, 14 Jun 1993 07:21:18 -1000
From: Torben Noerup Nielsen <torben@hawaii.edu>
Sender: Torben Noerup Nielsen <torben@hawaii.edu>
Subject: re: HTML+ support for eqn & Postscript
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: janssen@parc.xerox.com, www-talk@nxoc01.cern.ch
In-Reply-To: <9306140936.AA00563@manuel.hpl.hp.com>
Message-Id: <MailManager.740078478.151.torben@foralie.net.hawaii.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dave,
>Well both of these will be possible with the HTML+ DTD, by using the
>capability to embed foreign formats inline in the HTML+ source, e.g.
>
>         <H2>A example of an equation</H2>
>
>         <EMBED TYPE="text/eqn">zeta (s) ~=~ sum from k=1 to inf
>          k sup -s ~~~ (Re s &gt; 1) </EMBED>
>
>The browser identifies the format of the embedded data from the "type"
>attribute, specified as a MIME content type. Certain characters need to
>be escaped using entity definitions, e.g. ">" by "&gt;" in the example.
>
>Building in support for a range of formats has the danger of leading to
>very large programs for browsers. This could be avoided by using a common
>API for rendering foreign formats, e.g. as functions that take a sequence
>of bytes and return a pixmap.

Well, it may be the best that we're going to get. However, I still feel that
equations are too basic to not be supported directly. Note that the more
successful text processing systems (and that's part of what this will have to
be) all support text, equations and tables nicely.

Thanks, Torben


From daemon  Mon Jun 14 19:29:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07209; Mon, 14 Jun 93 19:29:41 MET DST
Return-Path: <strata@virtual-city.virtual.net>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07204; Mon, 14 Jun 93 19:29:39 MET DST
Received: from HYBRID.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06778; Mon, 14 Jun 1993 19:51:44 +0200
Received: from virtual-city.virtual.net. by  hybrid.com (4.1/SMI-4.1)
	id AA00293; Mon, 14 Jun 93 10:49:14 PDT
Received: by virtual-city.virtual.net. (4.1/SMI-4.1)
	id AA03296; Mon, 14 Jun 93 10:47:03 PDT
Date: Mon, 14 Jun 93 10:47:03 PDT
From: "M. Strata Rose" <strata@virtual-city.virtual.net>
Reply-To: strata@hybrid.com
To: daemon@nxoc01.cern.ch
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Subject: Re: Style sheets for HTML
In-Reply-To: Your message of Sun, 13 Jun 1993 13:51:46 -0400 (EDT)
Message-Id: <CMM.0.90.2.740080023.strata@virtual-city.virtual.net>


I can't comment on the degree of overhead involved in having multiple media
links in the same document, but specifying a style sheet for xwindows or a
random palmtop or whatever seems extremely useful.  Those of us in the MOO
community and the educational community have a body of people used to a
particular style of interfaces, and this sort of style sheet support would
make it much easier for us to integrate tools like Mosaic into our existing
environments. 

_Strata

M. Strata Rose
Unix  & Network Consultant
Virtual City Project
strata@hybrid.com
strata@apple.com
strata@eddie.mit.edu


From daemon  Mon Jun 14 19:37:55 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07391; Mon, 14 Jun 93 19:37:57 MET DST
Return-Path: <kevin@scic.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07386; Mon, 14 Jun 93 19:37:55 MET DST
Received: from ssd.intel.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07286; Mon, 14 Jun 1993 19:59:59 +0200
Received: from sv002.scic.intel.com by SSD.intel.com (4.1/SMI-4.1)
	id AA16163; Mon, 14 Jun 93 10:59:53 PDT
Received: from rs042.scic.intel.com by sv002.scic.intel.com (4.1/SCICX.1.11); Mon, 14 Jun 93 10:59:51 PDT
Received: from mc024.scic.intel.com by rs042.scic.intel.com (AIX 3.2/UCB 5.64/SCICI.1.11); Mon, 14 Jun 1993 10:59:44 -0700
Message-Id: <9306141759.AA27367@rs042.scic.intel.com>
Date: Mon, 14 Jun 1993 10:58:53 -0800
To: www-talk@nxoc01.cern.ch
From: kevin@scic.intel.com (Kevin Altis)
X-Sender: kevin@rs042.scic.intel.com
Subject: Re: SPaces and Tabs in HTML documents

I believe the proper thing to do is to have a way of specifying horizontal
whitespace as well as settings for tabs specified in units (inches,
centimeters, and points at a minimum). Support for right justification is
important, especially to support text that reads right to left such as
arabic, hebrew and kanji. Full justification would be nice, but is
complicated. The ability for an author to specify a recommended style sheet
per document, defining typefaces, point sizes, tab settings, etc. would be
beneficial.

Monospaced typefaces such as Courier are not commonly used to view
documents outside of DOS, character based terminals and shell windows. In
graphical environments and printing, the width of a "space" or
uninterpreted "tab" will vary widely depending on typeface (Times,
Helvetica, etc.), type size, "style" (bold, italics, etc.), so documents
created today that make assumptions about whitespace by using "space"
characters are going to look real bad tomorrow. Just look at the
progression of documents on the Mac, Windows and Unix as people figured
that out, not to mention proper use of double quotes, capitalization, and
other grammar and punctuation (See Robin Wiliams "The Mac is not a
typewriter" or "The PC is not a typewriter" at your local bookstore).
Scalable font technology (ATM and Truetype), fractional spacing support in
applications, kerning between characters and words, etc. can all change the
look of a document, particularly one relying on the use of spaces for
whitespace. Also, keep in mind that display resolutions and actual dots per
inch (dpi) of monitors varies and higher dpi monitors are becoming more
common (120 dpi has been available for a while).

There is no reason to assume 80 characters per line either.

Kevin Altis
Intel Corporation
SuperComputer Systems Division
Beaverton, Oregon


From daemon  Mon Jun 14 20:15:23 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08097; Mon, 14 Jun 93 20:15:35 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08089; Mon, 14 Jun 93 20:15:23 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11613; Mon, 14 Jun 1993 20:37:27 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11669>; Mon, 14 Jun 1993 11:36:17 PDT
Received: by holmes.parc.xerox.com id <16134>; Mon, 14 Jun 1993 11:36:07 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon, 14 Jun 1993 11:36:05 -0700 (PDT)
Message-Id: <Yg7AIJ8B0KGW9gectj@holmes.parc.xerox.com>
Date: 	Mon, 14 Jun 1993 11:36:05 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: torben@hawaii.edu, janssen@parc.xerox.com,
        Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HTML+ support for eqn & Postscript
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306140936.AA00563@manuel.hpl.hp.com>
References: <9306140936.AA00563@manuel.hpl.hp.com>

Excerpts from ext.WorldWideWeb: 14-Jun-93 HTML+ support for eqn & Pos..
Dave_Raggett@hplb.hpl.hp (1775)

> Browsers can then be upgraded to display new formats without changing their
> code at all. All you would need is a way of binding the MIME content type
> to the function name for that format, e.g. via X resources or a config file.
> The functions could be implemented as separate programs driven via pipes and
> stdin/stdout or as dynamically linked library modules (Windows DLLs).

Yes, that sounds good.  My favorite way to handle this is to have the
browser create and manage an X sub-window over the area where the inset
is to be displayed, and pass the window ID of the sub-window to the
subprogram which understands the inset format, with the understanding
that that program is to handle all events and refresh on the sub-window,
but the browser gets to handle configuration and window movement.

Bill

From daemon  Mon Jun 14 21:06:41 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09005; Mon, 14 Jun 93 21:06:44 MET DST
Return-Path: <cshotton@oac.hsc.uth.tmc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09000; Mon, 14 Jun 93 21:06:41 MET DST
Received: from oac.hsc.uth.tmc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15439; Mon, 14 Jun 1993 21:28:27 +0200
Message-Id: <9306141928.AA15439@dxmint.cern.ch>
Received: from oac2.hsc.uth.tmc.edu by oac.hsc.uth.tmc.edu with SMTP
	(1.37.109.4/16.2) id AA24377; Mon, 14 Jun 93 14:23:12 -0500
Date: Mon, 14 Jun 1993 14:27:22 -0600
To: dale@ora.com (Dale Dougherty)
From: cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton)
Subject: Re: SPaces and Tabs in HTML documents
Cc: www-talk@nxoc01.cern.ch

>I object to collapsing spaces everywhere outside of PRE.
>I agree that coding multiple spaces is not a wise thing
>to do, but I must believe that lacking better solutions,
>we need spaces.

I disagree. White space should be "transparent" because it doesn't mean the
same thing from display to display. What is an 8 character wide tab on a
VT100 turns into some arbitrary chunk of white space on other displays.
What is really needed is some sort of marker like <indent> or <space> with
arguments in some universal unit.

This brings up another white space, namely the question of line ends in
<pre> blocks. What IS the "legal" end of line terminator in HTML? CR/LF? LF
only? Many documents with <pre> sections look great on one client and
horrible on others because of the inconsistent treatment of end of line
characters. 
--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                             \ 
Assistant Director, Academic Computing     \   "Are we there yet?"
U. of Texas Health Science Center Houston   \ 
cshotton@oac.hsc.uth.tmc.edu  (713) 794-5650 \ 
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_-


From daemon  Mon Jun 14 21:59:06 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10201; Mon, 14 Jun 93 21:59:10 MET DST
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10194; Mon, 14 Jun 93 21:59:06 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21065; Mon, 14 Jun 1993 22:21:06 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA13514; Mon, 14 Jun 93 16:20:54 EDT
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA12460; Mon, 14 Jun 93 16:20:51 -0400
Date: Mon, 14 Jun 93 16:20:51 -0400
Message-Id: <9306142020.AA12460@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Cc: mory@athena.mit.edu, mengwong@pobox.upenn.edu, jkp@cs.hut.fi
Subject: Central index of internet resources 


Do you have a term paper, report, internal documentation, how-to,
lecture notes that may be of use to the net as a whole?  If so.....

*********

USENET UNIVERSITY -- NEW NETWORK ACADEMY -- META-LIBRARY
CALL FOR SUBMISSIONS

The UU-NNA Meta-library is a central WWW server containing an index of
various information sources.  It is currently in beta-test and will be
open to the public on 1 July 1993.  If you have a material or service
which you would like listed in the index, please fill out this form
and send it to joe@athena.mit.edu.  Examples of source material which
may be indexed are term papers, lecture notes, internal documentation,
short how-to's, etc. etc.

PLEASE DO NOT SEND THE SOURCE MATERIAL!!!!  The library is serves simply
as an index to materials on the Internet.  I don't have the disk space
to store the material itself.....

School and department the source material should be classifed as:

Author of the material:

Title of the material:

Description of the material:

Format of the material (the preferred format is Hypertext Markup Language):

Keywords for the material:


How do you wish to make the material available (supported methods are
anonymous ftp, gopher, world-wide-web, and wais).


What is the location of the material (i.e. if by anonymous ftp, give the
machine and filename of the material, if by wais, give a search that will
get the material etc., etc.).  If you can give me a universal resource
locator, please do so.







From daemon  Mon Jun 14 22:35:32 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11039; Mon, 14 Jun 93 22:35:34 MET DST
Return-Path: <rmah@panix.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11035; Mon, 14 Jun 93 22:35:32 MET DST
Received: from sun.Panix.Com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25221; Mon, 14 Jun 1993 22:57:29 +0200
Received: by sun.Panix.Com id AA15472
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Mon, 14 Jun 1993 16:57:19 -0400
Date: Mon, 14 Jun 1993 16:55:54 -0400 (EDT)
From: Robert Mah <rmah@panix.com>
Subject: Unsubscribe me
To: www-talk@nxoc01.cern.ch
In-Reply-To: <9306141928.AA15439@dxmint.cern.ch>
Message-Id: <Pine.3.05.9306141652.A14771-9100000@sun.panix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm afraid I have to cancel my subscribtion to www-talk.  So could I
please be taken off the mailing list.  Thanks for all the info!

Cheers,
Rob

---------------------------------------------------------------------
Robert S. Mah   | Voice: (212) 947-6507 | "Every day an adventure,
One Step Beyond | EMail: rmah@panix.com |  every moment a challenge."



From daemon  Mon Jun 14 23:13:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11913; Mon, 14 Jun 93 23:13:43 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11908; Mon, 14 Jun 93 23:13:40 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29319; Mon, 14 Jun 1993 23:35:45 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11654>; Mon, 14 Jun 1993 14:35:13 PDT
Received: by holmes.parc.xerox.com id <16134>; Mon, 14 Jun 1993 14:35:06 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon, 14 Jun 1993 14:34:58 -0700 (PDT)
Message-Id: <gg7Cw2AB0KGWRgeYdv@holmes.parc.xerox.com>
Date: 	Mon, 14 Jun 1993 14:34:58 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: timbl@nxoc01.cern.ch, marca@ncsa.uiuc.edu (Marc Andreessen),
        dale@ora.com (Dale Dougherty)
Subject: Re: SPaces and Tabs in HTML documents
Cc: Damian Cugley <Damian.Cugley@prg.ox.ac.uk>, www-talk@nxoc01.cern.ch,
        terry@ora.com, kramer@ora.com
In-Reply-To: <9306140941.ZM13648@rock.west.ora.com>
References: <9306141623.AA02170@www3.cern.ch>
	<9306140941.ZM13648@rock.west.ora.com>

Excerpts from ext.WorldWideWeb: 14-Jun-93 Re: SPaces and Tabs in HTML..
Dale Dougherty@ora.com (827)

>  Where this has caused us problems in
> Xmosaic is in documents that have an inline image followed
> on the same line by text.  There's no good way to get proper
> spacing between the image and the first character.

"Proper spacing" is purely a function of the presentation tool, not of
the document.

Bill

From daemon  Mon Jun 14 23:17:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11970; Mon, 14 Jun 93 23:17:58 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11965; Mon, 14 Jun 93 23:17:56 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29476; Mon, 14 Jun 1993 23:40:00 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11614>; Mon, 14 Jun 1993 14:37:45 PDT
Received: by holmes.parc.xerox.com id <16134>; Mon, 14 Jun 1993 14:37:37 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon, 14 Jun 1993 14:37:31 -0700 (PDT)
Message-Id: <sg7CyPcB0KGW1geZ9F@holmes.parc.xerox.com>
Date: 	Mon, 14 Jun 1993 14:37:31 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, kevin@scic.intel.com (Kevin Altis)
Subject: Re: SPaces and Tabs in HTML documents
In-Reply-To: <9306141759.AA27367@rs042.scic.intel.com>
References: <9306141759.AA27367@rs042.scic.intel.com>

Excerpts from ext.WorldWideWeb: 14-Jun-93 Re: SPaces and Tabs in HTML..
Kevin Altis@scic.intel.c (1842)

> I believe the proper thing to do is to have a way of specifying horizontal
> whitespace as well as settings for tabs specified in units (inches,
> centimeters, and points at a minimum). Support for right justification is
> important, especially to support text that reads right to left such as
> arabic, hebrew and kanji. Full justification would be nice, but is
> complicated. The ability for an author to specify a recommended style sheet
> per document, defining typefaces, point sizes, tab settings, etc. would be
> beneficial.

You must be thinking of some other markup format.  HTML+ should not
support *any* of this.  It's supposed to support *generic*, *meaningful*
markup, not procedural typographic junk.

Bill

From daemon  Mon Jun 14 23:35:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12290; Mon, 14 Jun 93 23:35:42 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12286; Mon, 14 Jun 93 23:35:40 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01696; Mon, 14 Jun 1993 23:57:45 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA23366; Mon, 14 Jun 1993 17:57:34 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA17394; Mon, 14 Jun 1993 14:57:33 -0700
Message-Id: <199306142157.AA17394@ora.com>
From: Terry Allen <terry@ora.com>
Date: Mon, 14 Jun 1993 14:57:33 PDT
In-Reply-To: Bill Janssen <janssen@parc.xerox.com>
       "Re: Spaces outside PRE" (Jun 14,  2:34pm)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: Bill Janssen <janssen@parc.xerox.com>
Subject: Re: Spaces outside PRE
Cc: www-talk@nxoc01.cern.ch

Your response is dead wrong.  I must have some way of indicating
to the application where I want white space, or I do not have
sufficient control over the formatting of my documents.  How
the browser *handles* my request for white space is a 
presentational issue.  But white space in general is *not*
purely presentational.  This is all the more important because
of the limited range of markup possible in so generalized a
system as HTML.

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Tue Jun 15 01:30:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14064; Tue, 15 Jun 93 01:30:43 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14060; Tue, 15 Jun 93 01:30:40 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13844; Tue, 15 Jun 1993 01:52:46 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11698>; Mon, 14 Jun 1993 16:52:24 PDT
Received: by holmes.parc.xerox.com id <16134>; Mon, 14 Jun 1993 16:52:16 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Mon, 14 Jun 1993 16:52:08 -0700 (PDT)
Message-Id: <wg7EwcQB0KGWBgego2@holmes.parc.xerox.com>
Date: 	Mon, 14 Jun 1993 16:52:08 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: Terry Allen <terry@ora.com>
Subject: Re: Spaces outside PRE
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <199306142157.AA17394@ora.com>
References: <199306142157.AA17394@ora.com>

Excerpts from ext.WorldWideWeb: 14-Jun-93 Re: Spaces outside PRE Terry
Allen@ora.com (558)

> I must have some way of indicating
> to the application where I want white space, or I do not have
> sufficient control over the formatting of my documents.

Sorry, you're not supposed to have control over the formatting of your
documents, in the sense that I think you mean.  (I may be
misinterpreting your meaning; could you say a bit more about why
"whitespace in general is *not* purely presentational"?)  There are
plenty of formats that support that kind of thing; there's no need to
turn HTML into yet-another-bastardized-procedural-markup format.

I think it's pretty clear, though, that there's a lot of desire for
browsers like XMosaic to support both HTML and one or more additional
procedural formats, such as TeX or MS-Word.

Bill

From daemon  Tue Jun 15 01:35:21 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14148; Tue, 15 Jun 93 01:35:23 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14143; Tue, 15 Jun 93 01:35:21 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14012; Tue, 15 Jun 1993 01:57:27 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA15880; Mon, 14 Jun 1993 19:57:22 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA19171; Mon, 14 Jun 1993 16:57:20 -0700
Message-Id: <199306142357.AA19171@ora.com>
From: Terry Allen <terry@ora.com>
Date: Mon, 14 Jun 1993 16:57:20 PDT
In-Reply-To: Bill Janssen <janssen@parc.xerox.com>
       "Re: Spaces outside PRE" (Jun 14,  4:52pm)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: Bill Janssen <janssen@parc.xerox.com>
Subject: Re: Spaces outside PRE
Cc: www-talk@nxoc01.cern.ch

Quick example:

This sentence uses white space to separate words.

Thissentenceuseswhitespacetoseparatewords.

Unless you tag every word, that white space has meaning.  It is
not purely presentational.  

Similarly with other uses of white space:  if one represented by
tagging everything white space can be used for, you wouldn't 
need it.  But in a small tag set such as HTML, you can't get
along without it.  Even in a large SGML DTD provision is not
made for all the things one might use white space for,
meaningfully.

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Tue Jun 15 01:41:45 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14232; Tue, 15 Jun 93 01:41:47 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14227; Tue, 15 Jun 93 01:41:45 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14240; Tue, 15 Jun 1993 02:03:42 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28335
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 14 Jun 93 19:03:03 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:terry@ora.com id AA18971; Mon, 14 Jun 93 19:05:47 -0500
Date: Mon, 14 Jun 93 19:05:47 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306150005.AA18971@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: Terry Allen <terry@ora.com>, www-talk@nxoc01.cern.ch
Subject: Re: Spaces outside PRE
In-Reply-To: <wg7EwcQB0KGWBgego2@holmes.parc.xerox.com>
References: <199306142157.AA17394@ora.com>
	<wg7EwcQB0KGWBgego2@holmes.parc.xerox.com>
X-Md4-Signature: 9c5a20cb10112393ade8d514102e3c65

Bill Janssen writes:
> I think it's pretty clear, though, that there's a lot of desire for
> browsers like XMosaic to support both HTML and one or more additional
> procedural formats, such as TeX or MS-Word.

That would fit into the $1,000,000+ feature request category.  :-)

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Tue Jun 15 04:09:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15689; Tue, 15 Jun 93 04:09:45 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15685; Tue, 15 Jun 93 04:09:42 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27916; Tue, 15 Jun 1993 04:31:49 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576709-3>; Mon, 14 Jun 1993 22:31:42 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA04581; Mon, 14 Jun 93 22:21:29 EDT
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306150221.AA04581@begbick.law.cornell.edu.law.cornell.edu>
Subject: Lost in spaces
To: www-talk@nxoc01.cern.ch
Date: Mon, 14 Jun 1993 22:21:28 -0400
X-Mailer: ELM [version 2.2 PL15]

Folks:

I had hoped to stay right out of this one, but I think perhaps a dash
of practicality is in order.  One for which I will probably be
electronically lynched, but such are the risks.

The current debate over whitespace is a glaring example of the sort of
thing which has disadvantaged HTML vis a vis rougher (and readier)
non-standards like Gopher from the beginning.  I have been on the
stump for WWW a good bit lately amongst law schools, many of whom are
looking at putting up some kind of server capability for the first
time, and for whom _any_ move toward new technology is done at the
expense of a primary mission of low-level support for faculty and
student activity.  These people are not exactly grabbing pitons and
running out to look for a learning curve to scale, and there is a
general perception that hypertext is hard, it's much easier just to
dump an unformatted file into Gopher and it's almost as good.  I
happen not to agree with this, and am devoting a certain amount of
time and effort to weaning them from this attitude.  But say SGML in
anything above a soothing whisper and they run from the room.

I sure hope that none of them took my proselytizing at a conference in
Chicago last week seriously enough to subscribe to www-talk in 
some hope of finding out what the Web is about.  I suspect they would
be a mite bewildered by the religious warfare amongst the Ayatollahs
of Em Space.

I agree that bastardizing standards is a rotten idea and in
the long run complicates implementors' lives a little, maybe.  Just
maybe. But something as inherently counterintuitive as taking all
control over whitespace away from an author -- or allowing them to
retain it by creating a tagset the size of the Manhattan phone book --
sure isn't going to put a lot of docs on the Web very quickly,
whatever it may do for the purity of the standard.

Uncharacteristically difficult tonight,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Tue Jun 15 05:59:08 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16446; Tue, 15 Jun 93 05:59:10 MET DST
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16442; Tue, 15 Jun 93 05:59:08 MET DST
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09362; Tue, 15 Jun 1993 06:21:03 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA04854; Mon, 14 Jun 93 23:20:57 -0500
Message-Id: <9306150420.AA04854@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Spaces and Tabs in HTML documents 
Reply-To: www-talk@nxoc01.cern.ch
Organization: Berkeley Software Design, Inc.
Date: Mon, 14 Jun 1993 23:20:56 -0500
From: Tony Sanders <sanders@bsdi.com>

How about having two <PRE> style tags.  One works just like existing <PRE>
and another tag that (probably) doesn't use the fixed-width font but does
preserves spaces and tabs as much as possible and allows full HTML mark-up.
It will be the task of the browser to make this look good.  This way you
can write freestyle HTML or where needed switch into pseudo-fixed-width
mode (<PFW>? :-).  This was we can keep the freestyle input of HTML
which I much prefer, but still allow a back-door for those cases
that require special spacing but don't really need pure fixed-width.
Think of it as three levels of control:
    1) spaces mean nothing (default)
    2) spaces mean something
    3) fully preformatted text, don't mess with it

One other thing I would like to note is that <PRE> tends to imply computer
generated text that you *want* to be in a courier like font.  <PFW> would
imply that it's pre-formated at some level (which I'll leave open for
debate) but it's generally not something that wants a courier type font.
Perhaps we need one more level (2.5) that is for fully preformatted text
(just like <PRE>) but that you probably don't want a courier font for it
either.  In reality we'll probably have options to PRE, like TYPE="spaces",
TYPE="spaces/indent", with TYPE="preforamtted" being the default.

This isn't a fully developed idea, I just wanted to toss it out for
consideration as an option.

As a side note (just to generate some controversy more interesting
than spaces and tabs).

Let's keep in mind that while pure generalized markup is a good thing,
HTML is ultimately a presentation format.  HTML is not, should not, and
can not be the DTD to end all DTD's so if we want to be able to represent
a wide variety of formats in HTML we are going to have to give *some*
level of control to the author in some cases.  Emphasis is a good example
of this.  HTML simply cannot include semantic tags for every frickin'
thing you can think of.  At some point you fall back to something like
italic/bold (or <EM>/<STRONG> or whatever).  The <PRE> tag itself
is a major back-door to allow all kinds of author specified layout.

Clearly we want generalized markup as much as possible, but for a
presentation format we need some basics to fall back on or we are just
shooting ourselves in the foot.  SGML bigots are missing the big picture,
99.999% of the existing data *doesn't have* semantic information and no
one gives a shaving cream about it; we just want it online and some of us
would like to access it via hypertext.  Man pages are a good example of
this (you can hypertext the references to other man pages, but you can't
put semantic tags back where there is only bold and italic text).  Also,
since you pretty much have to process already formated man pages the layout
is fixed (this is where <PRE> comes in handy).

--sanders

From daemon  Tue Jun 15 06:27:37 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16601; Tue, 15 Jun 93 06:27:38 MET DST
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16596; Tue, 15 Jun 93 06:27:37 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12054; Tue, 15 Jun 1993 06:49:39 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0o5Sxl-000EatC; Tue, 15 Jun 93 00:49 EDT
Message-Id: <m0o5Sxl-000EatC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: "home pages for newsgroups" project
Date: Tue, 15 Jun 1993 00:49:36 -0400
From: Edward Vielmetti <emv@garnet.msen.com>

I'm looking for a collaborator in a project to build "home pages"
for a bunch of Usenet newsgroups.


Many netnews groups have archives, special collections, or associated
gopher, wais, or world wide web servers that go along with them.
Current network information about these resources is scattered hither
and yon, in FAQ files, in archie, in wais, etc. etc.  If you don't
know what you are looking for it can be mighty tricky to find it,
and in many cases its more work than it should be.

I'd like to propose a standard "home page" format (probably a DTD, eh?)
for a newsgroup.  At the very minimum this could be automatically
generated from the great big lists of newsgroups.  With more work
it would systematically and regularly collect information about
groups, so that readers coming on new could get up to speed fast,
or so that long-suffering netheads could help guide new people to
the "right" group.

I've put together a tagged file format for a newsgroup description.
It's not HTML (not presentation oriented) but it should be straightforward
to munch on it to turn it into HTML.  I'll send copies to anyone
who is willing to send back a similarly tagged version of their
favorite group.  

thanks

From daemon  Tue Jun 15 08:15:11 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17170; Tue, 15 Jun 93 08:15:14 MET DST
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17166; Tue, 15 Jun 93 08:15:11 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26401; Tue, 15 Jun 1993 08:37:03 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0o5UdQ-000EavC; Tue, 15 Jun 93 02:36 EDT
Message-Id: <m0o5UdQ-000EavC@garnet.msen.com>
To: dale@ora.com (Dale Dougherty)
Cc: timbl@nxoc01.cern.ch, marca@ncsa.uiuc.edu (Marc Andreessen),
        Damian Cugley <Damian.Cugley@prg.ox.ac.uk>, www-talk@nxoc01.cern.ch,
        terry@ora.com, kramer@ora.com
Subject: Re: SPaces and Tabs in HTML documents 
In-Reply-To: Your message of "Mon, 14 Jun 93 09:41:19 PDT."
             <9306140941.ZM13648@rock.west.ora.com> 
Date: Tue, 15 Jun 1993 02:36:42 -0400
From: Edward Vielmetti <emv@garnet.msen.com>

the issue of "how do we treat spaces" in html is a symptom of another
problem with the way development is starting to go.

if you are an SGML purist, you are going to mark up your document
in a format that's semantically correct (chapters are chapters,
paragraphs are paragraphs, and that blob of white space is a
carefully constructed signifier of an emphatic   pause).

you then take your SGML document and transmute it into another SGML
document, one with a simpler format and more concrete representation.
in the World Wide Web you make the decision that <chapter> means
<h1>, text inside <sidenote> should be marked as such to show up as
you want it on screen, etc etc.

lots of people are going to do lots of browsers.  you have to pick
which one you expect things to look "best" in and work to that.  you
may want to generate text for paper, in which case your original markup
may get transmuted into a different format for the paper layout.

the "transmute" step is one people seem to be missing.  i would like
to see more tools thought through that generate HTML as an output
of another process which starts with a richer document model.

--Ed

From daemon  Tue Jun 15 09:27:22 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17944; Tue, 15 Jun 93 09:27:24 MET DST
Return-Path: <@gps1.leeds.ac.uk%benw@chem.leeds.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17940; Tue, 15 Jun 93 09:27:22 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07026; Tue, 15 Jun 1993 09:49:29 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Tue, 15 Jun 1993 09:48:50 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Tue, 15 Jun 1993 09:47:24 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 09:46:13 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 09:44:00 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 09:46:03 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 09:46:02 +0200
Date: Tue, 15 Jun 1993 09:46:02 +0200
X400-Originator: benw <benw@chemistry.leeds.ac.uk>
X400-Recipients: www-talk@NXOC01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<8527.9306150746@chemistry.leeds]
X400-Content-Type: P2-1984 (2)
Content-Identifier: (l)q(r)home page
From: Ben Whitaker <benw@chem.leeds.ac.uk>
Message-Id: <8527.9306150746@chemistry.leeds.ac.uk>
To: www-talk <www-talk@nxoc01.cern.ch>
Subject: "home pages for newsgroups"
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 749

Edward Vielmetti <emv@COM.MSEN.GARNET> writes:

>
> I'm looking for a collaborator in a project to build "home pages"
> for a bunch of Usenet newsgroups.
>
> .....

Sorry but I'm not voluntering :-). However, it has often struck me,
as a I pull back a few thousand newsgroups, that constructs such as
<a name=news href=news:*>Usenet News</a> might sensibley look for 
a .newsrc in ~ and only pull back subscribed groups. I guess this is
something for the NCSA crew.

Ben Whitaker

****************************************************************************
School of Chemistry				email: benw@uk.ac.leeds.chem
University of Leeds, Leeds LS2 9JT, UK  	voice: 44.532.336580
****************************************************************************

From daemon  Tue Jun 15 15:29:23 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22672; Tue, 15 Jun 93 15:29:27 MET DST
Return-Path: <P.lister@mail.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22667; Tue, 15 Jun 93 15:29:23 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05426; Tue, 15 Jun 1993 15:51:22 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Tue, 15 Jun 1993 15:50:42 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Tue, 15 Jun 1993 15:49:41 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 15:48:56 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 15:48:44 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Tue, 15 Jun 1993 15:48:42 +0200
Date: Tue, 15 Jun 1993 15:48:42 +0200
X400-Originator: P.lister@mail.cranfield.ac.uk
X400-Recipients: www-talk@nxoc01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9306151348.AA26252@xdm039.ccc.c]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: SPaces an...
From: "Peter Lister, Cranfield Computer Centre" <P.lister@mail.cranfield.ac.uk>
Message-Id: <9306151348.AA26252@xdm039.ccc.cranfield.ac.uk>
To: www-talk@nxoc01.cern.ch
Cc: P.lister@mail.cranfield.ac.uk
In-Reply-To: <9306151145.AA11793@xdm001>
Subject: Re: SPaces and Tabs in HTML documents

> the "transmute" step is one people seem to be missing.  i would like
> to see more tools thought through that generate HTML as an output
> of another process which starts with a richer document model.

Three cheers. :-0 :-0 :-0

It seems fairly clear to me that HTML's beauty is as a publication
protocol; but the top-level source of a document should <em>NOT</em>
use it. I compose documents in terms of semantics (i.e. "top-level
heading") not "big font, carriage return at the end"), and I feel quite
strongly that not only can I do without control over the formatting of
my documents, I actively don't want it.

Cranfield has an house style for paper documents designed by experts,
but it's not used much because each author must lay a document out by
hand, or pay a secretary to do so. Ideally, authors should be able to
produce a high level description in their favourite authoring tool, and
then translate to whatever formats are needed: a paper (e.g.
PostScript) copy in the "house style"; HTML which browsers can display
according to the (human) reader's preferences (which may be quite
unexpected for, say, a partially sighted user); entries for a
bibliographic database, and so on.

An interesting point occurs to me. Voice simulation for the blind is
becoming more and more sophisicated. It can't been too long before
spoken hypertext is available. Anyone considered how HTML might cope
with that? I suggest that only semantic markup will be of much use....

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From daemon  Tue Jun 15 16:25:44 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24059; Tue, 15 Jun 93 16:25:47 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24055; Tue, 15 Jun 93 16:25:44 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19656; Tue, 15 Jun 1993 16:47:52 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03441; Tue, 15 Jun 93 16:47:22 +0200
Date: Tue, 15 Jun 93 16:47:22 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306151447.AA03441@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: jds@kudzu.cnidr.org (Jane Dunlap Smith)
Subject: HTML editor for the NeXT -- version 0.16
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>From: jds@kudzu.cnidr.org (Jane Dunlap Smith)
>Date: Tue, 15 Jun 93 8:46:42 EDT
>
>Hi, Tim.
>
>Am I just being stupid and can't find it or does there exist an html
>editor for the NeXT?
>
>Jane Smith
>Clearinghouse for Networked Information Discovery and Retrieval


My fault ... firstly, the latest (still months old an buggy) wasn't  
there, secondly what was there wasn't stippred so it was rather big,
and thirdly it wasn't in a sensible place.

It is now /pub/www/bin/next/WorldWideWeb_0.16.tar.Z

There have been a few requests for this, if yours was one
please consider this a reply!

Remember to use

	dwrite WorldWideWeb NewsHost your.news.host

to set up the news host.
	
This is NOT an up-to-date browser --- it doesn't use the libwww  
library.
It has no Gopher or FTP access and has lots of bugs.  Our
priority list doesn't allow us to upgrade it.

If someone is interested in taking over the NextStep editor, then
we could talk about it.

Tim

From daemon  Tue Jun 15 17:42:49 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25990; Tue, 15 Jun 93 17:42:53 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25983; Tue, 15 Jun 93 17:42:49 MET DST
Received: from [140.186.65.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07326; Tue, 15 Jun 1993 18:04:52 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA20398; Tue, 15 Jun 1993 12:04:44 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA25260; Tue, 15 Jun 1993 09:04:42 -0700
Message-Id: <199306151604.AA25260@ora.com>
From: Terry Allen <terry@ora.com>
Date: Tue, 15 Jun 1993 09:04:41 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: Quad (was Spaces)

I think the various points of view have been well represented on
this issue, and fairly economically, too.  Let me make a practical
proposal:  I think I would be satisfied with a single white space
character (or entity), something like Tex's \quad, that is, an en
in the current font.  Is this something we can all accept as needed
even if some see it as impure SGML?

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Tue Jun 15 20:04:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28903; Tue, 15 Jun 93 20:05:00 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28897; Tue, 15 Jun 93 20:04:58 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01765; Tue, 15 Jun 1993 20:27:04 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11893>; Tue, 15 Jun 1993 10:29:17 PDT
Received: by holmes.parc.xerox.com id <16137>; Tue, 15 Jun 1993 10:26:08 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue, 15 Jun 1993 10:25:54 -0700 (PDT)
Message-Id: <og7UMWMB0KGW1gei55@holmes.parc.xerox.com>
Date: 	Tue, 15 Jun 1993 10:25:54 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: Spaces and Tabs in HTML documents
In-Reply-To: <9306150420.AA04854@austin.BSDI.COM>
References: <9306150420.AA04854@austin.BSDI.COM>

Excerpts from ext.WorldWideWeb: 14-Jun-93 Re: Spaces and Tabs in HTML..
Tony Sanders@bsdi.com (2846)

> Let's keep in mind that while pure generalized markup is a good thing,
> HTML is ultimately a presentation format.

Huh?  Where do you get this?  I thought it was a format for writing down
information.

Bill

From daemon  Tue Jun 15 20:04:55 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28894; Tue, 15 Jun 93 20:04:59 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28887; Tue, 15 Jun 93 20:04:55 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01759; Tue, 15 Jun 1993 20:27:02 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11973>; Tue, 15 Jun 1993 11:09:01 PDT
Received: by holmes.parc.xerox.com id <16135>; Tue, 15 Jun 1993 10:22:40 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Tue, 15 Jun 1993 10:22:38 -0700 (PDT)
Message-Id: <Yg7UJSwB0KGWJgehE0@holmes.parc.xerox.com>
Date: 	Tue, 15 Jun 1993 10:22:38 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, tom@begbick.law.cornell.edu (Thomas R. Bruce)
Subject: Re: Lost in spaces
In-Reply-To: <9306150221.AA04581@begbick.law.cornell.edu.law.cornell.edu>
References: <9306150221.AA04581@begbick.law.cornell.edu.law.cornell.edu>

Excerpts from ext.WorldWideWeb: 14-Jun-93 Lost in spaces Thomas R.
Bruce@begbick. (2359)

> I agree that bastardizing standards is a rotten idea and in
> the long run complicates implementors' lives a little, maybe.  Just
> maybe. But something as inherently counterintuitive as taking all
> control over whitespace away from an author -- or allowing them to
> retain it by creating a tagset the size of the Manhattan phone book --
> sure isn't going to put a lot of docs on the Web very quickly,
> whatever it may do for the purity of the standard.

I'm not arguing that authors shouldn't have control over the
presentation of their material, merely that they shouldn't have this
control *in HTML*.  There are plenty of markup formats which allow this
kind of thing; there's no need to add it to HTML.  There's also no
reason docs "on the Web" have to be in HTML -- if there's a better
format, use it!  This allows us to avoid the "rotten idea".

Bill


From daemon  Wed Jun 16 01:04:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05109; Wed, 16 Jun 93 01:04:50 MET DST
Return-Path: <gsstark@mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05105; Wed, 16 Jun 93 01:04:47 MET DST
Received: from MIT.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21427; Wed, 16 Jun 1993 01:26:57 +0200
Received: from DEATHTONGUE.MIT.EDU by MIT.EDU with SMTP
	id AA04097; Tue, 15 Jun 93 19:26:55 EDT
From: gsstark@mit.edu
Received: by deathtongue (5.0/4.7) id AA01120; Tue, 15 Jun 93 19:26:52 EDT
Date: Tue, 15 Jun 93 19:26:52 EDT
Message-Id: <9306152326.AA01120@deathtongue>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: "[106] in World Wide Web"
Subject: Re: Spaces and Tabs in HTML documents
Content-Length: 445

   > Let's keep in mind that while pure generalized markup is a good thing,
   > HTML is ultimately a presentation format.
Where did you get this? HTML is a very poor format for presentation.

If you want to specify presentation for a tool like xmosaic you need
something as powerful as tex or latex. HTML will never be capable of
that flexibility. HTML is only reasonable if the presentation client
decides how to actually format the document.

From daemon  Wed Jun 16 01:39:07 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05513; Wed, 16 Jun 93 01:39:10 MET DST
Return-Path: <grobe@ukanaix.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05509; Wed, 16 Jun 93 01:39:07 MET DST
Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26775; Wed, 16 Jun 1993 02:01:15 +0200
Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA37602; Tue, 15 Jun 1993 18:58:50 -0500
Date: Tue, 15 Jun 1993 18:58:50 -0500
From: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
Message-Id: <9306152358.AA37602@ukanaix.cc.ukans.edu>
To: www-talk@nxoc01.cern.ch


dave:

thanks for your reply. it was very helpful.  i have a couple of comments.

first, i mentioned that we are planning to use something like:
      <link rev=made href="mailto:...whatever..." >
to allow info providers to provide a path for readers (through their
clients) to contact them with comments.  note that this is a (static) "link"
rather than an (executable link, or) anchor, whereas your MSG tag is an
"executable" link.  lynx will support a command that will search out 
the static info and open a mail screen for the user with the address already
in place.  (actually, lynx already supports such a command when displaying
files in its native hypertext format, and we have found this so useful
that we feel we must duplicate it as we convert our documents to html
this summer.) so, even though MSG is a better solution, we can't wait.

also with respect to the markup of tables, it seems to me that it would be
useful to allow more explicit control over display of the headers, separately
from the body of the table.  that is, i might want to set up headers
that are not centered, but rather left- or right-justified. 

for example, suppose you want to mark up this table:

            average         maximum
          height in         weight in
              yards         metric tons

 males       1.9               .003
 females     1.7               .002


you could allow complete control over the header format by allowing
a second cols attribute applicable to only the headers, or, if you
didn't want to allow complete control you could just add
a placement attribute to specify center, left, or right justification,
giving a <dl> structure that would look something like:

   <dl cols="C7N1.1N0.3">
      <dthd>                       <! null column header >
      <ddhd right> average         <!-- first header line -->
      <ddhd left> maximum
      <dthd>                     <! null column header >
      <ddhd right> height in         <!-- second header line -->
      <ddhd left> weight in 
      <dthd>                       <!third header line>
      <ddhd right> yards
      <ddhd left> metric tons
  <dt>males <dd> 1.9 <dd> .003
  <dt>females <dd> 1.7 <dd> .002


the renderer would set up the right justified 
headers so that the longest header was centered over the data,
and the shorter headers were right justified with the longest one.

further, i suspect the renderer would center over the displayed
data rather than with respect to the designated columns.  the column
sizing is a matter of a maximum width, and may not even be close to
the width of the bulk of the data to be displayed. in this regard
the "cols" attribute may be more like a "datatype" than a format.
on the other hand, this would require an initial inspection pass.

>ISSUE: Is it a bad idea to overload definition lists for tables?

i think it would be easier for beginning users to have two separate
constructs, one for description lists and one for tables.  i know that
users building description lists could simply ignore the extra features
(if their teachers and the documentation they read can resist trying 
to tell them about all the extras!), but all users marking up tables 
would have to deal with the description list mnemonics.  if you
develop a <table> tag, you could get away from the dt and dd distinction
(if you so choose) or at least use something with better mnemonic
value for the user thinking s/he is marking up a table (or relation) rather
than a "description list".  

the first element of a table is (strictly speaking) no different from
the others (a table is simply a set of tuples) and, since
some tables have line-label information on the right and may even
have it in some other column or not at all, calling the first column 
a "description term" may actually confuse the user.  i suppose that you 
will still have to have a different tag to mark the start 
of a new record, of course, so you would end up with a <table> structure
looking something like: 

  <table cols="C5N6.2EL20">      <!-- just an example datatype-->
  <ch center|left|right s=n> text <h c|l|r s=n> text  <h c|l|r s=n> . . .
  <ch c|l|r s=n> text <h c|l|r s=n> text <h c|l|r s=n> . . .

       . . .

  <row>  data    <comma>  data    <comma> . . .
  <row>  data    <comma>  data    <comma> . . .

       . . .

  </table>

here again, some kind of style attribute might be useful, by the way.
and yes, that is one of those "comma" delimited lists you have heard
about.  i couldn't think of anything more mnemonic.

:michael grobe


From daemon  Wed Jun 16 04:44:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07479; Wed, 16 Jun 93 04:48:33 MET DST
Return-Path: <rgardner@charon.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07158; Wed, 16 Jun 93 04:44:31 MET DST
Received: from CHARON.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24215; Wed, 16 Jun 1993 05:06:40 +0200
Received:  by charon (5.57/2.3JIK)
	id <AA27257@charon>; Tue, 15 Jun 93 23:06:37 -0400
Message-Id: <9306160306.AA27257@charon>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Cc: rgardner@charon.mit.edu
Subject: stuff
Date: Tue, 15 Jun 93 23:06:36 EDT
From: "stuff available list" available on request--just ask for it! <rgardner@charon.mit.edu>

So you wanted to know about "stuff available"?
Or maybe I just decided you should get this.

Here's a list of some things.  You can get some
of this stuff once by asking.  You can get on a
mailing list for updates, additions, future stuff,
etc, by asking.  That's two things.  One is just
asking for some stuff.  Two is asking to get on one
of my mailing lists for stuff.  Ok, get ready!
Here's information about some "stuff":

1) art stuff, for instance, the Electronic Art &
Culture Postcard.  I send this out about once a
month to my EAACP mailing list.  You can get it once
by asking, and regularly by asking to get on my
mailing list for it.  There's more art stuff,
but you have to ask.

2) PC software/databases.  I compile databases and
wrap them in software.  Information about an ftp
site, and how to get copies from that site, are
available on request.

3) The Friedrichshof Chronicles.  This is a sort of
net.literature project of mine.  It is some writing
done while living on an artists commune some years
ago.  Contains "adult" material.  You have to very
explicitely ask for a sample of this.  Then you have
to very explicitely ask to get on the mailing list
for future chapters.  The Friedrichshof and
Cambridge Chronicles are also available on an anony-
mous ftp site--so you can read them anonymously.  I
will send you just ftp instructions if you ask.

4) The Cambridge Chronicles.  Like a diary.  Like
The Friedrichshof Chronicles, but written here in
Cambridge, Massachusetts, location of two of the
world's most opinionated zip codes.  You gotta ask.

5) net stuff.  I find net related stuff on the
Internet and save it.  Do you know about Gilder,
superdistribution, etc?  No?  Need I say more?

6) essays.  I write essays from time to time.
No telling what the next one will be about.  Ask
to get on my essay mailing list and you will get
a copy of each one as it comes off the assembly
line in my brain.

7) buzz.  A file of stuff written by me to people
or lists on the net.  So I'm an egomaniac and think
every word from my mouth is important!  So you don't
have to ask for it!  And I won't send it!  Phhhhttt!

8) books.  Some books "written and/or compiled"
by me.  Some very peculiar stuff.  Some inventions.
Some concepts--emphasis on the CON, as I tell people.

Please feel free to copy this file and send it to
anyone (but not a mailing list or news group, please)
you think might be interested.

If you are interested in any of the things on this
list, then send me mail and ask for something.  If
you are suspicious, and wonder just who the heck I
am, then you can try the finger command:

     finger rgardner@charon.mit.edu

Otherwise, send your email requests to:

     rgardner@charon.mit.edu

From daemon  Wed Jun 16 04:49:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07593; Wed, 16 Jun 93 04:49:33 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07586; Wed, 16 Jun 93 04:49:31 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24455; Wed, 16 Jun 1993 05:11:36 +0200
Received: by kauri.vuw.ac.nz id AA01643
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Wed, 16 Jun 1993 15:11:30 +1200
Date: Wed, 16 Jun 1993 15:11:30 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306160311.AA01643@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Resource estimation

For my proposal that's going to the committee here (I'm soon going to
make all my CWIS documents available for public review via our WWW
server -- I wrote them in HTML so it shouldn't be too hard to serve
them :-) I need some estimates of the hardware to run a dedicated WWW
server off.

We will have about 10,000 users (hopefully :-) and I hope for
relatively high usage.  Can anyone suggest a suitable platform?

Nat.

From daemon  Wed Jun 16 06:35:13 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10316; Wed, 16 Jun 93 06:35:15 MET DST
Return-Path: <jmt@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10312; Wed, 16 Jun 93 06:35:13 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12882; Wed, 16 Jun 1993 06:57:20 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA03400; Tue, 15 Jun 93 23:55:26 -0500
Received: from newkid (newkid.eitech.com) by eitech.com (4.1/SMI-4.1)
	id AA23822; Tue, 15 Jun 93 21:51:33 PDT
Date: Tue, 15 Jun 93 21:51:33 PDT
From: jmt@eitech.com (Marty Tenenbaum)
Message-Id: <9306160451.AA23822@eitech.com>
Received: by newkid (4.1/SMI-4.1)
	id AA01707; Tue, 15 Jun 93 21:49:44 PDT
To: Nathan.Torkington@vuw.ac.nz
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Nathan Torkington's message of Wed, 16 Jun 1993 15:11:30 +1200 <199306160311.AA01643@kauri.vuw.ac.nz>
Subject: Resource estimation

yet another one

From daemon  Wed Jun 16 06:50:27 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10393; Wed, 16 Jun 93 06:50:29 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10389; Wed, 16 Jun 93 06:50:27 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14510; Wed, 16 Jun 1993 07:12:34 +0200
Received: by kauri.vuw.ac.nz id AA06398
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Wed, 16 Jun 1993 17:12:28 +1200
Date: Wed, 16 Jun 1993 17:12:28 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306160512.AA06398@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Some CWIS meta-documents available

Anyone involved in setting up a CWIS is strongly urged by me to read
Prentiss Riddle's stuff.  Failing that, there's always the crapola
that I churn out:

	http://www.vuw.ac.nz/who/Nathan.Torkington/cwis/home.html

Currently, you can read: 

 o ``CWIS Defined'' 
 o ``A System For the Inclusion of Text Documents in a PAT Database'' 
 o ``IT Tools for VUW'' 
 o ``Candidate Databases for the CWIS'' 
 o ``Draft CWIS Strategic Plan (for review)'' 
 o ``Draft of CWIS Policy'' 

Enjoy;

Nat.

From daemon  Wed Jun 16 07:40:27 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10767; Wed, 16 Jun 93 07:40:29 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10763; Wed, 16 Jun 93 07:40:27 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21199; Wed, 16 Jun 1993 08:02:34 +0200
Received: by kauri.vuw.ac.nz id AA08104
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Wed, 16 Jun 1993 18:02:30 +1200
Date: Wed, 16 Jun 1993 18:02:30 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306160602.AA08104@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Bickering

Nothing terrifies me more than the petty bickering over HMML that is
happening here.  I fled gopher+ because of its gloated featuritis, and
I worry about the same thing happening here?  Will HMML become
unusable because every person and their dog is including pointless
features in the specs.

Nat
(my opinion on whitespace (or `shitespace' as my fingers tried to call
it :) is that it should be used as separators, and the quantity > 1
ignored)

From daemon  Wed Jun 16 09:20:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11678; Wed, 16 Jun 93 09:20:42 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11674; Wed, 16 Jun 93 09:20:40 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09532; Wed, 16 Jun 1993 09:42:50 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03875; Wed, 16 Jun 93 09:42:22 +0200
Date: Wed, 16 Jun 93 09:42:22 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306160742.AA03875@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: Re: Spaces and Tabs in HTML documents 
Cc: www-talk@nxoc01.cern.ch, bernd@crnvma.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>Date: Mon, 14 Jun 1993 23:20:56 -0500
>From: Tony Sanders <sanders@bsdi.com>
>
>How about having two <PRE> style tags.  One works just like existing  
<PRE>
>and another tag that (probably) doesn't use the fixed-width font but  
does
>preserves spaces and tabs as much as possible and allows full HTML  
mark-up.
>It will be the task of the browser to make this look good. 


	I am sceptical.   The significance of HT (the character)
	in PRE (the element) is to go to the "next" tab stop
	after the current position.
	If you don't know the relative font sizes, you can't predict
	where you will be, and so what the next stop will be.
	Any tabbing arrangement which allows variable width
	characters must therefore change the significance to
	"go to the left most tab stop you haven't used so far"
	and wrap the text when it reaches a tab stop by itself.
	Now we have tables.  And when we have tables, we will need
	lines in them of various types, and column headings and
	things.  And it will be good but it won't be tabs.


...[...]....
>shooting ourselves in the foot.  SGML bigots are missing the big  
picture,
>99.999% of the existing data *doesn't have* semantic information and  
no
>one gives a shaving cream about it; we just want it online and some  
of us
>would like to access it via hypertext.
...
>--sanders


	Nicely put! :-)
	HTML has to bridge between the 99.999% and rendering-
	free SGML whose justification we also all know.
	
	Tim

From daemon  Wed Jun 16 09:42:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11916; Wed, 16 Jun 93 09:42:44 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11912; Wed, 16 Jun 93 09:42:42 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12973; Wed, 16 Jun 1993 10:04:51 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03888; Wed, 16 Jun 93 10:04:22 +0200
Date: Wed, 16 Jun 93 10:04:22 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306160804.AA03888@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: Resource estimation
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>Date: Wed, 16 Jun 1993 15:11:30 +1200
>From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>

>
>For my proposal that's going to the committee here (I'm soon going  
to
>make all my CWIS documents available for public review via our WWW
>server -- I wrote them in HTML so it shouldn't be too hard to serve
>them :-) I need some estimates of the hardware to run a dedicated  
WWW
>server off.
>
>We will have about 10,000 users (hopefully :-) and I hope for
>relatively high usage.  Can anyone suggest a suitable platform?
>
>Nat.

In fact, the load on an HTTP server machine is very slight,
because the process only runs as long as it takes to return
the document. The info.cern.ch server which has the Subject
Catalogue gets probably a relatively high usage, about
10k requests a day, or (thinks...) one every 9 seconds.
the CPU load is negligible.  In fact of course the peak rate
is higher, but still its not really a factor.

So I would recommend that you chose the platform as one
which has good *reliability*, one which your operators will
know how to back up and handle in an emergency, one with
good connectivity  (like ability to mount appleshare and
Novell stuff might be useful).

A greater load than the httpd server will occur if
you allow telnet sessions to www or lynx, of course.
If you allow people to telnet in and select XMosaic
to their Xterminal, then you'd better get something
really beefy!

Remember to allow lots of disk room for logs.

Tim


From daemon  Wed Jun 16 10:21:53 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12302; Wed, 16 Jun 93 10:21:56 MET DST
Return-Path: <nop@theory.cs.mankato.msus.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12297; Wed, 16 Jun 93 10:21:53 MET DST
Received: from theory.CS.Mankato.MSUS.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21685; Wed, 16 Jun 1993 10:44:02 +0200
Received: by theory.cs.mankato.msus.edu (5.65/DEC-Ultrix/4.3)
	id AA08704; Wed, 16 Jun 1993 03:44:23 -0500
Date: Wed, 16 Jun 1993 03:44:23 -0500
From: nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
Message-Id: <9306160844.AA08704@theory.cs.mankato.msus.edu>
To: timbl@nxoc01.cern.ch
Cc: Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
In-Reply-To: Tim Berners-Lee's message of Wed, 16 Jun 93 10:04:22 +0200 <9306160804.AA03888@www3.cern.ch>
Subject: Resource estimation

> In fact, the load on an HTTP server machine is very slight,
> because the process only runs as long as it takes to return
> the document. The info.cern.ch server which has the Subject
> Catalogue gets probably a relatively high usage, about
> 10k requests a day, or (thinks...) one every 9 seconds.
> the CPU load is negligible.  In fact of course the peak rate
> is higher, but still its not really a factor.

Also note that httpd appears to be somewhat memory-hungry.  On my
DECstation 5000, running Ultrix, it used 8M to serve ONE PAGE.  In a
system serving more pages I can see that this kind of caching would be
useful, but in small systems you may wanna look at an alternative
server.

Jay Carlson
nop@theory.cs.mankato.msus.edu

Flat text is just *never* what you want.   ---stephen p spackman

From daemon  Wed Jun 16 11:59:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13511; Wed, 16 Jun 93 11:59:14 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13507; Wed, 16 Jun 93 11:59:12 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12874; Wed, 16 Jun 1993 12:21:20 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 16 Jun 93 11:13:26 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA16064; Wed, 16 Jun 93 11:19:34 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306161019.AA16064@manuel.hpl.hp.com>
Subject: Re: Em space, user fears of HTML
To: tom@law.mail.cornell.edu
Date: Wed, 16 Jun 93 11:19:32 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

I too am concerned about potential barriers to the success of the WWW.

> These people are not exactly grabbing pitons and
> running out to look for a learning curve to scale, and there is a
> general perception that hypertext is hard, it's much easier just to
> dump an unformatted file into Gopher and it's almost as good.  I
> happen not to agree with this, and am devoting a certain amount of
> time and effort to weaning them from this attitude.  But say SGML in
> anything above a soothing whisper and they run from the room.

We are having the same experience in Hewlett Packard. Users are rightly
concerned about learning new formats. My ideas for combatting this are:

        a) introduce simple to use WYSIWYG editors for HTML
           (should be much much easier than Microsoft Word etc.)

        b) it should be trivial to include plain ASCII documents
           (my browser automatically recognises different formats
            based on document content and/or file extensions)

        c) simple filters for converting common document formats to/from HTML
           (e.g. Microsoft Word via RTF)

        d) writing a good beginners guide for HTML aimed at minimising
           learning problems

        e) Getting out there and letting people know how good WWW is.

IMHO HTML is much simpler than most existing formats and once people
get over their fright, they will become enthusiasts.

Dave Raggett

p.s. what are the situations when people do want greater control over spacing?

From daemon  Wed Jun 16 12:47:04 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14221; Wed, 16 Jun 93 12:47:06 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14217; Wed, 16 Jun 93 12:47:04 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23330; Wed, 16 Jun 1993 13:09:12 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 16 Jun 93 12:01:19 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA16095; Wed, 16 Jun 93 12:07:27 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306161107.AA16095@manuel.hpl.hp.com>
Subject: Re: SPaces and Tabs in HTML documents 
To: emv@garnet.msen.com
Date: Wed, 16 Jun 93 12:07:26 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> you then take your SGML document and transmute it into another SGML
> document, one with a simpler format and more concrete representation.
> in the World Wide Web you make the decision that <chapter> means
> <h1>, text inside <sidenote> should be marked as such to show up as
> you want it on screen, etc etc.

You may care to look at the HTML+ DTD. It includes support for both of
these, whilst remaining a simple generic format:

    <P STYLE="MARGIN"> for sidenotes

    <GROUP TYPE="CHAPTER"> ... </GROUP>

The GROUP element is intended to enclose books, chapters, sections etc.
which may even extend over multiple HTML+ documents. I have made a special
effort to help authors preserve information when converting to HTML+
while allowing simple browsers to ignore such information. This has been
done without the need to an explosion of tags as in the ISO work on SGML DTDs.

> lots of people are going to do lots of browsers.  you have to pick
> which one you expect things to look "best" in and work to that.  you
> may want to generate text for paper, in which case your original markup
> may get transmuted into a different format for the paper layout.

HTML+ is intended to allow people to generate high quality paper documents
and includes features such as sidenotes and floating panels to that effect.
Tob Raisch's style sheets for HTML also promise to give authors greater
control without compromising the presentation independence of HTML+ itself.

Cheers,

Dave Raggett

From daemon  Wed Jun 16 12:52:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14307; Wed, 16 Jun 93 12:52:59 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14302; Wed, 16 Jun 93 12:52:56 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23699; Wed, 16 Jun 1993 13:15:06 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04398; Wed, 16 Jun 93 13:14:36 +0200
Date: Wed, 16 Jun 93 13:14:36 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306161114.AA04398@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
Subject: Re: Resource estimation
Cc: timbl@nxoc01.cern.ch, Nathan.Torkington@vuw.ac.nz, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Wed, 16 Jun 1993 03:44:23 -0500
> From: nop@theory.cs.mankato.msus.edu (Jay A. Carlson)

> 

> Also note that httpd appears to be somewhat memory-hungry.  On my
> DECstation 5000, running Ultrix, it used 8M to serve ONE PAGE.  In  
a
> system serving more pages I can see that this kind of caching would  
be
> useful, but in small systems you may wanna look at an alternative
> server.


Not sure what that 8M is.  It's not caching anything.
Be sure to strip the executables if you take the distributed ones --
I notice they are 300k to 600k whereas a stripped on is around
say 150k (that's compiled including the WAIS gateway code)
as they were compiled with debug flags on.

Anyone know what the 8M is?

Tim


From daemon  Wed Jun 16 13:07:17 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14484; Wed, 16 Jun 93 13:07:19 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14480; Wed, 16 Jun 93 13:07:17 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26365; Wed, 16 Jun 1993 13:29:24 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 16 Jun 93 12:21:31 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA19258; Wed, 16 Jun 93 12:27:40 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306161127.AA19258@manuel.hpl.hp.com>
Subject: Re: Quad (was Spaces)
To: terry@ora.com
Date: Wed, 16 Jun 93 12:27:38 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Terry,

You say

> I think the various points of view have been well represented on
> this issue, and fairly economically, too.  Let me make a practical
> proposal:  I think I would be satisfied with a single white space
> character (or entity), something like Tex's \quad, that is, an en
> in the current font.  Is this something we can all accept as needed
> even if some see it as impure SGML?

Did you mean "&em;" or <em> rather than "en"? I like your suggestion
it is simple and easy to implement.

Perhaps you could help me with a naming problem. In the HTML+ DTD I use
a single tag for all inline emphasis, using a string attribute value
to specify different categories of emphasis. My original name was EMPH
but feel this is perhaps too long. I then thought of contracting this
to EM, but see now that this might be confused with an em space.

Any ideas for what I should call this tag?

Best wishes,

Dave Raggett

From daemon  Wed Jun 16 13:53:50 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15214; Wed, 16 Jun 93 13:53:53 MET DST
Return-Path: <secret@hpwww.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15209; Wed, 16 Jun 93 13:53:50 MET DST
Received: from hpwww.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07442; Wed, 16 Jun 1993 14:16:01 +0200
Message-Id: <9306161216.AA07442@dxmint.cern.ch>
Received: by hpwww.cern.ch
	(1.37.109.4/16.2) id AA22928; Wed, 16 Jun 93 14:15:09 +0200
From: Arthur Secret <secret@hpwww.cern.ch>
Subject: WWW - ORACLE
To: www-talk@nxoc01.cern.ch
Date: Wed, 16 Jun 93 14:15:08 METDST
Mailer: Elm [revision: 70.85]

Hello,

Forwarded is a mail from Guy Decoux presenting his improvements
made on the WWW-Oracle Gateway.

To know what has been done so far on this subject (to my knowledge), you should
access http://info.cern.ch/hypertext/WWW/RDBGate/Overview.html

(Begin forwarded message)
>
>
> This is an adaptation of Arthur Secret's work.
>
> Characteristics
> ---------------
>
>   * only the condition of the WHERE clause is required
>     in the search text
>  
>
>  * links to other queries can be made.
>
>   * multiple styles (glossaries, lists, plaintext, ...)
>
>   * queries to multiple databases are possible.
>
>   * only the server knows the access details for the
>    database (database name, username, password).
>
>   * no modifications for the clients, only the server is upgraded.
>
>   * possible access control to restrict what systems can
>     query a specific table (adaptation of "tcp_wrapper"
>     - Wietse Venema (wietse@wzv.win.tue.nl)).
>
>   * "oracle/" must be specified in the pathname of the document.
>
> Syntax
> ------
>
>  With each document (suffix ".html") is associated a file with  
>suffix
>".sql". This file defines both the SQL statement to be used
>when a query is done on the file, and also the format of the output  
>to be returned. The file format is :
>
>   * head (optional) : normal text with possible keywords
>      - <unesc> condition of the WHERE clause (HTUnEscape)
>      - <esc> encoded condition (HTEscape).
>      
>
>      The macros <unesc> and <esc> are replaced by the
>      search text entered by the user in escaped (URL)
>      or unescaped (as typed) form.
>
>   * the SELECT clause is given between tags <SELECT ...> </SELECT>.  
>Syntax
>is <SELECT option = string, ...>. The following options can be used  
>(all
>optional) :
>
>     - type=tableau : for output like
>
>          col1  col2 ... coln
>          -------------------
>          aaa   aaa  ... aaa
>          bbb   bb   ... b
>                 ...
>          ccc   c    ... cc
>
>     - database : database name (default A)
>     - username : oracle username (default SCOTT)
>     - password : password (default TIGER)
>     - format   : default C format to apply to each returned value
>(default, "%s=%s")
>     - maxselect: maximum number of returned row (default 40).
>
> The names of options are not case sensitive.  The <select>
> block is expanded to the returned results.
>
>   * this can be repeated ("head", "<select> block", "head", "
>     <select> block", ...)
>
> In the SELECT clause, you can specify (in comment /* */) a C  
>"printf" format string (after
>the column name, or alias) to display the returned value. This format  
>can have 3 %s (like default format of tag <SELECT>).  These are used
>to output the following string values:
>
>     - 1st %s for column name (or alias, if specified)
>     - 2nd and 3rd %s for the returned value (see example below).
>
> The SELECT clause is also a C format whith a maximum of 8  
>occurrences of "%s", each used for the condition of the WHERE clause.
>
> Text can be put before (and after) each row.
>
> Example
> -------
>
> The following document "http://moulon.inra.fr/oracle/A/projet.html"
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>~~~~~~
>                                                                         
>Projets
>                            DESCRIPTION D'UN PROJET
>                                       
>
>   Interrogation de la relation projets[1] sur un quelconque de ces  
>champs,
>   afin de retrouver les caracteristiques associees telles que  
>description,
>   bibliographie, ou la carte.
>   
>
>   Attention : mefiez vous des "faux-amis".
>   
>
>   Certains champs peuvent preter a confusion lors de  
>l'interrogation, par
>   exemple le champ responsable figurant a la fois dans les relations  
>projets
>   et dispositif. Pour eviter de tels problemes, si vous vous doutez  
>d'une
>   confusion possible, prefixez le champ par le nom de la relation.
>   
>
>   Par exemple, "projets.responsable like 'ts%'"
>   
>
>   -------
>   
>
>   Retour au menu[2].
>     [End]
>
>
>FIND <keywords>, 1-2, Back, Up, Quit, or Help:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>~~~~~~~
>
> is associated with file "projet.sql" :
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>~~~~~~~
> <h1>Projets associes a <unesc></h1><ul>
> <select>
> /*<li>*/ select rowid
> /*%0.0s<a  
> href=http://moulon.inra.fr:80/oracle/A/projet.row?rowid='%s'>*/,
> projet "prj", type "type" , responsable "resp"/*%s=%s*/
> from projets
> where %s/*</a>
> */
> </select>
> </ul><p><h2>Caracteristiques associees</h2>
> <h3>
> <a  
> href=http://moulon.inra.fr:80/oracle/A/biblio.sql?<esc>>Bibliographie< 
> /a>
> </h3>
> <h3><a  
> href=http://moulon.inra.fr:80/oracle/A/carte.sql?<esc>>Carte</a></h3>
> <h3><a  
> href=http://moulon.inra.fr:80/oracle/A/dispositif.sql?<esc>>dispositif 
> </a>
> </h3>
> <h2><a href=http://moulon.inra.fr:80/oracle/A/projet.lis?<esc>>Liste  
> </a>
> des reponses</h2>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> ~~~~~~~
>
>  Query "FIND projet like 'P%'" gives :
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>~~~~~~~
>                                                               projet  
> like 'P%'
>                      PROJETS ASSOCIES A PROJET LIKE 'P%'
>                                       
>
>      prj=P1type=type P1resp=ts (decoux@moulon.inra.fr)[1]
>      
>
>      prj=P2type=type P2resp=decoux[2]
>      
>
>      prj=P3type=type P3resp=ts[3]
>      
>
> Caracteristiques associees
> 
>
>  BIBLIOGRAPHIE[4]
>  
>
>  CARTE[5]
>  
>
>  DISPOSITIF[6]
>  
>
> Liste [7] des reponses
> 
>
>   
>
>     [End]
> 
>
> 
>
> FIND <keywords>, 1-7, Back, Up, Quit, or Help: 
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> ~~~~~~~
>
>  i.e. :
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> ~~~~~~~
> <ISINDEX><TITLE>projet like 'P%'</TITLE>
> <h1>Projets associes a projet like 'P%'</h1><ul>
> <li><a  
> href=http://moulon.inra.fr:80/oracle/A/projet.row?rowid='000002BF.0000 
> .0003'>prj=P1type=type P1resp=ts (decoux@moulon.inra.fr)</a>
> <li><a  
> href=http://moulon.inra.fr:80/oracle/A/projet.row?rowid='000002BF.0001 
> .0003'>prj=P2type=type P2resp=decoux</a>
> <li><a  
> href=http://moulon.inra.fr:80/oracle/A/projet.row?rowid='000002BF.0003 
> .0003'>prj=P3type=type P3resp=ts</a>


> </ul><p><h2>Caracteristiques associees</h2>
> <h3>
> <a  
> href=http://moulon.inra.fr:80/oracle/A/biblio.sql?projet%20like%20%27P 
> %25%27>Bibliographie</a>
> </h3>
> <h3><a  
> href=http://moulon.inra.fr:80/oracle/A/carte.sql?projet%20like%20%27P% 
> 25%27>Carte</a></h3>
> <h3><a  
> href=http://moulon.inra.fr:80/oracle/A/dispositif.sql?projet%20like%20 
> %27P%25%27>dispositif</a>
> </h3>
> <h2><a  
> href=http://moulon.inra.fr:80/oracle/A/projet.lis?projet%20like%20%27P 
> %25%27>Liste </a>
> des reponses</h2>
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> ~~~~~~~
>
> Files are :
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> ~~~~~~~
>
>  * projet.row
>
> <h2>Description generale d'un projet</h2>
> <select format="%s = %s<p>
> ">
> select projet,type,t1d,t2d,morpho,physio,qtl,responsable,mere,pere,
> CARTE/*%s = <a  
> href=http://moulon.inra.fr:80/oracle/A/carte.row?carte='%s'>%s</a><p>* 
> /,remarques
> from projets
> where %s
> </select>
>
>  * biblio.sql
>
> <h2>Bibliographie pour <unesc></h2><ul>
> <select>
> /*<li>*/select unique biblio.rowid "-"
> /*%0.0s<a  
> href=http://moulon.inra.fr:80/oracle/A/biblio.row?rowid='%s'>*/,
> ref , auteurs from projet_biblio, biblio, projets
> where (num_ref = ref) and (num_prj=projet) and %s /*</a>
> */
> </select>
> </ul><p><h1><a  
> href=http://moulon.inra.fr:80/oracle/A/biblio.lis?<esc>>Liste
> </a> des reponses</h1>
>
>  * carte.sql :
>
> <h2>Cartes pour <unesc></h2><ul>
> <select>
> /*<li>*/select cartes.rowid "-"
> /*%0.0s<a  
> href=http://moulon.inra.fr:80/oracle/A/carte.row?rowid='%s'>*/,
> cartes.carte , population "pop"
> from cartes, projets
> where (projets.carte = cartes.carte) and %s/*</a>
> */
> </select>
> </ul><p><h1><a  
> href=http://moulon.inra.fr:80/oracle/A/carte.lis?<esc>>Liste
> </a> des reponses</h1>
>
>  * dispositif.sql 
>
>
> <h2>Dispositifs pour <unesc></h2><ul>
> <select format="%s=%s">
> /*<li>*/select unique dispositif.rowid "-"
>/*%0.0s<a  
> href=http://moulon.inra.fr:80/oracle/A/dispositif.row?dispositif.rowid 
> ='%s'>*/,
> experience "exp" , test
> from dispositif_projet, dispositif, projets
> where (num_exp = experience) and (num_prj = projet) and (%s)/*</a>
> */
> </select>
> </ul><p><h1><a  
> href=http://moulon.inra.fr:80/oracle/A/dispositif.lis?<esc>>Liste  
> </a>
> des reponses</h1>
> <p>Voir aussi les 
>
> <a  
> href=http://moulon.inra.fr:80/oracle/A/caract.html>caracteristiques</a 
>
> associees a chaque dispositif.>
>
>  * projet.lis :
>
> Reponse a la question <unesc><pre>
> <select format="%s = %s
> ">
> select * from projets where %s/*//
> */
> </select>
> </pre>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> ~~~~~~~
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Guy Decoux
> INRA
> Laboratoire de Genetique Vegetale
> Ferme du Moulon
> 91190 Gif sur Yvette
>
> Tel :    (33 1) 69 41 97 37
> Fax :    (33 1) 69 41 27 90
> e-mail : decoux@moulon.inra.fr
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> p.s.
>
>  Please note :
>
>   1) I program like i speak english (very BAD, excuse me)
>
>   2) A french and comprehensible version of this text is
>        http://moulon.inra.fr/oracle/www_oracle.html
>
>
--
Arthur Secret, e-mail: secret@dxcern.cern.ch

From daemon  Wed Jun 16 14:19:46 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15647; Wed, 16 Jun 93 14:19:48 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15643; Wed, 16 Jun 93 14:19:46 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15825; Wed, 16 Jun 1993 14:41:56 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04548; Wed, 16 Jun 93 14:41:28 +0200
Date: Wed, 16 Jun 93 14:41:28 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306161241.AA04548@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: www-talk@nxoc01.cern.ch
Subject: HTML spec
Reply-To: timbl@nxoc01.cern.ch



The version of the HTML spec on
ftp://info.cern.ch/pub/www/doc/html-spec.{txt,ps}
or
http://info.cern.ch/pub/www/doc/html-spec.multi

is in RFC style for Internet Darft release, which I will
do in the next few days.

Tim

From daemon  Wed Jun 16 14:27:18 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15757; Wed, 16 Jun 93 14:27:20 MET DST
Return-Path: <njw@cs.city.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15753; Wed, 16 Jun 93 14:27:18 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16399; Wed, 16 Jun 1993 14:49:24 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Wed, 16 Jun 1993 14:48:49 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Wed, 16 Jun 1993 14:46:57 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Wed, 16 Jun 1993 14:48:05 +0200
Date: Wed, 16 Jun 1993 14:48:05 +0200
X400-Originator: njw@cs.city.ac.uk
X400-Recipients: www-talk@nxoc01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<og7lO5C__5g8JYgnFd@cs.city.ac.u]
X400-Content-Type: P2-1984 (2)
Content-Identifier: WYSIWYG edito...
From: Nick Williams <njw@cs.city.ac.uk>
Message-Id: <og7lO5C__5g8JYgnFd@cs.city.ac.uk>
To: www-talk@nxoc01.cern.ch
Subject: WYSIWYG editor for HTML (p.s. and that spacing discussion)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Well, I've been working on a WYSIWYG beast for editing HTML, using the
Andrew Toolkit.  The editor is currently not far away from beta testing
as is.  However, I'd like to provide support for editing foreign
characters and the like, but I just don't know what's available.  Is
there an exhaustive list of "special" characters which HTML supports? 

When I've put this in, I'll provide it for beta test to interested
people who already have the Andrew Toolkit. 

Oh, and BTW, I would FAR prefer double newline to be a paragraph break,
rather than the (entirely artificial, it seems) <p> construct.  And BTW,
when reading files, my editor cleans up text by converting all
whitespace to normal spaces and collapsing them down to singletons,
except in a <pre>, in which case nothing is done to the text.  And
multiple <p>'s are also collapsed to singletons.  

Nick
Nick Williams                          E-mail: njw@cs.city.ac.uk (MIME and ATK)
Systems Architecture Research Centre,  Tel: +44 71 477 8551
London, EC1V 0HB                       Fax: +44 71 477 8587

From daemon  Wed Jun 16 15:28:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16933; Wed, 16 Jun 93 15:28:43 MET DST
Return-Path: <cshotton@oac.hsc.uth.tmc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16929; Wed, 16 Jun 93 15:28:40 MET DST
Received: from oac.hsc.uth.tmc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03857; Wed, 16 Jun 1993 15:50:50 +0200
Message-Id: <9306161350.AA03857@dxmint.cern.ch>
Received: from oac2.hsc.uth.tmc.edu by oac.hsc.uth.tmc.edu with SMTP
	(1.37.109.4/16.2) id AA10807; Wed, 16 Jun 93 08:46:19 -0500
Date: Wed, 16 Jun 1993 08:50:30 -0600
To: www-talk@nxoc01.cern.ch
From: cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton)
Subject: DELETE

DELETE www-talk


From daemon  Wed Jun 16 16:04:07 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17780; Wed, 16 Jun 93 16:04:12 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17774; Wed, 16 Jun 93 16:04:07 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13024; Wed, 16 Jun 1993 16:26:13 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA07482
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 16 Jun 93 09:26:10 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA21923; Wed, 16 Jun 93 09:28:55 -0500
Date: Wed, 16 Jun 93 09:28:55 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306161428.AA21923@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: mosaic-x@ncsa.uiuc.edu, hardin@ncsa.uiuc.edu
Subject: Adobe Acrobat released
X-Md4-Signature: 016f9d078960947bf8c5919f1eafd2c5

It will be interesting to see what happens with this -- anyone know if
there are available specs for PDF (the document format) yet?

Marc


From: clarinews@clarinet.com (UPI)
Newsgroups: clari.tw.computers,clari.biz.products,clari.local.sfbay
Subject: Adobe debuts software to simplify paperwork
Keywords: computers, manufacturing, corporate products & services,
	corporate finance
Date: Tue, 15 Jun 93 17:15:06 PDT
ACategory: financial
Slugword: adobe
Priority: regular
Format: regular
ANPA: Wc: 445/411; Id: z6201; Sel: xxbfc; Adate: 6-15-810ped
Codes: ybfcrxx., yfcprxx., //nf--f/, tsza....

	MOUNTAIN VIEW, Calif. (UPI) -- Adobe Systems Inc. rolled out Tuesday
its much-awaited Acrobat program, designed to simplify communications
between office computers.
	Adode, which debuted the program at a news conference in New York,
promised Acrobat will make it practical to distribute electronic
versions of reports, newspapers and books, complete with artwork,
photographs and typefaces.
	``Acrobat will fundamentally charge the economics of information by
removing the critical barriers that have kept electronic documents from
moving between computers,'' said John Warnock, chairman and chief
executive officer.
	``Today's paper-based information is hampered by the physical media,''
WArnock said. ``Acrobat technology liberates information and the flow of
ideas and allows it to enter the electronic age.''
	Analysts have called the product a break-through, saying it could
double Abode's annual revenues, which were $265 million last year.
	Shares jumped $3 a share on Monday in acticipation of the
announcement, then slid 50 cents to $72 in over-the-counter trading.
	Besides internal corporate uses, Acrobat may also be useful to
publishers seeking easier ways of distributing information. A newspaper
could be distributed through telephone lines into computers, with the
pages appearing the same as they do in print.
	Adobe said the Acrobat products preserve the essential look and feel
of even the most complex documents that contain photographs, various
typefaces and color.
	The product's release is an advance from competing products and
arrives in the market prior to rival programs that are expected to come
from such major players as Microsoft Corp., Apple Computer Inc. and
Xerox Corp.
	As a result, Acrobat may set an industry standard. Its previous
products, led by its flagship PostScript that tells a computer or
printer how to format characters, are well-regarded in the industry.
	The first versions of Acrobat will work on Apple's Macitosh system
and personal computers running Microsoft's Windows operating system.
Unix and DOS systems wil be available later this year.
	Abode unveiled three products -- Acrobat Reader, Acrobat Exchange and
Acrobat Distiller -- using its portable document format.
	Acrobat Reader, to be used for viewing documents, will be sold at $35
a copy at quantities of more the 500.
	Acrobat Exchange, to be used for networks, will be sold at $195 for a
single copy and $146 a copy at quantities of more than 100 copies.
	Acrobat Distiller, to be used for creating documents, was priced at
$695 for individual users and $2,495 for networks.


From daemon  Wed Jun 16 16:43:38 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18651; Wed, 16 Jun 93 16:43:41 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18643; Wed, 16 Jun 93 16:43:38 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26046; Wed, 16 Jun 1993 17:05:43 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA09775; Wed, 16 Jun 1993 11:05:33 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA13055; Wed, 16 Jun 1993 08:05:31 -0700
Message-Id: <199306161505.AA13055@ora.com>
From: Terry Allen <terry@ora.com>
Date: Wed, 16 Jun 1993 08:05:31 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: RE exotic characters

May I urge that WWW developers adopt the ISO character entity
sets used for SGML?  There are lots of these sets, providing
all the exotic characters you're likely to find.  Here's the
set of characters for "publishing" applications, as a sample.

<!-- (C) International Organization for Standardization 1986
     Permission to copy in any form is granted for use with
     conforming SGML systems and applications as defined in
     ISO 8879, provided this notice is included in all copies.
-->
<!-- Character entity set. Typical invocation:
     <!ENTITY % ISOpub PUBLIC
       "ISO 8879:1986//ENTITIES Publishing//EN">
     %ISOpub;
-->
<!ENTITY emsp   SDATA "[emsp  ]"--=em space-->
<!ENTITY ensp   SDATA "[ensp  ]"--=en space (1/2-em)-->
<!ENTITY emsp13 SDATA "[emsp3 ]"--=1/3-em space-->
<!ENTITY emsp14 SDATA "[emsp4 ]"--=1/4-em space-->
<!ENTITY numsp  SDATA "[numsp ]"--=digit space (width of a number)-->
<!ENTITY puncsp SDATA "[puncsp]"--=punctuation space (width of comma)-->
<!ENTITY thinsp SDATA "[thinsp]"--=thin space (1/6-em)-->
<!ENTITY hairsp SDATA "[hairsp]"--=hair space-->
<!ENTITY mdash  SDATA "[mdash ]"--=em dash-->
<!ENTITY ndash  SDATA "[ndash ]"--=en dash-->
<!ENTITY dash   SDATA "[dash  ]"--=hyphen (true graphic)-->
<!ENTITY blank  SDATA "[blank ]"--=significant blank symbol-->
<!ENTITY hellip SDATA "[hellip]"--=ellipsis (horizontal)-->
<!ENTITY nldr   SDATA "[nldr  ]"--=double baseline dot (en leader)-->
<!ENTITY frac13 SDATA "[frac13]"--=fraction one-third-->
<!ENTITY frac23 SDATA "[frac23]"--=fraction two-thirds-->
<!ENTITY frac15 SDATA "[frac15]"--=fraction one-fifth-->
<!ENTITY frac25 SDATA "[frac25]"--=fraction two-fifths-->
<!ENTITY frac35 SDATA "[frac35]"--=fraction three-fifths-->
<!ENTITY frac45 SDATA "[frac45]"--=fraction four-fifths-->
<!ENTITY frac16 SDATA "[frac16]"--=fraction one-sixth-->
<!ENTITY frac56 SDATA "[frac56]"--=fraction five-sixths-->
<!ENTITY incare SDATA "[incare]"--=in-care-of symbol-->
<!ENTITY block  SDATA "[block ]"--=full block-->
<!ENTITY uhblk  SDATA "[uhblk ]"--=upper half block-->
<!ENTITY lhblk  SDATA "[lhblk ]"--=lower half block-->
<!ENTITY blk14  SDATA "[blk14 ]"--=25% shaded block-->
<!ENTITY blk12  SDATA "[blk12 ]"--=50% shaded block-->
<!ENTITY blk34  SDATA "[blk34 ]"--=75% shaded block-->
<!ENTITY marker SDATA "[marker]"--=histogram marker-->
<!ENTITY cir    SDATA "[cir   ]"--/circ B: =circle, open-->
<!ENTITY squ    SDATA "[squ   ]"--=square, open-->
<!ENTITY rect   SDATA "[rect  ]"--=rectangle, open-->
<!ENTITY utri   SDATA "[utri  ]"--/triangle =up triangle, open-->
<!ENTITY dtri   SDATA "[dtri  ]"--/triangledown =down triangle, open-->
<!ENTITY star   SDATA "[star  ]"--=star, open-->
<!ENTITY bull   SDATA "[bull  ]"--/bullet B: =round bullet, filled-->
<!ENTITY squf   SDATA "[squf  ]"--/blacksquare =sq bullet, filled-->
<!ENTITY utrif  SDATA "[utrif ]"--/blacktriangle =up tri, filled-->
<!ENTITY dtrif  SDATA "[dtrif ]"--/blacktriangledown =dn tri, filled-->
<!ENTITY ltrif  SDATA "[ltrif ]"--/blacktriangleleft R: =l tri, filled-->
<!ENTITY rtrif  SDATA "[rtrif ]"--/blacktriangleright R: =r tri, filled-->
<!ENTITY clubs  SDATA "[clubs ]"--/clubsuit =club suit symbol-->
<!ENTITY diams  SDATA "[diams ]"--/diamondsuit =diamond suit symbol-->
<!ENTITY hearts SDATA "[hearts]"--/heartsuit =heart suit symbol-->
<!ENTITY spades SDATA "[spades]"--/spadesuit =spades suit symbol-->
<!ENTITY malt   SDATA "[malt  ]"--/maltese =maltese cross-->
<!ENTITY dagger SDATA "[dagger]"--/dagger B: =dagger-->
<!ENTITY Dagger SDATA "[Dagger]"--/ddagger B: =double dagger-->
<!ENTITY check  SDATA "[check ]"--/checkmark =tick, check mark-->
<!ENTITY cross  SDATA "[ballot]"--=ballot cross-->
<!ENTITY sharp  SDATA "[sharp ]"--/sharp =musical sharp-->
<!ENTITY flat   SDATA "[flat  ]"--/flat =musical flat-->
<!ENTITY male   SDATA "[male  ]"--=male symbol-->
<!ENTITY female SDATA "[female]"--=female symbol-->
<!ENTITY phone  SDATA "[phone ]"--=telephone symbol-->
<!ENTITY telrec SDATA "[telrec]"--=telephone recorder symbol-->
<!ENTITY copysr SDATA "[copysr]"--=sound recording copyright sign-->
<!ENTITY caret  SDATA "[caret ]"--=caret (insertion mark)-->
<!ENTITY lsquor SDATA "[lsquor]"--=rising single quote, left (low)-->
<!ENTITY ldquor SDATA "[ldquor]"--=rising dbl quote, left (low)-->

<!ENTITY fflig  SDATA "[fflig ]"--small ff ligature-->
<!ENTITY filig  SDATA "[filig ]"--small fi ligature-->
<!ENTITY fjlig  SDATA "[fjlig ]"--small fj ligature-->
<!ENTITY ffilig SDATA "[ffilig]"--small ffi ligature-->
<!ENTITY ffllig SDATA "[ffllig]"--small ffl ligature-->
<!ENTITY fllig  SDATA "[fllig ]"--small fl ligature-->

<!ENTITY mldr   SDATA "[mldr  ]"--em leader-->
<!ENTITY rdquor SDATA "[rdquor]"--rising dbl quote, right (high)-->
<!ENTITY rsquor SDATA "[rsquor]"--rising single quote, right (high)-->
<!ENTITY vellip SDATA "[vellip]"--vertical ellipsis-->

<!ENTITY hybull SDATA "[hybull]"--rectangle, filled (hyphen bullet)-->
<!ENTITY loz    SDATA "[loz   ]"--/lozenge - lozenge or total mark-->
<!ENTITY lozf   SDATA "[lozf  ]"--/blacklozenge - lozenge, filled-->
<!ENTITY ltri   SDATA "[ltri  ]"--/triangleleft B: l triangle, open-->
<!ENTITY rtri   SDATA "[rtri  ]"--/triangleright B: r triangle, open-->
<!ENTITY starf  SDATA "[starf ]"--/bigstar - star, filled-->

<!ENTITY natur  SDATA "[natur ]"--/natural - music natural-->
<!ENTITY rx     SDATA "[rx    ]"--pharmaceutical prescription (Rx)-->
<!ENTITY sext   SDATA "[sext  ]"--sextile (6-pointed star)-->

<!ENTITY target SDATA "[target]"--register mark or target-->
<!ENTITY dlcrop SDATA "[dlcrop]"--downward left crop mark -->
<!ENTITY drcrop SDATA "[drcrop]"--downward right crop mark -->
<!ENTITY ulcrop SDATA "[ulcrop]"--upward left crop mark -->
<!ENTITY urcrop SDATA "[urcrop]"--upward right crop mark -->


-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Wed Jun 16 16:53:30 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18895; Wed, 16 Jun 93 16:53:32 MET DST
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18891; Wed, 16 Jun 93 16:53:30 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28345; Wed, 16 Jun 1993 17:15:40 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA08302; Wed, 16 Jun 1993 10:15:36 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Resource estimation 
In-Reply-To: Your message of "Wed, 16 Jun 1993 10:04:22 +0200."
             <9306160804.AA03888@www3.cern.ch> 
Date: Wed, 16 Jun 1993 10:15:36 -0500
Message-Id: <8299.740243736@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Tim Berners-Lee
>>From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
>>For my proposal that's going to the committee here (I'm soon going  
>to
>>make all my CWIS documents available for public review via our WWW
>>server -- I wrote them in HTML so it shouldn't be too hard to serve
>>them :-) I need some estimates of the hardware to run a dedicated  
>WWW
>>server off.
>
>In fact, the load on an HTTP server machine is very slight,
>because the process only runs as long as it takes to return
>the document. The info.cern.ch server which has the Subject
>Catalogue gets probably a relatively high usage, about
>10k requests a day, or (thinks...) one every 9 seconds.
>the CPU load is negligible.  In fact of course the peak rate
>is higher, but still its not really a factor.

This goes along with our experience (though our load is only maybe 40%
of yours.)  Just passing text files along is pretty cheap.

Of course, if you're getting to pick the platform, part of it depends
how you'll have the server configured and what kinds of access it will
be doing.  If you are using standard multithreading with lots of
fork()ing then a system with copy-on-write would be nice.  If your
server does lots of execing instead, this won't help as much.  Lots of
physical memory is always nice (lazy man's performance philosophy is
to let the OS do the caching.)  Being able to plock() the server
process so it doesn't get swapped might be good, though if it's as
heavily used as you hope this won't be an issue much.

Will people be using this system to just fetch simple HTML files, or
as a gateway, or to do frequent queries of large databases?  I expect
that only in the last of these three is adequate CPU power likely to
enter into the picture.  If you anticipate doing cryptographic
manipulations as part of transactions (e.g. kerberos authentication or
PEM or something like that) obviously that can eat some CPU.

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
"I cannot recommend this candidate too highly or say enough good things about
him.  In my opinion you will be lucky to get him to work for you.  I urge you
to waste no time making him an offer.  No one would be better for the job."

From daemon  Wed Jun 16 17:21:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19587; Wed, 16 Jun 93 17:21:58 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19583; Wed, 16 Jun 93 17:21:56 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06804; Wed, 16 Jun 1993 17:44:06 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA05114; Wed, 16 Jun 93 17:43:37 +0200
Date: Wed, 16 Jun 93 17:43:37 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306161543.AA05114@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Adobe Acrobat released
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


> Date: Wed, 16 Jun 93 09:28:55 -0500
> From: marca@ncsa.uiuc.edu (Marc Andreessen)
> 

> It will be interesting to see what happens with this -- anyone know  
if
> there are available specs for PDF (the document format) yet?
> 

> Marc


I know they explicitly kept the specs secret until their product line
was solid.  Once they release them they will propose it as a  
standard!  A sure way to get it accepted by the net....

 

From daemon  Wed Jun 16 17:33:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19885; Wed, 16 Jun 93 17:33:22 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19880; Wed, 16 Jun 93 17:33:19 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12056; Wed, 16 Jun 1993 17:55:23 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA09124; Wed, 16 Jun 93 10:55:14 -0500
Message-Id: <9306161555.AA09124@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Spaces and Tabs in HTML documents 
In-Reply-To: Tim Berners-Lee's message of Wed, 16 Jun 93 09:42:22 +0200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 16 Jun 1993 10:55:13 -0500
From: Tony Sanders <sanders@bsdi.com>

>From: Tony Sanders <sanders@bsdi.com>
> How about having two <PRE> style tags.  One works just like existing <PRE>
> and another tag that (probably) doesn't use the fixed-width font but does
> preserves spaces and tabs as much as possible and allows full HTML mark-up.
> It will be the task of the browser to make this look good. 
> 
> 	If you don't know the relative font sizes, you can't predict
> 	where you will be, and so what the next stop will be.
This can be solved in the browser (either by forcing a fixed width
or by computing the tabs by look ahead within the element).

> 	Now we have tables.  And when we have tables, we will need
Yes, tables might actually solve most of the problem.

I was just offering a different way to think about the problem, which is
that we don't have to choose whether whitespace is significant or not, if
we need it to be significant just add an element that does what we need.

I vote that by default whitespace not be significant, as several people
have already argued for better than I could.

--sanders

From daemon  Wed Jun 16 17:42:36 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20098; Wed, 16 Jun 93 17:42:38 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20092; Wed, 16 Jun 93 17:42:36 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12975; Wed, 16 Jun 1993 18:04:43 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA09176; Wed, 16 Jun 93 11:04:36 -0500
Message-Id: <9306161604.AA09176@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Resource estimation 
In-Reply-To: Jay A. Carlson's message of Wed, 16 Jun 93 03:44:23 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 16 Jun 1993 11:04:35 -0500
From: Tony Sanders <sanders@bsdi.com>

> Also note that httpd appears to be somewhat memory-hungry.  On my
> DECstation 5000, running Ultrix, it used 8M to serve ONE PAGE.  In a
> system serving more pages I can see that this kind of caching would be
> useful, but in small systems you may wanna look at an alternative
> server.

Plexus only uses 1.2M and that includes the image decoding stuff.  It also
doesn't exec very often so the overhead on the system is negligible, you
have to worry more about the network usage than system usage.  It doesn't
cache anything itself, it assumes your OS is smart enough to do that.

http://www.bsdi.com/server/doc/plexus.html

--sanders

From daemon  Wed Jun 16 17:53:34 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20361; Wed, 16 Jun 93 17:53:36 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20357; Wed, 16 Jun 93 17:53:34 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16228; Wed, 16 Jun 1993 18:15:44 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA15280
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 16 Jun 93 11:15:42 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA22335; Wed, 16 Jun 93 11:18:26 -0500
Date: Wed, 16 Jun 93 11:18:26 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306161618.AA22335@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: group annotation server
X-Md4-Signature: 0ae09c6fc1df8771b513722f9b233c8f

I'm running a public Mosaic group annotation server on
hoohoo.ncsa.uiuc.edu, port 8001.  If you're running Mosaic 1.1, feel
free to put the following line in your .Xdefaults:

XMosaic*annotationServer: hoohoo.ncsa.uiuc.edu:8001

Also feel free to post group annotations (text or audio); consider
this an experiment in community-wide asynchronous collaboration.
We've got ~50MB free for this; I certainly wouldn't mind filling it
up.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Wed Jun 16 17:54:28 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20384; Wed, 16 Jun 93 17:54:30 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20380; Wed, 16 Jun 93 17:54:28 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16288; Wed, 16 Jun 1993 18:16:38 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576707-2>; Wed, 16 Jun 1993 12:16:27 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA05675; Wed, 16 Jun 93 12:06:14 EDT
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306161606.AA05675@begbick.law.cornell.edu.law.cornell.edu>
Subject: Cello Beta 0.3 loose.
To: www-talk@nxoc01.cern.ch
Date: Wed, 16 Jun 1993 12:06:14 -0400
Cc: fatty!teknoids@dxmint.cern.ch, fatty!cello-l@dxmint.cern.ch
X-Mailer: ELM [version 2.2 PL15]

Folks:

Beta version 0.3 of Cello is hereby released on an unsuspecting world.
You can pick it up from fatty.law.cornell.edu in /pub/LII/Cello, or by
clicking on the 'pick up viewers' link on the default home page in the
distribution.

The new version fixes the following problems:


1) Crashes when searching using particularly long WAIS search strings.

2) Memory leakage of various minor kinds, probably visible as gradually
slowing performance when accessing HTML files with large numbers of
links.


It adds the following features:

1) 'enter search terms' dialog box now appears automagically when you
access a searchable document, eg. a WAIS title page.

2) DOS filenames may now be relative.  It seems to have escaped
general notice that Cello may be used as an HTML viewer regardless of
whether there is a usable Net connection or not...  

IMPORTANT NOTE:
In order to implement relative names, it was necessary to make a
slight change in the way DOS file names are handled.  The correct way
to designate a file named (for instance) f:\foo\bar\bletch.htm is

HREF="file://localhost/f:/foo/bar/bletch.htm"

Note that the colon following the f (the drive designator) was not
previously required.

PLEASE ASSIST BY REPORTING GPFs:

There have been very few reports of GPFs and other Windows crashes.  I
am not fool enough to believe that Cello is blameless in this respect
or even capable of being used for more than 300 ms. without crashing.
Please report these; they're virtually impossible to path-test for.
If possible report what you were doing when the GPF occurred, what
resource you were accessing, and the funny hex number that shows up in
the GPF dialog box.  Indefinite hangs are also of interest.


Happy motoring,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Wed Jun 16 19:14:43 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21840; Wed, 16 Jun 93 19:14:46 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21835; Wed, 16 Jun 93 19:14:43 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07729; Wed, 16 Jun 1993 19:36:54 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA23694; Wed, 16 Jun 1993 12:29:23 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306161729.AA23694@stat1.cc.ukans.edu>
Subject: Re: Resource estimation
To: www-talk@nxoc01.cern.ch
Date: Wed, 16 Jun 93 12:29:23 CDT
X-Mailer: ELM [version 2.3 PL2]

> For my proposal that's going to the committee here (I'm soon going to
> make all my CWIS documents available for public review via our WWW
> server -- I wrote them in HTML so it shouldn't be too hard to serve
> them :-) I need some estimates of the hardware to run a dedicated WWW
> server off.
> 
> We will have about 10,000 users (hopefully :-) and I hope for
> relatively high usage.  Can anyone suggest a suitable platform?
> 
> Nat.

Our KUfacts machine supports 600-1000 Lynx logins per day with reasonable
speed.  It is also used as a productional machine for academic research
work.  The hardware behind the machine is a rs/6000 350 with only 32 mbytes
of RAM, so it isn't what you would call a 'heavy' machine.  Lynx usage
is in general very unintensive with most processes using maybe 2% of the
processor with peaks in the teens during file transfers.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Wed Jun 16 19:47:50 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22553; Wed, 16 Jun 93 19:47:52 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22549; Wed, 16 Jun 93 19:47:50 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15474; Wed, 16 Jun 1993 20:09:51 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA22442; Wed, 16 Jun 1993 14:09:44 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA15864; Wed, 16 Jun 1993 11:09:42 -0700
Message-Id: <199306161809.AA15864@ora.com>
From: Terry Allen <terry@ora.com>
Date: Wed, 16 Jun 1993 11:09:42 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: RE two PREs

Presently in xmosaic PRE is presented in a typewriter font; this is okay
for code examples (unless you have in-line annotations that you want 
distinguished from the code) but not for all forms of text that should
be displayed verbatim (poetry).  So either two PREs are needed, or the
font change in PRE should be invoked specifically, perhaps by using
CODE inside PRE.

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Wed Jun 16 20:13:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23043; Wed, 16 Jun 93 20:13:46 MET DST
Return-Path: <mleventh@us.oracle.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23035; Wed, 16 Jun 93 20:13:39 MET DST
Received: from gatekeeper.oracle.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21758; Wed, 16 Jun 1993 20:35:37 +0200
Received:  from hqsun4.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
	id AA14150; Wed, 16 Jun 93 11:35:33 PDT
Received:  by hqsun4.us.oracle.com (5.59.10/37.3)
	id AA13608; Wed, 16 Jun 93 11:35:30 PDT
Message-Id: <9306161835.AA13608@hqsun4.us.oracle.com>
Date: Wed, 16 Jun 93 11:35:30 PDT
From: Michael Leventhal <mleventh@us.oracle.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML spec


WWW is only at the periphery of my attention, so I
apologize if my comment is not "on point" and is not
very elaborated.

I believe the growing pains of HTML can only be
resolved by evolving to the SGML architectural
form concept, as exemplified by HyTime.  That is
not to say that WWW architectural forms should
*be* HyTime, but *a* set of architectural forms
will provide a baseline for WWW browsers.  It
will be impossible to arrive at a monolithic 
answer for all problems from whitespace to
tables.  Different WWW applications will arise
although this should never preclude the most
minimal application.  In fact, one of the chief
benefits will be the ability to preserve a
minimal application which is the key to 
rapid and wide diffusion of the concept.

Regards,

Michael Leventhal
Multimedia Development
Oracle Corporation

From daemon  Wed Jun 16 20:28:24 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23359; Wed, 16 Jun 93 20:28:26 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23355; Wed, 16 Jun 93 20:28:24 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24047; Wed, 16 Jun 1993 20:50:33 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24850
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 16 Jun 93 13:50:31 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA22567; Wed, 16 Jun 93 13:53:08 -0500
Date: Wed, 16 Jun 93 13:53:08 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306161853.AA22567@wintermute.ncsa.uiuc.edu>
To: Michael Leventhal <mleventh@us.oracle.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML spec
In-Reply-To: <9306161835.AA13608@hqsun4.us.oracle.com>
References: <9306161835.AA13608@hqsun4.us.oracle.com>
X-Md4-Signature: 199c02491481ab1d5f1c6284065b55af

Michael Leventhal writes:
> I believe the growing pains of HTML can only be resolved by evolving
> to the SGML architectural form concept [...]

Judging from my experiences in talking to real people in the real
world, the fastest way to kill WWW will be to go more strongly down
the SGML path.

(I realize the above isn't an incredibly valuable contribution to the
ongoing discussions; I haven't had time to type up my feelings in any
detail yet, but at this point I think that dealing with SGML in
general is a complete waste of time and that we'd currently be a lot
further along if we weren't burdened by the SGML baggage we've
inherited and are still carrying.  99.99% of the people I talk to want
to put rich documents online, want control over what it looks like,
and don't give a damn about semantic markup or distinctions between
document structure and appearance AT ALL; the other 0.01% are still
grappling with this whole keyboard-monitor-mouse concept.)

Marc


From daemon  Wed Jun 16 20:43:24 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23666; Wed, 16 Jun 93 20:43:26 MET DST
Return-Path: <mleventh@us.oracle.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23662; Wed, 16 Jun 93 20:43:24 MET DST
Received: from gatekeeper.oracle.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26877; Wed, 16 Jun 1993 21:05:32 +0200
Received:  from hqsun4.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
	id AA17181; Wed, 16 Jun 93 12:05:29 PDT
Received:  by hqsun4.us.oracle.com (5.59.10/37.3)
	id AA14623; Wed, 16 Jun 93 12:05:27 PDT
Message-Id: <9306161905.AA14623@hqsun4.us.oracle.com>
Date: Wed, 16 Jun 93 12:05:27 PDT
From: Michael Leventhal <mleventh@us.oracle.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML spec

I wouldn't care to dispute your point of view.  But since
you went down that road, I think what I suggest is the
correct approach to the problems I've seen discussed here.
Chucking it all is, of course, another kind of solution.

Best regards,

Michael Leventhal

> From daemon@nxoc01.cern.ch Wed Jun 16 11:56:02 1993
> Date: Wed, 16 Jun 93 13:53:08 -0500
> From: marca@ncsa.uiuc.edu (Marc Andreessen)
> To: Michael Leventhal <mleventh@us>
> Cc: www-talk@nxoc01.cern.ch
> Subject: Re: HTML spec
> X-Md4-Signature: 199c02491481ab1d5f1c6284065b55af
> Content-Length: 972
> 
> Michael Leventhal writes:
> > I believe the growing pains of HTML can only be resolved by evolving
> > to the SGML architectural form concept [...]
> 
> Judging from my experiences in talking to real people in the real
> world, the fastest way to kill WWW will be to go more strongly down
> the SGML path.
> 
> (I realize the above isn't an incredibly valuable contribution to the
> ongoing discussions; I haven't had time to type up my feelings in any
> detail yet, but at this point I think that dealing with SGML in
> general is a complete waste of time and that we'd currently be a lot
> further along if we weren't burdened by the SGML baggage we've
> inherited and are still carrying.  99.99% of the people I talk to want
> to put rich documents online, want control over what it looks like,
> and don't give a damn about semantic markup or distinctions between
> document structure and appearance AT ALL; the other 0.01% are still
> grappling with this whole keyboard-monitor-mouse concept.)
> 
> Marc
> 
> 


From daemon  Wed Jun 16 20:47:22 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23727; Wed, 16 Jun 93 20:47:26 MET DST
Return-Path: <hoesel@chem.rug.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23721; Wed, 16 Jun 93 20:47:22 MET DST
Received: from rugch4.chem.rug.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28238; Wed, 16 Jun 1993 21:08:40 +0200
Received: from rugnm6.chem.rug.nl by rugch4.chem.rug.nl with SMTP
	(16.8/16.2) id AA17159; Wed, 16 Jun 93 21:06:12 +0200
Received: from Xtreme.chem.rug.nl by rugnm6.chem.rug.nl via SMTP (920330.SGI/920922.WK)
	for @rugch4.chem.rug.nl:marca@ncsa.uiuc.edu id AA02954; Wed, 16 Jun 93 21:14:05 GMT
Received: by Xtreme (920330.SGI/920502.SGI)
	for @rugch4.chem.rug.nl:www-talk@nxoc01.cern.ch id AA01720; Wed, 16 Jun 93 21:10:28 +0200
From: hoesel@chem.rug.nl (frans van hoesel)
Message-Id: <9306161910.AA01720@Xtreme>
Subject: Re: HTML spec
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Wed, 16 Jun 1993 21:10:28 +0100 (MDT)
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306161853.AA22567@wintermute.ncsa.uiuc.edu> from "Marc Andreessen" at Jun 16, 93 01:53:08 pm
X-Mailer: ELM [version 2.4 PL5]
Content-Type: text
Content-Length: 1574      

Marc writes:
> 
> 99.99% of the people I talk to want to put rich documents online,
> want control over what it looks like,
> and don't give a damn about semantic markup or distinctions between
> document structure and appearance AT ALL; the other 0.01% are still
> grappling with this whole keyboard-monitor-mouse concept.)

You are very right about that !. HTML as it is now is simple to learn.
In fact I learned by simply starting (and finished with the vatican
exhibit). There were some things that I would like to control, and are
not (yet?) possible, and some never will be, but I liked it already
as it is.
Ofcourse it took some time to find out the nice tricks. for example
to have the editor replace all CRCR pairs with a CR<p>CR but at the
point I did the last page, it went all very easy.

- frans

O, the points that were missing at that time, which I would have liked
text running around the picture, pre formatted text in a nice font,
and a mouse position depended selection inside an image
(yes I know we have now ISMAP, and I don't like it at all, because it
 depends so much on the server: I cannot simply setup a document that
 works this way, without storing this document on a very special server...
 I want to make a document, that should contain the relevant info, not
 the server!)

but the net result is still pretty good.
Now if there only were a program that color quantifies a page of images to
use not more than say 150 colors, but each image itself not more than 50...

I guess the wish list never ends, and that's what we are all avraid off.





From daemon  Wed Jun 16 21:02:33 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23991; Wed, 16 Jun 93 21:02:35 MET DST
Return-Path: <RASHTY@hujivms.bitnet>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23986; Wed, 16 Jun 93 21:02:33 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01102; Wed, 16 Jun 1993 21:24:44 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 4460; Wed, 16 Jun 93 21:24:58 SET
Received: from HUJIVMS (NJE origin RASHTY@HUJIVMS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 4283; Wed, 16 Jun 1993 21:24:58 +0200
Received: by HUJIVMS (HUyMail-V6l); Wed, 16 Jun 93 22:24:36 +0300
Date:     Wed,  16 Jun 93 22:24 +0300
Message-Id: <16060093222410@HUJIVMS>
From: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@cearn.bitnet>
To: www-talk@nxoc01.cern.ch
Subject:  GNU-info files under WWW

>To: rashty@vms
>Subject: server for info format files
>Reply-To: edna@shum.cc.huji.ac.il

    Has anybody written a server for displaying GNU-info files under WWW?
    Or anything to convert GNU-info to html.

Thanks.

From daemon  Wed Jun 16 21:33:33 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24783; Wed, 16 Jun 93 21:34:17 MET DST
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24763; Wed, 16 Jun 93 21:33:33 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08641; Wed, 16 Jun 1993 21:53:53 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0o63YH-000Eb9C; Wed, 16 Jun 93 15:53 EDT
Message-Id: <m0o63YH-000Eb9C@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: mosaic as a better wais client; mark up the "catalog"
Date: Wed, 16 Jun 1993 15:53:44 -0400
From: Edward Vielmetti <emv@garnet.msen.com>

If you get no hits on a WAIS database, the server will return a
catalog that looks something like this:

Catalog for database: ./comp-emacs
Date: Jun 16 02:15:13 1993
62 total documents

Document # 1
Headline: steff@ims. Re: Re: I thought TeX was supposed to be free!
DocID: 0 1189 /usr2/news/comp/emacs/8592

Document # 2
Headline: rms@gnu.ai Re: Emacs 19.10 available
DocID: 0 3062 /usr2/news/comp/emacs/8593

(...)

As an exercise, mark up the catalog into HTML and return it, attractively
formatted, as a document.  (Or if its' too big send it back in a few
different chunks).

--Ed

From daemon  Wed Jun 16 22:25:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25837; Wed, 16 Jun 93 22:25:22 MET DST
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25833; Wed, 16 Jun 93 22:25:19 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19440; Wed, 16 Jun 1993 22:47:30 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA20567 (5.65b/3.8/CWI-Amsterdam); Wed, 16 Jun 1993 22:47:26 +0200
Received: by voorn.cwi.nl with SMTP
	id AA18048 (5.65b/3.8/CWI-Amsterdam); Wed, 16 Jun 1993 22:47:24 +0200
Message-Id: <9306162047.AA18048=guido@voorn.cwi.nl>
To: Dudu Rashty +972-2-584848 <RASHTY%HUJIVMS.BITNET@relay.nluug.nl>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: GNU-info files under WWW 
In-Reply-To: Your message of "Wed, 16 Jun 1993 22:24:00 MDT."
             <16060093222410@HUJIVMS> 
From: Guido.van.Rossum@cwi.nl
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Wed, 16 Jun 1993 22:47:24 +0200
Sender: Guido.van.Rossum@cwi.nl

>     Has anybody written a server for displaying GNU-info files under WWW?
>     Or anything to convert GNU-info to html.

I'm not sure if this fits your bill (since texinfo is one step removed
from plain info), but it won't hurt advertising this piece of code again:

I have written a texinfo to html converter in Python.  Python is an
object-oriented interpreted language (also written by me).  The html
converter is part of the Python source distribution (in demo/www); you
can ftp this distribution from ftp.cwi.nl, directory pub/python, file
python0.9.8.tar.Z.  It runs on most UNIX platforms.

If you have a Sparc or SGI platform, I can make a binary of just the
texinfo-to-html program available for you; this would save you the
trouble of building Python just to run the script, but means you can't
modify the program (the html it generates may need some
customization).  Let me know if you're interested in this.

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From daemon  Wed Jun 16 23:09:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26814; Wed, 16 Jun 93 23:09:04 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26810; Wed, 16 Jun 93 23:09:02 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29667; Wed, 16 Jun 1993 23:31:10 +0200
Received: by kauri.vuw.ac.nz id AA03276
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 17 Jun 1993 09:31:06 +1200
Date: Thu, 17 Jun 1993 09:31:06 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306162131.AA03276@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Marc Andreessen's message <9306161618.AA22335@wintermute.ncsa.uiuc.edu>
Subject: group annotation server

Anyone remember the `Maps in a Mirror' book by Orson Scott Card where
he wrote a prequel short-story to the `Foundation' series by Isaac
Asimov?  The nifty part of the story was the cross-referencing room in
the Imperial Library, where the ultimate privilege for librarians was
to work in the room.

What happened in the room?  Books, articles, papers, and similar
things were displayed on the librarians computers, and they got to
annotate them.  Phrases that set off associations in their minds were
linked, and the end result was a new set of possible directions for
the documents to be explored in.

I hope the Annotation server can be like this (despite the need for a
wide pipe into the backbone :).  It seems like a good start, at any
rate.

Has anyone considered setting up WAN annotation servers, and those
servers exchanging annotations a-la NNTP?

Nat

From daemon  Thu Jun 17 02:01:13 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29296; Thu, 17 Jun 93 02:01:17 MET DST
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29292; Thu, 17 Jun 93 02:01:13 MET DST
Received: from butternut.cs.scarolina.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08613; Thu, 17 Jun 1993 02:23:24 +0200
Return-Path: <fs@usceast.cs.scarolina.edu>
Received: by usceast.cs.scarolina.edu (cs.grandpoobah.102592)
From: Faisal Siddiqi <fs@usceast.cs.scarolina.edu>
Message-Id: <9306170023.AA00920@usceast.cs.scarolina.edu>
Subject: Please unsubscribe
To: www-talk@nxoc01.cern.ch
Date: Wed, 16 Jun 93 20:23:15 EDT
X-Mailer: ELM [version 2.3 PL11]

Please remove my name from this mailing list 

	fs@cs.scarolina.edu

Thanks 

From daemon  Thu Jun 17 20:46:05 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15192; Thu, 17 Jun 93 20:46:44 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15180; Thu, 17 Jun 93 20:46:05 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20606; Thu, 17 Jun 1993 21:07:23 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA15168; Thu, 17 Jun 1993 15:06:37 -0400
Date: Thu, 17 Jun 1993 15:03:56 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Re: group annotation server
To: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <199306162131.AA03276@kauri.vuw.ac.nz>
Message-Id: <Pine.3.03.9306171553.R14137-a100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 17 Jun 1993, Nathan Torkington wrote:

> What happened in the room?  Books, articles, papers, and similar
> things were displayed on the librarians computers, and they got to
> annotate them.  Phrases that set off associations in their minds were
> linked, and the end result was a new set of possible directions for
> the documents to be explored in.

Ahhhh.... Dreams of XANADU.  (Where's my laudanum?)

This is the original vision of Vannavar Bush, Doug Englebart, and the enfant
terrible of 'hypertext', Terrifying Ted Nelson.  <grin>

Read Literary Machines, or Computer Lib/Dream Machines by Nelson.

They might well change your life.  I *know* they changed mine.  </rr>



From daemon  Thu Jun 17 22:40:35 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17398; Thu, 17 Jun 93 22:40:37 MET DST
Return-Path: <emv@garnet.msen.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17394; Thu, 17 Jun 93 22:40:35 MET DST
Received: from garnet.msen.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03213; Thu, 17 Jun 1993 23:02:43 +0200
Received: by garnet.msen.com (Smail3.1.28.1 #11)
	id m0o6R6U-000EacC; Thu, 17 Jun 93 17:02 EDT
Message-Id: <m0o6R6U-000EacC@garnet.msen.com>
To: www-talk@nxoc01.cern.ch
Subject: Workshop on hypermedia authoring systems
Date: Thu, 17 Jun 1993 17:02:38 -0400
From: Edward Vielmetti <emv@garnet.msen.com>

Any WWW-interested folks within hailing distance of Southampton 
should consider taking a look at Microcosm, esp. to note how it
might interact in interesting ways with web-based technologies.

--Ed

------- Forwarded Message

From: The Association for learning technology <alt@vax.oxford.ac.uk>
Subject: ALT Workshop on Hypermedia Systems - Register now!

Association for Learning Technology Workshop
============================================

Building Resource-Based Learning Environments
- --------------------------------------------- 
Using Hypermedia Systems
- ------------------------


Presenters: Wendy Hall, Gerard Hutchings & Hugh Davis 

Date: Tuesday July 13th 1993 

Duration: 10.00 - 16.30

Venue: University of Southampton


Objective:

The main objective of this workshop is to show how the new generation of
open hypermedia systems, such as Microcosm, can be used to build
richly-resourced, multimedia learning environments. Participants will be
introduced to authoring in Microcosm and shown how this environment is
being used to create a campus-wide structure for multimedia learning.
Examples of material developed as part of the project will be used as
illustrations. Participants will also be shown how existing applications
can be integrated into such an environment and linked to the multimedia
material in the resource-base.

Programme:

10:00-10:30     Registration & Coffee

10:30-12:30     Introduction 
			Review of existing systems, the need for open
			systems, overview of Microcosm

12:30-13:30     Lunch

13:30-15:00     Authoring in Microcosm
		Examples of the use of Microcosm to include:
        		Human Morphology
        		Engineering
        		Biology
        		History

15:00-15:30     Tea

15:30-16:30     Microcosm as the basis for a resource-based learning strategy
		Open learning systems for the future

16:30   	Depart

Coffee, lunch, tea provided.                                                

Registration fee: #50.00 for ALT members; #100.00 for non-members.

About the organisers:

Wendy Hall is a Senior Lecturer in Computer Science at the University of
Southampton. She is co-Director of the Image and Media research group at
Southampton and also co-Director of the University's Teaching and
Technology Learning (TLTP) Project. Her research interests include the
development of hypermedia interfaces for multimedia information systems.
She is a co-founder of the Microcosm project at Southampton. 

Hugh Davis is a Lecturer in Computer Science at the University of
Southampton and was a founder member of the Microcosm project. He has been
project manager for the past two years and in this capacity has worked
closely with a number of projects that are using Microcosm as a basis for
multimedia information system development. His research interests include
the design and application of open hypermedia systems. 

Gerard Hutchings is a Researcher in Computer Science at the University of
Southampton and is currently working on the TLTP Biodiversity Consortium
Project on the development of multimedia information systems for use in the
teaching of Biology. He has many years research experience in the
development and evaluation of hypermedia systems. 


============================================================================
REGISTRATION FORM

ALT WORKSHOP No 1

Building Resource-Based Learning Environments Using Hypermedia Systems

NAME:________________________________________

ADDRESS:_____________________________________
_____________________________________________
_____________________________________________

TEL:_________________________________________
FAX:_________________________________________
EMAIL:_______________________________________

ARE YOU A MEMBER OF ALT? YES/NO

(TO JOIN ALT, SEE ADDRESS BELOW)

HOW DID YOU HEAR ABOUT THIS WORKSHOP?
_____________________________________________

IF REPLYING BY EMAIL, PUT AN X HERE FOR AN INVOICE: [ ]

IF REPLYING BY POST, PLEASE SEND WITH YOUR CHEQUE MADE PAYABLE TO "UNIVERSITY
OF SOUTHAMPTON".

PLEASE RETURN THIS FORM BY * 6 JULY 1993 * TO:

        Dr Wendy Hall
        Department of Electronics and Computer Science
        University of Southampton
        Southampton  SO9 5NH
        U.K.

        Tel: +44 (0)703 592388
        Fax: +44 (0)703 592865
        e-mail: wh@ecs.soton.ac.uk

To join the Association for Learning Technology, contact:
 
	Rhonda Riachi,
	ALT Programmes Manager, 
	Oxford University Computing Services, 
	13 Banbury Road,
	Oxford, OX2 6NN. 

	Tel: +44 (0)865 273281
	Fax: +44 (0)865 273275
	e-mail: alt@vax.ox.ac.uk


==============================================================================


------- End of Forwarded Message


From daemon  Fri Jun 18 06:32:04 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22196; Fri, 18 Jun 93 06:32:06 MET DST
Return-Path: <mkgray@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22192; Fri, 18 Jun 93 06:32:04 MET DST
Received: from ATHENA.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21618; Fri, 18 Jun 1993 06:54:18 +0200
Received: from OLIVER.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA05435; Fri, 18 Jun 93 00:54:15 EDT
From: mkgray@athena.mit.edu
Received: by oliver.MIT.EDU (AIX 3.2/UCB 5.64/4.7) id AA19427; Fri, 18 Jun 1993 00:52:54 -0400
Message-Id: <9306180452.AA19427@oliver.MIT.EDU>
To: www-talk@nxoc01.cern.ch
Subject: New Server
Date: Fri, 18 Jun 93 00:52:49 EDT

The Student Information Processing Board (SIPB)
of the Massachusetts Institute of Technology 
introduces a new HTTP server at www.mit.edu:8001 
with gateways to 

AFS, the Discuss bulliten board system, the Geographic Nameserver, 
US National Weather information, Amateur Radio Callsign database and 
a wide variety of hypertexted documents. To access this server open URL
http://www.mit.edu:8001/

or, if you are reading this in a WWW client,
<a href="http://www.mit.edu:8001/">follow this link</a>.

We would very much like feedback/comments/bug-reports, so please send
them to webmaster@athena.mit.edu.

					Matthew Gray
					mkgray@athena.mit.edu
					Chairman, SIPB

From daemon  Fri Jun 18 08:23:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22920; Fri, 18 Jun 93 08:23:14 MET DST
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22914; Fri, 18 Jun 93 08:23:12 MET DST
Date: Fri, 18 Jun 93 08:23:12 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9306180623.AA22914@ nxoc01.cern.ch >
To: terry@ora.com, www-talk@nxoc01.cern.ch
Subject: Re: RE two PREs

PRE was deigned to address a very specific problem:
putting in information which had been PREformatted
in all kinds of ways (tables, diagrams included) using
plain ASCII text, in the assumption of fixed-width
characters.

PRE MUST always be displayed using fixed width characters:
indeed, even when <B>old has been turned on, if a bold
font can't be found with the same pitch, then bold should
not be shown. [Recent usergripe that his formatting was
all off becuase he used bold ina PRE].

Poetry is somethingdifferent altogether.  It is less
obvious that you ned to have significant newlines, especially
as lines in powetry can wrap.  I would suggest for HTML+
an element for poetry and elements for verses, with
lines being paragraphs within the verse, for example.
But mark it up.

Tim

From daemon  Fri Jun 18 08:41:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23240; Fri, 18 Jun 93 08:41:04 MET DST
Return-Path: <timbl>
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23234; Fri, 18 Jun 93 08:41:02 MET DST
Date: Fri, 18 Jun 93 08:41:02 MET DST
From: timbl (Tim Berners-Lee)
Message-Id: <9306180641.AA23234@ nxoc01.cern.ch >
To: emv@garnet.msen.com, www-talk@nxoc01.cern.ch
Subject: Re: mosaic as a better wais client; mark up the "catalog"
Cc: h


This is a case for an HTTP server which sits on top of the WAIS
database and gives an enhanced hypertext view of it.  I think
Jim Fulton was wondering about this.  A simple example is that,
instead of returning a search result with an item
whose name is "Search failed, here is the catlogue", which
looks strange preceded by "The search produced one result:",
it could give a nice informative hypertext message, and
(ifg it is small) include the catalogue immediately.

Anothre example if that the server could have a home page
with links to any help about it, instead of having to
serach for "help" which sometimes gives lots of othre things
too.

Tim

From daemon  Fri Jun 18 09:27:14 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23680; Fri, 18 Jun 93 09:27:16 MET DST
Return-Path: <decoux@moulon.inra.fr>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23675; Fri, 18 Jun 93 09:27:14 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17800; Fri, 18 Jun 1993 09:49:28 +0200
Received: from chenas.inria.fr by mcsun.EU.net with SMTP
	id AA27701 (5.65b/CWI-2.225); Fri, 18 Jun 1993 09:49:14 +0200
Received: from inra.inra.fr by chenas.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA15949; Fri, 18 Jun 1993 09:49:08 +0200 (MET)
Received: from moulon.moulon.inra.fr (moulon-gw) by inra.inra.fr, Fri, 18 Jun 93 09:49:01 +0200
Received: by moulon.moulon.inra.fr, Fri, 18 Jun 93 09:47:07 +0200
Date: Fri, 18 Jun 93 09:47:07 +0200
From: decoux@moulon.inra.fr (ts)
Message-Id: <9306180747.AA15033@moulon.moulon.inra.fr>
To: www-talk@nxoc01.cern.ch
Subject: gateway WWW - Oracle



The Uniform Resource Locator for this document is:
http://moulon.inra.fr:80/oracle/why_oracle.html

Why "oracle/" in the URL ?
==========================

My first idea was : oracle://server/database/file, whith the following algorithm.  

Algorithm
+++++++++

 o client 
    o client know the scheme : it use the adequate protocol to get the
      document (like nntp for news:) 
    o else client know a gateway : it send the entire URL to this gateway 
    o otherwise : client use a default protocol (http) to send the entire
      URL to the server specified in the URL.  
       o server is NOT a WWW server : ERROR 
 o server 
    o server know this scheme 
       o local document : server send the document.  
       o else a new URL is linked with this URL : 
          o server send the new URL to the client.  
          o client retry with the new URL.  
    o otherwise : ERROR 

Example
+++++++

 o "server_A" has a database "data_A" 
 o client request "oracle://server_A/data_A/file" to "server_A", with default
   protocol http : server send the document.  
 o "data_A" is moved to "server_B", whith new name "data_B" 
 o old client request "oracle://server_A/data_A/file" to "server_A" 
    o "server_A" send the new URL "oracle://server_B/data_B/file" 
    o client request "oracle://server_B/data_B/file" to "server_B" 

Conclusion
++++++++++

Unfortunatly, for me, this is not the algorithm of WWW.

 o i can't use "oracle://server/database", because client reply : 

   WWW Alert:  Unable to access document.

 o i can't define "WWW_oracle_GATEWAY", because it's a server for
   local databases but not for ALL databases.  
 o my server is very minuscule, i don't want 2 minuscules servers on 2
   differents ports : one for "http", another for "oracle" 

Syntax is "http://server/...oracle/...",i.e.  a default protocol http (for the client)
whith the string "oracle/" (for the server) to recognize this new scheme.  

p.s.:
 l'URL de la version francaise est "http://moulon.inra.fr/oracle/pourquoi_oracle.html"



From daemon  Fri Jun 18 12:09:25 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25533; Fri, 18 Jun 93 12:09:28 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25528; Fri, 18 Jun 93 12:09:25 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11931; Fri, 18 Jun 1993 12:31:14 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA08107 (5.65b/CWI-2.225); Fri, 18 Jun 1993 12:31:11 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 18 Jun 93 11:23:11 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA29068; Fri, 18 Jun 93 11:29:22 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306181029.AA29068@manuel.hpl.hp.com>
Subject: re: HTML+ support for eqn & Postscript
To: torben@hawaii.edu
Date: Fri, 18 Jun 93 11:29:21 BST
Cc: janssen@parc.xerox.com, www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

>> [Dave's example of <EMBED> and eqn]

> Well, it may be the best that we're going to get. However, I still feel that
> equations are too basic to not be supported directly. Note that the more
> successful text processing systems (and that's part of what this will have to
> be) all support text, equations and tables nicely.

The ability to embed foreign formats seems a good thing as it allows us to
take advantage of evolving de facto standards for a whole range of things.

Just how critical is building in support for equations to the continuing
growth of the web? IMHO long term success is more important than intellectual
purity.

Some general issues:

    o   trade-off of complexity versus coverage

        ISO have an SGML DTD for maths - but this is "clearly" too complex.
        Perhaps there is a reasonable middle ground which would satisfy
        most peoples needs. Increasing the coverage from that point would
        enormously add to the complexity. So what is the right coverage?

    o   the impact of yet another standard for equations

        A simple approach for equations (which is easy to convert to/from
        existing standards) may be worthwhile if widely adopted ...

    o   the large numbers of math symbols in use

        A real problem this. Which ones are common place?

    o   just how much code is needed for parsing/rendering?

        Lets keep browsers simple!

    o   what to do with line mode displays

        Well you could just show the markup format ...

I will have a look at eqn and Latex to get a feeling for what would
be involved in extending HTML+ to directly support equations, and how
one could deal with it in browsers.

Dave Raggett

From daemon  Fri Jun 18 13:22:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26788; Fri, 18 Jun 93 13:23:01 MET DST
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26784; Fri, 18 Jun 93 13:22:59 MET DST
Received: from [138.250.1.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22966; Fri, 18 Jun 1993 13:45:08 +0200
Received: by xdm001 
	id AA26867; Fri, 18 Jun 93 12:44:59 +0100
Received: by xdm039 (5.57/4.7) id AA20840; Fri, 18 Jun 93 12:44:56 +0100
Message-Id: <9306181144.AA20840@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: HTML+ support for eqn & Postscript 
In-Reply-To: Your message of "Fri, 18 Jun 93 12:03:46 BST."
             <9306181103.AA26138@xdm001> 
Date: Fri, 18 Jun 93 12:44:54 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

Being a technical university, maths is highly desirable for us.

>    o   trade-off of complexity versus coverage
>    o   the impact of yet another standard for equations
>    o   the large numbers of math symbols in use
>    o   just how much code is needed for parsing/rendering?
>    o   what to do with line mode displays

My answer would be "whatever TeX can do, use that". The best way to do
that is to use TeX, either by displaying the output of an existing dvi
viewer, e.g. xdvi, or make WWW browsers into TeX viewers (maybe limited
to just mathematical TeX). What to do with char displays? Do what TeX
does (I don't *know* what it does, I don't want to know, I just know
that its users seem happy with it).

We use (amongst other things) DECWrite, which deals with equations by
embedding limited, math only, TeX code (actually stored in a separate
file), and translating it to DECwrite's internal format for final
display. It works well. DEC saw no reason to invent a new format, and
given that TeX already exists, I  see no point in reinventing it,
either. Face it, the hard bit has been done - the browser author
doesn't have to know what the Tex code *does*, simply hand the input to
it and render the output. Yes, I know it's not trivial for browser
authors, but my guess is that reinventing maths symbol processing for
HTML would be worse. Do the TeX stuff in a separate process, if you
like. Ghostscript takes this approach of separating viewer and processor, I believe.

The same arguments apply to eqn, for sites which use that. We don't,
but the code exists as groff. Fine; lets use that. If WWW land goes for
eqn, I'm sure it's not too difficult to translate existing TeX math to
eqn math. And once we can embed eqn or Tex math, why not arbitrary
troff/groff or TeX? This has the distinct advantage of handling native
man pages and TeXinfo straight off. 

Finally - a limited set of math symbols just wouldn't work. Authors
will stop using it as soon as they realised that bits of it failed to
come out. An HTML+ math format would need to be as complete as TeX/eqn
from day one, which is a tall order; otherwise its like only supporting
the 20 most frequently used letters of the alphabet on the basis that
they cover 98% of English text. True, but still not acceptable.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From daemon  Fri Jun 18 13:45:52 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27127; Fri, 18 Jun 93 13:45:54 MET DST
Return-Path: <nikos@cbl.leeds.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27123; Fri, 18 Jun 93 13:45:52 MET DST
Received: from chx400.switch.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27235; Fri, 18 Jun 1993 14:08:07 +0200
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Fri, 18 Jun 1993 14:07:49 +0200
X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed;
               Fri, 18 Jun 1993 14:06:30 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Fri, 18 Jun 1993 14:06:04 +0200
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Fri, 18 Jun 1993 14:06:04 +0200
Date: Fri, 18 Jun 1993 14:06:04 +0200
X400-Originator: nikos@cbl.leeds.ac.uk
X400-Recipients: www-talk@NXOC01.cern.ch
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<26583.9306181206@cbl.leeds.ac.u]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: HTML+ sup...
From: N F Drakos <nikos@cbl.leeds.ac.uk>
Message-Id: <26583.9306181206@cbl.leeds.ac.uk>
To: www-talk <www-talk@nxoc01.cern.ch>
Subject: Re: HTML+ support for eqn & Postscript

>We use (amongst other things) DECWrite, which deals with equations by
>embedding limited, math only, TeX code (actually stored in a separate
>file), and translating it to DECwrite's internal format for final
>display. It works well. DEC saw no reason to invent a new format, and
>given that TeX already exists, I  see no point in reinventing it,
>either. Face it, the hard bit has been done - the browser author
>doesn't have to know what the Tex code *does*, simply hand the input to
>it and render the output. Yes, I know it's not trivial for browser
>authors, but my guess is that reinventing maths symbol processing for
>HTML would be worse. Do the TeX stuff in a separate process, if you
>like. Ghostscript takes this approach of separating viewer and processor, I
> believe.
> 

I agree. We are taking this approach in a tex2html translator we are
currently building.
The idea is to translate into HTML as much as possible and include
the rest (pictures, equations, tables, etc.) as inlined images.
Then, an HTML viewer need only handle inlined images and allow text to
flow around them. 

Nikos Drakos,
Computer Based Learning Unit, University of Leeds.

  

From daemon  Fri Jun 18 13:58:03 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27313; Fri, 18 Jun 93 13:58:07 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27308; Fri, 18 Jun 93 13:58:03 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28328; Fri, 18 Jun 1993 14:20:15 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA17014 (5.65b/CWI-2.225); Fri, 18 Jun 1993 14:20:08 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 18 Jun 93 13:11:53 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA29318; Fri, 18 Jun 93 13:18:04 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306181218.AA29318@manuel.hpl.hp.com>
Subject: Re: HTML+ and Tables
To: grobe@ukanaix.cc.ukans.edu
Date: Fri, 18 Jun 93 13:18:01 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

This is in response to Michael Grobe's message of Tue, 15 Jun 1993
( Message-Id: <9306152358.AA37602@ukanaix.cc.ukans.edu> )

Dear Michael,

Comments on LINK and mailTo:
---------------------------
> first, i mentioned that we are planning to use something like:

>      <link rev=made href="mailto:...whatever..." >

> to allow info providers to provide a path for readers (through their
> clients) to contact them with comments.  note that this is a (static) "link"
> rather than an (executable link, or) anchor, whereas your MSG tag is an
> "executable" link.  lynx will support a command that will search out 
> the static info and open a mail screen for the user with the address already
> in place.

What do you mean by static link? Do you mean a browser menu option that lets
users mail comments back to authors? Sounds like a good idea. How do you
specify values for the subject and other header fields? I guess you could
use the TITLE attribute for the subject, but that seems pushing the notation
too far from its original concept.

{\begin aside}

While I think about it, the attribute "REV" and Tim's suggested values aren't
particularly transparent. Perhaps HTML+ should use "REL" for relationship
rather than "REV" (why "REV"?). Also "author" might be better than "made".
What is the METHODS attribute intended for? Does anyone use it?

What are your views on the attributes for LINK?

{\end aside}

My latest version of the HTML+ DTD includes a FORM tag in place of MSG.

        <!ELEMENT FORM - - (MH*, (%main;|INPUT|SELECT)*)>
        <!ATTLIST FORM
            id      ID        #IMPLIED
            action  %URL;     #IMPLIED>

        <!ELEMENT MH - - CDATA -- RFC 822 header fields -->

The idea is that you could have multiple forms in each document. The FORM
tag acts as a wrapper for each form and defines the action to be take when
the user presses the "commit" key.

By specifying a mailTo URL the form would be mailed to the designated
person. The MH tag allows you to specify the mail headers is a more
general way that would be possible with attributes to the FORM tag itself.

        <FORM action="mailTo:grobe@ukanaix.cc.ukans.edu">
            <MH> Subject: comments on proposal
            <INPUT id="f1">Your Comments</INPUT>
        </FORM>

The presence of "mailTo:" in an LINK or A element would imply the need to
pop-up an editor for the message with the appropriate header fields already
filled in. The FORM element on the other hand creates the message itself.

If the action starts "http:...", the form would be sent as a query for
this URL. The encoding of the forms contents would depend on the METHODS
attribute and default to an id:value listing following a "?" suffix.

I still need to do some more work on the actual details of the encoding format,
e.g. escaping white space and dealing with multiple values. In practice, it
seems much nicer to define a new HTTP method for forms data, than to try and
force it into the URL syntax.

Comments on Tables
------------------

I am getting uncomfortable about the detailed column specification format,
e.g. it defines how wide the fields are without taking into account the width
of the headers.

A better approach would be to let the browser work this out for itself.
This fits in well with your suggestion for adding a placement attribute to
specify center, left, or right justification. In the following I have
used a separate tag for tables rather than overloading DL:

    <!ELEMENT TBL - - (TT?, TH*, TD*)>
    <!ATTLIST TBL
        id      ID        #IMPLIED
        cols    CDATA     #REQUIRED -- number of columns --
        compact (compact) #IMPLIED  -- if present use compact style --
        border  (border)  #IMPLIED  -- if present draw borders -->

    <!ELEMENT TT - O (%text;)+ -- table title -->

    <!ELEMENT TH - O (%text;)+ -- column heading -->
    <!ATTLIST TH
        S   NUMBER  1           -- columns spanned --
        L   (L)     #IMPLIED    -- left aligned --
        C   (C)     #IMPLIED    -- center aligned --
        R   (R)     #IMPLIED    -- right aligned --
        D   (D)     #IMPLIED    -- decimal aligned -->

    <!ELEMENT TD - O (P|UL|OL|%text;)+ -- field data -->
    <!ATTLIST TD
        S   NUMBER  1           -- columns spanned --
        L   (L)     #IMPLIED    -- left aligned --
        C   (C)     #IMPLIED    -- center aligned --
        R   (R)     #IMPLIED    -- right aligned --
        D   (D)     #IMPLIED    -- decimal aligned -->

The above approach allows you to state <TD L> which is perhaps nicer
than <TD A=Left>. The drawback is I don't know how in SGML to define several
attributes as being mutually exclusive. *** What do you think? ***


                  An Example of a Table
    ___________________________________________________
    |          |          average          | other    |
    |          |   height    |     weight  | category |
    |_________________________________________________|
    | males    |    1.9      |      .003   | yyy      |
    |_________________________________________________|
    | females  |    1.7      |      .002   |      xxx |
    ___________________________________________________

    <tbl cols="4" border>
        <tt> An Example of a Table
        <th> <th s="2"> average <th l> other
        <th> <th> height <th> weight <th l> category
        <td> males <td> 1.9 <td> .003 <td l> yyy
        <td> females <td> 1.7 <td> .002 <td r> xxx
    </tbl>

The browser works through the table to determine the types and widths of
each field and how much room to allocate for each column. Using a fixed font
for tables would speed things up a bit. By default headers are centred while
text fields are left aligned. Numbers are vertically aligned on the units,
making them harder to deal with.

How does that sound?

Dave Raggett

From daemon  Fri Jun 18 15:44:32 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29898; Fri, 18 Jun 93 15:44:35 MET DST
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29893; Fri, 18 Jun 93 15:44:32 MET DST
Received: from [138.250.1.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21259; Fri, 18 Jun 1993 16:06:45 +0200
Received: by xdm001 
	id AA29032; Fri, 18 Jun 93 15:06:41 +0100
Received: by xdm039 (5.57/4.7) id AA21659; Fri, 18 Jun 93 15:06:36 +0100
Message-Id: <9306181406.AA21659@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: How can one use '#' in a URL? 
Reply-To: p.lister@cranfield.ac.uk
Date: Fri, 18 Jun 93 15:06:33 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

I've thought for some time that a nice feature in WWW servers would be
the ability to look inside a remote tar (or tar.Z) file (or an ar
library or whatever), i.e. remotely list the contents or just extract
one file. I've been thinking how I could build this into a server like plexus.

So that a normal URL which names a tar file will simply retrieve the
file (as most users want, I assume)  there needs to be some way of
referring to the subunit of the file. The obvious way is to use #, e.g.

http://www/foo/bar.tar.Z#blech.c

 - this would indicate to the server that it is to unpack blech.c from
/foo/bar.tar.Z and send it back as a normal file. However, I have only
seen the # documented as something which browsers can use for internal
hyperlinks, not as part of the a URL that can be sent to a http server.
Is this a problem?

The question mark would seem better suited to search the list of contents, e.g.

http://www/foo/bar.tar.Z?*.c

would return

blech.c	erk.c	glug.c

A related question is whether I can have slashes in the test following
the # or ?. e.g. for a tar file with relative filenames

http://www/foo/bar.tar.Z#./blech.c

would be common. Since slashes are meaningful to an http: URL, and the
browser can interpret them, would this cause confusion?

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

From daemon  Fri Jun 18 16:08:07 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00729; Fri, 18 Jun 93 16:08:11 MET DST
Return-Path: <wmperry@mango.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00722; Fri, 18 Jun 93 16:08:07 MET DST
Received: from mango.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24713; Fri, 18 Jun 1993 16:30:20 +0200
Message-Id: <9306181430.AA24713@dxmint.cern.ch>
Received: from localhost by mango.ucs.indiana.edu
	(5.65c/9.4jsm) id AA22824; Fri, 18 Jun 1993 09:28:56 -0500
To: p.lister@cranfield.ac.uk
Cc: www-talk@nxoc01.cern.ch
Subject: Re: How can one use '#' in a URL? 
In-Reply-To: Your message of "Fri, 18 Jun 1993 15:06:33 -0000."
             <9306181406.AA21659@xdm039> 
Date: Fri, 18 Jun 1993 09:28:43 -0500
From: "William M. Perry" <wmperry@mango.ucs.indiana.edu>

>I've thought for some time that a nice feature in WWW servers would be
>the ability to look inside a remote tar (or tar.Z) file (or an ar
>library or whatever), i.e. remotely list the contents or just extract
>one file. I've been thinking how I could build this into a server like plexus.
>
>So that a normal URL which names a tar file will simply retrieve the
>file (as most users want, I assume)  there needs to be some way of
>referring to the subunit of the file. The obvious way is to use #, e.g.
>
>http://www/foo/bar.tar.Z#blech.c
>
> - this would indicate to the server that it is to unpack blech.c from
>/foo/bar.tar.Z and send it back as a normal file. However, I have only
>seen the # documented as something which browsers can use for internal
>hyperlinks, not as part of the a URL that can be sent to a http server.
>Is this a problem?

   I don't think this is correct.  Any url can make use of the # directive.
It just tells a browser to go to a specific part of a document instead of
to the beginning.  I don't know of any browsers that actually 'generate'
these internally.

>The question mark would seem better suited to search the list of contents,
>e.g. http://www/foo/bar.tar.Z?*.c
>would return
>
>blech.c	erk.c	glug.c
>
>A related question is whether I can have slashes in the test following
>the # or ?. e.g. for a tar file with relative filenames
>
>http://www/foo/bar.tar.Z#./blech.c
>
>would be common. Since slashes are meaningful to an http: URL, and the
>browser can interpret them, would this cause confusion?

   The only problem with using ./ in the path would be that the browser
is likely to interpret it as a relative pathname.  For example, 
http://www/foo/bar.tar.Z#./blech.c would more than likely be translated
into http://www/foo/bar.tar.Z#/foo/blech.c by a browser.

   It would be fairly easy to tell the replacing function not to replace
any . or .. after a # sign though.  (I haven't tried this with mosaic or
lynx yet, but I know that my emacs browser would replace the ./ with nothing
so the url above would be http://www/foo/bar.tar.Z#blech.c)

-Bill Perry

From daemon  Fri Jun 18 16:11:48 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00843; Fri, 18 Jun 93 16:11:50 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00839; Fri, 18 Jun 93 16:11:48 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25914; Fri, 18 Jun 1993 16:34:02 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576703-2>; Fri, 18 Jun 1993 10:33:46 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA06757; Fri, 18 Jun 93 10:23:26 EDT
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306181423.AA06757@begbick.law.cornell.edu.law.cornell.edu>
Subject: Cello beta 0.4 released
To: fatty!cello-l@dxmint.cern.ch, fatty!teknoids@dxmint.cern.ch,
        www-talk@nxoc01.cern.ch
Date: Fri, 18 Jun 1993 10:23:25 -0400
X-Mailer: ELM [version 2.2 PL15]

Folks:

Cello beta version 0.4 is now available on 
fatty.law.cornell.edu, directory pub/LII/Cello.

The new version fixes the following:

-- Assorted GPFs resulting primarily from Developer Silliness.
   (scattered reports)
   
-- Problems with quoting of SRC attribute in <IMG> tags.  Net 
   result was an inability to retrieve image files on some 
   servers.
   (reported by Alert Cellist Nick Williams)
   
-- Text, title, and status bar backgrounds are now set to match 
   Windows system color, rather than defaulting to white.
   (reported by Alert Cellist Nick Williams)
   
-- Complete Windows crash caused by jumps to "empty" or 
   unavailable Gopher links is now fixed.
   (reported by Alert Cellists Paul Birch and Lars Johansen)
   
-- Isolated WAIS crashes repaired
   (reported by Alert Cellist Paul Birch, who will now be able 
   to read the Bluegrass archives undisturbed)
   
-- Problems with whitespace in files mailed to someone.


There are numerous small UI enhancements, no one of which is 
worth writing up.  I have also made a few small changes to the 
default home page, where there was at least one incorrect URL.

Unsolved mysteries of science:

   The Machine from Hell at Cornell continues to suffer from 
   FTP hangs on files > 4K bytes.  It appears that the upcall 
   mechanism isn't working correctly.  Anyone suffering from this 
   problem please contact me directly.

Viewer news:

   A Windows MPEG viewer is available at
      file://bode.ee.ualberta.ca/pub/dos/win3/mpeg
   There are assorted files to get depending on your video 
   hardware.  It seems to run OK with Cello, but not 
   necessarily with my video hardware (grin).  Anybody who
   wants to do some experimentation and report to CELLO-L is 
   hereby warmly invited to do so.

Regards,
Tb.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Fri Jun 18 16:19:50 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01028; Fri, 18 Jun 93 16:19:52 MET DST
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01023; Fri, 18 Jun 93 16:19:50 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27951; Fri, 18 Jun 1993 16:41:59 +0200
Received: by xdm001 
	id AA29586; Fri, 18 Jun 93 15:41:53 +0100
Received: by xdm039 (5.57/4.7) id AA22068; Fri, 18 Jun 93 15:41:49 +0100
Message-Id: <9306181441.AA22068@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: How can one use '#' in a URL? 
In-Reply-To: Your message of "Fri, 18 Jun 93 15:31:05 BST."
             <9306181431.AA29345@xdm001> 
Date: Fri, 18 Jun 93 15:41:47 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

>    I don't think this is correct.  Any url can make use of the # directive.
> It just tells a browser to go to a specific part of a document instead of
> to the beginning.  I don't know of any browsers that actually 'generate'
> these internally.

Misunderstanding. I mean to say that I don't know how or whether
servers will react to # in a URL; as far as I am aware, browsers simply
react to them when they see them in an HTML file. I should be more precise.

>    The only problem with using ./ in the path would be that the browser
> is likely to interpret it as a relative pathname.  For example, 

Exactly -  to tar, ./foo is NOT equivalent to foo. Can anyone who is
knows URLS give the word on whether slashes should be interpreted after a ? or #.

Further, is a null search term significant or not? Is "foo?" equivalent
to "foo". I would personally hope NOT, as a null default search term
could be useful (e.g. to return a catalogue).

Peter

From daemon  Fri Jun 18 16:35:32 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01512; Fri, 18 Jun 93 16:35:39 MET DST
Return-Path: <eostrom@fiicmds04.tu-graz.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01505; Fri, 18 Jun 93 16:35:32 MET DST
Received: from fiicmds1.tu-graz.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00789; Fri, 18 Jun 1993 16:57:42 +0200
Received: by iicm.tu-graz.ac.at (5.57/Ultrix3.0-C)
	id AA10525; Fri, 18 Jun 93 16:58:51 +0200
From: eostrom@fiicmds04.tu-graz.ac.at (Erik Ostrom)
Message-Id: <9306181458.AA10525@iicm.tu-graz.ac.at>
Received: by fiicmnx01.tu-graz.ac.at (NX5.67c/NX3.0X)
	id AA01789; Fri, 18 Jun 93 16:58:36 +0200
Date: Fri, 18 Jun 93 16:58:36 +0200
To: wmperry@mango.ucs.indiana.edu
Cc: p.lister@cranfield.ac.uk, www-talk@nxoc01.cern.ch
In-Reply-To: <9306181430.AA24713@dxmint.cern.ch> (wmperry@mango.ucs.indiana.edu)
Subject: Re: How can one use '#' in a URL?

   >http://www/foo/bar.tar.Z#blech.c
   >
   > - this would indicate to the server that it is to unpack blech.c from
   >/foo/bar.tar.Z and send it back as a normal file. However, I have only
   >seen the # documented as something which browsers can use for internal
   >hyperlinks, not as part of the a URL that can be sent to a http server.
   >Is this a problem?

      I don't think this is correct.  Any url can make use of the # directive.
   It just tells a browser to go to a specific part of a document instead of
   to the beginning.  I don't know of any browsers that actually 'generate'
   these internally.

But I think Peter is correct that, given a URL with a # inside it, the browser
doesn't send back the part beginning with #.  That is, seeing the URL above, a
browser would ask www for a document /foo/bar.tar.Z and then look for the
anchor "blech.c" inside it--which is not what he wants.

      The only problem with using ./ in the path would be that the browser
   is likely to interpret it as a relative pathname.  For example,
   http://www/foo/bar.tar.Z#./blech.c would more than likely be translated
   into http://www/foo/bar.tar.Z#/foo/blech.c by a browser.

      It would be fairly easy to tell the replacing function not to replace
   any . or .. after a # sign though.  (I haven't tried this with mosaic or
   lynx yet, but I know that my emacs browser would replace the ./ with nothing
   so the url above would be http://www/foo/bar.tar.Z#blech.c)

As mentioned above, I don't think the browser should interpret the part after
# as part of a path, since the # character is supposed to be followed by an
anchorid and anchorids are not hierarchical.  Wanted to note, though, that
according to the URL spec "/." may be simplified but "./" is not.

Of course, according to the URL spec gopher addresses have a slash between
gtype and selector, too, and that doesn't seem to have affected implementation
any.

   -Bill Perry

-Erik

From daemon  Fri Jun 18 16:44:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01790; Fri, 18 Jun 93 16:44:16 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01784; Fri, 18 Jun 93 16:44:12 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02805; Fri, 18 Jun 1993 17:06:25 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA02012; Fri, 18 Jun 93 10:06:22 -0500
Message-Id: <9306181506.AA02012@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML+ support for eqn & Postscript 
In-Reply-To: Dave_Raggett's message of Fri, 18 Jun 93 11:29:21 BST.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 18 Jun 1993 10:06:21 -0500
From: Tony Sanders <sanders@bsdi.com>

> >> [Dave's example of <EMBED> and eqn]
> 
> > Well, it may be the best that we're going to get. However, I still feel that
> > equations are too basic to not be supported directly. Note that the more
> > successful text processing systems (and that's part of what this will have to
> > be) all support text, equations and tables nicely.
> 
> The ability to embed foreign formats seems a good thing as it allows us to
> take advantage of evolving de facto standards for a whole range of things.

I agree, I feel that the ability to support postscript, eqn, tex, and the
ISO math DTD all at one whack far outweighs building in equation support.

Furthermore, the server could convert from just about anything to postscript
if needed, so that would seem a good format to support for you graphics
based browser writers (ghostscript will even draw in your window for you
if you can figure out how to make it work).

--sanders

From daemon  Fri Jun 18 17:01:45 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02375; Fri, 18 Jun 93 17:01:47 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02371; Fri, 18 Jun 93 17:01:45 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05564; Fri, 18 Jun 1993 17:23:58 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA29478 (5.65b/CWI-2.225); Fri, 18 Jun 1993 17:23:50 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 18 Jun 93 16:15:44 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA29719; Fri, 18 Jun 93 16:21:55 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306181521.AA29719@manuel.hpl.hp.com>
Subject: Re: HTML+ Forms
To: TONYJ@scs.slac.stanford.edu
Date: Fri, 18 Jun 93 16:21:52 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Hi Tony,

Sorry for the delay in getting back to you, I am rather snowed under
these days.

> Hi Dave, do I take it from this comment that some examples exist of the 
> use of <INPUT> and other form stuff? If so can I access them somewhere? I 
> have a preliminary implementation of Forms for MidasWWW and would like 
> some examples to try them out on.

Can you tell more about your implementation of Forms for MidasWWW?

I enclose the current HTML+ definitions for forms at the end of this
message. The new FORM tag allows several forms to be included in
the same document. This tag also defines what to do when the user
presses the "commit" key (normally the Return key), e.g. to send the
form's contents as a query to a server or to send it to a designated
person as an email message. The new MH tag allows you to define
arbitrary email header fields at the start of each message.

We still need to pin down how form contents can be passed to
servers as queries etc. and I would be very grateful for some
help in this regard. Some ideas for doing this with URLs are given
later on.

Now for an example which supposes that a server has been set up to help
sales staff configure quotes for computer workstations. It is based on
an expert system I worked on a couple of years ago.

    <FORM action="http://ukrc.hp.com:8002/s720">
        <H1>HP 9000 Series 720 Workstation</H1>

        <UL>
            <LI> 50 MHz PA-RISC CPU
            <LI> Wide range of graphics options
            <LI> 16 to 128 Mb ECC RAM and 2 optional disks
        </UL>

        <INPUT id="f1" type="INT" width="2" value="1"> Quantity </INPUT>

        <SELECT id="f2" compact> Graphics
            <ITEM id="i1" selected> Mono GRX
            <ITEM id="i2"> Color CRX
            <ITEM id="i3"> 2D Color VRX
        </SELECT>

        <SELECT id="f3" compact> Internal hard disks
            <ITEM id="i4"> 1 x 420 Mb
            <ITEM id="i5" selected error> 2 x 420 Mb
        </SELECT>
    
        <INPUT id="f4" type="bool" value="true" error> 3.5 inch floppy drive

        <P>
        *** You are only allowed two internal drives! ***
    </FORM>

The form starts with a header and a list of features for the workstation.
A quantity field follows which allows users to type a two digit integer.
It is initialised to the value "1".

Next there is a selection menu. Users have to choose one of a range of
graphics options. The initial value is the first item as indicated by
the selected attribute. The compact attribute tells the browser to render
the menu in a compact style, e.g. as a button with a drop down menu. For
menus supporting multiple selections, you would need to show the current
selections as a (truncated) list next to the dropdown button. The normal
(uncompact) style would be a permanently visible list, perhaps with some
kind of button to the left of each item, but visually distinct from
bulleted lists defined with the UL tag.

Fields can be marked as being in error or greyed out (disabled). The latter
case means the field cannot be altered - perhaps because its value is
constrained by the values of other fields.

The next field is also a selection menu. In this case the selected item
is marked as being in error and needing to be changed. The browser could
indicate this by a red splash next to the menu item.

The last field is a boolean checkbox, currently checked. It too is marked
as being in error and needing to be changed. The static text message which
follows indicates the nature of the problem.

Menus and checkboxes can be altered by clicking the mouse. Other kinds of
input fields require the user to set the input focus to that field, e.g.
by clicking with the mouse or using the tab/shift tab keys. Input fields
needing keyboard input show a cursor (blinking?) when they have the input
focus.

Pressing the Return key sends the form's content to the server designated
by the URL in the FORM tag. The server evaluates the form's contents
and in this case replies by sending a document containing the form, but
marked up to indicate the user has made some inconsistent choices for
disk drives.

This assumes that the browser encodes the form's contents as a
list of field ids and values following a "?" suffix after the URL.
It may be better to define a HTTP method for form data with a clean
encoding.

A suggested URL encoding:

    ? FIELD [ + FIELD ]*        -- ie FIELDs seperated by "+" --

where FIELD is:
    id:value                    -- single valued fields --
    id:(value[+value]*)         -- multi valued fields --

Selections would use the item id in place of the actual
string value.

Special characters should be replaced by "%" followed by the
two hex digits encoding the ASCII value.

The special chars are (based on Tim's URL spec for xalphas:

        + - % ( ) ! ^ & * $         (and all white space chars)

Note that URLs would then be of arbitrary length!

Best wishes,

Dave Raggett

------------------------------------------------------------------------

<!-- Forms: these are composed from input fields and selection menus

    These elements define fields which users can type into or select
    with mouse clicks. The browser should manage the input focus
    e.g. with the tab/shift tab keys and mouse clicks.

    The enter/return key is then taken to mean the use has filled
    in the form and wants the apppropriate action taken:

        -   send as query/update to WWW server
        -   email/fax to designated person

    The action is specified as a URL, e.g. "mailto:dsr@hplb.hpl.hp.com

    You can specify additional mail headers with the MH tag:

    <MH>Subject: Please add me to tennis tournament</MH>
 -->

<!ELEMENT FORM - - (MH*, (%main;|INPUT|SELECT)*)>
<!ATTLIST FORM
    id      ID        #IMPLIED
    action  %URL;     #IMPLIED>

<!ELEMENT MH - - CDATA -- RFC 822 header fields -->

<!ELEMENT INPUT - - (%text;)>
<!ATTLIST INPUT
    id      ID      #IMPLIED
    type    CDATA   #IMPLIED    -- URL, INT, FLOAT, DATE, BOOL, TEXT --
    width   CDATA   #IMPLIED    -- precision e.g."32x4" for multiline text --
    value   CDATA   #IMPLIED    -- the current value (yes/no for boolean fields) --
    disabled (disabled) #IMPLIED    -- if grayed out --
    error   (error)    #IMPLIED    -- if in error -->

<!-- Menu selections one from many and many from many

  The compact attribute is a suggestion that the browser renders
  the list in compact style, e.g. as a dropdown menu.

  The multi attribute means the menu permits multiple selections -->

<!ELEMENT SELECT - - ((%text;)*, ITEM*)>
<!ATTLIST SELECT
    id      ID        #IMPLIED
    compact (compact) #IMPLIED
    multi   (multi)   #IMPLIED>

<!-- menu items with attributes for menu selections -->
<!ELEMENT ITEM - O (%text;)>
<!ATTLIST ITEM
    id          ID         #IMPLIED
    selected    (selected) #IMPLIED -- if selected in list --
    disabled    (disabled) #IMPLIED -- if grayed out --
    error       (error)    #IMPLIED -- if in error -->

From daemon  Fri Jun 18 18:03:26 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03622; Fri, 18 Jun 93 18:03:28 MET DST
Return-Path: <frankston!frankston.com!Andrew_Marc_Greene@world.std.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03618; Fri, 18 Jun 93 18:03:26 MET DST
Received: from world.std.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15597; Fri, 18 Jun 1993 18:25:40 +0200
Received: from frankston.UUCP by world.std.com (5.65c/Spike-2.0)
	id AA26580; Fri, 18 Jun 1993 12:25:39 -0400
Message-Id: <199306181625.AA26580@world.std.com>
Received:  from frankston.com by frankston.com (UUPC/extended 1.11q) with UUCP;
           Fri, 18 Jun 1993 12:22:19 EDT
From: Andrew_Marc_Greene@frankston.com
To: www-talk@frankston.com
Subject: Remove me please...
Date: Fri, 18 Jun 1993 12:22 -0400

Sorry to waste bandwidth, but mail to owner-www-talk bounced.  I seem to have 
been accidentally added to www-talk; please remove me as I am not interested 
in receiving this mail.  Thanks.

From daemon  Fri Jun 18 18:50:30 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04549; Fri, 18 Jun 93 18:50:35 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04544; Fri, 18 Jun 93 18:50:30 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23646; Fri, 18 Jun 1993 19:12:43 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA02364; Fri, 18 Jun 93 12:12:41 -0500
Message-Id: <9306181712.AA02364@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: setext -> HTML converter
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 18 Jun 1993 12:12:40 -0500
From: Tony Sanders <sanders@bsdi.com>

I'm working on adding a setext -> HTML converter to my HTTP server (I've
got it mostly working already, it's 42 lines of perl, will be about 75
when it's done).  The basic idea is to ease the mark-up required for simple
documents (like email) but it'll work for complex documents as well because
you can use other markup as needed.

Setext was created by Ian Feldman <ianf@random.se>, you can contact him for
his setext documents.  I'll try and make them available via HTTP after
I get my converter working better (they are in setext).

setext = structure-enchanced text

The Basics:

    Title		-> <TITLE>Title</TITLE>
    =====		-> <H1>Title</H1>
    subhead
    -------		-> <H2>subhead</H2>
    **bold**            -> <B>bold</B>
    ~italic~            -> <I>italic</I>
    _under_lined_       -> <I>under lined</I>
    hyper_text_         -> <A HREF="http:foo">hyper text</A>
    .. _hyper_text_ http:foo
    .. other dotdot lines are ignored

Note that you can put the ".. _hyper_text_ ..." lines anywhere (at the
end is a nice place).  This makes the text easier to read.

Setext also defines a blockquote and list style, I'll add support for
them before I release it.

<BLOCKQUOTE> for lines like:
> this is a block quote,
> look familiar?

and <UL>...</UL> for:
    * list item 1
    * list item 2

Currently I can convert documents like:

    Sample Setext Document
    ======================

    This is a sample setext_ document that shows off the various features
    of setext_ and how easy it is write hypertext documents.

    Wouldn't **you** like to be able to write documents using this _simple_
    form of document markup?

    What can you do with setext?
    ----------------------------

    Most of the things you want to do like:  headers, sub-headers, **bold**,
    _italic_, and hypertext links_.

    --sanders

    .. _links_  http:links
    .. _setext_ http:setext

to:

    <HEAD>
    <TITLE>Sample Setext Document</TITLE>
    </HEAD>
    <BODY>
    <H1>Sample Setext Document</H1>
    <P>
    This is a sample 
    <A HREF="http:setext">setext</A>
    document that shows off the various features
    of 
    <A HREF="http:setext">setext</A>
    and how easy it is write hypertext documents.
    <P>
    Wouldn't <B>you</B> like to be able to write documents using this <I>simple</I>
    form of document markup?
    <P>
    <H2>What can you do with setext?</H2>
    <P>
    Most of the things you want to do like:  headers, sub-headers, <B>bold</B>,
    <I>italic</I>, and hypertext 
    <A HREF="http:links">links</A>
    .
    <P>
    --sanders
    <P>
    </BODY>


Is anyone else interested in this?

--sanders

From daemon  Fri Jun 18 19:12:22 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04963; Fri, 18 Jun 93 19:12:24 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04959; Fri, 18 Jun 93 19:12:22 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27093; Fri, 18 Jun 1993 19:34:32 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA07748; Fri, 18 Jun 1993 13:33:40 -0400
Date: Fri, 18 Jun 1993 13:27:36 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Sender: Rob Raisch <raisch@ora.com>
Reply-To: Rob Raisch <raisch@ora.com>
Subject: Re: HTML+ and Tables
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: grobe@ukanaix.cc.ukans.edu, www-talk@nxoc01.cern.ch
In-Reply-To: <9306181218.AA29318@manuel.hpl.hp.com>
Message-Id: <Pine.3.03.9306181327.l14137-d100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

>> What are your views on the attributes for LINK?

This is a very old posting.  I thought it might have some pertinance to the
current thread.  I might not how the same views as strongly now as when I first
wrote this, but it does identify some interesting LINK strategies....

	</rr>

------------------
November 22, 1993
------------------
[ I first posted this some weeks ago on the 'www-interest' list, and 
  received only one reply, (complementing me on my reference to Rexx.)

  I really had hoped that this post would start an interesting discussion
  on the topics I address, specifically the ideas of 'attention links' 
  'user documents' and 'transparent documents'.

  Are these ideas so obvious that they merit no discussion whatsoever?

  Always interested in replies, /rr ]


First of all, hearty congrats to the WWW people.  It's a great tool, and
since it is based on SGML, it has the broadest scope of any solution I have
yet seen.

To others, see the current issue of Byte magazine regarding "Info-Glut" and
SGML.  Interesting.

----------------------

I have a few recommendations regarding new link types in WWW.  This is based
on thinking about hyper-applications for almost 15 years, (ever since I 
first had the pleasure of hearing Ted Nelson speak in 1977.)

First though, there are a few ideas which I feel should be mentioned to 'set
the stage' for my list.

	Transparent Documents  --

		a transparent document is one which a user creates locally,
		and that is a new representation of an existant document.
		Transparent documents are used to create new local links on
		a document which I do not have permission to modify.

		Transparent documents can then be made available to others,
		(published) just as a "regular" document is, thus facilitating
		the creation of new works from old.

	User Documents --

		a user document is where I keep my "bookmarks", links to
		local documents, links to messages from others, links to
		my "attention" links, (see below).  User documents are where
		we, as navigators of the docuverse, are defined as individuals.

		They are also where we can keep links to other user documents
		which have been permitted to view/modify my own local documents.

		Another function of the User document is to collect users into
		an abstract group. (Thus, based on my membership in user 
		document 'Research Group', I am permitted access to materials
		'owned' by that group. Of course, messages sent to an abstract
		group then become available to all members of that group.)

		(Please note that a User Document is nothing more or less than
		 a collection of links, (as all documents are).)

------------------

Now, on to my list of link types....

There are 4 'minimal' link types which, I believe, a useful h-app *must* 
support.

	1.	Replacement
			-- when activated, replaces the current document
			   with a new document, (this is what WWW offers
			   today).

	2.	Annotation
			-- when activated, overlays a new document on the
			   current document, partially obscuring the original.
			   (An annotation must be dismissed by the reader.)

	3.	Inclusion
			-- when the document is created, elements from other
			   documents are collection to be included in the
			   representation of the current document.  (Quotes)

	4.	Expansion
			-- when activated, new information is added to the 
			   current document, expanding the original scope.

			   (Think of outline processors, and the collapse
			    of detail.)  

			   This is also a reflection of Nelson's concept of 
			   'stretch text'.  

			   A stretch-text definition of "stretch text" might be:

			   "Stretch text is{}a sentence{}that when{}collapsed
			    states it's thesis{}and when expanded adds detail." 

			   "Stretch text is where a sentence is constructed in 
			    such a way that when it is collapsed it states it's 
			    thesis in simple terms, and when expanded adds 
			    detail to further express itself."

There are 3 further types which I believe are necessary to complete the
function paradigm.


	6.	Execution

			-- when activated, some arbitrary function is performed.
			   The point that was mentioned about the lack of an
			   ubiquitious scripting language is well made.  Lisp
			   is too arcane for most.  Shell languages are too
			   platform specific.  What is needed is a simple
			   to understand, freely available scripting platform.
			   Although I hesitate to mention it, REXX might be
			   a reasonable choice due to it's broad availability.

	5.	Attention   (a specialisation of the Execution type)

			-- when the current document is modified (a link is
			   added, or removed, or the document is merely read)
			   a message is sent to the 'owner' of the attention
			   link.  This message creates a new link in the 'user
			   document' of the individual who placed the attention.

			   In this way, I could place a link onto a document I 
			   had interest in, and when it was changed or accessed
			   in some manner, I would be informed.

	7.	Collection  (a non-local specialisation of the Execution type)

			-- when activated, a collection link leaves the current
			   document, and 'travels' the docuverse, in search of
			   other documents which satisfy it's internal criteria.
			   This is the concept of a 'knowbot'.

			   Collection links can be activated based on day and
			   time, much like the WAIS questions in the MAC 
			   WAIS interface, WAIS-Station.  They could also be
			   activated based on external events, such as the 
			   activation of an attention link.

			   Collection links would be written in the ubiquitious
			   scripting language, and would only be allowed to 
			   operate on documents which were EXPLICITLY permitted.


----------------------------


One of the missing pieces here is the ability of creating new h-texts, and 
adding new links to old h-texts.

Hypertext, and like systems, are of limited use if they do not support 
collaboration.  I feel that this is a VERY important point.

When might we expect extensions to WWW that support collaboration?


----------------------------

So.....

	Scenerio:

		I start my session with my h-app, and open my user document.

		I notice that 17 of my attention links have been activated 
		in the last day.

		I select the most interesting and activate the link which
		it created in my personal user document.

		I am now reading an article which I previously linked, and
		see that an annotation which I made some time ago has been
		added to, by a colleague.

		The comments are pertinant to my current work, so I create
		a new local 'transparent' document to mirror the original 
		work.

		On this new document, I make a few new annotations and decide
		to made this new work available to the research group of which
                I am leader.  I place a link to it in the user document which
                represents my working group.

                I also send a new document link to the colleague who made the
                original comments, so that he can see how I have interpreted
                his ideas, and included them into my own research.

                I move ever onwards...

---------------------

Ok, I hope that that fuels a little discussion, and I would *love* to hear
from others regarding these ideas.






From daemon  Fri Jun 18 19:19:16 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05069; Fri, 18 Jun 93 19:19:18 MET DST
Return-Path: <mleggott@sandnc.stfx.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05065; Fri, 18 Jun 93 19:19:16 MET DST
Received: from sandnc.StFX.CA by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28579; Fri, 18 Jun 1993 19:41:28 +0200
Received: from cwaves by sandnc.stfx.ca (NX5.67c/NX3.0M)
	id AA05340; Fri, 18 Jun 93 14:35:53 -0400
From: Mark Leggott <mleggott@sandnc.stfx.ca>
Message-Id: <9306181835.AA05340@sandnc.stfx.ca>
Received: by cwaves.stfx.ca (NX5.67c/NX3.0X)
	id AA02443; Fri, 18 Jun 93 14:35:54 -0400
Date: Fri, 18 Jun 93 14:35:54 -0400
Received: by NeXT.Mailer (1.87.1.RR)
Received: by NeXT Mailer (1.87.1.RR)
To: www-talk@nxoc01.cern.ch
Subject: NeXT client

Sorry if I am covering ground covered elsewhere (FAQ's), but I  
thought this might be an appropriate forum for my questions.

I am investigating the possibility of using WWW as the central app  
for our proposed electronic library system (Xel - Xavier electronic  
library).  Having come here recently (2 months ago) from a  
CD-ROM/Hypertext company, WWW appeals to me for a number of reasons.   
I have also worked with various _SGML_, or _SGML-like_ engines (OWL  
Guide, CDAuthor Hypertext, KRS, PLS, Hyperwriter, WorldView, IDEAS,  
Mark-It, etc) and would like to build on that.

The library has four NeXT machines, which will form the seed of the  
system, and they will be the platform where capabilities of the Web  
are first demonstrated (I hope).  I would like to prepare a demo of a  
home page providing access to regional resources (ie. telnet'ing to  
other library catalogues, ftp sites, etc) sometime in the next few  
weeks.  


I realize the latest version (0.16) of the NeXT Hypermedia  
Browser/Editor does not support telnet, gopher, etc., but I would  
like to use the NeXT for these early demos if possible.  Besides, I  
am new to NeXT, love it, and would like to use it for document  
creation/development. Once I get into the development environment in  
more detail I would be interested in helping in any way I can with  
the NeXT WWW app. 


- Does anybody have a NeXT browser that supports these functions, or  
is there a way to telnet from the current version in some way?  


- If not, I have recently loaded MouseX for X11R5 - does anybody have  
any experience with Viola or other X11 apps using this version?   
Should I obtain a different X app for NeXT that has been proven with  
some of these?  


- I have also recently loaded the Cello app, but would like to stay  
away from DOS/Windows if possible for now.

I appreciate any info you may be able to provide, and am looking  
forward to working with WWW and the Web development community.

Thanks

================================================================
Mark Leggott, NeXT Administrator / Database&Network Coordinator
Angus L. MacDonald Library, St. Francis Xavier University
Antigonish, Nova Scotia, E2G 1C0  Canada      

Voice 902-867-2242  FAX 902-867-2334 

================================================================

From daemon  Fri Jun 18 20:03:53 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05970; Fri, 18 Jun 93 20:04:02 MET DST
Return-Path: <torben%Hawaii.Edu@galaxy.net.hawaii.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05964; Fri, 18 Jun 93 20:03:53 MET DST
Received: from galaxy.net.Hawaii.Edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05068; Fri, 18 Jun 1993 20:26:07 +0200
Received: from foralie.net.hawaii.edu ([132.160.3.1]) by galaxy.net.Hawaii.Edu with SMTP id <119698>; Fri, 18 Jun 1993 08:23:46 -1000
Date: 	Fri, 18 Jun 1993 08:13:30 -1000
From: Torben Noerup Nielsen <torben@hawaii.edu>
Sender: Torben Noerup Nielsen <torben@hawaii.edu>
Subject: re: HTML+ support for eqn & Postscript
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: janssen@parc.xerox.com, www-talk@nxoc01.cern.ch
In-Reply-To: <9306181029.AA29068@manuel.hpl.hp.com>
Message-Id: <MailManager.740427210.151.torben@foralie.net.hawaii.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dave,

>The ability to embed foreign formats seems a good thing as it allows us to
>take advantage of evolving de facto standards for a whole range of things.

Mathematics should *not* be considered a foreign format. It should be fully
integrated and allow easy construction of hypertext with lots of references.
Typical mathematical/scientific exposition skips what more advanced readers
will consider insignificant steps. It should be possible to expand such steps
by just clicking on them.

>Just how critical is building in support for equations to the continuing
>growth of the web? IMHO long term success is more important than intellectual
>purity.

I don't see why support for equations goes against intellectual purity at all.
Equation support is quite clean; i.e., it's ideally suited for markup.
Consider also that if it were supported, it would be pretty easy to set up
filters that would allow the text to be parsed and ingested into symbolic
mathematics packages.

Without adequate support for equations and general mathematical notation, the
Web will not be able to reasonably support scientific papers and I think that
a lot of potential utility is lost. The Web will then degenerate from being a
potentially very useful tool to being an interesting toy. But that's just my
opinion.

>I will have a look at eqn and Latex to get a feeling for what would
>be involved in extending HTML+ to directly support equations, and how
>one could deal with it in browsers.

Eqn and TeX are essentially equivalent as far as mathematics is concerned.
Yeah, TeX is supposed to be more ``standard" in terms of spacing and so forth,
but structurally, they are equivalent. Eqn is old, but incredibly useful and
quite clean as well.

Thanks, Torben


From daemon  Fri Jun 18 21:00:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07241; Fri, 18 Jun 93 21:00:59 MET DST
Return-Path: <yandros@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07227; Fri, 18 Jun 93 21:00:19 MET DST
Received: from CHARON.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11435; Fri, 18 Jun 1993 21:20:43 +0200
Received:  by charon (5.57/2.3JIK)
	id <AA25233@charon>; Fri, 18 Jun 93 15:20:35 -0400
Date: Fri, 18 Jun 93 15:20:35 -0400
From: yandros@athena.mit.edu
Message-Id: <9306181920.AA25233@charon>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Andrew_Marc_Greene@frankston.com's message of Fri, 18 Jun 1993 12:22 -0400 <199306181625.AA26580@world.std.com>
Subject: Remove me please...
X-Orgs: MIT SIPB VWA


  Sorry to waste bandwidth, but mail to owner-www-talk bounced.  I
  seem to have been accidentally added to www-talk; please remove me
  as I am not interested in receiving this mail.  Thanks.

Sorry (again) to waste bandwidth (again), but this was the result of a
problem with the local mail configuration for MIT.. (so much for
`reliable centrally maintained services. :-/  I guess we all have our
bad days).  I've taken care of this.

Again, I'm sorry for the wasted message...
Chad


From daemon  Fri Jun 18 21:35:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07821; Fri, 18 Jun 93 21:36:48 MET DST
Return-Path: <wmperry@guava.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07802; Fri, 18 Jun 93 21:35:39 MET DST
Received: from guava.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15891; Fri, 18 Jun 1993 21:55:59 +0200
Received: from localhost by guava.ucs.indiana.edu
	(5.65c/9.4jsm) id AA11958; Fri, 18 Jun 1993 14:55:50 -0500
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Subject: New Version of WWW Browser For Emacs
Date: Fri, 18 Jun 1993 14:55:45 -0500
Message-Id: <11956.740433345@guava.ucs.indiana.edu>
From: "William M. Perry" <wmperry@guava.ucs.indiana.edu>

This is to announce the release of version .55beta of the emacs world
wide web browser.

This has some fairly large changes, but most of them won't be visible
to the users.

For those not familiar with w3-mode already, it is a hypertext browser
written entirely in emacs-lisp.  It runs under emacs 18, emacs 19,
Lucid Emacs, and Epoch equally well.  (Well, not equally, but close
enough)  It takes advantage of different features of each emacs.
(Font/mouse support in lucid/epoch/emacs19, graphics support in epoch,
etc)

The browser can be ftped from:
ftp://moose.cs.indiana.edu/pub/elisp/w3/w3.tar.z       For the main files
ftp://moose.cs.indiana.edu/pub/elisp/w3/extras.tar.z   For support files

The extras.tar.z file contains: ange-ftp, background, transparent,
gopher, forms, and nntp lisp packages.  (Other people wrote _MUCH_
better gopher/ftp interfaces than I could hope to, so I use those)

If you already have these files installed on your system, there is no
need for you to get the extras.tar.z file.

Once you have unpacked the w3.tar.z file in your lisp directory, you
should be able to just edit the Makefile to point to where you want
the lisp files installed, where your .emacs file is, and where emacs
is located on your system.  Then type 'make install' and it will add a
few autoload statements to your .emacs and change your load-path
slightly.  (You can just type 'make w3' to just compile the lisp code
if you want to make the changes to your .emacs yourself)

Documentation on the emacs browser can be obtained from:

http://cs.indiana.edu:80/elisp/w3/docs.html

Please send me some email if you pick up this package, just so I can
tell roughly how many people are using it.

Also send mail if you find any files that cause w3 to break (already
know of one that causes an infinite loop: try to avoid
http://sipb.mit.edu:8001/afs/sipb/user/mcmullan/ht/sls.html if at all
possible - the multiple nested lists cause the parser to freak right
now, and I haven't had time to track it down).

Happy Emacsing!

-Bill Perry

-- William M. Perry (wmperry@indiana.edu) --
'Who finds a thought that enables him to obtain a slightly deeper glimpse into
 the eternal secrets of nature has been given great grace.'
    - Albert Einstein


From daemon  Sat Jun 19 00:08:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10908; Sat, 19 Jun 93 00:08:58 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10903; Sat, 19 Jun 93 00:08:56 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03318; Sat, 19 Jun 1993 00:31:09 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA03641; Fri, 18 Jun 93 17:31:06 -0500
Message-Id: <9306182231.AA03641@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Plexus log file summaries
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 18 Jun 1993 17:31:05 -0500
From: Tony Sanders <sanders@bsdi.com>

Here is some log file summerizing scripts for Plexus log files (it should
be easy to modify this for other formats).  I will be including them in
the next release.

I have two scripts, usage.byhost and usage.byurl which generates output
like the following.  They read in the previous results and then merge the
current log info.  There is also a script that runs them and then empties
and restarts the log file.

>>>>>> usage.host
   694 137.39.95.2			(this is my host)
   434 xxx.xxx.xxx.xx
   ...

>>>>>> usage.url
  1621 /
  1366 /demo/icons.html
  1337 /decode_walk
  ...

Note that this usage.byurl "folds" some directories into a single line.
You can add folding at any time and the summary will reflect the change,
however you cannot unfold once you have folded.  It's pretty easy to figure
out how to add or remove items from the list (it's the first function in
the script.

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  summary usage.byhost usage.byurl
# Wrapped by sanders@austin.BSDI.COM on Fri Jun 18 17:24:28 1993
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'summary' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'summary'\"
else
echo shar: Extracting \"'summary'\" \(413 characters\)
sed "s/^X//" >'summary' <<'END_OF_FILE'
X#!/bin/sh
X
X#
X# summerize host usage
X#
Xbin/usage.byhost
X
X#
X# summerize the URL usage and empty the log.
X#
Xbin/usage.byurl
X
X#
X# append the log to log.summary
X#
Xecho ------- SUMMARY ------- >> log.summary
Xcat log >> log.summary
X
X#
X# restart the log file
X#
Xrm -f log; touch log; .s chown sanders.www log
Xpid=`ps auxww | perl -ne '/^www.*plexus/ && do { ($a,$b) = split(" ",$_); print $b; exit; }'`
X.s kill -USR1 $pid
END_OF_FILE
if test 413 -ne `wc -c <'summary'`; then
    echo shar: \"'summary'\" unpacked with wrong size!
fi
chmod +x 'summary'
# end of 'summary'
fi
if test -f 'usage.byhost' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'usage.byhost'\"
else
echo shar: Extracting \"'usage.byhost'\" \(657 characters\)
sed "s/^X//" >'usage.byhost' <<'END_OF_FILE'
X#!/usr/bin/perl
X#
X# usage.byhost
X#
X$log = $ARGV[0] || "/usr/local/www/log";
X$sum = "usage.host";
Xif ( -f $sum ) {
X    rename ($sum, "$sum-") || die "rename $sum $sum-: $!";
X}
Xif ( -f "$sum-" ) {
X    open(SUM, "< $sum-") || die "$sum-: $!";
X    while(<SUM>) {
X        ($a, $b) = split(" ", $_, 2);
X        $count{$b} += $a;
X    }
X    close(SUM);
X}
Xopen(SUM, "> /tmp/$sum") || die "$sum: $!";
X
Xopen(LOG, $log) || die "$log: $!";
Xwhile(<LOG>) {
X    next if /^-/;
X    chop;
X    s/ .*//;
X    $count{$_}++;
X}
Xclose(LOG);
X
Xforeach $i (keys(%count)) {
X    printf(SUM "%6d %s\n", $count{$i}, $i);
X}
Xclose(SUM);
Xsystem("sort -rn /tmp/$sum > $sum ; rm -f /tmp/$sum");
END_OF_FILE
if test 657 -ne `wc -c <'usage.byhost'`; then
    echo shar: \"'usage.byhost'\" unpacked with wrong size!
fi
chmod +x 'usage.byhost'
# end of 'usage.byhost'
fi
if test -f 'usage.byurl' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'usage.byurl'\"
else
echo shar: Extracting \"'usage.byurl'\" \(1104 characters\)
sed "s/^X//" >'usage.byurl' <<'END_OF_FILE'
X#!/usr/bin/perl
X#
X# usage.byurl
X#
Xsub junk {
X    $_[0] =~ s,^(/decode_walk)[/\?].*,\1, && return 1;
X    $_[0] =~ s,^(/bookmark)[/\?].*,\1, && return 1;
X    $_[0] =~ s,^(/finger)[/\?].*,\1, && return 1;
X    $_[0] =~ s,^(/date)[/\?].*,\1, && return 1;
X    $_[0] =~ s,^(/calendar)[/\?].*,\1, && return 1;
X    $_[0] =~ s,^(/bsdi-man)[/\?].*,\1, && return 1;
X    $_[0] =~ s,^(/faces)[/\?].*,\1, && return 1;
X    0;
X}
X$log = $ARGV[0] || "/usr/local/www/log";
X$sum = "usage.url";
Xif ( -f $sum ) {
X    rename ($sum, "$sum-") || die "rename $sum $sum-: $!";
X}
Xif ( -f "$sum-" ) {
X    open(SUM, "< $sum-") || die "$sum-: $!";
X    while(<SUM>) {
X	($a, $b) = split(" ", $_, 2);
X	&junk($b);
X	$count{$b} += $a;
X    }
X    close(SUM);
X}
Xopen(SUM, "> /tmp/$sum") || die "$sum: $!";
X
Xopen(LOG, $log) || die "$log: $!";
Xwhile(<LOG>) {
X    next if /^-/ || /^137.39.95.2 / || /^127.0.0.1 /;
X    next unless ($b) = m/GET ([^ \t\r\n]*)/;
X    &junk($b);
X    $count{$b}++;
X}
Xclose(LOG);
X
Xforeach $i (keys(%count)) {
X    printf(SUM "%6d %s\n", $count{$i}, $i);
X}
Xclose(SUM);
Xsystem("sort -rn /tmp/$sum > $sum ; rm -f /tmp/$sum");
END_OF_FILE
if test 1104 -ne `wc -c <'usage.byurl'`; then
    echo shar: \"'usage.byurl'\" unpacked with wrong size!
fi
chmod +x 'usage.byurl'
# end of 'usage.byurl'
fi
echo shar: End of shell archive.
exit 0

From daemon  Sat Jun 19 00:32:26 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11177; Sat, 19 Jun 93 00:32:28 MET DST
Return-Path: <kevin@scic.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11173; Sat, 19 Jun 93 00:32:26 MET DST
Received: from ssd.intel.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05567; Sat, 19 Jun 1993 00:54:41 +0200
Received: from sv002.scic.intel.com by SSD.intel.com (4.1/SMI-4.1)
	id AA03493; Fri, 18 Jun 93 15:54:36 PDT
Received: from rs042.scic.intel.com by sv002.scic.intel.com (4.1/SCICX.1.11); Fri, 18 Jun 93 15:54:35 PDT
Received: from mc024.scic.intel.com by rs042.scic.intel.com (AIX 3.2/UCB 5.64/SCICI.1.11); Fri, 18 Jun 1993 15:54:33 -0700
Message-Id: <9306182254.AA28245@rs042.scic.intel.com>
Date: Fri, 18 Jun 1993 15:53:29 -0800
To: www-talk@nxoc01.cern.ch
From: kevin@scic.intel.com (Kevin Altis)
X-Sender: kevin@rs042.scic.intel.com
Subject: Re: HTML+ support for eqn & Postscript

>The idea is to translate into HTML as much as possible and include
>the rest (pictures, equations, tables, etc.) as inlined images.
>Then, an HTML viewer need only handle inlined images and allow text to
>flow around them. 

This is the only sane way to deal with "foreign" elements that a browser
can't understand or render itself. The number of object types (pictures,
equations, spreadsheets, movies, etc., open and platform specific picture
formats, different ways of specifying equations, etc. will quickly
overwhelm anyone writing browsers. It also clutters the very simple HTML we
now have. In some cases it may even be possible to translate certain
images, such as FAX data into text, that a browser can handle. 

Digression: Under Windows you could use Dynamic Link Libraries for the
Browser to display data types it does not know about: movies, spreadsheets,
etc. and on the Mac you could also use DLL or AppleEvents.

Kevin Altis
Intel Corporation
SuperComputer Systems Division
Beaverton, Oregon


From daemon  Sat Jun 19 00:32:29 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11184; Sat, 19 Jun 93 00:32:31 MET DST
Return-Path: <kevin@scic.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11180; Sat, 19 Jun 93 00:32:29 MET DST
Received: from ssd.intel.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05572; Sat, 19 Jun 1993 00:54:44 +0200
Received: from sv002.scic.intel.com by SSD.intel.com (4.1/SMI-4.1)
	id AA03522; Fri, 18 Jun 93 15:54:42 PDT
Received: from rs042.scic.intel.com by sv002.scic.intel.com (4.1/SCICX.1.11); Fri, 18 Jun 93 15:54:41 PDT
Received: from mc024.scic.intel.com by rs042.scic.intel.com (AIX 3.2/UCB 5.64/SCICI.1.11); Fri, 18 Jun 1993 15:54:36 -0700
Message-Id: <9306182254.AA14423@rs042.scic.intel.com>
Date: Fri, 18 Jun 1993 15:53:33 -0800
To: www-talk@nxoc01.cern.ch
From: kevin@scic.intel.com (Kevin Altis)
X-Sender: kevin@rs042.scic.intel.com
Subject: link areas within images

Not all clients can display images, but images whether PostScript, GIF,
TeX, etc. will end up being part of many online documents. With that in
mind, I think that we need to be able to specify link areas within image
boundaries, not just the image itself as a link. For example, if you
provide a map image, a browser should support selecting particular
locations within that map image. The simplest way to do this is to specify
a rectangular boundary relative to one corner of the image. Since the image
may be scaled to fit within a browser window, the rectangular link area
would also have to be scaled.

PROPOSAL
I propose using the top left corner of the image as 0,0 (top,left) and
specifying the rectangular areas within the image as top,left,bottom,right
relative to the top left corner of the image, which fits with many of the
existing image models. top,left,bottom,right will be specified as positive
integers (you can't have a link area off the image). If a link area
overlaps another, then the first link area specified in the HTML for the
document would take precedence. Link areas within images should have
several highlighting types, much like Bold, Italics, and Underline for
text, so that link areas on the image can appear transparent to the user (a
rectangular highlight would distract from the rest of the image), some
highlight such as color or brightness change, or have a state showing the
link has been visited. Supporting arbitrary closed polygons as link areas
would require a little more work, but would be a good idea in the long run.

BENEFITS
Besides opening up a large number hypertext applications not currently
possible with HTML because the granularity of image links isn't precise
enough, supporting image links probably avoids some other complexities
threatening HTML. The discussions revolving around PRE and equations
indicate that HTML doesn't provide enough control to produce the kinds of
documents we're used to doing with TeX, FrameMaker, PostScript, etc.
However, those documents, or individual parts of those documents can be
rendered by other applications and returned as images to WWW browsers as
long as areas within those returned images still work as hypertext links. A
rendering application that returns an image, could also return relative
rectangles as valid HTML that would specify the location of a particular
word, phrase, embedded equation, embedded image, etc. dynamically, which
the browser can then add to the HTML for that document while the document
is being viewed.

Kevin Altis
Intel Corporation
SuperComputer Systems Division
Beaverton, Oregon


From daemon  Sat Jun 19 02:52:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12116; Sat, 19 Jun 93 02:52:22 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12112; Sat, 19 Jun 93 02:52:19 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18384; Sat, 19 Jun 1993 03:14:34 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22331
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 18 Jun 93 20:14:33 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA27298; Fri, 18 Jun 93 20:17:17 -0500
Date: Fri, 18 Jun 93 20:17:17 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306190117.AA27298@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: from Dr. SGML^H^H^H^H Macro...
X-Md4-Signature: 9a5372fedb2932130dae5a091f8cb244

From: drmacro@vnet.IBM.COM
Date: Fri, 18 Jun 93 08:40:05 EDT
Newsgroups: comp.text.sgml
Subject: HyTime Finite Coordinate Space Locations
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: Usenet 3.1

A typical problem with online presentation systems is the problem
of defining hyperlink anchors and other things within bitmap
images or other multimedia data notations that have no facility
for defining locations within themselves or that are not revisable.
Most systems I've seen provide some sort of addressing mechanism
that applies a location onto the object.  For example, the IPF
online help system under OS/2 lets you create what it calls an
"art link" by specifying a graphic and then coding in the x and
y locations of a hot spot to create a link anchor.  It works, but
it's particularly transportable or flexible.  HyTime provides a
more general solution to this problem through its finite coordinate
space (FCS) location element (fcsloc).

Fcsloc lets you impose or overlay a coordinate space onto a data
object such that the boundaries of the data object are aligned with
the coordinate space.  To make this works takes a little set up on
the application side, but once the coordinate space is defined, using
an FCSLOC is no more difficult than using any other location mechanism.

The finite coordinate space element (FCS) defines a set of coordinate
axes.  Each axis has a measurement domain associated with it, e.g.,
what system of measurement is used for each axis (inches, seconds,
pixels, etc.).  A "semantic" FCS is defined in the DTD by declaring
an element that conforms to the FCS architectural form.  For example,
to address into graphics, we might define a two-dimensional FCS.

Within the document instance, particular portions of the FCS are defined
by specifying instances of the FCS element defined in the DTD.

Thus, to solve the problem of addressing into images, we first declare
an instance of the FCS form in the DTD itself:

<!ELEMENT GraphicGrid - O (evsched : wand : baton)+ >
<!ATTLIST GraphicGrid
          ID       ID    #IMPLIED
          HyTime   NAME  #FIXED fcs
          axisdefs NAMES #FIXED "xaxis yaxis"
>
<!ELEMENT (xaxis : yaxis) - O (#PCDATA) >
<!ATTLIST (xaxis : xaxis)
          HyTime   NAME  #FIXED axis
          axisdim  CDATA #FIXED "1000"     -- Length of axis  --
          axismeas CDATA #FIXED "gquantum" -- generic quantum --
>

These declarations define the semantic coordinate space GraphicGrid,
which for this example just uses the generic quantum as its measurement
unit, which is fine for overlaying onto graphics of varying resolutions.
To actually use the fcsloc element, however, we have to actually put an
instance of GraphicGrid in our document.  It would look like this:

  <GraphicGrid id=maingrid>
  <evsched><event></event></evsched><GraphicGrid>

For this simple example, the finite coordinate space contains a single
empty event element.  This is because for this example, we aren't
creating an event schedule, but simply defining an FCS to overlay onto a
graphic image, however, the element GraphicGrid has required content,
so I had to put something.

The location source for the fcsloc is a
graphic entity, which is addressed via a nameloc element that associates
an ID with the entity name.  The fcsloc element also refers to the FCS
element and contains the actual address within the FCS being located:

<nameloc id=graphic=object><nmlist entity>a-graphic-entity</nameloc>
<fcsloc locsrc=graphic-object
        impfcs=maingrid>
  <extlist>100 150 200 100
</fcsloc>

The Locsrc= attribute names the object against which the fcsloc is
applied (the location source).  The Impfcs= attribute refers to the FCS
element that defines the grid to overlay onto the object, in this case,
the GraphicGrid element with an id of "maingrid".  The extlist element
contains an "extent list", which is nothing more than a set of
dimension specifications, one for each axis, applied in the order the
axis elements are declared in the Axisdefs= attribute of the FCS
element.

Note that for a special-purpose application like IBMIDDoc, the FCS
element would not have to be actually coded in each document, but could
be defined in the application specification and treated as though it
really did exist, so that in practice, all the author has to specify is
the FCSLOC element.  For interchange with other HyTime applications, the
real FCS element could be generated dynamically or included via entity
reference to an entity shipped as part of the IBMIDDoc package.

Notice that the measurement domain of the FCS is ignored for the
purpose of doing the location.  If I understand it correctly,
the imposed FCS is aligned with the boundaries of the location
source (the graphic in this example).  The dimension spec in the
FCSLOC then effectively defines a proportional part of the FCS,
rather than some absolute measurement.  In other words, if the
FCS's measurement domain was centimeters, and you specified
a dimension of '1 450' thinking you were asking for 450 centimeters,
you would really be addressing some proportion of the FCS,
dependent on the length of each axis (defined with the axisdim=
attribute of the Axis elements).

This behavior makes sense because computer-presented objects
tend not to have meaningful absolute extents.  For example, if
you use a word processor that shows a scale across a document and
labels it as "inches", chances are the ruler on the screen won't match
the ruler in your desk.  Also, it's unlikely that the presentation
system will know how big, in absolute measurements, a given object
thinks it is, as that information will always be notation-specific.

Note also that FCSLOC is really an expedient for systems that
don't support either event schedules or have data notations that
provide ways, in that notation, to define anchor points within
them.  Event schedules do provide the richness of expression to
allow the definition of position within an FCS using absolute
measurements.  For example, instead of imposing a hyperlink
anchor onto a graphic using FCSLOC, I could create an event
schedule that places both the graphic and the hyperlink anchor
on the FCS and thus relates them to each other within the
same coordinate space.

<GraphicGrid><!-- FCS element, contains event schedule -->
 <evsched><!-- Contains events in this coordinate space -->
  <event id=the-graphic
         extent="1 782 1 6687">
  <!-- Contains reference to graphic -->
   <object objectname=my-graphic>
  </event>
  <event id=anchor-in-graphic
         extent="100 150 200 100">
   <refkey linkends="the-graphic text-anchor">Link to something else</>
  </event>
 </evsched>
</GraphicGrid>

With this two-event event schedule, I've placed two objects
within a defined coordinate space, in this case, a graphic
and a link, thereby relating them spatially.  The RefKey element
is also an Ilink element, so it specifies the graphic as one
of its anchors explicitly, even though their occurence within
the schedule also relates it to the graphic.  RefKey is an element
from the IBMIDDoc language.  It has the defined semantic of creating
hyperlinks between multimedia objects and text.

Note also that the elements in the event schedule are references
to other objects, not necessarily objects themselves.  This is a
very powerful aspect of event schedules, because it lets you
position objects without modifying the objects themselves--anything
you can address can be placed in an event schedule by using standard
HyTime location elements to refer to it.

For a real online system to present this event schedule, it first
defines the location of the FCS itself (which might be
defined by another event schedule, see the next discussion), then
interprets each event, placing it on the FCS (in this example, a
two-dimensional grid) according to its defined extent.  It then does
whatever processing is associated with the objects in each event,
e.g., display the graphic and display and manage the hyperlink anchor.
None of these functions are anything most sophisticated online
systems don't already do--we've just expressed the constructs using
a standard notation, HyTime.  Implementing support for this level
of function should be a fairly small delta on top of an existing system
that already provides the presentation functions needed.

Note also that an event could itself be a reference to another
event schedule.  For example, consider the problem of defining
a multimedia presentation consisting of a series of "panels"
organized in time.  You would have one event schedule representing
the main time dimension.  The events in this schedule would be
panel events.  Each panel could be described as a two-dimensional
FCS with the panel objects being events within it.  Consider this
example:

<TimeLine><!-- FCS element with one axis, measured in abstract units -->
 <evshed>
  <event extent="1 1"><!-- For this example, each even takes one
                           quantum since we're just defining order -->
   <panel contentref=panel-1><!-- Uses content of Panel element
                                  defined elsewhere -->
    </event>
    <event extent="1"><!-- Starts at quantum following previous event -->
     <panel contentref=panel-2>
    </event>
  </evsched>
</TimeLine>

You could think of this timeline element as being analogous to
a master document in a DTP system, defining at the highest organizational
level the order of inclusion of the constituent elements of the
presentation, with the added function of defining their extents.

Each panel would itself be an event schedule, this time, either
containing or refering to content objects:

<PanelSpec><!-- FCS element with two axes, measured in abstract units -->
 <evsched>
  <TextBlock extent="10 100 20 236">
  <!-- TextBlock is an event form element, now with the application-
       specific semantic of containing text elements. -->
   <parablock contentref="some-text-data">
    <!-- Refers to some text data marked up with IBMIDDoc elements
         elsewhere.-->
  </TextBlock>
  <ViewPort extent="50 100 60 400"><!-- Also of form event -->
   <MultiMediaObject object=video1>
    <TextAlternative>
     <p>This video shows the following...
    </TextAlternative>
   </MultiMediaObject>
  </Viewport>
  &standard-buttons;<!-- Get standard button events -->
</PanelSpec>

Note that the PanelSpec event schedule is a sort of "style spec" for
the panel, defining not the content, but at least one aspect of its
physical aspect, namely the positions of the elements within the
panel space.  However, in this sort of application, the lines between
style and content start to blur a little.  They could be unblurred in
a concrete application by only allowing reference elements within
events.  Conversely, you could define the panel content language
as a series of event schedules that contain their content directly.
But, the details of the presentation of each panel element, such as
border size, color, etc., would be purely a matter of style.

Note in these examples that I've used normal IBMIDDoc elements as
the content of the panel event schedule.  This is to emphasize both
that IBMIDDoc is capable of applying to multimedia applications and
that the purpose of a multi-media-specific language is to do nothing
more than define the order and position of content within time
and space--there is no need to invent completely new content objects.

Going through these examples has convinced me that scheduling in
HyTime is (or can be) much simpler than it looks at first glance.
I was rather surprised at how easy it was to type in the event
schedules above.  I was also surprised at how similar my "panel"
event schedule is to the structures defined by the IBM Dialog Tag
Language, which provides elements for logically organizing panels
into regions that contain the real content elements (fields, buttons,
text, etc).  Regions are explicit coordinate spaces.  Interesting.

Finally, note the indirection in all of this.  This indirection is
crucial both to the implementation and the flexibility of the system.
It is the indirection of pointing from an event schedule to the
content that makes the system flexible and maintainable.  It will be
the job of multimedia authoring tools to manage this indirection for
writers--that's the really difficult part of authoring in this
environment.  For example, I would expect a multimedia editor to
build these sorts of event schedules under the covers as the author
creates their presentation, including providing an interface for
creating the references from events to actual content elements, as
well as doing the things it already does, such as calculating the
extents of events (e.g., the screen locations of viewports or
windows).

More finally, note that given this sort of HyTime language for
defining the structure of multimedia presentations, there's no
need to have a presentation system that interprets the event
schedules in real time (although that would be nice).  You could
(and probably must in the short term) apply the same technique
that the Dialog Tag Language did, namely, compiling the declarative
source into a run-time form that does not need to be interpreted.
It is important to remember that just because your source is structured
with HyTime, it does not mean your presentation system must understand
HyTime, any more than using SGML for text means your ultimate formatter
has to understand SGML.  It only requires the ability to create processors
that create from the source a runtime object that expresses the structures
in the source.  It is really a question of binding time:  when do you
bind the source to its presentation?  In the near term, the binding
will be early, at the time you compile the deliverable into some
proprietary form (e.g., IPF, ToolBook, etc.).  In the future, the
binding will be as late as possible using true HyTime engines that
interpret the source and create the presentation directly at
presentation time.

Eliot Kimber                      Internet:  drmacro@vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-254-5160
IBM Corporation
Research Triangle Park, NC 27709


From daemon  Sat Jun 19 03:30:34 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12352; Sat, 19 Jun 93 03:30:39 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12348; Sat, 19 Jun 93 03:30:34 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23269; Sat, 19 Jun 1993 03:52:49 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23868
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 18 Jun 93 20:52:10 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:dsr@hplb.hpl.hp.com id AA27583; Fri, 18 Jun 93 20:54:44 -0500
Date: Fri, 18 Jun 93 20:54:44 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306190154.AA27583@wintermute.ncsa.uiuc.edu>
To: Torben Noerup Nielsen <torben@hawaii.edu>
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, janssen@parc.xerox.com,
        www-talk@nxoc01.cern.ch
Subject: re: HTML+ support for eqn & Postscript
In-Reply-To: <MailManager.740427210.151.torben@foralie.net.hawaii.edu>
References: <9306181029.AA29068@manuel.hpl.hp.com>
	<MailManager.740427210.151.torben@foralie.net.hawaii.edu>
X-Md4-Signature: 2bb2d80986e5f3b5219e604eaf07c1d2

Torben Noerup Nielsen writes:
> >I will have a look at eqn and Latex to get a feeling for what would
> >be involved in extending HTML+ to directly support equations, and how
> >one could deal with it in browsers.
> 
> Eqn and TeX are essentially equivalent as far as mathematics is
> concerned.  Yeah, TeX is supposed to be more ``standard" in terms of
> spacing and so forth, but structurally, they are equivalent. Eqn is
> old, but incredibly useful and quite clean as well.

TeX/LaTeX is the only way to fly, if we're going to do equations.  A
much larger number of people already know how to use it.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Sat Jun 19 03:53:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12514; Sat, 19 Jun 93 03:53:22 MET DST
Return-Path: <torben%Hawaii.Edu@galaxy.net.hawaii.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12510; Sat, 19 Jun 93 03:53:19 MET DST
Received: from galaxy.net.Hawaii.Edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24976; Sat, 19 Jun 1993 04:15:34 +0200
Received: from foralie.net.hawaii.edu ([132.160.3.1]) by galaxy.net.Hawaii.Edu with SMTP id <119808>; Fri, 18 Jun 1993 16:12:56 -1000
Date: 	Fri, 18 Jun 1993 16:11:09 -1000
From: Torben Noerup Nielsen <torben@hawaii.edu>
Sender: Torben Noerup Nielsen <torben@hawaii.edu>
Subject: re: HTML+ support for eqn & Postscript
To: Marc Andreessen <marca@ncsa.uiuc.edu>
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, janssen@parc.xerox.com,
        www-talk@nxoc01.cern.ch
In-Reply-To: <9306190154.AA27583@wintermute.ncsa.uiuc.edu>
Message-Id: <MailManager.740455869.151.torben@foralie.net.hawaii.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Marc,

> TeX/LaTeX is the only way to fly, if we're going to do equations.  A
> much larger number of people already know how to use it.
>
> Marc

Fine. TeX/eqn are so similar that it really doesn't matter. Functionally, they
are isomorphic and that's what counts. What is important is that either can be
parsed and fed into a symbolic mathematics system and either can express just
about every conceivable collection of equations. With TeX supporting
equations, you would have an incredibly powerful system. Yes, the viewers
would be bigger in terms of lines of code. But consider what you could achieve
with them and I think it's worth it.

Thanks, Torben


From daemon  Sat Jun 19 08:34:37 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13881; Sat, 19 Jun 93 08:34:39 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13877; Sat, 19 Jun 93 08:34:37 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21893; Sat, 19 Jun 1993 08:56:53 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11002
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 19 Jun 93 01:56:51 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA28278; Sat, 19 Jun 93 01:59:35 -0500
Date: Sat, 19 Jun 93 01:59:35 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306190659.AA28278@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: if you get bored...
X-Md4-Signature: f59e7ca464e8b3ae27540ddf8036658c

...take a look at:

http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/hdf-browsing.html

...screen dumps of some new Mosaic capabilities -- browsing scientific
data files in HDF and netCDF formats.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Sun Jun 20 00:03:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19162; Sun, 20 Jun 93 00:03:50 MET DST
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19157; Sun, 20 Jun 93 00:03:47 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06299; Sun, 20 Jun 1993 00:26:05 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA10479; Sat, 19 Jun 1993 18:26:02 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
	id AA11688; Sat, 19 Jun 1993 15:25:58 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
	id AA02140; Sat, 19 Jun 1993 15:27:19 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9306191527.ZM2138@cider.west.ora.com>
Date: Sat, 19 Jun 1993 15:27:18 -0700
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: www-talk@nxoc01.cern.ch
Subject: WWW Developer's Conference

	Announcement:	World-Wide Web Wizards Workshop
	===============================================
	
Dale Dougherty of O'Reilly & Associates and
Tim Berners-Lee of CERN are organizing a technical workshop for
W3 software developers.   We have worked out the following
dates for the workshop, to be held in Cambridge, MA. 

	Wednesday July 28 1993
		to
	Friday July 30 1993

Depending on the turnout, we plan to 
meet at the office of O'Reilly & Associates.

The workshop is an opportunity to bring together developers 
who have been working on WWW-related code and who have had
only email (and web) contact with each other.  

A principal aim will be to discuss development priorities,
especially developments in HTTP and (to a lesser extent) HTML.
Features being added to the public domain code library, and
the basic servers, will be under discussion, for example

	- Authentication and Accounting
	- Naming schemes (URNs and machinery behind them)
	- Style sheet mechanisms
	- Negotiation of document representations,
		character sets, etc in HTTP
	- Interactive objects
	- Software needs of Internet service providers
	
The workshop will not be a tutorial for beginners;
it will be organized as a discussion forum for developers.
The objective is to establish common direction for
Web development, so that developers can benefit from
the work others are doing.

We would also like to have some discussions among those
with an informed managerial perspective on the current
and future directions of the web, and its organization. 

Those who are interested in attending, please email dale@ora.com.

We'd like to get a sense of how many people are coming
to ensure that we have enough space.
We will will distribute additional information, in particular
hotel information and directions, to the www-talk alias. 

Tim Berners-Lee, CERN
Dale Dougherty, O'Reilly & Associates

-- 

Dale Dougherty 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

UUCP:	uunet!ora!dale     Internet :   dale@ora.com


From daemon  Sun Jun 20 04:25:05 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20733; Sun, 20 Jun 93 04:25:07 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20729; Sun, 20 Jun 93 04:25:05 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24726; Sun, 20 Jun 1993 04:47:23 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA27085
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 19 Jun 93 21:47:21 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA00157; Sat, 19 Jun 93 21:50:04 -0500
Date: Sat, 19 Jun 93 21:50:04 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306200250.AA00157@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: launching executables through HTML files
X-Md4-Signature: c3fdd0628372843f7da12b891ce49e09

What's the current status on the idea of allowing hyperlinks in HTML
documents to cause executables to be launched?  

For various reasons, we're about ready to give into our previous
resistance to this whole idea and try to allow, under some
circumstances, local executables to be launched via hyperlinks in
Mosaic.

Didn't someone suggest an exec: URL type, or something like that?

Some users I have talked to in the past have suggested allowing
another application to actually control the launching of a specified
command: the browser would fork off this (more or less trusted)
application which could perform verification, testing of pathnames, or
whatever before giving the user a dialog box that would allow the
command to actually be launched.  Would this be a widely applauded
idea or should the browser just handle things itself (throw up the
command in a dialog box and say, "OK buddy, yes or no?")?

Also, there was the idea that maybe executables should only be allowed
to be launched from documents residing on the local host (not over
ftp, http, or anything else).  This seems like a pretty much useless
restriction with the current state and expansion of transparent
networked filesystems, though.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Sun Jun 20 05:12:33 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21009; Sun, 20 Jun 93 05:12:35 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21005; Sun, 20 Jun 93 05:12:33 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29083; Sun, 20 Jun 1993 05:34:50 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA01080; Sat, 19 Jun 93 22:34:47 -0500
Message-Id: <9306200334.AA01080@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: launching executables through HTML files 
In-Reply-To: Marc Andreessen's message of Sat, 19 Jun 93 21:50:04 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Sat, 19 Jun 1993 22:34:46 -0500
From: Tony Sanders <sanders@bsdi.com>

> command: the browser would fork off this (more or less trusted)
> application which could perform verification, testing of pathnames, or
> whatever before giving the user a dialog box that would allow the
> command to actually be launched.  Would this be a widely applauded
> idea or should the browser just handle things itself (throw up the
> command in a dialog box and say, "OK buddy, yes or no?")?

I think you should be able to configure the browser as to what MIME types
it should handle and which get passed to an external program.  Something
like the following (for X applications anyway):

XMosaic*contentTranslations: \
    		#override			\n\
    text/html:	text_html()			\n\
    text/*:	text_plain()			\n\
    image/gif:	image_gif()			\n\
    image/jpg:	image_jpg()			\n\
    image/*:	exec(xv)			\n\
    video/mpg:	exec(mpeg_play -loop)		\n\
    audio/*:	exec(audio_play)		\n\
    exec/*:	verify_exec() exec(exec_handler)\n\
    */*:	unknown()

The #override means replace the translation table completely,
otherwise do a merge.

Can anyone see that having a URL "exec:..." is better than simply
groking "content-type: exec/*"?  I think using content-type is
better because the "....:" part of a URL should specify how to
retrive the data, not what to do with it.

--sanders

From daemon  Mon Jun 21 01:02:50 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26528; Mon, 21 Jun 93 01:02:52 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26524; Mon, 21 Jun 93 01:02:50 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02810; Mon, 21 Jun 1993 01:24:46 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16633
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 20 Jun 93 18:24:37 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA00795; Sun, 20 Jun 93 18:27:22 -0500
Date: Sun, 20 Jun 93 18:27:22 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306202327.AA00795@wintermute.ncsa.uiuc.edu>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: launching executables through HTML files 
In-Reply-To: <9306200334.AA01080@austin.BSDI.COM>
References: <9306200334.AA01080@austin.BSDI.COM>
X-Md4-Signature: 9cdb9b7ce78789eb2891f0c783c53244

Tony Sanders writes:
> I think you should be able to configure the browser as to what MIME types
> it should handle and which get passed to an external program.  Something
> like the following (for X applications anyway):
> 
> XMosaic*contentTranslations: \
>     		#override			\n\
>     text/html:	text_html()			\n\
>     text/*:	text_plain()			\n\
>     image/gif:	image_gif()			\n\
>     image/jpg:	image_jpg()			\n\
>     image/*:	exec(xv)			\n\
>     video/mpg:	exec(mpeg_play -loop)		\n\
>     audio/*:	exec(audio_play)		\n\
>     exec/*:	verify_exec() exec(exec_handler)\n\
>     */*:	unknown()
> 
> The #override means replace the translation table completely,
> otherwise do a merge.

The reason I've held off doing that in general, believe it or not, is
because I'm not sure what method to use.  I'd rather not invent a new
method.  I may use mailcaps (RFC 1343).  ?

> Can anyone see that having a URL "exec:..." is better than simply
> groking "content-type: exec/*"?  I think using content-type is
> better because the "....:" part of a URL should specify how to
> retrive the data, not what to do with it.

Except that one thing you're never going to do (at least, that I'm
never going to want to let you do :-) is to actually retrieve
executables over the net.  If you look at it from the point of view
that the access method of a URL describes the process to be used to
fetch data, then you could say that could be (a) a network protocol or
(b) a local executable, without violating the metaphor.

I dunno... I still don't like the idea of firing off arbitrary
executables on the client side, so I'm not gonna strenuously argue
either way.

I take it by your use of the exec/* content type that the command to
be executed would be in the data part of the message element and not
in the subtype field of the content type, though, right?

Marc


From daemon  Mon Jun 21 06:13:21 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28399; Mon, 21 Jun 93 06:13:23 MET DST
Return-Path: <phillips@cs.ubc.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28395; Mon, 21 Jun 93 06:13:21 MET DST
Received: from relay.cdnnet.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02142; Mon, 21 Jun 1993 06:35:38 +0200
Received: by relay.CDNnet.CA (4.1/1.14)
	id AA17865; Sun, 20 Jun 93 21:35:34 PDT
Date: 20 Jun 93 21:35 -0700
From: George Phillips <phillips@cs.ubc.ca>
To: <www-talk@nxoc01.cern.ch>
Message-Id: <5848*phillips@cs.ubc.ca>
Subject: Re: launching executables through HTML files

There was some talk of this on comp.infosystems.www.  I think
executable data in a document is a different issue from execution
of local programs.  For code in a document you not only have to
trust the server but you have to agree on what code is -- pretty
difficult across UNIX boxes, never mind throwing MS-DOS, VMS and
MacOS on top of that.  Given the compatibility and trust problems,
you probably wouldn't accept code from anything but a local server
who could just as well point you to an NFS file.

The best suggestion for local program execution was to extend the
file: scheme.  If the URL points to an executable file and that
file is in your access control list, then it is executed and the
output format is know from the .suffix.  In addition, arguments
can be passed to the executable with a magic delimiter ('%/' was
suggested).

So, if you get "file:/usr/local/rn.html%/news/comp/sources/misc",
it will run "/usr/local/rn.html /news/comp/sources/misc".  Assuming,
say, that "/usr/local" is in your "WWWPATH" environment variable.

I'm already using my own version of local program executing URLs
for a newsreader with history and some other stuff.  I'd love to
see this stuff made official so I can distribute these.

From daemon  Mon Jun 21 06:30:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28494; Mon, 21 Jun 93 06:31:01 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28490; Mon, 21 Jun 93 06:30:59 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04411; Mon, 21 Jun 1993 06:53:18 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA03577; Sun, 20 Jun 93 23:53:15 -0500
Message-Id: <9306210453.AA03577@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: launching executables through HTML files 
In-Reply-To: George Phillips's message of 20 Jun 93 21:35:00 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Sun, 20 Jun 1993 23:53:14 -0500
From: Tony Sanders <sanders@bsdi.com>

> The best suggestion for local program execution was to extend the
> file: scheme.  If the URL points to an executable file and that
> file is in your access control list, then it is executed and the
> output format is know from the .suffix.  In addition, arguments
> can be passed to the executable with a magic delimiter ('%/' was
> suggested).
> 
> So, if you get "file:/usr/local/rn.html%/news/comp/sources/misc",
> it will run "/usr/local/rn.html /news/comp/sources/misc".  Assuming,
> say, that "/usr/local" is in your "WWWPATH" environment variable.
> 
> I'm already using my own version of local program executing URLs
> for a newsreader with history and some other stuff.  I'd love to
> see this stuff made official so I can distribute these.

I disagree, you can do this just as well with the methods I've pointed
out using Content-type: and it doesn't require ugly hacks to the browser
(since you already have to deal with handing different content-types off
to the correct external program, adding another type should be clean,
hacking file: isn't).  **Plus** using content-type doesn't require that
you encode the command as a URL (Ugh).

Content-type: exec/x-local

/usr/local/rn.html /news/comp/sources/misc

The browser goes, oh exec/x-local.  I'll hand that off to such-and-such,
the it can decide if /usr/local/rn.html is safe or not.

--sanders

From daemon  Mon Jun 21 08:00:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29035; Mon, 21 Jun 93 08:01:01 MET DST
Return-Path: <phillips@cs.ubc.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29031; Mon, 21 Jun 93 08:00:59 MET DST
Received: from relay.cdnnet.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13022; Mon, 21 Jun 1993 08:23:17 +0200
Received: by relay.CDNnet.CA (4.1/1.14)
	id AA18681; Sun, 20 Jun 93 23:23:13 PDT
Date: 20 Jun 93 23:23 -0700
From: George Phillips <phillips@cs.ubc.ca>
To: www-talk@nxoc01.cern.ch
In-Reply-To: <9306210453.AA03577@austin.BSDI.COM>
Message-Id: <5849*phillips@cs.ubc.ca>
Subject: Re: launching executables through HTML files 

>I disagree, you can do this just as well with the methods I've pointed
>out using Content-type: and it doesn't require ugly hacks to the browser
>(since you already have to deal with handing different content-types off
>to the correct external program, adding another type should be clean,
>hacking file: isn't).  **Plus** using content-type doesn't require that
>you encode the command as a URL (Ugh).
>
>Content-type: exec/x-local
>
>/usr/local/rn.html /news/comp/sources/misc

Well, arguably this is just as messy.  But, believe it or not, I don't
care as long as it will do the job.  I'm probably missing something
about the MIME structure of things, but don't you still need some
sort of URL to get the ball rolling (and keep it rolling)?  Can you
actually say something like:

	Other <A HREF=
	Content-type: exec/x-local

	/usr/local/rn.html /newsgrouplist
	>newsgroups</A>

(Or some syntactically correct variant).  Just to be clear, here's how I
see the file: hack equivalent:

	Other <A HREF=file:/usr/local/rn.html%/newsgrouplist>newsgroups</A>

It would seem some kind of URL hack is necessary, no?

From daemon  Mon Jun 21 09:16:51 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29714; Mon, 21 Jun 93 09:16:57 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29710; Mon, 21 Jun 93 09:16:51 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26456; Mon, 21 Jun 1993 09:39:11 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA08214
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 21 Jun 93 02:39:09 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA02656; Mon, 21 Jun 93 02:41:52 -0500
Date: Mon, 21 Jun 93 02:41:52 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306210741.AA02656@wintermute.ncsa.uiuc.edu>
To: George Phillips <phillips@cs.ubc.ca>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: launching executables through HTML files 
In-Reply-To: <5849*phillips@cs.ubc.ca>
References: <5849*phillips@cs.ubc.ca>
	<9306210453.AA03577@austin.BSDI.COM>
X-Md4-Signature: b8599260f9a02ef0f5c7095e6ca57742

George Phillips writes:
> Well, arguably this is just as messy.  But, believe it or not, I don't
> care as long as it will do the job.  I'm probably missing something
> about the MIME structure of things, but don't you still need some
> sort of URL to get the ball rolling (and keep it rolling)?  Can you
> actually say something like:
> 
> 	Other <A HREF=
> 	Content-type: exec/x-local
> 
> 	/usr/local/rn.html /newsgrouplist
> 	>newsgroups</A>


You'd want, let's see...

Other <A HREF="foobar.mime">newsgroups</A>

Where foobar.mime contained...

------------------------------------------------------------------------------
Content-type: exec/x-local

/usr/local/rn.html /newsgrouplist
------------------------------------------------------------------------------

...or something like that.  I guess.  (Somebody yell at me if I'm
wrong.)

Marc


From daemon  Mon Jun 21 10:29:57 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01318; Mon, 21 Jun 93 10:29:59 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01314; Mon, 21 Jun 93 10:29:57 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23831; Mon, 21 Jun 1993 10:52:17 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA28919 (5.65b/CWI-2.225); Mon, 21 Jun 1993 10:52:13 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 21 Jun 93 09:44:11 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12620; Mon, 21 Jun 93 09:50:28 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306210850.AA12620@manuel.hpl.hp.com>
Subject:  RE two PREs
To: terry@ora.com
Date: Mon, 21 Jun 93 9:50:26 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Terry,

> Presently in xmosaic PRE is presented in a typewriter font; this is okay
> for code examples (unless you have in-line annotations that you want 
> distinguished from the code) but not for all forms of text that should
> be displayed verbatim (poetry).  So either two PREs are needed, or the
> font change in PRE should be invoked specifically, perhaps by using
> CODE inside PRE.

HTML+ has a style attribute for the PRE tag with just such ideas in mind:

<!-- Preformatted text with fixed pitch font,
     respecting original spacing and newlines.
     The style attribute allows authors to specify
     alternative styles, e.g. "poem" which browsers
     could render in a proportional font.
 -->
<!ELEMENT PRE - - (%text;)+>
<!ATTLIST PRE
    id      ID      #IMPLIED -- link destination --
    style   CDATA   #IMPLIED -- various styles --
    width   NUMBER  #IMPLIED -- e.g. 40, 80, 132 -->

My expectation is there are a small number of useful styles for which we can
agree on the names and how to render them. One problem with using a CDATA
(free text) field for style names is that browsers may not recognise less
common ones. It seems to me that it is worth breaching the principle of
presentation independence slightly to include some rendering hints to allow
for graceful degradation. With this in mind I am now considering adding a
justification attribute to the paragraph tag <P>, e.g. <P CENTER>, together
with a line break tag <BR>.

A wider issue is changing character sets, e.g. from Latin-1 to Old English
(or at a more mundane level to Asian character sets).

Switching to 16 bit fonts will help (at least for extant languages). However,
I see no real alternative in the longer term to building in support for
outline fonts, e.g. TrueType, together with full support for the ISO entity
definitions.

Dave Raggett

From daemon  Mon Jun 21 10:35:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01489; Mon, 21 Jun 93 10:36:01 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01485; Mon, 21 Jun 93 10:35:59 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25073; Mon, 21 Jun 1993 10:58:18 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA29187 (5.65b/CWI-2.225); Mon, 21 Jun 1993 10:58:15 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 21 Jun 93 09:49:31 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA12632; Mon, 21 Jun 93 09:55:48 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306210855.AA12632@manuel.hpl.hp.com>
Subject:  HyTime compatibility (was  Re: HTML spec)
To: mleventh@us.oracle.com
Date: Mon, 21 Jun 93 9:55:47 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Michael,

> I believe the growing pains of HTML can only be
> resolved by evolving to the SGML architectural
> form concept, as exemplified by HyTime.  That is
> not to say that WWW architectural forms should
> *be* HyTime, but *a* set of architectural forms
> will provide a baseline for WWW browsers.  It
> will be impossible to arrive at a monolithic 
> answer for all problems from whitespace to
> tables.

I am exploring what it means to make HTML+ HyTime compatible. Elliot
Kimber (IBM) is helping me in this regard. It definitely looks an
important issue for the long term viability of HTML.

Dave Raggett

From daemon  Mon Jun 21 11:11:03 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02446; Mon, 21 Jun 93 11:11:06 MET DST
Return-Path: <VMNETNEW@slacvm.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02442; Mon, 21 Jun 93 11:11:03 MET DST
Received: from SERV02.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10160; Mon, 21 Jun 1993 11:33:21 +0200
Received: from SLACVM.SLAC.STANFORD.EDU (MAILER@SLACVM) by
 SERV02.SLAC.STANFORD.EDU (PMDF #2896 ) id
 <01GZMH72LH1S001WZD@SERV02.SLAC.STANFORD.EDU>; Mon, 21 Jun 1993 02:33:03 PDT
Received: by SLACVM (Mailer R2.08 R208004) id 5987; Mon, 21 Jun 93 02:32:15 PST
Date: 21 Jun 1993 09:03:02 +0000 (GMT)
From: marcus@x4u.desy.de (Marcus Speh)
Subject: How do I use Xmosaic's ISMAP flag with CERN httpd
Sender: VMNETNEW@slacvm.slac.stanford.edu
To: WWW-TALK@nxoc01.cern.ch
Message-Id: <MARCUS.93Jun21110302@x4u.desy.de>
Organization: Deutsches Elektronen-Synchrotron, Hamburg, Germany.
X-Envelope-To: WWW-TALK@INFO.CERN.CH
Content-Transfer-Encoding: 7BIT
Xref: unixhub comp.infosystems.www:367 cern.www.talk:14 slac.www.talk:4
Newsgroups: comp.infosystems.www,cern.www.talk,slac.www.talk
Path: slacvm!unixhub!dxcern!dscomsa!dscomsf!marcus
X-Sender: usenet@dscomsa.desy.de (usenet)

    I am currently writing the hypertext doc to a class library
which I want to be fully transparent for the public. Thus, I
prepared an image of the Class Inheritance Tree with neat
boxes. I thought I'd use the ISMAP feature [I have XMosaic v1.1
for SGI-Irix4d]: I followed your demo, i.e. I have a file which
contains
                                                        <xmp>
<A HREF="./decodeMGLIB"><IMG SRC="MGLIB-all.gif" ISMAP>
</A>
                                                        </xmp>
and in the same dir a file
                                                        <xmp>
/decodeMGLIB
                                                        </xmp>
containing
                                                        <xmp>
<A HREF="/decodeMGLIB?90,400">ISU</A>
<A HREF="/decodeMGLIB?180,299">MultiGrid</A>
                                                        </xmp>
Now, only if I accidentally hit the right coordinates,
(90,400) or (180,299), I get the wanted answer, written to files
named
                                                        <xmp>
/decodeMGLIB?90,400
/decodeMGLIB?180,299
                                                        </xmp>

respectively, while for other coordinates, I get the error:
                                                        <XMP>
**** HTAccess: socket or file number returned by obsolete
load routine!  **** HTAccess: Internal software error.
Please mail www-bug@info.cern.ch!
                                                        </XMP>
In his reply, Tony Sanders (sanders@bsdi.com)
who contributed this feature said he did not even know the
CERN httpd supported it. Tony also writes:
                                                        <PRE>
  What Mosaic
  should be passing to the server for your example
  would be:

  GET /decode?xxx,yyy

  It's the job of the server to decode the xxx,yyy
  coords and translate that to some document.

  > these are the upper right corners of subimages

  I would imagine that you have to describe both corners,
  and I'll bet it's the upper-left and lower-right, not
  upper-right but that's just a guess.
                                                        </PRE>
Now, I dont know whether this quote helps, but maybe one or the
other wizard at CERN, or an XMosaic expert knows the answer.
  If that should be necessary: the files I am talking about above are
at at URL http://info.desy.de:80/pub/www/refs/test, or
<A HREF="http://info.desy.de:80/pub/www/refs/test">here</a>
(if you're reading this with WWW)
                                                                <P>
        <A HREF="http://info.desy.de:80/pub/www/people/marcus.html">
marcus                                                  </a>


From daemon  Mon Jun 21 12:47:09 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04557; Mon, 21 Jun 93 12:47:11 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04551; Mon, 21 Jun 93 12:47:09 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20034; Mon, 21 Jun 1993 13:09:30 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA05819 (5.65b/CWI-2.225); Mon, 21 Jun 1993 13:09:27 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 21 Jun 93 12:00:43 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA13111; Mon, 21 Jun 93 12:06:58 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306211106.AA13111@manuel.hpl.hp.com>
Subject: Re: HTML spec
To: marca@ncsa.uiuc.edu
Date: Mon, 21 Jun 93 12:06:57 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Marc says:

> I haven't had time to type up my feelings in any detail yet, but at this
> point I think that dealing with SGML in general is a complete waste of time
> and that we'd currently be a lot further along if we weren't burdened by the
> SGML baggage we've inherited and are still carrying.  99.99% of the people
> I talk to want to put rich documents online, want control over what it looks
> like, and don't give a damn about semantic markup or distinctions between
> document structure and appearance AT ALL; the other 0.01% are still
> grappling with this whole keyboard-monitor-mouse concept.)

So why don't we lobby Adobe to put in URL based links into its next version
of Postscript and go home now?

Seriously - how much interest is there in a non-proprietary, lightweight
extendable format derived from HTML? Am I barking up the wrong tree with
HTML+ ?

Dave Raggett

From daemon  Mon Jun 21 12:58:05 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04748; Mon, 21 Jun 93 12:58:07 MET DST
Return-Path: <VMNETNEW@slacvm.slac.stanford.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04744; Mon, 21 Jun 93 12:58:05 MET DST
Received: from SERV02.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21177; Mon, 21 Jun 1993 13:20:25 +0200
Received: from SLACVM.SLAC.STANFORD.EDU (MAILER@SLACVM) by
 SERV02.SLAC.STANFORD.EDU (PMDF #2896 ) id
 <01GZMKXWT00W001WZD@SERV02.SLAC.STANFORD.EDU>; Mon, 21 Jun 1993 04:20:11 PDT
Received: by SLACVM (Mailer R2.08 R208004) id 6519; Mon, 21 Jun 93 04:19:32 PST
Date: 21 Jun 1993 10:38:38 +0000 (GMT)
From: hoesel@rugch4.chem.rug.nl (frans van hoesel)
Subject: Re: How do I use Xmosaic's ISMAP flag with CERN httpd
Sender: VMNETNEW@slacvm.slac.stanford.edu
To: WWW-TALK@nxoc01.cern.ch
Message-Id: <20433e$ct1@rugch4.chem.rug.nl>
Organization: Dept. of Chemistry, University of Groningen, the Netherlands
X-Envelope-To: WWW-TALK@INFO.CERN.CH
Content-Transfer-Encoding: 7BIT
Xref: unixhub comp.infosystems.www:368 cern.www.talk:15 slac.www.talk:5
Path: 
 slacvm!unixhub!linac!uwm.edu!wupost!uunet!mcsun!sun4nl!freya.let.rug.nl!rugch4! hoesel
Newsgroups: comp.infosystems.www,cern.www.talk,slac.www.talk
Followup-To: comp.infosystems.www,cern.www.talk,slac.www.talk
Lines: 41
Nntp-Posting-Host: xtreme.chem.rug.nl
X-Newsreader: TIN [version 1.2 PL0]
References: <MARCUS.93Jun21110302@x4u.desy.de>

Marcus Speh (marcus@x4u.desy.de) wrote:
:     I am currently writing the hypertext doc to a class library
: which I want to be fully transparent for the public. Thus, I
: prepared an image of the Class Inheritance Tree with neat
: boxes. I thought I'd use the ISMAP feature [I have XMosaic v1.1
: for SGI-Irix4d]: I followed your demo, i.e. I have a file which
: contains
:                                                         <xmp>
: <A HREF="./decodeMGLIB"><IMG SRC="MGLIB-all.gif" ISMAP>
: </A>
:                                                         </xmp>
: and in the same dir a file
:                                                         <xmp>
: /decodeMGLIB
:                                                         </xmp>
: containing
:                                                         <xmp>
: <A HREF="/decodeMGLIB?90,400">ISU</A>
: <A HREF="/decodeMGLIB?180,299">MultiGrid</A>
:                                                         </xmp>
: Now, only if I accidentally hit the right coordinates,
: (90,400) or (180,299), I get the wanted answer, written to files
: named
:                                                         <xmp>
: /decodeMGLIB?90,400
: /decodeMGLIB?180,299
:                                                         </xmp>

You'll need indeed a special server, that knows about your
document and how to decode it.
It is not simply a matter of creating the right files and
expect things to work.
I *do* want ISMAP or equivalent support, but the links should go into
the document, not on some specialized server that handles your docs.

_________________________________________________________________________
     frans van hoesel                      Phone (fax/voice/data)
 hoesel@Xtreme.chem.rug.nl                     +31.50.127033
   Scientific programmer                  'every day is a good day'
_________________________________________________________________________


From daemon  Mon Jun 21 15:34:17 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07478; Mon, 21 Jun 93 15:34:24 MET DST
Return-Path: <cja@castle.edinburgh.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07473; Mon, 21 Jun 93 15:34:17 MET DST
Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06793; Mon, 21 Jun 1993 15:56:34 +0200
Via: uk.ac.edinburgh.castle; Mon, 21 Jun 1993 14:55:57 +0100
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HyTime compatibility (was Re: HTML spec)
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Cc: mleventh@us.oracle.com, www-talk@nxoc01.cern.ch
Date: Mon, 21 Jun 93 14:55:52 WET DST
Message-Id: <9306211455.aa04200@castle.ed.ac.uk>

> I am exploring what it means to make HTML+ HyTime compatible. Elliot
> Kimber (IBM) is helping me in this regard. It definitely looks an
> important issue for the long term viability of HTML.

I have the HyTime standard in front of me, and on first reading it is
impressive in terms of what it tries to cover.  Much of it is
impenetrable, but I hope another pass through it will clarify my
understanding a bit.

But a word of caution.  In at least two different places I have read
that HyTime was designed for the INTERCHANGE of hypermedia data, and
that it is not necessarily a good choice for an efficient run-time
hypermedia format.  Of course, it may well be that the overhead
associated with HyTime is small compared with the network overhead for
multimedia data transfer - but we should be aware of the problem. 

Making WWW HyTime-compatible does not bring any immediate benefits. 
Maybe it would make the job of client developers easier if there was a
public-domain HyTime engine available - but until there is, it is
difficult to argue for.

Despite the above, I am keen that WWW should move in this direction. 
HyTime appears to provide a good deal of flexibility.  You could simply
view it as a collection of useful ideas with which to design hypermedia
applications - and nothing is lost by building in HyTime compatability.

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom


From daemon  Mon Jun 21 16:41:30 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08627; Mon, 21 Jun 93 16:41:32 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08623; Mon, 21 Jun 93 16:41:30 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21385; Mon, 21 Jun 1993 17:03:51 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03831; Mon, 21 Jun 93 17:02:33 +0200
Date: Mon, 21 Jun 93 17:02:33 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306211502.AA03831@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Mark Leggott <mleggott@sandnc.stfx.ca>
Subject: Re: NeXT client
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



Ok,  I have made a more recent but very buggy app avaialble.
It can't edit -- try and it will destroy your files!
  But you can browse. No embedded graphics unfortunately.

Your development proposal sounds great..... if you are in a position  
to enhance the NeXT editor, then we could come to an arrangement...

Here is the corrent README from ftp://info.cern.ch/

	THE EDITOR

WorldWideWeb_0.16.tar.Z is the only wysiwyg hypertext editor for the
NeXT.  It has limitations and bugs -- it can't access Gopher, FTP  
sites,
etc.  But it is a hypertext editor!

Note this app is compiled for NextStep 3.0 and won't work with 2.1.
There is no way round this; don't ask!  (The Project file is
converted by the ProjectBuilder to a version 3 project file
when you first compile for version 3.  The version 3 project
file won't work with 2.0 (Interface builder and project builder
shared a file and an app in 2.x), and so there is no going back!
The 3.x app won't work under 2.x as it needs 3.x shared libaries.)


	THE BROWSER

The file labelled 1.0 is a pre-alpha browser which uses the libwww
library, so you can get multimedia files etc etc.  Does doc
format conversion, etc.  


THE EDITOR DOES NOT WORK.  NOT SUPPORTED....
Only for the curious.  This DOES handle Gopher, FTP, etc.

Sorry they have the same icon now ... can be very confusing
if you use both.

timbl


Begin forwarded message:

From: Mark Leggott <mleggott@sandnc.stfx.ca>
Date: Fri, 18 Jun 93 14:35:54 -0400
To: www-talk@nxoc01.cern.ch
Subject: NeXT client

Sorry if I am covering ground covered elsewhere (FAQ's), but I  
thought this might be an appropriate forum for my questions.

I am investigating the possibility of using WWW as the central app  
for our proposed electronic library system (Xel - Xavier electronic  
library).  Having come here recently (2 months ago) from a  
CD-ROM/Hypertext company, WWW appeals to me for a number of reasons.   
I have also worked with various _SGML_, or _SGML-like_ engines (OWL  
Guide, CDAuthor Hypertext, KRS, PLS, Hyperwriter, WorldView, IDEAS,  
Mark-It, etc) and would like to build on that.

The library has four NeXT machines, which will form the seed of the  
system, and they will be the platform where capabilities of the Web  
are first demonstrated (I hope).  I would like to prepare a demo of a  
home page providing access to regional resources (ie. telnet'ing to  
other library catalogues, ftp sites, etc) sometime in the next few  
weeks. 


I realize the latest version (0.16) of the NeXT Hypermedia  
Browser/Editor does not support telnet, gopher, etc., but I would  
like to use the NeXT for these early demos if possible.  Besides, I  
am new to NeXT, love it, and would like to use it for document  
creation/development. Once I get into the development environment in  
more detail I would be interested in helping in any way I can with  
the NeXT WWW app.

- Does anybody have a NeXT browser that supports these functions, or  
is there a way to telnet from the current version in some way? 


- If not, I have recently loaded MouseX for X11R5 - does anybody have  
any experience with Viola or other X11 apps using this version?   
Should I obtain a different X app for NeXT that has been proven with  
some of these? 


- I have also recently loaded the Cello app, but would like to stay  
away from DOS/Windows if possible for now.

I appreciate any info you may be able to provide, and am looking  
forward to working with WWW and the Web development community.

Thanks

================================================================
Mark Leggott, NeXT Administrator / Database&Network Coordinator
Angus L. MacDonald Library, St. Francis Xavier University
Antigonish, Nova Scotia, E2G 1C0  Canada     

Voice 902-867-2242  FAX 902-867-2334
================================================================


From daemon  Mon Jun 21 16:50:20 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08774; Mon, 21 Jun 93 16:50:22 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08770; Mon, 21 Jun 93 16:50:20 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23829; Mon, 21 Jun 1993 17:12:40 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03863; Mon, 21 Jun 93 17:11:21 +0200
Date: Mon, 21 Jun 93 17:11:21 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306211511.AA03863@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: sanders@bsdi.com
Subject: Re: public annotations
Cc: Marc Andreessen <marca@ncsa.uiuc.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


I was thinking of making a new algorithm for finding a home page --
to first try, at machine fred.dep.uni.edu

	http://www.dep.uni.edu/			and then
	http://www.uni.edu/			and then
	http://www.edu/				and then
	some basic home page.
	
There are quite a lot of places where this will give something
now.  Sounds alike an easy default for people who might
pick up the software and not know that there is in fact a local
server.  It will ease admin and promote more servers.

The search would be only in the DNS of couse, if they don't
exist. If one of these is found, it could also by default be
used as a site server.

Whadya think?

Tim


From daemon  Mon Jun 21 17:08:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09089; Mon, 21 Jun 93 17:08:42 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09085; Mon, 21 Jun 93 17:08:40 MET DST
Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28408; Mon, 21 Jun 1993 17:30:59 +0200
Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
	id AA19793 (5.65b/CWI-2.225); Mon, 21 Jun 1993 17:30:55 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 21 Jun 93 16:22:38 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA14282; Mon, 21 Jun 93 16:28:55 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306211528.AA14282@manuel.hpl.hp.com>
Subject: Re: link areas within images
To: kevin@rs042.scic.intel.com
Date: Mon, 21 Jun 93 16:28:53 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Kevin Altis says:

> PROPOSAL
> I propose using the top left corner of the image as 0,0 (top,left) and
> specifying the rectangular areas within the image as top,left,bottom,right
> relative to the top left corner of the image, which fits with many of the
> existing image models. top,left,bottom,right will be specified as positive
> integers (you can't have a link area off the image). If a link area
> overlaps another, then the first link area specified in the HTML for the
> document would take precedence. Link areas within images should have
> several highlighting types, much like Bold, Italics, and Underline for
> text, so that link areas on the image can appear transparent to the user (a
> rectangular highlight would distract from the rest of the image), some
> highlight such as color or brightness change, or have a state showing the
> link has been visited. Supporting arbitrary closed polygons as link areas
> would require a little more work, but would be a good idea in the long run.

Kevin, you make like to look at HTML+ and how it supports figures using an
element specifying rectangular regions within the image and a URL to
traverse when the user clicks on this part of the image. The image data
is specified as either a URL or via embedded data on a non-HTML+ format (e.g.
for Adobe Illustrator drawings). This work is based on Pei Wei's experimental
DTD "HMML" and provides an alternative to making the server do all the work.

The coordinate scheme is (0,0) for the upper left corner to (1,1) for the
lower right. Scaled coordinates are used because pixel based coordinates are
inappropriate for drawings.

Dave Raggett

p.s. the HTML+ DTD is at  ftp://info.cern.ch/pub/www/dev/htmlplus.dtd.txt

From daemon  Mon Jun 21 17:58:01 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10208; Mon, 21 Jun 93 17:58:04 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10204; Mon, 21 Jun 93 17:58:01 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10522; Mon, 21 Jun 1993 18:20:21 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA05202; Mon, 21 Jun 93 11:20:18 -0500
Message-Id: <9306211620.AA05202@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: How do I use Xmosaic's ISMAP flag with CERN httpd 
In-Reply-To: frans van hoesel's article in comp.infosystems.www,cern.www.talk,slac.www.talk  of 21 Jun 93 10:38:38 -0000.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 21 Jun 1993 11:20:18 -0500
From: Tony Sanders <sanders@bsdi.com>

> You'll need indeed a special server, that knows about your
> document and how to decode it.
> It is not simply a matter of creating the right files and
> expect things to work.
FYI: this is a lot easier in the next Plexus (2.2 coming soon).  You just
create a file that describes your image, you can use a combination of
bitmasks and rectangles to set all the hot spots.  Hopefully, I'll have
time at some point to write an X based app that pops up your image and
lets you set all the hot spots then writes out all the necessary data.
e.g., Here is all the data you have to generate for the space walk demo:
    walk default server/walk/default.html
    walk bitmask server/walk/astronaut.mask 106 110 server/walk/astronaut.html
    walk bitmask server/walk/camera.mask 106 110 server/walk/camera.html
    walk bitmask server/walk/earth.mask 106 110 server/walk/earth.html
    walk bitmask server/walk/pack.mask 106 110 server/walk/pack.html
    walk rect 0 0 106 110 server/walk/space.html

> I *do* want ISMAP or equivalent support, but the links should go into
> the document, not on some specialized server that handles your docs.
Look at the FIGA stuff in HTML+.  I think we've pretty well established
that both are desirable.  ISMAP just happens to be the best solution
for existing browsers.

--sanders

From daemon  Mon Jun 21 17:58:14 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10219; Mon, 21 Jun 93 17:58:16 MET DST
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10213; Mon, 21 Jun 93 17:58:14 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10781; Mon, 21 Jun 1993 18:20:34 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA07640; Mon, 21 Jun 1993 12:20:19 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
	id AA21066; Mon, 21 Jun 1993 09:20:15 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
	id AA03348; Mon, 21 Jun 1993 09:21:36 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9306210921.ZM3346@cider.west.ora.com>
Date: Mon, 21 Jun 1993 09:21:35 -0700
In-Reply-To: Dave_Raggett <dsr@hplb.hpl.hp.com>
        "HyTime compatibility (was  Re: HTML spec)" (Jun 21,  9:55am)
References: <9306210855.AA12632@manuel.hpl.hp.com>
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HyTime compatibility (was  Re: HTML spec)
Cc: www-talk@nxoc01.cern.ch

Dave,

In my opinion, HyTime is not a useful direction for
WWW at this time.  It will require a lot of effort just to
understand, and even more to implement on a basic level.  As
part of the Davenport Group, I spent more than a year
investigating HyTime for possible use in Docbook DTD and other
online publishing activities.  I did not see broad support
for HyTime, as a standard or as technology.  I
decided that HyTime was not something to be used by our
current or next generation of technology. I was also very
frustrated that HyTime exists only on paper, and so anyone
can say anything about it without proving it in practice.

You have to separate out the claims made for HyTime and the technology
or applications required to make use of it.  Most people
who talk HyTime do not bother to distinguish between the two
and they tend to trivialize the impact on applications. 
Remember, there are no HyTime engines available anywhere
and until there are no one can prove or disprove their claims.
When someone says "HyTime allows you to do ....", probe for
specifics.  Ask how it works.

You will also have trouble figuring out whether HyTime is
a standard syntactical representation for hypermedia constructs
or a way of life.  If the latter, then you have to
start living that way now, or be lost.  (And that's why
most HyTime advocates urge you to accept HyTime now.)  If it is just
a standard representation of the kind of things we are already
doing, then the door is always open to use that syntax,
should it emerge as something of value.  

HyTime is intended to be an interchange standard, and its
awkward syntax is not meant to be processed in real-time.
If you study the standard, you will find out that for
the most part, its method of standard representation involves
putting a standard "wrapper" around application-specific info.  
So, for instance, it allows HyTime apps to identify links 
in a standard way, but it does not make the link addressing used in
applications interoperable.  In WWW, we use URLs for link addressing
and if we send an HTML document to another 
hypermedia application, the tough part to interchange is the URL.
If the target app does not understand URLs, the document is
pretty useless.  All HyTime would do is put the URL in 
a standard wrapper indicating that the tag contained link information.  

We should be aware of HyTime -- there are some challenging
ideas in it that go way beyond linking. However, we should
not ignore the absence of HyTime-based technology -- none was 
developed to test the specification as part of the standardization 
process. If you take the view that
HyTime offers a standard representation for hypermedia documents, 
then we should be able to convert HTML documents into
a form that is HyTime-compliant for the purpose of interchanging
documents with other HyTime-supporting apps,
(which do not yet exist).   As long as our focus is
on creating documents to be used in the Web, 
we don't need to be encumbered by HyTime syntax, much
less by the HyTime way of thinking.  Anyone who feels HyTime
is important is free to manage his information using
HyTime-compliant DTDs and then create HTML versions of
those documents for the Web.  We do not need it as a way
to interchange documents among Web browsers and create
interoperable links; we have that
level of standardization right now, and we have something
that works.

Dale

-- 

Dale Dougherty 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

UUCP:	uunet!ora!dale     Internet :   dale@ora.com


From daemon  Mon Jun 21 18:10:11 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10521; Mon, 21 Jun 93 18:10:18 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10515; Mon, 21 Jun 93 18:10:11 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16518; Mon, 21 Jun 1993 18:32:30 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 21 Jun 93 17:24:27 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA14381; Mon, 21 Jun 93 17:30:44 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306211630.AA14381@manuel.hpl.hp.com>
Subject: Re: HyTime compatibility (was Re: HTML spec)
To: C.J.Adie@edinburgh.ac.uk
Date: Mon, 21 Jun 93 17:30:43 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Chris,

> But a word of caution.  In at least two different places I have read
> that HyTime was designed for the INTERCHANGE of hypermedia data, and
> that it is not necessarily a good choice for an efficient run-time
> hypermedia format.  Of course, it may well be that the overhead
> associated with HyTime is small compared with the network overhead for
> multimedia data transfer - but we should be aware of the problem. 

I am still exploring what it means to make HTML+ HyTime compliant
or compatible. It is really a matter of conforming to some of the
architectural ideas in HyTime. We don't need to take on board
everything HyTime includes. In some cases we might want to provide
a HyTime compliant alternative when the normal HTML approach is
incompatible with HyTime. There is no pressure to adopt features
that would penalise an efficient run-time hypermedia format. 

At its simplest, we could provide support for hypertext references
via entity declarations following the CLINK and NOTLOC model. This
means you could declare all the references at the start of the
document, and then use local names throughout the body of the
document where ever you need a hypertext reference.

With WYSIWYG editors this wouldn't be too much of a pain. The HREF
attribute would remain as now, but there would be an alternative
that assumes local names and which is HyTime compliant.

Much of this involves some extra attributes of interest only when
trying to get another HyTime compliant system to make sense of an
HTML+ document. It wouldn't effect HTML+ browsers significantly.

Other aspects of HyTime can be included as additions to the DTD as
a bridge to the future when HyTime location ladders and finite
coordinate space elements become useful.

Regards,

Dave Raggett

From daemon  Mon Jun 21 18:32:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11050; Mon, 21 Jun 93 18:33:01 MET DST
Return-Path: <weber@eitech.eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11046; Mon, 21 Jun 93 18:32:59 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25918; Mon, 21 Jun 1993 18:55:05 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA08299; Mon, 21 Jun 93 11:54:54 -0500
Received: from eitech.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA15458; Mon, 21 Jun 93 09:49:08 PDT
Message-Id: <9306211649.AA15458@eitech.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: HTML spec 
In-Reply-To: Your message of "Mon, 21 Jun 1993 12:06:57 -0000."
             <9306211106.AA13111@manuel.hpl.hp.com> 
Date: Mon, 21 Jun 1993 09:49:07 -0700
From: "Jay C. Weber" <weber@eitech.eitech.com>

>Seriously - how much interest is there in a non-proprietary, lightweight
>extendable format derived from HTML? Am I barking up the wrong tree with
>HTML+ ?
>
>Dave Raggett

Dave,

A lot of us think you are barking up the right tree.  Thanks for
your focus and effort.

Jay Weber


From daemon  Mon Jun 21 18:38:41 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11149; Mon, 21 Jun 93 18:38:43 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11145; Mon, 21 Jun 93 18:38:41 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26377; Mon, 21 Jun 1993 19:01:01 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA07797
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 21 Jun 93 12:00:59 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA03425; Mon, 21 Jun 93 12:03:46 -0500
Date: Mon, 21 Jun 93 12:03:46 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306211703.AA03425@wintermute.ncsa.uiuc.edu>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: marca@ncsa.uiuc.edu, www-talk@nxoc01.cern.ch
Subject: Re: HTML spec
In-Reply-To: <9306211106.AA13111@manuel.hpl.hp.com>
References: <9306211106.AA13111@manuel.hpl.hp.com>
X-Md4-Signature: 858ede3c0e52615b6d8ebe8bb7069961

Dave_Raggett writes:
> So why don't we lobby Adobe to put in URL based links into its next version
> of Postscript and go home now?

I wonder...

> Seriously - how much interest is there in a non-proprietary,
> lightweight extendable format derived from HTML? Am I barking up the
> wrong tree with HTML+ ?

Lots and nope.  I think you're doing a great job with HTML,
particularly in that HTML+ will greatly enhance the capabilities of
WWW systems; it will get a lot of use and I look forward to supporting
it, as I've said before.  But I would think that whether or not SGML
had anything to do with it or not, and I think it will be useful
to more people if SGML isn't allowed to philosophically restrict it
(similar to the way HTML became more useful with <I> and <B>).

Cheers,
Marc


From daemon  Tue Jun 22 00:09:40 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18241; Tue, 22 Jun 93 00:09:42 MET DST
Return-Path: <paolo@venedig.ai.univie.ac.at>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18237; Tue, 22 Jun 93 00:09:40 MET DST
Received: from moskau.ai.univie.ac.at by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08894; Tue, 22 Jun 1993 00:31:58 +0200
Received: by moskau.ai.univie.ac.at id AA05420
  (5.65c8/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Tue, 22 Jun 1993 00:31:50 +0200
From: paolo petta <paolo@venedig.ai.univie.ac.at>
Message-Id: <199306212231.AA05420@moskau.ai.univie.ac.at>
Subject: 2.07 and WAIS<->WWW *sources*?
To: www-talk@nxoc01.cern.ch
Date: Tue, 22 Jun 1993 00:31:44 +0200
X-Mailer: ELM [version 2.3 PL11]

Versions 2.07 of the library and the line mode browser have been
available at info.cern.ch for a couple of days now...

My questions:

1) will the sources be published, too?
	(there are only the 2.06 right now...)

2) does this version already include the WAIS-WWW gateway functionality?
	(if I am not totally mistaken this was hinted at by TBL...)

3) if the WAIS-WWW gateway is not included in 2.07, could some kind soul
	please point me to a source? We need to set one up for our
	internal use (and thus can't rely on `external' gateways - not
	to speak of the bottleneck of our feeble internet connection)

Thank you very much indeed!

paolo
-- 
paolo petta                                            +43-1-5336112(Tel)
Austrian Research Inst. for Artificial Intelligence    +43-1-5320652(Fax)
Schottengasse 3, A-1010 Vienna, Austria, Europe     paolo@ai.univie.ac.at 

From daemon  Tue Jun 22 00:32:07 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18622; Tue, 22 Jun 93 00:32:09 MET DST
Return-Path: <Christopher.McRae@library.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18618; Tue, 22 Jun 93 00:32:07 MET DST
Received: from [128.218.15.10] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17957; Tue, 22 Jun 1993 00:54:29 +0200
Received: from sphinx.library.ucsf.edu by library.ucsf.edu with SMTP id AA02389
  (5.67a8/IDA-1.5 for <www-talk>); Mon, 21 Jun 1993 15:54:14 -0700
Message-Id: <199306212254.AA02389@library.ucsf.edu>
To: www-talk@library.ucsf.edu
Subject: Re: HTML spec 
In-Reply-To: Your message of "Mon, 21 Jun 93 12:06:57 BST."
             <9306211106.AA13111@manuel.hpl.hp.com> 
Date: Mon, 21 Jun 93 15:57:20 MDT
From: "Christopher J. McRae" <Christopher.McRae@library.ucsf.edu>


Dave writes:
> So why don't we lobby Adobe to put in URL based links into its next version
> of Postscript and go home now?
> 

  Can you say Acrobat?  Adobe Acrobat is a new product from abobe which
includes, among other things, the successor to postscript, PDF (Portable
Document Format).  PDF is essentially postscript with embedded structure,
including hyperlinks. 

Chris
--------------------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From daemon  Tue Jun 22 01:04:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19017; Tue, 22 Jun 93 01:05:00 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AB19013; Tue, 22 Jun 93 01:04:58 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26911; Tue, 22 Jun 1993 01:27:20 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA04026
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 21 Jun 93 18:27:12 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:dsr@hplb.hpl.hp.com id AA05248; Mon, 21 Jun 93 18:29:47 -0500
Date: Mon, 21 Jun 93 18:29:47 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306212329.AA05248@wintermute.ncsa.uiuc.edu>
To: dale@ora.com (Dale Dougherty)
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Subject: Re: HyTime compatibility (was  Re: HTML spec)
In-Reply-To: <9306210921.ZM3346@cider.west.ora.com>
References: <9306210855.AA12632@manuel.hpl.hp.com>
	<9306210921.ZM3346@cider.west.ora.com>
	<dsr@hplb.hpl.hp.com>
X-Md4-Signature: 7ac2b0686c89decf0e7b0bd141f1b108

Dale Dougherty writes:
> [...] I did not see broad support for HyTime, as a standard or as
> technology. [...] I was also very frustrated that HyTime exists only
> on paper, and so anyone can say anything about it without proving it
> in practice. [...] Remember, there are no HyTime engines available
> anywhere [...]

Amen.

Marc


From daemon  Tue Jun 22 01:26:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19210; Tue, 22 Jun 93 01:26:57 MET DST
Return-Path: <putz@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19206; Tue, 22 Jun 93 01:26:56 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06155; Tue, 22 Jun 1993 01:49:17 +0200
Received: from spoggles.parc.xerox.com ([13.1.102.87]) by alpha.xerox.com with SMTP id <11703>; Mon, 21 Jun 1993 16:49:04 PDT
Received: by spoggles.parc.xerox.com id <2445>; Mon, 21 Jun 1993 16:48:51 -0700
From: Steve Putz <putz@parc.xerox.com>
To: www-talk@nxoc01.cern.ch
Subject: Experimental Map Browser WWW server at pubweb.parc.xerox.com
Message-Id: <93Jun21.164851pdt.2445@spoggles.parc.xerox.com>
Date: 	Mon, 21 Jun 1993 16:48:40 PDT

Some of you have already discovered there is a new experimental World
Wide Web Server running at the Xerox Palo Alto Research Center in Palo
Alto, California.  The address is pubweb.parc.xerox.com. See:

<A HREF="http://pubweb.parc.xerox.com:80/">Xerox PARC PubWeb Server</A>

Currently the only documents available are via a custom map rendering
service -- yet another experiment in providing dynamic information
retrieval via World Wide Web.

The Map Viewer is implemented as as a perl script that accepts requests
for map renderings (encoded as URLs) and returns HTML documents
including a Mosaic-style inlined GIF image of the requested map. It
does not yet take advantage of the Mosaic extensions for detecting
mouse positions within an image.

Eventually we may use this server to publish some general information
about PARC and perhaps provide access to published PARC technical
reports.

Steve Putz <putz@parc.xerox.com>
Xerox Palo Alto Research Center
Palo Alto, California

From daemon  Tue Jun 22 02:19:23 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19695; Tue, 22 Jun 93 02:19:24 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19691; Tue, 22 Jun 93 02:19:23 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29692; Tue, 22 Jun 1993 02:41:42 +0200
Received: by kauri.vuw.ac.nz id AA13621
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Tue, 22 Jun 1993 12:41:36 +1200
Date: Tue, 22 Jun 1993 12:41:36 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306220041.AA13621@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Authentication

This is something I want.  Has anyone looked at RFC 1416, on Telnet
Authentication?  If there's a working model, it shouldn't be too hard
to implement in the HTTP protocol ...

Nat

From daemon  Tue Jun 22 05:50:13 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21429; Tue, 22 Jun 93 05:50:15 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21425; Tue, 22 Jun 93 05:50:13 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AC04531; Tue, 22 Jun 1993 06:12:35 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA15747
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 21 Jun 93 23:12:34 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA05637; Mon, 21 Jun 93 23:15:19 -0500
Date: Mon, 21 Jun 93 23:15:19 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306220415.AA05637@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: new HTML primer
X-Md4-Signature: 81b53afadb58bcad76aedcb975fbbe5f

A new HTML primer is up at
http://www.ncsa.uiuc.edu/demoweb/html-primer.html ...
comments to pubs@ncsa.uiuc.edu.

Cheers,
Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Tue Jun 22 11:59:04 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25372; Tue, 22 Jun 93 11:59:07 MET DST
Return-Path: <cja@castle.edinburgh.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25368; Tue, 22 Jun 93 11:59:04 MET DST
Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24659; Tue, 22 Jun 1993 12:21:24 +0200
Via: uk.ac.edinburgh.castle; Tue, 22 Jun 1993 11:13:34 +0100
To: dale@ora.com
Subject: Re: HyTime compatibility (was Re: HTML spec)
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Date: Tue, 22 Jun 93 11:13:18 WET DST
Message-Id: <9306221113.ab13569@castle.ed.ac.uk>

Dale Dougherty writes:
> In WWW, we use URLs for link addressing and if we send an HTML document
> to another hypermedia application, the tough part to interchange is the
> URL.  If the target app does not understand URLs, the document is pretty
> useless.  All HyTime would do is put the URL in a standard wrapper
> indicating that the tag contained link information. 

From my limited understanding of HyTime, I believe this is correct - 
there is no way you could take a document from one HyTime system and
expect to import it into another HyTime system without change.  But the
task is much _easier_ if both systems are HyTime compliant.

Let's summarise the advantages and disadvantages of adding HyTime CLINKs
to HTML+.

Advantage:

 * Easier to import information from other HyTime-compliant systems, or
   from systems which export information in HyTime-compliant format (of
   which there are currently none).

Disadvantages:

 * Two alternative ways of doing the same thing leads to lack of
   clarity in the DTD.

 * Added complexity in browser code (which would have to support both
   styles of link, and wouldn't have a HyTime engine to help - yet).

On this one it seems to me that the disadvantages outweigh the advantages -
HyTime CLINKs are not the way to go for HTML+.

However, Dale also says:

> there are some challenging ideas in [HyTime] that go way beyond linking.

Could the ideas in HyTime's measurement module and the concept of a FCS
help in defining hot spots within an image?  There would be no
disadvantages associated with multiple ways of doing things.

I'd also like to explore how HyTime constructs could be used to express
synchronisation relationships between documents.

On one or two things I want to take issue with Dale:

> As
> part of the Davenport Group, I spent more than a year
> investigating HyTime for possible use in Docbook DTD and other
> online publishing activities.  I did not see broad support
> for HyTime, as a standard or as technology.  I
> decided that HyTime was not something to be used by our
> current or next generation of technology. I was also very
> frustrated that HyTime exists only on paper, and so anyone
> can say anything about it without proving it in practice.

Did you reject HyTime simply based on these reasons, or were there
specific technical issues which you objected to? If so, I'm interested
to know what they were.

The Davenport Group certainly went on to use HyTime in their SOFABED
spec.

> However, we should not ignore the absence of HyTime-based technology --
> none was developed to test the specification as part of the
> standardization process. 

HyTime-based technology _is_ being developed.

HTML+ will need testing and changing before it is finished.  We should
not be afraid to add bits of HyTime to HTML+ if it looks sensible to do so.
If it doesn't work, it can be replaced.

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom


From daemon  Tue Jun 22 20:04:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08491; Tue, 22 Jun 93 20:04:49 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08487; Tue, 22 Jun 93 20:04:47 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09484; Tue, 22 Jun 1993 20:27:53 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA23983; Tue, 22 Jun 1993 13:26:55 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306221826.AA23983@stat1.cc.ukans.edu>
Subject: Re: launching executables through HTML files
To: www-talk@nxoc01.cern.ch
Date: Tue, 22 Jun 93 13:26:54 CDT
In-Reply-To: <9306200250.AA00157@wintermute.ncsa.uiuc.edu>; from "Marc Andreessen" at Jun 19, 93 9:50 pm
X-Mailer: ELM [version 2.3 PL2]

> 
> What's the current status on the idea of allowing hyperlinks in HTML
> documents to cause executables to be launched?  
> 
> Also, there was the idea that maybe executables should only be allowed
> to be launched from documents residing on the local host (not over
> ftp, http, or anything else).  This seems like a pretty much useless
> restriction with the current state and expansion of transparent
> networked filesystems, though.
> 


Most network file systems still appear to be local accesses so this IS
still a valid idea.  I think it is unreasonable to expect users to be
able to make reasonable judgements about how a particular command might
effect there system.  Do YOU really think that there is no one clever
enough to fool YOU with some cryptic UNIX trojan link.  The average
user isn't competant enough to tell whether some command will destroy
his system, therefore tight control should be exercised with this
link type.  Another issue is how can a single executable link be useful
on other systems?  Why should a machine specific link be usable across
the network?  We are playing with fire with this link type, I know this
from experience.

My suggestion would be to allow "exec:" type links to be run only if
the file that contains them resides on the local filesystem.  (physical,
NFS, AFS, etc.)  Or a file that resides on a trusted host. (in a list?)  
That way there is at least some sense of security.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Wed Jun 23 09:47:24 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18345; Wed, 23 Jun 93 09:47:26 MET DST
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18341; Wed, 23 Jun 93 09:47:24 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21459; Wed, 23 Jun 1993 10:10:31 +0200
Received: by xdm001 
	id AA20141; Wed, 23 Jun 93 09:10:27 +0100
Received: by xdm039 (5.57/4.7) id AA19481; Wed, 23 Jun 93 09:10:24 +0100
Message-Id: <9306230810.AA19481@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: launching executables through HTML files 
In-Reply-To: Your message of "Tue, 22 Jun 93 22:12:54 BST."
             <9306222112.AA11241@xdm001> 
Date: Wed, 23 Jun 93 09:10:21 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

> My suggestion would be to allow "exec:" type links to be run only if
> the file that contains them resides on the local filesystem.  (physical,
> NFS, AFS, etc.)  Or a file that resides on a trusted host. (in a list?)
> That way there is at least some sense of security.

Since when was AFS a "local" file system? I do not regard arbitrary
files in AFS as trustworthy in the least.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From daemon  Wed Jun 23 11:08:33 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19194; Wed, 23 Jun 93 11:08:35 MET DST
Return-Path: <cailliau@cernnext.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19190; Wed, 23 Jun 93 11:08:33 MET DST
Received: from www2.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09393; Wed, 23 Jun 1993 11:31:41 +0200
From: cailliau@cernnext.cern.ch
Received: by www2.cern.ch (NX5.67c/NX3.0S)
	id AA00717; Wed, 23 Jun 93 11:28:19 +0200
Date: Wed, 23 Jun 93 11:28:19 +0200
Message-Id: <9306230928.AA00717@www2.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: kevin@rs042.scic.intel.com, Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: link areas within images
Cc: www-talk@nxoc01.cern.ch

PLEASE

Can we have coordinates the way everyone does then, i.e. 0,0 is in  
the BOTTOM LEFT and 1,1 is at the TOP RIGHT.
PostScript works that way, maths work that way, etc.
ONLY for character grid personal computers is an inverted vertical  
axis used, so as to add a line space for each new line instead of  
having to subtract it. This was a frig, and I hope we can avoid  
repeating it.
---
Robert Cailliau  cailliau@cernnext.cern.ch
World-Wide Web Project
CERN -- European Laboratory for Particle Physics
CH-1211 Geneve 23 (Switzerland)
Tel. +41 22 767 5005

From daemon  Wed Jun 23 15:16:50 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23133; Wed, 23 Jun 93 15:16:54 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23126; Wed, 23 Jun 93 15:16:50 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA10963; Wed, 23 Jun 1993 15:39:58 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA00523; Wed, 23 Jun 93 15:38:31 +0200
Date: Wed, 23 Jun 93 15:38:31 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306231338.AA00523@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: paolo petta <paolo@venedig.ai.univie.ac.at>
Subject: Re: 2.07 and WAIS<->WWW *sources*?
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

From: paolo petta <paolo@venedig.ai.univie.ac.at>
>Date: Tue, 22 Jun 1993 00:31:44 +0200
>
>Versions 2.07 of the library and the line mode browser have been
>available at info.cern.ch for a couple of days now...
>
>My questions:
>
>1) will the sources be published, too?
>	(there are only the 2.06 right now...)

Yes, they are there .. but 2.09 is out in binary and that 

will be out in source soon too. See
<http://info.cern.ch/hypertext/WWW/Library/Features.html>
for changes between versions.

>2) does this version already include the WAIS-WWW gateway  
functionality?
>	(if I am not totally mistaken this was hinted at by TBL...)

Yes it does.  You just have to set compile options and
also link with the freeWAIS libraries.  Allows direct
WAIS access by WWW clients and allows your httpd to
function as a WAIS gateway. 



>paolo petta                                             
+43-1-5336112(Tel)

Tim Berners-Lee
CERN

From daemon  Wed Jun 23 17:38:22 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26777; Wed, 23 Jun 93 17:38:24 MET DST
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26772; Wed, 23 Jun 93 17:38:22 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12788; Wed, 23 Jun 1993 18:01:24 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA00730; Wed, 23 Jun 1993 12:01:18 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
	id AA15427; Wed, 23 Jun 1993 09:01:15 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
	id AA05476; Wed, 23 Jun 1993 09:02:36 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9306230902.ZM5474@cider.west.ora.com>
Date: Wed, 23 Jun 1993 09:02:36 -0700
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: www-talk@nxoc01.cern.ch
Subject: WWW Developer's Conference

So far we have about 15 people coming to the WWW Developer's
Conference, July 28 to July 30, 1993.  We will meet 9-5 on
those days at:

O'Reilly & Associates
90 Sherman Street 
Cambridge, MA 02140
617-354-5800

Here's the closest, cheapest hotel.  There are others
in Cambridge, of course, but this is fairly close to
the office.  The hotel is within walking distance (< 1/2 mile) of the
subway station (MBTA Red Line, Alewife Station).

Best Western Homestead
220 Alewife Parkway
Cambridge, MA  
(617) 491-8000

The rates I'm able to get for now:

$72 - single/night
$79 - double/night
$84 - triple/night

This rate is dependent on our reserving a block of rooms.
So, if you plan to stay at this hotel, please let me
know and we will take care of the reservations for
you.  

Thanks, 

Dale

-- 

Dale Dougherty 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

UUCP:	uunet!ora!dale     Internet :   dale@ora.com


From daemon  Wed Jun 23 19:56:41 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00290; Wed, 23 Jun 93 19:56:48 MET DST
Return-Path: <nop@theory.cs.mankato.msus.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00281; Wed, 23 Jun 93 19:56:41 MET DST
Received: from theory.CS.Mankato.MSUS.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11744; Wed, 23 Jun 1993 20:19:49 +0200
Received: by theory.cs.mankato.msus.edu (5.65/DEC-Ultrix/4.3)
	id AA00506; Wed, 23 Jun 1993 13:19:56 -0500
Date: Wed, 23 Jun 1993 13:19:56 -0500
From: nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
Message-Id: <9306231819.AA00506@theory.cs.mankato.msus.edu>
To: cailliau@cernnext.cern.ch
Cc: kevin@rs042.scic.intel.com, dsr@hplb.hpl.hp.com, www-talk@nxoc01.cern.ch
In-Reply-To: cailliau@cernnext.cern.ch's message of Wed, 23 Jun 93 11:28:19 +0200 <9306230928.AA00717@www2.cern.ch>
Subject: link areas within images

> Can we have coordinates the way everyone does then, i.e. 0,0 is in  
> the BOTTOM LEFT and 1,1 is at the TOP RIGHT.
> PostScript works that way, maths work that way, etc.

Of course, PostScript got this wrong in a lot of ways---for the
majority of users of PostScript, their language reads left to right,
top to bottom.  In particular, this causes problems when printing on
pages of different sizes.  You often see this when moving from A4 to
US Letter size, where things tend to get cut off because 0,0 is too
close to the bottom of the page.

Also note that much cruft was installed in Display PostScript to allow
flipped coordinate systems where 0,0 is top left.

I don't see this as a big issue, but most of the text we're likely to
have in the web reads top-to-bottom, so I don't wanna deal with
inverting coordinates a second time...

Jay Carlson
nop@theory.cs.mankato.msus.edu

Flat text is just *never* what you want.   ---stephen p spackman

From daemon  Wed Jun 23 20:44:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01606; Wed, 23 Jun 93 20:44:41 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01602; Wed, 23 Jun 93 20:44:39 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19429; Wed, 23 Jun 1993 21:07:47 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA01194; Wed, 23 Jun 93 21:06:09 +0200
Date: Wed, 23 Jun 93 21:06:09 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306231906.AA01194@www3.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: libwww 2.09: Executable documents and binary FTP


The just released incremental version of the WWW common
code library addresses two things recently discussed on
this list. One is the selection of the proper transfer mode
for FTP, and the other is how to make executable scripts.

The problem with FTP is that the client MUST select the
correct mode (Ascii or Image) wheras the server (presumably)
knows what the format is. The client guesses the content-type
from the file suffix.  It now also guesses the encoding
as well.  It will therefore select A for .txt files and I
for .Z files, and so get the right results even with
Macs and non-ASCII servers around.  The suffix table
can be set up in the client's rule file, if it is used with
one.

The executable scripts problem I viewed as another format
negotiation problem.  It is easier to set up the suffix table
and the command you want executed for given content types.
Its all in the rule file.  If you are rash enough to put in

   presentation   application/x-csh   "csh %s"

into your client rule file, then you can try out the
example script in the test data linked to the
test page ... 
http://www3.cern.ch/hypertext/WWW/Test/Executable/test1.execme.csh
if I remember rightly.

Obviously this is just a hook.  A script which previews it or
at least asks would be more reasonable.

I used application/x-csh rather than inventing exec/x-csh as I
think this is more in the MIME spirit.
The competition is obviously on for portable
1. safe scripting language for general use
2. timed presentation language (HyTime based?) for
   illustrated talks which give themselves.

I seem to have got off the topic of the release...
Other things...
Of course I would expect X clients to load rules from the
Xresource database too -- by calling HTSetConfiguration().
Similarly other platform-specific sources of initilisation
information.

Tim BL
CERN

From daemon  Wed Jun 23 21:08:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02215; Wed, 23 Jun 93 21:13:02 MET DST
Return-Path: <jim@zorro.njit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02102; Wed, 23 Jun 93 21:08:42 MET DST
Received: from zorro.njit.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22668; Wed, 23 Jun 1993 21:31:47 +0200
Message-Id: <9306231931.AA22668@dxmint.cern.ch>
Received: by zorro.njit.edu
	(15.11/15.6) id AA17402; Wed, 23 Jun 93 15:30:58 edt
Date: Wed, 23 Jun 93 15:30:58 edt
From: James Whitescarver <jim@zorro.njit.edu>
To: daemon@nxoc01.cern.ch, www-announce@nxoc01.cern.ch,
        www-talk@nxoc01.cern.ch
Subject: Re:  Central index of internet resources
Cc: jkp@cs.hut.fi, mengwong@pobox.upenn.edu, mory@athena.mit.edu



From daemon  Thu Jun 24 00:13:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06274; Thu, 24 Jun 93 00:13:49 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06268; Thu, 24 Jun 93 00:13:31 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19990; Thu, 24 Jun 1993 00:36:27 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11649>; Wed, 23 Jun 1993 15:35:16 PDT
Received: by holmes.parc.xerox.com id <16134>; Wed, 23 Jun 1993 15:35:05 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Wed, 23 Jun 1993 15:35:01 -0700 (PDT)
Message-Id: <0g_BeJsB0KGW0WlmtM@holmes.parc.xerox.com>
Date: 	Wed, 23 Jun 1993 15:35:01 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: kevin@rs042.scic.intel.com, Dave_Raggett <dsr@hplb.hpl.hp.com>,
        cailliau@cernnext.cern.ch
Subject: Re: link areas within images
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306230928.AA00717@www2.cern.ch>
References: <9306230928.AA00717@www2.cern.ch>

I agree with Robert's call for the more traditional lower-left-based
coordinate system, but feel obliged to point out that the X Window
System has 0,0 at the upper left.

Bill

From daemon  Thu Jun 24 01:21:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07145; Thu, 24 Jun 93 01:22:09 MET DST
Return-Path: <strata@hybrid.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA07140; Thu, 24 Jun 93 01:21:58 MET DST
Received: from hybrid.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27070; Thu, 24 Jun 1993 01:45:03 +0200
Received: by  hybrid.com (4.1/SMI-4.1)
	id AA05855; Wed, 23 Jun 93 16:41:42 PDT
Date: Wed, 23 Jun 93 16:41:42 PDT
From: strata@hybrid.com (M. Strata Rose (consultant))
Message-Id: <9306232341.AA05855@ hybrid.com>
To: www-talk@nxoc01.cern.ch
Subject: Internet Tools Search & Showcase
Cc: mobile-ip@parc.xerox.com, technomads@bikelab.corp.sun.com


I have just been asked to do a book proposal on the new generation of
Internet tools, those that depend on global connectivity and fairly
highspeed links.  I will be featuring browsers such as Mosaic, Xwais,
and Cello, and innovative audio/video/multimedia packages such as CUCME,
Netjam, MBONE multicasting, etc.  I am looking for pointers to programs
and applications, preferably in the public domain or shareware, that
are beginning to tap the promise of the Internet-- I would love to do
a chapter on collaboration and visualization tools such as the NCSA tools
and the EVL stuff, for instance.

I am also looking for pointers to the latest work in mobile and nomadic
computing; I have some info already but this is a very good place to ask. :-)

I would appreciate any pointers to new, interesting, or unusual Internet
applications that do browsing, audio or video (especially in realtime
or something quite like it), collaboration or shared work environments
without physical presence, and so on.  You get the idea.   I have a bit
of a list already, but I *know* there are things out there that I haven't
heard of yet.  Even if they're not going to be released until later in 
the year, or are still internal research projects at your university,
if it will be possible to ftp sources or binaries before January of 94
and start messing with it, I want to hear about it!  Here's your chance
at notoriety.  

I am turning in a preliminary list of chapters Friday by 5pm PST; this
will of course mutate wildly over the course of the book (I'm a realist,
even if this is my first book project) but the more things I can mention
the better chance it has of being approved.  I only need a brief synopsys
of your project to include a line or two about it in the proposal.  If
what you are developing has not been announced yet, please let me know
and I will note that, ie. "this tool is being developed at a large university
which shall remain nameless until the announcement in September".

I am not interested in commercial products at this time unless they
represent an extension or enhancement to public domain or shareware tools
(eg., the custom browser clients being developed by WAIS Inc).

Thanks for any info you can give me!  And to forestall the flood of
"I don't have anything to tell you about but really want your list"
letters, I *will* be posting a synopsys of said tools to the groups
who've received this message.

Cheers,
_Strata

M. Strata Rose
Unix & Network Consultant
Virtual City Project
strata@hybrid.com  *|*  strata@apple.com  *|*  strata@eddie.mit.edu


From daemon  Thu Jun 24 09:53:57 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12125; Thu, 24 Jun 93 09:54:00 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12121; Thu, 24 Jun 93 09:53:57 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04206; Thu, 24 Jun 1993 10:17:05 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Thu, 24 Jun 93 09:08:57 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA29086; Thu, 24 Jun 93 09:15:17 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306240815.AA29086@manuel.hpl.hp.com>
Subject:  Re: link areas within images
To: hoesel@chem.rug.nl
Date: Thu, 24 Jun 93 9:15:14 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> Is it too late to vote for non rectangular local(!) mouse support.
> I want to show a picture of the ruins of pompeii (shown from above at an
> angle of say 30 degree) and want people to be able to click on one off the
> wall of a building. The wall can be a line running at an arbritary angle
> over the screen,and could even be a bit irregular (around a chimney perhaps)

You are certainly not too late!

The current mechanism is uses the browser to recognise when the user
clicks with the mouse over an active region of the image/drawing:

<!-- Figure anchors designate rectangular areas on the
    figure which can be clicked with the mouse. The units
    are scaled from 0.0 to 1.0 for each axis. The default
    area is the whole of the figure. This mechanism
    interprets mouse clicks locally.
-->

<!ELEMENT FIGA - O (EMPTY)>
<!ATTLIST FIGA
    href    %URL;   #REQUIRED   -- link to traverse when clicked --
    x1      NUMBER  #IMPLIED    -- left in range 0 to 1 --
    y1      NUMBER  #IMPLIED    -- top in range 0 to 1 --
    x2      NUMBER  #IMPLIED    -- right in range 0 to 1 --
    y2      NUMBER  #IMPLIED    -- bottom in range 0 to 1 -->

To supported polygons as regions, we need a way of specifying a list of
points. The obvious way is as a comma separated list of numbers:

The following is a triangle: (0.2, 0.3) (0.23, 0.33) (0.15, 0.31)


        "0.2,0.3,0.23,0.33,0.15,0.31"  as  x1,y1,x2,y2,x3,y3,...

> some kind of highlight on the client site is needed, so if the user moves
> the mouse over the wall (the line) it lights up or something equivalent, so
> the user can see: 'he, this part of the wall does something, lets see it' or
> 'hmm this part af the wall is connected to the part on the other side of the
> chimney, and I have seen that already. lets skip this link'

As far as I can see, the browser can handle all this automatically, without
any need for additional information. It could even examine the URL associated
with each region to select a mouse cursor appropriate to the type of linked
information, e.g. musical notes for sound sequences.

The new version of FIGA would look like:

<!ELEMENT FIGA - O (EMPTY)>
<!ATTLIST FIGA
    href   %URL;    #REQUIRED   -- link to traverse when clicked --
    area   NUMBERS  #IMPLIED    -- x1,y1,x2,y2,x3,y3,... -->
    
The ISMAP mechanism with XMosaic's IMG tag gets the server to process mouse
clicks, and hence can offer greater flexibility than a static collection of
polygonal areas handled by the client, e.g. the active regions could vary
with time in shape and effect.

<!ELEMENT FIG - - (EMBED?, FIGA*, (%text;)*)>
<!ATTLIST FIG
    id      ID      #IMPLIED
    float  (float)  #IMPLIED -- fixed or floating figures --
    ismap  (ismap)  #IMPLIED -- mouse clicks handled by server --
    src     %URL;   #IMPLIED -- link to image data -->

The coordinates for clicks are measured in the same units as FIGA rather than
IMG's pixel values which can't cope with objects such as drawings for which
the pixel extent will vary from one browser to the next in an unpredictable
way.

Example:

    <fig ismap src="http://chem.rug.nl/geo/nl.gif">
        Major population centers in the Nederlands
    </fig>

A mouse click over a city is sent to the server as:

        "http://chem.rug.nl/geo/nl.gif?X,Y"

with X and Y replaced by numbers in the range from 0 to 1.

In theory authors could combine both techniques. Clicks over areas defined
with the FIGA tag are handled locally, while clicks over other parts of the
image are sent to the server.

Does this seem OK?

Dave Raggett

From daemon  Thu Jun 24 10:01:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12328; Thu, 24 Jun 93 10:02:00 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12324; Thu, 24 Jun 93 10:01:58 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05972; Thu, 24 Jun 1993 10:25:04 +0200
Received: by kauri.vuw.ac.nz id AA23887
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Thu, 24 Jun 1993 20:24:55 +1200
Date: Thu, 24 Jun 1993 20:24:55 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306240824.AA23887@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Simple access control

Which servers have the ability to deny connections based on hostname?
ie
	access	/local/*	*.nz	refuse
	host	/local/*	*	fail

would only allow *.nz access to anything in /local and everyone else
would be refused.

I ask, because it is a simple step to go from this to
	kdomain	/www/sensitive/budget/*	budget
	kdomain	/www/sensitive/staff/*	staff

to define kerberos demesne for files in various locations and do away
entirely with the hostname gumpf.

Nat.

From daemon  Thu Jun 24 11:35:29 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13632; Thu, 24 Jun 93 11:35:32 MET DST
Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13628; Thu, 24 Jun 93 11:35:29 MET DST
Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23485; Thu, 24 Jun 1993 11:58:37 +0200
Received: by xdm001 
	id AA16474; Thu, 24 Jun 93 10:58:32 +0100
Received: by xdm039 (5.57/4.7) id AA29949; Thu, 24 Jun 93 10:58:30 +0100
Message-Id: <9306240958.AA29949@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Re: link areas within images 
In-Reply-To: Your message of "Thu, 24 Jun 93 10:35:21 BST."
             <9306240935.AA16100@xdm001> 
Date: Thu, 24 Jun 93 10:58:28 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>

I've just played with Xerox PARCs world map, and been following the
discussion of hot spots with images, and arbitrary polygon hotspots.

It occurs to me to ask whether the various mechanisms described can
handle sending an arbitrary region of the image, e.g. could my broswer
permit me to draw an outline of the region (e.g. Europe on the world
map) I want, then send back a URL for map?X1,Y1+X2,Y2.

This seems to be a reasonable requirement, but I haven't seen it
explictly describe in the correspondence so far.

Peter Lister                                    p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From daemon  Thu Jun 24 12:34:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14547; Thu, 24 Jun 93 12:34:21 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14543; Thu, 24 Jun 93 12:34:19 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04212; Thu, 24 Jun 1993 12:57:28 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Thu, 24 Jun 93 11:30:12 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00571; Thu, 24 Jun 93 11:36:34 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306241036.AA00571@manuel.hpl.hp.com>
Subject: Re: link areas within images
To: cailliau@cernnext.cern.ch
Date: Thu, 24 Jun 93 11:36:32 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> PLEASE
> 
> Can we have coordinates the way everyone does then, i.e. 0,0 is in  
> the BOTTOM LEFT and 1,1 is at the TOP RIGHT.
> PostScript works that way, maths work that way, etc.
> ONLY for character grid personal computers is an inverted vertical  
> axis used, so as to add a line space for each new line instead of  
> having to subtract it. This was a frig, and I hope we can avoid  
> repeating it.

That sounds fine by me. Does anyone else think otherwise?

Dave


From daemon  Thu Jun 24 13:02:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15117; Thu, 24 Jun 93 13:02:44 MET DST
Return-Path: <guido@cwi.nl>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15113; Thu, 24 Jun 93 13:02:42 MET DST
Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08704; Thu, 24 Jun 1993 13:25:52 +0200
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
	id AA13018 (5.65b/3.8/CWI-Amsterdam); Thu, 24 Jun 1993 13:25:49 +0200
Received: by voorn.cwi.nl with SMTP
	id AA12514 (5.65b/3.8/CWI-Amsterdam); Thu, 24 Jun 1993 13:25:46 +0200
Message-Id: <9306241125.AA12514=guido@voorn.cwi.nl>
Subject: Re: link areas within images 
To: www-talk@nxoc01.cern.ch
X-Organization: CWI (Centrum voor Wiskunde en Informatica)
X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
Date: Thu, 24 Jun 1993 13:25:45 +0200
From: Guido van Rossum <Guido.van.Rossum@cwi.nl>

> > Can we have coordinates the way everyone does then, i.e. 0,0 is in  
> > the BOTTOM LEFT and 1,1 is at the TOP RIGHT.
> > PostScript works that way, maths work that way, etc.
> > ONLY for character grid personal computers is an inverted vertical  
> > axis used, so as to add a line space for each new line instead of  
> > having to subtract it. This was a frig, and I hope we can avoid  
> > repeating it.
> 
> That sounds fine by me. Does anyone else think otherwise?

It's not just character grid PCs, most bitmapped displays (e.g. X11,
Mac) do it it this way, too.  My choice would depend on the kind of
coordinate system to be used; if it were directly related to pixels,
let Y point down, but if you normalize to e.g. [0.0, 1.0] then Y would
best point up, in correspondence with standard graph conventions.
(Just trying to settle the argument with facts instead of personal
feelings...)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>

From daemon  Thu Jun 24 15:04:14 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17476; Thu, 24 Jun 93 15:04:17 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17472; Thu, 24 Jun 93 15:04:14 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02004; Thu, 24 Jun 1993 15:27:24 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02490; Thu, 24 Jun 93 15:25:55 +0200
Date: Thu, 24 Jun 93 15:25:55 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306241325.AA02490@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: "Peter Lister,
     Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Subject: Re: How can one use '#' in a URL? 
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>Date: Fri, 18 Jun 93 15:41:47 BST
>From: "Peter Lister, Cranfield Computer Centre"  
<ccprl@xdm001.ccc.cranfield.ac.uk>
>
>>    I don't think this is correct.  Any url can make use of the #  
directive.
>> It just tells a browser to go to a specific part of a document  
instead of
>> to the beginning.  I don't know of any browsers that actually  
'generate'
>> these internally.
>
>Misunderstanding. I mean to say that I don't know how or whether
>servers will react to # in a URL; as far as I am aware, browsers  
simply
>react to them when they see them in an HTML file. 


The # is a delimiter which separates the opaque part of the
URL which is passed to the server from the opaque part of
the URL which is passed to the displaying application.
There is no way you can pass a URL containing # to a server,
as that is precicely what it does not mean.

If you want to make a special world around tar files, then
do, but use valid characters. If you want to avoid using
things which might crop up in the file names, then the %
character is there which with non hex characters gives
all sorts of combinations -- like %/ mentioned before to
mean "interpret that which is on the left with respect to
that which is on the left".  You could use this for
tar files too, in your server:

	/docs/foo.tar%/bar.c		extraction
	/docs/foo.tar%L			listing
	/docs/foo.tar%LR		deep listing
	/docs/foo.tar			the file itself

for example.  Remember that this string will be passed
straight to the server and the client is not allowed
to interpret it at all. The bit to the right of the #
is the reverse: it is never passed to the server,
only the client (the presentation app) can interpret it.


>Further, is a null search term significant or not? Is "foo?"  
equivalent
>to "foo". I would personally hope NOT, as a null default search term
>could be useful (e.g. to return a catalogue).

They are different.  Some servers return the same thing for the
two different URLs.  I am not sure which browsers actually support
an empty search string. I agreee it is logical to do so.  You should
NOT assume any convenmtion for what it means. For example,
if the server ANDs its terms, you might expect he catalogue, while
if it ORs them you would expect nothing back.  If you want to
make the catlogue available, it is MUCH better to make a link
to it from the index cover page.

Tim BL

>Peter
>
>

From daemon  Thu Jun 24 15:16:48 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17925; Thu, 24 Jun 93 15:16:50 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17920; Thu, 24 Jun 93 15:16:48 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05577; Thu, 24 Jun 1993 15:39:56 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02600; Thu, 24 Jun 93 15:38:28 +0200
Date: Thu, 24 Jun 93 15:38:28 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306241338.AA02600@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Campus-Wide Information Systems <CWIS-L%WUVMD.BITNET@cearn.bitnet>
Subject: WWW access to Hytelnet 6.5 now available
Cc: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch,
        aa375@freenet.carleton.ca
Reply-To: timbl@nxoc01.cern.ch


The latest Hytelnet database is available on the web. Point
any W3 browser (Cello, Mosaic, tkWWW, MacWeb, etc etc) at
http://info.cern.ch.:8002/w3start.txt
or follow links to "Servers by type" and chose "Telnet".
It's also in the Mosaic "documents" menu.

Here are details of the changes from Peter Scott:

			---------------------
			
HYTELNET version 6.5, the database which gives an WWW user
instant-access to all Internet-accessible library catalogs,
FREE-NETS, CWISs, BBSs, Gophers, WAIS, etc. is now available. 


Version 6.5 is a major upgrade. Much redundant information has been
deleted, and errors have been corrected. Also all the new/updated
files created since Version 6.4 have been incorporated.
Certain files have been renamed to match their domain names.

[...]
Peter Scott
National Capital FreeNet
aa375@freenet.carleton.ca


From daemon  Thu Jun 24 16:14:24 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19846; Thu, 24 Jun 93 16:14:26 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19842; Thu, 24 Jun 93 16:14:24 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18477; Thu, 24 Jun 1993 16:37:34 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA24120; Thu, 24 Jun 1993 09:36:30 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306241436.AA24120@stat1.cc.ukans.edu>
Subject: Re: Internet Tools Search & Showcase
To: strata@hybrid.com (M. Strata Rose (consultant))
Date: Thu, 24 Jun 93 9:36:30 CDT
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306232341.AA05855@ hybrid.com>; from "M. Strata Rose (consultant)" at Jun 23, 93 4:41 pm
X-Mailer: ELM [version 2.3 PL2]

> 
> 
> I have just been asked to do a book proposal on the new generation of
> Internet tools, those that depend on global connectivity and fairly
> highspeed links.  I will be featuring browsers such as Mosaic, Xwais,
> and Cello, and innovative audio/video/multimedia packages such as CUCME,
> Netjam, MBONE multicasting, etc.  I am looking for pointers to programs
> and applications, preferably in the public domain or shareware, that
> are beginning to tap the promise of the Internet-- I would love to do
> a chapter on collaboration and visualization tools such as the NCSA tools
> and the EVL stuff, for instance.
> 
What about us poor lowly VT100 developers.  Those GUI people get all
the glory :)

:lou

From daemon  Thu Jun 24 17:15:48 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21501; Thu, 24 Jun 93 17:15:50 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21497; Thu, 24 Jun 93 17:15:48 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02008; Thu, 24 Jun 1993 17:38:48 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA18049; Thu, 24 Jun 93 10:38:17 -0500
Message-Id: <9306241538.AA18049@austin.BSDI.COM>
To: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: link areas within images 
In-Reply-To: "Peter Lister, Cranfield Computer Centre"'s message of Thu, 24 Jun 93 10:58:28 BST.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 24 Jun 1993 10:38:16 -0500
From: Tony Sanders <sanders@bsdi.com>

I would like to see this also, exactly as peter described it (using
+ to seperate each x,y pair).  What we really need to define are the
semantics for the browser ISMAP="point" rect poly???  I'm not sure how
to do this in a generic way (do we also need "sound" "video"??).
Maybe instead of telling the browser the type of selection the browser
should tell the server:  http://server/europe?poly+x,y+x,y...

But maybe the ISMAP should still have a hint about what's expected?

> I've just played with Xerox PARCs world map, and been following the
> discussion of hot spots with images, and arbitrary polygon hotspots.
> 
> It occurs to me to ask whether the various mechanisms described can
> handle sending an arbitrary region of the image, e.g. could my broswer
> permit me to draw an outline of the region (e.g. Europe on the world
> map) I want, then send back a URL for map?X1,Y1+X2,Y2.
> 
> This seems to be a reasonable requirement, but I haven't seen it
> explictly describe in the correspondence so far.
> 
> Peter Lister                                    p.lister@cranfield.ac.uk
> Computer Centre,
> Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
> Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875

From daemon  Thu Jun 24 19:09:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24159; Thu, 24 Jun 93 19:09:33 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24155; Thu, 24 Jun 93 19:09:31 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24205; Thu, 24 Jun 1993 19:32:37 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA18786; Thu, 24 Jun 93 12:32:35 -0500
Message-Id: <9306241732.AA18786@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Simple access control 
In-Reply-To: Nathan Torkington's message of Thu, 24 Jun 93 20:24:55 +1200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 24 Jun 1993 12:32:35 -0500
From: Tony Sanders <sanders@bsdi.com>

> Which servers have the ability to deny connections based on hostname?

Actually, Plexus has something like this but it was just a quick hack
to play around with (it uses IP numbers right now, like I said it was
just a quick hack).

It's http://www.bsdi.com/server/account.pl if anyone wants to play around
with it and make it work right.

>>>>>>>

While I'm at it I'll announce Plexus 2.2-Beta which can be had from
ftp://austin.bsdi.com/pub/Plexus-2.2-beta.tar.Z		(old tar format)
ftp://austin.bsdi.com/pub/Plexus-2.2-beta.pax.Z		(new ustar format)

I'm running this on www.bsdi.com now and it seems to be doing just fine.
Notable changes are image decoding is much better (you just define a
configuration file *and* it supports rectangles, thanks to Chris McRae
for doing this).  Also, Plexus 2.2-beta is ready to support format
negotiation, I include a setext -> HTML converter (it currently doesn't
negotiate, it just converts).  It still needs work in this area but it
should be pretty easy to add new converters.

Let me know soon if you have any problems, I'll be releasing it soon.

I really think you'll like the new image decoding stuff that Chris did,
it's quite easy to add image decoding now.

Changes to Plexus from Previous Versions
========================================

Plexus 2.2
----------

* added support for document translation (lots of changes in dir.pl)
* added setext.pl to convert from setext (.etx) to HTML
* added better image decoding support thanks to Chris McRae
  <mcrae@ckm.ucsf.edu>.  You can now specify image decoding
  in a configuration file ($MAP_CONFIG_FILE) and you can use
  bitmasks or rectangles.  In most cases you don't have to write
  any code!  Things like bookmark are more complicated and still
  require code, but few things really need that.
* &send_file went away and was replaced with: &wrap_file, &wrap_fd,
  &raw_file, &raw_fd.   &require is certainly the only stable
  interface at this point (though I don't see &raw_fd changing again).
  &wrap_* will probably have to change again to make file translations
  work "right".
* added support for hypertext'ed man pages from pre-formatted files.
  In this initial release they are specific to bsdi man pages
  but should be easy to configure for your local system (most of the
  config options are at the top of the bsdi-man.pl file).
* added some log file summerizing scripts

--sanders

From daemon  Thu Jun 24 19:23:06 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24474; Thu, 24 Jun 93 19:23:08 MET DST
Return-Path: <kevin@scic.intel.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24468; Thu, 24 Jun 93 19:23:06 MET DST
Received: from ssd.intel.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26836; Thu, 24 Jun 1993 19:46:15 +0200
Received: from sv002.scic.intel.com by SSD.intel.com (4.1/SMI-4.1)
	id AA29013; Thu, 24 Jun 93 10:46:11 PDT
Received: from rs042.scic.intel.com by sv002.scic.intel.com (4.1/SCICX.1.11); Thu, 24 Jun 93 10:46:10 PDT
Received: from mc024.scic.intel.com by rs042.scic.intel.com (AIX 3.2/UCB 5.64/SCICI.1.11); Thu, 24 Jun 1993 10:46:07 -0700
Message-Id: <9306241746.AA20854@rs042.scic.intel.com>
Date: Thu, 24 Jun 1993 10:44:59 -0800
To: www-talk@nxoc01.cern.ch
From: kevin@scic.intel.com (Kevin Altis)
X-Sender: kevin@rs042.scic.intel.com
Subject: Re: link areas within images

>I agree with Robert's call for the more traditional lower-left-based
>coordinate system, but feel obliged to point out that the X Window
>System has 0,0 at the upper left.

Since, this issue doesn't want to die, I vote for staying with "0,0" at the
top,left. Except for PostScript, that is the common usage within character
based and bitmap based displays. Diverging from this practice now will
require extra transformations to the local text and graphics environments.
PostScript can be confusing sometimes because of the 0,0 at the bottom,
left. Think about large objects that span pages and arbitrary scaling of
objects where the "anchor" is typically at the top left of the object, not
at the bottom left. Even in the simplest cases, where there isn't a "page
boundary", drawing occurs from the top left, then down the virtual page,
with scrollbars added if needed. With Hebrew, Arabic, Kanji, etc. which
read right to left, you still start at the top of the page.

It would be possible to put "0,0" at some arbitrary location within an
image, like the center of the image so that you have the image overlayed on
a "normal" cartesian coordinate system. It requires a transformation as
simple as putting "0,0" at the bottom left, plus defining where you want
"0,0" and whether you want positive y to go up or down, prior to
referencing any images.

ka


From daemon  Thu Jun 24 19:26:00 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24546; Thu, 24 Jun 93 19:26:02 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA24542; Thu, 24 Jun 93 19:26:00 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27027; Thu, 24 Jun 1993 19:49:10 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576697-3>; Thu, 24 Jun 1993 13:49:04 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA09053; Thu, 24 Jun 93 13:38:31 EDT
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306241738.AA09053@begbick.law.cornell.edu.law.cornell.edu>
Subject: Cello Beta 0.5 out.
To: www-talk@nxoc01.cern.ch, teknoids@fatty.law.cornell.edu,
        cello-l@fatty.law.cornell.edu
Date: Thu, 24 Jun 1993 13:38:30 -0400
X-Mailer: ELM [version 2.2 PL15]

Folks:

Cello Beta version 0.5 is hereby shoved out the door.

Improvements:

Cello now supports the use of a mail relay host for the mailing
feature (thanks to several Alert Cellists).  Use Configure/Mail relay
to set this up.

Minor performance improvements have been made in the Telnet feature
(on the order of 20% in speed, depending on what you're doing).
(Thanks to Developer Guilt)

rlogin:// URLs are now supported by mapping them to telnet.
(Thanks to Alert Cellist Lou Montulli)

FTP directories now show a link which permits a move to the parent
directory.
(Thanks to an Alert Cellist whose mail message got trashed by me
before this got written up...you know who you are).

Along the way a few GPF problems and other assorted trash got fixed,
but in some cases I could not duplicate problems reported by Alert
Cellists.  While I appreciate receiving Doctor Watson logs and the
like when problems occur -- they really _are_ helpful -- it is also
very useful (and sometimes vital) for you to include a URL for the
resource you were trying to access when whatever problem occurred.  In
the case of GPF's which occur on exit, these can be fiendish to track
down, but some idea of what you were doing immediately prior to
exiting is useful.

Regards,
Tb.
-- 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Thu Jun 24 19:59:03 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25293; Thu, 24 Jun 93 19:59:07 MET DST
Return-Path: <brian@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25285; Thu, 24 Jun 93 19:59:03 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04788; Thu, 24 Jun 1993 20:22:11 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA09624; Thu, 24 Jun 93 13:21:53 -0500
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA27832; Thu, 24 Jun 93 11:16:30 PDT
Date: Thu, 24 Jun 93 11:16:30 PDT
From: brian@eitech.com (Brian Smithson)
Message-Id: <9306241816.AA27832@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: link areas within images

The notion that 0,0 at lower,left is "more traditional" is most valid for
paper pages, not for scrollable pages.  Computer displays are more often
oriented to top,left.  This may be due in part to the direction of raster
scanning, but I think that it has more to do with the notion of scrolling
where the bottom is in a sense undefined.  Let's keep 0,0 at top,left.

From daemon  Thu Jun 24 21:21:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27400; Thu, 24 Jun 93 21:21:21 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27395; Thu, 24 Jun 93 21:21:19 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24439; Thu, 24 Jun 1993 21:44:27 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA19272; Thu, 24 Jun 93 14:44:23 -0500
Message-Id: <9306241944.AA19272@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: link areas within images 
In-Reply-To: Your message of Thu, 24 Jun 93 10:44:59 -0800.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 24 Jun 1993 14:44:23 -0500
From: Tony Sanders <sanders@bsdi.com>

> It would be possible to put "0,0" at some arbitrary location within an
> image, like the center of the image so that you have the image overlayed on
> a "normal" cartesian coordinate system. It requires a transformation as
> simple as putting "0,0" at the bottom left, plus defining where you want
> "0,0" and whether you want positive y to go up or down, prior to
> referencing any images.

Hey, we could put 0,0 at the center and return polar coordinates. :-)
Or, we could map the image onto a 4D manifold...

I vote we let Dave pick one out of a hat and get it over with or start
start a seperate list (origin-tl-or-bl@whocares.com :-).  Maybe
alt.religion.computers is the best place to take this up.

--sanders

From daemon  Thu Jun 24 22:14:55 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28567; Thu, 24 Jun 93 22:14:57 MET DST
Return-Path: <brian@eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28563; Thu, 24 Jun 93 22:14:55 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06739; Thu, 24 Jun 1993 22:38:05 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA10599; Thu, 24 Jun 93 15:37:47 -0500
Received: from hewey.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA28321; Thu, 24 Jun 93 13:32:11 PDT
Date: Thu, 24 Jun 93 13:32:11 PDT
From: brian@eitech.com (Brian Smithson)
Message-Id: <9306242032.AA28321@eitech.com>
To: www-talk@nxoc01.cern.ch
Subject: Re: link areas within images


> Maybe
> alt.religion.computers is the best place to take this up.

Don't you mean "talk.origins"? :-)

From daemon  Fri Jun 25 00:04:30 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00461; Fri, 25 Jun 93 00:04:32 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00457; Fri, 25 Jun 93 00:04:30 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26982; Fri, 25 Jun 1993 00:27:41 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA23305; Thu, 24 Jun 1993 17:26:37 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306242226.AA23305@stat1.cc.ukans.edu>
Subject: direct WAIS in Lynx
To: www-talk@nxoc01.cern.ch
Date: Thu, 24 Jun 93 17:26:37 CDT
X-Mailer: ELM [version 2.3 PL2]

I've been porting Lynx to the 2.09 WWW library and adding the direct
WAIS modules.  My question is what is the best WAIS distribution to
use.  I downloaded wais-8-b5 and am having alot of compile troubles.
Is there another "free" WAIS that I should be using?  Is 8-b5 free
WAIS or is it the distribution that thinking machines distributes?

Another thing, is it a good idea to include the wais distribution
in the Lynx distribution for ease of installation?  Are there any
copywrite issues involved here?  

It looks like this isn't going to work on alot of machines anyways 
since WAIS requires an ANSI C compiler.

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Fri Jun 25 00:13:04 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00574; Fri, 25 Jun 93 00:13:07 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00569; Fri, 25 Jun 93 00:13:04 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01216; Fri, 25 Jun 1993 00:36:15 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28282
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 24 Jun 93 17:36:12 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA11814; Thu, 24 Jun 93 17:38:56 -0500
Date: Thu, 24 Jun 93 17:38:56 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306242238.AA11814@wintermute.ncsa.uiuc.edu>
To: montulli@stat1.cc.ukans.edu (Lou Montulli)
Cc: www-talk@nxoc01.cern.ch
Subject: direct WAIS in Lynx
In-Reply-To: <9306242226.AA23305@stat1.cc.ukans.edu>
References: <9306242226.AA23305@stat1.cc.ukans.edu>
X-Md4-Signature: 997be64f662f5d5fa7a76a402c41e2e2

Lou Montulli writes:
> I've been porting Lynx to the 2.09 WWW library and adding the direct
> WAIS modules.  My question is what is the best WAIS distribution to
> use.  I downloaded wais-8-b5 and am having alot of compile troubles.
> Is there another "free" WAIS that I should be using?  Is 8-b5 free
> WAIS or is it the distribution that thinking machines distributes?

"free WAIS" == "freeWAIS 0.1" == CNIDR's packaging of "normal WAIS"
(from Thinking Machines) with lots of user-contributed fixes [boolean
searching, etc.] == the predecessor of freeWAIS 1.0, CNIDR's Mother of
all WAIS's and Z39.50-92 engine.  The FTP site is sunsite.unc.edu.

> It looks like this isn't going to work on alot of machines anyways 
> since WAIS requires an ANSI C compiler.

GCC...

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Fri Jun 25 00:26:06 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00770; Fri, 25 Jun 93 00:26:08 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00766; Fri, 25 Jun 93 00:26:06 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01708; Fri, 25 Jun 1993 00:49:13 +0200
Received: by kauri.vuw.ac.nz id AA13849
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Fri, 25 Jun 1993 10:49:09 +1200
Date: Fri, 25 Jun 1993 10:49:09 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306242249.AA13849@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: CERN 2.06 rules

How the heck do I get the daemon to map everything onto /usr/local/www
*and* everything ending in / to */home.html.  I've tried:
	map /* /usr/local/www/*
and	map */ */home.html

and the first line works, but the second doesn't.  Help?

Nat

From daemon  Fri Jun 25 00:28:03 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00810; Fri, 25 Jun 93 00:28:04 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00806; Fri, 25 Jun 93 00:28:03 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03007; Fri, 25 Jun 1993 00:51:09 +0200
Received: by kauri.vuw.ac.nz id AA13949
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Fri, 25 Jun 1993 10:51:04 +1200
Date: Fri, 25 Jun 1993 10:51:04 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306242251.AA13949@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Marc Andreessen's message <9306242238.AA11814@wintermute.ncsa.uiuc.edu>
Subject: direct WAIS in Lynx

freeWAIS is good ('tho the X stuff still has bugs, damnit).  I would
*not* include the source in your distribution.  Include a message
saying the libraries you need, and where to find the source for them,
but don't include the code yourself -- many of us already have
freeWAIS and don't want to drag it over an expensive link again.

Nat

From daemon  Fri Jun 25 00:35:07 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00945; Fri, 25 Jun 93 00:35:09 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00941; Fri, 25 Jun 93 00:35:07 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA06042; Fri, 25 Jun 1993 00:58:15 +0200
Received: by kauri.vuw.ac.nz id AA14189
  (5.65c/IDA-1.4.4 for www-talk@info.cern.ch); Fri, 25 Jun 1993 10:58:09 +1200
Date: Fri, 25 Jun 1993 10:58:09 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306242258.AA14189@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: #WWW on IRC

What I thought would be really valuable is a WWW developers (possibly
and users) BBS, telnettable to.  That way the conversation could be
subdivided into topics (``boards'' for Clients, Mosaic, Servers, CERN
Code, WAIS, Getting Started, SGML-flamage, &c.).  The site to set this
up would need to be well connected, though (hint hint :-).

A problem I find with the mailing list is that *everything* is here,
which is not necessarily a good thing :).  I delete more than I read,
and it takes a while for the mail to get through.

As an interim idea, why not use IRC to communicate informally?  I'll
join #WWW on IRC whenever I'm on, and if there's sufficient interest,
I'll look into writing a 'bot to serve files, maybe even access the
web.  Someone with a less crappy connection to the backbone might be
able to run the 'bot if it gets going.

Feedback?  Abuse?  See you on IRC?

Nat.

From daemon  Fri Jun 25 00:45:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01138; Fri, 25 Jun 93 00:45:44 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01134; Fri, 25 Jun 93 00:45:42 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08491; Fri, 25 Jun 1993 01:08:53 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA14757; Thu, 24 Jun 1993 18:07:55 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306242307.AA14757@stat1.cc.ukans.edu>
Subject: Re: #WWW on IRC
To: www-talk@nxoc01.cern.ch
Date: Thu, 24 Jun 93 18:07:55 CDT
In-Reply-To: <199306242258.AA14189@kauri.vuw.ac.nz>; from "Nathan Torkington" at Jun 25, 93 10:58 am
X-Mailer: ELM [version 2.3 PL2]

> 
> What I thought would be really valuable is a WWW developers (possibly
> and users) BBS, telnettable to.  That way the conversation could be
> subdivided into topics (``boards'' for Clients, Mosaic, Servers, CERN
> Code, WAIS, Getting Started, SGML-flamage, &c.).  The site to set this
> up would need to be well connected, though (hint hint :-).
> 
> A problem I find with the mailing list is that *everything* is here,
> which is not necessarily a good thing :).  I delete more than I read,
> and it takes a while for the mail to get through.
> 
> As an interim idea, why not use IRC to communicate informally?  I'll
> join #WWW on IRC whenever I'm on, and if there's sufficient interest,
> I'll look into writing a 'bot to serve files, maybe even access the
> web.  Someone with a less crappy connection to the backbone might be
> able to run the 'bot if it gets going.
> 
> Feedback?  Abuse?  See you on IRC?
> 
> Nat.

NO No No No NO!  Sub-division of the list maybe, but IRC NEVER!
Couldn't we come up with a Web based solution for this?  After all
we are writing Web clients! 

:lou
-BTW don't you think that the time differences between our continents
might be a problem for live discussions.  Oh yeah, I forgot, developers 
work 24 hours a day, who has time to sleep :-)
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Fri Jun 25 01:06:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01391; Fri, 25 Jun 93 01:06:13 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01386; Fri, 25 Jun 93 01:06:12 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11268; Fri, 25 Jun 1993 01:29:14 +0200
Received: by kauri.vuw.ac.nz id AA15448
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 25 Jun 1993 11:29:08 +1200
Date: Fri, 25 Jun 1993 11:29:08 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306242329.AA15448@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Lou Montulli's message <9306242307.AA14757@stat1.cc.ukans.edu>
Subject: Re: #WWW on IRC

Lou Montulli writes:

> NO No No No NO!  Sub-division of the list maybe, but IRC NEVER!

Hmm, ircaphobe? :)

> Couldn't we come up with a Web based solution for this?  After all
> we are writing Web clients! 

It would require a PUT method, and possibly authorisation, both of
which are lacking at the moment :)

> -BTW don't you think that the time differences between our continents
> might be a problem for live discussions.  Oh yeah, I forgot, developers 
> work 24 hours a day, who has time to sleep :-)

Not everyone needs to be on at the same time for informal discussions
-- for instance, your question about WAIS could have been answered by
me, likewise my query about the 2.06 distribution could have been
answered by saying ``fool, it was *fixed* in the 2.06 distribution''
:-).  Some things, net face-to-face would be nice for.

Nat.

From daemon  Fri Jun 25 01:15:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01495; Fri, 25 Jun 93 01:15:58 MET DST
Return-Path: <mitra@pandora.sf.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01491; Fri, 25 Jun 93 01:15:56 MET DST
Received: from pandora.sf.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16130; Fri, 25 Jun 1993 01:39:06 +0200
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: Re: #WWW on IRC
Organization: Pandora Systems
Date: Thu, 24 Jun 1993 23:38:57 GMT
Message-Id: <C95GCx.9pz@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.2 PL0]
References: <9306242307.AA14757@stat1.cc.ukans.edu>
Apparently-To: <www-talk@nxoc01.cern.ch>

Since many of us read this group ported to a newsgroup, why not just
subdivide the newsgroup.   comp.infosystems.www.mosaic and so on. 

- Mitra


From daemon  Fri Jun 25 02:29:06 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02542; Fri, 25 Jun 93 02:29:17 MET DST
Return-Path: <janssen@parc.xerox.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02536; Fri, 25 Jun 93 02:29:06 MET DST
Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AB01417; Fri, 25 Jun 1993 02:52:17 +0200
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11718>; Thu, 24 Jun 1993 17:51:52 PDT
Received: by holmes.parc.xerox.com id <16134>; Thu, 24 Jun 1993 17:51:47 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
          via MS.5.6.holmes.parc.xerox.com.sun4_41;
          Thu, 24 Jun 1993 17:51:33 -0700 (PDT)
Message-Id: <8g_YkJcB0KGWIWlo9f@holmes.parc.xerox.com>
Date: 	Thu, 24 Jun 1993 17:51:33 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: www-talk@nxoc01.cern.ch, Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Subject: Re: #WWW on IRC
In-Reply-To: <199306242258.AA14189@kauri.vuw.ac.nz>
References: <199306242258.AA14189@kauri.vuw.ac.nz>

Excerpts from ext.WorldWideWeb: 24-Jun-93 #WWW on IRC Nathan
Torkington@vuw.ac (887)

> As an interim idea, why not use IRC to communicate informally?

Or maybe even a MUD?

Bill

From daemon  Fri Jun 25 02:36:54 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02638; Fri, 25 Jun 93 02:36:56 MET DST
Return-Path: <chrisf@sour.sw.oz.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02634; Fri, 25 Jun 93 02:36:54 MET DST
Received: from joyce.cs.su.OZ.AU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01590; Fri, 25 Jun 1993 02:59:50 +0200
Received: from sour.sw.oz.au (for nxoc01.cern.ch) with MHSnet;
	Fri, 25 Jun 1993 10:59:40 +1000
Received: from sour.sw.oz.au by swift.sw.oz.au with SMTP
	id AA16228; Fri, 25 Jun 93 10:58:44 AES (5.59)
	(from chrisf@sour.sw.oz.au for www-talk@nxoc01.cern.ch)
Received: by sour.sw.oz.au
	id AA27421; Fri, 25 Jun 1993 10:58:38 +1000 (5.65c/1.34)
	(from chrisf@sour.sw.oz.au for www-talk@nxoc01.cern.ch)
From: chrisf@sour.sw.oz.au (Christopher Fraser)
Message-Id: <199306250058.AA27421@sour.sw.oz.au>
Subject: Re: launching executables through HTML files
To: www-talk@nxoc01.cern.ch
Date: Fri, 25 Jun 1993 10:58:37 +1000 (EST)
Return-Receipt-To: chrisf@suite.sw.oz.au
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 4394      


(This is a repost; I think the previous one got lost.)

But I thought Lou Montulli said:
> 
> > 
> > What's the current status on the idea of allowing hyperlinks in HTML
> > documents to cause executables to be launched?  
> > 
> > Also, there was the idea that maybe executables should only be allowed
> > to be launched from documents residing on the local host (not over
> > ftp, http, or anything else).  This seems like a pretty much useless
> > restriction with the current state and expansion of transparent
> > networked filesystems, though.
> > 
> 
> 
> Most network file systems still appear to be local accesses so this IS
> still a valid idea.  I think it is unreasonable to expect users to be
> able to make reasonable judgements about how a particular command might
> effect there system.  Do YOU really think that there is no one clever
> enough to fool YOU with some cryptic UNIX trojan link.  The average
> user isn't competant enough to tell whether some command will destroy
> his system, therefore tight control should be exercised with this
> link type.  Another issue is how can a single executable link be useful
> on other systems?  Why should a machine specific link be usable across
> the network?  We are playing with fire with this link type, I know this
> from experience.
> 
> My suggestion would be to allow "exec:" type links to be run only if
> the file that contains them resides on the local filesystem.  (physical,
> NFS, AFS, etc.)  Or a file that resides on a trusted host. (in a list?)  
> That way there is at least some sense of security.
> 

I think the problem with the current suggestions is that they rely on the
server suppling pathnames to commands. Firstly, the namespace on a machine is
particularly machine and configuration specifc; relying on a command to be in
particular directory is a bit tenuous. Secondly, we want the user and site
webmaster to be able to configure the way the commands are run.

A much better approach, IMHO, is to have a symbolic command
name which is mapped to a particular command by the browser (client, whatever
the correct terminology is). For example:

  exec:text-edit%/etc/passwd

The browser has some default mapping for text-edit, (eg: using the EDITOR 
environment variable in an xterm), however the user can override this if they
like (eg: if DISPLAY is set, and EDITOR is emacsclient, don't bother with
the xterm). If there is no mapping for the command name, some sort of requestor
thing is popped up. There is certainly scope to fetch the mapping information
from some remote server, but ultimately it's up to the browser to interpret
the command.

You should be able to pass arguments in some manner, eg: everything
after the percent or something similar It should be up to the
command to check for tainted/invalid arguments. I'd imagine most of the
commands would be shell scripts which assemble a command line and exec
it (Macs and PC's would have some sort of analouge).

Normally the browser should wait for the command to finish (report the exit
status if nonzero etc) however it would be cute to also have a mechanism
whereby the browser creates a pipe, and then runs the command with
stdin/stdout attached to the other end of the pipe. The browser then talks
http to the command across the pipe. The namespace of the command would
be something like:

  local:pid/

When the last page onto the command's namespace was closed, the command would
be killed (SIGHUP, or some additional http construct).

Now, why would we want to do this? Well, there are situations I see where it's
adventageous to keep state at the remote end of a http connection. For example,
you want to browse the contents of a compressed tar file, the command would
unpack it somewhere, when it started up and delete it when it exited. Keeping
state as the remote end is exactly the sort of thing you want to avoid across
network connections, but for local commands it's fine.

Appologies if I'm reiterating what has alreday been said ... Incidently, when
people have something new and interestign which is W3 related, please don't
just post the http address, some of us only have netfile ftp access to outside
world.  

Cheers,
--
Christopher Fraser              ``Insult is the lowest form of flattery''
chrisf@sw.oz.au 

Cheers,
--
Christopher Fraser              ``Insult is the lowest form of flattery''
chrisf@sw.oz.au 


From daemon  Fri Jun 25 02:39:20 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02688; Fri, 25 Jun 93 02:39:22 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02684; Fri, 25 Jun 93 02:39:20 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01719; Fri, 25 Jun 1993 03:02:31 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA04863
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 24 Jun 93 20:01:56 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:Nathan.Torkington@vuw.ac.nz id AA12174; Thu, 24 Jun 93 20:04:40 -0500
Date: Thu, 24 Jun 93 20:04:40 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306250104.AA12174@wintermute.ncsa.uiuc.edu>
To: Bill Janssen <janssen@parc.xerox.com>
Cc: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>, www-talk@nxoc01.cern.ch,
        chouck@ncsa.uiuc.edu
Subject: Re: #WWW on IRC
In-Reply-To: <8g_YkJcB0KGWIWlo9f@holmes.parc.xerox.com>
References: <199306242258.AA14189@kauri.vuw.ac.nz>
	<8g_YkJcB0KGWIWlo9f@holmes.parc.xerox.com>
X-Md4-Signature: 5e36a251a9fe8923c97e4e8e786bfdb9

Bill Janssen writes:
> Excerpts from ext.WorldWideWeb: 24-Jun-93 #WWW on IRC Nathan
> Torkington@vuw.ac (887)
> 
> > As an interim idea, why not use IRC to communicate informally?
> 
> Or maybe even a MUD?

Actually, I kinda like that idea.  Particularly since there are now a
number of Muds that have pretty nicely integrated Web & Gopher
servers, and (at least) Gopher clients.  Hmmmmmm...

Marc


From daemon  Fri Jun 25 04:05:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03541; Fri, 25 Jun 93 04:05:59 MET DST
Return-Path: <wmperry@strawberry.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03537; Fri, 25 Jun 93 04:05:58 MET DST
Received: from strawberry.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18418; Fri, 25 Jun 1993 04:29:09 +0200
Received: from localhost by strawberry.ucs.indiana.edu
	(5.65c/9.4jsm) id AA04613; Thu, 24 Jun 1993 21:28:59 -0500
To: montulli@stat1.cc.ukans.edu (Lou Montulli)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Internet Tools Search & Showcase 
In-Reply-To: Your message of "Thu, 24 Jun 1993 09:36:30 CDT."
             <9306241436.AA24120@stat1.cc.ukans.edu> 
Date: Thu, 24 Jun 1993 21:28:57 -0500
Message-Id: <4611.740975337@strawberry.ucs.indiana.edu>
From: "William M. Perry" <wmperry@strawberry.ucs.indiana.edu>

Thus wrote: 
>> 
>> 
>> I have just been asked to do a book proposal on the new generation of
>> Internet tools, those that depend on global connectivity and fairly
>> highspeed links.  I will be featuring browsers such as Mosaic, Xwais,
>> and Cello, and innovative audio/video/multimedia packages such as CUCME,
>> Netjam, MBONE multicasting, etc.  I am looking for pointers to programs
>> and applications, preferably in the public domain or shareware, that
>> are beginning to tap the promise of the Internet-- I would love to do
>> a chapter on collaboration and visualization tools such as the NCSA tools
>> and the EVL stuff, for instance.
>> 
>What about us poor lowly VT100 developers.  Those GUI people get all
>the glory :)

    Yeah . . . lets hold a revolution.  Death to the GUI Fascist
    Pig-Dogs?  Doesn't quite flow - oh well, will just have to wait
    for a better slogan.

    But on to the main point of the article.  Will browsers that run
    on dumb tty's be featured?  Lots of people that would benefit from
    the web (and contribute to it eventually) aren't fortunate enough
    to have X terminals or SparcStations sitting on their desks (lets
    not forget how spoiled we are), and some even have to deal with
    macs.  (And lets not forget those poor unfortunates without net
    connections (linuxers in particular)).

    Thanks,
    	Bill P.

From daemon  Fri Jun 25 04:29:45 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03682; Fri, 25 Jun 93 04:29:48 MET DST
Return-Path: <chrisf@sour.sw.oz.au>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03678; Fri, 25 Jun 93 04:29:45 MET DST
Received: from joyce.cs.su.OZ.AU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24831; Fri, 25 Jun 1993 04:52:49 +0200
Received: from sour.sw.oz.au (for nxoc01.cern.ch) with MHSnet;
	Fri, 25 Jun 1993 12:52:43 +1000
Received: from sour.sw.oz.au by swift.sw.oz.au with SMTP
	id AA18986; Fri, 25 Jun 93 12:51:43 AES (5.59)
	(from chrisf@sour.sw.oz.au for www-talk@nxoc01.cern.ch)
Received: by sour.sw.oz.au
	id AA29073; Fri, 25 Jun 1993 12:51:33 +1000 (5.65c/1.34)
	(from chrisf@sour.sw.oz.au for www-talk@nxoc01.cern.ch)
From: chrisf@sour.sw.oz.au (Christopher Fraser)
Message-Id: <199306250251.AA29073@sour.sw.oz.au>
Subject: Re: #WWW on IRC
To: www-talk@nxoc01.cern.ch
Date: Fri, 25 Jun 1993 12:51:33 +1000 (EST)
In-Reply-To: <199306242258.AA14189@kauri.vuw.ac.nz> from "Nathan Torkington" at Jun 25, 93 10:58:09 am
Return-Receipt-To: chrisf@suite.sw.oz.au
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1222      

But I thought Nathan Torkington said:
> 
> What I thought would be really valuable is a WWW developers (possibly
> and users) BBS, telnettable to.  That way the conversation could be
> subdivided into topics (``boards'' for Clients, Mosaic, Servers, CERN
> Code, WAIS, Getting Started, SGML-flamage, &c.).  The site to set this
> up would need to be well connected, though (hint hint :-).
> 
> A problem I find with the mailing list is that *everything* is here,
> which is not necessarily a good thing :).  I delete more than I read,
> and it takes a while for the mail to get through.

Whilst I'm not innately opposed the idea of a bulletin board (server,
archive, whatever), please do spare a thought for us plebs without internet
connections (mind you; I am working on it!). Anyway, the mailing list format
is a Good Thing for developers conferences; there's typically a much lower
noise level than newsgroups/bulletin boards/IRC (mailing lists are typically
much more intimidating to new users :-)

There is probably scope for creating channels on this mailing list, but I 
don't think it's too bad at the moment.

Cheers,
--
Christopher Fraser              ``Insult is the lowest form of flattery''
chrisf@sw.oz.au 


From daemon  Fri Jun 25 05:42:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04250; Fri, 25 Jun 93 05:42:58 MET DST
Return-Path: <kchang@ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04246; Fri, 25 Jun 93 05:42:56 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA08245; Fri, 25 Jun 1993 06:06:07 +0200
Received: from santacruz.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12428
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 24 Jun 93 23:05:47 -0500
Date: Thu, 24 Jun 93 23:05:47 -0500
Message-Id: <9306250405.AA12428@newton.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
From: kchang@ncsa.uiuc.edu (Kenneth Chang)
X-Sender: kchang@newton.ncsa.uiuc.edu
Subject: Re: RE two PREs

>> = Terry
> = Dave Raggett

>> Presently in xmosaic PRE is presented in a typewriter font; this is okay
>> for code examples (unless you have in-line annotations that you want 
>> distinguished from the code) but not for all forms of text that should
>> be displayed verbatim (poetry).  So either two PREs are needed, or the
>> font change in PRE should be invoked specifically, perhaps by using
>> CODE inside PRE.
>
>HTML+ has a style attribute for the PRE tag with just such ideas in mind:
>
><!-- Preformatted text with fixed pitch font,
>     respecting original spacing and newlines.
>     The style attribute allows authors to specify
>     alternative styles, e.g. "poem" which browsers
>     could render in a proportional font.

I think Terry's solution of requiring a <CODE> to get a fixed-width
font within a PRE is simpler and more general. Right now, I come across
things such as addresses, e.g.

National Center for Supercomputing Applications
405 E. Springfield Avenue
Champaign, Illinois 61820

that there really isn't any way to code in HTML sensibly. It certainly
isn't a poem, either.

--ken chang
  NCSA Publications


From daemon  Fri Jun 25 05:57:28 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04359; Fri, 25 Jun 93 05:57:30 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04355; Fri, 25 Jun 93 05:57:28 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09928; Fri, 25 Jun 1993 06:20:39 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12984
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 24 Jun 93 23:20:37 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA12611; Thu, 24 Jun 93 23:23:14 -0500
Date: Thu, 24 Jun 93 23:23:14 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306250423.AA12611@wintermute.ncsa.uiuc.edu>
To: kchang@ncsa.uiuc.edu (Kenneth Chang)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: RE two PREs
In-Reply-To: <9306250405.AA12428@newton.ncsa.uiuc.edu>
References: <9306250405.AA12428@newton.ncsa.uiuc.edu>
X-Md4-Signature: b95c84ad09ccf099fcc0bf6ccf99d6d2

Kenneth Chang writes:
> >> = Terry
> > = Dave Raggett
> 
> >> Presently in xmosaic PRE is presented in a typewriter font; this is okay
> >> for code examples (unless you have in-line annotations that you want 
> >> distinguished from the code) but not for all forms of text that should
> >> be displayed verbatim (poetry).  So either two PREs are needed, or the
> >> font change in PRE should be invoked specifically, perhaps by using
> >> CODE inside PRE.
> >
> >HTML+ has a style attribute for the PRE tag with just such ideas in mind:
> >
> ><!-- Preformatted text with fixed pitch font,
> >     respecting original spacing and newlines.
> >     The style attribute allows authors to specify
> >     alternative styles, e.g. "poem" which browsers
> >     could render in a proportional font.
> 
> I think Terry's solution of requiring a <CODE> to get a fixed-width
> font within a PRE is simpler and more general. Right now, I come across
> things such as addresses, e.g.
> 
> National Center for Supercomputing Applications
> 405 E. Springfield Avenue
> Champaign, Illinois 61820
> 
> that there really isn't any way to code in HTML sensibly. It certainly
> isn't a poem, either.

A line-break primitive would solve that and keep <pre> pure (the whole
point behind <pre> is that it's preformatted in ASCII and browsers
shouldn't screw around with that formatting; it shouldn't simply mean
"newlines significant").

Marc


From daemon  Fri Jun 25 06:28:28 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04591; Fri, 25 Jun 93 06:28:30 MET DST
Return-Path: <kchang@ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04586; Fri, 25 Jun 93 06:28:28 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17658; Fri, 25 Jun 1993 06:51:40 +0200
Received: from santacruz.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14254
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Thu, 24 Jun 93 23:51:37 -0500
Date: Thu, 24 Jun 93 23:51:37 -0500
Message-Id: <9306250451.AA14254@newton.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
From: kchang@ncsa.uiuc.edu (Kenneth Chang)
X-Sender: kchang@newton.ncsa.uiuc.edu
Subject: Re: RE two PREs

Marc Andreesen (over in the next building) writes:

>A line-break primitive would solve that and keep <pre> pure (the whole
>point behind <pre> is that it's preformatted in ASCII and browsers
>shouldn't screw around with that formatting; it shouldn't simply mean
>"newlines significant").

No. It should mean "newlines and spaces significant."

Since one can already imbed codes in PRE sections, the
browsers are already screwing around with the formatting. A line
break primitive makes for messy coding (I sure wouldn't want to
format Shakespeare with it). 

I need one of two things:

a) PRE defaults to the proportional spaced font.

or

b) A primitive (<R> for Roman?) that forces the viewer to use the
proportional spaced font.

--ken chang
  NCSA Publications


From daemon  Fri Jun 25 12:00:20 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08128; Fri, 25 Jun 93 12:00:22 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08123; Fri, 25 Jun 93 12:00:20 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23940; Fri, 25 Jun 1993 12:23:29 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 25 Jun 93 11:15:08 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA14156; Fri, 25 Jun 93 11:21:25 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306251021.AA14156@manuel.hpl.hp.com>
Subject: Text on Image for HTML+
To: marca@ncsa.uiuc.edu
Date: Fri, 25 Jun 93 11:21:23 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Marc says:

> Hi Dave, got a user request for this...

> * text on top of an image background or in a colored background box
>   which sits arbitrarily on top of an image background.

> I'm ambivalent; it might be overkill.  On the other hand, it would be
> neat.

OK how about this:

A new tag FIGT which allows you to position arbitrary text at a given
point in the image. The optional "BOX" attribute requests the browser to draw
a background box (obscuring the image). You can choose to make the whole of
the box into a hypertext link, or to use the A tag for designated parts of
the text. The optional "WIDTH" attribute allows you to limit the width of
the box. By default, the browser will make the width equal the lesser of the
length of the text string or the right most extent of the image.

I have also switched back to having the upper left as (0,0). Furthermore,
to provide backwards compatibility with servers supporting X Mosaic's ISMAP
feature, I have added the "PIX" attribute to FIG. This switches the coordinate
scheme to pixels for the scope of the figure, i.e. for FIGA, FIGT and sending
mouse clicks to the server.

This will make it practical to automatically convert HTML documents into
the HTML+ format, so that we can painlessly switch to the new DTD.

Cheers,

Dave Raggett

n.b. I have ditched "ISMAP" in favour of "MAP" to ensure people realise
that the mechanism is not the same (i.e. it defaults to scaled coords).

----------- DTD snippet for figures ---------------------------------------

<!-- Figures

    Figures can be fixed to the point in the text flow where
    they should appear or may float relative to the text.

    The image/drawing is specified by a URL or as embedded
    data for simple drawings. The elements text serves
    as the caption. Use the CREDIT emphasis to record
    photo credits etc.

    Mouse clicks can be handled by server (MAP) or browser (FIGA)
    The coordinate scheme is (0,0) for upper left and (1,1)
    for the lower right of the figure with X to the right
    and Y up the "page". When sending clicks to the server
    append to URL as in:   URL?X,Y

    The PIX attribute switches the coordinate scheme to
    pixel values with (0,0) as the top left. This is intended
    to provide backwards compatibility with servers that
    support X Mosaic's ISMAP feature.

    For backwards compatibility with servers which support
    X Mosaic's ISMAP feature

    Clicks on areas designated with FIGA should take
    preference over handling by the server.

    FIGT allows you to position text over the figure.
-->

<!ELEMENT FIG - - (EMBED?, (FIGA|FIGT)*, (%text;)*)>
<!ATTLIST FIG
    id      ID       #IMPLIED
    float  (float)   #IMPLIED -- fixed or floating figures --
    map     (map)    #IMPLIED -- server can handle mouse clicks --
    pix     (pix)    #IMPLIED -- use pixel coordinates --
    src     %URL;    #IMPLIED -- link to image data -->

<!-- Figure anchors designate polygonal areas on the figure
    which can be clicked with the mouse. The default area
    is the whole of the figure. This mechanism interprets
    mouse clicks locally, and browsers can choose to highlight
    the designated area (or change the mouse sprite) when the
    mouse is moved over the area.

    Note that polygons may be non-convex or even intersect
    themselves, thereby complicating the definition of what
    is enclosed by the polygon. Holes are excluded.
-->

<!ELEMENT FIGA - O (EMPTY)>
<!ATTLIST FIGA
    href    %URL;   #REQUIRED   -- link to traverse when clicked --
    area    NUMBERS #IMPLIED    -- x1,y1,x2,y2,x3,y3,... -->

<!-- Text on top of an figure background, or in a colored background
     box which sits arbitrarily on top of an figure background.
     The text can include headers, lists and tables etc. The width
     attribute allows you to limit the width of the text box. The
     height is then determined automatically by the browser.

     You can make the whole of the box into a hypertext link.
-->

<!ELEMENT FIGT - - (%main;)>
<!ATTLIST FIGT
    at      NUMBERS #IMPLIED    -- upper left origin for text --
    box     (box)   #IMPLIED    -- draw background coloured box --
    width   NUMBER  #IMPLIED    -- given in average char widths --
    href    %URL;   #REQUIRED   -- link to traverse when clicked -->


From daemon  Fri Jun 25 12:24:26 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08355; Fri, 25 Jun 93 12:24:28 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08351; Fri, 25 Jun 93 12:24:26 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28656; Fri, 25 Jun 1993 12:47:37 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 25 Jun 93 11:39:28 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA14172; Fri, 25 Jun 93 11:45:52 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306251045.AA14172@manuel.hpl.hp.com>
Subject: Re: RE two PREs
To: kchang@ncsa.uiuc.edu
Date: Fri, 25 Jun 93 11:45:50 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Ken,

Following Marc Andreessen's lead, I have added some rendering hints
to the P tag, along with two new tags: BR (line break) and SP (unbreakable
space). These will give you the control you need, e.g.

<P INDENT>
National Center for Supercomputing Applications<BR>
405 E. Springfield Avenue<BR>
Champaign, Illinois 61820<BR>

gives:
        National Center for Supercomputing Applications
        405 E. Springfield Avenue
        Champaign, Illinois 61820

The EMPH tag has been likewise extended to include rendering hints:

<!ELEMENT EMPH - - (%text;)*>
<!ATTLIST EMPH
    type    CDATA   #IMPLIED    -- logical category e.g. CITE --
    b       (b)     #IMPLIED    -- render in bold font --
    i       (i)     #IMPLIED    -- render in italic font --
    u       (u)     #IMPLIED    -- underline text --
    tt      (tt)    #IMPLIED    -- render in typewriter font --
    vp      (vp)    #IMPLIED    -- render in variable pitch font --
    sup     (sup)   #IMPLIED    -- superscript --
    sub     (sub)   #IMPLIED    -- subscript --
    index   CDATA   #IMPLIED    -- entries for index compilation -->

This allows you to switch fonts by <EMPH VP>variable pitch</EMPH>, even
within PRE elements.

My real concern now is the bias to West European languages. Latin-1 is
inadequate for other areas of the world. Unicode (16 bit fonts) helps
but doesn't address non-extant languages such as old english.

Cheers, 

Dave Raggett

From daemon  Fri Jun 25 18:33:10 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14803; Fri, 25 Jun 93 18:33:12 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14799; Fri, 25 Jun 93 18:33:10 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15460; Fri, 25 Jun 1993 18:56:22 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA20683; Fri, 25 Jun 1993 11:55:24 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306251655.AA20683@stat1.cc.ukans.edu>
Subject: Re: #WWW on IRC
To: www-talk@nxoc01.cern.ch
Date: Fri, 25 Jun 93 11:55:24 CDT
In-Reply-To: <199306242329.AA15448@kauri.vuw.ac.nz>; from "Nathan Torkington" at Jun 25, 93 11:29 am
X-Mailer: ELM [version 2.3 PL2]

> Hmm, ircaphobe? :)

Definately!
> 
> Not everyone needs to be on at the same time for informal discussions
> -- for instance, your question about WAIS could have been answered by
> me, likewise my query about the 2.06 distribution could have been
> answered by saying ``fool, it was *fixed* in the 2.06 distribution''
> :-).  Some things, net face-to-face would be nice for.
> 
> Nat.
> 

Hmmm, as a supplement irc could be useful, but I would hate for it to
be seen as a psuedo replacement.

I thought that the MUD idea was humorous :)

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Fri Jun 25 19:06:07 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15439; Fri, 25 Jun 93 19:06:09 MET DST
Return-Path: <David.Martin@library.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15435; Fri, 25 Jun 93 19:06:07 MET DST
Received: from lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19518; Fri, 25 Jun 1993 19:29:19 +0200
Received: from brasil.library.ucsf.edu by library.ucsf.edu with SMTP id AA28502
  (5.67a8/IDA-1.5 for <www-talk>); Fri, 25 Jun 1993 10:29:03 -0700
Message-Id: <199306251729.AA28502@library.ucsf.edu>
From: David.Martin@library.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: www-talk@library.ucsf.edu
Subject: Accessing URL's
Date: Fri, 25 Jun 93 10:25:48 MDT
Sender: David.Martin@library.ucsf.edu

I would like to propose the following extension (not too difficult, but
I couldn't find all the places to modify):

Allow Xmosaic to read symbolic links as URL's

That is, allow files like the following:

mosaic-docs -> http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs
cave.html -> http://www.ncsa.uiuc.edu/evl/cave/cave.html

This would simplify the storage of bookmarks and allow a user to
organize their local hierarchy appropriate to the information resources
that they had identified, e.g. collecting URL's about a specific subject
or concept area.

I did an initial hack to the code to allow the interpretation of
symbolic links, but would like to see this extension permeated
throughout the code (i.e. saving, etc..)

dcm

From daemon  Fri Jun 25 20:00:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16476; Fri, 25 Jun 93 20:01:01 MET DST
Return-Path: <David.Martin@library.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16472; Fri, 25 Jun 93 20:00:59 MET DST
Received: from lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29792; Fri, 25 Jun 1993 20:24:11 +0200
Received: from brasil.library.ucsf.edu by library.ucsf.edu with SMTP id AA29167
  (5.67a8/IDA-1.5 for <www-talk>); Fri, 25 Jun 1993 11:24:02 -0700
Message-Id: <199306251824.AA29167@library.ucsf.edu>
From: David.Martin@library.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu or uunet!dcmartin
Phone: 415/476-6111
Fax: 415/476-4653
To: George Phillips <phillips@cs.ubc.ca>
Cc: www-talk@library.ucsf.edu
In-Reply-To: Your message of 25 Jun 93 11:08:00 -0800
	<5879*phillips@cs.ubc.ca> 
Subject: Re: Accessing URL's 
Date: Fri, 25 Jun 93 11:20:47 MDT
Sender: David.Martin@library.ucsf.edu

No.  There is no organizational structure to the subject.html file or
you must have some methodology for the creation, editting and
organization of such HTML documents.  The file system paradigm, with
directories and a hierarchy, is a more prevalent and more open design
with many options for creative interfaces (e.g. utilizing the
OpenWindows file manager to access HTML links via launching Xmosaic or
using ToolTalk between the file manager and Xmosaic).

dcm
--------
George Phillips writes:

An interesting idea, but is in not just a easy to create a
"subject.html" file that has all the links in it (and some
explanitory text, even)?

-- George

From daemon  Fri Jun 25 20:35:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17286; Fri, 25 Jun 93 20:35:41 MET DST
Return-Path: <nop@theory.cs.mankato.msus.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17281; Fri, 25 Jun 93 20:35:39 MET DST
Received: from theory.CS.Mankato.MSUS.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05160; Fri, 25 Jun 1993 20:58:50 +0200
Received: by theory.cs.mankato.msus.edu (5.65/DEC-Ultrix/4.3)
	id AA06324; Fri, 25 Jun 1993 13:58:44 -0500
Date: Fri, 25 Jun 1993 13:58:44 -0500
From: nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
Message-Id: <9306251858.AA06324@theory.cs.mankato.msus.edu>
To: Nathan.Torkington@vuw.ac.nz
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Nathan Torkington's message of Fri, 25 Jun 1993 10:58:09 +1200 <199306242258.AA14189@kauri.vuw.ac.nz>
Subject: #WWW on IRC

> What I thought would be really valuable is a WWW developers (possibly
> and users) BBS, telnettable to.  That way the conversation could be
> subdivided into topics (``boards'' for Clients, Mosaic, Servers, CERN
> Code, WAIS, Getting Started, SGML-flamage, &c.).  The site to set this
> up would need to be well connected, though (hint hint :-).

> A problem I find with the mailing list is that *everything* is here,
> which is not necessarily a good thing :).  I delete more than I read,
> and it takes a while for the mail to get through.

> As an interim idea, why not use IRC to communicate informally?  I'll
> join #WWW on IRC whenever I'm on, and if there's sufficient interest,
> I'll look into writing a 'bot to serve files, maybe even access the
> web.  Someone with a less crappy connection to the backbone might be
> able to run the 'bot if it gets going.

Let me suggest that you visit JaysHouse, "a MOO for friends to talk,
experiment with networking, hypertext, collaboration, etc." at
    telnet://jhm.moo.mud.org:1709/

MOO stands for "MUD, Object-Oriented"; it's a text-based simulated world with
an object-oriented programming language used to create the components of that
world.  Among those components are, of course, people and rooms; also a
full-fledged mail/newsgroup system, which could be used as you indicated for
splitting discussion into topics (while still keeping them all closely
related.)

We at JH have been using MOO to explore some of the same issues that show up
in WWW.  For example, we developed a Gopher client in MOO that allows for
collaborative browsing of Gopher, and embedding of Gopher data in `physical'
objects--for example, a `weather map' in the living room that gets its data
from the Gopher weather server.  More recently we've been working on our own
internal hypertext system, used to add a richer dimension to the MOO's help
system, as well as notes and other assorted objects.  There's a gateway to
jtext--said hypertext system--at
    http://jhm.moo.mud.org:7043/
I think this has been announced in www-land before, but I'm not sure.

I see JH as a technology demonstration---I'm not proposing that all
the WWW people move in there.  If people feel that this is a
communication medium worth exploring, we can find a site and set up a
WWW-specific server.

Oh--I'm usually logged on as "Jay".  Other good people to talk to
about hypertext stuff are Joe (or Joe Feedback) and Ron, and other
people can be helpful as well.  We'd like to talk to WWW people about
this as a possible communication system, and hear what you think.

Hope to see you soon.

Jay Carlson
nop@theory.cs.mankato.msus.edu

Flat text is just *never* what you want.   ---stephen p spackman

From daemon  Fri Jun 25 22:14:17 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19369; Fri, 25 Jun 93 22:14:19 MET DST
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19364; Fri, 25 Jun 93 22:14:17 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21664; Fri, 25 Jun 1993 22:37:30 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA07887; Fri, 25 Jun 1993 15:37:28 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Encapsulating HTTP in MIME
Date: Fri, 25 Jun 1993 15:37:27 -0500
Message-Id: <7883.741040647@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

HTTP, particularly HTTP/1.0, is a transaction oriented protocol.  I
believe there are advantages to generating a mechanism whereby the
individual portions of the transactions (the REQUEST and the RESPONSE)
can be treated as MIME content-types, allowing separation,
encapsulation, forwarding, and the usual MIME stuff.

I (tentatively and roughly) suggest the creation of two additional
MIME types:

  message/http-request

and

  message/http-response

with their contents being identical to the request and response
messages of an HTTP transsaction, respectively.  Since the machine and
port of an HTTP transaction aren't represented within the request or
response explicitly, the request will need this as a parameter called
"host" or some such when it can't be assumed to be the machine reading
the request.

WHY DO THIS?

One advantage to this kind of method is that it should make it easier
for non-interactive users to utilize the full power of HTTP/1.0 via
mail messages sent to a mailbot that can take the http-request, send
it over the network as appropriate, and send back the result
encapsulated as an http-response.  This allows for precise tagging and
should help make a more automated environment for WWW users stuck on
UUCP or other dialup networks sending HTTP transactions via email (or
other means.)  The current mailbot, while servicable, is hardly
elegant; this could, in principle, let UUCP people (or people with
paranoid firewalls, or whatever) use XMosaic, just a bit slower.

The ability to encapsulate requests and responses inside other MIME
objects will also allow for Privacy Enhanced Mail (PEM) security
services, notably authentication, to be applied to HTTP transactions.
The problem of authorization to data may be handled by simply taking
the entire REQUEST segment, tagging it as an http-request, and signing
it with standard PEM techniques.  MIME-PEM interoperation is still an
internet draft, but the big issues are pretty much taken care of; only
minor syntactic matters remain.

The only real area of uncertainty I have is what HTTP request method
is appropriate for sending an encapsulated request to a server
directly.  It could use the PUT or POST methods, or a new method.
I'll use PUT for the moment.  Thus, a simple request to a mailbot
might look kind of like this:

  From: jrandom@nowhere.org
  To: mailbot@www.some.place.edu
  MIME-Version: 1.0
  Content-Type: message/http-request; host="info.cern.ch:80"

  GET /hypertext/WWW/TheProject.html HTRQ/1.0
  From: jrandom@nowhere.org
  Accept: text/plain; text/html; image/gif; ...
  User-Agent: ...
  [ ... ]

and the mailbot would send back a message something like this:

  From: mailbot@www.some.place.edu
  To: jrandom@nowhere.org
  MIME-Version: 1.0
  Content-Type: message/http-response

  103 200 OK
  Last-Modified: <date>
  MIME-Version: 1.0
  Content-Type: text/html

  [the HTML document]

An authenticated transaction searching for information in an online
multimedia encyclopedia might look vaguely like this:

  PUT request HTRQ/1.0
  MIME-Version: 1.0
  Content-Type: multipart/pem; boundary="boundary"; privacy=mic-only
  Length: <whatever>

  --boundary
  Content-Type: message/pem-clear

  Content-Type: message/http-request

  GET /multimedia-encyclopedia/index?space+mission+moon HTRQ/1.0
  From: mvanheyn@cs.indiana.edu
  Accept: text/plain; text/html; image/gif; ...

  --boundary
  Content-Type: application/pem

  Proc-Type: 4,MIC-ONLY
  Originator-ID-Asymmetric: ...
  MIC-Info: RSA-MD5,RSA, [various signature information...]
  ...

  --boundary--

Thus, the *entire* HTTP request is encapsulated inside the
authenticated (and, if desired, encrypted) portion of the message;
this is important, since the whole request should be authenticated
(the first line is probably the most important thing to verify) and
protected by the PEM structure.

The preceeding example is based on the current internet draft
draft-ietf-pem-mime-02.txt; if you aren't familiar with it, the above
may look a little odd.  Naturally, "ordinary" requests and replies
would normally be used in situations not requiring services of PEM.

I believe this kind of content tagging has some general advantages for
increasing the ability to do HTTP transactions indirectly, and has the
distinct advantage of continuing HTTP's relationship with MIME and
closeness with "normal" mail.  Trying to force a PEM signature into an
HTTP Authorization: header or some such might be possible, but seems
like a bad idea to me.

I also believe that using PEM as a model for security services
continues the close relationship between HTTP and mail and is strongly
preferable to using Kerberos; I won't rant about this one right now
though.

Obviously, details and syntax and stuff would need to be fleshed out;
for example, it might be desirable to use unique identifiers
(Message-ID?) to allow clients receiving responses in batch mode by
UUCP to sort out which responses go with with requests.  In general, I
think this kind of development would be of use. 

Reactions?
- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu
MIME, RIPEM and HTML spoken here.

From daemon  Sat Jun 26 00:38:01 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22267; Sat, 26 Jun 93 00:38:04 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22263; Sat, 26 Jun 93 00:38:01 MET DST
Received: from kauri.vuw.ac.nz by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11369; Sat, 26 Jun 1993 01:01:11 +0200
Received: by kauri.vuw.ac.nz id AA26671
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Sat, 26 Jun 1993 11:00:47 +1200
Date: Sat, 26 Jun 1993 11:00:47 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306252300.AA26671@kauri.vuw.ac.nz>
To: montulli@stat1.cc.ukans.edu (Lou Montulli)
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: Lou Montulli's message <9306251655.AA20683@stat1.cc.ukans.edu>
Subject: Re: #WWW on IRC

Lou Montulli writes:

> I thought that the MUD idea was humorous :)

Don't laugh -- MUDs are just a first cut at a simulated world (VR is
such an over-used term), and they don't necessarily have to be filled
with hacking and slashing.  Indeed, I think you're about to find out
how good they can be for:
 -- multiway chat,
 -- simple user-interfaces,
and
 -- development.

Nat

From daemon  Sat Jun 26 01:04:08 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22586; Sat, 26 Jun 93 01:04:10 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22581; Sat, 26 Jun 93 01:04:08 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14199; Sat, 26 Jun 1993 01:27:19 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA23526; Fri, 25 Jun 93 18:27:14 -0500
Message-Id: <9306252327.AA23526@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: #WWW on IRC 
In-Reply-To: Nathan Torkington's message of Sat, 26 Jun 93 11:00:47 +1200.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 25 Jun 1993 18:27:13 -0500
From: Tony Sanders <sanders@bsdi.com>

I agree.  I've even been thinking about using one for doing customer
support at BSDI.  Customers could log into the MUD and get patches,
info, open bugs, check out reported bugs, open problem reports (for
those with support), maybe even chat with developers on occasion.

I think MUDs are great.  A WWW<->MUD gateway would be even better.
Someone needs to write WWWmud that uses HTML to build the interface
(problem is MUD's are interactive, when are we going to have iHTML? :-)
Still it could be done with some compromises.

Anyone want to hack "ihttp://..." into their browser? :-)

> Lou Montulli writes:
> 
> > I thought that the MUD idea was humorous :)
> 
> Don't laugh -- MUDs are just a first cut at a simulated world (VR is
> such an over-used term), and they don't necessarily have to be filled
> with hacking and slashing.  Indeed, I think you're about to find out
> how good they can be for:
>  -- multiway chat,
>  -- simple user-interfaces,
> and
>  -- development.
> 
> Nat

From daemon  Sat Jun 26 06:00:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25189; Sat, 26 Jun 93 06:00:34 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA25185; Sat, 26 Jun 93 06:00:31 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24337; Sat, 26 Jun 1993 06:23:43 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA24108; Fri, 25 Jun 93 23:23:40 -0500
Message-Id: <9306260423.AA24108@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: WWW usage
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Fri, 25 Jun 1993 23:23:39 -0500
From: Tony Sanders <sanders@bsdi.com>

FYI: This document_ is available via the setext -> HTML converter:
    http://www.bsdi.com/setext/www-usage.etx

WWW Usage Tracking
------------------
  Is anyone interested in tracking WWW usage?

  I propose someone setup a mail gateway for usage reports that get dumped
  into the Web.  I would be willing to do this if no one else is interested.
  I could at least archive the raw data onto the Web if not summerize it and
  graph it.

  Maybe a weekly report that says something like:

    Date: Sat Jun 26 03:01:56 GMT 1993
    Server: http://www.bsdi.com/
    Requests last 7 days: 3589
    Unique hosts last 7 days: 69
    Total unique hosts: 847
    Total requests: 18358
    Total days of service: 52

  Whatdaya think?

  At some point it would be neat if someone could take all the IP addresses
  from all the servers and ``uniq'' them to get an idea of how many users
  we have (My server has 847 unique ip addresses in the log).  Does anyone
  care about having their IP address uniqued?  Does anyone care about having
  their IP address made public (I'm not suggesting this, just curious).

  Once HTTP/1.0 gets more widespread we will be able to track client usage.

  In case anyone else is interested: my 7 day summaries for the past
  52 days (minus this week).  Each * is 100 requests.

    05/03 ********************
    05/10 ********************
    05/17 ******************
    05/24 ***************
    05/31 ***********************
    06/07 *****************************
    06/14 *******************************

  Anyone else have this data they can post?

A Related Issue
---------------

  Is anyone having any performance problems with their HTTP servers?  I did
  some tests on my 486DX2/66 (call it 31MIPS) and found that Plexus runs
  about 5 tps, and I timed the NCSA server that runs from inetd but it's
  not a fair comparison (1 tps) because you could run it native and save
  the exec cost.  What are you busy server people running at peak (in tps)?
  I would **really** like to hear what tps other people are getting and on
  what hardware (~ MIPS anyway) and if you can do some peak performance
  tests that would help.  I expect it'll be about the same (5 tps peak) on
  most hardware available today as I think most of the overhead is beyond
  the control of the server (i.e., in TCP/IP and exec).

--sanders

.. _document http://www.bsdi.com/setext/www-usage.etx

From daemon  Sat Jun 26 10:00:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26459; Sat, 26 Jun 93 10:00:04 MET DST
Return-Path: <CSP1DWD@mvs.oac.ucla.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26455; Sat, 26 Jun 93 10:00:02 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28715; Sat, 26 Jun 1993 10:23:16 +0200
Message-Id: <9306260823.AA28715@dxmint.cern.ch>
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 7272; Sat, 26 Jun 93 10:23:16 SET
Received: from UCLAMVS.BITNET (NJE origin MAILER@UCLAMVS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 9537; Sat, 26 Jun 1993 10:23:16 +0200
Date:    Sat, 26 Jun 93 01:23 PDT
To: timbl@nxoc01.cern.ch
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@mvs.oac.ucla.edu>
Subject: Sun3 Compile of WWWLibrary_2.06
Cc: www-talk@nxoc01.cern.ch

Even though I set environment var WWW_MACH to sun3, it goes ahead and
starts making the library as if for a sun4... any fixes for this?

-- Denis


From daemon  Sat Jun 26 20:05:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29898; Sat, 26 Jun 93 20:05:33 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29893; Sat, 26 Jun 93 20:05:31 MET DST
Received: from amber.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18837; Sat, 26 Jun 1993 20:28:45 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA06334; Sat, 26 Jun 1993 14:27:30 -0400
Date: Sat, 26 Jun 1993 14:15:28 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Suggestion for a new URL type
To: www-talk@nxoc01.cern.ch
Message-Id: <Pine.3.03.9306261428.L5397-a100000@amber.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


I'd like to suggest the following form for a new type of URL.  This would
answer the need of a 'finger' URL type, as well as others, in a simple,
generic interface.

	A Generic TCP URL Type - 

		ex. tcp://host.domain:port/data_for_tcp_port

	where:
		-	port would be numeric as well as symbolic,
				79 or finger
		-	data_for_tcp_port would allow escaped chars,
				line#1\nline#2\nline#3

	Possible uses:

	Finger 		- 	"tcp://ruby.ora.com:79" or
				"tcp://ruby.ora.com:finger/username"

	Webster 	-	"tcp://ora.com:webster/DEFINE server\nQUIT"

	Whois		-	"tcp://rs.internic.net:43/ORA.COM"

	Time		-	"tcp://localhost:daytime"

	NNTP		-	"tcp://ruby.ora.com:nntp/LIST"

Any comments?



From daemon  Sat Jun 26 20:35:24 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00287; Sat, 26 Jun 93 20:35:26 MET DST
Return-Path: <wmperry@nectarine.ucs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00283; Sat, 26 Jun 93 20:35:24 MET DST
Received: from nectarine.ucs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23082; Sat, 26 Jun 1993 20:58:39 +0200
Received: from localhost by nectarine.ucs.indiana.edu
	(5.65c/9.4jsm) id AA08348; Sat, 26 Jun 1993 13:58:34 -0500
To: Rob Raisch <raisch@ora.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Suggestion for a new URL type 
In-Reply-To: Your message of "Sat, 26 Jun 1993 14:15:28 -0400."
             <Pine.3.03.9306261428.L5397-a100000@amber.ora.com> 
Date: Sat, 26 Jun 1993 13:58:33 -0500
Message-Id: <8346.741121113@nectarine.ucs.indiana.edu>
From: "William M. Perry" <wmperry@nectarine.ucs.indiana.edu>

Thus wrote: Rob Raisch
>
>I'd like to suggest the following form for a new type of URL.  This would
>answer the need of a 'finger' URL type, as well as others, in a simple,
>generic interface.
>
>	A Generic TCP URL Type - 
>
>		ex. tcp://host.domain:port/data_for_tcp_port
>
>	where:
>		-	port would be numeric as well as symbolic,
>				79 or finger
>		-	data_for_tcp_port would allow escaped chars,
>				line#1\nline#2\nline#3
>
>	Possible uses:
>
>	Finger 		- 	"tcp://ruby.ora.com:79" or
>				"tcp://ruby.ora.com:finger/username"
>
>	Webster 	-	"tcp://ora.com:webster/DEFINE server\nQUIT"
>
>	Whois		-	"tcp://rs.internic.net:43/ORA.COM"
>
>	Time		-	"tcp://localhost:daytime"
>
>	NNTP		-	"tcp://ruby.ora.com:nntp/LIST"
>
>Any comments?

   What about security?  What if some bozo decided to put a url like:

tcp://some.generic.news.server:nntp/line#1\nCODE TO FORGE NEWSGROUP\n...

or

tcp://some.generic.news.server:25/HELO some.host\nRCPT TO: root\nMAIL
FROM: stupid.user\nDATA\n Hey bozo - <Very derogative statements> Love
- stupid.user\n.\nQUIT\n

And called it something like "Man Pages For Ultrix"?

Could lead to some interesting discussions with your local sysadmin if
you clicked on that second one. :)

I talked with Marc Vanheyningen about this a few months ago, and he
convinced me that it would be a _BAD THING_ to do something like this.
Not that there are many bozos out there that would do one of the
above, but it would only take one or two to cause some real trouble.

-Bill Perry

From daemon  Sat Jun 26 21:42:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00867; Sat, 26 Jun 93 21:42:58 MET DST
Return-Path: <Christopher.McRae@library.ucsf.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00862; Sat, 26 Jun 93 21:42:56 MET DST
Received: from lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01917; Sat, 26 Jun 1993 22:06:10 +0200
Received: from sphinx.library.ucsf.edu by library.ucsf.edu with SMTP id AA14895
  (5.67a8/IDA-1.5 for <www-talk>); Sat, 26 Jun 1993 13:06:00 -0700
Message-Id: <199306262006.AA14895@library.ucsf.edu>
To: ebina@ncsa.uiuc.edu
Cc: marca@ncsa.uiuc.edu, www-talk@library.ucsf.edu
Subject: Re: Xmosaic and Xv 
In-Reply-To: Your message of "Fri, 25 Jun 93 17:04:03 CDT."
             <9306252204.AA18537@void.ncsa.uiuc.edu> 
Date: Sat, 26 Jun 93 13:09:14 MDT
From: "Christopher J. McRae" <Christopher.McRae@library.ucsf.edu>


Marc Andreessen writes:
|
| ebina@ncsa.uiuc.edu writes:
| > Right now mosaic defaults to using xv as the viewer for many different
| > image types.  I don't see why it is necessary to have it take the id
| > of another window when it can just use its own.
| 
| I think Chris is referring to the idea someone had a while back on
| www-talk that xv could theoretically be used to view inlined images in
| much the same way as ghostview uses ghostscript (by controlling an X
| window ID) -- however, nope, we haven't touched it and I doubt we
| will.  Among other things, we need to be able to have the internal
| image mechanisms we now have anyway (for HDF support) and that we need
| things like the image-as-anchor and image-as-anchor-and-map support.
| 
| Cheers,
| Marc
| 

Eric,
  The justification for using xv to display inlined images is listed right
in your reply: xv displays *many* different image types.  We are using
mosaic to display a database of medical journals we have; however, since
the page images are in TIFF format, I have to convert to GIF them all to
GIF.  
  One of the things we're interested in is services which dynamically
generate an HTML representation of the results of some search or filtering
process.  There is no way of knowing, apriori, what document formats we
might encounter and we would like a client with general image display
capabilities.  Xv fills this role nicely.
  Further, we envision offloading as much of the processing from the client
as possible.  Rather than including local format conversion capability within
the client, we expect to provide a "community of servers" with which the
client can contract to obtain the information it wants, and in a form which
it can use.  By providing a particular server (such as xv) with a window id,
the client retains control of the presentation of the information while
avoiding having to know anything about the format of the data being displayed.
  
Marc,
  Suppose someone (such as ourselves) were able to integrate tooltalk
functionality into mosaic, *and* could provide an HDF- and tooltalk-capable
version of xv (or some such image manipulation package).  Would the technology
fit into your development strategy for mosaic?

Chris
--------------------------------------------------------------------------------
Christopher McRae			mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management	at&t: 415/476-3577
530 Parnassus Avenue, Box 0840	 	fax: 415/476-4653
San Francisco, California 94143

From daemon  Sat Jun 26 21:44:29 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00901; Sat, 26 Jun 93 21:44:31 MET DST
Return-Path: <raisch@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00897; Sat, 26 Jun 93 21:44:29 MET DST
Received: from amber.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01993; Sat, 26 Jun 1993 22:07:43 +0200
Received: by ora.com (5.65c/Spike-2.1)
	id AA06449; Sat, 26 Jun 1993 16:06:24 -0400
Date: Sat, 26 Jun 1993 15:59:37 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Subject: Re: Suggestion for a new URL type 
To: "William M. Perry" <wmperry@nectarine.ucs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <8346.741121113@nectarine.ucs.indiana.edu>
Message-Id: <Pine.3.03.9306261536.R5397-b100000@amber.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


I strongly disagree.  The security issue is inherent in the network, not
in URLs. We should not attempt to scale some moral high ground simply to
stop up some possible security holes, which are not ours to stop up in the
first place. 

The answer to insecure network services is to make them more secure, not
to limit the deployment and usefulness of URLs. 

If a dedicated cracker wishes to break the system, I would suggest that
writing an HTML document, and using that as a lock pick on doors which
have no locks to begin with, would be a marvelous exercise in stupidity.

	</rr>

On Sat, 26 Jun 1993, William M. Perry wrote:

>    What about security?  What if some bozo decided to put a url like:
> 
> tcp://some.generic.news.server:nntp/line#1\nCODE TO FORGE NEWSGROUP\n...
> 
> or
> 
> tcp://some.generic.news.server:25/HELO some.host\nRCPT TO: root\nMAIL
> FROM: stupid.user\nDATA\n Hey bozo - <Very derogative statements> Love
> - stupid.user\n.\nQUIT\n
> 
> And called it something like "Man Pages For Ultrix"?
> 
> Could lead to some interesting discussions with your local sysadmin if
> you clicked on that second one. :)
> 
> I talked with Marc Vanheyningen about this a few months ago, and he
> convinced me that it would be a _BAD THING_ to do something like this.
> Not that there are many bozos out there that would do one of the
> above, but it would only take one or two to cause some real trouble.
> 
> -Bill Perry




From daemon  Sat Jun 26 23:50:31 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02024; Sat, 26 Jun 93 23:50:33 MET DST
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02020; Sat, 26 Jun 93 23:50:31 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17463; Sun, 27 Jun 1993 00:13:45 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA22627; Sat, 26 Jun 1993 17:13:41 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Rob Raisch <raisch@ora.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Suggestion for a new URL type 
In-Reply-To: Your message of "Sat, 26 Jun 1993 15:59:37 -0400."
             <Pine.3.03.9306261536.R5397-b100000@amber.ora.com> 
Date: Sat, 26 Jun 1993 17:13:41 -0500
Message-Id: <22625.741132821@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Rob Raisch
>I strongly disagree.  The security issue is inherent in the network, not
>in URLs. We should not attempt to scale some moral high ground simply to
>stop up some possible security holes, which are not ours to stop up in the
>first place. 
>
>The answer to insecure network services is to make them more secure, not
>to limit the deployment and usefulness of URLs. 
>
>If a dedicated cracker wishes to break the system, I would suggest that
>writing an HTML document, and using that as a lock pick on doors which
>have no locks to begin with, would be a marvelous exercise in stupidity.

I believe we should have an attitude similar to that of MIME regarding
security:

- Security is more important than interoperability
- No additions should be made without a careful review of possible
  security issues
- User agents should present the user with sufficient information for
  the user to avoid possible traps, and should do so in a way that
  even a relatively inexperienced user can understand

Allowing an attacker to cause a victim to telnet to an arbitrary port
on an arbitrary machine and send arbitrary data certainly has some
potential risks.

Scenario:  Someone installs a document with a hyperlink that, when
activated, causes bad mail (say, a death threat) to be mailed to the
President of your organization/university/whatever.  You click on it.
Depending on the implementation of the client, you may or may not see
anything out of the ordinary, and you may or may not understand what
it means.  If the attacker is clever, it's labeled something like
"Click here to see some sample SMTP output."

Three days later, you are brought up on charges of mailing a death
threat.  An investigation of transfer logs, RFC 931 authentication
protocols, or whatever reveal that the message did come from your
account/machine (which is correct; it *did*.)  You have no idea what
happened.  Even if you did suspect a bad hyperlink, the offending HTML
document has been changed (and may have even been rigged by the server
to only look that way for you, and only once.)

That's just an offhand scenario.  It might also be possible to forge
postings (including control postings that do damage, like sendsys or
rmgroup or cancel) or muck with other widely used protocols.

Being able to do that kind of arbitrary URL referencing would have
some advantages, and would lessen the need for gateways; this is good.
My own inclination is that a client would have to take significant
steps to reduce the risk of problems, and that the advantage of this
kind of URL would be outweighed by the added inconvenience of users
being warned of arbitrary transactions for approval (not to mention
the trouble for client writers.)  That's just an inclination, though.
I'd be interested in the results of a security review; maybe it's not
as much a problem as I'm guessing.

- Marc
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here

From daemon  Sun Jun 27 00:05:26 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02158; Sun, 27 Jun 93 00:05:27 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02154; Sun, 27 Jun 93 00:05:26 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19040; Sun, 27 Jun 1993 00:28:40 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03189
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 26 Jun 93 17:28:34 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:wmperry@nectarine.ucs.indiana.edu id AA16184; Sat, 26 Jun 93 17:31:20 -0500
Date: Sat, 26 Jun 93 17:31:20 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306262231.AA16184@wintermute.ncsa.uiuc.edu>
To: Rob Raisch <raisch@ora.com>
Cc: "William M. Perry" <wmperry@nectarine.ucs.indiana.edu>,
        www-talk@nxoc01.cern.ch
Subject: Re: Suggestion for a new URL type 
In-Reply-To: <Pine.3.03.9306261536.R5397-b100000@amber.ora.com>
References: <8346.741121113@nectarine.ucs.indiana.edu>
	<Pine.3.03.9306261536.R5397-b100000@amber.ora.com>
X-Md4-Signature: ce47f66dc37ae4e724caf2d5c070210a

Rob Raisch writes:
> If a dedicated cracker wishes to break the system, I would suggest
> that writing an HTML document, and using that as a lock pick on
> doors which have no locks to begin with, would be a marvelous
> exercise in stupidity.

This is true in and of itself.  However, the true danger is that this
is would be a remarkably efficient way to trick other people into
doing things not in their best interest (as Marc VH points out) and
therefore I think this is a bad road to travel down.  Let's keep such
functionality on the server/gateway side; it is easy enough to write
gateways as it is (and in fact it would be trivial to write a gateway
to accomplish exactly the functionality Rob describes).

Marc


From daemon  Sun Jun 27 00:30:15 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02369; Sun, 27 Jun 93 00:30:16 MET DST
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02365; Sun, 27 Jun 93 00:30:15 MET DST
Received: from lib.ucsf.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23366; Sun, 27 Jun 1993 00:53:30 +0200
Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by library.ucsf.edu with SMTP id AA15827
  (5.67a8/IDA-1.5 for <www-talk@library.ucsf.edu>); Sat, 26 Jun 1993 15:53:19 -0700
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA20483; Sat, 26 Jun 93 18:53:22 EDT
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA13660; Sat, 26 Jun 93 18:53:17 -0400
Date: Sat, 26 Jun 93 18:53:17 -0400
Message-Id: <9306262253.AA13660@theodore-sturgeon>
To: www-talk@library.ucsf.edu, Christopher.McRae@library.ucsf.edu
Subject: Re: tkWWW and Xv


tkWWW uses xloadimage to display images inside the tkWWW executable.
It's actually quite simple to set up.  All you have to do is to pass
the window argument to xloadimage.  The only tricky part is that when
you you are finished displaying the image, you need to display a white
field to free the colormap cells.

tkWWW doesn't support the image tag (yet).  This is because the
current version of tk doesn't support window children of the text
widget.  As soon as the tk gurus have that working........



From daemon  Mon Jun 28 00:40:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09898; Mon, 28 Jun 93 00:40:40 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09894; Mon, 28 Jun 93 00:40:39 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07076; Mon, 28 Jun 1993 01:03:54 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA17898; Sun, 27 Jun 1993 19:03:50 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA03639; Sun, 27 Jun 1993 16:03:49 -0700
Message-Id: <199306272303.AA03639@ora.com>
From: Terry Allen <terry@ora.com>
Date: Sun, 27 Jun 1993 16:03:49 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: SGML baggage (was HTML spec)

Regarding Marc and Dave's exchange a week ago:

It may be that eyes glaze over when the letters SGML are uttered,
but we need it as a way of making rules and drawing limits.  With
SGML I can parse my HTML docs and be confident that any browser
using the HTML DTD (and, let us hope, soon the HTML+ DTD) will
be able to handle my docs and not choke.  They may even
be presented in a way that makes their structure clear by 
typographic means.

All DTDs compromise between semantic and visual markup.  The 
exchange about white space touched on this point.  

So the thing to do is enrich the DTD so that reasonable presentation
demands can be met, relying on semantic tagging rather than visual
tagging as much as feasible, then hide the whole SGML layer from writers
who don't want to hear about SGML.  To the extent the markup of our docs
is semantic rather than visual, we're ahead.  

After all, the non-Postscript alternative is RTF  (snore) . . .

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Mon Jun 28 01:30:10 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10181; Mon, 28 Jun 93 01:30:12 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10177; Mon, 28 Jun 93 01:30:10 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14948; Mon, 28 Jun 1993 01:53:27 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA18954; Sun, 27 Jun 1993 19:53:25 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA03818; Sun, 27 Jun 1993 16:53:24 -0700
Message-Id: <199306272353.AA03818@ora.com>
From: Terry Allen <terry@ora.com>
Date: Sun, 27 Jun 1993 16:53:23 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: One PRE, and entities

Dear Dave:
Sorry not to respond sooner to your post of Monday last, pointing
out HTML+'s style attribute for PRE.  This is okay, but maybe
not the most economical approach. 

I think there are two issues:  1) the spec's definition of 
leading white space and line breaks as significant within PRE, 
and 2) font changes within PRE.  Presently, 1 seems to work just 
fine (at least in xmosaic and lynx, the two browsers I'm using 
for trials), so it should not be necessary to institute a <BR> 
tag to get line breaks within PRE.  Outside PRE one shouldn't 
need them (counterexamples welcome).

Presently, however, PRE is defined as having typewriter type
as its default font, and I think that's wrong.   I'd rather have
to invoke that font (by <CODE>) explicitly, the default font
remaining the same as the main text.  That way I don't need
an <R> tag, which has also been suggested, and when I
have an address to display, I can type:
<PRE>
       Name
       Address
       Telephone.  
</PRE>
and get three indented lines in the main text font.
I think that if the definition of PRE is changed in this way
the style attribute might not be needed.

On another topic you mentioned, charsets, wide fonts, and
outline fonts, what I gleaned from the recent discussion of
Unicode on comp.text.sgml is that it shouldn't wreck the 
SGML mechanism.  For what is not supported by Unicode, should
we choose to go that rather quirky route, the SGML external
entity mechanism is the obvious method, as you point out.  
We already have character entities in the HTML DTD; all that's 
needed is to establish how to reference external entity sets not 
actually included in the HTML+ DTD.  SGML rather envisions that
the entity files are available locally at run time; for WWW it
might be better to be able to indicate the entity files are on
the same machine the document is being fetched from.

And if we can reference external entities, we can do something
requested this week in my office:  use entities to represent
URLs.  Than means 1) URLs themselves may be extracted from the 
main document and collated in a referenced navigational document,
and 2) common link types may be generated automatically:  for
any "Next" link, my &next; entity can refer to a script that 
looks through a list of filenames, chooses the one after the 
current file, and returns that as the URL for the target of 
the link.  

I'l like to suggest that references to external entities go
in the HEAD of the document.

Regards,
.


-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Mon Jun 28 05:30:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11849; Mon, 28 Jun 93 05:30:04 MET DST
Return-Path: <phillips@cs.ubc.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11845; Mon, 28 Jun 93 05:30:02 MET DST
Received: from relay.cdnnet.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18311; Mon, 28 Jun 1993 05:53:18 +0200
Received: by relay.CDNnet.CA (4.1/1.14)
	id AA13505; Sun, 27 Jun 93 20:53:14 PDT
Date: 27 Jun 93 20:53 -0700
From: George Phillips <phillips@cs.ubc.ca>
To: <www-talk@nxoc01.cern.ch>
Message-Id: <5886*phillips@cs.ubc.ca>
Subject: browser execution

I've thought about this business of getting a WWW browser to execute
a program and I've convinced that a new URL scheme is necessary
for some uses.  In particular, you need it if you want to repeatedly
run a program which outputs HTML (or MIME) and generally acts like
a server.

An executable MIME content type is good for "one-shot" executions
(like a "mail developers" link which runs a mailer), but it can't
cover the more dynamic semi-server case.  Why?  Because you need
a MIME document to back up each URL your server outputs that
refers back to the server.  This is fine with an HTTP server, but
for a browser-executed server it means having a file for every
link which defeats the purpose.

A hack to the file: scheme is mostly OK except that it limits executable
things to file: (no big deal with the MIME executable content type),
is not particularly abstract (it points to a specific file) and leaves
the relative URL semantics hanging.  Look at the HTML output of
file:/bin/rn.html%/comp/sources/misc.  If it outputs the anchor
<A HREF=/comp/binaries/mac>mac</A>, does that mean
file:/comp/binaries/mac or file:/bin/rn.html%/comp/sources/mac?
The writer of "rn.html" would certainly prefer the latter over
having to constantly spit out full references, but the former is
what should really happen.  Sure, we could pass in the full URL
to rn.html so it knows the path, but that seems pretty messy.

So how about this:  an "exec:" scheme that looks like:

	exec://encoded-URL/opaque/stuff/like/other/URLs

Semantics: decode the "encoded-URL", grab it and execute it
with the rest of the URL.  I used the  "//" notation so
that executables can ouput "/" rooted URLs without having
to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
We can do the "encoded-URL" any way we like, but suppose that
: -> ; and / -> \.  A full exec: URL might look like:

	exec://file;\bin\rn.html/comp/sources/misc

However, with the MIME executable content type, I'd expect that
most exec: URLs would point to files, so file: would be the default.
Additionally, the browser might have some notion of a PATH for
exec: files (possibly as a first-level security mechanism), so the
whole thing could be shortened to:

	exec://rn.html/comp/sources/misc

I fully realize that these URLs probably won't work between different
sites.  I don't expect WWW servers to be sending you these any time
soon (unless they're trying to delete all your files :-), but
it's possible if some general agreement on the symbolic names
happens.  For instance, it may become agreed that
<A HREF=exec://mailer/mosaic-guys@ncsa>bug report</A> will
fire up some kind of mail program.

While the file: with %/ hack is workable, I think this is better.
What do you think?

From daemon  Mon Jun 28 07:11:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12591; Mon, 28 Jun 93 07:12:00 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12587; Mon, 28 Jun 93 07:11:58 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03645; Mon, 28 Jun 1993 07:35:10 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA27645; Mon, 28 Jun 93 00:35:06 -0500
Message-Id: <9306280535.AA27645@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: browser execution 
In-Reply-To: Your message of 27 Jun 93 20:53:00 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 28 Jun 1993 00:35:06 -0500
From: Tony Sanders <sanders@bsdi.com>

> for some uses.  In particular, you need it if you want to repeatedly
> run a program which outputs HTML (or MIME) and generally acts like
> a server.
...
> An executable MIME content type is good for "one-shot" executions
> (like a "mail developers" link which runs a mailer), but it can't
> cover the more dynamic semi-server case.  Why?  Because you need
> a MIME document to back up each URL your server outputs that
> refers back to the server.  This is fine with an HTTP server, but
> for a browser-executed server it means having a file for every
> link which defeats the purpose.
SAS strikes again (server aversion syndrome :-)

FYI: Here is how using content-type might work for your example of a
pseudo-newsreader (using a server of course).

    <A HREF="http://server/rn.html">drink me</A>

on selection returns the document:

    content-type: application/x-csh
    ... whatever you wanted rn.html to do
    ... links can look like <A HREF="http://server/article/####">read me</A>

http://server/article/#### returns:

    content-type: application/x-csh
    ... whatever you wanted rn.html to do with the #### argument

So I argue we should figure out to have the browser talk to a local server
rather than figure out how to encode arbitary commands in the URL.

My reasoning:
  o Browsers cannot change on a whim, because for the Web to be truly
    useful to the user community at large all browsers must support the
    **same** set of features (to a large extent anyway).
  o Therefore we **must** have a definition for the browser that is simple
    and complete such that any features you might ever want can be done
    in a server.

    So why the SAS that seems to be so prevalent?  Instead of hacking
    things into the browser we should be looking for ways to extend the
    browser such that servers can do those tasks, but everyone seems to
    be heading the opposite direction.  Maybe this is something we
    can take up at the workshop (what should go in the server and what
    should we build-in to the browser).

I'm not a purist or anything, I think it's fine if we want the browser to
support things like gopher and ftp directly but at some point we are going
to have to draw the line if we want most browsers to support a common
set of features (even <IMG> is a good example of this problem).

--sanders

From daemon  Mon Jun 28 08:59:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13355; Mon, 28 Jun 93 08:59:50 MET DST
Return-Path: <phillips@cs.ubc.ca>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13350; Mon, 28 Jun 93 08:59:47 MET DST
Received: from relay.cdnnet.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25193; Mon, 28 Jun 1993 09:23:01 +0200
Received: by relay.CDNnet.CA (4.1/1.14)
	id AA16467; Mon, 28 Jun 93 00:22:58 PDT
Date: 28 Jun 93  0:22 -0700
From: George Phillips <phillips@cs.ubc.ca>
To: <www-talk@nxoc01.cern.ch>
In-Reply-To: <9306280535.AA27645@austin.BSDI.COM>
Message-Id: <5888*phillips@cs.ubc.ca>
Subject: Re: browser execution 

>SAS strikes again (server aversion syndrome :-)
>
>So I argue we should figure out to have the browser talk to a local server
>rather than figure out how to encode arbitary commands in the URL.

Besides making the problem harder and adding a level of indirection,
I don't see how talking to a local server is any different.  Instead
of figuring out how to encode a command into the URL, you have to figure
out how to encode a command into an application/x-csh content type.
The content type isn't going to be any more portable than the URL
encoding and it may even be harder to do security checks on it.

>My reasoning:
>  o Browsers cannot change on a whim, because for the Web to be truly
>    useful to the user community at large all browsers must support the
>    **same** set of features (to a large extent anyway).
>  o Therefore we **must** have a definition for the browser that is simple
>    and complete such that any features you might ever want can be done
>    in a server.

I'd hardly call executable content types any more supportable by all
browsers than exec: URLs.  They're both inherently local things if
you want side effects and that has no effect to the community at
large since they won't see them.  Not all the browsers are equal
right now, which is healthy progress in action -- you can't raise the
bar all at once.  For that matter, exec: URLs would be more uniform
since they operate at a lower level.

>    So why the SAS that seems to be so prevalent?  Instead of hacking
>    things into the browser we should be looking for ways to extend the
>    browser such that servers can do those tasks, but everyone seems to
>    be heading the opposite direction.  Maybe this is something we
>    can take up at the workshop (what should go in the server and what
>    should we build-in to the browser).

Servers are not _that_ easy to write.  They are if you're running UNIX
and you have either inetd.conf privileges or know how to do sockets.
Who knows what you'd have to do under VMS or MVS and you just can't
do them under MS-DOS.  On the other hand, writing a program which
dumps some HTML to a file is easy and possible under all systems.
It's very similar to adding to a server, but anybody, not just the
server administrator can do it and they can share with other non-privileged
users.

Even if you can easily run a server, you've got some security problems
to deal with.  Having a browser that will execute code (or URLs, whatever)
from documents is a little scary; having a server that anyone can
connect to execute code is really scary.  With the browser executing
code you leverage off the normal system authentication.  With a server,
you have to re-invent that.  Sure, these features are coming and
that's good; but you're building up an awful lot of stuff to solve
a simple problem.

>I'm not a purist or anything, I think it's fine if we want the browser to
>support things like gopher and ftp directly but at some point we are going
>to have to draw the line if we want most browsers to support a common
>set of features (even <IMG> is a good example of this problem).

Well, if you want to add features you have a choice.  Either make it
harder for the browser writers or make it harder for the server writers.
I maintain that the exec: URL scheme makes it a little harder for
the browser writers but is a boon for server writers since it truly
makes it easy to write a server (just like the simple inetd scripts,
but you don't need privilege).

From daemon  Mon Jun 28 14:42:34 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17673; Mon, 28 Jun 93 14:42:37 MET DST
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17669; Mon, 28 Jun 93 14:42:34 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24585; Mon, 28 Jun 1993 15:05:51 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA21671; Mon, 28 Jun 1993 08:05:49 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: browser execution
Date: Mon, 28 Jun 1993 08:05:49 -0500
Message-Id: <21669.741272749@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Responding to a few things by various people...

George Phillips <phillips@cs.ubc.ca> says:
>Semantics: decode the "encoded-URL", grab it and execute it
>with the rest of the URL.  I used the  "//" notation so
>that executables can ouput "/" rooted URLs without having
>to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
>We can do the "encoded-URL" any way we like, but suppose that
>: -> ; and / -> \.  A full exec: URL might look like:
>
>	exec://file;\bin\rn.html/comp/sources/misc

I'd be more inclined to encode the URL with the general percent escape
notation, but that's just me.

(Unrelated question:  Consider the URL http://foo/search?bar%2Bbaz --
how many search keywords does it have, and what are they?  My
inclination is to interpret it as one keyword "bar+baz", though that's
inconvenient for the server since it can't just do all the percent
substitution immediately upon receiving the object.)

>However, with the MIME executable content type, I'd expect that
>most exec: URLs would point to files, so file: would be the default.
>Additionally, the browser might have some notion of a PATH for
>exec: files (possibly as a first-level security mechanism), so the
>whole thing could be shortened to:
>
>	exec://rn.html/comp/sources/misc

This sounds a bit more portable and a bit less anxiety-inducing as far
as security is concerned.  A special directory (or set of aliases, or
something) of safe commands described with somewhat abstract names
could work out OK.  The result is that your local commands end up of
the form:

	exec://mail-rfc822/x-mosaic@ncsa.uiuc.edu

or something like that.  Whether this is better than the form:

	mail-rfc822://x-mosaic@ncsa.uiuc.edu

(or something like that) is debatable either way; I think either is
probably workable as long as the number of different things you can do
that way is rather small, considered carefully, and centrally
registered in some fashion.

Tony Sanders <sanders@bsdi.com> responds:
>SAS strikes again (server aversion syndrome :-)
>
>    content-type: application/x-csh

No!  Anything but the Cshell!  Nobody move, or I post Tom Christiansen
to the mailing list! :-)

>My reasoning:
>  o Browsers cannot change on a whim, because for the Web to be truly
>    useful to the user community at large all browsers must support the
>    **same** set of features (to a large extent anyway).
>  o Therefore we **must** have a definition for the browser that is simple
>    and complete such that any features you might ever want can be done
>    in a server.

I agree here, which is why I'm hesitant to extend things to a general
execution type since programs (particularly, say, cshell programs) are
inherintly non-portable.  I suppose we could try to agree on a
language to specify programs to be executed in.  Such a language would
need a number of attributes:

- Highly portable, will run on UNIX boxes, DOS boxes, Macs, whatever
- Freely available
- Can work in a "paranoid" fashion whereby it is reasonably safe to
  execute untrusted code with it

I'm not sure such a language can even exist.  (Perl meets the first
two criteria, at least.)  I'm pretty sure that inventing it is more
than we can or should try to do.

>I'm not a purist or anything, I think it's fine if we want the browser to
>support things like gopher and ftp directly but at some point we are going
>to have to draw the line if we want most browsers to support a common
>set of features (even <IMG> is a good example of this problem).

I concur; one problem is that most people will generally use just one
browser and thus they'll write documents assuming that everyone else
uses it too.  I've seen documents that rely on IMG too much, given the
number of browsers that don't support it.

George Phillips <phillips@cs.ubc.ca> answers:
>Servers are not _that_ easy to write.  They are if you're running UNIX
>and you have either inetd.conf privileges or know how to do sockets.
>Who knows what you'd have to do under VMS or MVS and you just can't
>do them under MS-DOS.  On the other hand, writing a program which
>dumps some HTML to a file is easy and possible under all systems.
>It's very similar to adding to a server, but anybody, not just the
>server administrator can do it and they can share with other non-privileged
>users.

Servers _can be_ easy to write.  A base server could allow you to
easily add new functionality of the variety you discuss without
needing to understand the details of UNIX sockets (not that they're
really that complicated anyway.)  Plexus, for example, allows this.
Don't confuse limitations of particular implementations with
limitations of HTTP servers in general.

>Even if you can easily run a server, you've got some security problems
>to deal with.  Having a browser that will execute code (or URLs, whatever)
>from documents is a little scary; having a server that anyone can
>connect to execute code is really scary.  With the browser executing
>code you leverage off the normal system authentication.  With a server,
>you have to re-invent that.  Sure, these features are coming and
>that's good; but you're building up an awful lot of stuff to solve
>a simple problem.

Servers can run without privilige; ours runs as id "daemon" and
doesn't have the priv to do much other than dequeue other people's
print jobs.  Surely webmasters don't run their HTTP server as root?

Browsers, on the other hand, have to run as users and are thus capable
of harming their users; I find using "normal system authentication"
(as it exists on most machines) to run code in this kind of situation
highly undesirable.

>Well, if you want to add features you have a choice.  Either make it
>harder for the browser writers or make it harder for the server writers.
>I maintain that the exec: URL scheme makes it a little harder for
>the browser writers but is a boon for server writers since it truly
>makes it easy to write a server (just like the simple inetd scripts,
>but you don't need privilege).

Except that what has been written isn't a server at all, it's just a
program.  It doens't provide a service to anyone except the person (or
small group of people) who have examined it, decided it safe, and
placed it on their list of commands for which exec:ing is permissible.
(unless this procedure is not used, in which case it's a security hole
you could drive an aircraft carrier through.)

- Marc
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here

From daemon  Mon Jun 28 16:03:09 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19187; Mon, 28 Jun 93 16:03:11 MET DST
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA19183; Mon, 28 Jun 93 16:03:09 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12731; Mon, 28 Jun 1993 16:26:26 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA29805; Mon, 28 Jun 1993 09:26:14 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Encapsulating HTTP parts in MIME
Date: Mon, 28 Jun 1993 09:26:12 -0500
Message-Id: <29789.741277572@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Following is an updated and (I think) better version of my earlier
suggestion.  I have also posted it to the newsgroup; I'd prefer if
people who can access it discuss it there rather than in this mailing
list since it's crossposted so the MIME community can also contribute
suggestions (and since it's not really possible to cross-post on
mailing lists.)

HyperText Transfer Protocol (HTTP) is a transaction oriented protocol
based on request-response.  I believe there are some advantages to
being able to consider these components (the request and the response)
as MIME content-types, so they may be forwarded, gatewayed,
encapsulated, authenticated, encrypted, and the like via standard MIME
techniques.  Since both the request and the response in HTTP/1.0 are
already very close to MIME messages, I believe that "message" is the
appropriate primary content-type.

There are two applications which most readily come to mind for this
kind of definition:

- Allowing the full power of HTTP/1.0 to be utilized via a mailbot,
  for users who cannot use HTTP directly due to limitations of dialup
  links like UUCP, firewalls, etc.
- Allow an HTTP request or response to have some or all of the
  security services made possible for MIME objects by the PEM-MIME
  inter-operation standard (still in draft right now.)

Significant concerns I have in mind:

- As much as possible, the new system should work smoothly with both
  HTTP/1.0 and HTTP/0.9.
- MIME gateways should be able to handle these messages (e.g. change
  the Content-Transfer-Encoding as necessary for various transports)
  smoothly.

A tentative method:

Define a request as content-type "message/http-request".

Required parameters:
  method:	the method of the request (e.g. "GET")
  object:	the object of the request (e.g. "/foo/bar/baz.html")
  version:	which version of HTTP (e.g. "HTTP/1.0", or is it "HTRQ/1.0" ?)

Optional parameters:
  address(?):	the address of the HTTP server (e.g. "info.cern.ch:80")
  id:		a unique identifier to be returned with the response
		(e.g. "12345@foo.bar")

The request itself (minus the first line, which is given in the
required parameters) follows.  Obviously, in HTTP/0.9, these
parameters contain the whole request and thus the content will always
be empty, while in HTTP/1.0 these parameters contain a MIME message
(possibly with some additional RFC822-style headers.)
 
Define as another content type "message/http-response".

Required parameters:
  version:	the version of the response (e.g. "HTTP/1.0")

Optional parameters:
  status:	the numeric result (mandatory in HTTP/1.0 only, e.g. "200")
  reason:	the textual result (also HTTP/1.0 only, e.g. "OK")
  in-reply-to:	the unique identifier from the "id" parameter of the
		http-request for which this is the response

The body contains the remainder of the response; in HTTP/1.0, it will
consist of an MIME message (possibly with some additional
822-compliant headers.)  In HTTP/0.9 it will not consist of any
headers; therefore, a blank line will precede the text (the blank line
is the boundary between the lines of headers [of which there are none]
and the body of the encapsulated message.)

WHY TO DO IT THIS WAY
---------------------

Since message/rfc822 is the primary subtype of message, it seems
reasonable that user agents and (more importantly) gateways should
generally treat unknown subtypes of messages as such.

Hence, the first line of information from both the request and the
response has been removed from the body and placed in the parameters;
the first line is not syntactically a legal 822 header, and thus would
likely confuse gateways.  Gateways need to be able to understand this
subtype properly, so that they can do things like change the encoding
as necessary.  (HTTP goes over direct sockets, and thus normally
"binary" is always available as an encoding, but this will not be the
case when using a mailbot.)  Am I correct in supposing that this
method will make gateway handling relatively painless?

Putting these things into parameters doesn't feel very philosophically
clean, though.  I suppose I could instead make a part like
"multipart/http-request" with two parts, one the "header" (the leading
line containing method, object and version) and the second being the
822 compliant message.  I think the parameter method seems simpler to
understand, implement, and use (though I don't know which is
philosophically cleaner.)

I'm not really sure how to deal with the case of HTTP/0.9 vs. HTTP/1.0
responses, since the latter is a MIME message while the former is not.
Putting the blank line as "end of headers" in 0.9 is the best I can
think of to still allow some generality and give gateways a chance to
do the right thing regarding encoding; I'd love to hear better
suggestions.

Arguably, putting an id and in-reply-to parameter is redundant with
their similar headers in the message itself.  However, normally an MUA
does not make these headers available to the originating and receiving
programs, while parameters normally are.

Obviously, it is best to respond with the same version as the request,
it is acceptable to respond with an earlier version than the request,
and it is forbidden to respond with a later version than the request.

SOME EXAMPLES
-------------

A simple dialogue with a mailbot to do an HTTP/1.0 poll:

  To: mailbot
  From: joe_user@somewhere.com
  MIME-Version: 1.0
  Content-Type: message/http-request; address="info.cern.ch:80"; 
		method="GET"; object="/hypertext/WWW/TheProject.html";
		version="HTTP/1.0"; id="1234@somewhere.com"

  From: joe_user@somewhere.com
  Accept: text/plain; text/html; application/postscript; image/gif
  User-Agent: 
  [ this is a blank line, and it is significant ]

and the mailbot would respond with something like this:

  From: mailbot
  To: joe_user@somewhere.com
  MIME-Version: 1.0
  Content-Type: message/http-response; version="HTTP/1.0";
		in-reply-to="1234@somewhere.com"; status=200;
		reason="Document follows"

  MIME-Version: 1.0
  Content-Type: text/html
		
  <HEADER>
  <TITLE>The World Wide Web project</TITLE>
  <NEXTID N="59">
  </HEADER>
  <BODY>
  <H1>World Wide Web</H1>The WorldWideWeb (W3) is a wide-area<A
  [ ... ]

Naturally, these objects could be encapsulated inside other objects,
though the only use for that which I can think of would be making the
request or response the secured object of a multipart/pem message.

Any comments, reactions, flames, or other thoughts?
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here

From daemon  Mon Jun 28 18:51:34 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22807; Mon, 28 Jun 93 18:51:38 MET DST
Return-Path: <m.koster@nexor.co.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22801; Mon, 28 Jun 93 18:51:34 MET DST
Received: from lancaster.nexor.co.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19478; Mon, 28 Jun 1993 19:14:49 +0200
Message-Id: <9306281714.AA19478@dxmint.cern.ch>
Received: from nexor.co.uk (actually victor.nexor.co.uk) 
          by lancaster.nexor.co.uk with SMTP (PP);
          Mon, 28 Jun 1993 18:14:35 +0100
To: www-talk@nxoc01.cern.ch, timbl@nxoc01.cern.ch
Cc: webmaster@nexor.co.uk
Subject: Warchie is moving to ArchiePlex
Date: Mon, 28 Jun 1993 18:13:28 +0100
From: Martijn Koster <m.koster@nexor.co.uk>


Hi all,

Just a quick note to say that Warchie, the full-hypertext Archie gateway,
is moving. I rewrote Warchie in Perl, called it ArchiePlex (becuase it
fits into Plexus so nicely, and because nobody knew how to pronounce
Warchie), and installed it under http://web.nexor.co.uk/archieplex.

The "List of Hypertext Archie Servers" can now be reached from
http://web.nexor.co.uk/archie.html. This document is probably the 
best one to link to.

The Warchie service on web.nexor.co.uk:1993 will be turned off shortly,
and the Warchie documentation will probably be moved off-line.

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A=Mark400; 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

From daemon  Mon Jun 28 19:02:45 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23064; Mon, 28 Jun 93 19:02:47 MET DST
Return-Path: <weber@eitech.eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23060; Mon, 28 Jun 93 19:02:45 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21291; Mon, 28 Jun 1993 19:26:02 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA29135; Mon, 28 Jun 93 12:25:33 -0500
Received: from eitech.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA06661; Mon, 28 Jun 93 10:20:02 PDT
Message-Id: <9306281720.AA06661@eitech.com>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch, ekr@eitech.eitech.com, ams@eitech.eitech.com,
        jay@eitech.eitech.com
Subject: Re: Encapsulating HTTP parts in MIME 
In-Reply-To: Your message of "Mon, 28 Jun 1993 09:26:12 CDT."
             <29789.741277572@moose.cs.indiana.edu> 
Date: Mon, 28 Jun 1993 10:19:55 -0700
From: "Jay C. Weber" <weber@eitech.eitech.com>

(My news poster choked when I tried to followup via news; feel free to
forward this to comp.infosystems.www, comp.mail.mime)

In article <29596.741277437@moose.cs.indiana.edu> Marc VanHeyningen <mvanheyn@cs.indiana.edu> writes:
>HyperText Transfer Protocol (HTTP) is a transaction oriented protocol
>based on request-response.  I believe there are some advantages to
>being able to consider these components (the request and the response)
>as MIME content-types, so they may be forwarded, gatewayed,
>
>- Allowing the full power of HTTP/1.0 to be utilized via a mailbot,
>  for users who cannot use HTTP directly due to limitations of dialup
>  links like UUCP, firewalls, etc.

To implement this, check out the ServiceMail Toolkit, a package that
helps in constructing mailbots that speak MIME.  You'll find it in
the metamail contrib distribution (try to get a recent version with
ServiceMail 2.0).  I'm the primary author, I'd be glad to help someone
figure out how to use it for this application.  (I'd been planning to
do it myself.)

ServiceMail installations usually use the Subject: field to contain
the "method" and its parameters.  Especially if you put it in the
embedded message/http-request, this fits well.

>- Allow an HTTP request or response to have some or all of the
>  security services made possible for MIME objects by the PEM-MIME
>  inter-operation standard (still in draft right now.)

We're in the middle of adding PEM-MIME support to ServiceMail; we're
directly supporting symmetric-key, in the PEM-MIME style.  Public-key
is still too hazy with respect to licensing.

Jay Weber
Enterprise Integration Technologies

From daemon  Tue Jun 29 00:04:15 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29270; Tue, 29 Jun 93 00:04:17 MET DST
Return-Path: <kevinh@pulua.hcc.hawaii.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29266; Tue, 29 Jun 93 00:04:15 MET DST
Received: from pulua.hcc.Hawaii.Edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07477; Tue, 29 Jun 1993 00:27:35 +0200
Received: by pulua.hcc.Hawaii.Edu (4.1/SMI-4.1)
	id AA00478; Mon, 28 Jun 93 12:25:59 HST
Date: Mon, 28 Jun 93 12:25:59 HST
From: kevinh@pulua.hcc.hawaii.edu (Kevin 'Kev' Hughes)
Message-Id: <9306282225.AA00478@pulua.hcc.Hawaii.Edu>
To: www-talk@nxoc01.cern.ch
Subject: re: WWW usage


A few topics ago, Tony Sanders (sanders@bsdi.com) was talking about
the possibility of tracking WWW usage. I don't know what sort of mechanisms
will be built into future servers, but I made a little C program that
spits out the type of report he mentioned, such as:

Date: Mon Jun 28 08:20:39 GMT 1993
Server: http://pulua.hcc.hawaii.edu/
Requests last 7 days: 5427
Unique hosts last 7 days: 287
Total unique hosts: 1020
Total requests: 14657
Total days of service: 34

...it does weekly, daily, and comprehensive reports too. It's at

http://pulua.hcc.hawaii.edu/files/getsites.html

if anyone's interested.

	-- Kevin Hughes
	   kevinh@pulua.hcc.hawaii.edu

From daemon  Tue Jun 29 01:06:55 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29970; Tue, 29 Jun 93 01:06:57 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29966; Tue, 29 Jun 93 01:06:55 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16172; Tue, 29 Jun 1993 01:30:13 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA01128; Mon, 28 Jun 93 18:30:09 -0500
Message-Id: <9306282330.AA01128@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: HTML+ and browser functionality
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 28 Jun 1993 18:30:08 -0500
From: Tony Sanders <sanders@bsdi.com>

Hey, I remember a while back someone suggested having certain standard
links in the document (forw back up top).  Instead of hardcoding these
how about just having a control panel element that might work like this:

<CONTROL>
    <UL>
	<LI> <A ...>Click here</A>
	<LI> <A ...>Drink me</A>
	<LI> <A ...>Go away</A>
    </UL>
</CONTROL>

Then a clever browser can do whatever it wants to render that section of
code (the idea being that it could stick it in a window so it's always
available for navigation).  By default it can just render in place.

This has the advantage of allowing us to experiment with different control
structures.  FBUT is ok for some documents but I can see applications where
other navigation schemes would be useful (e.g., NSEW in maps).

Any comments?  Sorry if someone already "invented" this, I didn't see anything
in the HTML+ DTD_ and wanted get peoples comments.

BTW: I would like to give a big thanks to Dave Raggett for doing a great
job on the HTML+ DTD_.  From our random arguments and outrageous requets
(tables, forms, ...) Dave has really pulled HTML+ together.  Any idea when
it'll be stable enough to start developing browsers for?

Looking forward to the Workshop next month,
--sanders_

.. _sanders http://www.bsdi.com/hyplan/sanders.html
.. _DTD ftp://info.cern.ch/pub/www/dev/htmlplus.dtd

From daemon  Tue Jun 29 01:31:52 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00369; Tue, 29 Jun 93 01:31:54 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00365; Tue, 29 Jun 93 01:31:52 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21437; Tue, 29 Jun 1993 01:55:09 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA29108; Mon, 28 Jun 1993 19:55:05 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA01319; Mon, 28 Jun 1993 16:55:04 -0700
Message-Id: <199306282355.AA01319@ora.com>
From: Terry Allen <terry@ora.com>
Date: Mon, 28 Jun 1993 16:55:04 PDT
In-Reply-To: Tony Sanders <sanders@bsdi.com>
       "HTML+ and browser functionality" (Jun 28,  6:30pm)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: sanders@bsdi.com
Subject: Re: HTML+ and browser functionality
Cc: www-talk@nxoc01.cern.ch

The CONTROL panel would certainly help me.  But I'd want the 
addresses of the links to be outside the document, and the
entries in the CONTROL panel to work like entities.  You'd
say somewhere in the HEAD section that the standard links
you wanted were NEXT PREVIOUS UPALEVEL, and only those links
would appear in the browser (frame?).  

For the browser to know where NEXT PREVIOUS etc are, it needs
a navigational info file; that file has to be referred to
in the HEAD section where these links are specified.  Does
all this resolve to a URL type?

Regards,

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Tue Jun 29 02:02:00 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00739; Tue, 29 Jun 93 02:02:05 MET DST
Return-Path: <mitra@pandora.sf.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00733; Tue, 29 Jun 93 02:02:00 MET DST
Received: from pandora.sf.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24922; Tue, 29 Jun 1993 02:25:18 +0200
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: WWW and OpenView
Organization: Pandora Systems
Date: Tue, 29 Jun 1993 00:25:12 GMT
Message-Id: <C9Cx61.1Mr@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.2 PL0]
Apparently-To: <www-talk@nxoc01.cern.ch>



From daemon  Tue Jun 29 02:04:32 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00795; Tue, 29 Jun 93 02:04:34 MET DST
Return-Path: <mitra@pandora.sf.ca.us>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00791; Tue, 29 Jun 93 02:04:32 MET DST
Received: from pandora.sf.ca.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25056; Tue, 29 Jun 1993 02:27:51 +0200
Newsgroups: list.www-talk
Path: mitra
From: mitra@path.net (Mitra)
Subject: XMosaic and OpenView
Organization: Pandora Systems
Date: Tue, 29 Jun 1993 00:27:46 GMT
Message-Id: <C9CxAB.1rL@pandora.sf.ca.us>
X-Newsreader: TIN [version 1.2 PL0]
Apparently-To: <www-talk@nxoc01.cern.ch>


Is there any way to run Xmosaic on a sun running openview (as shipped by sun) 
rather than a full X system - 

Failing that can someone mail me a list of what I need to get Xmosaic running, 
as a hint - I'd rather not have to ftp the whole of X over a 9600 baud
link to my development machine :-)

- Mitra


From daemon  Tue Jun 29 02:10:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00884; Tue, 29 Jun 93 02:10:44 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00880; Tue, 29 Jun 93 02:10:42 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26767; Tue, 29 Jun 1993 02:34:00 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA01399; Mon, 28 Jun 93 19:33:57 -0500
Message-Id: <9306290033.AA01399@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML+ and browser functionality 
In-Reply-To: Your message of Mon, 28 Jun 93 16:55:04 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 28 Jun 1993 19:33:56 -0500
From: Tony Sanders <sanders@bsdi.com>

Terry Allen (terry@ora.com) writes:
> The CONTROL panel would certainly help me.  But I'd want the 
> addresses of the links to be outside the document, and the
> entries in the CONTROL panel to work like entities.  You'd
> say somewhere in the HEAD section that the standard links
> you wanted were NEXT PREVIOUS UPALEVEL, and only those links
> would appear in the browser (frame?).  
> 
> For the browser to know where NEXT PREVIOUS etc are, it needs
> a navigational info file; that file has to be referred to
> in the HEAD section where these links are specified.  Does
> all this resolve to a URL type?

But then you can't control the look of the nav panel (hey <NAV>),
e.g., I want to use by bookmark icon for navigation:

<NAV> 
<A HREF="/bookmark/server_bookmark/demo.html:Index_Page/demo.html:Index_Page/page2.html:Page_2">
<IMG SRC="/server/bookmark/bookmark.xbm" ISMAP></A>
</NAV>

Can you explain why you want the links to be "outside the document"?
I don't understand how this makes it better (I assume it has something
to do with autonavigation without using a server or something).
I'm not against supporting that but we need to figure out how to make
it work while still allowing complete customization of the NAV panel
(perhaps via a REL in the link <A REL="nav" HREF="http:...">???).

I have no idea where this is going.  Terry, since you know what you
want can you see how this might be accomplished?

--sanders

From daemon  Tue Jun 29 08:36:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04272; Tue, 29 Jun 93 08:36:14 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04267; Tue, 29 Jun 93 08:36:12 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26356; Tue, 29 Jun 1993 08:59:32 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28177
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 29 Jun 93 01:59:30 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA24314; Tue, 29 Jun 93 02:02:20 -0500
Date: Tue, 29 Jun 93 02:02:20 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306290702.AA24314@wintermute.ncsa.uiuc.edu>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: browser execution
In-Reply-To: <21669.741272749@moose.cs.indiana.edu>
References: <21669.741272749@moose.cs.indiana.edu>
X-Md4-Signature: fad2e018398d81cc34a5a9def1f694e0

> >Servers are not _that_ easy to write.  They are if you're running UNIX
> >and you have either inetd.conf privileges or know how to do sockets.
> >Who knows what you'd have to do under VMS or MVS and you just can't
> >do them under MS-DOS.  On the other hand, writing a program which
> >dumps some HTML to a file is easy and possible under all systems.
> >It's very similar to adding to a server, but anybody, not just the
> >server administrator can do it and they can share with other non-privileged
> >users.

As a side note, xinetd -- recently posted to comp.sources.unix
-- allows users to run a (turbocharged version of) inetd
without root privileges.

> >Even if you can easily run a server, you've got some security problems
> >to deal with.  Having a browser that will execute code (or URLs, whatever)
> >from documents is a little scary; having a server that anyone can
> >connect to execute code is really scary.  With the browser executing
> >code you leverage off the normal system authentication.  With a server,
> >you have to re-invent that.  Sure, these features are coming and
> >that's good; but you're building up an awful lot of stuff to solve
> >a simple problem.
> 
> Servers can run without privilige; ours runs as id "daemon" and
> doesn't have the priv to do much other than dequeue other people's
> print jobs.  Surely webmasters don't run their HTTP server as root?
> 
> Browsers, on the other hand, have to run as users and are thus capable
> of harming their users; I find using "normal system authentication"
> (as it exists on most machines) to run code in this kind of situation
> highly undesirable.

Having browsers execute code is *very* scary.  Servers generally run
(or should run -- no reason not to) as userid 'nobody', and as such
can cause practically no damage to anything.  In any case, server
writers have much more knowledge about what's going to happen and what
could happen while writing a server than client users do while just
randomly clicking hyperlinks.  I don't see as there's any reason to
think that client-side execution is safer.

> >Well, if you want to add features you have a choice.  Either make it
> >harder for the browser writers or make it harder for the server writers.
> >I maintain that the exec: URL scheme makes it a little harder for
> >the browser writers but is a boon for server writers since it truly
> >makes it easy to write a server (just like the simple inetd scripts,
> >but you don't need privilege).
> 
> Except that what has been written isn't a server at all, it's just a
> program.  It doens't provide a service to anyone except the person (or
> small group of people) who have examined it, decided it safe, and
> placed it on their list of commands for which exec:ing is permissible.
> (unless this procedure is not used, in which case it's a security hole
> you could drive an aircraft carrier through.)

What he said.

Marc


From daemon  Tue Jun 29 08:43:24 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04358; Tue, 29 Jun 93 08:43:25 MET DST
Return-Path: <RASHTY@vms.huji.ac.il>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04354; Tue, 29 Jun 93 08:43:24 MET DST
Received: from cearn.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28465; Tue, 29 Jun 1993 09:06:44 +0200
Received: from CEARN.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
   with BSMTP id 3987; Tue, 29 Jun 93 09:06:39 SET
Received: from HUJIVMS (NJE origin MAILER@HUJIVMS) by CEARN.CERN.CH (LMail V1.1d/1.7f) with BSMTP id 6756; Tue, 29 Jun 1993 09:06:39 +0200
Received: by HUJIVMS via SMTP(128.139.4.11) (HUyMail-V6l);
          Tue, 29 Jun 93 10:06:44 +0300
Received: by VMS.HUJI.AC.IL (HUyMail-V6l); Tue, 29 Jun 93 10:06:40 +0200
Date:     Tue,  29 Jun 93 10:06 +0200
Message-Id: <29060093100639@VMS.HUJI.AC.IL>
From: Dudu Rashty +972-2-584848 <RASHTY@vms.huji.ac.il>
To: www-talk@nxoc01.cern.ch
Subject:  EARN GUIDE TO NETWORK RESOURCES TOOLS

Hi

the European Academic & Research Network (EARN) has published a guide for
network resources tools,  The guide was published in May 1993.

A simple hypertext version is avaiable from
http://www.huji.ac.il/www_help/earn.html


Thanks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:                                                      **** Thanks !! **** :
: Dudu Rashty                Rashty@Vms.Huji.Ac.Il         __o     o__     :
: Computation Center         Bitnet:Rashty@HUJIVMS       _ \<,_   _.>/ _   :
: The Hebrew University      Phone:  +972-2-584397      (_)/ (_) (_) \(_)  :
: Jerusalem 91904, ISRAEL.   Fax:    +972-2-527349       D    u    d    u  :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From daemon  Tue Jun 29 11:55:25 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06344; Tue, 29 Jun 93 11:55:27 MET DST
Return-Path: <M.T.Hamilton@lut.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06340; Tue, 29 Jun 93 11:55:25 MET DST
Received: from avarice.lut.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09762; Tue, 29 Jun 1993 12:18:44 +0200
Received: from genie.lut.ac.uk by avarice.lut.ac.uk 
          id <19883-0@avarice.lut.ac.uk>; Tue, 29 Jun 1993 11:23:07 +0100
Date: Tue, 29 Jun 1993 11:22:11 +0100 (BST)
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Subject: MIME mailcap entry for HTML, using TkWWW
To: www-talk@nxoc01.cern.ch
Message-Id: <Pine.3.07.9306291110.F19312-a100000@avarice>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: M.T.Hamilton@lut.ac.uk

I don't recall having seen anything like this, so here goes...

  text/x-html; xmosaic %s
  text/x-html; xmosaic %s; compose=htmlcompose %s;\
     description="HTML Hypertext generated by tkWWW 0.8"

Where htmlcompose is... 

  #!/bin/sh

  WWW_HOME=$1.html export WWW_HOME

  cat >$WWW_HOME <<!!EOF!!
  <title>HTML generated for `whoami`@`hostname`.`domainname` by TkWWW</title>
  <h1>Type your message in here!</h1>
  !!EOF!!

  tkWWW -wwwnoinfo
  mv $1.html $1

The only drawback with using tkWWW this way is that you have
to go through the "generate source" & "save source" dialogs
to get your HTML exported.

Suggestion:

One way to get around this would be to have a command line option 
(say -wwwsource) that told it just to act as an HTML editor, reading
in $1 and dumping the exported HTML automatically on exiting.

Martin

PS An "insert file" option would be quite nice too!




From daemon  Tue Jun 29 12:15:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06496; Tue, 29 Jun 93 12:16:00 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA06492; Tue, 29 Jun 93 12:15:59 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA15800; Tue, 29 Jun 1993 12:39:19 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA05872
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Tue, 29 Jun 93 05:39:16 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA25390; Tue, 29 Jun 93 05:42:06 -0500
Date: Tue, 29 Jun 93 05:42:06 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306291042.AA25390@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Cc: mosaic-x@ncsa.uiuc.edu, robm@ncsa.uiuc.edu, hardin@ncsa.uiuc.edu
Subject: NCSA httpd 0.4 released
X-Md4-Signature: ef0652d108a79c4a4f6661df6cb97ef2

NCSA httpd version 0.4 is now available at:

  ftp://ftp.ncsa.uiuc.edu/Mosaic/ncsa_httpd/ncsa-httpd-0.4.tar.Z

This server has the following features:

    o Directory index support.
    o Access logging.
    o Group annotation server support.
    o Drop-in Gopher replacement support.
    o Simple and lightweight; easy to compile.
    o Clean; returns files without ever mutating their data.

Changes from 0.3 include the following:

    o Added annotation server support.  See README.GROUP-ANNOTATIONS.
    o Added access logging capability.
    o Added HTTP/1.0 compatibility (3rd+ args of GET command ignored).
    o Changed handling of full hostnames.
    o Fixed bug with index.html not being recognized unless a trailing
      slash was appended to the directory name.
    o Fixed bug with extraneous null appended to end of file data
      stream.
    o Fixed bug handling directory URL's with trailing slashes.
    o Made a little more Ultrix-friendly.

We recommend that sites currently using version 0.3 of this server
upgrade and encourage people to experiment with the annotation server
support.  As noted in the README, the annotation server support is
purely experimental and may be changed substantially in the future.

Please send comments or bug reports to httpd@ncsa.uiuc.edu.  Your
comments are greatly appreciated.

Cheers,
Marc (on behalf of Rob, Eric, and himself)

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu


From daemon  Tue Jun 29 14:49:51 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09082; Tue, 29 Jun 93 14:49:53 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09078; Tue, 29 Jun 93 14:49:51 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA16292; Tue, 29 Jun 1993 15:13:12 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA02936; Tue, 29 Jun 93 15:11:33 +0200
Date: Tue, 29 Jun 93 15:11:33 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306291311.AA02936@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: jkrey@isi.edu (Joyce Reynolds)
Subject: Re: Protocol name for port 80
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch



Thanks .. that will be technically accurate at the same time as
letting people know what it's about!

Tim


Begin forwarded message:

Date: Fri, 25 Jun 1993 16:41:33 -0700
From: jkrey@isi.edu (Joyce Reynolds)
To: timbl@nxoc01.cern.ch
Subject: Re: Protocol name for port 80
Cc: iana@isi.edu




Tim B-L,

We have changed "www" referring to port 80 to "www-http".

Joyce


From daemon  Tue Jun 29 15:46:43 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10442; Tue, 29 Jun 93 15:46:46 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10438; Tue, 29 Jun 93 15:46:43 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29703; Tue, 29 Jun 1993 16:09:56 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 29 Jun 93 15:01:34 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA29722; Tue, 29 Jun 93 15:08:03 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306291408.AA29722@manuel.hpl.hp.com>
Subject: Re: One PRE, and entities
To: terry@ora.com
Date: Tue, 29 Jun 93 15:07:59 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Many thanks Terry for your comments.

> Sorry not to respond sooner to your post of Monday last, pointing
> out HTML+'s style attribute for PRE.  This is okay, but maybe
> not the most economical approach. 

> I think there are two issues:  1) the spec's definition of 
> leading white space and line breaks as significant within PRE, 
> and 2) font changes within PRE.  Presently, 1 seems to work just 
> fine (at least in xmosaic and lynx, the two browsers I'm using 
> for trials), so it should not be necessary to institute a <BR> 
> tag to get line breaks within PRE.  Outside PRE one shouldn't 
> need them (counterexamples welcome).

One use is for <BR> with <P CENTER> to get some centred lines, but which
all belong to the same logical paragraph.

> Presently, however, PRE is defined as having typewriter type
> as its default font, and I think that's wrong.   I'd rather have
> to invoke that font (by <CODE>) explicitly, the default font
> remaining the same as the main text.  That way I don't need
> an <R> tag, which has also been suggested, and when I
> have an address to display, I can type:
> <PRE>
>        Name
>        Address
>        Telephone.  
> </PRE>
> and get three indented lines in the main text font.
> I think that if the definition of PRE is changed in this way
> the style attribute might not be needed.

I'm not sure that most people would agree with your preference to explicitly
invoking a fixed pitch font.

Rather than an <R> tag, I would like to augment the EMPH rendering hints to
include additional font types beyond TT. This has a certain feeling of
completeness to it. The obvious step is to then also include the same font
attributes in PRE (defaulting to fixed pitch), i.e.

<!ATTLIST PRE
    id      ID      #IMPLIED -- link destination --
    style   CDATA   #IMPLIED -- various styles --
    tr      (tr)    #IMPLIED -- render in serif (Times Roman) font --
    hv      (hv)    #IMPLIED -- render in sans serif (Helvetica) font --
    width   NUMBER  #IMPLIED -- e.g. 40, 80, 132 -->

e.g.
        <PRE TR>
                Name
                Address
                Telephone
        </PRE>        

With PRE right aligned text would only work in a particular window size.
PRE stops the browser from being able to adjust margins etc. to get the
alignment ok for the current window size. I would therefore like to allow
greater flexibility for normal paragraphs via rendering hints, e.g. your
example becomes:

        <P INDENT>
        Name<BR>
        Address<BR>
        Telephone.

The change to a container model for the P tag ensures that the scope is well
defined. The style attribute for PRE should be retained so that authors can
indicate the logical role of the preformatted text in an extensible manner.

On the subject of changing fonts, thanks for your comments on using the SGML
external entity mechanism.

> We already have character entities in the HTML DTD; all that's 
> needed is to establish how to reference external entity sets not 
> actually included in the HTML+ DTD.  SGML rather envisions that
> the entity files are available locally at run time; for WWW it
> might be better to be able to indicate the entity files are on
> the same machine the document is being fetched from.

As far as Latin-1 goes it is a simple matter to map entity definitions to an
8-bit ASCII code. More generallt, this breaks down into two parts:

    a)  mapping the entity name to a character code and char set

    b)  how to render fonts in this char set (at least for the
        character codes needed for the current document)

It would be neat if we could use outline fonts for this. From the point
of view of HTML+ all that is needed is (a). The rest is a matter for the
protocol spec. Perhaps for now we need a mechanism like #INCLUDE that
works across the network. This could be implemented using the LINK tag.

> And if we can reference external entities, we can do something
> requested this week in my office:  use entities to represent
> URLs.  Than means 1) URLs themselves may be extracted from the 
> main document and collated in a referenced navigational document,
> and 2) common link types may be generated automatically:  for
> any "Next" link, my &next; entity can refer to a script that 
> looks through a list of filenames, chooses the one after the 
> current file, and returns that as the URL for the target of 
> the link.  

Tell me more about the reasons people were asking for this feature.

It seems to me that Next and Previous can be adequately handled using
the existing framework:

    a)  defined by LINK elements with REL attribute
    b)  sequences defined with the GROUP tag in the parent doc

These will need to be clarified in the RFC for HTML+.

Regards,

Dave Raggett

From daemon  Tue Jun 29 16:10:39 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10992; Tue, 29 Jun 93 16:10:41 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10988; Tue, 29 Jun 93 16:10:39 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05733; Tue, 29 Jun 1993 16:33:51 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 29 Jun 93 15:25:33 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00554; Tue, 29 Jun 93 15:32:01 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306291432.AA00554@manuel.hpl.hp.com>
Subject: Re: HTML+ and browser functionality
To: sanders@bsdi.com
Date: Tue, 29 Jun 93 15:31:58 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> Hey, I remember a while back someone suggested having certain standard
> links in the document (forw back up top).  Instead of hardcoding these
> how about just having a control panel element that might work like this:

> <CONTROL>
>     <UL>
>         <LI> <A ...>Click here</A>
>         <LI> <A ...>Drink me</A>
>         <LI> <A ...>Go away</A>
>     </UL>
> </CONTROL>

> Then a clever browser can do whatever it wants to render that section of
> code (the idea being that it could stick it in a window so it's always
> available for navigation).  By default it can just render in place.

Urh, whats wrong with the LINK element, e.g.

        <LINK rel="up" href=...>
        <LINK rel="prev" href=...>
        <LINK rel="next" href=...>

The links specified with the LINK tag are assumed to be global to the
entire document and so could be automatically added to a menu or toolbar.

> BTW: I would like to give a big thanks to Dave Raggett for doing a great
> job on the HTML+ DTD_.  From our random arguments and outrageous requets
> (tables, forms, ...) Dave has really pulled HTML+ together.  Any idea when
> it'll be stable enough to start developing browsers for?

Gee thanks. I have just started to write HTML+ up as an RFC which attempts
to clarify the details of the format and how it should be handled by browsers.
This should be ready within three/four weeks.

Dave Raggett

p.s. Tim's spec seems to have the attribute named "REV" but "REL" seems
more appropriate. Any comments anyone?

From daemon  Tue Jun 29 16:34:46 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11513; Tue, 29 Jun 93 16:34:48 MET DST
Return-Path: <dale@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11509; Tue, 29 Jun 93 16:34:46 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13025; Tue, 29 Jun 1993 16:58:06 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA25917; Tue, 29 Jun 1993 10:57:42 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
	id AA04782; Tue, 29 Jun 1993 07:57:38 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
	id AA05074; Tue, 29 Jun 1993 07:58:58 -0700
From: dale@ora.com (Dale Dougherty)
Message-Id: <9306290758.ZM5072@cider.west.ora.com>
Date: Tue, 29 Jun 1993 07:58:57 -0700
In-Reply-To: Dave_Raggett <dsr@hplb.hpl.hp.com>
        "Re: HTML+ and browser functionality" (Jun 29,  3:31pm)
References: <9306291432.AA00554@manuel.hpl.hp.com>
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>, sanders@bsdi.com
Subject: Re: HTML+ and browser functionality
Cc: www-talk@nxoc01.cern.ch

On Jun 29,  3:31pm, Dave_Raggett wrote:
} Subject: Re: HTML+ and browser functionality
>
>Urh, whats wrong with the LINK element, e.g.
>
>        <LINK rel="up" href=...>
>        <LINK rel="prev" href=...>
>        <LINK rel="next" href=...>
>
>The links specified with the LINK tag are assumed to be global to the
>entire document and so could be automatically added to a menu or toolbar.
>
This seems like the right approach.  We'd like to use it to
define a linear sequence, for example, the sections of a chapter.
However, we should probably be sure to distinguish "next" and "prev" 
from "forward" and "back", which have to do with the navigational
sequence.

In a previous message, you 
mentioned using the GROUP tag also for this purpose.  Can you
explain use of the GROUP tag?  I'd like to use the GROUP tag to
is define a set of links shared by a set of documents, such as
chapters all containing links to a table of contents, or a glossary.

Thanks.

-- 

Dale Dougherty 
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472 
(707) 829-3762 (home office); 1-800-998-9938

UUCP:	uunet!ora!dale     Internet :   dale@ora.com


From daemon  Tue Jun 29 16:39:43 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11641; Tue, 29 Jun 93 16:39:45 MET DST
Return-Path: <weber@eitech.eitech.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11636; Tue, 29 Jun 93 16:39:43 MET DST
Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13631; Tue, 29 Jun 1993 17:03:02 +0200
Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
	 with SMTP id AA16698; Tue, 29 Jun 93 10:02:31 -0500
Received: from eitech.eitech.com by eitech.com (4.1/SMI-4.1)
	id AA02010; Tue, 29 Jun 93 07:56:58 PDT
Message-Id: <9306291456.AA02010@eitech.com>
To: Terry Allen <terry@ora.com>
Cc: sanders@bsdi.com, www-talk@nxoc01.cern.ch
Subject: Re: HTML+ and browser functionality 
In-Reply-To: Your message of "Mon, 28 Jun 1993 16:55:04 PDT."
             <199306282355.AA01319@ora.com> 
Date: Tue, 29 Jun 1993 07:56:57 -0700
From: "Jay C. Weber" <weber@eitech.eitech.com>

A while back I suggested that we modify libwww to support variable
substitution in URLs, e.g., if "$xyz" is embedded in a URL, then
the browser should look in its internal symbol table and substitute
the value of variable "xyz" before dereferencing the URL.

Such a mechanism would make it easy to support dynamic links, e.g.,
<A HREF="$home">Home</A> uses a builtin variable "home".

We took a first cut at modifying libwww for this, and we're now using
it in our Windows NT browser (not for home and previous links, but for
variables set dynamically by embedded widgets -- for this we also use
simple conditionals in URLs).

Jay Weber
EIT

From daemon  Tue Jun 29 17:09:42 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12455; Tue, 29 Jun 93 17:09:47 MET DST
Return-Path: <cja@castle.edinburgh.ac.uk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12449; Tue, 29 Jun 93 17:09:42 MET DST
Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22282; Tue, 29 Jun 1993 17:32:57 +0200
Via: uk.ac.edinburgh.castle; Tue, 29 Jun 1993 16:29:05 +0100
To: mmis@mailbase.ac.uk, wg-imm@rare.nl, mm-sig@jnt.ac.uk, wg-isus@rare.nl,
        www-talk@nxoc01.cern.ch
Subject: Network Access to Multimedia Information
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Date: Tue, 29 Jun 93 16:29:00 WET DST
Message-Id: <9306291629.aa00879@castle.ed.ac.uk>

RARE recently commissioned a report on network access to multimedia
information.  This report has now been completed, and is available by
anonymous FTP.  The full report is rather lengthy, so there is a short
summary available as well.

Host:       ftp.ed.ac.uk
Directory:  /pub/mmaccess
Filenames:  report.doc    Report in Word for Windows 2 format (binary!)
            report.ps     Report in Postscript form
            report.txt    Report in ASCII text form
            summary.doc   Summary in Word for Windows 2 format (binary!)
            summary.ps    Summary in Postscript form
            summary.txt   Summary in ASCII text form
            *.*.Z         Each of the above files run through Unix
                          compress program (binary!)

I'd welcome feedback, comment etc.  Discussion of the report is probably
best conducted on the Multimedia Information Services list,
mmis@mailbase.ac.uk.  To subscribe, mail mailbase@mailbase.ac.uk with

JOIN MMIS yourfirstname yourlastname

in the body of the message.

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom


From daemon  Tue Jun 29 17:18:03 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12660; Tue, 29 Jun 93 17:18:05 MET DST
Return-Path: <stellr@smyrna.cc.vt.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12655; Tue, 29 Jun 93 17:18:03 MET DST
Received: from smyrna.cc.vt.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25139; Tue, 29 Jun 1993 17:41:24 +0200
Received: by smyrna.cc.vt.edu (5.65/DEC-Ultrix/4.3)
	id AA09399; Tue, 29 Jun 1993 11:44:51 -0400
From: stellr@smyrna.cc.vt.edu (Ray Stell)
Message-Id: <9306291544.AA09399@smyrna.cc.vt.edu>
Subject: searchable index of the web
To: www-talk@nxoc01.cern.ch
Date: Tue, 29 Jun 93 11:44:50 EDT
X-Mailer: ELM [version 2.3 PL4]

Seems to me, that one of the things that makes the web an awkward 
beast is the lack of a searchable index.  It depends on folklore 
to stay together.  Hence, you have these post that come to this 
mailer saying look here, look what I built.  If you neglect to 
add it to Marc's hotlist, well, hmmm, now where was that mud thingy.

Perhaps this already exists, and I missed it in the documentation.
If the developers put their stuff in directory trees made up of keywords:

http://myunixbox.edu/www/mud/thingy

Then, I can find him in the index when I search for thingy.
I'm sure this has all been covered, but howso?   I missed it. 
======================================================================
Ray Stell		stellr@smyrna.cc.vt.edu		(703) 231-4109

From daemon  Tue Jun 29 17:54:41 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13477; Tue, 29 Jun 93 17:54:43 MET DST
Return-Path: <dsr@hplb.hpl.hp.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13473; Tue, 29 Jun 93 17:54:41 MET DST
Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03907; Tue, 29 Jun 1993 18:17:56 +0200
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 29 Jun 93 17:07:33 +0100
Received: by manuel.hpl.hp.com
	(16.6/15.6+ISC) id AA00598; Tue, 29 Jun 93 17:13:57 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9306291613.AA00598@manuel.hpl.hp.com>
Subject: Re: HTML+ and browser functionality
To: dale@ora.com
Date: Tue, 29 Jun 93 17:13:55 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> In a previous message, you 
> mentioned using the GROUP tag also for this purpose.  Can you
> explain use of the GROUP tag?  I'd like to use the GROUP tag to
> is define a set of links shared by a set of documents, such as
> chapters all containing links to a table of contents, or a glossary.

If you have a number of chapters (with one document per chapter) which all
share same table of contents, then one approach is to insert a link in each
chapter to the table of contents. This is ok, but a pain to maintain. It
would in many cases be much nicer to define the structure of the book in 
one place, with pointers to the table of contents and the various chapters.

The GROUP tag can be used to define hierarchical groupings of tagged elements
such as chapters, appendices and so on. When you follow a link into a book
defined in this way, the browser can keep track of the context, and show
menu items or toolbar buttons for the table of contents etc. The idea needs
to be thought through in more detail, and is still a bit rough ...

e.g. in the document book.html

     <GROUP type="table of contents">
        <TITLE>Your Dog! </TITLE>

        <A REL="partof" href="preface.html"> Preface </A>

        <GROUP type="chapters">
          <UL>
            <LI> <A REL="partof" href="chap1.html"> Introduction </A>
            <LI> <A REL="partof" href="chap2.html"> So you want a dog </A>
            <LI> <A REL="partof" href="chap3.html"> Your new arrival </A>
            <LI> <A REL="partof" href="chap4.html"> Training </A>
            ...
          </UL>
        </GROUP>

        <GROUP type="appendices">
            ...
        </GROUP>
     </GROUP>

Rather than simple lists of elements, it seems nicer to allow a range of
markup so that the hierarchy can be viewed directly. The REL="partof"
attribute indicates that the associated document "belongs" to this group,
rather than simply a referenced work. You can therefore build up hierarchies
extending across a collection of documents.

The order in which such parts appear in the markup defines a browse sequence
and imply NEXT and PREV links when viewing these documents. This is
independent of the use of the UL element as seen above.

Note that a given document could be part of several different books. The
appropriate link to follow when the user presses NEXT depends on how the
current document was reached. Perhaps we need to extend the A tag to allow
authors to specify which context is intended for ordinary cross references.

Some more thought is needed on exactly how the browser knows which LINK
elements are implied, i.e. what menu items to show for a given document.

Regards,

Dave Raggett

From daemon  Tue Jun 29 19:55:19 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16171; Tue, 29 Jun 93 19:55:22 MET DST
Return-Path: <terry@ora.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16167; Tue, 29 Jun 93 19:55:19 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05587; Tue, 29 Jun 1993 20:18:36 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
	id AA11378; Tue, 29 Jun 1993 14:18:33 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
	id AA09510; Tue, 29 Jun 1993 11:18:32 -0700
Message-Id: <199306291818.AA09510@ora.com>
From: Terry Allen <terry@ora.com>
Date: Tue, 29 Jun 1993 11:18:31 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: Link info outside doc

Here's why I'd like to be able to store the link info outside the 
document.  I have documents that have a set order (chapters of a 
book, chunks of chapters of a book) and that all need NEXT and 
PREVIOUS links.  In the present HTML, I have to (don't I?) provide
the URLs for the next and previous documents in each document.
This is tedious and prone to error.

I'd like to be able to provide a list of the docs in order, then
in each doc just specify that it should have a NEXT and PREVIOUS
link.  Then the browser can refer to the list of files and find
the right URL.  If I want to change the order I can reorder the
list of docs, without having to go into every file and change
the URLs.  

Is there a way to do this in HTML+ that I have missed?

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472

From daemon  Tue Jun 29 19:57:50 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16242; Tue, 29 Jun 93 19:57:52 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA16238; Tue, 29 Jun 93 19:57:50 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07343; Tue, 29 Jun 1993 20:21:09 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA05096; Tue, 29 Jun 93 13:21:02 -0500
Message-Id: <9306291821.AA05096@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: browser execution 
In-Reply-To: Marc's message of Tue, 29 Jun 93 02:02:20 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Tue, 29 Jun 1993 13:21:01 -0500
From: Tony Sanders <sanders@bsdi.com>

Marc wisely said:
> Having browsers execute code is *very* scary.  Servers generally run
> (or should run -- no reason not to) as userid 'nobody', and as such
> can cause practically no damage to anything.  In any case, server
> writers have much more knowledge about what's going to happen and what
> could happen while writing a server than client users do while just
> randomly clicking hyperlinks.  I don't see as there's any reason to
> think that client-side execution is safer.

In either case you should probably **seriously** think about running
in a chroot()'ed environment (which requires root perms to setup
of course).

Also, what about DOS environments (et.al.) where you have neither file
permissions nor chroot().  I think you are just SOL.

--sanders

From daemon  Tue Jun 29 20:30:56 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17103; Tue, 29 Jun 93 20:30:58 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17098; Tue, 29 Jun 93 20:30:56 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20805; Tue, 29 Jun 1993 20:54:17 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA17988; Tue, 29 Jun 1993 13:53:18 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306291853.AA17988@stat1.cc.ukans.edu>
Subject: MacWWW
To: www-talk@nxoc01.cern.ch
Date: Tue, 29 Jun 93 13:53:18 CDT
X-Mailer: ELM [version 2.3 PL2]

One of our local developers is trying to make use of the MacWWW sources
that are distributed from info.cern.ch.  He has had problems finding
all of the peices in the distribution.  Has anyone else had this problem?
Is the distribution really missing peices?  If it is, and I will assume
that for the moment, who shall I contact to get a complete distribution set?

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Tue Jun 29 20:35:37 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17250; Tue, 29 Jun 93 20:35:40 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17245; Tue, 29 Jun 93 20:35:37 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21050; Tue, 29 Jun 1993 20:58:57 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA05326; Tue, 29 Jun 93 13:58:55 -0500
Message-Id: <9306291858.AA05326@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Web intro document needed
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Tue, 29 Jun 1993 13:58:55 -0500
From: Tony Sanders <sanders@bsdi.com>

Anyone have a good "getting started on the web" document for people not
on the web?  It should talk about what browsers are available and where
to get them from.

If not I think I'll write one.

--sanders

From daemon  Tue Jun 29 20:50:35 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17546; Tue, 29 Jun 93 20:50:37 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA17542; Tue, 29 Jun 93 20:50:35 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25605; Tue, 29 Jun 1993 21:13:55 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA05421; Tue, 29 Jun 93 14:13:52 -0500
Message-Id: <9306291913.AA05421@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML+ and browser functionality 
In-Reply-To: Your message of Tue, 29 Jun 93 07:58:57 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Tue, 29 Jun 1993 14:13:52 -0500
From: Tony Sanders <sanders@bsdi.com>

> On Jun 29,  3:31pm, Dave_Raggett wrote:
> } Subject: Re: HTML+ and browser functionality
> >
> >Urh, whats wrong with the LINK element, e.g.
> >
> >        <LINK rel="up" href=...>
> >        <LINK rel="prev" href=...>
> >        <LINK rel="next" href=...>
> >
> >The links specified with the LINK tag are assumed to be global to the
> >entire document and so could be automatically added to a menu or toolbar.
> >
> This seems like the right approach.  We'd like to use it to
> define a linear sequence, for example, the sections of a chapter.
> However, we should probably be sure to distinguish "next" and "prev" 
> from "forward" and "back", which have to do with the navigational
> sequence.
Right, this is needed for picking up "threads" of documents to print
out the whole meta-document.  I'm not suggesting we should replace this.

I just think it would be fun to allow the document to define it's own
look for the navigation panel using normal HTML commands.  This could
co-exist with <LINK REL> with no problem.

--sanders

From daemon  Tue Jun 29 21:14:02 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18035; Tue, 29 Jun 93 21:14:04 MET DST
Return-Path: <montulli@stat1.cc.ukans.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18031; Tue, 29 Jun 93 21:14:02 MET DST
Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA09118; Tue, 29 Jun 1993 21:37:23 +0200
Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
          id AA20049; Tue, 29 Jun 1993 14:35:59 -0500
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Message-Id: <9306291935.AA20049@stat1.cc.ukans.edu>
Subject: And now for something completely different!
To: www-talk@nxoc01.cern.ch
Date: Tue, 29 Jun 93 14:35:49 CDT
X-Mailer: ELM [version 2.3 PL2]

Now that WWW has hypermedia capibilities wouldn't it be nice to have a nice
collage (sp?) of developers faces.  I'm also sort of mystified as to how
everyone looks and would rather avoid all of the suprise at the upcoming
developers conference.  I will therefore take the lead and publish my
face as a URL. (No laughing please!)

gopher://kufacts.cc.ukans.edu/g9/cwis/people/Lou.Montulli.gif

These URL's (which I hope every developer or team will submit) could be
added to the WWW people document that Tim maintains or everyone could
put together a seperate document containing info about themselves, 
their organization, etc.  This may also help to convey a more humanistic
view of developers instead of the arcane mystic view that most non-programers
hold.

Maybe in the future we will have to remove our pictures so that our fame
doesn't cause mob scenes everywhere we go.  I here Michael Jackson has
a big problem with that :)

:lou
-- 
  **************************************************************************
  *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  *         Lou  MONTULLI @ Ukanaix.cc.ukans.edu                           *
  *                         Kuhub.cc.ukans.edu      ACS Computing Services *
  *     913/864-0436        Ukanvax.bitnet             Lawrence, KS 66044  *
  *             UNIX! Cool! I know that!  Jurassic Park - The Movie        *
  **************************************************************************

From daemon  Tue Jun 29 22:59:26 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20488; Tue, 29 Jun 93 22:59:28 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA20484; Tue, 29 Jun 93 22:59:26 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01584; Tue, 29 Jun 1993 23:22:47 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA06012; Tue, 29 Jun 93 16:22:44 -0500
Message-Id: <9306292122.AA06012@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: And now for something completely different! 
In-Reply-To: Your message of Tue, 29 Jun 93 14:35:49 CDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Tue, 29 Jun 1993 16:22:44 -0500
From: Tony Sanders <sanders@bsdi.com>

Web Faces
=========

Lou Montulli writes:
> Now that WWW has hypermedia capibilities wouldn't it be nice to have a nice
> collage (sp?) of developers faces.  I'm also sort of mystified as to how
> everyone looks and would rather avoid all of the suprise at the upcoming
> developers conference.  I will therefore take the lead and publish my
> face as a URL. (No laughing please!)

Yes, I agree.  Maybe we could digitize "faces" at the workshop? If someone
just brings a video camera we can grab frames later and send them back
the person for publishing.  Is anyone willing to do this, or am I the only
one without a digitizer?


Net Access at Workshop?
=======================

I expect Dale etc already thought of this but just in case...

Are we going to have Internet access at the Workshop?  I might be able to
provide temporary copies of BSD/386 if someone else (Dale?) could provide
some PCs with network cards.  I'll be in Tuesday night and would be willing
to pop down and help install/setup whatever (this holds true even if you
don't need BSD/386 for the PCs, I will be willing to help out in whatever
way I can, just let me know, I'll be around Saturday also).


--sanders_

.. _Contact http://www.bsdi.com/hyplan/sanders.html
.. _sanders http://www.bsdi.com/hyplan/sanders.html

From daemon  Tue Jun 29 23:24:12 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21048; Tue, 29 Jun 93 23:24:14 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21043; Tue, 29 Jun 93 23:24:12 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA02879; Tue, 29 Jun 1993 23:47:33 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA06123; Tue, 29 Jun 93 16:47:30 -0500
Message-Id: <9306292147.AA06123@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: HTML+ and browser functionality 
In-Reply-To: Dave_Raggett's message of Tue, 29 Jun 93 15:31:58 BST.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Tue, 29 Jun 1993 16:47:29 -0500
From: Tony Sanders <sanders@bsdi.com>

> Urh, whats wrong with the LINK element, e.g.
> 
>         <LINK rel="up" href=...>
>         <LINK rel="prev" href=...>
>         <LINK rel="next" href=...>
> 
> The links specified with the LINK tag are assumed to be global to the
> entire document and so could be automatically added to a menu or toolbar.

I want something like this, maybe not this syntax but the semantics:

<HEAD>
    <TITLE>document</TITLE>
    <LINK rel="up" href=...>
    <LINK rel="prev" href=...>
    <LINK rel="next" href=...>
</HEAD>
<NAV>
    <A REF="up"><IMG SRC="/img/up.gif"></A>
    <A REF="prev"><IMG SRC="/img/prev.gif"></A>
    ...
</NAV>

This lets you specify how the navigation panel looks so the browser doesn't
have to grok special link relationships (up, prev, next) for this purpose.
I think this is a big win because if you hardcode up,prev,next that will
pretty much squelch any development on new navigation models.  I want to
be able to pop up a compass rose for navigating map data, or the image of
a book to turn pages etc.  Each class of document has it's own navigation
needs and I think hardcoding this in the browser is a bad idea.  This
could be done with having a bunch of rel attributes and having the browser
select the look based on the available LINK's but I don't think anyone
is likely to implement that and it still doesn't let you create nav's on
the fly.  I don't have the "solution" I'm just presenting the problem
that I would like to solve (dynamic nav panels).

Is anyone else interested in being able to build the look of the
navigation panel on the fly?  This could mesh quite nicely with
the LINK rel stuff if done right.

--sanders

From daemon  Wed Jun 30 00:13:06 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21922; Wed, 30 Jun 93 00:13:08 MET DST
Return-Path: <sugar!karl@one.neosoft.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21918; Wed, 30 Jun 93 00:13:06 MET DST
Received: from one.NeoSoft.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05807; Wed, 30 Jun 1993 00:36:27 +0200
Received: from sugar.UUCP by one.NeoSoft.com (5.67/1.34)
	id AA03439; Tue, 29 Jun 93 17:34:58 -0500
Received: by NeoSoft.Com (smail2.5)
	id AA10920; 29 Jun 93 17:32:21 CDT (Tue)
Subject: Re: browser execution
To: sugar!bsdi.com!sanders@dxmint.cern.ch
Date: Tue, 29 Jun 1993 17:32:20 -0500 (CDT)
From: Karl Lehenbauer <karl@sugar.neosoft.com>
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306291821.AA05096@austin.BSDI.COM> from "Tony Sanders" at Jun 29, 93 01:21:01 pm
X-Mailer: ELM [version 2.4 PL5]
Content-Type: text
Content-Length: 1469      
Message-Id: <9306291732.AA10920@NeoSoft.Com>

> Marc wisely said:
> > Having browsers execute code is *very* scary.  Servers generally run
> > (or should run -- no reason not to) as userid 'nobody', and as such
> > can cause practically no damage to anything.  In any case, server
> > writers have much more knowledge about what's going to happen and what
> > could happen while writing a server than client users do while just
> > randomly clicking hyperlinks.  I don't see as there's any reason to
> > think that client-side execution is safer.
> 
> In either case you should probably **seriously** think about running
> in a chroot()'ed environment (which requires root perms to setup
> of course).
> 
> Also, what about DOS environments (et.al.) where you have neither file
> permissions nor chroot().  I think you are just SOL.

We are involved in some work on safe Tcl which will become part of
active email under MIME.  The idea is that a subordinate Tcl interpreter
can be created that is restricted only to operations that are safe --
file access, forking, etc, are unavailable.  The "regular" Tcl interpreter
can also export commands to the safe interpreter which are executed
in the regular interpreter's environment -- totally analogous to an
operating system's system calls.

I am about to post a secure Tcl experimenter's kit to comp.lang.tcl.

It would be a good candidate, IMHO, for delivering active HTML messages
(i.e. programs) that can be executed safely, even though the sender
isn't trusted.


From daemon  Wed Jun 30 00:16:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22003; Wed, 30 Jun 93 00:17:00 MET DST
Return-Path: <mvanheyn@cs.indiana.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA21998; Wed, 30 Jun 93 00:16:58 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05947; Wed, 30 Jun 1993 00:40:19 +0200
Received: from localhost by moose.cs.indiana.edu
	(5.65c/9.4jsm) id AA00505; Tue, 29 Jun 1993 17:40:07 -0500
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: feednews@news.cs.indiana.edu, pem-dev@tis.com, www-talk@nxoc01.cern.ch
Newsgroups: comp.infosystems.www,comp.protocols.kerberos,alt.security.ripem,comp.security.misc,sci.crypt
Subject: Security services for HTTP:  Kerberos vs. PEM
Summary: 
Followup-To: poster
Distribution: world
Organization: Computer Science Dept, Indiana University
Keywords: 
Date: Tue, 29 Jun 1993 17:40:07 -0500
Message-Id: <503.741393607@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

HyperText Transfer Protocol, a simple stateless protocol based on
request-response of MIME messages and associated with the World Wide
Web project, has need of security services (e.g. authentication) in
order to allow things like information protection, modification or
annotation, and possibly compensated commercial information exchange
(in the medium to far future).

The two obvious approaches seem to be Kerberos (widely used and
oriented towards providing security for client-server relationships)
and PEM (not as widely used yet, oriented towards providing protection
for MIME objects such as messages.)

I'm attempting to put together a reasonably fair assesment of
potential advantages and problems for each of three different methods
for providing security:
   - Kerberos
   - PEM with symmetric cryptography only
   - PEM with asymmetric cryptography

I'd appreciate hearing from anyone with some knowledge about the
application and implications about each of these approaches
(preferably something more than I can have, which consists of a casual
reading of the pertinent RFCs, drafts, FAQs, and the like) regarding
how readily the necessary support structure can be/is being put in
place, how important the various services each offers is, how
potentially extensible each is, and that kind of thing.  If people
care, I can post the resulting document and let the flames begin. :-)

(For that matter, if someone knows a much better method that I didn't
know about, let me know about that too.)
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here

From daemon  Wed Jun 30 00:41:22 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22266; Wed, 30 Jun 93 00:41:23 MET DST
Return-Path: <Nathan.Torkington@vuw.ac.nz>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA22262; Wed, 30 Jun 93 00:41:22 MET DST
Received: from [130.195.11.3] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07143; Wed, 30 Jun 1993 01:04:41 +0200
Received: by kauri.vuw.ac.nz id AA18510
  (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Wed, 30 Jun 1993 11:04:29 +1200
Date: Wed, 30 Jun 1993 11:04:29 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-Id: <199306292304.AA18510@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
In-Reply-To: Karl Lehenbauer's message <9306291732.AA10920@NeoSoft.Com>
Subject: Re: browser execution

Karl Lehenbauer writes:

> We are involved in some work on safe Tcl which will become part of
> active email under MIME. [...]
> It would be a good candidate, IMHO, for delivering active HTML messages
> (i.e. programs) that can be executed safely, even though the sender
> isn't trusted.

Something I would like to see is libraries (I don't know if you have
them or not).  They could be specified through MIME, I guess, and
would be a combination of ID and ``place to get them from if you don't
already have them''.  For instance, say I want interactive hypertext,
I could use a set of libraries that have already been written and
debugged, rather than including the same code in every single
interactive hypertext document.

This would lead to:
  -- standardisation of code (a Good Thing).  C is intelligable
     because libc.a provides a common set of ground rules without
     which every program's source would bloat enormously.
  -- local copies of libraries, to avoid repetitive and time-consuming
     delays fetching libraries over a long-haul network for each
     document.
  -- quick boot-strapping.  If a couple of useful libraries for text
     and interactive graphics were available, more users would be
     willing to start the gentle slope of the learning curve.

Nat.

From daemon  Wed Jun 30 07:16:14 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26338; Wed, 30 Jun 93 07:16:15 MET DST
Return-Path: <joe@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA26334; Wed, 30 Jun 93 07:16:14 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27130; Wed, 30 Jun 1993 07:39:36 +0200
Received: from THEODORE-STURGEON.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA05388; Wed, 30 Jun 93 01:39:31 EDT
From: joe@athena.mit.edu
Received: by theodore-sturgeon (5.57/4.7) id AA20609; Wed, 30 Jun 93 01:39:29 -0400
Date: Wed, 30 Jun 93 01:39:29 -0400
Message-Id: <9306300539.AA20609@theodore-sturgeon>
To: www-talk@nxoc01.cern.ch
Subject: Re: searchable index of the web


A very incomplete index of the web is located at
http://sturgeon.mit.edu:8001 as part of the Usenet University -- New
Network Academy.  The way that this index works is that items are
assigned a "coverage code" 010 being a general index of everything on
the net to 120 which is an item (for example, a question in a Usenet
FAQ) and are sorted from most general reference to least general.

That way the first items returned by a search are the most general
ones corresponding to your search, and so you don't have the problem
as with veronica and archie of searching for "Law" and getting
overloaded with individual treaties.





From daemon  Wed Jun 30 09:39:45 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27335; Wed, 30 Jun 93 09:39:47 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27331; Wed, 30 Jun 93 09:39:45 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA13299; Wed, 30 Jun 1993 10:03:04 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA00748
  (5.65a/IDA-1.4.2 for www-announce@nxoc01.cern.ch); Wed, 30 Jun 93 03:03:02 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA28548; Wed, 30 Jun 93 03:05:50 -0500
Date: Wed, 30 Jun 93 03:05:50 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306300805.AA28548@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch, www-announce@nxoc01.cern.ch
Cc: mosaic-x@ncsa.uiuc.edu
Subject: NCSA Mosaic for X 1.2 available.
X-Md4-Signature: 7d59ffb17a737b5a75e4368a4aae4870

Version 1.2 of NCSA Mosaic for the X Window System, a networked
information systems and World Wide Web browser, is now available:

file://ftp.ncsa.uiuc.edu/Mosaic/xmosaic-source/xmosaic-1.2.tar.Z
                            .../xmosaic-binaries/xmosaic-sun.Z
                            .../xmosaic-binaries/xmosaic-sun-lresolv.Z
                            .../xmosaic-binaries/xmosaic-sgi.Z
                            .../xmosaic-binaries/xmosaic-ibm.Z
                            .../xmosaic-binaries/xmosaic-dec.Z
                            .../xmosaic-binaries/xmosaic-alpha.Z
                            .../xmosaic-diffs/xmosaic-1.1-1.2-diffs.Z

I'm flirting with fate by putting this out right before I fly to a
conference for the rest of the week, but it seems to be stable.  Any
serious bugs will be fixed this weekend.

Changes since 1.1 include:

 o Binary transfer mode, when on, now forces all files to be treated as
   binary, whether or not their extensions are recognized.  (Due to
   overwhelming popular request.) 
 o Gopher file types are now picked up on the basis of file extension, if a
   file extension exists, with the default being the normally assumed
   type.  This means that "foo.ps" returned as type '0' (text) is interpreted
   as PostScript, etc.  Resource tweakGopherTypes (default True) can be
   set to False to turn this off and interpret Gopher documents stricly by
   the Gopher typing system.  
 o Resource postscriptViewerCommand is now "dump" by default.  This
   is because ghostview (the previous default), as currently shipped, runs
   ghostscript in unsafe mode and a malicious PostScript file could cause
   damage to your filesystem as a result.  
 o Added fullHostname resource to allow explicit setting of the fully
   qualified hostname (machine.domain).  We recommend you don't use
   this resource (allow Mosaic to determine your full hostname on the
   fly) unless your system chokes on gethostbyname().  
 o Fixed problem with annotationServer resource set and annotation
   server not available or network down.  
 o Fixed problem with missing title (or author) in annotation.  
 o Fixed occasional coredump in File->Reload.  
 o Fixed occasional crash with inlined images after windows have been
   closed.  
 o Made failure of gethostbyname() robust (coredumps actually inside
   gethostbyname() must still be dealt with by the gethostbynameIsEvil
   resource).  
 o Fixed coredump when checking for editable annotation property when
   document contains no text.  
 o Fixed coredump when closing window if hotkey is hit while window
   is still open but in the process of being destroyed.  
 o Local files should now always be automatically canonicalized into a
   full URL of form file://hostname/full/path/filename -- this applies to
   command-line arguments and to filenames passed through
   File->Open.
 o Now recognize file://localhost/ scheme for expressly accessing local
   files.  
 o Fixed problem with multiline FTP server responses (courtesy John
   Ockerbloom).  
 o Fixed problem with ".." in FTP directory resulting in slash falling off
   of toplevel URL and subsequent jumps failing.  
 o Fixed problem with trailing slashes in FTP directory specifications
   that were causing part of the directory name to be used twice.  
 o Changed sgimoviePlayerCommand default to movieplayer, which
   actually exists on some SGI systems.  
 o Made a few changes to menubar Documents and Help menus.  
 o Cleaned up lots of typecasting warnings in Xmx code.  
 o Fixed problem with Motif 1.2 and file insertions in annotate window.  
 o Fixed problem with double quotes in titles of group annotations.  
 o Added resource reverseInlinedBitmapColors to allow reversal of
   foreground and background colors in inlined XBM bitmaps.  
 o Fixed problem with group annotations on URL's containing pound
   signs (normally this never happens, but it will happen for HDF files in
   Mosaic 2.0).  
 o Added confirmation box for deleting annotations from the menubar;
   added resource confirmDeleteAnnotation, defaults to true.  
 o Correctly recognizes mis-suffixed HTML files starting with <head>,
   <html>, and <HTML> tags also now.  
 o XPM3-format inlined image support fixed.  

This release of NCSA Mosaic is known to compile on the following
platforms:

  SGI (IRIX 4.0.2) 
  IBM (AIX 3.2)
  Sun 4 (SunOS 4.1.2 with stock X11R4 and Motif 1.1).
  DECstation 5000-200 (Ultrix).
  DEC Alpha (OSF/1 1.2).

Rumor has it that Mosaic will compile on systems like:

  Hewlett Packard HP/UX 7.x, 8.x, 9.x.
  Dell SVR4
  Sun Solaris 2.x
  SCO Open Desktop
  Harris Nighthawk
  NeXT BSD

Documentation is available online within Mosaic.  Comments, questions,
and bug reports should be sent to mosaic-x@ncsa.uiuc.edu.  Thanks in
advance for any feedback you can provide.

Cheers,
Marc & Eric

--
Marc Andreessen & Eric Bina
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu, ebina@ncsa.uiuc.edu


From daemon  Wed Jun 30 09:43:16 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27373; Wed, 30 Jun 93 09:43:18 MET DST
Return-Path: <dem@spectrospin.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27369; Wed, 30 Jun 93 09:43:16 MET DST
Received: from chsun.chuug.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14449; Wed, 30 Jun 1993 10:06:37 +0200
Received: from spectrospin.ch (zurich.spectrospin.ch) by chsun.eunet.ch (5.65c8/1.34)
	id AA21134; Wed, 30 Jun 1993 10:06:53 +0200
Received: from rueschlikon.spectrospin.ch by spectrospin.ch (4.1/SMI-4.1)
	id AA05889; Wed, 30 Jun 93 10:07:08 +0200
Received: by rueschlikon.spectrospin.ch (4.1/SMI-4.1)
	id AA05966; Wed, 30 Jun 93 10:06:53 +0200
Date: Wed, 30 Jun 93 10:06:53 +0200
From: dem@spectrospin.ch (Marco A.Demarmels)
Message-Id: <9306300806.AA05966@rueschlikon.spectrospin.ch>
To: www-talk@nxoc01.cern.ch
Subject: HTML based help

Hi out there

being new to the list and the subject I would like to ask you experts to set
some pointers for me.

I am looking for two kinds of applications related to each other:

- a hypertext document retrieval system (with and without network capabilities)
- a hypertext context sensitive help system

After a first look at xmosaic I am asking myself whether it is possible to use it
unchanged for the former problem and use a 'subset' of xmosaic for the latter
(a hypertext browser or -library).

I want to support Macs (partly with AU/X), PCs (Windows, Desqview/X),
and Unix boxes (Sun, SGI, mips) either with the
same X11 based application using all the available Xservers on these platforms,
or using architecture dependent applications.

Any suggestions/experiences/ideas on that?

Thank you very much in advance for your help
------------------------------------------------------------------------
 ...     ...  | Marco A. Demarmels, M.D.          |                    
.    * .    . | Medical Applications Dept.        |"non sunt multipli-
 .   . .   .  | Spectrospin AG, Switzerland       | canda entia praeter 
 SPECTROSPIN  | VOICE: +41 (1) 825-9475           | necessitatem"
 .   . .   .  | FAX:   +41 (1) 825-9696           |                     
.    * .    . | Internet: dem@spectrospin.ch      | (Occam's razor)     
 ...     ...  | UUCP:  ...!mcsun!chsun!zurich!dem |
------------------------------------------------------------------------

From daemon  Wed Jun 30 10:44:51 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28083; Wed, 30 Jun 93 10:44:54 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28076; Wed, 30 Jun 93 10:44:51 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA23603; Wed, 30 Jun 1993 11:08:14 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA03819; Wed, 30 Jun 93 11:06:33 +0200
Date: Wed, 30 Jun 93 11:06:33 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306300906.AA03819@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: montulli@stat1.cc.ukans.edu (Lou Montulli)
Subject: Re: And now for something completely different!
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


As well as URLs of pictures, URLs of bios or submissions of short  
bios of WWWWizards would be apreciated.  The WWW People list in
<http://info.cern.ch/hypertext/WWW/People.html> is getting really
out of date, so included yourself if you aren't there.
I edit it with the NextStep editor, which doesn't handle
inline images :-( so Arthur or I will just put links to pics for now.

Tim

From daemon  Wed Jun 30 11:37:08 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28761; Wed, 30 Jun 93 11:37:10 MET DST
Return-Path: <roeber@axcrnb.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28757; Wed, 30 Jun 93 11:37:08 MET DST
Received: from AXCRNB.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01581; Wed, 30 Jun 1993 12:00:31 +0200
Date: Wed, 30 Jun 1993 12:00:31 +0200
Message-Id: <9306301000.AA01581@dxmint.cern.ch>
From: roeber@axcrnb.cern.ch (Frederick G.M. Roeber)
X-Vms-To: dxmint::www-talk@info.cern.ch
X-Vms-Cc: ROEBER
Subject: Usenet News meets The Web
X-Mail11-Ostype: VAX/VMS
Apparently-To: <www-talk@nxoc01.cern.ch>

I have written down some ideas on how the news system might benefit from the 
web, and (particularly in the area of public annotations) vice-versa.  It's a 
bit long to mail out, but it's here:

   <a href="http://info.cern.ch/roeber/webnews.html">
     http://info.cern.ch/roeber/webnews.html
   </a>

For those who don't read news because of the volume, I'd note that the WAIS-like 
selection system I propose would allow much tighter filtering than is currently 
done.

I'd love to hear any ideas, feedback, etc.

Frederick.
roeber@cern.ch


From daemon  Wed Jun 30 12:49:33 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29800; Wed, 30 Jun 93 12:49:34 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29796; Wed, 30 Jun 93 12:49:33 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12451; Wed, 30 Jun 1993 13:12:56 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04076; Wed, 30 Jun 93 13:11:15 +0200
Date: Wed, 30 Jun 93 13:11:15 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306301111.AA04076@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Terry Allen <terry@ora.com>
Subject: Re: Link info outside doc
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>
>Begin forwarded message:
>
>From: Terry Allen <terry@ora.com>
>Date: Tue, 29 Jun 1993 11:18:31 PDT
>X-Mailer: Mail User's Shell (7.2.0 10/31/90)
>To: www-talk@nxoc01.cern.ch
>Subject: Link info outside doc
>
>Here's why I'd like to be able to store the link info outside the 

>document.  I have documents that have a set order (chapters of a 

>book, chunks of chapters of a book) and that all need NEXT and 

>PREVIOUS links.  In the present HTML, I have to (don't I?) provide
>the URLs for the next and previous documents in each document.
>This is tedious and prone to error.
...
>-- 

>Terry Allen  (terry@ora.com)

I think your solution is to keep a database of what files
are in which book(s).  You run a special server which
will automatically append the navigation information
from the database.   HTML is a delivery format.
It does not have to be your storage format.

Tim BL



From daemon  Wed Jun 30 12:52:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29871; Wed, 30 Jun 93 12:52:48 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA29867; Wed, 30 Jun 93 12:52:47 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA12665; Wed, 30 Jun 1993 13:16:09 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04091; Wed, 30 Jun 93 13:14:29 +0200
Date: Wed, 30 Jun 93 13:14:29 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306301114.AA04091@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: joe@athena.mit.edu
Subject: Re: searchable index of the web
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>From: joe@athena.mit.edu
>Date: Wed, 30 Jun 93 01:39:29 -0400
>
>A very incomplete index of the web is located at
>http://sturgeon.mit.edu:8001 as part of the Usenet University -- New
>Network Academy.  The way that this index works is that items are
>assigned a "coverage code" 010 being a general index of everything  
on
>the net to 120 which is an item (for example, a question in a Usenet
>FAQ) and are sorted from most general reference to least general.

This weighting of the generality of a node is very interesting,
especially for indexes.

How were the entries in your index collected -- by hand,
or by a traversal of the web?

Tim BL

From daemon  Wed Jun 30 16:10:41 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03945; Wed, 30 Jun 93 16:10:43 MET DST
Return-Path: <Steen.Linden@uni-c.dk>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA03941; Wed, 30 Jun 93 16:10:41 MET DST
Received: from danpost3.uni-c.dk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19565; Wed, 30 Jun 1993 16:34:03 +0200
Message-Id: <9306301434.AA19565@dxmint.cern.ch>
Received: from danpost3.uni-c.dk by danpost3.uni-c.dk 
          id <13497-0@danpost3.uni-c.dk>; Wed, 30 Jun 1993 16:33:58 +0200
Subject: httpd on a SUN
To: www-talk@nxoc01.cern.ch
Date: Wed, 30 Jun 1993 16:33:55 +0200 (MET DST)
Organization: UNI-C - Danish Computing Centre for Research and Education
Address: DTH Building 305, DK-2800 Lyngby, Denmark
Phone: +45 45 93 83 55
Fax: +45 45 93 02 20
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 411
From: Steen Linden <Steen.Linden@uni-c.dk>
Sender: Steen.Linden@uni-c.dk

Hi all,

I have been trying to set up the CERN httpd server on a SUN IPX with
SunOS 4.1.3.

Unfortunately it does't work out that well for me. I have tried various
combinations of the library and daemon versions in the archive at
info.cern.ch. Could anybody with a SUN and a working httpd tell me what
version they got working?

Thanks,

Steen Linden
UNI-C - Danish Computing Centre for Research and Education


From daemon  Wed Jun 30 16:49:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04750; Wed, 30 Jun 93 16:50:01 MET DST
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04746; Wed, 30 Jun 93 16:49:58 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27309; Wed, 30 Jun 1993 17:13:21 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
	id AA04770; Wed, 30 Jun 93 17:11:40 +0200
Date: Wed, 30 Jun 93 17:11:40 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306301511.AA04770@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HTML+ and browser functionality
Cc: sanders@bsdi.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

>p.s. Tim's spec seems to have the attribute named "REV" but "REL"  
seems
> more appropriate. Any comments anyone?


The HTML spec has *both* REL and REV.   Both attributes can be lists
of relationships.  The occurence of a relationship in the REV  
(reverse) list indicates a relationship in th ereverse direction.
Otherwise, you have to have a convention for indicating logically
reverse relationships (eg is-child; has-child) or some
out of band system for knowing that

	A  is-parent-of	B

implies and is implied b by

	B  is-child-of	A

Is there any document where REV is present withouit REL?

Tim

From daemon  Wed Jun 30 20:36:01 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09868; Wed, 30 Jun 93 20:36:04 MET DST
Return-Path: <tom@begbick.law.cornell.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09863; Wed, 30 Jun 93 20:36:01 MET DST
Received: from ROUTER.MAIL.CORNELL.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA27422; Wed, 30 Jun 1993 20:59:24 +0200
Received: from begbick.law.cornell.edu.law.cornell.edu ([132.236.108.7]) by router.mail.cornell.edu with SMTP id <576845-2>; Wed, 30 Jun 1993 14:59:12 -0400
Received: by begbick.law.cornell.edu.law.cornell.edu (4.1/SMI-4.1)
	id AA01113; Wed, 30 Jun 93 14:48:11 EDT
From: tom@begbick.law.cornell.edu (Thomas R. Bruce)
Message-Id: <9306301848.AA01113@begbick.law.cornell.edu.law.cornell.edu>
Subject: Cello Beta 0.6 released
To: teknoids@fatty.law.cornell.edu, law-lib@ucdavis.ucdavis.edu,
        www-talk@nxoc01.cern.ch
Date: Wed, 30 Jun 1993 14:48:11 -0400
X-Mailer: ELM [version 2.2 PL15]

Folks:

Cello beta version 0.6 is hereby released, and available for anonymous
FTP from fatty.law.cornell.edu in the /pub/LII/Cello directory.

For those who missed earlier announcements and versions, Cello is an
all-purpose Internet browser which incorporates WWW, Gopher, FTP,
Telnet, and News clients along with the ability to use many other
services through gateways.

The new version addresses the following problems:

-- CTRL-Backspace will now generate the DEL character (ASCII 0x7F) in
the Telnet client, which apparently some users of UN*X systems badly
need.

-- Various problems with tabbed text in assorted monospaced text modes
were fixed.

-- Problems with WHOIS searches launched from within Gopher are now
fixed.

-- A minor problem in which the scrollbar would hang at the bottom of
a document was repaired.

-- The usual rogue's gallery of GPFs and assorted weirdness were laid
to rest.

Thanks as usual to all the Alert Cellists who spotted and reported
problems, suggested features, and otherwise are keeping me on my toes.

Regards,
Tb. 
-- 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|  Thomas R. Bruce                   tom@law.mail.cornell.edu |
|  Research Associate                                         |
|  Cornell Law School                     Voice: 607-255-1221 |
|  Myron Taylor Hall                        FAX: 607-255-7193 |
|  Ithaca, NY 14853                                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From daemon  Wed Jun 30 20:42:29 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10057; Wed, 30 Jun 93 20:42:31 MET DST
Return-Path: <mkgray@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA10053; Wed, 30 Jun 93 20:42:29 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA28458; Wed, 30 Jun 1993 21:05:52 +0200
Received: from URANUS.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA09253; Wed, 30 Jun 93 15:05:51 EDT
From: mkgray@athena.mit.edu
Received: by uranus.MIT.EDU (AIX 3.2/UCB 5.64/4.7) id AA25385; Wed, 30 Jun 1993 15:05:47 -0400
Message-Id: <9306301905.AA25385@uranus.MIT.EDU>
To: joe@athena.mit.edu
Cc: www-talk@nxoc01.cern.ch
Subject: Re: searchable index of the web 
In-Reply-To: Your message of Wed, 30 Jun 93 01:39:29 -0400.
             <9306300539.AA20609@theodore-sturgeon> 
Date: Wed, 30 Jun 93 15:05:45 EDT

I have written a perl script that wanders the WWW collecting URLs, keeping
tracking of where it's been and new hosts that it finds.  Eventually,
after hacking up the code to return some slightly more useful information
(currently it just returns URLs), I will produce a searchabe index of this.
There is a complete list of all the sites it has found at

<a href="http://www.mit.edu:8001/afs/sipb/user/mkgray/ht/comprehensive.html">
A complete list of sites found by the W4 (World Wide Web Wanderer)
</a>

I'll announce here when we get this index properly running, however it probably
won't be until sometime in August, as I am going on vacation.  Until then...

					Matthew Gray
					mkgray@athena.mit.edu

Visit the SIPB WWW Plexus Server.  URL: http://www.mit.edu:8001/

From daemon  Wed Jun 30 21:32:47 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11495; Wed, 30 Jun 93 21:32:49 MET DST
Return-Path: <stellr@smyrna.cc.vt.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11491; Wed, 30 Jun 93 21:32:47 MET DST
Received: from [128.173.4.58] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04086; Wed, 30 Jun 1993 21:56:10 +0200
Received: by smyrna.cc.vt.edu (5.65/DEC-Ultrix/4.3)
	id AA01276; Wed, 30 Jun 1993 15:59:38 -0400
From: stellr@smyrna.cc.vt.edu (Ray Stell)
Message-Id: <9306301959.AA01276@smyrna.cc.vt.edu>
Subject: Re: searchable index of the web
To: mkgray@athena.mit.edu
Date: Wed, 30 Jun 93 15:59:37 EDT
Cc: www-talk@nxoc01.cern.ch
In-Reply-To: <9306301905.AA25385@uranus.MIT.EDU>; from "mkgray@athena.mit.edu" at Jun 30, 93 3:05 pm
X-Mailer: ELM [version 2.3 PL4]

> 
> I have written a perl script that wanders the WWW collecting URLs, keeping
> tracking of where it's been and new hosts that it finds.  Eventually,
> after hacking up the code to return some slightly more useful information
> (currently it just returns URLs), I will produce a searchabe index of this.
> There is a complete list of all the sites it has found at
> 
> <a href="http://www.mit.edu:8001/afs/sipb/user/mkgray/ht/comprehensive.html">
> A complete list of sites found by the W4 (World Wide Web Wanderer)
> </a>
> 
> I'll announce here when we get this index properly running, however it probably
> won't be until sometime in August, as I am going on vacation.  Until then...
> 
> 					Matthew Gray
> 					mkgray@athena.mit.edu
> 
> Visit the SIPB WWW Plexus Server.  URL: http://www.mit.edu:8001/
> 


This sounds good, better than depending on my memory.  Will w4
crack open an log the <Title> or is this directory tree oriented?
If I'm running a server, how will you know to wander to it?  
Should there be a web of wanderers (w5?) so w4e in Europe can
feed from w4u in the US, etc?  Why is this topic such a quiet one? 
======================================================================
Ray Stell		stellr@smyrna.cc.vt.edu		(703) 231-4109

From daemon  Wed Jun 30 22:07:58 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12469; Wed, 30 Jun 93 22:08:00 MET DST
Errors-To: sanders@bsdi.com
Return-Path: <sanders@bsdi.com>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA12465; Wed, 30 Jun 93 22:07:58 MET DST
Errors-To: sanders@bsdi.com
Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA07882; Wed, 30 Jun 1993 22:31:11 +0200
Received: from localhost by austin.BSDI.COM (5.67/1.37)
	id AA09977; Wed, 30 Jun 93 15:30:52 -0500
Message-Id: <9306302030.AA09977@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: searchable index of the web 
In-Reply-To: Your message of Wed, 30 Jun 93 15:59:37 EDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 30 Jun 1993 15:30:47 -0500
From: Tony Sanders <sanders@bsdi.com>

> > I have written a perl script that wanders the WWW collecting URLs, keeping
> > tracking of where it's been and new hosts that it finds.  Eventually,
Darn, I wanted to do that.  So, how "big" is the Web?  Can you figure out
stuff like "width" (distance between documents)?

Wouldn't it be better if you could just ask each server for it's
connectivity? Seems like this would make things run a **lot** faster.
Since each server has local access to all the information it could
just find all the HREFs real quick, unique them and report to
someone else.

>>>> Dale & TimBL <<<<
This would be a good topic to cover at the workshop.

I was shocked to see how few home pages I've visted.  I really need to
get out more often :-)  Then I noticed that they all have the :port
which mans it's not the same.  Marc, when doing annotations and
checking the "visited" list maybe you should ignore :80 on http:
servers?

We need to do something anyway.  With annotations you can get really
lost in the Web.

--sanders

From daemon  Wed Jun 30 22:34:59 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13108; Wed, 30 Jun 93 22:35:01 MET DST
Return-Path: <mkgray@athena.mit.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA13104; Wed, 30 Jun 93 22:34:59 MET DST
Received: from ATHENA-AS-WELL.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11512; Wed, 30 Jun 1993 22:58:22 +0200
Received: from URANUS.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA17474; Wed, 30 Jun 93 16:58:20 EDT
From: mkgray@athena.mit.edu
Received: by uranus.MIT.EDU (AIX 3.2/UCB 5.64/4.7) id AA23487; Wed, 30 Jun 1993 16:58:18 -0400
Message-Id: <9306302058.AA23487@uranus.MIT.EDU>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: searchable index of the web 
In-Reply-To: Your message of Wed, 30 Jun 93 15:30:47 -0500.
             <9306302030.AA09977@austin.BSDI.COM> 
Date: Wed, 30 Jun 93 16:58:15 EDT

Ok, how "big" is the Web.  Here is what W4 has found out.
Actually, first I'd better explain a little bit about what the wanderer does.
It does a simple depth first search, with an added feature I call 'getting
bored'.  That is, if it finds a number of documents that have the same
URL, up to the last field (eg http://foo/bar/blah, http://foo/bar/baz, 
http://foo/bar/more) it will eventually get 'bored' and skip it.  This makes
it go a little quicker.  Of course, it potentially is losing some documents
here, but probably not.

W4 took many hours (maybe 20) to run, but I don't remember exactly, because it
saves state so I could kill it and restart it whenever I wanted.  Well, in
total, the W4 found more than 17,000 http documents (didn't follow any other
kinds of links) and more than 125 unique hosts.  In the current version,
it *only* retrieved the URL of the document.
In the next version, I hope to have it do the following other things.

o	Get the <title>Title</title> of the document
o	Get the length of the document
o	Do a 'keyword' analysis of the document
o	Count the number of links in a document
o	Improve on the boredom system

By a 'keyword' analysis, I mean looking at the document for words that
appear frequently, but aren't normally common words.  Additionally, titles
and things appearing in headers would be good candidates for keyword searches.
I'll try and get the current code at least clean enough that I'm willing to
let everyone in the world to see it, but if you *really* want to see it now,
send me mail.  Any other suggestions would be welcome.

Once this index is produced, it will be searchable via http, and I suppose
by WAIS though I really detest the way WAIS restricts searches.  In any case,
there is a possibility that this will be done by the end of the summer.

						Matthew Gray
						mkgray@athena.mit.edu

From daemon  Wed Jun 30 23:50:03 1993
Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14549; Wed, 30 Jun 93 23:50:05 MET DST
Return-Path: <marca@wintermute.ncsa.uiuc.edu>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA14545; Wed, 30 Jun 93 23:50:03 MET DST
Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA21535; Thu, 1 Jul 1993 00:13:26 +0200
Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16648
  (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Wed, 30 Jun 93 17:13:24 -0500
Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
	for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA29682; Wed, 30 Jun 93 17:16:14 -0500
Date: Wed, 30 Jun 93 17:16:14 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-Id: <9306302216.AA29682@wintermute.ncsa.uiuc.edu>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: searchable index of the web 
In-Reply-To: <9306302030.AA09977@austin.BSDI.COM>
References: <9306302030.AA09977@austin.BSDI.COM>
X-Md4-Signature: 5d2723eadde1b8c147faa7143c6a4e17

Tony Sanders writes:
> I was shocked to see how few home pages I've visted.  I really need to
> get out more often :-)  Then I noticed that they all have the :port
> which mans it's not the same.  Marc, when doing annotations and
> checking the "visited" list maybe you should ignore :80 on http:
> servers?

Yup.  And 70 for Gopher servers.  And WAIS gateways should be
equivalenced.  And trailing periods in machine names should be
ignored.  And trailing slashes in directory names.  And...

Big problem; hopefully solved by URN's; planning on patching the hell
out of libwww2 for Mosaic 2.0 to try to do as much as possible though.
> 
> We need to do something anyway.  With annotations you can get really
> lost in the Web.
> 
> --sanders

Cheers,
Marc


