still one smiley glitch

still one smiley glitch

[Karl Kleinpaste]

5.2.36 + Jan Vroonhof's very latest smiley patch.

Article <31eb8c79.3291435@206.13.28.28> contains a line:

go to either http://www.altavista.com/  or  http:/dejanews.com/

in which the first <colon><slash><slash> is shown correctly, but the
second <colon><slash><slash> appears as http<glyph>dejanews.com/

--karl,
mildly confused

Re: still one smiley glitch

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "KK" == Karl Kleinpaste <karl@lycos.com> writes:

KK> go to either http://www.altavista.com/  or  http:/dejanews.com/
KK> in which the first <colon><slash><slash> is shown correctly, but the
KK> second <colon><slash><slash> appears as http<glyph>dejanews.com/

That would be because "<colon><slash>" is *NOT* a valid URL component.
It must be a colon followed by two slashes.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMe0zjJ6VRH7BJMxHAQEqBAQAjMgrSl5siZ7/s0DLWgvYb4CFWzQfwjEs
MuU5WX2Fq8D0LmnX0dybzojXu4+WfV3rj0O0t9LLDxasl2YSXLmqxMC7i/UmXebb
LdJllA+z5LFzIXKhvBFt3OUs0lTiAfbtWAagN/c17kBEEnrzZHnFYiAc4cP/3YhN
HNJB2pMSs2M=
=4YDn
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ Climb your way to the top; that's why the
<ratinox@unilab.dfci.harvard.edu>   \ drapes are there. -A cat's guide to life
http://www.dfci.harvard.edu/         \ 

Re: still one smiley glitch

[William Perry]

Karl Kleinpaste wrote:
> 
> 5.2.36 + Jan Vroonhof's very latest smiley patch.
> 
> Article <31eb8c79.3291435@206.13.28.28> contains a line:
> 
> go to either http://www.altavista.com/  or  http:/dejanews.com/
> 
> in which the first <colon><slash><slash> is shown correctly, but the
> second <colon><slash><slash> appears as http<glyph>dejanews.com/

  Well, seeing as how the second URL is techincally invalid, I wouldn't
worry too much about it. :)

-Bill P.

Re: still one smiley glitch

[Per Abrahamsen]

>>>>> "WP" == William Perry <wmperry@aventail.com> writes:

>> go to either http://www.altavista.com/  or  http:/dejanews.com/

WP>   Well, seeing as how the second URL is techincally invalid, I wouldn't
WP> worry too much about it. :)

Really?  I thought it would refer to the directory `dejanews.com'
located in the root of the local machine.  

I suspect it was a typo from Karl's side anyway.

Re: still one smiley glitch

[Karl Kleinpaste]

Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:
> That would be because "<colon><slash>" is *NOT* a valid URL component.
> It must be a colon followed by two slashes.

Yup, my error.  I hadn't quite noticed that the 2nd URL was malformed.

Re: still one smiley glitch

[Kai Grossjohann]

>>>>> On 17 Jul 1996 21:10:51 +0200, Per Abrahamsen
>>>>> <abraham@dina.kvl.dk> said:

>>>>> "WP" == William Perry <wmperry@aventail.com> writes:

  WP> Well, seeing as how the second URL is techincally invalid, I
  WP> wouldn't worry too much about it. :)

  Per> Really?  I thought it would refer to the directory
  Per> `dejanews.com' located in the root of the local machine.

AFAIK the RFC sez if the URL begins with a protocol spec it is an
absolute URL.  Absolute URLs must contain the host name (preceded by
this // thingy).

Nonetheless, some browsers seem to interpret "http:/foo" as a local URL
and don't grok "/foo".

kai
-- 
Life is hard and then you die.

Re: still one smiley glitch

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

PA> Really?  I thought it would refer to the directory `dejanews.com'
PA> located in the root of the local machine.  

Really; a local file or directory URL looks like this:
<URL:file://dejanews.com/>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMe4+tJ6VRH7BJMxHAQErHgP+KhjMaErABUHV5uIhW4W4gNNm6ld9swHe
yYH1r+CWdHux5Xt7gFJoDIJTXAEZ2q+FQhW8fsz+gpInCuHPWthqqCNHtnbTsytu
kM6DES35BN/hBFRJC5RJTL7fcZdL83l/e78sHm97JZjsQcudGnYmpoGkDLA6WcuA
YSjOyhYIpTs=
=66+0
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ Climb your way to the top; that's why the
<ratinox@unilab.dfci.harvard.edu>   \ drapes are there. -A cat's guide to life
http://www.dfci.harvard.edu/         \ 

Re: still one smiley glitch

[Lars Balker Rasmussen]

Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:
> >>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> PA> Really?  I thought it would refer to the directory `dejanews.com'
> PA> located in the root of the local machine.  
> 
> Really; a local file or directory URL looks like this:
> <URL:file://dejanews.com/>

Hmm, a _local_ file would be <URL:file:/dejanews.com> which indeed is as
Per describes it.

Picking nits,
-- 
Lars Balker Rasmussen
<URL:http://www.daimi.aau.dk/~gnort/>  <URL:mailto:lars@rasmussen.org>

Re: still one smiley glitch

[Greg Thompson]

>"RP" == Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

  PA> Really?  I thought it would refer to the directory `dejanews.com'
  PA> located in the root of the local machine.  

  RP> Really; a local file or directory URL looks like this:
  RP> <URL:file://dejanews.com/>

that's one form.  other valid file urls are:

<URL:file://localhost/dir/file>	this one is valid on any machine
<URL:file:///dir/file>		this one is to be treated the same as
				localhost
<URL:file://dejagnus.com/dir/file>	this one is only valid if
					you're on the machine
					dejagnus.com, otherwise you
					can't access it.

from rfc1738:

3.10 FILES

   The file URL scheme is used to designate files accessible on a
   particular host computer. This scheme, unlike most other URL schemes,
   does not designate a resource that is universally accessible over the
   Internet.

   A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

   For example, a VMS file

     DISK$USER:[MY.NOTES]NOTE123456.TXT

   might become

     <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

   As a special case, <host> can be the string "localhost" or the empty
   string; this is interpreted as `the machine from which the URL is
   being interpreted'.

   The file URL scheme is unusual in that it does not specify an
   Internet protocol or access method for such files; as such, its
   utility in network protocols between hosts is limited.
-- 
		-greg				     woke up depressed
						       i left for work
						   you have a good day
							  -soundgarden

Re: still one smiley glitch

[Per Abrahamsen]

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

PA> Really?  I thought it would refer to the directory `dejanews.com'
PA> located in the root of the local machine.  

>>>>> "RP" == Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:

RP> Really; a local file or directory URL looks like this:
RP> <URL:file://dejanews.com/>

I meant the root of the current http server, i.e. local compared to
the current document) .  Like this

	This page is hosted by <a href="http:/index.html">foobar</a>.

Works for me, but that might be an Netscape bug.

Re: still one smiley glitch

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

PA> I meant the root of the current http server, i.e. local compared to
PA> the current document) .  Like this

You mean a relative document reference.  Those are properly set up like
this:

for an absolute local reference:
<a href="/home/ratinox/Bookmarks.html">...</a>
and for a relative local reference:
<a href="Bookmarks.html">...</a>

with no lookup type.

Neither of these are valid URLs, though they are valid HTML.  URLs are
unambiguous, human-readable addresses.  A valid URL has this format:

	The URL specifier "<URL" at the beginning of the line
	The type of lookup
	The colon-slash-slash delimiter
	A host name (should be fully qualified)
		Optionally a colon and port number
	A slash delimiter
		Optionally a directory path or path to file.  If a
		directory then there must be a trailing slash.
	The URL closure ">" and nothing else on the line.

And yes, I know, my .sig does not contain a valid URL.  Sue me :).

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMe5yZZ6VRH7BJMxHAQHmOgP/RHpv23Cpn0Rkocqt29/xgwcLX9C4UfUV
+AeH1iQjoo2BkBDqQl9jrpdHulnAc7tVZ+YHHEzHXQkJ84k759srLKyF6I3lxu1W
MDjSR/I33aIREi4mzwraBoFmaA4ViGu8tUWe8bFbg54un5XDe5pq9KAr5LkoB9sK
NoISc4CcTO0=
=V09q
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ When in doubt, cop an attitude. -A cat's
<ratinox@unilab.dfci.harvard.edu>   \ guide to life
http://www.dfci.harvard.edu/         \ 

Re: still one smiley glitch

[Greg Thompson]

>"RP" == Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:

  RP> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

  PA> I meant the root of the current http server, i.e. local compared to
  PA> the current document) .  Like this

  RP> You mean a relative document reference.  Those are properly set
  RP> up like this:

  RP> for an absolute local reference:
  RP> <a href="/home/ratinox/Bookmarks.html">...</a>
  RP> and for a relative local reference:
  RP> <a href="Bookmarks.html">...</a>

  RP> with no lookup type.

  RP> Neither of these are valid URLs, though they are valid HTML.
  RP> URLs are unambiguous, human-readable addresses.  A valid URL has
  RP> this format:

  RP> 	The URL specifier "<URL" at the beginning of the line
  RP> 	The type of lookup
  RP> 	The colon-slash-slash delimiter
  RP> 	A host name (should be fully qualified)
  RP> 		Optionally a colon and port number
  RP> 	A slash delimiter
  RP> 		Optionally a directory path or path to file.  If a
  RP> 		directory then there must be a trailing slash.
  RP> 	The URL closure ">" and nothing else on the line.

this is not true.  <URL:> has nothing to do with proper url syntax.
it has become common convention when embedding a url in a piece of
mail or something, but a url does not need that stuff around it.  it
sounds like you are describing a convention for putting a url in a
message, not the proper syntax of a url.
-- 
		-greg	   a fire in its heart will not let it die. it
			      roars + fumes + cries all day.  shoot me
			   out the sky. pop!  pop! down goes the enemy
								-rodan

Re: still one smiley glitch

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "GT" == Greg Thompson <gregt@visix.com> writes:

GT> this is not true.  <URL:> has nothing to do with proper url syntax.
GT> it has become common convention when embedding a url in a piece of
GT> mail or something, but a url does not need that stuff around it.  it
GT> sounds like you are describing a convention for putting a url in a
GT> message, not the proper syntax of a url.

Check the RFCs (1738?), because what I describe is exactly the standard
for placing a URL in a human-readable document, which is what we are
dealing with.  Without the '<URL:...>' wrapper, a URL in such a document
is not considered valid; it has not been properly delimited.

Therefore, the proper format for specifying a generic file is
<URL:file://hostname/path/to/file>
Yes, I goofed last time up; the hostname is not optional.  For a local
file, the hostname part may be 'localhost'.

And a minor correction.  Usernames and passwords may appear in a URL,
like this:
<URL:ftp://foo:bar@ftp.baz.com/path/to/file>
They are, of course, optional.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMe+ZFZ6VRH7BJMxHAQEgmwP+MTrGhz2Cf2svOfnCSHZyRWzh5A9yRX3c
/T8PByeZj56I1+OVvQjS+cCmG/JCIdq2wjZscipo3/c4I47N9g9pGggZJDNKfs5X
u580lB+CXhJpjTHT/P6eWd3igAFQAakgVkX0ESrt0V8G9PbteuOeFuZz1uNVd6q7
VmytNroDTIM=
=PxiU
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ If you're not receiving enough attention,
<ratinox@unilab.dfci.harvard.edu>   \ try knocking over some very expensive
http://www.dfci.harvard.edu/         \ antique lamps. -A cat's guide to life

Re: still one smiley glitch

[Steven L Baur]

>>>>> "Richard" == Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:
>>>>> "GT" == Greg Thompson <gregt@visix.com> writes:

GT> this is not true.  <URL:> has nothing to do with proper url syntax.
GT> it has become common convention when embedding a url in a piece of
GT> mail or something, but a url does not need that stuff around it.  it
GT> sounds like you are describing a convention for putting a url in a
GT> message, not the proper syntax of a url.

Richard> Check the RFCs (1738?), because what I describe is exactly
Richard> the standard for placing a URL in a human-readable document,
Richard> which is what we are dealing with.  Without the '<URL:...>'
Richard> wrapper, a URL in such a document is not considered valid; it
Richard> has not been properly delimited.

RFC 1808 deals with relative URLs
RFC 1738 deals with absolute URLs

APPENDIX: Recommendations for URLs in Context
   
   URIs, including URLs, are intended to be transmitted through
   protocols which provide a context for their interpretation.
   
   In some cases, it will be necessary to distinguish URLs from other
   possible data structures in a syntactic structure. In this case, is
   recommended that URLs be preceeded with a prefix consisting of the
   characters "URL:". For example, this prefix may be used to
   distinguish URLs from other kinds of URIs.
   
   In addition, there are many occasions when URLs are included in other
   kinds of text; examples include electronic mail, USENET news
   messages, or printed on paper. In such cases, it is convenient to
   have a separate syntactic wrapper that delimits the URL and separates
   it from the rest of the text, and in particular from punctuation
   marks that might be mistaken for part of the URL. For this purpose,
   is recommended that angle brackets ("<" and ">"), along with the
   prefix "URL:", be used to delimit the boundaries of the URL.  This
   wrapper does not form part of the URL and should not be used in
   contexts in which delimiters are already specified.
   
   In the case where a fragment/anchor identifier is associated with a
   URL (following a "#"), the identifier would be placed within the
   brackets as well.
   
   In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
   need to be added to break long URLs across lines.  The whitespace
   should be ignored when extracting the URL.


-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.