See also: IRC log
<scribe> Scribenick: Ashok
<scribe> Scribe: Ashok Malhotra
<Drummond_Reed> BTW, the page Peter will be speaking to in a minute is http://wiki.oasis-open.org/xri/XriTcW3cTag
Stuart: Outlines objectives of the call
Drummond: Peter will co-chair the call
<ht> A reminder to our guests that we take minutes in IRC, and the IRC logs will be public in an hour or two, so bear that in mind
Peter: This initial call should be a discovery process that will start a productive dialog
Stuart: We take notes on IRC. The minutes are public. I will run the minutes by the chair of the XRI TC before publishing
ht: The bar for introducing new URI schems should be very high and I think XRI does not get over the bar but lets discuss
jar: We are looking for URIs for data integration ...
Drummond: Lack of discussion seems to have led to a number on misunderstandings on both sides ... I hope we can clear those up
<timbl> "Global Registry" ? pointer?
<JeffH> I may have been pegged as IPcaller
<Drummond_Reed> XRI global registry services are provided by XDI.org (http://xdi.org) - Cordance and NeuStar are contractors to XDI.org
Frederick is that you?
<timbl> Ashok, are you capturing these intros somewhere?
no, I was not ... only the high points
Jamie: Looks forward to better collaboration between OASIS and W3C
fhirsch: I'm with Nokia and also on the OASIS board. I am interested in how all this works out
<GabeW> It would be great to have fhirsch here
Stuart: Frederick, I'm happy to have you stay. Our records are public
<peterdavis> XRI TC is fine with Fredericks attendance
<timbl> Paul Trevithick (sp?) -- started teh Higgins project, unifying objects a cross a global graph.
Paul_Trevithick: ... started Higgins project which has to do with identifying objects over a global graph
DaveO: Tag member... belives in using existing technogies where possible but I'm open ...
Stuart: Peter, please summarize where XRI TC is
Peter: We will do some TAG teaming on this
<Drummond_Reed> Peter will be speaking to a page on the XRI TC wiki: http://wiki.oasis-open.org/xri/XriTcW3cTag
Peter: I have 4 sub-items on the intro
What problems the XRI TC expects to solve... usecases
Conclusions we came to ... URis were not quite sufficient to address these
How the XRI commitee drafts solve these
IPR issues
Problems we are aiming to solve
<timbl> "feasibility of URIs wrt to authority production" ?
1. Cannot be dependent on any transport or protocol or authority
TimBl: asks clarification on authority part
Peter: Did not want to be dependent on any authority
2. Independence of any characteristic of resource that may change over time
<jbradley_ve7jtb> FYI I was dropped by the bridge and can't get back in because it is full.
<jbradley_ve7jtb> I will stay on IRC
<peterdavis> Enables cross-mapping of multiple abstract or concrete identifiers for the same resource
<timbl> The TC had a requirment to create multiple synonym IDs which could be canonicalized into one canonical ID.
This gets at the issue of synonms
<timbl> -- timbl's understanding if what was said
<Drummond_Reed> clarification: it is not a requirement that the synonyms *must* be canonicalized into one, just that this is an option
4. can map any number of concrete identifiers into a service ... such as SOAP service
We have a small number of services types that can be used with XRIs
SOAP, or XML get or a more complex service
TimBL: These are to resolve references
Peter: No, can point to specific service such as UDDI
<ht> John Bradley: dial *0 when you are told you can't get in
<ht> and ask Josh to patch you in manually
<jbradley_ve7jtb> OK
Drummond: These are captured on the page above
<Stuart> ie. http://wiki.oasis-open.org/xri/XriTcW3cTag
I think of XRI as abstraction layer on URIs
Peter: Another requirement is cross-context identifiers
So, one identifier can reference another identifier in another scheme
Peter: Marty provides examples in Boeing usecases
Marty: In a directory situation, looking up a authenticated identifier and looking up its properties
e.g. X509 identifiers, ... SAML assertions.
Lot of internal apps look up things based on employee number
XRI can help describe identifier and then point to matching rules
<Drummond_Reed> sorry, I got dropped due to operator error (my own)
<Drummond_Reed> am back
Stuart: please explain this XRI
<Stuart> xri://=(mailto:gabewachob@gmail.com)
<GabeW> I'd note, btw, that this mailto: URI is not my actual email address...
<JeffH> i.e. this is just an example?
<GabeW> which is an accident
Peter: in front is a cross reference. The = global context symbol. There are 4
<DanC> "=" is xri syntax meaning "the authority is an individual" <- that's what I understood
<peterdavis> Ashok, Drummond is speaking, FWIW
Says it's personal
<timbl> "Global context symbol -- there are 4 = person , + general,. @ orgamization $ standards body"
<timbl> / is global context and / is a authority -local context
<timbl> ... // is global context and / is a authority -local context
In native form you don't need xri:
<Drummond_Reed> XRI syntax defines four global context symbols for establishing shared context for an identifier
<Drummond_Reed> = for personal identifiers
<Drummond_Reed> @ for organizational identifiers
<Norm> So xri://= means it's a person, xri://@ means it's an organization, etc.?
<timbl> Norm, yes I tink so
Cross context works at any level of the path
<DanC> don't think so, Norm; I gather xri://=(mailto:gabewachob@gmail.com) is notation for mailto:gabewachob@gmail.com ; i.e. it refers to a mailbox, not a person.
<GabeW> Norm: yes
<peterdavis> xri://@boeing*(@example*bob) is from Boeing use case
<DanC> oops; looks like I misunderstood.
<GabeW> DanC: the stuff inside the () is just a string -- but it can be extracted mechanically as a URI
<peterdavis> perhaps a better subject for dicusion
Marty: It will be the example about multiple identity providers for a single entity
<Stuart> GabeW: is it not more restrictive down to being another XRI?
<Drummond_Reed> actually, Dan's point is a very good one: mailto:gabewachob@gmail.com is an identifier of a mailbox, while xri://=(mailto:gabewachob@gmail.com) can be an identifier of the person using that mailbox
Stuart: Do you want to go back to top-level of the summary
<DanC> can be?
Peter: We discussed looking at URis and we thought a new identifier syntax was necessary
<Drummond_Reed> I say "can be" because the assertion is that the authority for that identifier is a person
1. A uri is either local or requires a DNS. DNS may not be always right authority. E.g telephone number does not use DNS.
<Norm> So an XRI for a telephone number would include an authority component?
<timbl> tel://1/617/671/6200
TimBL: Telephone numbers have a hierarchical pattern to them
<timbl> That would have been fine use of punctuation
Peter: It does have a delegation pattern look to it
But some identifiers do not have delgation properties to them
2. This notion of cross referencing is not possible ... embedding identifiers is important to us
3. synonym support -- we did not find a model for synonms
<DanC> (the pattern of "http doesn't have X so we can't use http" seems to skip past the possibility of layering X on top of http. e.g. synonyms; RDF/OWL layers synonyms on top of http (and other) URIs )
4. Notion of interop service discovery ... UDDI, ebXML discussion
http schems could probably fulfil this with careful instructions
Drummond: IPR concerns were brought up in contect of XRI vote
We have noted concerns on the page
Requirement that IPR be RF ...
Jamie: 3 things ...I'm not sure which are TAGs concern
I don't think the IPR issues were core of the TAGs critiques
Sorry ... I had trouble getting the IPR points ...
Jamie: The IPRs associated directly
with the OASIS TC deliverable.
... The IPRs associated with setting up and operating an XRI
resolution service and/or a registry
... Missed 3rd point.
<MartySchleiff> Norm - look for 'express" in the Boeing XRI use cases
<timbl> I think that people on the net checked wondered about the reason for starting a new naming scheme and look for commercial motivation.
ht: We had questions about registration and management process
TimBL: The TAGs concerns is architectural... competion with URI space
What's the motivation?
Historically, the motivation has been commercial
People have been asking on the net
ht: Gloss on the single sentence... TAGs reading is understand, document and preserve the value proposition of the architecture of the Web
Centrality is the Web being a single information space.
This hugely important in keeping the Web valuable
<JeffH> on which list was this said, HT ?
It's not the other schemes split the info space but they Balkanize it
Thus, bar on new identifier schemes must be very high
You need to demonstrate there is a bar for URIs doing what you want or there is a huge value add
Convenience is not enough
many types of naming schemes amount to lookup + hierarchy
Existing mechanisms have solved a bunch of problems
reinventing all that has a huge cost -- both technical and social
We have not heard convincing arguments that XRI provides enough value add to overcome that cost
I will give you all your requirements and still say the cost of fragmenting the info space is too high
Cost to a naming scheme no one can click on and follow
Any new naming scheme require a huge amount of work from a lot of folks to get into the game
<dorchard> The Mark Baker email about fragmented information space is http://lists.w3.org/Archives/Public/www-tag/2008Jun/0042.html
<MartySchleiff> Henry - did you read my response to your misrepresentation of how things work at Boeing?
<ht> Yes, and I'm glad to hear that things are more flexible than I thought
<ht> I know of many other large organisations that don't have that flexibility
Stuart: Let's allow 10 minutes of discussion and get to next steps in last 5 minutes
Peter: We do not want to fragment the info space
There are several facets to XRI naming structure that we may or may not have articulated
We did not find ways to represent embedded idenfiers within URI BNF
<timbl> The political requirement to make a different authority to IANA was mentioned earlier
Many of our identifiers use DNs some do not. We need to figure out which do and do not
<ht> HST thinks that addressing the "http scheme did not allow us to to use non-DNS authority resolution" is a very concrete challenge that we could focus on
<Drummond_Reed> Yes, and in fact XRI proxy resolution -- which uses XRIs in HTTP URI form -- does that
Marty: Boeing usecases do not talk about click behaviour or what the browser is supposed to do
<GabeW> in fact, xri.net/<xristuff> is how xri's are largely being resolved today
<DanC> (hmm... where does the requirement to use non-DNS authorities come from? that sounds more like a solution than a requirement. Indeed, why doesn't http://xri.org/etc work?)
The cost of introducing all new fetures into URI would be more than introducing a new scheme
Drummond: Intention is not to fragment the info space
Our requirements were not URI compatible ... we tried and defined mapping from XRI to URI and IRI normal forms
<Stuart> There's a relevant message from Roy Fielding at: http://www.w3.org/mid/DA4CB689-4D55-4261-9AA3-B63BD2308D43@gbiv.com
The cross reference requirement has grown in important ... primarily to data sharing
the XDI TC is looking into that
<peterdavis> danc, because, in part, identifiers are produced in many spaces, not just atop the Internet Protocol
<DanC> (embedding URIs inside other URIs doesn't require a new scheme. every forms-based service that asks users to input a URI does it, e.g. the W3C markup validation service.)
<Stuart> he says (amongst other things): "... Because http URIs are not,
<Stuart> in fact, dependent on DNS.
<Stuart> "
<MartySchleiff> Ashok - The cost of introducing all new features into http: would be more than introducing a new scheme
<dorchard> Really, it has far more to do with a basic misunderstanding of
<dorchard> web architecture, namely that you have to use HTTP to get a
<dorchard> representation of an "http" named resource.
<Zakim> dorchard, you wanted to talk about protocol independence and metadata in URIs
We want to create compatibility with info space while adding a branch that adds value
<DanC> peterdavis, no Internet Protocol operations are needed to mint an identifier that starts with http://xri.org/
DaveO: You say you don't want to fragment info space but it sure looks like it
You duplicate a number of URI infrastructure features.
<MartySchleiff> +q
What's the killer app for XRI's?
We could say "XRIs will be URIs" and this meets some of our requirements but not all
DaveO: An early claim was 'we need XRIs to prevent phishing attacks'
Web Services have fragmented the info space and this has caused great grief
Web Services have carved out a small space ... this has restricted their growth
I don't want to see that happening again
<GabeW> thats an issue I'm personally interested in, fwiw
Roy says http identifiers do not have to be bound to http
<Norm> They sure don't.
XRI coud use a URI template to restrict space for special uses
<timbl> ok
Jamie: The list of concerns tells me we need more conversation
should continue
Visceral response from OASIS -- we should reply to critique
Some of the OASIS community comes from a different perspective re. single info space
We need to discuss which XRI requirements could be satisfied by URI schemes
<ht> Jamie == James Bryce Clark ?
<peterdavis_> yes
Stuart: Summer is looming may be hard to schedule calls
Please use public mailing lists for technical discussion
<ht> HST votes for non-DNS authority as really central, and easiest to explore
Perhaps we need more focussed calls on some of Peters items
Peter: I agree on exploring single requirements
<ht> HST hopes that we stay on www-tag or somewhere similar -- we need more expertise than we have in this small group. . .
Drummond: Subgroups may be an efficient way to proceed
<peterdavis_> i agree ht. just challenging to follow this topic independent of the other topics on www-tag
Stuart: Let's go back and think about subgoups
Drummond: We can also do f2f meetings
<MartySchleiff> +q
<GabeW> thanks all!
<GabeW> see some of you on #swig
Peter: We appreciate taking up your call ... look forward to further discussion
<jbradley_ve7jtb> by
Thanks all around
Close of meeting
<Drummond_Reed> Thank you Ashok for scribing
<wil> thanks all