# Re: URLs and types: concentrate on FTP

John Curran (jcurran@nic.near.net)
Fri, 04 Jun 1993 09:22:48 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Larry Masinter: "Re: URLs and types: concentrate on FTP"
- Previous message: Ed Krol: "Suggest meaning for URN"
- In reply to: Larry Masinter: "Re: URLs and types: concentrate on FTP"

    Message-Id: <9306041322.AA20440@mocha.bunyip.com>

    To: Larry Masinter <masinter@parc.xerox.com>

    Subject: Re: URLs and types: concentrate on FTP

    In-Reply-To: Your message of Fri, 04 Jun 1993 02:02:46 -0700.

                 <93Jun4.020257pdt.2741@golden.parc.xerox.com>

    Date: Fri, 04 Jun 1993 09:22:48 -0400

    From: John Curran <jcurran@nic.near.net>

--------
From: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: URLs and types: concentrate on FTP
Date: Fri, 4 Jun 1993 02:02:46 PDT
...
Well, I'm using 'URL' to mean 'the thing we stick inside HTML
documents and other places to link to data when you don't have a URN
or don't want to make one up.' and, in particular, the thing that
currently has a draft proposal saying:
The data format of a file can only, in the general FTP case,
be deduced from the name, normally the suffix of the name.
This is not standardised. The transfer mode (binary or text)
must in turn be deduced from the data format. It is
recommended that conventions for suffixes of public archives
be established, but it outside the scope of this paper.
...
Now, I'm saying 'put it in the URL' because we've already defined HTML
to include a 'url' in a HREF, and various other utilities are thinking
about using URLs for the same purpose.

Admirable goals. The answer is simple: include additional fields in the
HTML link for holding size, color, format, and anything else that you want.
Until such time as we have actively explored format notation, applications
should continue to use whatever existing mechanisms they have.

Yes, we need to standardize this meta-information. No, it is not an easy
thing to "just do". At this point, URL are LOCATORS, nothing more. It
is quite possible that we may need to create a non-trivial representation
of a resource format (Uniform Resource Format Id: URFI?) to adaquately
describe the fact that XXX is a compressed postscript file, versus a
ZIPped rtf file, versus... If anyone thinks that formats are trivial
to represent, please post your proposal at this time. Include MIME and
character set comparisions as an appendix for easier updating.

Standardizing the type information is an important task, and needs doing.
When we're done, we may be able to augment a URLocation with a URformat
and a URsize and URaccess and a URcost sytanx to build a complete resource
instance descriptor. Hopefully, as each is introduced, life will become
easier on the information tool developers.

However, we do need to have some proposals for URformats, meet to discuss
said proposals, build consensus, and some other similiar activities before
we can say that URformat id's are optional components of a URL. In the
meantime, URLs remain locators.

/John

- Next message: Larry Masinter: "Re: URLs and types: concentrate on FTP"
- Previous message: Ed Krol: "Suggest meaning for URN"
- In reply to: Larry Masinter: "Re: URLs and types: concentrate on FTP"