Re: [iucg] IDNA, IRI, HTML5 coordination
JFC Morfin <jefsey@jefsey.com> Thu, 17 September 2009 15:25 UTC
Return-Path: <jefsey@gmail.com>
X-Original-To: iucg@core3.amsl.com
Delivered-To: iucg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87173A6965 for <iucg@core3.amsl.com>; Thu, 17 Sep 2009 08:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level:
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sambfn1e+sgi for <iucg@core3.amsl.com>; Thu, 17 Sep 2009 08:25:17 -0700 (PDT)
Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id DC9473A69CD for <iucg@ietf.org>; Thu, 17 Sep 2009 08:25:16 -0700 (PDT)
Received: by bwz6 with SMTP id 6so99156bwz.37 for <iucg@ietf.org>; Thu, 17 Sep 2009 08:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=LMQ4/bQDOPAnNsPebBWe4B76kap4Tfssygn8W4Sm/yk=; b=DdD8IoN4CxBLhDujACKwcT84pOhKbDzsajvjBGSK7MkOx2Errn01YrRkdmBhz+AVty NAxIzujCiLuUz2fqJ9fCGkp7YkJYURwUGms8qsNOTwbPJBqPgcnR1oNg9fYHklZjNU8D Fdzms4e2A5XnI6m4yyMH/OrDW1Cvt+69lCEKg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DHWe70qqHsOcLZT0xjaklSf6bZzyLuhIRSa9t9mPVx22Nblda5DB998J916ouL6mLL 9oDGGYNu53kw7IVtF8CNyvYy4zIX0nnIuupRtDVGvrzNvvNuJHCnFrtYYrVO29pq/Jqr zc7snpaQbeYf9l1F1gCGwnKm4lMAVlsEFwwKg=
MIME-Version: 1.0
Sender: jefsey@gmail.com
Received: by 10.204.153.219 with SMTP id l27mr482025bkw.141.1253201163387; Thu, 17 Sep 2009 08:26:03 -0700 (PDT)
In-Reply-To: <8B62A039C620904E92F1233570534C9B0118DBB46FA0@nambx04.corp.adobe.com>
References: <0F9C0B65969D644EA7B34DF381465F66F451C8@RY02MAIL.citc.gov.sa> <4AAE260B.7080806@it.aoyama.ac.jp> <017C69CB-CD3E-4692-82AE-6514B3D20DBA@google.com> <0F9C0B65969D644EA7B34DF381465F66F45238@RY02MAIL.citc.gov.sa> <92EF5D61-AB67-4A67-9DF5-AB208A2B5795@google.com> <8B62A039C620904E92F1233570534C9B0118DBB46FA0@nambx04.corp.adobe.com>
Date: Thu, 17 Sep 2009 17:26:03 +0200
X-Google-Sender-Auth: 925a969301b3cfc8
Message-ID: <1f9674ed0909170826r6c295a4es64f390fa5c543154@mail.gmail.com>
From: JFC Morfin <jefsey@jefsey.com>
To: Larry Masinter <masinter@adobe.com>
Content-Type: multipart/alternative; boundary="0015175cf9f62d05280473c7a24f"
Cc: public-iri@w3.org, iucg@ietf.org
Subject: Re: [iucg] IDNA, IRI, HTML5 coordination
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2009 15:25:19 -0000
Larry, please note that the IUCG (iucg@ietf.org) (Internet users contributing group) explores the Intersem (semiotic Internet), its semantic addressing system as a layer above the DNS layer and the support of Internet presentations. Our schedule is; - to see the IDNA work to get completed, so we can make sure that our additions to IDNA do not prevent us to be 100% IDNA compliant. - to document our initially intended framework. Hopefully next month, if IDNA is sent to the IESG in the coming weeks. Our intent would be the IETF/LC to know why we introduce one character option/change in IDNA so we may understand if we should present our needed solution as an IDNA extension or alternative. Best JFC Morfin IUCG Moderator http://iucg.org 2009/9/16 Larry Masinter <masinter@adobe.com> > Goal: bring together and coordinate the definitions > of what is used for resource identification in the web and elsewhere > (IRIs as the evolution of URL, URI, IRI, HREF, Web Address, etc.) > within W3C, IETF and their specifications. See "design goals" below. > > Goal of this message: lay out the concerned groups, start discussion > of process for coordination. > > I've bcc'd everyone except the public-iri@w3.org mailing list, > archive http://lists.w3.org/Archives/Public/public-iri/ as the > list proposed for discussion: > > > My suggestion for how to get all of these groups to coordinate > is to start an IETF working group with a charter to bring these > specifications into alignment. I can't think of any other process > which can accomplish the goal. > > PLEASE, PLEASE: if you're going to post an opinion, please at least > cc public-iri@w3.org and try to keep discussion there. > > PLEASE: Separate 'process' issues (should there be a working group? > Who else needs to be involved? What's the timing and when?) from > technical issues. > > Thanks, > > Larry > > ================= > (Incomplete) list of specifications, groups, chairs, editors: > > HTTP: > > [HTTPBIS-URI] HTTP URI scheme def in HTTPBIS draft: > > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2 > [HTTP-RFC<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2%0A[HTTP-RFC>] > current HTTP URI scheme definition > in RFC 2616 http://tools.ietf.org/html/rfc2616#section-3.2.2 > [HTTPBIS-WG<http://tools.ietf.org/html/rfc2616#section-3.2.2%0A[HTTPBIS-WG>] > IETF HTTPBIS working group > charter: http://tools.ietf.org/wg/httpbis/charters > http://www.ietf.org/dyn/wg/charter/httpbis-charter.html > mailing list: ietf-http-wg@w3.org, > archives http://lists.w3.org/Archives/Public/ietf-http-wg/ > chair: Mark Nottingham <mnot@mnot.net> > editors: Roy Fielding <fielding@gbiv.com>, > Julian Reschke <julian.reschke@greenbytes.de>, (others) > > IDNA: > [IDNABIS-*] definitions, policies, standards for how Internationalized > Domain Names should be handled in Internet applications > http://tools.ietf.org/html/draft-ietf-idnabis-defs/ > [IDNABIS-WG] IETF IDNABIS working group > charter: http://www.ietf.org/dyn/wg/charter/idnabis-charter.html > chair: Vint Cerf <vint@google.com> > editor: John C Klensin <klensin@jck.com> > > IRI: > [IRIBIS-6] Revision under preparation: > http://tools.ietf.org/html/draft-duerst-iri-bis-06 > [IRIBIS-LMM<http://tools.ietf.org/html/draft-duerst-iri-bis-06%0A[IRIBIS-LMM>] > ("Experimental" draft attempting to satisfy IDNABIS and HTML requirements) > http://larry.masinter.net/iribis-hack.html > ( > http://tools.ietf.org/rfcdiff?url1=draft-duerst-iri-bis.txt&url2=http://larry.masinter.net/iribis-hack.txt > ) > discussion on: public-iri@w3.org (among others) > (other)editors: Martin Dürst <duerst@it.aoyama.ac.jp> > Michel SUIGNARD <Michel@suignard.com> > > Mailto URI: > > [MAILTO-RFC] Mailto: URI scheme > Current: http://tools.ietf.org/html/rfc2368 > [MAILTO-BIS <http://tools.ietf.org/html/rfc2368%0A[MAILTO-BIS>] In > preparation > http://tools.ietf.org/html/draft-duerst-mailto-bis-06 > (other) editors (including) Martin Dürst (duerst@it.aoyama.ac.jp) > discussion on: uri@w3.org > > URI: > > [URI-RFC] URI spec > http://tools.ietf.org/html/rfc3986 > mailing list: uri@w3.org > (other) editors: Roy Fielding <fielding@gbiv.com>, Tim Berners-Lee < > timbl@w3.org> > [URIREG-RFC] > URI guidelines: policies and procedures for registering new URI > schemes > http://tools.ietf.org/html/rfc4395 > editors: Tony Hansen <tony@att.com> > mailing list for URI review: uri-review@ietf.org > > HTML5: > [HTML5-CURRENT] HTML5 definition of "URLs" > http://dev.w3.org/html5/spec/Overview.html#urls > [WEBADDRESS] Attempt to split out "Web Address" component: > http://www.w3.org/html/wg/href/draft > [HTML-WG <http://www.w3.org/html/wg/href/draft%0A[HTML-WG>] W3C Working > Group > charter: http://www.w3.org/html/wg/ > URL/IRI issue: http://www.w3.org/html/wg/tracker/issues/56 > chairs: Paul Cotton <paul.cotton@microsoft.com> > Maciej Stachowiak <mjs@apple.com> > Sam Ruby <rubys@intertwingly.net> > editor: Ian Hickson <ian@hixie.ch> > > > Other interested groups: > > IETF Applications area > mailing list: apps-discuss@ietf.org > area directors: Lisa Dusseault <lisa.dusseault@gmail.com>; > Alexey Melnikov <alexey.melnikov@isode.com> > > W3C TAG (architectural issue around URIs in W3C specs) > mailing list: www-tag@w3.org > archive http://lists.w3.org/Archives/Public/www-tag/ > issue: http://www.w3.org/2001/tag/group/track/issues/27 > chair: Noah Mendelsohn <noah_mendelsohn@us.ibm.com> > > [WHATWG] http://www.whatwg.org/ > > > (Have I missed any groups, specs? I'll update this list > and set it up somewhere) > > ============================================== > 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? > > > 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. > > 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? > > > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update >
- Re: [iucg] IDNA, IRI, HTML5 coordination JFC Morfin
- Re: [iucg] IDNA, IRI, HTML5 coordination jean-michel bernier de portzamparc
- Re: [iucg] IDNA, IRI, HTML5 coordination jefsey
- Re: [iucg] IDNA, IRI, HTML5 coordination jean-michel bernier de portzamparc
- Re: [iucg] IDNA, IRI, HTML5 coordination Marie-France Berny