Re: requesting feedback regarding HTML5 and RFC 3987

<hat type='individual'/>

On 5/26/11 8:04 PM, Bjoern Hoehrmann wrote:
> * Chris Weber wrote:
>> However, our understanding is that ISSUE-56 can be reopened if new
>> information emerges, such as "IETF completing production of a
>> document suitable as a formal reference".  And of course as chairs
>> of the IRI WG we would like to deliver such a document.
> 
> My impression is that the Working Group largely lacks the resources to
> do much to satisfy requirements of third parties beyond doing rudimen-
> tary bug fixes. That includes a diverse set of active participants and
> the necessary technical expertise as well as a good understanding of the
> needs of any third parties. There are a number of problems with various
> of the deliverables of the group, addressing those meets the needs of a
> very broad community, I think that should be the primary concern here.
> 
>> Here is the minimum baseline that we understand is necessary in order
>> to meet the needs of the W3C's HTML WG:
>>
>> 1) The IRI specification will provide "MUST" language and normative
>>    algorithms for parsing arbitrary Unicode strings as IRI against
>>    an absolute base URL.
> 
> I don't understand what this means. It seems pretty clear to me, to give
> some examples, that not all strings can be processed as if they're IRIs,
> it is common for browsers for instance to reject certain strings as mal-
> formed when you try to use them as resource identifier. Further, due to
> bugs in widely deployed implementations some URI processing is specific
> to the scheme that's employed, say, in `javascript:...#...` the `#` is
> not considered to denote a fragment identifier in some contexts in some
> implementations. I would most certainly disagree with the IRI WG as it's
> currently chartered to include this kind of scheme specific rule.
> 
>> 2) The IRI specification will define how to extract the hostname out
>>    of an IRI for proper resolution and application of the same origin
>>    policy.
> 
> This is already defined in the URI specification for all that I could
> tell based on this brief description, and it would seem anything like a
> "same origin policy" is certainly out of scope of the group.
> 
>> 3) The IRI specification will define how base URI referencing would
>>    be performed for hierarchical schemes.
> 
> I am not sure what "base URI referencing" is, but the URI specification
> would seem to already address how to turn a relative reference into an
> absolute one given a base reference. I do not see what "hierarchical"
> schemes have to do with this.
> 
>> The chairs would like to request feedback from the group, especially
>> those who are also participants in the HTML WG, about whether the
>> those three deliverables would be sufficient to meet the needs of
>> the W3C's HTML WG.
> 
> I am very sure the three points, even with my limited understanding of
> them, would not be sufficient. As I understand it, the issue originated
> with "There is all sorts of URI stuff that should be outsourced"; I've
> not seen so much as a clear separation of what this working group might
> work on versus what it would not. I gave an example above what I would
> find out of scope at the moment.
> 
> Again, I would very much prefer if the working group would use the ex-
> isting documents as a baseline, solicit bug reports, and then deal with
> those, instead of trying to have some document referenced by "HTML5".
> The people working on "HTML5" can and will solve what problems they have
> and there is no need nor good reason to try to solve their problems for
> them at this point. I would be more sympathetic to this if I regularily
> saw people from Microsoft, Mozilla, Google, Apple, Opera, posting here,
> but they are not.

As I understand it, people were concerned that something like "Legacy
extended IRIs for XML resource identification" (LEIRIs) would be
standardized, leading to fragmentation in IRI processing rules...

http://www.w3.org/TR/leiri/

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Received on Wednesday, 1 June 2011 00:21:47 UTC