Re: IDNA, IRI, HTML5 coordination

Here's a few technical comments.

On Sep 16, 2009, at 8:43 AM, Larry Masinter wrote:

>
> ==============================================
> Some design goals:
>
> I’ve tried to write down some of the design goals which I think are  
> important; these may be in conflict, but I've tried to propose  
> priorities which make sense to me. Does anyone disagree with any of  
> these? Think some are missing?

Overall, your design goals sound great to me, and I think a unified  
and cleaned up spec for resource identifiers would be of great value.

>
>
> Consistent Terminology: Multiple definitions of the same terms in  
> different documents are to be avoided; even consistent definitions  
> are problematic. Where possible, newer documents should reference  
> older specs.
>
> Security: Avoiding security problems (e.g., difficulties due to  
> spoofing, renaming, misuse of DNS) is a high priority; avoiding  
> security problems is a higher priority than being consistent with  
> existing applications.
>
> Uniform behavior: Optional interpretation rules for resource  
> identifiers which give different results depending on the processing  
> model chosen are to be avoided.
>
> Consistency of web and other Internet applications:   
> Interoperability between web applications (browsers, proxies,  
> spiders, etc.) and other Internet applications which use resource  
> identifiers (email, directory services) is important, and should be  
> given equal (or nearly equal) priority as interoperability between  
> web browsers. Recommended practice for web applications and other  
> Internet applications should be the same – those creating web  
> content should not be encouraged to create Resource Identifiers  
> (whether called URLs, URIs, IRIs, Web Addresses) which would not  
> function in other applications.
>
> Consistency of specifications with implementations:  When existing  
> specifications do not match the common practice of existing  
> applications, it is appropriate to update the existing  
> specification, even if long standing.
>
> Improve interoperability: When existing implementations disagree,  
> document existing practice, but recommend (normatively) the behavior  
> that will best lead to improved interoperability.
>
> Separate “specification of what a conservative producer should send”  
> from “advice for what a liberal consumer should accept”: for  
> robustness, the specification of a “conforming” resource identifier  
> should produce can be (if necessary) more restrictive than the  
> specification of what some common applications accept.

I largely agree with this point. But I think the rules for lenient  
processing should be a normative but optional mode, rather than merely  
implementation advice. Referencing specifications should specify  
whether particular contexts require strict processing or lenient  
processing (or allow either). The reason is that advice is not strong  
enough - anyone doing lenient processing should do it in the exact  
same way, or we will have interoperability failures. I believe this  
ties into your "Uniform behavior" design go.

>
> Minimize options and specifications: The split between URI and IRI  
> as separate protocol elements was unfortunate – to have two separate  
> normative terms, “URI” and “IRI” to describe two variations of  
> “resource identifiers”, but having unnecessary multiple non- 
> terminals and terms is harmful. Adding additional terms such as  
> “LEIRI” and “Web Address” or HREF should be avoided, if at all  
> possible.. (In some ways, “URI” was the term used to unify “URL” and  
> “URN”).
>
> Unless necessary for other reasons above, avoid making existing,  
> conforming, and widely implemented behavior non-conforming:  
> Applications which accept URIs but not IRIs should not be made “non- 
> conforming” by a redefinition of terms.
>
> ============================
>
> Some issues (I'm sure there are many more)
>
> •	Can IRI -> URI transformation be scheme independent? ((optional  
> processing would allow
>      non-uniform behavior, not meet IDNA requirements))
> •	Use of term “URL”  ((ambiguous terms))
> •	handling of extra processing rules for XML vs HTML5 vs. IRI document
> •	Whether HTML5 references anything other than IRIbis
> •	Updating the URI scheme registry to be clear that "URI schemes"  
> are the same as “URL schemes”
>      and “IRI schemes”
> •	Can different URI schemes allow different I18N processing rules?
>
>
>
>

Received on Thursday, 17 September 2009 12:50:12 UTC