Re: [XRI} Draft minutes from TAG telcon of 2008-07-24

Hi All,

Just some quick answers to questions you pose.
My intent is to be as transparent as possible.

My comments are inline.


> Issue UrnsAndRegistries-50 (ISSUE-50)
>
> http://www.w3.org/2001/tag/group/track/issues/54
>
> SW: There has been some discussion with the XRI TC, as well as some
> private conversation with their chairs, to the effect that we would
> take things forward via www-tag
> ... which has largely happened, whether we started it or not
>
> HST: So as I signalled I would, I started drafting a message about the
> "[the] http scheme did not allow us to use non-DNS authority
> resolution" XRI issue. I got distracted from this by trying to explore
> the impact of certain aspects of WebArch on ARKs based on my
> inclination to move XRIs in that direction if possible
> Mark Baker got involved, and latterly DC. I think there's a
> fundamental issue we need to be clear on: is it OK for a group of
> domain name owners to agree a naming convention amongst themselves? In
> the ARK case, this trespasses on the WebArch advice wrt aliasing, and
> in general might also seem to fall foul of the whole business of URI
> opacity (that was Mark Baker's particular concern).
>
> DC: I think the ARK scheme is good
> ... It does promote aliases, and suffers the consequent downside:
> caching may not work
>
> DC: But that was necessitated by the lack of a single domain holder
> who could do the job
> ... So I think it's OK
> ... It's fine for e.g. Univ. of Minnesota to say "We will use ark: per
> the ARK spec.", it's not fine for any client to interpret the presence
> of ark: to mean "this URI is an ARK"
> ... There has to be an independent channel, e.g. to the client
> developer, that UM has commited to the ARK story, and this was a UM
> URI that had ark: in it
> ... Is the ARK spec on the right side of that line? I.e. does it
> expect clients to treat all ark: as ARKs?
>
That is true for ARK however,  I think applying it to XRI which was  
the goal of the conversation would lead to all clients treating all  
paths beginning with xri: as XRI.

That is where David Booth and I expressed concern in that it violates  
the clear chain of authority principle at least when applied to XRI.

I point out that none of this from our side is intended as criticism  
of what ARK has done.

> HST: I think it's on the right side, but we should check
>
> DC: Similarly you don't want to use xri.... as a domain-based key w/o
> getting IANA to reserve that subdomain

A TLD would be nice if we are going to do it.
>
>
> <Stuart> Henry did you see the most recent Bradley proposal based on
> dns namess like boeing.com.xri.net (ie. it is under xri.net).
>
> SW: Right, hence the xri.net, or, following a suggestion from me,
> boeing.com.xri.net, using subregistrations under xri.net
>
> <DanC> John Bradley signs his messages http://xri.net/=jbradley
>

http://xri.net is the public HXRI proxy run by NeuStar as part of the  
XRI Global Registry Service.

This has been in operation for over a year.
HXRI and the proxy resolver resulted from the first feedback from the  
W3C a number of years ago now.

> SW: There seems to be some willingness, e.g. on the part of John
> Bradley, to shift from using a scheme to using subdomains

It wouldn't be much of a discussion/negotiation without some  
willingness to compromise.

I think we would all like to find a "Best Practice"/Standard for  
dealing with the things that I have described as sub schemes within  
the http: scheme.   Where user Agents can trigger click behavior based  
on the sub scheme.

A ARK browser could be triggered if it is an ARK sub scheme URI. etc.
Other external apps could be triggered like a file browser for DAV
Or smart apps will have additional functionality built in for sub  
schemes.

Perhaps even a standard Javascript repository could be established for  
the sub-schemes to help browsers do smarter things with them.

What I want to avoid is some people like ARK using the path and some  
people using the authority,  and someone else coding things into the  
port numbers or user name.

If a standard for sub-schemes is developed the XRI-TC will seriously  
consider using it.
I would personally undertake to advance that inside the XRI-TC.

Using a registered URI scheme may have drawbacks but at least it is a  
standard.

I await HST's further information on using http: with "non-DNS  
authority resolution"

I don't yet see consensus amongst the TAG on the best way for us to  
proceed.

The XRI-TC remains open to input.

>
>
> <DanC> "OASIS IDtrust Steering Committee is a special group" --
> http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=idtrust-sc
>
> <DanC> (hm... http://idtrust.xml.org/ ...)
>
> <DanC> (and now http://www.oasis-idtrust.org/ ...)
>
> <DanC> aha! found a full URL for "OASIS IDTRUST-SC":
> http://www.oasis-idtrust.org/steering-committee
>
> <DanC> and http://www.oasis-idtrust.org/bradley

The OASIS Identity and Trusted Infrastructure (IDtrust) Member Section  
consists of a number of OASIS Technical Committees:
Digital Signature Services eXtended (DSS-X)
Enterprise Key Management Infrastructure (EKMI)
Open Reputation Management Systems (ORMS)
Public Key Infrastructure (PKI) Adoption
Extensible Resource Identifier (XRI)
XRI Data Interchange (XDI)
Identity Metasystem Interoperability (IMI) TC  (*Proposed)

The Member section coordinates and supports it member TC's
We co-sponsor two major events.
The Open Standards Forum in London this year http://events.oasis-open.org/home/forum/2008
IDtrust 2008 with NIST and Internet2 in MD http://middleware.internet2.edu/idtrust/2008/

Yes that was a shameless plug:)

I am a steering committee member  elected by the members of the TC's  
in the IDtrust section.
http://www.oasis-idtrust.org/node/60

The Steering committee would like to see these issues resolved between  
the XRI-TC and the TAG.

I have discussed this with committee members,  they are aware of my  
posts to the TAG list.

>
>
> SW: Of course Bradley doesn't speak for the TC

I do not.  I am really quire grateful for that:)

This allows me to explore the options with people without prematurely  
committing the XRI-TC to a particular course of action.

At the end of the day I may wind up disavowed by both sides in this  
matter.  I am OK with that.

>
> <Stuart> http://lists.w3.org/Archives/Public/www-tag/2008Jul/0096
>
> SW: I asked Shleiff if he could live with the 'booth-bradley'
> proposal, and
>
> SW: he has replied that although preferring a scheme, he could live
> with booth-bradley
> ... DC, what do you think?
>
> DC: As long as it's ??? or xri., yes

This is one proposal.  It may turn out to be the best one.  David  
Booth is a smart guy.
It would be premature to rule other other possible proposals from HST  
based on ARK or something else.

I think the booth-bradley proposal has merit,  but I am not  
emotionally attached to it if something better turns up.

>
>
> SW: HST?
>
> HST: Yes, maybe, behind on my reading
>
> SW: I think DO might be on board, but that was a while ago. . .
>
> SW: we would need to check with him

I think DO is back from Vacation shortly I will try and meet with him.

SW and I have been discussing how XRI's use of a scheme with IRI may  
have fallen afoul of the interpretation of anyURI in http://www.w3.org/TR/xmlschema-2

Or more specifically in http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators

The value of the href attribute must be a URI reference as defined in  
[IETF RFC 2396], or must result in a URI reference after the escaping  
procedure described below is applied. The procedure is applied when  
passing the URI reference to a URI resolver.

The interpretation of the above with respect to IRI in XML and more  
particularly XRI IRI in XML may be one of the root issues of the  
disagreement over XRI  2.0' adoption as a OASIS standard.

I think we need to fully understand this before choosing the correct  
remedy.

I hope to get together with DO and discuss this i detail.


>
>
> SW: So this is coming down to: Is the TAG's concern entirely around
> the new scheme?
> ... Metadata is perhaps another area
> ... We don't have critical mass for that discussion right now

SW and I have discussed the metadata/data issue off-list and I hope to  
get something together on the topic for everyone shortly.
I personally think this can be addressed through education and  
documentation rather than spec changes.

I will get something out i the next week.

>
>
> <DanC> (re representations vs metadata, well... if they go with
> http://xri.net/... , then I think that problem will take care of
> itself; they'd hardly be the wierdest web site out there.)
>
> SW: Formats for messages, which encourage e.g. the use of =iname, and
> don't allow URIs, is an over-constraining position which we might have
> to object to

XRI supports DNS, IP,  and http:  authorities,  as well as others  
through cross references.

I think Marty Schleiff had an example of how XRI could support ARC  
through cross references.

I need some clarification on what message formats you are referring to?

>
> ... I've agreed to meet with Peter Davis and Drummond Reed to discuss
> how the discussion is going
> ... I'd like to have someone with me if I can't have TimBL
> ... I'd suggest HST
> ... They've suggested 4 August
>
> HST: I will be on holiday then
>
> DC: Wrt emails, I'm not sure to what extent the main participants
> speak for the TC
> ... Is there a critical mass of the TC participating?

You can be assured that I have a peanut gallery at OASIS especially  
the XRI and XDI TCs

Some people find engaging the TAG intimidating.   I am attempting to  
proxy there opinions, as best I can.

Drummond and others are on Vacation, but I am in contact with them.

>
>
> SW: I think the participants are influential, but until a specific
> proposal is framed and put to the TC for approval
> ... we can't really make any assumptions
>
> <DanC> http://lists.oasis-open.org/archives/xri/
>
OASIS and the TCs operate through formal votes.

Until we have something concrete to vote on it is difficult to take  
formal action.

Be assured that this is on the agenda of every XRI-TC meeting.

> SW: AM?
>
> AM: I haven't looked into details, but the sense of progress towards a
> compromise is certainly encouraging
>
It is.

> SW: JR?
>
> JR: A lot of the problem is that the TAG's position is not
> well-communicated, or is very sophisticated, and so is hard to get
> across to this group, who don't share our interests
> ... I think it is beginning to get across
>
> <DanC> fwiw, I took a stab at this URI persistence stuff in
> http://www-128.ibm.com/developerworks/xml/library/x-urlni.html
>
This morning I posted on the persistence issue and the differences  
between ARK's notion of persistence and XRI's.

I will have a look through your doc.  Please feel free to add to the  
thread.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中