# Re: New Internet-Draft: finger URL

Reed Wade (wade@cs.utk.edu)
Wed, 15 Feb 1995 16:05:13 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael A. Dolan: "Re: New Internet-Draft: finger URL"
- Previous message: Paul Hoffman: "Re: New Internet-Draft: finger URL"
- In reply to: Paul Hoffman: "Re: New Internet-Draft: finger URL"
- Next in thread: Michael A. Dolan: "Re: New Internet-Draft: finger URL"

    Message-Id: <9502152105.AA14422@honk.cs.utk.edu>

    To: ietf-lists@proper.com (Paul Hoffman)

    Subject: Re: New Internet-Draft: finger URL

    In-Reply-To: Your message of "Wed, 15 Feb 1995 11:58:13 MST."

                 <v02110114ab67fe878c0e@[165.227.40.18]>

    Date: Wed, 15 Feb 1995 16:05:13 -0500

    From: Reed Wade <wade@cs.utk.edu>

>Reed, these are clearly client implementation issues. Anyone writing a
>URL-reading finger client would have to look at how she/he would want to
>parse and send. I believe this is probably beyond what belongs in a URL
>description; look at how little client stuff appeared in RFC 1738.

At minimum, tho, you _must_ unambiguously indicate what part
is data and what part is connection info. That's what the
//host:port/ muck in 1738 is for. If that type of host info
is not used in the url (as we're suggesting) then there needs
to be some other way of indicating what's what.

There are 2 potential interpretations of what might go out on
the wire. This ought to be resolved and not left to implementational
caprice.

-reed

-----
University of Tennessee, Knoxville Dept of Computer Science
Netlib Development Group 'I was kidding,' says bomb suspect
wade@cs.utk.edu -- <URL:http://www.netlib.org/utk/people/ReedWade.html>

- Next message: Michael A. Dolan: "Re: New Internet-Draft: finger URL"
- Previous message: Paul Hoffman: "Re: New Internet-Draft: finger URL"
- In reply to: Paul Hoffman: "Re: New Internet-Draft: finger URL"
- Next in thread: Michael A. Dolan: "Re: New Internet-Draft: finger URL"