Re: New Version Notification for draft-duerst-iri-bis-06

Hi Larry,

Any update on this? It's blocking resolution of HTML WG ISSUE-56[1].  
The requested resolution for ISSUE-56 is to reference IRIbis, but  
doing so would leave dangling references until the following issues  
are addressed.

Regards,
Maciej

[1] http://www.w3.org/html/wg/tracker/issues/56

On Jul 28, 2009, at 2:25 PM, Ian Hickson wrote:

> On Mon, 13 Jul 2009, Larry Masinter wrote:
>>
>> This version attempts to integrate the "web address" concept (called
>> Hypertext Reference or HREF) into the main IRI specification.  The  
>> text
>> has gone through sufficient transformations that I don't have  
>> confidence
>> in its accuracy, but at least it indicates to me that the many  
>> specs are
>> mergable.
>
>   http://tools.ietf.org/html/draft-duerst-iri-bis
>
> It appears that in the process of merging this:
>
>   http://www.w3.org/html/wg/href/draft-ietf.html
>
> ...into the above ID, the following key parts were lost:
>
> * The definition of what is a "valid URL", defined such that an IRI is
>   only a "valid URL" if its query part will be interpreted according  
> to
>   the IRI spec according to the URL parsing algorithm.
>
> * The definition of what is an "absolute URL", defined such that even
>   invalid strings can be valid URLs. For example, the following:
>
>       http://example.com/%
>
>   ...is not a "valid URL" but needs to be an "absolute URL".
>
> * The definition of how to determine whether the following  
> components are
>   present in, and how to obtain their value from, a string that may  
> not
>   be a "valid URL":
>
>     <scheme>
>     <host>
>     <port>
>     <hostport>
>     <path>
>     <query>
>     <fragment>
>     <host-specific>
>
> * The definitions for how to resolve a string to an "absolute URL"  
> when
>   the original string is not necessarily a "valid URL".
>
> (I use the term "URL" here in the HTML5 sense, which has varyingly  
> been
> called a Web Address or an HRef in related work.)
>
>
> The following issues also exist in the draft:
>
> * "is the script's character. encoding" has a typo (misplaced ".")
>
> * Step 8 in the algorithm for parsing HRefs appears to be a corrupted
>   form of the definition of <hostport> from the old HTML5 text. The  
> new
>   text as phrased appears to be meaningless.
>
> * It appears that the parsing algorithm is destructive, in that the
>   results will not be isomorphic with the input. For example, the
>   following:
>
>      http://example.com/##
>
>   ...will turn into:
>
>      http://example.com/#%23
>
>   ...which, once the "resolving" algorithm is reintroduced, will be
>   incompatible with implemented practice.
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'
>

Received on Friday, 21 August 2009 20:33:58 UTC