OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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

Hi Drummond and Nat,


  It may be worthwhile to check out what UBL and the TAG TCs are doing around double meetings to make sure everyone can participate.






From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, June 05, 2008 12:47 PM
To: 'Nat Sakimura'
Cc: 'XRI TC'
Subject: RE: [xri] Agenda: XRI TC Telecon 10-11AM PT Thursday 2008-06-05


Nat, thanks very much for taking the time to send this. I know the current call timing does not work for you. This may be something that the TC needs to revisit again – as you know it is a very difficult problem since we have TC members on all continents.


I will try to make sure your inputs are reflected in the minutes.




From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
Sent: Thursday, June 05, 2008 3:45 AM
To: Drummond Reed
Cc: 'XRI TC'
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:

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
    Dial In Number: 571-434-5750
    Conference ID: 5474
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

This depends on how long W3C want to take for dialogue. Perhaps 6 months?

        b) What level of changes in the specs do we anticipate making first?

For Syntax:

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.

For Resolution:

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.

        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.)

        d) What other adoption avenues do we want to pursue in that period?

Make a compelling beta apps and deploy them to appeal to the general public for its utility.

        e) What non-normative materials do we want to produce in that

- XRI benefits on OpenID
- Solving Zooko
- Non-HTTP usage of XRI
- XRI deployment made easy
- Real World Case Studies


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?

At least, IMHO it should 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.)

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.

This is a good idea. Especially for "No" voters to collect what they did not like about XRI.
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.

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:

To me, what TAG was concerned technically has always been a bit vague.
I am +1 to http://lists.w3.org/Archives/Public/www-tag/2008Jun/0008 by Marty.

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:
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

Licensing thing is a fact. Neutrality is about the interpretation. Fact is fact. To state the fact, neutrality is not necessary.
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. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]