Subject: Re: [iucg] IDNA, IRI, HTML5 coordination

From: JFC Morfin <[email-masked]>
Date: Thu, 17 Sep 2009 17:26:03 +0200

Larry,
please note that the IUCG ([email-masked]) (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 <[email-masked]>

> 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 [email-masked] 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 [email-masked] 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: [email-masked],
>          archives http://lists.w3.org/Archives/Public/ietf-http-wg/
>    chair:   Mark Nottingham <[email-masked]>
>    editors: Roy Fielding <[email-masked]>,
>             Julian Reschke <[email-masked]>, (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 <[email-masked]>
>      editor: John C Klensin <[email-masked]>
>
> 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: [email-masked] (among others)
>     (other)editors: Martin Dürst <[email-masked]>
>                     Michel SUIGNARD <[email-masked]>
>
> 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 ([email-masked])
>   discussion on: [email-masked]
>
> URI:
>
> [URI-RFC] URI spec
>      http://tools.ietf.org/html/rfc3986
>   mailing list: [email-masked]
>   (other) editors: Roy Fielding <[email-masked]>, Tim Berners-Lee <
> [email-masked]>
> [URIREG-RFC]
>      URI guidelines: policies and procedures for registering new URI
> schemes
>      http://tools.ietf.org/html/rfc4395
>     editors: Tony Hansen <[email-masked]>
>     mailing list for URI review: [email-masked]
>
> 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 <[email-masked]>
>             Maciej Stachowiak <[email-masked]>
>             Sam Ruby <[email-masked]>
>     editor: Ian Hickson <[email-masked]>
>
>
> Other interested groups:
>
> IETF Applications area
>      mailing list: [email-masked]
>      area directors: Lisa Dusseault <[email-masked]>;
>          Alexey Melnikov <[email-masked]>
>
> W3C TAG (architectural issue around URIs in W3C specs)
>     mailing list: [email-masked]
>     archive http://lists.w3.org/Archives/Public/www-tag/
>     issue: http://www.w3.org/2001/tag/group/track/issues/27
>     chair: Noah Mendelsohn <[email-masked]>
>
> [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
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Sat, 19 Sep 2009 01:34:07 +0200

Larry,
also what about RFIDs ?
jfc

2009/9/17 JFC Morfin <[email-masked]>

>> [IRIBIS-LMM<http://tools.ietf.org/html/draft-duerst-iri-bis-06%0A%5BIRIBIS-LMM>]
>> [MAILTO-BIS <http://tools.ietf.org/html/rfc2368%0A%5BMAILTO-BIS>] In
>> preparation
>> [HTML-WG <http://www.w3.org/html/wg/href/draft%0A%5BHTML-WG>] W3C Working
>> Group
>> 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.
>>
>> •       Updating the URI scheme registry to be clear that "URI schemes"
>> are the same as “URL schemes”
>>      and “IRI schemes”
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iucg
>
>

---

From: jefsey <[email-masked]>
Date: Sat, 19 Sep 2009 02:17:48 +0200

>jfc

Jean-Michel,
je sais pas comment fonctionne ton forward mais ton envoi de ma 
question après notre discussion sur PERFIDA va confuser Larry. On 
dirait que j'ai signé ton mail. Cela fait drôle.
jfc

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Sat, 19 Sep 2009 02:24:34 +0200

Mille excuse, il est tard. J'ai juste copié collé ta suggestion de lui
envoyer juste un petit mot.
Loin de moi l'idée de me faire passer pour ta pontifiscience :-)
Il est l'or d'aller se coucher!
Kenavo.
Portzamparc

Le 19 septembre 2009 02:17, jefsey <[email-masked]> a écrit :

> je sais pas comment fonctionne ton forward mais ton envoi de ma question
> après notre discussion sur PERFIDA va confuser Larry. On dirait que j'ai
> signé ton mail. Cela fait drôle.
> jfc
>
>

---

From: Marie-France Berny <[email-masked]>
Date: Sat, 19 Sep 2009 02:39:16 +0200

JFC,
I would also be interested to team with Jean-Michel on this. I do not know
if I will get enough time for that now we plan to operate servers. Do you
think you could get the person you thought on board. For the time being I
have no idea were we could get a budget.

I suggest we try to focus on the unbound issue, get it compiled for test,
get punyplus on it. I could try to set-up an ONS on my machine. It would be
fun to get some support for a DNSSEC ONS on a laptop.

I just thought you could involve Francis Muguet an ask for a PERFIDA class?
Or do you think we could set one up as part of the interplus intertest?

Best
Marie-France