[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Groups - xri-requirements-1.0-draft-05b.doc uploaded
The issue I see is that if the regular expressions are truly stored in NAPTR records, there is simply no way that non-ascii (or whatever the legal DNS RR character set is) can be used. Can the Regex's match Unicode strings if the unicode strings are encoded a la UTF-8 (e.g. with a %-escaping)? Thanks for digging into this Peter.. -Gabe > -----Original Message----- > From: Peter C Davis [mailto:peter.davis@neustar.biz] > Sent: Tuesday, May 20, 2003 2:37 PM > To: Dave McAlpin > Cc: 'Sakimura, Nat'; xri@lists.oasis-open.org > Subject: Re: [xri] Groups - > xri-requirements-1.0-draft-05b.doc uploaded > > > That is a very good question dave, for which i presently do > not have an > answer. to my knowledge, POSIX re is expressed 8bit, so this > may pose > an issue. generally, however, the princiapls of DDS can still apply > (but may not conform to RFC3401-5. I'll take an action item > to dig into > this deeper. > > As for Nat's note.. I completely agree, we should focus our > attentions > on IRI (presuming it's tractable). The IRI vs. URI fight is in fact > mostly an interop argument. something XRI will not face (if > we choose > to follow the propoer RFC's). > > --- peterd > > > Dave McAlpin wrote: > > >Peter, can you comment on the applicability of DDDS based > resolution to > >IRIs? Can POSIX-based regular expressions deal with > identifiers expressed in > >Unicode? > > > >Dave > > > >-----Original Message----- > >From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] > >Sent: Tuesday, May 20, 2003 12:06 AM > >To: xri@lists.oasis-open.org > >Subject: RE: [xri] Groups - > xri-requirements-1.0-draft-05b.doc uploaded > > > >Gabe, > > > >Conceptually, IRI has larger set than URI (IRI includes > URI), but both > >are countable and thus can be mapped one to one, I think. > Could you give > >me an example of mapping one URI to multiple IRIs please? > > > >Fundamentally, the question for us probably is "do we really > want to be > >bound by this aging URI standard?" To me, URI v.s. IRI controversy is > >largely due to the backward compatibility issues. If we > think afresh, we > >probably do not choose URI to be the normative format > because it is the > >source of milliard of problems for I18N. Unicode is not perfect (some > >purists say that it is useless - it generally cannot > distinguish among > >similar but distinct characters because these are collapsed > into one), > >but is much cleaner. Resolution does not have to go through the > >transformation to URI. Our internationalized identifier > should be able > >to be resolved directly. > > > >On equivalence: I think URI equivalence arguments do not > affect us. This > >is because we have abstract permanent identifier, which can be pretty > >restrictive in the allowed character set as we do not need the human > >readability. To test the equivalence of two identifiers, we should > >resolve to the permanent identifier and compare them. To protect the > >privacy, we might not want to expose the permanent > identifier. In this > >case, the proxy should give out True/False result. We have a much > >powerful tool than URIs in this regard. > > > >Nat > > > >-----Original Message----- > >From: Wachob, Gabe [mailto:gwachob@visa.com] > >Sent: Friday, May 16, 2003 4:25 AM > >To: 'Drummond Reed'; xri@lists.oasis-open.org > >Subject: RE: [xri] Groups - > xri-requirements-1.0-draft-05b.doc uploaded > > > >Drummond- > > A few notes. > > > > First, in section 3.4.5 (you said 3.3.5) - "non-resolvable > >syntax" - whats the use case? Why do we need to *prevent* an > attempt to > >resolve? Why would a software component resolve an > identifier unless it > >needed to? It seems like there are only two cases: a piece > of software > >needs to resolve the identifier, or it doesn't. This > decision is based > >on application semantics, not the syntax of the identifier. How does > >marking an identifier as "non-resolvable" help at all? > > > > In section 3.4.6 (internationalization) - there is a discussiong > >going on at the W3C TAG (issue named something like "IRIEverywhere") > >where the appropriateness of where IRIs should be used is being > >discussed. It is clear, for example, that IRIs cannot be > used everywhere > >URIs can be used. The issue is whether *future* specs should refer to > >IRIs or URIs. An IRI can be "cast down" into a URI unambiguously, but > >because there are several ways to translate unicode into > ascii, its not > >always possible to unambigously convert an URI back into an > IRI (without > >some context like the encoding used to go from IRI to URI). > So, while I > >think we should definitely address IRIs and XRIs, I don't think XRIs > >should expect to be solving the problems that IRIs have with the > >relationshipt to URIs. We *could* propose a way to encode the things > >that are needed to unambiguously convert a URI back into an > IRI, but I'm > >guessing that would actually break the IRI spec. I'm going > out beyond my > >competency ! > > here I think. > > Bottom line is that we either have to wait for the IRI things to > >shake out, or we have to tread new ground in i18n. I > *definitely* want > >XRIs to be "i18n enabled", but I'm a little worried about us > planning on > >achieving that in the short term by relying on IRIs. > > > > This document has come a LONG way and I think does a pretty good > >job of identifying why we are all here. Congrats and thanks > to all those > >who contributed. I'm sure there will be more input and fixes > to the doc, > >but I feel like we're very close to the "good enough" state > where we can > >then concentrate on the syntax and resolution specs. > > > > -Gabe > > > > > > > > > >>-----Original Message----- > >>From: Drummond Reed [mailto:drummond.reed@onename.com] > >>Sent: Thursday, May 15, 2003 11:45 AM > >>To: xri@lists.oasis-open.org > >>Subject: RE: [xri] Groups - > >>xri-requirements-1.0-draft-05b.doc uploaded > >> > >> > >>First, let me note two reasons for posting v5b: > >> > >>1) I found out from Marc Le Maitre this morning that leaving "Track > >>Changes" on screwed up the section numbering, so it makes > it difficult > >>to talk about requirement numbers. Let's use v5b on the call today. > >> > >>2) There was an MS Word cross-reference error (unfortunately not all > >>that uncommon) in 3.4.7 that needed fixing. > >> > >>Please make any edits to this clean version after making sure "Track > >>Changes" is turned on. > >> > >>I will review the key updates on the TC call this afternoon, but the > >>major areas to review are: > >> > >>* Sections 2.1 - 2.3 of the Motivations section. These were > rewritten > >>for the third time to reflect the consensus regarding terminology. > >> > >>* Requirement 3.1.2 was rewritten to reflect the URN > conformance topic > >>as discussed on the list. > >> > >>* The original requirements section 3.3 was broken into the > >>new sections > >>3.3 and 3.4 to reflect the clarifications in 2.2 and 2.3 about > >>persistence and HFIs/MFIs. > >> > >>* 3.3.5 (Non-Resolvable Syntax) was added to reflect a > >>requirement Marc > >>Le Maitre has surfaced from the Namespace committee of the > >>U.S. XML.gov > >>working group. > >> > >>* 3.4.6 (Internationalization) was edited to reflect Nat's input > >>regarding IRIs. We should discuss this on today's call. > >> > >>* The Glossary was updated and all TO DO's in it were finished. > >> > >>The only remaining TO DOs are a few entries in the > >>informative glossary > >>and Appendix A (Acknowledgments). > >> > >>Talk to everyone at 3pm PDT. > >> > >>=Drummond > >> > >>-----Original Message----- > >>From: Drummond Reed > >>Sent: Thursday, May 15, 2003 11:13 AM > >>To: xri@lists.oasis-open.org > >>Subject: [xri] Groups - xri-requirements-1.0-draft-05b.doc uploaded > >> > >>The document xri-requirements-1.0-draft-05b.doc has been > submitted by > >>Drummond Reed (drummond.reed@onename.com) to the Extensible Resource > >>Identifier TC document repository. > >> > >>Document Description: > >>v5b of XRI Requirements and Glossary - This is a CLEAN > version with a > >>faulty MS Word cross-reference fixed. Please submit any edits > >>using this > >>version. > >> > >>Download Document: > >>http://www.oasis-open.org/apps/org/workgroup/xri/download.php/ > >>2050/xri-r > >>equirements-1.0-draft-05b.doc > >> > >>View Document Details: > >>http://www.oasis-open.org/apps/org/workgroup/xri/document.php? > >>document_i > >>d=2050 > >> > >> > >>PLEASE NOTE: If the above links do not work for you, your email > >>application > >>may be breaking the link into two pieces. You may be able > to copy and > >>paste > >>the entire link address into the address field of your web browser. > >> > >>-OASIS Open Administration > >> > >> > >> > > > >You may leave a Technical Committee at any time by visiting > >http://www.oasis-open.org/apps/org/workgroup/xri/members/leav e_workgroup.php > > > > > >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php > > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]