[ogpx] issue : naming of capabilities in OGP

[Infinity Linden <[e-mail]>]

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