Re: Proposed Charter and Agenda for IRI BOF at IETF 76

On Sep 26, 2009, at 11:51 PM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> ...
>> I don't see a great advantage in splitting the specs, as this makes  
>> cross-references more complicated. If it were just a matter of  
>> transforming the kind of string that may appear in an "href"  
>> attribute into a valid IRI, then your proposal might be plausible.  
>> However, in addition to converting to a URI, HTML UAs also need to  
>> be able to do the following to resource identifiers treated with  
>> lenient processing: (a) separate into components, even when the  
>> string is not a valid URI or IRI, and in a way that is not  
>> necessarily equivalent to first converting to a valid IRI or URI;  
>> (b) resolve a reference relative to a base when either the  
>> reference or the base might not be a valid URI or IRI; (c)  
>> determine if a reference is "absolute" even if it might not be a  
>> valid URI or IRI. That would mean a great deal of algorithms  
>> defined in a totally separate place from the URI spec. This is what  
>> the Web Address spec[1] attempted to do, and it ends up duplicating  
>> a lot of concepts from IRI/URI. This effort was set aside in favor  
>> of IRIbis incorporating the necessary content.
>> ...
>
> a) As already mentioned in this thread, it appears this is covered  
> by the text in <http://tools.ietf.org/html/rfc3986#appendix-B>.

I haven't thought carefully about Appendix B to determine if its  
component splitting does the right thing in all cases. Tentatively it  
looks about right.

> b) Could you remind us why it's not possible to translate both to  
> valid URI/IRI and references first and then use the standard behavior?

That is what the Web Address algorithm (the former HTML5 algorithm) in  
fact does, see step 9: <http://www.w3.org/html/wg/href/draft.html#resolving-urls 
 >. However, the steps to translate to valid URIs (and the required  
postprocessing rules) are quite involved and must be specified  
somewhere.

>
> c) Again, see <http://tools.ietf.org/html/rfc3986#appendix-B>.

I can't see where Appenix B defines this.

>
> I do realize that a more normative way of what Appendix B says may  
> be needed, but please let's not dismiss what's already in the spec  
> as unusable.

I don't believe I dismissed it. But I agree, a normative version is  
needed.

Regards,
Maciej

Received on Sunday, 27 September 2009 07:20:56 UTC