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

On Apr 21, 2010, at 3:12 PM, Ted Hardie wrote:

> Hi Sam,
>
> My apology for the delay; somehow this thread was not updating, so I  
> missed
> your question until I manually checked the archive to see if my  
> posting of the
> minutes came through.  I'll confirm with Marc on the description and  
> get the
> tickets opened.

Any update on this?

  - Maciej

>
> regards,
>
> Ted
>
> On Wed, Apr 14, 2010 at 1:16 PM, Sam Ruby <rubys@intertwingly.net>  
> wrote:
>> 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 Thursday, 29 April 2010 05:05:33 UTC