OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] URI/IRI/XRI - what should extend what?



Awesome utility, Gabe!

-----Original Message-----
From: Gabe Wachob [mailto:gabe.wachob@amsoft.net] 
Sent: Tuesday, November 28, 2006 8:12 PM
To: 'Schleiff, Marty'; xri@lists.oasis-open.org
Subject: RE: [xri] URI/IRI/XRI - what should extend what?

Something legal in XRI normal form would be
xri://=foo*(http://www.example.com) 

This would be escaped (and boy this escaping is easy to screw up without the
spec in front of you):

xri://=foo*%28http%3A%2F%2Fwww.example.com%29

That’s a XRI in URI normal form. It’s a URI. 

Note that we've done nothing with IRI here. 

If we had non-ascii characters, say:

xri://=andré

I believe this is also a legal IRI.

Then it would become (and here's me doing UTF-8 encoding by hand) a URI:

xri://=andr%C3%A9

(I used http://people.w3.org/rishida/scripts/uniview/conversion.php )

   -Gabe

> -----Original Message-----
> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> Sent: Tuesday, November 28, 2006 7:03 PM
> To: Gabe Wachob; xri@lists.oasis-open.org
> Subject: RE: [xri] URI/IRI/XRI - what should extend what?
> 
> Hi Gabe (& All),
> 
> I'm really hesitant to continue broadcasting my own stupidity so widely,
> so I'm tempted to leave the distribution list off the ongoing
> discussion. However, the cost of my participation on the committee is
> that sometimes I'll bother you with my misconceptions and/or different
> viewpoints. And until you convince me that something is a misconception,
> of course I consider it just a differe viewpoint. Thanks for putting up
> with me so far.
> 
> At this time we're still trying to figure out what XRI normal form is
> --at least Drummond and I are still discussing what it should be. Gabe,
> to help me better understand, can you provide an an example of a
> normalized XRI that would not be a legal URI?
> 
> I don't think we'd have to define how to do IRI on top of XRI (although
> some examples illustrating the IRI/XRI mappings/conversions would be
> helpful), because the IRI spec already defines how to do IRI on top of
> URI.
> 
> I'd like for people to be able to be interested in XRI without ever
> hearing mention of IRI, just like when I read about RFC2141 URN, or
> RFC2254 LDAP, or address specification in RFC2822, maybe LID, or other
> identifier efforts. When I want to figure out how to handle
> international characters, then I can look to the IRI spec.
> 
> LDAP directories support unicode, but at Boeing today we pretty much
> stick with ASCII in searchable fields (like names and identifiers) for a
> couple reasons: The HR systems that provide much of our directory data
> may not deal with non-ASCII, if we change people's names and identifiers
> to support foreign character sets most of the users would no longer know
> how to enter a search string containing unlauts and other stuff, and
> some unknown portion of the 1000+ production applications that rely on
> the directory would likely croak. There's probably more reasons if I
> think about it a bit longer. I'm not saying that Boeing directories at
> some point in time won't support IRI; I'm just saying that to do so will
> raise some costly, difficult, and time consuming issues. I don't think
> we'll support IRI (in searchable fields) for a long, long time.
> 
> My middle management is now bragging to higher-level execs that one of
> our 2006 accomplishments is the introduction of support for XRI in our
> directory service. When we cannot accept our partners' SAML assertions
> containing non-ASCII XRI, I'd like to say that it's because we don't
> support IRI rather than that we only partially support XRI, or that our
> XRI support is broken. Adoption of XRI will be hampered if people start
> to associate the IRI difficulties with XRI.
> 
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Computing Security Infrastructure
> (206) 679-5933
> 
> 
> > -----Original Message-----
> > From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
> > Sent: Tuesday, November 28, 2006 5:07 PM
> > To: Schleiff, Marty; xri@lists.oasis-open.org
> > Subject: RE: [xri] URI/IRI/XRI - what should extend what?
> >
> > What I hear is this:
> >
> > You want to be able to say:
> >
> > 1) If you are just doing us-ascii, then you can ignore
> > implementing any IRI stuff at all
> >
> > 2) If you are doing XRI with more characters, then use
> > something like IRI on top of XRI - something we'd have to
> > define since XRI syntax (in XRI normal
> > form) is a superset of URI - that is a legal us-ascii XRI in
> > XRI normal form may not be a legal URI.
> >
> > What we can say today is:
> >
> > 1) If you all you are doing today is us-ascii XRIs, then you
> > can ignore implementing any IRI stuff at all (but this is
> > only "partial implementation"
> > of the XRI spec - since we don't define "us-ascii-only XRIs")
> >
> > 2) If you are doing anything other than us-ascii XRIs, then
> > you have to do IRI processing after XRI normalization.
> >
> > I don't see that what you are saying is actually all that
> > more attractive over what we can say today. The only change
> > we might want to add is a note saying that you can ignore all
> > the IRI stuff if you don't care about working with anything
> > but us-ascii characters...  (we'd have to actually confirm
> > that in detail, but I'm fairly sure).
> >
> > Would that satisfy your need/interest/want/desire?
> >
> >     -Gabe
> >
> > > -----Original Message-----
> > > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> > > Sent: Tuesday, November 28, 2006 4:17 PM
> > > To: Gabe Wachob; xri@lists.oasis-open.org
> > > Subject: RE: [xri] URI/IRI/XRI - what should extend what?
> > >
> > > Hi Gabe (& All),
> > >
> > > I'll try again.
> > >
> > > If we say XRI is a URI scheme, then we can focus on ASCII-only. I
> > > think we can (almost) ignore IRI and its issues, just like I think
> > > http is oblivious to IRI.
> > >
> > > So the folks who aren't English-speakers can use IRI to represent
> > > their XRIs just like they use IRI to represent their http URIs.
> > >
> > > Marty.Schleiff@boeing.com; CISSP
> > > Associate Technical Fellow - Cyber Identity Specialist Computing
> > > Security Infrastructure
> > > (206) 679-5933
> > >
> > >
> > > > -----Original Message-----
> > > > From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
> > > > Sent: Tuesday, November 28, 2006 12:02 PM
> > > > To: Schleiff, Marty; xri@lists.oasis-open.org
> > > > Subject: RE: [xri] URI/IRI/XRI - what should extend what?
> > > >
> > > > Marty-
> > > > 	I think you may have a misconception about all these things.
> > > >
> > > > 	First, URI's are defined with US-ASCII only. If you don't do
> > > > US-ASCII, you don't do URI's.
> > > > 	So the folks who aren't Engish-speakers decided they
> > wanted to play
> > > > in the URI world and so they defined IRI. IRI is
> > basically just the
> > > > way of encoding the full range of UTF-8 characters into URI-legal
> > > > strings.
> > > >
> > > > 	So if we don't leverage IRI, we just have to rewrite
> > IRI. I don't
> > > > see any point in that.
> > > >
> > > > 	If you want to support XRI, you have to support the full set
> of
> > > > internationalized characters, and the easiest way to do
> > that is to
> > > > use IRI libraries which are pretty ubiquitous now. There
> > are a lot
> > > > of Unicode corner cases and I'm fairly certain not
> > everyone handles
> > > > all of Unicode correctly.
> > > > But this is one of those areas where 99.99% of the cases
> > are handled
> > > > correctly and we should be happy with that.
> > > >
> > > > 	So, I'm not sure its really a big deal for a vendor to
> > support URI
> > > > and not IRI. And if they don't want to support IRI, then they
> > > > *really* won't want to support XRI.
> > > >
> > > > 	-Gabe
> > > >
> > > > > -----Original Message-----
> > > > > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> > > > > Sent: Tuesday, November 28, 2006 9:28 AM
> > > > > To: xri@lists.oasis-open.org
> > > > > Subject: [xri] URI/IRI/XRI - what should extend what?
> > > > >
> > > > > Hi All,
> > > > >
> > > > > The XRI Syntax spec describes IRI as extending the
> > character set
> > > > > of URI, and then describes XRI as extending the syntactic
> > > > elements (but
> > > > > not the character set) of IRI. If I were a product vendor, it
> > > > > would sound to me like in order to support XRI, my
> > products would
> > > > first (or
> > > > > also) have to support IRI. I might think IRI support sounds
> > > > > complex with lots of implications to my install base, so if I
> > > > > decide not to support IRI it also means I wouldn't be
> > supporting XRI.
> > > > > To me it seems like IRI adds lots of complexity to XRI.
> > I'd rather
> > > > > just say XRI is a URI scheme, restricted to UTF-8 like any
> > > > other URI.
> > > > > In XRI let's not even worry about other encodings. When
> > > > international
> > > > > characters are needed in an XRI, then the IRI spec deals
> > > > with how to
> > > > > do it. Let's leave the complexity in the IRI spec. Of
> > > > course we could
> > > > > include a section in the XRI Syntax spec that gives
> > > > examples of how to
> > > > > convert a URI with a scheme of xri:// into an IRI
> > according to the
> > > > > steps described in RFC 3987.
> > > > > I put this idea on the wiki (item #3.11 under XRI Syntax).
> > > > >
> > > > > Marty.Schleiff@boeing.com; CISSP
> > > > > Associate Technical Fellow - Cyber Identity Specialist
> > Computing
> > > > > Security Infrastructure
> > > > > (206) 679-5933
> > > >
> > > >
> >
> >


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]