Re: Change definition of URL to normatively reference IRI specification using a well-defined interface

On Thu, Apr 8, 2010 at 9:31 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> my understanding is that the correct next step will be to describe this issue
> in a way that we can track.

I've tried to write descriptions of the two issues. Please let me know
if you need any further advice on the matter.

Issue 1:
========================================================================
Update the IRI specification to define an algorithm with the following
characteristics:

  Input:
    * a string

  Output:
    * a boolean representing whether the algorithm succeeded or failed
    * if the algorithm succeeded, one or more strings corresponding to
      the following components, each of which may be present or absent:
      - <scheme> component
      - <host> component
      - <port> component
      - <hostport> component
      - <path> component
      - <query> component
      - <fragment> component
      - <host-specific> component

This algorithm must be such that it can be used where HTML5 says "the
user agent must use the parse an address algorithm defined by the IRI
specification" in a manner that user agents including major browser
vendors will be willing to implement the algorithm as written.

Exactly what this algorithm must do is a matter that will need careful
research, reverse-engineering existing UAs.

The algorithm needs to be defined in such a way that it can be
referenced unambiguously by name. For example, text such as the
following could be used to introduce this algorithm:

   When a specification says that a user agent is to *parse an
   address*, given a string INPUT, it must run the following steps,
   which return a failure/success condition and a set of components:

    ...

This gives a completely unambiguous and clear way to invoke the
algorithm described in the spec, along with RFC2119-level clarity
regarding what such invokations imply for the user agent.
========================================================================

Issue 2:
========================================================================
Update the IRI specification to define an algorithm with the following
characteristics:

  Input:
    * a string A
    * a string B, which was previously output from this algorithm
    * a character encoding

  Output:
    * a boolean representing whether the algorithm succeeded or failed
    * if the algorithm succeeded, a string

This algorithm must be such that it can be used where HTML5 says "the
result of applying the resolve an address algorithm defined by the IRI
specification to resolve url relative to base using encoding encoding"
in a manner that user agents including major browser vendors will be
willing to implement the algorithm as written.

Exactly what this algorithm must do is a matter that will need careful
research, reverse-engineering existing UAs.

The algorithm needs to be defined in such a way that it can be
referenced unambiguously by name. For example, text such as the
following could be used to introduce this algorithm:

   When a specification says that a user agent is to *resolve an
   address", given a string INPUT, a second string BASE, and a
   character encoding ENCODING, it must run the following steps, which
   return a failure/success condition and a string:

    ..."

This gives a completely unambiguous and clear way to invoke the
algorithm described in the spec, along with RFC2119-level clarity
regarding what such invokations imply for the user agent.
========================================================================

HTH,
-- 
Ian Hickson

Received on Friday, 9 April 2010 01:40:54 UTC