Re: detailed critique?

to follow up on what Sam X. Sun said:

> As discussed earlier, I believe that the treatment of
> "#segment" portion in URI syntax is defined following the
> "http:" URL implementation, which is the way implemented in
> libwww.lib, that is:

Almost.  The driving specific case is HTML documents, not HTTP
transport.  The existing implementations are driven by the desire
to make relative URLs work independent of retrieval protocol
across file: ftp: and http: [maybe gopher:] schemes.  It is
precisely this comm-protocol-indepence argument that I thought
Jim laid out well.

And Fote has convinced me that it is essential that file: and
ftp: scheme implementations be protected from thinking that the
#fragment part should be passed to the server.  HTTP servers
could perhaps be taught to ignore the #fragment if included in a
GET, but ftp servers are beyond our ability to retrain.  But this
could still be interpreted as a broad [but not universal] class
of retrieval methods for which the #fragment gets stripped in the
scheme handler before it exercises the external service for
retrieval.

> In other words, when we enter a URI "foo:aaa#bbb", we expect the entire
> "aaa#bbb" to be processed by the "foo" module, not just "aaa" part of it.
> And there is real world demand on this. For example, when we were trying to
> define a URI namespace for SICI, which uses "#" character heavily in its
> naming convention, we found that not only we couldn't map it into "http:"
> URL namespace, neither could we map it "legally" to any new URI namespace,
> because they are all defined following the "http:" convention.

This is extremely helpful.  Now the objection has standing; there is
actual damage possible.  Is the damage limited to having to use %23 for
# wherever it occurs in the SICI name?

Al Gilman

Received on Saturday, 28 February 1998 12:01:11 UTC