[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier Metadata
+1. As for how a particular type of local access might help, have I got a protocol for you!! ;-) Seriously, I believe XDI is expressly designed for this kind of XRI-identifiable resource description. It would fit like a dream (now it's me dreaming, not Marty ;-) =Drummond -----Original Message----- From: Lindelsee, Mike [mailto:mlindels@visa.com] Sent: Thursday, September 22, 2005 4:34 PM To: Drummond Reed; xri@lists.oasis-open.org Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier Metadata Discussing this during the call sounds reasonable to me. It seems to me that if these "typed" XRIs are going to be resolved using something other than XRI authority resolution, we should consider how XRI resolution (or local access) might facilitate that resolution. Mike >-----Original Message----- >From: Drummond Reed [mailto:drummond.reed@cordance.net] >Sent: Thursday, September 22, 2005 4:23 PM >To: Lindelsee, Mike ; xri@lists.oasis-open.org >Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for >Identifier Metadata > >Mike, two quick notes RE this thread: > >1) The concept of resolution of $ space XRIs is pretty new and applies >(IMHO) only to "dictionary" services -- something we talk >about extensively >in the context of XDI (which I fully recognize is a different >TC). But the >XRI specs says nothing about resolution of the $ space and I >don't think >they need to. What's been being discussed is simply how it >might work if it >was applied (given that Marty has a use case for doing so). > >2) Marty's "dreaming" about a $t type definition language and local >resolution service is forward thinking about how it might work >and not at >all in the scope of XRI 2.0. The only thing being discussed in >the scope of >2.0 is the addition of a $t tag to Metadata (item #3, after >the two Syntax >items, on tonight's/tomorrow's calls.) > >I'd suggest we talk over the use cases and requirements on the >call. If more >documentation is needed, we can agree on that and assign the >action item. > >=Drummond > >-----Original Message----- >From: Lindelsee, Mike [mailto:mlindels@visa.com] >Sent: Thursday, September 22, 2005 3:56 PM >To: xri@lists.oasis-open.org >Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for >Identifier >Metadata > >Comments inline... > >>-----Original Message----- >>From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] >>Sent: Thursday, September 22, 2005 1:32 PM >>To: Wachob, Gabe; Drummond Reed; xri@lists.oasis-open.org >>Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for >>Identifier Metadata >> >>Hi All, >> >>Regarding #3: I think this just means if an application encounters an >>XRI including something like ($t*uuidpair), the application >>will be able >>to know that it can use a different aproach for resolution (Open Group >>proposes a pair of UUIDs where one represents the issuing >>authority that >>can be looked-up for resolution purposes). It's not XRI >>resolution, it's >>UUID Pair resolution. > >I keep trying to fit this idea of using a different approach to >resolution of an XRI into the XRI architecture and continue to have a >hard time understanding why local access isn't the appropriate >solution. >From what I can tell, local access should cover this sort of behavior >perfectly. > >Perhaps some relatively detailed use cases would help everyone to >understand the functionality that is needed. At the very least, it >would help me to understand the tie between specifying semantics within >XRIs and resolution of those (or parts of those) XRIs. > >> - Or, if an application encounters an XRI including something like >>($t*dn), the application could know that it might have to >first do some >>normalization on the DN values before doing a string comparison (or >>whatever the comparison rules are). >> - Or, if an application encounters an XRI including something like >>($t*otps), the application will know that the identifier is a one time >>pseudonymn so it shouldn't bother establishing a local >profile for that >>identifier, because it will never be used again. >> - Or, if an application encounters an XRI including something like >>($t*IP), the application will know it represents an IP address that it >>might be able to ping rather than an OID. >> > >These examples seem like the tip of an iceberg to me. Who are the >participants in the use of these XRIs (e.g., who creates, manages, uses >them) and what are they used for (e.g., pure identification, >resolution, >a key in a data store somewhere)? Are the XRIs used "whole" (e.g., >xri://@foo*($t*IP*10.0.0.1)) or "in part" (e.g., $t*IP*10.0.0.1). If >they are resolvable (in XRI terms), what is returned in XRIDs for these >identifiers. > >I realize I'm crossing the boundry from requirements and use cases into >architecture and design, but I'm hoping my questions show why the >proposal doesn't seem like an obvious solution to me. It seems like >unstated problems are trying to be solved. I want to make sure that we >solve issues related to identification and resolution using XRIs in an >architecturally consistent way. > >>Regarding #4: I'm not sure I understand this one either. I think it >>means any issuer if identifiers could issue them with any identifier >>type. I don't think it means anyone can define a new identifier type >>under $t. Am I close? >> >>Regarding SUMMARY NOTE: If I think of it from the perspective >of an XRI >>resolver, I think it would be better to express even a mailto >>within XRI >>with a $t. That way, software will be able to recognize it as >>an XRI and >>invoke their XRI processor which will know how to deal with >>it. I may be >>dreaming, but it seems that way down the road we could define an XRI >>type definition language that we use to describe the caracteristics of >>each identifier type. Then the XRI resolver wouldn't even have to >>understand what is meant by ($t*mailto); instead it could just lookup >>the characteristics of mailto and process it accordingly. Such XRI >>resolver applications would not need to be enhanced whenever new >>identifier types are introduced; they'd only require modification when >>the type description language changes. Am I dreaming too large? > >This sounds very much like local access to me. While local access >doesn't specify the details of different resolution types, it is the >hook we built into XRI resolution for just that purpose. While you are >definitely not dreaming too large, I'm not sure that what you are >proposing is in scope for the 2.0 release. As with all of the other >proposals though, I think we should discuss the requirements and use >cases. > >Mike > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all >your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]