W3C home > Mailing lists > Public > public-html@w3.org > December 2009

RE: HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

From: Larry Masinter <masinter@adobe.com>
Date: Tue, 1 Dec 2009 15:59:24 -0800
To: Maciej Stachowiak <mjs@apple.com>
CC: "public-html@w3.org" <public-html@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118DC9EC912@nambx04.corp.adobe.com>
Re ISSUE-56 and ACTION-137:

> 2) There does not appear to be a rationale. Please provide a Rationale  
> section.

Here is a Rationale section:

This issue has been discussed at length in the HTML working group.

The original message from Roy Fielding which raised the issue,
as well as additional pointers to discussions and rationales may be 

* in the tracker entry for this issue:


*  the action that led to this change proposal:

*  discussion on:

Please see those discussions for more details.


-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Tuesday, December 01, 2009 12:13 PM
To: Larry Masinter
Cc: public-html@w3.org; PUBLIC-IRI@W3.ORG; www-tag@w3.org
Subject: Re: HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

Thanks for providing a Change Proposal for this issue! The chairs are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal:

1) Including the subsequently sent draft text, it seems to include  
sufficient summary, details and impact. The subject line seems like a  
fine one-sentence summary in fact.

2) There does not appear to be a rationale. Please provide a Rationale  

We suggest updating the Change Proposal to reflect the feedback in  
point (2).


On Nov 5, 2009, at 12:20 PM, Larry Masinter wrote:

> I have updated the proposed draft charter for IRI work in IETF:
> http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter
> to explicitly calls for the resulting document as being
> suitable as a normative reference from HTML, and points
> to a draft of HTML Editor Requirements at the end of
> http://trac.tools.ietf.org/area/app/trac/wiki/IriWorkGoals.
> Please review, accept, or update as necessary, the "HTML
> Editor Requirements" prior to IETF chartering of the
> working group next Tuesday Nov 10.
> Assuming the liaison and requirements are acceptable as
> part of the IETF IRI working group charter and we find
> sufficient volunteers for editing, reviewing nad chairing,
> I offer a (vague, but I think workable)
> Based on assuming
> that those requirements are met: please replace the
> definition of URL in the HTML5 specification and all
> descriptions of URL processing in the HTML5 specification
> with specific references to the [IRIBIS] document.
> I think this includes sections such as
> * Determine whether a string best matches Relative
>  or Absolute, e.g., one might say:
>  "Determine whether Absolute or Relative as per [IRIBIS]"
> * Determine whether a string is or isn't valid an IRI
>  "Determine whether valid as per [IRIBIS]"
> * Offer heuristics for interpreting a user input
>  or other unvalidated string as an IRI
>  "User agents MAY interpret invalid strings as if
>  they were valid in cases where the input is
>  not otherwise validated, as per [IRIBIS]"
> * Resolve a relative IRI against a base
> As far as timing goes:
> Whenever you have a normative specification to another
> specification which is, itself, under development,
> there is some coordination necessary, but this request
> is based on the assumption that it isn't necessary
> to wait for the IRIBIS process to complete in order
> for HTML5 to go to last call prior to its publication
> as Proposed Recommendation.
> If there is not an IETF working group to update these
> documents such that they are suitable for reference
> by the HTML working group, then an appropriate change
> proposal would be to put back in the HTML5-only
> URL parsing algorithm that was there before the
> [WEBADDRESS] specification was split out.
> Larry
> -- 
> http://larry.masinter.net
Received on Wednesday, 2 December 2009 00:00:02 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:04 UTC