Re: revised "generic syntax" internet draft

Chris Newman <Chris.Newman@innosoft.com> Fri, 18 April 1997 21:15 UTC

Received: from cnri by ietf.org id aa13092; 18 Apr 97 17:15 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa19693; 18 Apr 97 17:15 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id QAA01741 for uri-out; Fri, 18 Apr 1997 16:57:26 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id QAA01711 for <uri@services.bunyip.com>; Fri, 18 Apr 1997 16:57:23 -0400 (EDT)
Received: from THOR.INNOSOFT.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10324 (mail destined for uri@services.bunyip.com); Fri, 18 Apr 97 16:57:22 -0400
Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHUQ6OQAQC99EV0A@INNOSOFT.COM> for uri@bunyip.com; Fri, 18 Apr 1997 13:56:18 PDT
Date: Fri, 18 Apr 1997 13:57:42 -0700
From: Chris Newman <Chris.Newman@innosoft.com>
Subject: Re: revised "generic syntax" internet draft
In-Reply-To: <9704180819.aa08758@paris.ics.uci.edu>
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: IETF URI list <uri@bunyip.com>
Message-Id: <Pine.SOL.3.95.970418135341.9117E-100000@eleanor.innosoft.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-uri@bunyip.com
Precedence: bulk

On Fri, 18 Apr 1997, Roy T. Fielding wrote:
> Martin, I haven't forgotten about your very detailed problem statement
> at <http://www.imc.org/ietf-url/mail-archive/0052.html>.  My question was
> whether all the other people advocating non-ASCII URLs agree to that
> problem statement, and in particular to the course of action for the
> current draft revision.  The problem I am having is that every time
> I explain why one solution won't work, people defend it by describing
> the merits of some other solution (or even some other problem).  It seems
> to me that if you can't agree on what problem is being solved, then
> arguing about a solution is pointless.

That problem statement is a bit verbose, but accurate.

> I think there is a way to define UTF-8 preference for URL encoding
> such that it won't break existing services, by forbidding transcoding
> of already-encoded octets.  However, I won't bother to explain that
> until there is broad agreement on what needs to be solved.

Yes, if you forbid transcoding of %80-%FF, and that representation were
actually used in the filesystem, then the charset (or lack thereof) in the
filesystem isn't a problem.