Bill's input on messaging pattern (was: Agenda: XDI TC TeleconThursday 1

Subject: Bill's input on messaging pattern (was: Agenda: XDI TC TeleconThursday 1-2:30PM PT 2011-04-14)

On Thu, Apr 14, 2011 at 8:47 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

Nice work, I appreciate you folded in my ideas of having the request id and from into the authority segment. I read through the use case and there's a lot there so what follows are initial thoughts:

.. the “from” address, @!9999!8888, mixes the namespaces of orgs and abstract XRI identifiers. I've always kept them separate and I've seen a trend recently to mix them.

@!9999 is a simlified version of an organizational i-number (the real ones are sixteen hex digits, but that's too long to type for examples). !8888 is a community i-number. The composition of a community i-number under a global i-number follows rules for XRI 2.0 architecture that have not changed at all in XRI 3.0 architecture (except deprecation of ! as a global context symbol). See the XRI 3.0 spec at http://www.oasis-open.org/committees/download.php/35972/xri-syntax-3.0-wd03.pdf.

I propose that we go back to the following namespace model: @ i-names for orgs, = i-names for agents or classes of agents, $ i-names as XDI defined special authorities, + i-names as synonyms (for example I can decide that on a particular system +search is @alpha+search or @beta+search), and ! i-numbers as underlying XRI identifiers. For example if @alpha is assigned i-number !9999!8888 then the from could be !9999!8888 or @alpha, but not @!9999!8888.

There's a misunderstanding here. The i-number for a global organizational i-name like @alpha is a ! number in the @ space, i.e., @!9999 (again, the real thing is 16 hex digits as specified in http://gss.xdi.org/moin.cgi/FrontPage?action=AttachFile&do=view&target=gss-v1.0.pdf.

.. While I know you guys are sharing this in the spirit of the OASIS IPR, it's not being done by the letter of it. The stuff on the Gluu Openxdi wiki is under a CC license, except as otherwise noted. If these use cases are, as I surmise, intended as Gluu contributions to the OASIS TC then let's get them on the OASIS XDI wiki so no one can question anything relating to IPR when the spec comes up for vote.

Bill, I agree with your overall point that OASIS TC work belongs on an OASIS TC wiki. But XDI implementation projects, which do not always involve XDI TC members, cannot all be forced to use the XDI TC wiki. The examples being created on the OpenXDI wiki are just that -- examples, based on docs that are on the OASIS servers. I think we should encourage that, not try to dampen it.

Anything that is an actual contribution to the XDI TC should of course go on XDI TC servers. But all these patterns being discussed are already in the XDI Graph Patterns and XDI Statements documents that I have been uploading to Kavi regularly each week.

.. the data schema minimum form (which means its treated as text/plain literal) is data:,some_text_not_needing_escaping_here. You've got what look like some spaces and a missing comma in one of the examples.

Good catch, those should be fixed.

.. I strongly think msg shouldn't be a dollar-word but a +-word, +msg

I'll explain why I disagree on today's call. In short, any semantics at the "grammar" or "protocol" level of XDI should be specified as $ words by the XDI TC. The + space is like Wikipedia -- we don't control it, nobody does, it's consensual.

The semantics of $msg are critical from a protocol semantics standpoint.

.. Given the to address going in the authority the first statement of the request now seems unnecessary

Let's discuss on the call. As soon as you have an XDI message that goes to multiple authorities (like sending an email to multiple recipients), the XDI endpoint that receives it needs to know how to deliver it to all recipients (if you don't transmit it all p2p).

.. I'd also suggest adding at the onset a signature of the explicit graph in the message, for example a SHA-1 using secret expressed in XDI as @alpha+msg(@beta)/+secret/DECAFEBADBEEF

Yes, signatures should be in the graph -- we have left them out so far for simplicity.

.. I suggest numbering request identifiers so they are unique between the two endpoints.

That's what the $msg i-number is for, i.e., $msg!1234. Since the message is unique to the sender, i.e., @!9999!8888$msg!1234, that is the unique message ID.

.. The !1 tail segment in the object of the third statement of the first request (@!9999!8888$msg!1234$do/$get/@!1111!2222!1) seems to give special meaning to the i-number !1 as the profile. It's more characters but I'd suggest using an i-name and restricts to an aspect of their profile, perhaps in the context of an @ or = i-name. For example. I particularly like the idea of using delegation to an @+ i-name to indicate community context, for example @+school, or =+ to indicate individual context: =+student.

See above. The !1 is an i-number for a persona. You can give the persona any number of i-names and any number of +types as you want. It's the same as +tel in the Complex Properties graph in XDI Graph Patterns.

.. I originally suggested the to address, from, and message id should be in the message's root context identifier. Given this and the above comments the request message goes from:
@!9999!8888$msg!1234/$()/(@!1111!2222) @!9999!8888$msg!1234/$d!/(data:,2011-04-10T22:22:22Z) @!9999!8888$msg!1234$do/$get/@!1111!2222!1
to:
=alpha+msg(=beta)!1234/$s+SHA1!/(data:,1595f3f64133856fafa7d7a3720291445d76ccae) =alpha+msg(=beta)!1234/$d!/(data:,2011-04-10T22:22:22Z) =alpha+msg(=beta)!1234$do/$get/=beta=+student
English: For alpha's 1234th msg to beta, with a SHA-1 sig of 1595f3f64133856fafa7d7a3720291445d76ccae, on date 2011-04-10, at 22:22:22 zulu time, do a get for sub graph =beta=+student, which is =beta's profile as a student.

Let's discuss on the call, in light of my other comments above.

It's 12:59PT, so I'm sending this now and dialing in.

Best,

=Drummond

From: drummond.reed@gmail.com [mailto:drummond.reed@gmail.com] On Behalf Of Drummond Reed
Sent: Thursday, April 14, 2011 4:56 AM
To: OASIS - XDI TC
Subject: [xdi] Agenda: XDI TC Telecon Thursday 1-2:30PM PT 2011-04-14

Following is the agenda for the unofficial telecon of the XDI TC at:

Date: Thursday, 14 April 2011 USA
Time: 1:00PM - 2:30PM Pacific Time (20:00-21:30 UTC)

PLEASE DIAL ONE OF THE FOLLOWING NUMBERS:

1) Skype Number: +9900827047990866
(this will connect you directly to the conference room)

2) US/Canada Toll Number: +1-201-793-9022 7990866#

3) International Toll Number (follow this with the Conference Room Number:
7990866#)
Austria (0820 401 15470)
Belgium (0703 57 134)
France (0826 109 071)
Germany (0180 500 9527)
Ireland (0818 270 968)
Spain (902 885 791)
Switzerland (0848 560 397)
United Kingdom/Northern Ireland (0870 0990 931)

THE GOTOMEETING FOR TODAY IS:
   https://www2.gotomeeting.com/join/969244355

THE IDEARPAD LINK FOR TODAY IS:
http://xdi.idearpad.org/28

Please try to preface each of your comments with your name so the
transcription into the minutes is easier.

AGENDA

1) REVISED XDI GRAPH PATTERN DOCUMENT AND CORRESPONDING XDI STATEMENT DOCUMENTS

A new version (2011-04-12) of the XDI Graph Patterns document together with a second document, XDI Statements for XDI Graph Patterns have been uploaded. Unfortunately, it looks like the OASIS Kavi PDF bug is back, so I am again attaching the two files instead of linking them.

The changes in this version were to the Link contract and Messaging patterns to reflect a simpler approach to $do structures -- see topic #3 below.

2) PRIMARY/SECONDARY ADDRESSING PATTERN (SYNONYMS)

Giovanni posted a response about this topic at:

http://lists.oasis-open.org/archives/xdi/201104/msg00010.html

3) XDI MESSAGING PATTERN

Drummond, Mike, and Yuriy from the OpenXDI Project have spent time on this over the past week. The OpenXDI wiki has a page showing the first examples at:

http://openxdi-wiki.gluu.info/doku.php?id=usecases:poken-high4

4) NEXT CALL

Drummond has several upcoming conflicts -- we'll discuss the call schedule for the next few weeks.

------------
ONGOING ISSUES LIST

Each of these is a candidate for the agenda for future calls.

* TRANSACTIONAL INTEGRITY FOR XDI (added 2011-03-24)

Since versioning, as one example, involves multiple transactions that must be commited as a group, we will need to address transactional integrity. Specifically, we need to define how this will be handled at the protocol level, vs. the implementation level.

* PROPOSED CONSTRUCTS/OPERATORS FOR XDI

Discuss the following wiki page originally posted by Giovanni:

http://wiki.oasis-open.org/xdi/XdiNewFoundation

* DICTIONARY STRUCTURE

Mike would like an example of the PDX dictionary as soon as we can do it.

*   EQUIVALENCE SEMANTICS

Close on whether we need an additional $ word that is the equivalent
of Higgins Personal Data Model (PDM) semantics   of h:correlation,
which is not as strong as $is.

      http://lists.oasis-open.org/archives/xdi/201006/msg00036.html

* COOL URIS

Continue previous discussion about the use of standard RDF URIs in XDI:

http://lists.oasis-open.org/archives/xdi/201006/msg00023.html

xdi message