Hi,<br><br>I just thought that we want to keep our eyes on what&#39;s being done on these fronts and give feedback if necessary. <br><br>Jungshik<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Larry Masinter</b> <span dir="ltr">&lt;<a href="mailto:masinter@adobe.com">masinter@adobe.com</a>&gt;</span><br>
Date: 2009/9/16<br>Subject: IDNA, IRI, HTML5 coordination<br>To: &quot;<a href="mailto:PUBLIC-IRI@W3.ORG">PUBLIC-IRI@W3.ORG</a>&quot; &lt;<a href="mailto:PUBLIC-IRI@w3.org">PUBLIC-IRI@w3.org</a>&gt;<br><br><br>Goal: bring together and coordinate the definitions<br>

of what is used for resource identification in the web and elsewhere<br>
(IRIs as the evolution of URL, URI, IRI, HREF, Web Address, etc.)<br>
within W3C, IETF and their specifications. See &quot;design goals&quot; below.<br>
<br>
Goal of this message: lay out the concerned groups, start discussion<br>
of process for coordination.<br>
<br>
I&#39;ve bcc&#39;d everyone except the <a href="mailto:public-iri@w3.org">public-iri@w3.org</a> mailing list,<br>
archive <a href="http://lists.w3.org/Archives/Public/public-iri/" target="_blank">http://lists.w3.org/Archives/Public/public-iri/</a> as the<br>
list proposed for discussion:<br>
<br>
<br>
My suggestion for how to get all of these groups to coordinate<br>
is to start an IETF working group with a charter to bring these<br>
specifications into alignment. I can&#39;t think of any other process<br>
which can accomplish the goal.<br>
<br>
PLEASE, PLEASE: if you&#39;re going to post an opinion, please at least<br>
cc <a href="mailto:public-iri@w3.org">public-iri@w3.org</a> and try to keep discussion there.<br>
<br>
PLEASE: Separate &#39;process&#39; issues (should there be a working group?<br>
Who else needs to be involved? What&#39;s the timing and when?) from<br>
technical issues.<br>
<br>
Thanks,<br>
<br>
Larry<br>
<br>
=================<br>
(Incomplete) list of specifications, groups, chairs, editors:<br>
<br>
HTTP:<br>
<br>
[HTTPBIS-URI] HTTP URI scheme def in HTTPBIS draft:<br>
      <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2%0A[HTTP-RFC" target="_blank">http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2<br>
[HTTP-RFC</a>] current HTTP URI scheme definition<br>
      in RFC 2616 <a href="http://tools.ietf.org/html/rfc2616#section-3.2.2%0A[HTTPBIS-WG" target="_blank">http://tools.ietf.org/html/rfc2616#section-3.2.2<br>
[HTTPBIS-WG</a>] IETF HTTPBIS working group<br>
    charter: <a href="http://tools.ietf.org/wg/httpbis/charters" target="_blank">http://tools.ietf.org/wg/httpbis/charters</a><br>
             <a href="http://www.ietf.org/dyn/wg/charter/httpbis-charter.html" target="_blank">http://www.ietf.org/dyn/wg/charter/httpbis-charter.html</a><br>
    mailing list: <a href="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</a>,<br>
          archives <a href="http://lists.w3.org/Archives/Public/ietf-http-wg/" target="_blank">http://lists.w3.org/Archives/Public/ietf-http-wg/</a><br>
    chair:   Mark Nottingham &lt;<a href="mailto:mnot@mnot.net">mnot@mnot.net</a>&gt;<br>
    editors: Roy Fielding &lt;<a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a>&gt;,<br>
             Julian Reschke &lt;<a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a>&gt;, (others)<br>
<br>
IDNA:<br>
[IDNABIS-*] definitions, policies, standards for how Internationalized<br>
      Domain Names should be handled in Internet applications<br>
      <a href="http://tools.ietf.org/html/draft-ietf-idnabis-defs/" target="_blank">http://tools.ietf.org/html/draft-ietf-idnabis-defs/</a><br>
[IDNABIS-WG]  IETF IDNABIS working group<br>
      charter: <a href="http://www.ietf.org/dyn/wg/charter/idnabis-charter.html" target="_blank">http://www.ietf.org/dyn/wg/charter/idnabis-charter.html</a><br>
      chair: Vint Cerf &lt;<a href="mailto:vint@google.com">vint@google.com</a>&gt;<br>
      editor: John C Klensin &lt;<a href="mailto:klensin@jck.com">klensin@jck.com</a>&gt;<br>
<br>
IRI:<br>
[IRIBIS-6] Revision under preparation:<br>
      <a href="http://tools.ietf.org/html/draft-duerst-iri-bis-06%0A[IRIBIS-LMM" target="_blank">http://tools.ietf.org/html/draft-duerst-iri-bis-06<br>
[IRIBIS-LMM</a>] (&quot;Experimental&quot; draft attempting to satisfy IDNABIS and HTML requirements)<br>
      <a href="http://larry.masinter.net/iribis-hack.html" target="_blank">http://larry.masinter.net/iribis-hack.html</a><br>
      (<a href="http://tools.ietf.org/rfcdiff?url1=draft-duerst-iri-bis.txt&amp;url2=http://larry.masinter.net/iribis-hack.txt" target="_blank">http://tools.ietf.org/rfcdiff?url1=draft-duerst-iri-bis.txt&amp;url2=http://larry.masinter.net/iribis-hack.txt</a>)<br>

     discussion on: <a href="mailto:public-iri@w3.org">public-iri@w3.org</a> (among others)<br>
     (other)editors: Martin Dürst &lt;<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>&gt;<br>
                     Michel SUIGNARD &lt;<a href="mailto:Michel@suignard.com">Michel@suignard.com</a>&gt;<br>
<br>
Mailto URI:<br>
<br>
[MAILTO-RFC] Mailto: URI scheme<br>
      Current: <a href="http://tools.ietf.org/html/rfc2368%0A[MAILTO-BIS" target="_blank">http://tools.ietf.org/html/rfc2368<br>
[MAILTO-BIS</a>] In preparation<br>
     <a href="http://tools.ietf.org/html/draft-duerst-mailto-bis-06" target="_blank">http://tools.ietf.org/html/draft-duerst-mailto-bis-06</a><br>
   (other) editors (including) Martin Dürst (<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>)<br>
   discussion on: <a href="mailto:uri@w3.org">uri@w3.org</a><br>
<br>
URI:<br>
<br>
[URI-RFC] URI spec<br>
      <a href="http://tools.ietf.org/html/rfc3986" target="_blank">http://tools.ietf.org/html/rfc3986</a><br>
   mailing list: <a href="mailto:uri@w3.org">uri@w3.org</a><br>
   (other) editors: Roy Fielding &lt;<a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a>&gt;, Tim Berners-Lee &lt;<a href="mailto:timbl@w3.org">timbl@w3.org</a>&gt;<br>
[URIREG-RFC]<br>
      URI guidelines: policies and procedures for registering new URI schemes<br>
      <a href="http://tools.ietf.org/html/rfc4395" target="_blank">http://tools.ietf.org/html/rfc4395</a><br>
     editors: Tony Hansen &lt;<a href="mailto:tony@att.com">tony@att.com</a>&gt;<br>
     mailing list for URI review: <a href="mailto:uri-review@ietf.org">uri-review@ietf.org</a><br>
<br>
HTML5:<br>
[HTML5-CURRENT]   HTML5 definition of &quot;URLs&quot;<br>
     <a href="http://dev.w3.org/html5/spec/Overview.html#urls" target="_blank">http://dev.w3.org/html5/spec/Overview.html#urls</a><br>
[WEBADDRESS] Attempt to split out &quot;Web Address&quot; component:<br>
     <a href="http://www.w3.org/html/wg/href/draft%0A[HTML-WG" target="_blank">http://www.w3.org/html/wg/href/draft<br>
[HTML-WG</a>] W3C Working Group<br>
     charter: <a href="http://www.w3.org/html/wg/" target="_blank">http://www.w3.org/html/wg/</a><br>
     URL/IRI issue: <a href="http://www.w3.org/html/wg/tracker/issues/56" target="_blank">http://www.w3.org/html/wg/tracker/issues/56</a><br>
     chairs: Paul Cotton &lt;<a href="mailto:paul.cotton@microsoft.com">paul.cotton@microsoft.com</a>&gt;<br>
             Maciej Stachowiak &lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;<br>
             Sam Ruby &lt;<a href="mailto:rubys@intertwingly.net">rubys@intertwingly.net</a>&gt;<br>
     editor: Ian Hickson &lt;<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>&gt;<br>
<br>
<br>
Other interested groups:<br>
<br>
IETF Applications area<br>
      mailing list: <a href="mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
      area directors: Lisa Dusseault &lt;<a href="mailto:lisa.dusseault@gmail.com">lisa.dusseault@gmail.com</a>&gt;;<br>
          Alexey Melnikov &lt;<a href="mailto:alexey.melnikov@isode.com">alexey.melnikov@isode.com</a>&gt;<br>
<br>
W3C TAG (architectural issue around URIs in W3C specs)<br>
     mailing list: <a href="mailto:www-tag@w3.org">www-tag@w3.org</a><br>
     archive <a href="http://lists.w3.org/Archives/Public/www-tag/" target="_blank">http://lists.w3.org/Archives/Public/www-tag/</a><br>
     issue: <a href="http://www.w3.org/2001/tag/group/track/issues/27" target="_blank">http://www.w3.org/2001/tag/group/track/issues/27</a><br>
     chair: Noah Mendelsohn &lt;<a href="mailto:noah_mendelsohn@us.ibm.com">noah_mendelsohn@us.ibm.com</a>&gt;<br>
<br>
[WHATWG]  <a href="http://www.whatwg.org/" target="_blank">http://www.whatwg.org/</a><br>
<br>
<br>
(Have I missed any groups, specs? I&#39;ll update this list<br>
and set it up somewhere)<br>
<br>
==============================================<br>
Some design goals:<br>
<br>
I’ve tried to write down some of the design goals which I think are important; these may be in conflict, but I&#39;ve tried to propose priorities which make sense to me. Does anyone disagree with any of these? Think some are missing?<br>

<br>
<br>
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.<br>
<br>
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.<br>

<br>
Uniform behavior: Optional interpretation rules for resource identifiers which give different results depending on the processing model chosen are to be avoided.<br>
<br>
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.<br>

<br>
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.<br>

<br>
Improve interoperability: When existing implementations disagree, document existing practice, but recommend (normatively) the behavior that will best lead to improved interoperability.<br>
<br>
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.<br>

<br>
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”).<br>

<br>
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.<br>

<br>
============================<br>
<br>
Some issues (I&#39;m sure there are many more)<br>
<br>
•       Can IRI -&gt; URI transformation be scheme independent? ((optional processing would allow<br>
      non-uniform behavior, not meet IDNA requirements))<br>
•       Use of term “URL”  ((ambiguous terms))<br>
•       handling of extra processing rules for XML vs HTML5 vs. IRI document<br>
•       Whether HTML5 references anything other than IRIbis<br>
•       Updating the URI scheme registry to be clear that &quot;URI schemes&quot; are the same as “URL schemes”<br>
      and “IRI schemes”<br>
•       Can different URI schemes allow different I18N processing rules?<br>
<br>
<br>
<br>
<br>
</div><br>