Re: [iucg] IDNA, IRI, HTML5 coordination

[jean-michel bernier de portzamparc <[e-mail]>]

Larry,
also what about RFIDs ?
jfc


2009/9/17 JFC Morfin <[e-mail]>

> Larry,
> please note that the IUCG ([e-mail]) (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 <[e-mail]>
>
> 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 [e-mail] 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 [e-mail] 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: [e-mail],
>>          archives http://lists.w3.org/Archives/Public/ietf-http-wg/
>>    chair:   Mark Nottingham <[e-mail]>
>>    editors: Roy Fielding <[e-mail]>,
>>             Julian Reschke <[e-mail]>, (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 <[e-mail]>
>>      editor: John C Klensin <[e-mail]>
>>
>> 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%5BIRIBIS-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: [e-mail] (among others)
>>     (other)editors: Martin Dürst <[e-mail]>
>>                     Michel SUIGNARD <[e-mail]>
>>
>> Mailto URI:
>>
>> [MAILTO-RFC] Mailto: URI scheme
>>      Current: http://tools.ietf.org/html/rfc2368
>> [MAILTO-BIS <http://tools.ietf.org/html/rfc2368%0A%5BMAILTO-BIS>] In
>> preparation
>>     http://tools.ietf.org/html/draft-duerst-mailto-bis-06
>>   (other) editors (including) Martin Dürst ([e-mail])
>>   discussion on: [e-mail]
>>
>> URI:
>>
>> [URI-RFC] URI spec
>>      http://tools.ietf.org/html/rfc3986
>>   mailing list: [e-mail]
>>   (other) editors: Roy Fielding <[e-mail]>, Tim Berners-Lee <
>> [e-mail]>
>> [URIREG-RFC]
>>      URI guidelines: policies and procedures for registering new URI
>> schemes
>>      http://tools.ietf.org/html/rfc4395
>>     editors: Tony Hansen <[e-mail]>
>>     mailing list for URI review: [e-mail]
>>
>> 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%5BHTML-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 <[e-mail]>
>>             Maciej Stachowiak <[e-mail]>
>>             Sam Ruby <[e-mail]>
>>     editor: Ian Hickson <[e-mail]>
>>
>>
>> Other interested groups:
>>
>> IETF Applications area
>>      mailing list: [e-mail]
>>      area directors: Lisa Dusseault <[e-mail]>;
>>          Alexey Melnikov <[e-mail]>
>>
>> W3C TAG (architectural issue around URIs in W3C specs)
>>     mailing list: [e-mail]
>>     archive http://lists.w3.org/Archives/Public/www-tag/
>>     issue: http://www.w3.org/2001/tag/group/track/issues/27
>>     chair: Noah Mendelsohn <[e-mail]>
>>
>> [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
>> [e-mail]
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>
>
> _______________________________________________
> iucg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iucg
>
>