[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Agenda: XRI TC Telecon 10-11AM PT Thursday 2008-06-05
As it happens to be 2:00AM JST, I think I am not going to make it, so
here is what I think.|
Drummond Reed wrote:
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">This depends on how long W3C want to take for dialogue. Perhaps 6 months?Following is the agenda for the unofficial telecon of the XRI TC at: Date: Thursday, 05 June 2008 USA Time: 10:00AM - 11:00PM Pacific Time TO ACCESS THE AUDIO CONFERENCE: Dial In Number: 571-434-5750 Conference ID: 5474 AGENDA 1) DISCUSSION OF NEXT STEPS FOLLOWING XRI 2.0 VOTE Our first agenda item will be to continue the discussion started on Monday's special telecon about the next steps the TC will take following the vote. Specific questions we want to answer as part of this conversation: a) How soon do we want to take the XRI specifications to another vote?
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">For Syntax:b) What level of changes in the specs do we anticipate making first?
Earlier, I have suggested to replace xri:// with http://xri.net/ . To me, the former is better, I think, but I can live with the later, because end users will almost never see xri:// nor http://xri.net/ . Write it in perhaps URI template if it could be.
But, more importantly, make it clear that XRI is not URI. We define the transformation into URI, but that's about it.
Perhaps we can forget about IRI completely. For the sake of simplicity for the implementors, it probably is a good thing to do. Instead, we just state something like, "For network transmission, it MUST be UTF-8 unless the content encoding is explicitly stated in the underlying protocol." etc. When used as URI, of course, it has to be transformed to URI by urlencoding, of course. (Obviously, this should be explored more in detail. Point is: make it simple for the implementors, and make the international encoding deployable easily. FYI, freexri.com' XRI are Japanese capable already, thanks to Markus. He may have more input from the point of view of an implementor.)
Equivalence: Forget the normalization etc. Just compare i-numbers after resolution. An exact match is equivalence.
Also, incorporate UUID as an i-number so that transition of a local community to get connected to the global community would be smooth. (I have indicated this earlier as well.)
These change would incorporate many of the TAG opinion, as well as simplifying the spec.
Add some Non-HTTP resolution bindings. They can be pretty simple, like what I have suggested for SMTP and VOICE. I am kind of interested in finding a good way of doing this kind of thing on a high performance data-bus (e.g., mostly UDP based, I think. Also, something like TIBCO Rendezvous is interesting to me. ) kind of things as well as a binding on CICS/MQ :-)
As to the global root problem is concerned, it is nice if we can solve it, but I do not have a ready answer for it. Perhaps a P2P like setting may solve it, but I do not think this can be done in the above timeframe. (Techincally, it is very interesting, though.)
It might be worthwhile for us to consider breaking up the document into smaller pieces as well.
In General, our guidance should be the ease of development and deployment, not theory.
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">Perhaps:c) What other companies or individuals do we want to get involved?
- Technology Vendors: Microsoft (abstain), IBM (abstain), Oracle (Yes), TIBCO (Yes), Sun(No),
Verisign(No), Nokia(No) etc.
It may be kind of nice if we have some W3C view represented in the TC as well.
Also, some more international representation like NTT (Yes), NEC (No),
Beijing Sursen (Yes), etc.
- Business / Government Community: DoD (Yes), Wells Fargo(No),
Australian, Department of Education, Employment and Workplace Relations (Yes),
+ Some more representation of dobule and triple bytes language users would be nice.
- Academic Community: UCB (Yes), UoR(Yes), MIT(abs), etc. (ditto for multi-bytes)
- Grass root initiatives: (If there is one in OASIS.)
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">Make a compelling beta apps and deploy them to appeal to the general public for its utility.d) What other adoption avenues do we want to pursue in that period?
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">- XRI benefits on OpenIDe) What non-normative materials do we want to produce in that period?
- Solving Zooko
- Non-HTTP usage of XRI
- XRI deployment made easy
- Real World Case Studies
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">At least, IMHO it should include:2) OASIS COMMUNICATION ON XRI VOTE OASIS News will carry a short article on the results of the vote. Based on our discussion above, what points do we think it important to include? In addition, do we believe that OASIS should make a public communication about the vote? If so, what points should that include?
- It was one of the most highly voted ballot.
- The actual ratio of Yes to No in percentage of vote, and by how many negative vote mergin it did not pass.
i.e, it was only by less than ONE vote mergin.
- Mention W3C, Wikipedia, etc. campaigns (perhaps.)
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">This is a good idea. Especially for "No" voters to collect what they did not like about XRI.3) XRI TC COMMUNICATION WITH OASIS VOTERS Several people have recommended we communicate with all voters -- Yes and No -- thanking them for taking part and making it clear what our next steps will be. We will determine and assign this action item.
Even if they say "TAG reccomendation", ask them, what on TAG recommendation was particularly of interest to them.
Some of them can answer. Some of them probably will not be able to answer.
It is even better if we can get some of them to the TC.
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">To me, what TAG was concerned technically has always been a bit vague.4) NEXT STEPS WITH W3C TAG Again, in the context of the conclusions above, what specific next steps and outreach do we want to make to W3C TAG? Note that this is on the agenda of their meeting on Friday: http://lists.w3.org/Archives/Public/www-tag/2008Jun/0026.html
I am +1 to http://lists.w3.org/Archives/Public/www-tag/2008Jun/0008 by Marty.
065801c8c6d2$2517d5d0$0800a8c0@ELROND" type="cite">Licensing thing is a fact. Neutrality is about the interpretation. Fact is fact. To state the fact, neutrality is not necessary.5) WIKIPEDIA PAGE ON XRI The neutrality of the XRI page on Wikipedia has been placed under dispute, including specifically the licensing section. This has been correct by XRI TC members several times in the past. See the Talk page at: http://en.wikipedia.org/wiki/Talk:Extensible_Resource_Identifier We will discuss with OASIS Staff the best way to proceed with ensuring that errors are corrected and the information on this page is neutral and factual.
That annonymous post/changes are challenges to OASIS Open itself, and our legal system, IMHO.
(I do not know in the U.S., but repeatedly making a factually false claim on a entity to disrupt the entity's reputation is a criminal offence in Japan.)
I hope OASIS can settle this issue, not XRI TC.
Nat Sakimura (=nat) Nomura Research Institute, Ltd.