Joint TAG and XRI TC

3 Jul 2008


See also: IRC log


Stuart_Williams, Tim_Berners-Lee, Ashok_Malhotra, David_Orchard, Henry_Thompson, Norm_Walsh, Jonathan_Rees, Dan_Connolly, Drummond_Reed, Peter_Davies, Paul_Trevithick, Fredrick_Hirsch, John_Bradley, Les_Chasen, Gabe_Wachob, Jeff_Hodges, Marty_Schleiff, Marcus_Abadello, Will_Tan, Nika_Jones, Jamie_Bryce_Clark
Noah, Mendelsohn
Stuart Williams
Ashok Malhotra




<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

XRI TC Position (Peter Davies/Drummond Reed)

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

W3C TAG Position (Henry Thompson)

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

Next Steps

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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2008/07/09 12:52:41 $