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

On 04/08/2010 09:40 PM, Ian Hickson wrote:
> 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.

Ted, I would appreciate any feedback the IRIbis WG may have on this input.

- Sam Ruby

> 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,

Received on Wednesday, 14 April 2010 15:04:16 UTC