This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Details of the proposed change can be found here: http://lists.w3.org/Archives/Public/public-html/2009Nov/0153.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: What URL should I use to refer to IRI bis?
Are you asking for a URL, or for a revision of iri-bis? I personally would use <http://tools.ietf.org/html/draft-duerst-iri-bis-07>, but <http://www.ietf.org/id/draft-duerst-iri-bis-07.txt> would do as well. I'm pretty sure you're asking for something else though, so maybe you could elaborate.
I suggest using a reference: [IRIBIS] "Internationalized Resource Identifiers (IRIs)", Work in Progress, <http://tools.ietf.org/html/draft-duerst-iri-bis>. Note that the (proposed) charter for IETF work on this document has as a requirement that the document remain suitable as a normative reference from HTML. The IETF work on this document is scheduled for completion before the scheduled Candidate Recommendation for HTML5 and before the likely close of Last Call for this document. It will be necessary to track both during the W3C Last Call period.
I looked at doing this, but the IRIbis draft isn't yet in a state where I can really do this. There's no algorithm that defines how to resolve an arbitrary string against an absolute base URL, as far as I can tell; in particular, nothing seems to take into account the HRef-charset so as to encode characters differently in different parts of the string. There's no definition of "valid URL" that I can refer to (that takes into account the "HRef-charset"). The parsing algorithm is destructive (e.g. the <path> of "http://example.com/%X" is, as far as I can tell, 5 characters long ("/%25X"), not three as required by Web compat ("/%X"). There's no definition of "absolute URL" that I can use (mostly because the current parsing algorithms are destructive). This is all assuming that the split should be as it is now; this may not be a good assumption. If we should move the interface a bit, that may change matters. For example, it seems to me we probably what the "HRef-charset" definition in HTML5, rather than in the IRI spec. Please advise on how I should proceed.
Please clarify what you think is missing: http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0670/iri-rewrite-draft.html attached to http://lists.w3.org/Archives/Public/public-html/2009Nov/0670.html contains a complete proposed rewrite of section 2.5.1 including the definition of: The term resolve (in the context of resolve a URL relative to another URL), which seems to address: "There's no algorithm that defines how to resolve an arbitrary string against an absolute base URL" Perhaps the text in the "iri-rewrite-draft.html" belongs in the IRI document itself, though, but this adjustment can be coordinated between the two documents.
That text is woefully vague. For example the only conformance criteria in the definition of "resolve" is "these parsed components may then be recombined", which isn't even a requirement (it's a may, not a must). I'm looking for something which is unambiguous, absolutely clear, precise, and explicit about how two incoming Unicode strings and a character encoding are turned into a single Unicode string. Currently this simply isn't present in the detail needed to interoperably implement URL resolution in the face of erroneous URLs. Ideally this would mean a set of steps introduced with a MUST requirement, which can be blindly implemented with little thought, with no interpretation needed.
Just a few notes: - the new IETF IRI WG has started work, see http://tools.ietf.org/html/draft-ietf-iri-3987bis-00; so that's what should be discussed - HTML5 currently refers to WEBADRESSES, which in http://www.w3.org/html/wg/href/draft#resolving-urls, contains stuff that shouldn't be going into IRIbis because of HTML dependencies: "Otherwise, let base be the base URI of the element, as defined by the XML Base specification, with the base URI of the document entity being defined as the document base Web address of the Document that owns the element. [XMLBASE] For the purposes of the XML Base specification, user agents must act as if all Document objects represented XML documents." This should be fixed ASAP, because it is (and has been for a long time) blocking progress. I recommend that we come to a consensus what the interface between HTML5 and IRIBIS should be (who is defining what; for things like "resolving" what are the parameters?). Once we have that, we should be able to move things forward.
(In reply to comment #6) > That text is woefully vague. For example the only conformance criteria in the > definition of "resolve" is "these parsed components may then be recombined", > which isn't even a requirement (it's a may, not a must). It's just prose. You do not need a MUST to define how something is done. I realize you disagree with that, but trying to impose a specific specification style on others doesn't seem to be productive. > I'm looking for something which is unambiguous, absolutely clear, precise, and > explicit about how two incoming Unicode strings and a character encoding are > turned into a single Unicode string. Currently this simply isn't present in the > detail needed to interoperably implement URL resolution in the face of > erroneous URLs. Ideally this would mean a set of steps introduced with a MUST > requirement, which can be blindly implemented with little thought, with no > interpretation needed. It would be helpful if you could elaborate what's wrong; maybe by adding an example (I totally believe that something might be wrong, but it's unproductive to do just handwaving).
*** Bug 7391 has been marked as a duplicate of this bug. ***
Some time ago this was escalated as: http://www.w3.org/html/wg/tracker/issues/56
*** Bug 9138 has been marked as a duplicate of this bug. ***
(From bug 9138:) WEBADDRESSES contains stuff that needs to go back into HTML5, as it wouldn't be a candidate for inclusion in IRIbis (for instance, <http://www.w3.org/html/wg/href/draft>, Part 3 depends on specifics of HTML and the DOM).
I scanned the HTML5 document looking for references to [WEBADDRESSES] and the only references were in the definitions covered by the change proposal. So I don't know what else actually needs to be moved back into the HTML document. That is, my belief is that the change proposal for ISSUE-56 which is the tracker issue for this bug... well, that it's complete, ready to go, and, if the change were accepted, we'd be done as far as getting HTML 5 to last call.
WG Decision: http://lists.w3.org/Archives/Public/public-html/2011Mar/0397.html
(In reply to comment #14) > WG Decision: http://lists.w3.org/Archives/Public/public-html/2011Mar/0397.html I don't understand. That message seems to be about Content-Language, not URLs.
(In reply to comment #15) > (In reply to comment #14) > > WG Decision: http://lists.w3.org/Archives/Public/public-html/2011Mar/0397.html > > I don't understand. That message seems to be about Content-Language, not URLs. My bad. Correction posted here: http://lists.w3.org/Archives/Public/public-html/2011Mar/0404.html - Sam Ruby
I presume that this decision is specifically to revert this change: http://html5.org/tools/web-apps-tracker?from=3244&to=3245 ...and to fix any conflicts resulting. If so, should I also add a warning that the text is known to be quite wrong and that people should ignore it for now? Or is it safe to assume people will ignore it?
(In reply to comment #17) > I presume that this decision is specifically to revert this change: > http://html5.org/tools/web-apps-tracker?from=3244&to=3245 > ...and to fix any conflicts resulting. If so, should I also add a warning that > the text is known to be quite wrong and that people should ignore it for now? > Or is it safe to assume people will ignore it? Ian: not sure what could what could have caused that link to rot since the proposal was created; but yes, that does appear to be the change referenced by http://lists.w3.org/Archives/Public/public-html/2010Jul/0035.html Adam: can you work with Ian to resolve any conflicts? Ian: if you have new information w.r.t. bugs, please share.
> Adam: can you work with Ian to resolve any conflicts? Sure.
(In reply to comment #17) > I presume that this decision is specifically to revert this change: > http://html5.org/tools/web-apps-tracker?from=3244&to=3245 > ...and to fix any conflicts resulting. If so, should I also add a warning that > the text is known to be quite wrong and that people should ignore it for now? > Or is it safe to assume people will ignore it? I think one or more bugs would be a better way to indicate known problems than a blanket warning in the spec.
Checked in as WHATWG revision r6007. Check-in comment: apply wg decision http://html5.org/tools/web-apps-tracker?from=6006&to=6007