Re: [apps-discuss] URL definitions and draft-ruby-url-problem

Bjoern Hoehrmann <derhoermi@gmx.net> Fri, 19 December 2014 18:41 UTC

From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Date: Fri, 19 Dec 2014 19:41:02 +0100
Message-ID: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de>
References: <B53877D1-0996-448F-982D-4536805F2B1E@vpnc.org>
In-Reply-To: <B53877D1-0996-448F-982D-4536805F2B1E@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tFUzvF4zFfGgIqJwYkE6UfqAsFI
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem
Precedence: list

* Paul Hoffman wrote:
>This seems like an important document for us to look at, and possibly 
>adopt. Section 3 is pretty scary, and section 4 seems like a very 
>reasonable solution.

I have reviewed this document. Sections 1 and 2 seem reasonable to me.
Section 3 has

   The main problem is conflicting specifications that overlap but don't
   match each other.

   Additionally, the following are issues that need to be resolves to
   make URL processing unambiguous and stable.

   o  Nomenclature: over the years, a number of different sets of
      terminology has been used.  URL / URI / IRI is not the only
      difference.  [tantek-slice] chronicles a number of differences.

The latter refers to differences among APIs for manipulating resource
identifiers. I do not think that is a problem and does not need solving.

   o  Parameterization: standards in this area need to define such
      matters as normalization forms and values for parameters such as
      UseSTD3ASCIIRules.

Where the relevant standards allow implementations to choose options, it
is usually because there are good reasons to do so. Implementers ought
to document their choices properly, and it is a good thing when similar
implementations make the same choices, it might even be useful to have a
specification saying "Web browsers must use these options: A, B, C", but
that would just be a matter of doing it. So I am not sure what problem
needs solving in this regard.

   o  Interoperability: even after accounting for the above, there is a
      demonstrable lack of interoperability across popular libraries and
      browsers.  [whatwg-interop] identifies a number of such
      differences.

There are different classes of problems in this regard, e.g. there may
be existing requirements that are widely ignored, there may be ambiguous
requirements interpreted differently across implementations, there may
be implementation-defined behavior that varies across implementations in
a harmful manner, or there may be widely deployed behavior where further
standardisation might be useful, to mention a few. I think it would be
helpful to discuss these classes of problems separately.

   o  Specific scheme definitions: some UR* scheme definitions are
      woefully out of date, incomplete, or don't correspond to current
      practice, but updating their definitions is unclear.  This
      includes "file:", for which there is a current effort, but there
      are others which need review (including 'ftp:', 'data').

An open question here seems to be how to separate concerns. Can updating
specifications for individual schemes be done independently? If so, that
also would seem to simply require somebody doing it, so I am not sure of
the problem indicated here.

As for the "Outline of Potential Solution" in section 4, I agree that a
plan should be built. How many specifications, for instance, should we
have, what would be their scope, and what would be their contents? With-
out a plan, considering the other points in the section seems premature;
perhaps some of them are reasonable things to do independently of any
plan; in that case, they could simply be done.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

[apps-discuss] URL definitions and draft-ruby-url… Paul Hoffman
Re: [apps-discuss] URL definitions and draft-ruby… Bjoern Hoehrmann
Re: [apps-discuss] URL definitions and draft-ruby… Sam Ruby
Re: [apps-discuss] URL definitions and draft-ruby… Bjoern Hoehrmann
Re: [apps-discuss] URL definitions and draft-ruby… Martin J. Dürst
Re: [apps-discuss] URL definitions and draft-ruby… Martin J. Dürst
Re: [apps-discuss] URL definitions and draft-ruby… Sam Ruby
Re: [apps-discuss] URL definitions and draft-ruby… Sam Ruby
Re: [apps-discuss] URL definitions and draft-ruby… Larry Masinter