IDNA, IRI, HTML5 coordination
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: IDNA, IRI, HTML5 coordination
by Robin Berjon-2
::
Rate this Message:
On Sep 16, 2009, at 17:43 , Larry Masinter wrote:
> (Incomplete) list of specifications, groups, chairs, editors: > (...) > (Have I missed any groups, specs? I'll update this list > and set it up somewhere) The WebApps WG is interested in the topic, as the group defining the widget: URI scheme. WebApps WG (web applications formats and APIs) mailing list: public-webapps@... archive: http://lists.w3.org/Archives/Public/public-webapps/ -- Robin Berjon - http://berjon.com/ |
|
|
RE: IDNA, IRI, HTML5 coordination
by Phillips, Addison
::
Rate this Message:
Hello Larry,
> > (Have I missed any groups, specs? I'll update this list > and set it up somewhere) W3C International Activity / W3C Internationalization Core WG We are also the maintainers of Character Model and it's part on Resource Identifiers: http://www.w3.org/TR/charmod-resid/ That would probably be a good place to document the outcome of these discussions. And, obviously, we contribute to the various documents in question. Addison Addison Phillips Globalization Architect -- Lab126 Chair -- W3C Internationalization WG Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: uri-request@... [mailto:uri-request@...] On Behalf Of > Larry Masinter > Sent: Wednesday, September 16, 2009 8:43 AM > To: PUBLIC-IRI@... > Subject: IDNA, IRI, HTML5 coordination > > 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@... 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@... 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] current HTTP URI scheme definition > in RFC 2616 http://tools.ietf.org/html/rfc2616#section-3.2.2 > [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@..., > archives http://lists.w3.org/Archives/Public/ietf-http- > wg/ > chair: Mark Nottingham <mnot@...> > editors: Roy Fielding <fielding@...>, > Julian Reschke <julian.reschke@...>, (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@...> > editor: John C Klensin <klensin@...> > > IRI: > [IRIBIS-6] Revision under preparation: > http://tools.ietf.org/html/draft-duerst-iri-bis-06 > [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@... (among others) > (other)editors: Martin Dürst <duerst@...> > Michel SUIGNARD <Michel@...> > > Mailto URI: > > [MAILTO-RFC] Mailto: URI scheme > Current: http://tools.ietf.org/html/rfc2368 > [MAILTO-BIS] In preparation > http://tools.ietf.org/html/draft-duerst-mailto-bis-06 > (other) editors (including) Martin Dürst (duerst@...) > discussion on: uri@... > > URI: > > [URI-RFC] URI spec > http://tools.ietf.org/html/rfc3986 > mailing list: uri@... > (other) editors: Roy Fielding <fielding@...>, Tim Berners- > Lee <timbl@...> > [URIREG-RFC] > URI guidelines: policies and procedures for registering new > URI schemes > http://tools.ietf.org/html/rfc4395 > editors: Tony Hansen <tony@...> > mailing list for URI review: uri-review@... > > 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] 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@...> > Maciej Stachowiak <mjs@...> > Sam Ruby <rubys@...> > editor: Ian Hickson <ian@...> > > > Other interested groups: > > IETF Applications area > mailing list: apps-discuss@... > area directors: Lisa Dusseault <lisa.dusseault@...>; > Alexey Melnikov <alexey.melnikov@...> > > W3C TAG (architectural issue around URIs in W3C specs) > mailing list: www-tag@... > 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@...> > > [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? > > > |
|
|
Re: IDNA, IRI, HTML5 coordination
by Maciej Stachowiak
::
Rate this Message:
On Sep 16, 2009, at 8:43 AM, Larry Masinter wrote: > 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@... 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@... 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. I have some process questions: 1) What kind of timeline are we talking about? 2) Do we expect that HTML5 to depend on the ultimate product of this working group, or will some earlier spec (such as an updated IRIbis draft) meet its needs? I ask because resource identifiers are currently a blocking issue for the HTML Working Group. We would like to take HTML5 to Last Call soon (within the next quarter or two), but we do not have a suitable reference to use for processing of resource identifiers. HTML5 currently references the Web Address specification, which is not being updated or progressed along the standards track. IRIbis currently does not define many of the lenient processing algorithms needed by HTML5. Thus we are in a bind. If the new specification (which sounds like a great idea) is not ready soon, what should HTML5 use as an interim solution? I can imagine a few possibilities: (a) move Web Address forward in the W3C or the IETF, with the expectation that it will be obsoleted in due course by the grand unified resource identifier spec; (b) put interim definitions in the HTML5 spec itself until the new spec is ready; (c) update the IRIbis draft ASAP so HTML5 can reference it, while waiting for the new Working Group to be formed and the new spec to be written. Can anyone give guidance from an IETF perspective? Would it be problematic to pursue an interim solution? Regards, Maciej |
|
|
Re: IDNA, IRI, HTML5 coordination
by Maciej Stachowiak
::
Rate this Message:
Here's a few technical comments. On Sep 16, 2009, at 8:43 AM, Larry Masinter wrote: > > ============================================== > 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? Overall, your design goals sound great to me, and I think a unified and cleaned up spec for resource identifiers would be of great value. > > > 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. I largely agree with this point. But I think the rules for lenient processing should be a normative but optional mode, rather than merely implementation advice. Referencing specifications should specify whether particular contexts require strict processing or lenient processing (or allow either). The reason is that advice is not strong enough - anyone doing lenient processing should do it in the exact same way, or we will have interoperability failures. I believe this ties into your "Uniform behavior" design go. > > 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? > > > > |
|
|
|
|
|
Re: IDNA, IRI, HTML5 coordination
by JFC Morfin
::
Rate this Message:
Larry,
please note that the IUCG (iucg@...) (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@...> Goal: bring together and coordinate the definitions |
|
|
Re: IDNA, IRI, HTML5 coordination
by "Martin J. Dürst"
::
Rate this Message:
Hello Maciej,
I think you raise one of the most crucial points when you talk about dependency and timing for HTML5 below. We have had a lot of interim solutions in the IRI space, and they often leave some scars. (As an example, the fact that XML allows spaces and a few other characters not allowed in IRIs, and we therefore went ahead and defined LEIRIs in the current draft is a scar resulting from the XML specs basing their work on earlier drafts of the IRI spec.) Another danger of an interim solution is that often, the relevant and concerned parties are only interested in one specific aspect of the spec, and once they feel that part has settled down, they don't follow the rest of the work. In many ways, this is natural, but on the other hand, and with the way the IETF works in particular, changes are always possible, for various reasons (e.g. the WG is fine on a point, but overall, the IETF feels different, or there are details in one part of the spec that affect another part of the spec, and so on). So anybody who wants to use an interim solution be very well advised to follow the further progess of the spec and cry out loud if a further change down the road creates problems for them. (and even then, there's not really a guarantee the change won't happen) So it would definitely be great if we could avoid interim solutions. On the other hand, we also would of course like not to delay other specs. As for HTML5, I have heard repeatedly about projections for last call similar to the ones you give below. But what's the timeline after that? If that's another last call in six months, and CR in a year, then it may be possible for the IRI side to catch up. (Last Call in the IETF is 2 weeks for WGs, 4 weeks for documents that didn't go through a WG.) Just a thought, no idea at all whether it makes any sense. In my view, the ideal outcome would be that Larry and Michel and me have a draft that works for everybody involved by the Hiroshima IETF, we have a BOF there, and we decide that the work is already done and everybody is happy so no WG is needed. There is still some time until the Hiroshima IETF, and Larry and me have reserved some time to work together in early October, so there is at least a slight chance that this might work out, but on the other hand, there are a few points on which Larry and me currently have very differing opinions, to the extent that I'm not sure we could even write a reasonable charter for a potential IETF WG. I very much hope that this will change. For more details, please see the technical thread. Regards, Martin. On 2009/09/17 21:35, Maciej Stachowiak wrote: > > On Sep 16, 2009, at 8:43 AM, Larry Masinter wrote: > >> 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@... 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@... 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. > > I have some process questions: > > 1) What kind of timeline are we talking about? > 2) Do we expect that HTML5 to depend on the ultimate product of this > working group, or will some earlier spec (such as an updated IRIbis > draft) meet its needs? > > I ask because resource identifiers are currently a blocking issue for > the HTML Working Group. We would like to take HTML5 to Last Call soon > (within the next quarter or two), but we do not have a suitable > reference to use for processing of resource identifiers. HTML5 currently > references the Web Address specification, which is not being updated or > progressed along the standards track. IRIbis currently does not define > many of the lenient processing algorithms needed by HTML5. Thus we are > in a bind. If the new specification (which sounds like a great idea) is > not ready soon, what should HTML5 use as an interim solution? > > I can imagine a few possibilities: (a) move Web Address forward in the > W3C or the IETF, with the expectation that it will be obsoleted in due > course by the grand unified resource identifier spec; (b) put interim > definitions in the HTML5 spec itself until the new spec is ready; (c) > update the IRIbis draft ASAP so HTML5 can reference it, while waiting > for the new Working Group to be formed and the new spec to be written. > > Can anyone give guidance from an IETF perspective? Would it be > problematic to pursue an interim solution? > > Regards, > Maciej > > > > > > > > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@... |
|
|
Re: IDNA, IRI, HTML5 coordination
by "Martin J. Dürst"
::
Rate this Message:
Hello Graham, Larry,
On 2009/09/18 0:19, Larry Masinter wrote: >> Is this one to consider?: >> http://www.w3.org/TR/uri-clarification/ > > This W3C note (dated 2001) predates RFC 3986 > (dated 2005), so on the face of it, it shouldn't > be necessary. The primary concern should be > conflicting advice and specifications from > *current* and *in preparation* documents. I very much agree with Larry here. The above document mainly was used to clarify issues re. URN terminology (URN as a general term for 'names' vs. URN as in "urn:" scheme), and to help people understand that in a digital network, the distinction between "names" and "locations" is much less important (if not irrelevant) than in a traditional (hardware) library, where the fact that two copies of the same book ("name") can be in two different locations is crucial. >> Also, what is the specific problem, or pain, >> that this initiative will address? > > While having documents in conflict with widely > deployed implementations is a general pain > which we should work to correct, Yes, trying to bring things together so that people don't have to check a lot of different specs, trying to document existing widely-deployed implementations, and making sure the quirks of these implementations are not seen as creating a whole class of new identifiers, but only as "accepting slightly more than necessary" are in my view the main goals. > specifically > > http://dev.w3.org/html5/spec/Overview.html#urls > > contains: > >> NOTE: The term "URL" in this specification is used >> in a manner distinct from the precise technical >> meaning it is given in RFC 3986. Readers familiar >> with that RFC will find it easier to read this >> specification if they pretend the term "URL" as >> used herein is really called something else >> altogether. This is a willful violation of >> RFC 3986. [RFC3986] > > which (as a co-editor of RFC 3986, a member of the W3C > HTML-WG and a member of the W3C Technical Architecture > Group) gives me a specific pain. I'm trying to > complete the action items I took on in W3C HTML-WG > and W3C TAG to help resolve issues raised around > incompatible specifications. The "willful violation" in particular is somewhat repulsing. While it may have been well-intended ("watch out, we use this term differently"), it reads more like "we wanted to create havoc, and we did". That's not the way to write specs, in my view. The XML specs at one point used "Human Readable Resource Identifier" for what's now called "Legacy Extended Internationalized Resource Identifier". Maybe we can help HTML5 to move in a similar direction. But I don't think terminology issues should be on the critical path; more like: If we can solve these on the go, we'll do so. Regards, Martin. > Whether or not this initiative completes in > time to get the HTML text updated before the > W3C HTML working group decides to declare > "last call", the fact that the IETF documents > are, in fact, not suitable for direct citation > by those wishing to describe deployed > browser behavior seems like something the > IETF can correct. > > Larry > -- > http://larry.masinter.net > > > -----Original Message----- > From: Graham Klyne [mailto:graham.klyne@...] > Sent: Thursday, September 17, 2009 3:02 AM > To: Larry Masinter > Subject: Re: IDNA, IRI, HTML5 coordination > > Larry, > > Is this one to consider?: > http://www.w3.org/TR/uri-clarification/ > > Also, what is the specific problem, or pain, that this initiative will address? > > #g > -- -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@... |
|
|
Re: IDNA, IRI, HTML5 coordination
by Erik van der Poel
::
Rate this Message:
>> While having documents in conflict with widely
>> deployed implementations is a general pain >> which we should work to correct, > > Yes, trying to bring things together so that people don't have to check a > lot of different specs, trying to document existing widely-deployed > implementations, and making sure the quirks of these implementations are not > seen as creating a whole class of new identifiers, but only as "accepting > slightly more than necessary" are in my view the main goals. We must document not only what the consumers accept, but also what they do with that input, i.e. how the input is transformed into the output, and whether the output is normal or an error. It is important to document the current behavior of the implementations and to highlight the differences. Hopefully, some implementers will align their implementations with others. Where the implementations don't align, the documented differences serve as warnings to producers. (E.g. escaped UTF-8 host names are treated so differently by the browsers that producers would be wise to avoid them for now.) Of course, there are chicken and egg problems here. MSIE will display IDNs under .com in their Unicode form, but Firefox refuses to do so. As long as this major difference persists, registrants will probably refrain from registering and using IDNs under .com. If the registrants would use them more, MSIE, Firefox and Verisign might try to work towards a resolution. But registrants may not want to use IDNs under .com until MSIE, Firefox and Verisign have ironed out their differences. To put it differently, one of the goals is human-to-human communication, not mere machine-to-machine communication. If an IDN is not displayed legibly, we have not met that goal. If the IETF does not want to deal with UI, humans, display, etc, we must address this elsewhere, e.g. W3C. Erik |
|
|
Re: IDNA, IRI, HTML5 coordination
by Maciej Stachowiak
::
Rate this Message:
On Sep 18, 2009, at 2:48 AM, Martin J. Dürst wrote: > > As for HTML5, I have heard repeatedly about projections for last > call similar to the ones you give below. But what's the timeline > after that? If that's another last call in six months, and CR in a > year, then it may be possible for the IRI side to catch up. (Last > Call in the IETF is 2 weeks for WGs, 4 weeks for documents that > didn't go through a WG.) Just a thought, no idea at all whether it > makes any sense. My expectation is that we will not enter CR until at ;east a year after the start of our first Last Call. Due to the size, scope and impact of the spec, I expect we will need an unusually long Last Call period, and that we will receive a large number of comments which will take some time to address. And I expect the changes made based on comments to require a second Last Call. So this means that even if we use an interim solution for our first Last Call, IRI will have time to catch up and we will be able to update the reference before CR. > > In my view, the ideal outcome would be that Larry and Michel and me > have a draft that works for everybody involved by the Hiroshima > IETF, we have a BOF there, and we decide that the work is already > done and everybody is happy so no WG is needed. > > There is still some time until the Hiroshima IETF, and Larry and me > have reserved some time to work together in early October, so there > is at least a slight chance that this might work out, but on the > other hand, there are a few points on which Larry and me currently > have very differing opinions, to the extent that I'm not sure we > could even write a reasonable charter for a potential IETF WG. I > very much hope that this will change. For more details, please see > the technical thread. The Hiroshima IETF Meeting is November 8-13, right? This might be too late for our first Last Call, it will either be after we enter LC or at the very last minute. Thus, I'm still concerned about what we should do while waiting for the updated IRI specification. Regards, Maciej |
|
|
Re: IDNA, IRI, HTML5 coordination
by Maciej Stachowiak
::
Rate this Message:
On Sep 18, 2009, at 3:03 AM, Martin J. Dürst wrote: > > The "willful violation" in particular is somewhat repulsing. While > it may have been well-intended ("watch out, we use this term > differently"), it reads more like "we wanted to create havoc, and we > did". That's not the way to write specs, in my view. Do you think it would be helpful (or accurate) to label divergent use of the term "URL" as something other than "willful violation"? > > The XML specs at one point used "Human Readable Resource Identifier" > for what's now called "Legacy Extended Internationalized Resource > Identifier". Maybe we can help HTML5 to move in a similar direction. > But I don't think terminology issues should be on the critical path; > more like: If we can solve these on the go, we'll do so. There is considerable distaste for the alphabet soup of different terms for resource identifiers (URL, URN, URI, IRI, XRI, LEIRI...) and a great reluctance to introduce yet another term for what most people still colloquially call a "URL". If there was a great naming suggestion, I'm sure it would be considered, but I don't think "HRRI" would fly. This may be easier to resolve once there is a suitable IETF spec for HTML5 to reference. Regards, Maciej |
|
|
Re: [iucg] IDNA, IRI, HTML5 coordination
by jean-michel bernier de portzamparc
::
Rate this Message:
Larry,
also what about RFIDs ? jfc 2009/9/17 JFC Morfin <jefsey@...> Larry, |
| Free embeddable forum powered by Nabble | Forum Help |
