Subject: [ogpx] issue : naming of capabilities in OGP

From: Infinity Linden <[email-masked]>
Date: Fri, 29 May 2009 13:59:20 -0700

hey peeps... just thought i would try to kick off a couple technical
discussions...

so... if you look at the auth spec (
http://tools.ietf.org/html/draft-hamrick-ogp-auth-00 ), you'll note
that the client application is supposed to tell the agent domain what
capabilities (caps) it wants. this assumes the client application
knows the cap names and how to interact with the system hosting the
cap. (we _could_ get into a discussion about service discovery here,
but i'm hoping to limit the discussion on this thread to just the
naming issue.)

currently, capability names are descriptive strings (like
"place/avatar" and so forth.) There is a recommendation that we use
URIs of the following format as cap names:

"standard" capabilities defined by OGP should be identified as a URN
in the format:
  URN:OGP:<capability name> ("urn:ogp:/avatar/place" or
"urn:ogp:/eventqueue/get")

private extensions might be identified by URNs like:
 URN:OGP:<authority>/<capability name>
("urn:ogp:org.opensimulator/chatsession/create" or even
"urn:ogp:org.example/avatar/place")

so... to define it a little more formally with EBNF, you could say
that the OGP URN looks like:

ogpurn = 'URN:OGP:' , [ authority ]  , capname ;
capname = { fragment } ;
fragment = '/'  , { alphanumeric } ;
alphanumeric = alpha | digit ;
alphabetic character = "A" | "B" | "C" | "D" | "E" | "F" | "G"
                    | "H" | "I" | "J" | "K" | "L" | "M" | "N"
                    | "O" | "P" | "Q" | "R" | "S" | "T" | "U"
                    | "V" | "W" | "X" | "Y" | "Z" |
                      "a" | "b" | "c" | "d" | "e" | "f" | "g"
                    | "h" | "i" | "j" | "k" | "l" | "m" | "n"
                    | "o" | "p" | "q" | "r" | "s" | "t" | "u"
                    | "v" | "w" | "x" | "y" | "z" ;
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;

(also... insert the appropriate EBNF description of a fqdn for
authority (i'm too lazy to copy it.)

and if you wanted to get wild and conflate the name of the cap with
the location of a resource about the cap, you would use a traditonal
RFC2616 / 2817 http / https url like
("http://example.org/capabilities/avatar/place")

the development for this recommendation is...

* i made the recommendation that since peeps might want to create
extensions to OGP (in fact, OGP is expected to have extensions if for
no other reason than we can test capabilities before they're codified
in an rfc.) i was exposed to the java way of naming classes which is
to start the name of your class as the reverse of each element in your
organization's FQDN. So.. I recommended something like
"com.lindenlab.extension.foo" for linden-specific extensions
"com.ibm.extension.bar" for IBM specific extensions, etc.

* this left open the question of how do we denote standard cap names
that are defined in the spec. putting them under "com.lindenlab" is
inappropriate because OGP is a community effort. and doing the java
thing of putting standard caps under "ogp." is probably bad 'cause
ICANN is going to start allowing peeps to register arbitrary TLDs any
day now; creating a spec that requires SOMEONE to partner with a
registry so we can control the ogp.* namespace to prevent name
collisions is a plan fraught with peril.

* plus... John has an interest in using URLs as opaque cap identifiers.

and the solution that came out of it was using a URN.

this would require us to approach IANA and get a URN NID for OGP which
is a non-zero amount of work.

also... the way i've defined it, we're limiting cap names to ASCII
characters which may be inappropriate in an international world.

-comments?
-questions?

-cheers!
-meadhbh

---

From: Larry Masinter <[email-masked]>
Date: Sun, 31 May 2009 12:38:48 -0700

> ("http://example.org/capabilities/avatar/place")

Personally I'm pretty neutral, but I know lots of people who
would claim that using the URI of a resource about the capability
as the name of the capability as an important element of 
web architecture, i.e., that it isn't "wild" but it is expected.

The main thing that isn't clear is what the namespace denotes,
though, and why any of the other existing capability namespaces
aren't adequate.

If the capabilities are about "world location", for example,
or "presence information" about someone/someone's avatar's
"location", why the namespace of geographic locations aren't
used instead, etc. etc.

Larry
--
http://larry.masinter.net

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Infinity Linden
Sent: Friday, May 29, 2009 1:59 PM
To: [email-masked]
Subject: [ogpx] issue : naming of capabilities in OGP

-comments?
-questions?

-cheers!
-meadhbh
_______________________________________________
ogpx mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ogpx

---

From: Infinity Linden <[email-masked]>
Date: Sun, 31 May 2009 22:03:12 -0700

> though, and why any of the other existing capability namespaces

the existing namespace is a collection of names that sort of "evolved"
during the OGP beta last year. things like "place/avatar" and
"remove/avatar." so the idea of having the URN is that it lets the
community define standard capability names while letting individual
deployers define new services or new revisions of existing services.

for example, let's say we defined a named capability that was used by
the client to signal the agent domain to begin the process of rezzing
an avatar somewhere. we might want to call it
"urn:ogp:/agent/avatar/place". this would be distinct from the
capability the agent domain requests from the region domain to place
the avatar, which might be called "urn:ogp:/region/avatar/place".
Someone at example.com might have an idea for how to improve this
process, and might define a named capability called
"urn:ogp:example.com/region/avatar/place". For the system to function
properly, we just need to make sure distinct capability names are...
well... distinct. this format (should) make it much more clear what's
going on when people are debugging the protocol stream. like someone
might look at the stream as part of debugging and go... "oh! now i
understand why this isn't working, it's cause we're asking the region
for the _regular_ avatar/place cap, not the example.com avatar/place
cap!!!"

it also allows two organizations: we'll call them example.net and
example.com to both create their own named capabilities for their own
experiments or custom protocols. and again... the purpose of the
distinct capability names is so the client may ask for distinct
capabilities that support distinct interaction semantics. if a server
provides both a standard capability AND a custom capability, it's
signaling the client that it supports both protocol flows.

> "location", why the namespace of geographic locations aren't

named capabilities denote a function, not a location. so you might
have something like "urn:ogp:/location/find" to request a capability
from a region domain that allows a client application to search for a
location "in world." So the caps namespace isn't the  same as the
namespace of public protocol endpoints, but rather a simple
identifier. In OGP, you request named capabilities after
authentication / authorization. So if you wanted to have each location
in the virtual world be addressable as a named capability, you would
end up having to relog every time you wanted to find information about
a new location.

hmm.. rereading the section of the auth spec or the intro/requirements
doc, it's not especially clear how named capabilities are to be used.
lemme try to post some more about that on the list this week. maybe we
could refine the discussion and find an succinct answer to the
question "what kind of services are requested with named
capabilities?"

-cheers
-meadhbh