Second Life Wiki - User contributions [en]

Open Grid Public Beta

2010-02-12T01:55:09Z

Infinity Linden:

{{Alert Box| The vaak grid is currently unavailable as we transition from OGP based services to VWRAP based services. }}

{{Alert Box| Please read [[Open_Grid_Public_Beta#30-Sept-2008_Update|Sept-30-2008]]. We are no longer accepting requests to join the beta program at this time.}}

{{Alert Box| Please use the [[User:Pixel_Gausman/Interop_Viewer|trunk builds of Snowglobe if you wish to connect to an agent domain and use OGP teleport]].}}

The Open Grid Public Beta program is a Linden Lab sponsored opportunity for developers to make their virtual worlds interoperate with Second Life. Virtual world interoperability is enabled through the [[Open Grid Protocol]], under development by the [[AWG | Architecture Working Group]] of Second Life residents.

On June 30th, 2008, a group of Linden Lab and IBM "gridnauts" [http://torley.s3.amazonaws.com/Across-the-Metaverse.mp4 successfully launched from a Second Life developer grid and teleported over to an OpenSim grid running IBM's modified code]. They arrived without any of their attachments or inventory, since the protocol does not transfer assets between grids. Zero Linden of Linden Lab and Zha Ewry of IBM [http://www.metanomics.net/show/archive030308/ recently gave an interview] on the Metanomics Second Life TV show to introduce the project.

==30-Sept-2008 Update==

{{Alert Box|This has been a successful couple of months:

* Working OGP teleports between Linden Lab's regions and OpenSim regions running in both grid and standalone mode
* Over 100 residents teleporting between OGP-enabled OpenSims and Linden Lab regions.
* Resolved 36 OGP-related JIRAs
* Released and implemented a new draft of the OGP teleport specification

Many thanks to the OpenSim developers for their help.

So next steps:

* We are no longer accepting requests to add residents to the Open Grid Public Beta at this time
* We will continue resolving JIRAs opened against the Beta Agent and Region domains
* We will continue running our agent domain and OGP-enabled regions
* The gridnauts list and inworld group will continue to be available

As the Open Protocol team prepares for the next steps in Grid Interoperability, I would like to get your input.

I've opened a new meta-issue, JIRA https://jira.secondlife.com/browse/SVC-3156, for recommending next steps. Read the related JIRAs and vote for the ones you would like to see implemented in a future beta. If you don't see the idea you want to see implemented, then create a JIRA for it and link it as a child of the meta-issue. Use JIRA comments to discuss or detail proposals.}}

==Key Points ==

# Testing the ability to log in to Second Life and teleport between Second Life and other virtual worlds.
# Intended for developers, not residents at large.
# Demonstrates login and teleport only, no assets are transferred from Second Life to other virtual worlds.

==Participation==

Participation in the Open Grid Public Beta program is intended for the developers of virtual world viewer and simulator software.

Developers in the program implement the [[Open Grid Protocol]] in their software. The protocol provides a communication path between clients (Second Life Viewer), an [[Agent Domain]] (Second Life preview grid), and a simulator (Second Life, OpenSim). In particular, they implement the [[SLGOGP_Teleport_Strawman | teleport]] protocol.

Beta participants will have access to the Open Grid Protocol version of the Second Life viewer, which logs you into an agent domain running on the Second Life preview grid, and allows you to rez, without inventory, on a destination grid that understands the Open Grid Protocol.

In the first phase of the program Linden Lab will work with the developers of [http://www.opensimulator.org OpenSim] and OpenSim operators to login to our preview grid and teleport between the Second Life preview grid, and regions in OpenSim.

In the second phase of the beta, Linden Lab will open participation to other grid and virtual world operators and developers.

This beta is for adult residents of Second Life. We are currently exploring options for participation by TSL residents. TSL residents may now sign up to the email list (adult moderated, see below). Teens will be invited to join a TSL Gridnauts group which will be used to communicate details on the forthcoming teen beta.

==How To Participate==

{{:Warning|We are no longer accepting requests to join the beta at this time.}}

# [[Open_Grid_Public_Beta/Map_Locations|Claim a space on the map for your OpenSim region]].
# [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Download the Open Grid Beta Viewer]].
# [[Open_Grid_Public_Beta/Open_Sim_OGP_How_To|Build an OpenSim region with OGP enabled]].
# [[Open_Grid_Public_Beta/Teleport_How_To|Use the Open Grid Client to Teleport between Region Domains]]

Because the Beta will allow any external regions to connect to the grid, which may or may not provide adult content, the beta was limited to main grid users.

There is [[Open_Grid_Public_Beta/Public_Regions|a list of public OpenSim regions]] participating in the beta.

==In World Meetings==
* None scheduled at this time.
===Transcripts===
* [[:Category:Open_Grid_Public_Beta_Transcripts|All relevant transcripts]]
* July:
** Office Hours: [[User:Whump_Linden/Office_Hours/Transcript_20080723|23]] [[User:Whump_Linden/Office_Hours/Transcript_20080730|30]]
** Huddle transcripts
* August:
** Office Hours: [[User:Whump_Linden/Office_Hours/Transcript_20080806|06]] [[User:Whump_Linden/Office_Hours/Transcript_20080813|13]] [[User:Whump_Linden/Office_Hours/Transcript_20080820|20]]
** Huddle transcripts: [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080805|05]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080806|06]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080808|08]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080812|12]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080815|15]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080818|18]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080829|29]]
* September
** Office Hours: [[User:Whump_Linden/Office_Hours/Transcript_20080910|10]] [[User:Whump_Linden/Office_Hours/Transcript_20080917|17]]
** Huddle Transcripts: [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080912|12]] [[Open_Grid_Public_Beta/Daily_Huddle_Transcripts/Transcript_20080915|15]]
* October
** Office Hours: [[User:Whump_Linden/Office_Hours/Transcript_20081008|08]] [[User:Whump_Linden/Office_Hours/Transcript_20081029|29]]
* November:
** Office Hours: [[User:Whump_Linden/Office_Hours/Transcript_20081112|12]]
* December:
** Office Hours: [[User:Whump_Linden/Office_Hours/Transcript_20081203|3]]

===IRC===

irc://irc.freenode.net/#gridnauts

==Issue Tracking During the Beta Program==

Linden Lab has created new components in PJIRA to track OGPB issues, please read [[Open_Grid_Public_Beta/Issue_Tracking|the instructions on how to create OGPB issues in PJIRA]].

Status of OGPB issues will be reviewed during daily huddles.

A complete list of beta issues is in the umbrella issue {{Jira|SVC-2632}}.

==Beta Timeline==

* Beta launch -- July 31, 2008
* Interop testing with OpenSim (Phase 1) -- July 31, 2008
* [[Open_Grid_Public_Beta/Changes_20080822|Viewer, AD and RD Update 1]] --- August 22, 2008
* [[Open_Grid_Protocol|OGP Draft 3]] --- September 10, 2008
* Open to other virtual world platforms (Phase 2) -- TBD
* Beta period ends -- TBD

==FAQ==

See [[Open_Grid_Public_Beta/FAQ|Open Grid Public Beta FAQ]]

==Resources==

* Wiki pages
** Open Grid Protocol
*** [[Open Grid Protocol| Open Grid Protocol]] -- introduction
*** [[Agent Domain]]
*** [[Login Protocol]]
*** [[SLGOGP_Teleport_Strawman | Teleport Protcol]]
**[[AWG | Architecture Working Group]]
*** [[AW_Groupies | In-world discussion group]] -- for programmers and technically minded citizens
*** [[:Category:Grid_Interoperability_Chat_Logs|Relevant in-world discussion and office hours transcripts]]
*** [[Pyogp| Pyogp -- Python-based OGP test harness and client library]]
**** [[:Category:Pyogp_Transcripts|Pyogp discussion transcripts]]

* [http://www.opensimulator.org OpenSim]
** [http://opensimulator.org/wiki/Special:Search?search=chat+log OpenSim transcripts]

[[Category:Grid Interoperability]]
[[Category:Open_Grid_Public_Beta]]

Land

2010-02-12T01:53:34Z

Infinity Linden: /* Grid {{anchor|Main Grid}} */

{{Help|LandSim=*}}
{{otheruses4|Land|scripting ([[LSL]]) related articles|:Category:LSL Region}}

This article is supposed to give an overview about land in Second Life, going from the smallest to the largest scale.

[[File:Land-hierarchy.jpg|800px]]

== Parcel ==
{{RightToc}}
An area of land owned by a single user or group, which is at least 16m² and at maximum 65,536m², all within one [[#Region|region]]. Parcels are composed of square blocks measuring 4×4 meters, but the blocks do not have to be contiguous. Parcels have both an integer local id and a global [[UUID]]. Parcel settings are modifiable in the [[Video_Tutorial/Land/About_Land_options|About Land]] options.

== Region{{anchor|Sim}} ==
A named 256m x 256m (65,536 m²) area hosted by a single [[Sim|simulator process (sim)]]. In common usage, the term "simulator" or "sim" may also refer to a region, but in fact a single server process can host mulitple regions. They can be flagged as [[Region Flags|PG, Mature, or Adult]].

There are currently three types of regions: ''Full'', ''Homestead'' and ''Openspace'' (also known as ''Void''). All have the same size, but differ in their avatar-, and primitive limits, as well as in their price. See [[Linden_Lab_Official:Private Region Types|Private Region Types]] for official info and [[Private Region]] for general FAQ.

=== Full Region ===
There are two full regions per server host CPU. A region can hold up to 100 avatars and 15,000 [[prim]]s.
=== Homestead ===
Homestead regions were introduced in January 2009 and are only available for Residents who own at least one full region. It can hold 20 avatars, 3750 prims and the amount of running scripts might be restricted in the future.
<ul style="-moz-column-count:2; -webkit-column-count:2; column-count:2;">
*[[Linden_Lab_Official:About Homesteads|About Homesteads]]
*[[Linden_Lab_Official:Homestead FAQ|Homestead FAQ]]
</ul>
=== Openspace ===
Openspaces are, like Homesteads, only available for Residents who own at least one full Region. They support a maximum of 10 avatars and 750 prims.
<ul style="-moz-column-count:2; -webkit-column-count:2; column-count:2;">
*[[Linden_Lab_Official:Information about Openspaces (Void Regions)|Information about Openspaces (Void Regions)]].
*[[Linden_Lab_Official:Openspaces FAQ|Openspaces FAQ]]
</ul>

== Estate ==
A collection of regions with a particular shared set of rules, such as banned users, sun position, etc. Estates have integer identifiers. Read also [[Linden_Lab_Official:Estate FAQ|Estate FAQ]].
=== Mainland ===
The largest masses of non-island linked simulators in the Second Life grid that refer to Linden-designed continents. The “mainland” is estate ID 1 and owned by {{User2|Governor Linden}}. Residents with a [[Premium Account|premium account]] can buy mainland parcels and need to pay a monthly tier when their land exceeds 512m². See [http://secondlife.com/whatis/landpricing.php landpricing info]. A mainland region supports a maximum of 40 avatars.

=== Private Estate ===
Private estates are collections of Resident owned Regions. Some of these Residents are renting their land, so also Basic Account holders can use land this way.
See [[Estate Management]] and [[Private Estate Management Companies]] to learn more.
== Grid {{anchor|Main Grid}}==
{|
|valign="top"|In Second Life, a grid refers to an integrated system that provides a networked collection of servers, some of which are simulators that implement the presentation of land. Those are arranged in the form of a rectangular mesh. In addition, the SL grid provides a set of other services, including presence, inventory management, and asset store, that integrate with but are independent of the simulators.<ref>Read the discussion [http://groups.google.com/group/sldev/browse_thread/thread/afe59484a71e3830 What is a Grid?] on the [[SLDev]] mailing list for further information.</ref>

Linden Lab runs several grids for internal and external testing. Asset transfer and teleporting from the main grid (Agni) to another are currently not possible, but might become a feature in the future, when the [[Open Grid Protocol]] evolves.

Contrary to common belief (and what the wording implies), the [[Teen Grid]] and ''Main Grid'' differ only via their estates IDs and are on the same Grid (Agni), rather than different Grids.

Linden Lab's Grids are named after Hindu gods. Many of the Grids supported by the client are either inaccessible to the public or no longer active. To change the Grid you'd like to connect to, press {{KeyCombo|shift=*|ctrl=*|G}} on the login screen of your viewer and choose the grid from the drop-down menu.

Linden Lab obtaines a [[grid status|grid status report]] about the stability of the grid.

<references />
=== Agni ===
The primary Second Life grid to which users connect; named after the Vedic god of Fire, mentioned in the four Vedas.

Some [[:Category:Images of Agni|images of the Agni grid]] are available in this wiki.

{{ClientUpdate|Agni}}

=== Aditi ===
The beta test grid available to Residents for testing the Second Life server software before it's deployed to the main grid (Agni); named after the Vedic mother goddess, cosmic creatrix. Read more about Aditi in the [[Preview Grid|preview Grid article]].

{{ClientUpdate|Aditi}}

'''See also:'''
* [[Preview Grid Common Questions]]
* [http://secondlife.com/support/downloads.php http://secondlife.com/support/downloads.php]

=== Vaak ===
Vaak is a grid used to test interoperability with the [http://tools.ietf.org/wg/vwrap/charters Virtual World Region Agent Protocol (VWRAP)] family of specifications. VWRAP is the successor to the [[Open Grid Protocol]] and is being standardized under the auspices of the [http://ietf.org/ Internet Engineering Task Force (IETF)]. With the successful completion of the [[Open Grid Public Beta]], vaak is currently being rebuilt to adhere to the more recent VWRAP specifications. A public demonstration of a Second Life grid utilizing the VWRAP protocols is expected, but currently unscheduled. Interested persons are encouraged to watch the official [https://blogs.secondlife.com/index.jspa Second Life Blog] for news and announcements regarding VWRAP and the Vaak grid.

Linden Research thanks all [[Gridnaut|Gridnauts]] who participated in the [[Open Grid Public Beta]]. Without your interest, patience, hard work and bug reporting, we would not have been successful.

=== Uma ===
Uma is a [[Test Grid|test grid]] but has been reported to be now unavailable for the public.

|valign="top"|
{| class="sortable" {{Prettytable}}
|- {{Hl2}}
!!| Name !! class="unsortable" | Grid Type !! class="unsortable" | Hinduism
|-
|| Agni || Main || God of Fire
|-
|| Siva || Preview || Destroyer of the Universe
|-
|| Durga || Preview ||
|-
|| [[Aditi]] || Preview || Vedic: Mother Goddess
|-
|| Soma || [[QA Portal|QA]] || A Lunar Deity<br>Vedic: Drink of the Gods
|-
|| Ganga || [[QA Portal|QA]] ||
|-
|| Uma || ||
|-
|| Shakti || ||
|-
|| Vaak || VWRAP Interop Testing ||
|-
|| Mohini || ||
|-
|| Yami || ||
|-
|| Nandi || ||
|-
|| Mitra || ||
|-
|| Radha || ||
|-
|| Ravi || ||
|-
|| Aruna || ||
|-
|| Damballah || ||
|-
|| Bharati || ||
|-
|| Chandra || ||
|-
|| Danu || ||
|-
|| Parvati || ||
|-
|| Skanda || ||
|}
|}

== Related Articles ==
*[[:Category:Help/Land|Wiki articles about land]]
*[[Video_Tutorials/More#LAND|Video tutorials about land]]
*[[:Category:Land|Knowledge Base articles about land]]

Land

2010-02-12T01:48:24Z

Infinity Linden: /* Vaak */

{{Help|LandSim=*}}
{{otheruses4|Land|scripting ([[LSL]]) related articles|:Category:LSL Region}}

This article is supposed to give an overview about land in Second Life, going from the smallest to the largest scale.

[[File:Land-hierarchy.jpg|800px]]

== Parcel ==
{{RightToc}}
An area of land owned by a single user or group, which is at least 16m² and at maximum 65,536m², all within one [[#Region|region]]. Parcels are composed of square blocks measuring 4×4 meters, but the blocks do not have to be contiguous. Parcels have both an integer local id and a global [[UUID]]. Parcel settings are modifiable in the [[Video_Tutorial/Land/About_Land_options|About Land]] options.

== Region{{anchor|Sim}} ==
A named 256m x 256m (65,536 m²) area hosted by a single [[Sim|simulator process (sim)]]. In common usage, the term "simulator" or "sim" may also refer to a region, but in fact a single server process can host mulitple regions. They can be flagged as [[Region Flags|PG, Mature, or Adult]].

There are currently three types of regions: ''Full'', ''Homestead'' and ''Openspace'' (also known as ''Void''). All have the same size, but differ in their avatar-, and primitive limits, as well as in their price. See [[Linden_Lab_Official:Private Region Types|Private Region Types]] for official info and [[Private Region]] for general FAQ.

=== Full Region ===
There are two full regions per server host CPU. A region can hold up to 100 avatars and 15,000 [[prim]]s.
=== Homestead ===
Homestead regions were introduced in January 2009 and are only available for Residents who own at least one full region. It can hold 20 avatars, 3750 prims and the amount of running scripts might be restricted in the future.
<ul style="-moz-column-count:2; -webkit-column-count:2; column-count:2;">
*[[Linden_Lab_Official:About Homesteads|About Homesteads]]
*[[Linden_Lab_Official:Homestead FAQ|Homestead FAQ]]
</ul>
=== Openspace ===
Openspaces are, like Homesteads, only available for Residents who own at least one full Region. They support a maximum of 10 avatars and 750 prims.
<ul style="-moz-column-count:2; -webkit-column-count:2; column-count:2;">
*[[Linden_Lab_Official:Information about Openspaces (Void Regions)|Information about Openspaces (Void Regions)]].
*[[Linden_Lab_Official:Openspaces FAQ|Openspaces FAQ]]
</ul>

== Estate ==
A collection of regions with a particular shared set of rules, such as banned users, sun position, etc. Estates have integer identifiers. Read also [[Linden_Lab_Official:Estate FAQ|Estate FAQ]].
=== Mainland ===
The largest masses of non-island linked simulators in the Second Life grid that refer to Linden-designed continents. The “mainland” is estate ID 1 and owned by {{User2|Governor Linden}}. Residents with a [[Premium Account|premium account]] can buy mainland parcels and need to pay a monthly tier when their land exceeds 512m². See [http://secondlife.com/whatis/landpricing.php landpricing info]. A mainland region supports a maximum of 40 avatars.

=== Private Estate ===
Private estates are collections of Resident owned Regions. Some of these Residents are renting their land, so also Basic Account holders can use land this way.
See [[Estate Management]] and [[Private Estate Management Companies]] to learn more.
== Grid {{anchor|Main Grid}}==
{|
|valign="top"|In Second Life, a grid refers to an integrated system that provides a networked collection of servers, some of which are simulators that implement the presentation of land. Those are arranged in the form of a rectangular mesh. In addition, the SL grid provides a set of other services, including presence, inventory management, and asset store, that integrate with but are independent of the simulators.<ref>Read the discussion [http://groups.google.com/group/sldev/browse_thread/thread/afe59484a71e3830 What is a Grid?] on the [[SLDev]] mailing list for further information.</ref>

Linden Lab runs several grids for internal and external testing. Asset transfer and teleporting from the main grid (Agni) to another are currently not possible, but might become a feature in the future, when the [[Open Grid Protocol]] evolves.

Contrary to common belief (and what the wording implies), the [[Teen Grid]] and ''Main Grid'' differ only via their estates IDs and are on the same Grid (Agni), rather than different Grids.

Linden Lab's Grids are named after Hindu gods. Many of the Grids supported by the client are either inaccessible to the public or no longer active. To change the Grid you'd like to connect to, press {{KeyCombo|shift=*|ctrl=*|G}} on the login screen of your viewer and choose the grid from the drop-down menu.

Linden Lab obtaines a [[grid status|grid status report]] about the stability of the grid.

<references />
=== Agni ===
The primary Second Life grid to which users connect; named after the Vedic god of Fire, mentioned in the four Vedas.

Some [[:Category:Images of Agni|images of the Agni grid]] are available in this wiki.

{{ClientUpdate|Agni}}

=== Aditi ===
The beta test grid available to Residents for testing the Second Life server software before it's deployed to the main grid (Agni); named after the Vedic mother goddess, cosmic creatrix. Read more about Aditi in the [[Preview Grid|preview Grid article]].

{{ClientUpdate|Aditi}}

'''See also:'''
* [[Preview Grid Common Questions]]
* [http://secondlife.com/support/downloads.php http://secondlife.com/support/downloads.php]

=== Vaak ===
Vaak is a grid used to test interoperability with the [http://tools.ietf.org/wg/vwrap/charters Virtual World Region Agent Protocol (VWRAP)] family of specifications. VWRAP is the successor to the [[Open Grid Protocol]] and is being standardized under the auspices of the [http://ietf.org/ Internet Engineering Task Force (IETF)]. With the successful completion of the [[Open Grid Public Beta]], vaak is currently being rebuilt to adhere to the more recent VWRAP specifications. A public demonstration of a Second Life grid utilizing the VWRAP protocols is expected, but currently unscheduled. Interested persons are encouraged to watch the official [https://blogs.secondlife.com/index.jspa Second Life Blog] for news and announcements regarding VWRAP and the Vaak grid.

Linden Research thanks all [[Gridnaut|Gridnauts]] who participated in the [[Open Grid Public Beta]]. Without your interest, patience, hard work and bug reporting, we would not have been successful.

=== Uma ===
Uma is a [[Test Grid|test grid]] but has been reported to be now unavailable for the public.

|valign="top"|
{| class="sortable" {{Prettytable}}
|- {{Hl2}}
!!| Name !! class="unsortable" | Grid Type !! class="unsortable" | Hinduism
|-
|| Agni || Main || God of Fire
|-
|| Siva || Preview || Destroyer of the Universe
|-
|| Durga || Preview ||
|-
|| [[Aditi]] || Preview || Vedic: Mother Goddess
|-
|| Soma || [[QA Portal|QA]] || A Lunar Deity<br>Vedic: Drink of the Gods
|-
|| Ganga || [[QA Portal|QA]] ||
|-
|| Uma || ||
|-
|| Shakti || ||
|-
|| Vaak || [[Open_Grid_Protocol|OGP]] ||
|-
|| Mohini || ||
|-
|| Yami || ||
|-
|| Nandi || ||
|-
|| Mitra || ||
|-
|| Radha || ||
|-
|| Ravi || ||
|-
|| Aruna || ||
|-
|| Damballah || ||
|-
|| Bharati || ||
|-
|| Chandra || ||
|-
|| Danu || ||
|-
|| Parvati || ||
|-
|| Skanda || ||
|}
|}

== Related Articles ==
*[[:Category:Help/Land|Wiki articles about land]]
*[[Video_Tutorials/More#LAND|Video tutorials about land]]
*[[:Category:Land|Knowledge Base articles about land]]

Open Grid Public Beta/Public Regions

2009-10-07T02:56:10Z

Infinity Linden: /* Linden Lab OGP Regions */

The following OpenSim regions supporting the Open Grid protocol are available for you to teleport to once you've authenticated to the agent domain:

This is value you enter into the region URL dialog on the login screen and the World >> Teleport Region command.

== Linden Lab OGP Regions ==

* https://sim1.vaak.lindenlab.com:12043/cap/8f3bac3d-062c-0950-d0b0-62dd065bc5e8 for Bonifacio
* https://sim2.vaak.lindenlab.com:12043/cap/b1e4a4c9-2845-6d66-e04c-2e8f5d9ce9de for Ahern
* https://sim2.vaak.lindenlab.com:12043/cap/a960de83-fde8-e681-e307-c280842bd811 for Grignano
* https://sim2.vaak.lindenlab.com:12043/cap/901ad78d-c34b-d5f6-20ed-a1439d733c10 for Dore
* https://sim2.vaak.lindenlab.com:12043/cap/529528d6-e66e-ccce-2535-fe3061fe7f06 for Miramare

== Ugotrade ==

* http://ugotrade.net:9000
* 24/7 if it is down I will restart
* Contact: Tara5 Oh

== COM.lounge / Tao Takashi / mrtopf.de ==

* http://plonetv.de:9000
* currently offline due to awaiting new patch
* Contact: [http://mrtopf.de/blog Tao Takashi]

== BlueWall ==

* http://ascent.bluewallgroup.com:9900/BlueWall%20Isle
* http://ascent.bluewallgroup.com:9900/Bay%20Side
* http://ascent.bluewallgroup.com:9910/BlueWall%20Gateway ''Hypergrid gateway to OSGrid''
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:BlueWall Slade | Bluewall Slade]]
* E-Mail: [mailto://BlueWall.Slade@gmail.com BlueWall Slade]

== SimlandMax ==

* Region URL: http://simland.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:creator Luna]]

== Elsewhere ==

* Region URL: http://opensim.nowherevirtual.com:9000
* Times Available: 24/7 (except for maintenance)
* Contact: [[User:Emma Nowhere | Emma Nowhere ]]
* E-Mail: [mailto://emma.nowhere@gmail.com Emma Nowhere]

== LJPOGP00 ==

* http://98.26.97.209:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:Julie Wasserstrom | Julie Wasserstrom]]
* E-Mail: [mailto://Julie.Wasserstrom@gmail.com Julie Wasserstrom]

== Luskwood ==

* http://opengrid.luskwood.net:9000
* 24/7, Not built out yet though.
* Contact [[User:Michi Lumin | Michi Lumin]]
* E-Mail: [mailto://michi@luskwood.org Michi Lumin]

== Akina ==
* http://213.186.37.135:9000
* 24/7 except for maint and upgrades
* Contact: [[User:EloiseJolie Capalini|EloiseJolie Capalini]]
* Email [mailto://artana34@gmail.com Artana]

== Planck and Kaku ==

* Region URL: http://opensim.vworlds.co.uk:9000
* Times Available: 0:800 23:00 UTC 24/7 when new server is ready
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== Dirac, Fermi, Bohr and Pauli ==

* Region URL: http://mainland.vworlds.co.uk:9000/
* Times Available: 24/7
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== BrackenLand ==

* http://
* Temporarily offline
* Contact: [[User:Gomez Bracken | Gomez Bracken]]
* E-Mail: [mailto://gomez@temptations-club.com Gomez Bracken]

== Piper ==

* Region URL: http://primforge.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [http://primforge.com/ Torrid Luna]

== Zinnemann Grid ==

* Region URL: http://zinnemanngrid.com:9000
* [http://www.zinnemann.com/grid.asp Zinnemann Grid Webpage]
* Contact: [[User:Hans Zinnemann | Hans Zinnemann]]

== Lakewood / Ducatillon Group Project ==

* http://dgpexperimental.selfip.org:9000
* 24/7 - might be unavailable for short periods as far as we update/maintain the location
* Contact: [[User:McCoy Ducatillon | McCoy Ducatillon]]
* E-Mail: [mailto://ducatillongroup@gmail.com McCoy Ducatillon]

== Burning Life Test Open Sim ==

* Region URL: http://68.178.191.56:9000
* Times Available: 24/7 (Unless Under Update)
* Contact: [[User:Vicero Lambert | Vicero Lambert ]]
* E-Mail: [mailto://jakekukuk@gmail.com Vicero Lambert]

== Litesim Mainland ==

* http://lsmainland.ogs-openuser.litesim.com:8000/ogp_listen
* 24/7 - occasional issues
* Contact: [[User:Gareth Ellison | Gareth Nelson]]
* E-Mail: [mailto://gareth@litesim.com Gareth Nelson]
* About 10 regions on the grid
* Can also now do TP into other random (non-OGP) grids and tested with OSGrid and central grid

== Gridrock Worlds ==
* closed for the next few months
* Blog info: http://www.in2orbit.net
* E-Mail: [mailto://whyroc@in2orbit.net whyroc Slade]

== Douggles Hangout ==
* Region URL http://club-panty.com:9000
* 24/7 uptime
* Contact bonghit Schism_External
* Email [mailto:pantera.42069@yahoo.com]

== Pixelpark ==
* Region URL http://pixelpark.servegame.org:9000
* online ('''updated''' to OpenSim 0.6 as of 11/14/08 on Amazon EC2)
* Contact [[User:Bartholomew Kleiber | Bartholomew Kleiber ]]
* Email [mailto://dirk.krause@pixelpark.com Dirk Krause]

== Five Miles Out ==
* Region URL http://taurus.fivemile.org:9000
* 24/7 uptime 1 Gbps
* Contact [[User:Jim Kupferberg | Jim Kupferberg ]]
* Email [mailto:info@fivemile.net Jim Kupferberg]

== Whichway From Here ==
* Region URL http://ae6vk.harpsichordyet.com:9000
* 09:00-22:00 SLT, but down at my whim.
* Contact [[User:Whichway Janus | Whichway Janus ]]
* Email [mailto:Whichway.Janus@Yahoo.Com Whichway Janus]

== Dahlia Island ==
* Region URL http://thnk1.dyndns.org:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Dahlia Trimble | Dahlia Trimble]]
* Email [mailto:dahliaTrimble@gmail.com Dahlia Trimble]

== 3Di OGP Test ==
* Region URL http://210.188.235.138:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Kish Kas | Kish Kas]]

== Bit Island ==
* Region URL http://mark.bitlife.jp:9000
* 24/7 uptime
* Contact [[User:Bit2zero Planer | Bit2zero Planer]]

== metaXLR8 ==
* Region URL http://metaxlr8.com:9000
* Uptime 24/7, down only for testing and updating
* See http://metafuturing.net/index.php/MetaXLR8_OpenSim
* Contact: Giulio Perhaps

== La Isla West ==
* http://24.30.54.84:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:m0rdred Veil | m0rdred Veil]]
* E-Mail: [mailto://m0rdredveil@yahoo.com m0rdred Veil]

== AUGrid-OGP Norgan ==
* http://66.197.247.222:9005 http://ogp.augrid.org:9005
* http://ogp.augrid.org:9005/OGP%20Plaza - OGP Plaza
* http://ogp.augrid.org:9005/nortopia - Nortopia
* http://ogp.augrid.org:9005/augrid.org%20ogp - Augrid.org OGP
* http://ogp.augrid.org:9005/jodyville - JodyVille
* http://ogp.augrid.org:9005/66.197.247.222 - Test Numerical Sim name
* All regions are on AUGrid.org and Beta Grid
* Online 24/7 - Info and custom objects with land shaped like Aust. more info http://www.augrid.org
* Contact: [[User:Norgan Torok|Norgan Torok]]
* E-Mail: [mailto://contact@augrid.org Norgan Torok (SL)/Norgan Crazys (AUGrid)]

== Berlinos ==
* 1. Region URL: http://testgrid.de:9000/berlinos
* 2. Region URL: http://testgrid.de:9000/berlinos2
* 24/7 uptime
* Contact: [[User:Easyfresh Auer]]
* E-Mail: [mailto://easyfresh.auer@easyfresh-auer.de Easyfresh Auer]

== Bulli's Land ==
* Region URL: http://83.247.63.174:9000
* Up as much as possible
* Contact: [[User:Bulli Schumann]]
* E-Mail: [mailto://bulli.schumann@gmail.com Bulli Schumann]

== GCSE ==
* Region URL: http://gcse.ath.cx:9300
* 24/7 uptime (unless NAT loopback fails)
* Contact: [[User:Herfulnerful Holsworthy]]
* E-Mail: [mailto://herfulnerful@charter.net Herfulnerful Holsworthy]

== Radioactive World ==
* Region URL: '''http://ct1aic.dyndns.org:9000'''
* Up as much as possible
* Also with 14 SIM's @ OSGRID
* Contact: [[User:Radioactive Rosca]]
* E-Mail: [mailto://radioactive.rosca@gmail.com Radioactive Rosca]

== Bloob box Island ==
* Region URL: http://87.98.134.166:9000
* Up as much as possible
* Contact: [[User:kaly Mayako]]

== Chandra ==
* http://surya.grids.litesim.com:8000/ogp_listen
* 24/7 except for maint and upgrades
* Contact: [[User:Armon Aeon|Armon Aeon]]

== Ciuso Prime ==
*http://128.177.27.217:9000 or http://prime.ciuso.com:9000 - Not available currently!
*intended to be up 24*7 except for maintenance and upgrades
* Contact: [[User:Sered Woollahra|Sered Woollahra]], seredsecondlife at gmail.com

== Lexania ==
* 1. OGP Region URL: http://lexa.ath.cx:9000/Lexania
* 2. OGP Region URL: http://lexa.ath.cx:9000/Lexania2
* Uptime: Quite a lot
* Status: Three trees and a puddle (per region!) :)
* Contact: Sure, why not
* Which one: SL IM: [[User: Lexa Sands|Lexa Sands]]
* Email: I'll get SL IMs via Email when offline

== TicTacToe for Gridnauts ==
* This "opensim" (world) is a test for "minimum requirements". We are using a Dell Latitude D600 notebook having a Intel Centrino 2.0 Ghz, 512 Mb (RAM) and a broadband line having only 256 Kbps (for downloads)/100 Kbps (for uploads).
* 2 avatares can play the tic-tac-toe game clicking cubes, that will rotate.
* http://titactoe.ath.cx:9000/TicTacToe
* Our "opensim" is hooked to OSGrid. Region: TicTacToe.
* If you like to do a test or a demo, please contact me.
* Contact: [[User:Adamascj Aji|Americo Damasceno - Adamascj Aji]]

== Beta Technologies OpenSim (Mini-)Grid ==
* Micro-grid for [http://betatechnologies.info/ Beta Technologies].
* The first four regions are co-located in Phoenix, Arizona (ping times should be about the same as to LL's grids); the last four in Portugal, Europe. The purpose was to test running a common grid distributed among two data centres. Servers are quite different in performance: the European server has much more memory and performance, but the network access is poor. The Arizona regions are on a low-powered server which however boasts excellent connectivity. The experience of going from one to the other is quite intriguing.
* Open for now as we just test things out; some regions might be closed in the future as this Mini-Grid begins to be internally used for our own projects (mostly as a temporary sandbox before transferring content to LL's grid).
* Uptime: ought to be 99.7%, except for upgrades and the odd reconfiguration. Some sims or parcels might be closed as this is being used for some internal testing.
* No support web site for now (users are created manually)
* if you wish to add your region to our Mini-Grid for tests, and don't wish to go through the fuss of creating your set of central servers, you're welcome to do so at this stage. Just contact us!
* Available regions as follows:
** 3650/3650 - Beta Technologies - http://asimov.betatechnologies.info:9000/
** 3650/3651 - Theatron - http://asimov.betatechnologies.info:9001/
** 3651/3650 - Terreiro do Paco - http://asimov.betatechnologies.info:9002/ (lots of content here)
** 3651/3651 - Beta Business Park - http://asimov.betatechnologies.info:9003/
** 3652/3650 - EggVille - http://bradbury.betatechnologies.info:9000/
** 3652/3651 - Beta Sandbox - http://bradbury.betatechnologies.info:9001/
** 7000/7000 - Half Way - http://bradbury.betatechnologies.info:9002/
** 11000/11000 - Far Away - http://bradbury.betatechnologies.info:9003/

These last two are required because this minigrid is Hypergrid-enabled. So to jump across LL's grid and any other Hypergrid, due to the weird 4096-jump-limit, you need to jump to Half Way and later to Far Away and back.

* Contact: [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]]
* E-Mail: [mailto://Gwyneth.Llewelyn@BetaTechnologies.Info Gwyneth Llewelyn]

== eaglefx Binder ==

Sunred Beach Gridnaut

* http://gridnaut.sunredbeach.com:9008
* 24/7 - it may be unavailable for short periods for updates/maintenance
* Contact: [[User:eaglefx Binder | eaglefx Binder]]
* E-Mail: [mailto://eaglefx99@yahoo.com eaglefx Binder]

[[category:Open_Grid_Public_Beta]]

File:VWRAP adult content evaluation example.jpg

2009-10-02T16:05:31Z

Infinity Linden: this is an example of generic policy enforcement in VWRAP, not a proposal for how to actually enforce adult content policies.

this is an example of generic policy enforcement in VWRAP, not a proposal for how to actually enforce adult content policies.

VWRAP Charter

2009-09-01T20:07:52Z

Infinity Linden: Created page with 'Working Group Name: Virtual Worlds Region Agent Protocol (VWRAP) Chairs: TBD Area and Area Directors: Applications Area Lisa Dusseault <lisa.dusseault@gmail.com...'

Working Group Name:

Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

TBD

Area and Area Directors:

Applications Area

Lisa Dusseault <lisa.dusseault@gmail.com>
Alexey Melnikov <alexey.melnikov@isode.com>

Responsible Area Director:

TBD

Mailing List:

ogpx@ietf.org
http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for collaborative 3-dimensional virtual environment. The protocol permits users to interact as digital representations called "avatars". Avatars exist in at most one location within a shared virtual space. Conforming client applications use the protocol to
manipulate and move the user's avatar, create virtual objects, interact with other users and their surroundings, consume
and create media and information from sources inside and outside their simulated environment.

Adjacent points in virtual spaces accessible by this protocol may
be   explicitly   partitioned into   "regions"   to facilitate   the
computational and communication load balancing required to simulate
the virtual environment. Such virtual environments may consist of regions
administered by distinct organizations. Regions provide the service endpoints for interacting with the inhabitants and objects they contain. Regions uniquely represent their partition of the virtual space (that is, they are not a "sharding" mechanism). The
state of a virtual world is independent of the client applications
that access it and may persist between user sessions.

Regions and other services implemented according to the specifications may
be deployed by separate organizations with varying policies and trust
domains. The VWRAP protocol will provide the mechanisms for these
virtual world services to interoperate, when permitted by policy and
shared trust domains. To support the exegesis of the specifications,
the group may define a non-exhaustive set of non-normative policies
protocol participants may enforce.

Foundational components of the protocol include the publication of:

* an abstract type system, suitable for describing the application
    protocol in an implementation neutral manner,

* a   security   model   describing trust   relationships   between
    participating entities,

* guidelines   for   the   use   of existing   authentication   and
    confidentiality mechanisms,

* an application-layer protocol for establishing the user's avatar
    in a region,

* an application-layer protocol for changing an avatar's position, including moving between regions,

* format descriptions for objects and avatars, and

* an   application-layer protocol   for identifying   entities, and
    requesting information about them.

The protocol defined by this group will carry information about the
virtual environment, its contents and its inhabitants. It is an
application layer protocol, independent of transport, based partially
on these previously published internet drafts:

* http://tools.ietf.org/html/draft-hamrick-ogp-intro
* http://tools.ietf.org/html/draft-hamrick-llsd
* http://tools.ietf.org/html/draft-hamrick-ogp-auth
* http://tools.ietf.org/html/draft-hamrick-ogp-launch
* http://tools.ietf.org/html/draft-lentczner-ogp-base
* http://tools.ietf.org/html/draft-levine-ogp-clientcap
* http://tools.ietf.org/html/draft-levine-ogp-layering

The protocol should describe interaction semantics independent of transport, leveraging existing standards where
practical. It should define interoperability expectations for server
to server interactions as well as client-server interactions. Though
the protocol is independent of transport, early interoperability
trials used HTTP(S) for non-real-time messages. The working group will
define specific features that must be replicated in other transports
and will define the use of HTTP(S) as a transport of protocol
messages.

Goals and Milestones:

* October 2009   "Introduction and Goals" to the   IESG as an
    Informational RFC

* October 2009 "Abstract Type System for the Transmission of Dynamic
    Structured Data" to the IESG as Proposed Standard

* October 2010 "Foundational Concepts and Transport Expectations" to
    the IESG as Proposed Standard

* February 2010 "Guidelines for Host Authentication" to the IESG as
    an Informational RFC

* February 2010 "Service Establishment" to the IESG as Proposed
    Standard

* February 2010 "Client Application Launch Message" to the IESG as
    an Informational RFC

* February 2010 "Simulation Presence Establishment" to the IESG as
    Proposed Standard

* June 2010 "Primitive Object Format" to the IESG as Proposed
    Standard

* June 2010 "Digital Asset Access" to the IESG as Proposed Standard

* June 2010 "Entity Identifiers" to the IESG as Proposed standard

File:Activity Flows.png

2009-08-26T19:29:14Z

Infinity Linden: this is a VERY high level diagram showing the relationship of types of actions that occur in an OGP virtual world.

this is a VERY high level diagram showing the relationship of types of actions that occur in an OGP virtual world.

File:OGPX Document Roadmap.png

2009-08-26T19:27:42Z

Infinity Linden: this is a graphical description of the relationship between documents proposed to describe the IETF OGP protocol.

this is a graphical description of the relationship between documents proposed to describe the IETF OGP protocol.

Open Grid Public Beta/Public Regions

2009-08-04T23:00:21Z

Infinity Linden: /* Linden Lab OGP Regions */

The following OpenSim regions supporting the Open Grid protocol are available for you to teleport to once you've authenticated to the agent domain:

This is value you enter into the region URL dialog on the login screen and the World >> Teleport Region command.

== Linden Lab OGP Regions ==

* https://sim1.vaak.lindenlab.com:12043/cap/821cfa62-f4b7-26e2-d373-4c15b84a1de3 for Bethel
* https://sim1.vaak.lindenlab.com:12043/cap/8a8a97b1-0b8d-b5d3-a477-e7044c5b6f3e for Oak Grove
* https://sim1.vaak.lindenlab.com:12043/cap/62c65aa5-748f-62a7-99ab-ca6f16e72965 for Grignano
* https://sim1.vaak.lindenlab.com:12043/cap/7620c3f8-370a-61c2-57c8-12626a1af312 for Pullman

== Ugotrade ==

* http://ugotrade.net:9000
* 24/7 if it is down I will restart
* Contact: Tara5 Oh

== COM.lounge / Tao Takashi / mrtopf.de ==

* http://plonetv.de:9000
* currently offline due to awaiting new patch
* Contact: [http://mrtopf.de/blog Tao Takashi]

== BlueWall ==

* http://ascent.bluewallgroup.com:9900/BlueWall%20Isle
* http://ascent.bluewallgroup.com:9900/Bay%20Side
* http://ascent.bluewallgroup.com:9910/BlueWall%20Gateway ''Hypergrid gateway to OSGrid''
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:BlueWall Slade | Bluewall Slade]]
* E-Mail: [mailto://BlueWall.Slade@gmail.com BlueWall Slade]

== SimlandMax ==

* Region URL: http://simland.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:creator Luna]]

== Elsewhere ==

* Region URL: http://opensim.nowherevirtual.com:9000
* Times Available: 24/7 (except for maintenance)
* Contact: [[User:Emma Nowhere | Emma Nowhere ]]
* E-Mail: [mailto://emma.nowhere@gmail.com Emma Nowhere]

== LJPOGP00 ==

* http://98.26.97.209:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:Julie Wasserstrom | Julie Wasserstrom]]
* E-Mail: [mailto://Julie.Wasserstrom@gmail.com Julie Wasserstrom]

== Luskwood ==

* http://opengrid.luskwood.net:9000
* 24/7, Not built out yet though.
* Contact [[User:Michi Lumin | Michi Lumin]]
* E-Mail: [mailto://michi@luskwood.org Michi Lumin]

== Akina ==
* http://213.186.37.135:9000
* 24/7 except for maint and upgrades
* Contact: [[User:EloiseJolie Capalini|EloiseJolie Capalini]]
* Email [mailto://artana34@gmail.com Artana]

== Planck and Kaku ==

* Region URL: http://opensim.vworlds.co.uk:9000
* Times Available: 0:800 23:00 UTC 24/7 when new server is ready
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== Dirac, Fermi, Bohr and Pauli ==

* Region URL: http://mainland.vworlds.co.uk:9000/
* Times Available: 24/7
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== BrackenLand ==

* http://
* Temporarily offline
* Contact: [[User:Gomez Bracken | Gomez Bracken]]
* E-Mail: [mailto://gomez@temptations-club.com Gomez Bracken]

== Piper ==

* Region URL: http://primforge.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [http://primforge.com/ Torrid Luna]

== Zinnemann Grid ==

* Region URL: http://zinnemanngrid.com:9000
* [http://www.zinnemann.com/grid.asp Zinnemann Grid Webpage]
* Contact: [[User:Hans Zinnemann | Hans Zinnemann]]

== Lakewood / Ducatillon Group Project ==

* http://dgpexperimental.selfip.org:9000
* 24/7 - might be unavailable for short periods as far as we update/maintain the location
* Contact: [[User:McCoy Ducatillon | McCoy Ducatillon]]
* E-Mail: [mailto://ducatillongroup@gmail.com McCoy Ducatillon]

== Burning Life Test Open Sim ==

* Region URL: http://68.178.191.56:9000
* Times Available: 24/7 (Unless Under Update)
* Contact: [[User:Vicero Lambert | Vicero Lambert ]]
* E-Mail: [mailto://jakekukuk@gmail.com Vicero Lambert]

== Litesim Mainland ==

* http://lsmainland.ogs-openuser.litesim.com:8000/ogp_listen
* 24/7 - occasional issues
* Contact: [[User:Gareth Ellison | Gareth Nelson]]
* E-Mail: [mailto://gareth@litesim.com Gareth Nelson]
* About 10 regions on the grid
* Can also now do TP into other random (non-OGP) grids and tested with OSGrid and central grid

== Gridrock Worlds ==
* closed for the next few months
* Blog info: http://www.in2orbit.net
* E-Mail: [mailto://whyroc@in2orbit.net whyroc Slade]

== Douggles Hangout ==
* Region URL http://club-panty.com:9000
* 24/7 uptime
* Contact bonghit Schism_External
* Email [mailto:pantera.42069@yahoo.com]

== Pixelpark ==
* Region URL http://pixelpark.servegame.org:9000
* online ('''updated''' to OpenSim 0.6 as of 11/14/08 on Amazon EC2)
* Contact [[User:Bartholomew Kleiber | Bartholomew Kleiber ]]
* Email [mailto://dirk.krause@pixelpark.com Dirk Krause]

== Five Miles Out ==
* Region URL http://taurus.fivemile.org:9000
* 24/7 uptime 1 Gbps
* Contact [[User:Jim Kupferberg | Jim Kupferberg ]]
* Email [mailto:info@fivemile.net Jim Kupferberg]

== Whichway From Here ==
* Region URL http://ae6vk.harpsichordyet.com:9000
* 09:00-22:00 SLT, but down at my whim.
* Contact [[User:Whichway Janus | Whichway Janus ]]
* Email [mailto:Whichway.Janus@Yahoo.Com Whichway Janus]

== Dahlia Island ==
* Region URL http://thnk1.dyndns.org:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Dahlia Trimble | Dahlia Trimble]]
* Email [mailto:dahliaTrimble@gmail.com Dahlia Trimble]

== 3Di OGP Test ==
* Region URL http://210.188.235.138:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Kish Kas | Kish Kas]]

== Bit Island ==
* Region URL http://mark.bitlife.jp:9000
* 24/7 uptime
* Contact [[User:Bit2zero Planer | Bit2zero Planer]]

== metaXLR8 ==
* Region URL http://metaxlr8.com:9000
* Uptime 24/7, down only for testing and updating
* See http://metafuturing.net/index.php/MetaXLR8_OpenSim
* Contact: Giulio Perhaps

== La Isla West ==
* http://24.30.54.84:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:m0rdred Veil | m0rdred Veil]]
* E-Mail: [mailto://m0rdredveil@yahoo.com m0rdred Veil]

== AUGrid-OGP Norgan ==
* http://66.197.247.222:9005 http://ogp.augrid.org:9005
* http://ogp.augrid.org:9005/OGP%20Plaza - OGP Plaza
* http://ogp.augrid.org:9005/nortopia - Nortopia
* http://ogp.augrid.org:9005/augrid.org%20ogp - Augrid.org OGP
* http://ogp.augrid.org:9005/jodyville - JodyVille
* http://ogp.augrid.org:9005/66.197.247.222 - Test Numerical Sim name
* All regions are on AUGrid.org and Beta Grid
* Online 24/7 - Info and custom objects with land shaped like Aust. more info http://www.augrid.org
* Contact: [[User:Norgan Torok|Norgan Torok]]
* E-Mail: [mailto://contact@augrid.org Norgan Torok (SL)/Norgan Crazys (AUGrid)]

== Berlinos ==
* 1. Region URL: http://testgrid.de:9000/berlinos
* 2. Region URL: http://testgrid.de:9000/berlinos2
* 24/7 uptime
* Contact: [[User:Easyfresh Auer]]
* E-Mail: [mailto://easyfresh.auer@easyfresh-auer.de Easyfresh Auer]

== Bulli's Land ==
* Region URL: http://83.247.63.174:9000
* Up as much as possible
* Contact: [[User:Bulli Schumann]]
* E-Mail: [mailto://bulli.schumann@gmail.com Bulli Schumann]

== GCSE ==
* Region URL: http://gcse.ath.cx:9300
* 24/7 uptime (unless NAT loopback fails)
* Contact: [[User:Herfulnerful Holsworthy]]
* E-Mail: [mailto://herfulnerful@charter.net Herfulnerful Holsworthy]

== Radioactive World ==
* Region URL: '''http://ct1aic.dyndns.org:9000'''
* Up as much as possible
* Also with 14 SIM's @ OSGRID
* Contact: [[User:Radioactive Rosca]]
* E-Mail: [mailto://radioactive.rosca@gmail.com Radioactive Rosca]

== Bloob box Island ==
* Region URL: http://87.98.134.166:9000
* Up as much as possible
* Contact: [[User:kaly Mayako]]

== Chandra ==
* http://surya.grids.litesim.com:8000/ogp_listen
* 24/7 except for maint and upgrades
* Contact: [[User:Armon Aeon|Armon Aeon]]

== Ciuso Prime ==
*http://128.177.27.217:9000 or http://prime.ciuso.com:9000 - Not available currently!
*intended to be up 24*7 except for maintenance and upgrades
* Contact: [[User:Sered Woollahra|Sered Woollahra]], seredsecondlife at gmail.com

== Lexania ==
* 1. OGP Region URL: http://lexa.ath.cx:9000/Lexania
* 2. OGP Region URL: http://lexa.ath.cx:9000/Lexania2
* Uptime: Quite a lot
* Status: Three trees and a puddle (per region!) :)
* Contact: Sure, why not
* Which one: SL IM: [[User: Lexa Sands|Lexa Sands]]
* Email: I'll get SL IMs via Email when offline

==Kurai's OpenSims==
*http://zeitenwerk.de:9128
*Uptime: 24/7 - 100 Mbits
*Contact: [[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]

== TicTacToe for Gridnauts ==
* This "opensim" (world) is a test for "minimum requirements". We are using a Dell Latitude D600 notebook having a Intel Centrino 2.0 Ghz, 512 Mb (RAM) and a broadband line having only 256 Kbps (for downloads)/100 Kbps (for uploads).
* 2 avatares can play the tic-tac-toe game clicking cubes, that will rotate.
* http://titactoe.ath.cx:9000/TicTacToe
* Our "opensim" is hooked to OSGrid. Region: TicTacToe.
* If you like to do a test or a demo, please contact me.
* Contact: [[User:Adamascj Aji|Americo Damasceno - Adamascj Aji]]

== Beta Technologies OpenSim (Mini-)Grid ==
* Micro-grid for [http://betatechnologies.info/ Beta Technologies].
* The first four regions are co-located in Phoenix, Arizona (ping times should be about the same as to LL's grids); the last four in Portugal, Europe. The purpose was to test running a common grid distributed among two data centres. Servers are quite different in performance: the European server has much more memory and performance, but the network access is poor. The Arizona regions are on a low-powered server which however boasts excellent connectivity. The experience of going from one to the other is quite intriguing.
* Open for now as we just test things out; some regions might be closed in the future as this Mini-Grid begins to be internally used for our own projects (mostly as a temporary sandbox before transferring content to LL's grid).
* Uptime: ought to be 99.7%, except for upgrades and the odd reconfiguration. Some sims or parcels might be closed as this is being used for some internal testing.
* No support web site for now (users are created manually)
* if you wish to add your region to our Mini-Grid for tests, and don't wish to go through the fuss of creating your set of central servers, you're welcome to do so at this stage. Just contact us!
* Available regions as follows:
** 3650/3650 - Beta Technologies - http://asimov.betatechnologies.info:9000/
** 3650/3651 - Theatron - http://asimov.betatechnologies.info:9001/
** 3651/3650 - Terreiro do Paco - http://asimov.betatechnologies.info:9002/ (lots of content here)
** 3651/3651 - Beta Business Park - http://asimov.betatechnologies.info:9003/
** 3652/3650 - EggVille - http://bradbury.betatechnologies.info:9000/
** 3652/3651 - Beta Sandbox - http://bradbury.betatechnologies.info:9001/
** 7000/7000 - Half Way - http://bradbury.betatechnologies.info:9002/
** 11000/11000 - Far Away - http://bradbury.betatechnologies.info:9003/

These last two are required because this minigrid is Hypergrid-enabled. So to jump across LL's grid and any other Hypergrid, due to the weird 4096-jump-limit, you need to jump to Half Way and later to Far Away and back.

* Contact: [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]]
* E-Mail: [mailto://Gwyneth.Llewelyn@BetaTechnologies.Info Gwyneth Llewelyn]

== eaglefx Binder ==

Sunred Beach Gridnaut

* http://gridnaut.sunredbeach.com:9008
* 24/7 - it may be unavailable for short periods for updates/maintenance
* Contact: [[User:eaglefx Binder | eaglefx Binder]]
* E-Mail: [mailto://eaglefx99@yahoo.com eaglefx Binder]

[[category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Public Regions

2009-08-04T22:56:06Z

Infinity Linden: /* Linden Lab OGP Regions */

The following OpenSim regions supporting the Open Grid protocol are available for you to teleport to once you've authenticated to the agent domain:

This is value you enter into the region URL dialog on the login screen and the World >> Teleport Region command.

== Linden Lab OGP Regions ==

* https://sim1.vaak.lindenlab.com:12043/cap/821cfa62-f4b7-26e2-d373-4c15b84a1de3 for Bethel
* https://sim1.vaak.lindenlab.com:12043/cap/60fd89a9-c9ea-3967-0225-6f10018a5cef for Oak Grove
* https://sim1.vaak.lindenlab.com:12043/cap/62c65aa5-748f-62a7-99ab-ca6f16e72965 for Grignano
* https://sim1.vaak.lindenlab.com:12043/cap/7620c3f8-370a-61c2-57c8-12626a1af312 for Pullman

== Ugotrade ==

* http://ugotrade.net:9000
* 24/7 if it is down I will restart
* Contact: Tara5 Oh

== COM.lounge / Tao Takashi / mrtopf.de ==

* http://plonetv.de:9000
* currently offline due to awaiting new patch
* Contact: [http://mrtopf.de/blog Tao Takashi]

== BlueWall ==

* http://ascent.bluewallgroup.com:9900/BlueWall%20Isle
* http://ascent.bluewallgroup.com:9900/Bay%20Side
* http://ascent.bluewallgroup.com:9910/BlueWall%20Gateway ''Hypergrid gateway to OSGrid''
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:BlueWall Slade | Bluewall Slade]]
* E-Mail: [mailto://BlueWall.Slade@gmail.com BlueWall Slade]

== SimlandMax ==

* Region URL: http://simland.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:creator Luna]]

== Elsewhere ==

* Region URL: http://opensim.nowherevirtual.com:9000
* Times Available: 24/7 (except for maintenance)
* Contact: [[User:Emma Nowhere | Emma Nowhere ]]
* E-Mail: [mailto://emma.nowhere@gmail.com Emma Nowhere]

== LJPOGP00 ==

* http://98.26.97.209:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:Julie Wasserstrom | Julie Wasserstrom]]
* E-Mail: [mailto://Julie.Wasserstrom@gmail.com Julie Wasserstrom]

== Luskwood ==

* http://opengrid.luskwood.net:9000
* 24/7, Not built out yet though.
* Contact [[User:Michi Lumin | Michi Lumin]]
* E-Mail: [mailto://michi@luskwood.org Michi Lumin]

== Akina ==
* http://213.186.37.135:9000
* 24/7 except for maint and upgrades
* Contact: [[User:EloiseJolie Capalini|EloiseJolie Capalini]]
* Email [mailto://artana34@gmail.com Artana]

== Planck and Kaku ==

* Region URL: http://opensim.vworlds.co.uk:9000
* Times Available: 0:800 23:00 UTC 24/7 when new server is ready
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== Dirac, Fermi, Bohr and Pauli ==

* Region URL: http://mainland.vworlds.co.uk:9000/
* Times Available: 24/7
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== BrackenLand ==

* http://
* Temporarily offline
* Contact: [[User:Gomez Bracken | Gomez Bracken]]
* E-Mail: [mailto://gomez@temptations-club.com Gomez Bracken]

== Piper ==

* Region URL: http://primforge.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [http://primforge.com/ Torrid Luna]

== Zinnemann Grid ==

* Region URL: http://zinnemanngrid.com:9000
* [http://www.zinnemann.com/grid.asp Zinnemann Grid Webpage]
* Contact: [[User:Hans Zinnemann | Hans Zinnemann]]

== Lakewood / Ducatillon Group Project ==

* http://dgpexperimental.selfip.org:9000
* 24/7 - might be unavailable for short periods as far as we update/maintain the location
* Contact: [[User:McCoy Ducatillon | McCoy Ducatillon]]
* E-Mail: [mailto://ducatillongroup@gmail.com McCoy Ducatillon]

== Burning Life Test Open Sim ==

* Region URL: http://68.178.191.56:9000
* Times Available: 24/7 (Unless Under Update)
* Contact: [[User:Vicero Lambert | Vicero Lambert ]]
* E-Mail: [mailto://jakekukuk@gmail.com Vicero Lambert]

== Litesim Mainland ==

* http://lsmainland.ogs-openuser.litesim.com:8000/ogp_listen
* 24/7 - occasional issues
* Contact: [[User:Gareth Ellison | Gareth Nelson]]
* E-Mail: [mailto://gareth@litesim.com Gareth Nelson]
* About 10 regions on the grid
* Can also now do TP into other random (non-OGP) grids and tested with OSGrid and central grid

== Gridrock Worlds ==
* closed for the next few months
* Blog info: http://www.in2orbit.net
* E-Mail: [mailto://whyroc@in2orbit.net whyroc Slade]

== Douggles Hangout ==
* Region URL http://club-panty.com:9000
* 24/7 uptime
* Contact bonghit Schism_External
* Email [mailto:pantera.42069@yahoo.com]

== Pixelpark ==
* Region URL http://pixelpark.servegame.org:9000
* online ('''updated''' to OpenSim 0.6 as of 11/14/08 on Amazon EC2)
* Contact [[User:Bartholomew Kleiber | Bartholomew Kleiber ]]
* Email [mailto://dirk.krause@pixelpark.com Dirk Krause]

== Five Miles Out ==
* Region URL http://taurus.fivemile.org:9000
* 24/7 uptime 1 Gbps
* Contact [[User:Jim Kupferberg | Jim Kupferberg ]]
* Email [mailto:info@fivemile.net Jim Kupferberg]

== Whichway From Here ==
* Region URL http://ae6vk.harpsichordyet.com:9000
* 09:00-22:00 SLT, but down at my whim.
* Contact [[User:Whichway Janus | Whichway Janus ]]
* Email [mailto:Whichway.Janus@Yahoo.Com Whichway Janus]

== Dahlia Island ==
* Region URL http://thnk1.dyndns.org:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Dahlia Trimble | Dahlia Trimble]]
* Email [mailto:dahliaTrimble@gmail.com Dahlia Trimble]

== 3Di OGP Test ==
* Region URL http://210.188.235.138:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Kish Kas | Kish Kas]]

== Bit Island ==
* Region URL http://mark.bitlife.jp:9000
* 24/7 uptime
* Contact [[User:Bit2zero Planer | Bit2zero Planer]]

== metaXLR8 ==
* Region URL http://metaxlr8.com:9000
* Uptime 24/7, down only for testing and updating
* See http://metafuturing.net/index.php/MetaXLR8_OpenSim
* Contact: Giulio Perhaps

== La Isla West ==
* http://24.30.54.84:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:m0rdred Veil | m0rdred Veil]]
* E-Mail: [mailto://m0rdredveil@yahoo.com m0rdred Veil]

== AUGrid-OGP Norgan ==
* http://66.197.247.222:9005 http://ogp.augrid.org:9005
* http://ogp.augrid.org:9005/OGP%20Plaza - OGP Plaza
* http://ogp.augrid.org:9005/nortopia - Nortopia
* http://ogp.augrid.org:9005/augrid.org%20ogp - Augrid.org OGP
* http://ogp.augrid.org:9005/jodyville - JodyVille
* http://ogp.augrid.org:9005/66.197.247.222 - Test Numerical Sim name
* All regions are on AUGrid.org and Beta Grid
* Online 24/7 - Info and custom objects with land shaped like Aust. more info http://www.augrid.org
* Contact: [[User:Norgan Torok|Norgan Torok]]
* E-Mail: [mailto://contact@augrid.org Norgan Torok (SL)/Norgan Crazys (AUGrid)]

== Berlinos ==
* 1. Region URL: http://testgrid.de:9000/berlinos
* 2. Region URL: http://testgrid.de:9000/berlinos2
* 24/7 uptime
* Contact: [[User:Easyfresh Auer]]
* E-Mail: [mailto://easyfresh.auer@easyfresh-auer.de Easyfresh Auer]

== Bulli's Land ==
* Region URL: http://83.247.63.174:9000
* Up as much as possible
* Contact: [[User:Bulli Schumann]]
* E-Mail: [mailto://bulli.schumann@gmail.com Bulli Schumann]

== GCSE ==
* Region URL: http://gcse.ath.cx:9300
* 24/7 uptime (unless NAT loopback fails)
* Contact: [[User:Herfulnerful Holsworthy]]
* E-Mail: [mailto://herfulnerful@charter.net Herfulnerful Holsworthy]

== Radioactive World ==
* Region URL: '''http://ct1aic.dyndns.org:9000'''
* Up as much as possible
* Also with 14 SIM's @ OSGRID
* Contact: [[User:Radioactive Rosca]]
* E-Mail: [mailto://radioactive.rosca@gmail.com Radioactive Rosca]

== Bloob box Island ==
* Region URL: http://87.98.134.166:9000
* Up as much as possible
* Contact: [[User:kaly Mayako]]

== Chandra ==
* http://surya.grids.litesim.com:8000/ogp_listen
* 24/7 except for maint and upgrades
* Contact: [[User:Armon Aeon|Armon Aeon]]

== Ciuso Prime ==
*http://128.177.27.217:9000 or http://prime.ciuso.com:9000 - Not available currently!
*intended to be up 24*7 except for maintenance and upgrades
* Contact: [[User:Sered Woollahra|Sered Woollahra]], seredsecondlife at gmail.com

== Lexania ==
* 1. OGP Region URL: http://lexa.ath.cx:9000/Lexania
* 2. OGP Region URL: http://lexa.ath.cx:9000/Lexania2
* Uptime: Quite a lot
* Status: Three trees and a puddle (per region!) :)
* Contact: Sure, why not
* Which one: SL IM: [[User: Lexa Sands|Lexa Sands]]
* Email: I'll get SL IMs via Email when offline

==Kurai's OpenSims==
*http://zeitenwerk.de:9128
*Uptime: 24/7 - 100 Mbits
*Contact: [[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]

== TicTacToe for Gridnauts ==
* This "opensim" (world) is a test for "minimum requirements". We are using a Dell Latitude D600 notebook having a Intel Centrino 2.0 Ghz, 512 Mb (RAM) and a broadband line having only 256 Kbps (for downloads)/100 Kbps (for uploads).
* 2 avatares can play the tic-tac-toe game clicking cubes, that will rotate.
* http://titactoe.ath.cx:9000/TicTacToe
* Our "opensim" is hooked to OSGrid. Region: TicTacToe.
* If you like to do a test or a demo, please contact me.
* Contact: [[User:Adamascj Aji|Americo Damasceno - Adamascj Aji]]

== Beta Technologies OpenSim (Mini-)Grid ==
* Micro-grid for [http://betatechnologies.info/ Beta Technologies].
* The first four regions are co-located in Phoenix, Arizona (ping times should be about the same as to LL's grids); the last four in Portugal, Europe. The purpose was to test running a common grid distributed among two data centres. Servers are quite different in performance: the European server has much more memory and performance, but the network access is poor. The Arizona regions are on a low-powered server which however boasts excellent connectivity. The experience of going from one to the other is quite intriguing.
* Open for now as we just test things out; some regions might be closed in the future as this Mini-Grid begins to be internally used for our own projects (mostly as a temporary sandbox before transferring content to LL's grid).
* Uptime: ought to be 99.7%, except for upgrades and the odd reconfiguration. Some sims or parcels might be closed as this is being used for some internal testing.
* No support web site for now (users are created manually)
* if you wish to add your region to our Mini-Grid for tests, and don't wish to go through the fuss of creating your set of central servers, you're welcome to do so at this stage. Just contact us!
* Available regions as follows:
** 3650/3650 - Beta Technologies - http://asimov.betatechnologies.info:9000/
** 3650/3651 - Theatron - http://asimov.betatechnologies.info:9001/
** 3651/3650 - Terreiro do Paco - http://asimov.betatechnologies.info:9002/ (lots of content here)
** 3651/3651 - Beta Business Park - http://asimov.betatechnologies.info:9003/
** 3652/3650 - EggVille - http://bradbury.betatechnologies.info:9000/
** 3652/3651 - Beta Sandbox - http://bradbury.betatechnologies.info:9001/
** 7000/7000 - Half Way - http://bradbury.betatechnologies.info:9002/
** 11000/11000 - Far Away - http://bradbury.betatechnologies.info:9003/

These last two are required because this minigrid is Hypergrid-enabled. So to jump across LL's grid and any other Hypergrid, due to the weird 4096-jump-limit, you need to jump to Half Way and later to Far Away and back.

* Contact: [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]]
* E-Mail: [mailto://Gwyneth.Llewelyn@BetaTechnologies.Info Gwyneth Llewelyn]

== eaglefx Binder ==

Sunred Beach Gridnaut

* http://gridnaut.sunredbeach.com:9008
* 24/7 - it may be unavailable for short periods for updates/maintenance
* Contact: [[User:eaglefx Binder | eaglefx Binder]]
* E-Mail: [mailto://eaglefx99@yahoo.com eaglefx Binder]

[[category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Public Regions

2009-08-04T21:32:59Z

Infinity Linden: /* Linden Lab OGP Regions */

The following OpenSim regions supporting the Open Grid protocol are available for you to teleport to once you've authenticated to the agent domain:

This is value you enter into the region URL dialog on the login screen and the World >> Teleport Region command.

== Linden Lab OGP Regions ==

* https://sim1.vaak.lindenlab.com:12043/cap/821cfa62-f4b7-26e2-d373-4c15b84a1de3 for Bethel
* https://sim1.vaak.lindenlab.com:12043/cap/60fd89a9-c9ea-3967-0225-6f10018a5cef for Oak Grove
* https://sim1.vaak.lindenlab.com:12043/cap/8246e5ad-e8bb-7e1b-b3df-b737aa4e2f63 for Grignano
* https://sim1.vaak.lindenlab.com:12043/cap/daa40bda-5a00-6055-98f4-ef3b753114b5 for Pullman

== Ugotrade ==

* http://ugotrade.net:9000
* 24/7 if it is down I will restart
* Contact: Tara5 Oh

== COM.lounge / Tao Takashi / mrtopf.de ==

* http://plonetv.de:9000
* currently offline due to awaiting new patch
* Contact: [http://mrtopf.de/blog Tao Takashi]

== BlueWall ==

* http://ascent.bluewallgroup.com:9900/BlueWall%20Isle
* http://ascent.bluewallgroup.com:9900/Bay%20Side
* http://ascent.bluewallgroup.com:9910/BlueWall%20Gateway ''Hypergrid gateway to OSGrid''
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:BlueWall Slade | Bluewall Slade]]
* E-Mail: [mailto://BlueWall.Slade@gmail.com BlueWall Slade]

== SimlandMax ==

* Region URL: http://simland.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:creator Luna]]

== Elsewhere ==

* Region URL: http://opensim.nowherevirtual.com:9000
* Times Available: 24/7 (except for maintenance)
* Contact: [[User:Emma Nowhere | Emma Nowhere ]]
* E-Mail: [mailto://emma.nowhere@gmail.com Emma Nowhere]

== LJPOGP00 ==

* http://98.26.97.209:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:Julie Wasserstrom | Julie Wasserstrom]]
* E-Mail: [mailto://Julie.Wasserstrom@gmail.com Julie Wasserstrom]

== Luskwood ==

* http://opengrid.luskwood.net:9000
* 24/7, Not built out yet though.
* Contact [[User:Michi Lumin | Michi Lumin]]
* E-Mail: [mailto://michi@luskwood.org Michi Lumin]

== Akina ==
* http://213.186.37.135:9000
* 24/7 except for maint and upgrades
* Contact: [[User:EloiseJolie Capalini|EloiseJolie Capalini]]
* Email [mailto://artana34@gmail.com Artana]

== Planck and Kaku ==

* Region URL: http://opensim.vworlds.co.uk:9000
* Times Available: 0:800 23:00 UTC 24/7 when new server is ready
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== Dirac, Fermi, Bohr and Pauli ==

* Region URL: http://mainland.vworlds.co.uk:9000/
* Times Available: 24/7
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== BrackenLand ==

* http://
* Temporarily offline
* Contact: [[User:Gomez Bracken | Gomez Bracken]]
* E-Mail: [mailto://gomez@temptations-club.com Gomez Bracken]

== Piper ==

* Region URL: http://primforge.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [http://primforge.com/ Torrid Luna]

== Zinnemann Grid ==

* Region URL: http://zinnemanngrid.com:9000
* [http://www.zinnemann.com/grid.asp Zinnemann Grid Webpage]
* Contact: [[User:Hans Zinnemann | Hans Zinnemann]]

== Lakewood / Ducatillon Group Project ==

* http://dgpexperimental.selfip.org:9000
* 24/7 - might be unavailable for short periods as far as we update/maintain the location
* Contact: [[User:McCoy Ducatillon | McCoy Ducatillon]]
* E-Mail: [mailto://ducatillongroup@gmail.com McCoy Ducatillon]

== Burning Life Test Open Sim ==

* Region URL: http://68.178.191.56:9000
* Times Available: 24/7 (Unless Under Update)
* Contact: [[User:Vicero Lambert | Vicero Lambert ]]
* E-Mail: [mailto://jakekukuk@gmail.com Vicero Lambert]

== Litesim Mainland ==

* http://lsmainland.ogs-openuser.litesim.com:8000/ogp_listen
* 24/7 - occasional issues
* Contact: [[User:Gareth Ellison | Gareth Nelson]]
* E-Mail: [mailto://gareth@litesim.com Gareth Nelson]
* About 10 regions on the grid
* Can also now do TP into other random (non-OGP) grids and tested with OSGrid and central grid

== Gridrock Worlds ==
* closed for the next few months
* Blog info: http://www.in2orbit.net
* E-Mail: [mailto://whyroc@in2orbit.net whyroc Slade]

== Douggles Hangout ==
* Region URL http://club-panty.com:9000
* 24/7 uptime
* Contact bonghit Schism_External
* Email [mailto:pantera.42069@yahoo.com]

== Pixelpark ==
* Region URL http://pixelpark.servegame.org:9000
* online ('''updated''' to OpenSim 0.6 as of 11/14/08 on Amazon EC2)
* Contact [[User:Bartholomew Kleiber | Bartholomew Kleiber ]]
* Email [mailto://dirk.krause@pixelpark.com Dirk Krause]

== Five Miles Out ==
* Region URL http://taurus.fivemile.org:9000
* 24/7 uptime 1 Gbps
* Contact [[User:Jim Kupferberg | Jim Kupferberg ]]
* Email [mailto:info@fivemile.net Jim Kupferberg]

== Whichway From Here ==
* Region URL http://ae6vk.harpsichordyet.com:9000
* 09:00-22:00 SLT, but down at my whim.
* Contact [[User:Whichway Janus | Whichway Janus ]]
* Email [mailto:Whichway.Janus@Yahoo.Com Whichway Janus]

== Dahlia Island ==
* Region URL http://thnk1.dyndns.org:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Dahlia Trimble | Dahlia Trimble]]
* Email [mailto:dahliaTrimble@gmail.com Dahlia Trimble]

== 3Di OGP Test ==
* Region URL http://210.188.235.138:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Kish Kas | Kish Kas]]

== Bit Island ==
* Region URL http://mark.bitlife.jp:9000
* 24/7 uptime
* Contact [[User:Bit2zero Planer | Bit2zero Planer]]

== metaXLR8 ==
* Region URL http://metaxlr8.com:9000
* Uptime 24/7, down only for testing and updating
* See http://metafuturing.net/index.php/MetaXLR8_OpenSim
* Contact: Giulio Perhaps

== La Isla West ==
* http://24.30.54.84:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:m0rdred Veil | m0rdred Veil]]
* E-Mail: [mailto://m0rdredveil@yahoo.com m0rdred Veil]

== AUGrid-OGP Norgan ==
* http://66.197.247.222:9005 http://ogp.augrid.org:9005
* http://ogp.augrid.org:9005/OGP%20Plaza - OGP Plaza
* http://ogp.augrid.org:9005/nortopia - Nortopia
* http://ogp.augrid.org:9005/augrid.org%20ogp - Augrid.org OGP
* http://ogp.augrid.org:9005/jodyville - JodyVille
* http://ogp.augrid.org:9005/66.197.247.222 - Test Numerical Sim name
* All regions are on AUGrid.org and Beta Grid
* Online 24/7 - Info and custom objects with land shaped like Aust. more info http://www.augrid.org
* Contact: [[User:Norgan Torok|Norgan Torok]]
* E-Mail: [mailto://contact@augrid.org Norgan Torok (SL)/Norgan Crazys (AUGrid)]

== Berlinos ==
* 1. Region URL: http://testgrid.de:9000/berlinos
* 2. Region URL: http://testgrid.de:9000/berlinos2
* 24/7 uptime
* Contact: [[User:Easyfresh Auer]]
* E-Mail: [mailto://easyfresh.auer@easyfresh-auer.de Easyfresh Auer]

== Bulli's Land ==
* Region URL: http://83.247.63.174:9000
* Up as much as possible
* Contact: [[User:Bulli Schumann]]
* E-Mail: [mailto://bulli.schumann@gmail.com Bulli Schumann]

== GCSE ==
* Region URL: http://gcse.ath.cx:9300
* 24/7 uptime (unless NAT loopback fails)
* Contact: [[User:Herfulnerful Holsworthy]]
* E-Mail: [mailto://herfulnerful@charter.net Herfulnerful Holsworthy]

== Radioactive World ==
* Region URL: '''http://ct1aic.dyndns.org:9000'''
* Up as much as possible
* Also with 14 SIM's @ OSGRID
* Contact: [[User:Radioactive Rosca]]
* E-Mail: [mailto://radioactive.rosca@gmail.com Radioactive Rosca]

== Bloob box Island ==
* Region URL: http://87.98.134.166:9000
* Up as much as possible
* Contact: [[User:kaly Mayako]]

== Chandra ==
* http://surya.grids.litesim.com:8000/ogp_listen
* 24/7 except for maint and upgrades
* Contact: [[User:Armon Aeon|Armon Aeon]]

== Ciuso Prime ==
*http://128.177.27.217:9000 or http://prime.ciuso.com:9000 - Not available currently!
*intended to be up 24*7 except for maintenance and upgrades
* Contact: [[User:Sered Woollahra|Sered Woollahra]], seredsecondlife at gmail.com

== Lexania ==
* 1. OGP Region URL: http://lexa.ath.cx:9000/Lexania
* 2. OGP Region URL: http://lexa.ath.cx:9000/Lexania2
* Uptime: Quite a lot
* Status: Three trees and a puddle (per region!) :)
* Contact: Sure, why not
* Which one: SL IM: [[User: Lexa Sands|Lexa Sands]]
* Email: I'll get SL IMs via Email when offline

==Kurai's OpenSims==
*http://zeitenwerk.de:9128
*Uptime: 24/7 - 100 Mbits
*Contact: [[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]

== TicTacToe for Gridnauts ==
* This "opensim" (world) is a test for "minimum requirements". We are using a Dell Latitude D600 notebook having a Intel Centrino 2.0 Ghz, 512 Mb (RAM) and a broadband line having only 256 Kbps (for downloads)/100 Kbps (for uploads).
* 2 avatares can play the tic-tac-toe game clicking cubes, that will rotate.
* http://titactoe.ath.cx:9000/TicTacToe
* Our "opensim" is hooked to OSGrid. Region: TicTacToe.
* If you like to do a test or a demo, please contact me.
* Contact: [[User:Adamascj Aji|Americo Damasceno - Adamascj Aji]]

== Beta Technologies OpenSim (Mini-)Grid ==
* Micro-grid for [http://betatechnologies.info/ Beta Technologies].
* The first four regions are co-located in Phoenix, Arizona (ping times should be about the same as to LL's grids); the last four in Portugal, Europe. The purpose was to test running a common grid distributed among two data centres. Servers are quite different in performance: the European server has much more memory and performance, but the network access is poor. The Arizona regions are on a low-powered server which however boasts excellent connectivity. The experience of going from one to the other is quite intriguing.
* Open for now as we just test things out; some regions might be closed in the future as this Mini-Grid begins to be internally used for our own projects (mostly as a temporary sandbox before transferring content to LL's grid).
* Uptime: ought to be 99.7%, except for upgrades and the odd reconfiguration. Some sims or parcels might be closed as this is being used for some internal testing.
* No support web site for now (users are created manually)
* if you wish to add your region to our Mini-Grid for tests, and don't wish to go through the fuss of creating your set of central servers, you're welcome to do so at this stage. Just contact us!
* Available regions as follows:
** 3650/3650 - Beta Technologies - http://asimov.betatechnologies.info:9000/
** 3650/3651 - Theatron - http://asimov.betatechnologies.info:9001/
** 3651/3650 - Terreiro do Paco - http://asimov.betatechnologies.info:9002/ (lots of content here)
** 3651/3651 - Beta Business Park - http://asimov.betatechnologies.info:9003/
** 3652/3650 - EggVille - http://bradbury.betatechnologies.info:9000/
** 3652/3651 - Beta Sandbox - http://bradbury.betatechnologies.info:9001/
** 7000/7000 - Half Way - http://bradbury.betatechnologies.info:9002/
** 11000/11000 - Far Away - http://bradbury.betatechnologies.info:9003/

These last two are required because this minigrid is Hypergrid-enabled. So to jump across LL's grid and any other Hypergrid, due to the weird 4096-jump-limit, you need to jump to Half Way and later to Far Away and back.

* Contact: [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]]
* E-Mail: [mailto://Gwyneth.Llewelyn@BetaTechnologies.Info Gwyneth Llewelyn]

== eaglefx Binder ==

Sunred Beach Gridnaut

* http://gridnaut.sunredbeach.com:9008
* 24/7 - it may be unavailable for short periods for updates/maintenance
* Contact: [[User:eaglefx Binder | eaglefx Binder]]
* E-Mail: [mailto://eaglefx99@yahoo.com eaglefx Binder]

[[category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Public Regions

2009-08-04T18:25:10Z

Infinity Linden: /* Linden Lab OGP Regions */

The following OpenSim regions supporting the Open Grid protocol are available for you to teleport to once you've authenticated to the agent domain:

This is value you enter into the region URL dialog on the login screen and the World >> Teleport Region command.

== Linden Lab OGP Regions ==

:OGP Sims on Vaak are up again --[[User:Whump Linden|Whump Linden]] 23:58, 18 June 2009 (UTC)
:OGP Sims on Vaak are down, and we're working on getting them back up. --[[User:Infinity Linden|Infinity Linden]] 11:24, 04 August 2009 (PDT)

* https://sim1.vaak.lindenlab.com:12043/cap/cccc1bb7-3446-981c-cab3-d757e0a3b5bc for Bethel
* https://sim1.vaak.lindenlab.com:12043/cap/056398ad-5d3f-2b63-5195-30306844a108 for Oak Grove
* https://sim1.vaak.lindenlab.com:12043/cap/64376bd2-e32a-5034-b47d-4edd2227f1db for Grignano
* https://sim1.vaak.lindenlab.com:12043/cap/43efa885-5f86-5dc5-0839-f7eb1adc1713 for Pullman

== Ugotrade ==

* http://ugotrade.net:9000
* 24/7 if it is down I will restart
* Contact: Tara5 Oh

== COM.lounge / Tao Takashi / mrtopf.de ==

* http://plonetv.de:9000
* currently offline due to awaiting new patch
* Contact: [http://mrtopf.de/blog Tao Takashi]

== BlueWall ==

* http://ascent.bluewallgroup.com:9900/BlueWall%20Isle
* http://ascent.bluewallgroup.com:9900/Bay%20Side
* http://ascent.bluewallgroup.com:9910/BlueWall%20Gateway ''Hypergrid gateway to OSGrid''
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:BlueWall Slade | Bluewall Slade]]
* E-Mail: [mailto://BlueWall.Slade@gmail.com BlueWall Slade]

== SimlandMax ==

* Region URL: http://simland.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:creator Luna]]

== Elsewhere ==

* Region URL: http://opensim.nowherevirtual.com:9000
* Times Available: 24/7 (except for maintenance)
* Contact: [[User:Emma Nowhere | Emma Nowhere ]]
* E-Mail: [mailto://emma.nowhere@gmail.com Emma Nowhere]

== LJPOGP00 ==

* http://98.26.97.209:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:Julie Wasserstrom | Julie Wasserstrom]]
* E-Mail: [mailto://Julie.Wasserstrom@gmail.com Julie Wasserstrom]

== Luskwood ==

* http://opengrid.luskwood.net:9000
* 24/7, Not built out yet though.
* Contact [[User:Michi Lumin | Michi Lumin]]
* E-Mail: [mailto://michi@luskwood.org Michi Lumin]

== Akina ==
* http://213.186.37.135:9000
* 24/7 except for maint and upgrades
* Contact: [[User:EloiseJolie Capalini|EloiseJolie Capalini]]
* Email [mailto://artana34@gmail.com Artana]

== Planck and Kaku ==

* Region URL: http://opensim.vworlds.co.uk:9000
* Times Available: 0:800 23:00 UTC 24/7 when new server is ready
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== Dirac, Fermi, Bohr and Pauli ==

* Region URL: http://mainland.vworlds.co.uk:9000/
* Times Available: 24/7
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]

== BrackenLand ==

* http://
* Temporarily offline
* Contact: [[User:Gomez Bracken | Gomez Bracken]]
* E-Mail: [mailto://gomez@temptations-club.com Gomez Bracken]

== Piper ==

* Region URL: http://primforge.org:9009
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [http://primforge.com/ Torrid Luna]

== Zinnemann Grid ==

* Region URL: http://zinnemanngrid.com:9000
* [http://www.zinnemann.com/grid.asp Zinnemann Grid Webpage]
* Contact: [[User:Hans Zinnemann | Hans Zinnemann]]

== Lakewood / Ducatillon Group Project ==

* http://dgpexperimental.selfip.org:9000
* 24/7 - might be unavailable for short periods as far as we update/maintain the location
* Contact: [[User:McCoy Ducatillon | McCoy Ducatillon]]
* E-Mail: [mailto://ducatillongroup@gmail.com McCoy Ducatillon]

== Burning Life Test Open Sim ==

* Region URL: http://68.178.191.56:9000
* Times Available: 24/7 (Unless Under Update)
* Contact: [[User:Vicero Lambert | Vicero Lambert ]]
* E-Mail: [mailto://jakekukuk@gmail.com Vicero Lambert]

== Litesim Mainland ==

* http://lsmainland.ogs-openuser.litesim.com:8000/ogp_listen
* 24/7 - occasional issues
* Contact: [[User:Gareth Ellison | Gareth Nelson]]
* E-Mail: [mailto://gareth@litesim.com Gareth Nelson]
* About 10 regions on the grid
* Can also now do TP into other random (non-OGP) grids and tested with OSGrid and central grid

== Gridrock Worlds ==
* closed for the next few months
* Blog info: http://www.in2orbit.net
* E-Mail: [mailto://whyroc@in2orbit.net whyroc Slade]

== Douggles Hangout ==
* Region URL http://club-panty.com:9000
* 24/7 uptime
* Contact bonghit Schism_External
* Email [mailto:pantera.42069@yahoo.com]

== Pixelpark ==
* Region URL http://pixelpark.servegame.org:9000
* online ('''updated''' to OpenSim 0.6 as of 11/14/08 on Amazon EC2)
* Contact [[User:Bartholomew Kleiber | Bartholomew Kleiber ]]
* Email [mailto://dirk.krause@pixelpark.com Dirk Krause]

== Five Miles Out ==
* Region URL http://taurus.fivemile.org:9000
* 24/7 uptime 1 Gbps
* Contact [[User:Jim Kupferberg | Jim Kupferberg ]]
* Email [mailto:info@fivemile.net Jim Kupferberg]

== Whichway From Here ==
* Region URL http://ae6vk.harpsichordyet.com:9000
* 09:00-22:00 SLT, but down at my whim.
* Contact [[User:Whichway Janus | Whichway Janus ]]
* Email [mailto:Whichway.Janus@Yahoo.Com Whichway Janus]

== Dahlia Island ==
* Region URL http://thnk1.dyndns.org:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Dahlia Trimble | Dahlia Trimble]]
* Email [mailto:dahliaTrimble@gmail.com Dahlia Trimble]

== 3Di OGP Test ==
* Region URL http://210.188.235.138:9000
* 24/7 uptime, subject to outages for upgrades
* Contact [[User:Kish Kas | Kish Kas]]

== Bit Island ==
* Region URL http://mark.bitlife.jp:9000
* 24/7 uptime
* Contact [[User:Bit2zero Planer | Bit2zero Planer]]

== metaXLR8 ==
* Region URL http://metaxlr8.com:9000
* Uptime 24/7, down only for testing and updating
* See http://metafuturing.net/index.php/MetaXLR8_OpenSim
* Contact: Giulio Perhaps

== La Isla West ==
* http://24.30.54.84:9000
* 24/7 - may be unavailable for short periods for updates/maintenance
* Contact: [[User:m0rdred Veil | m0rdred Veil]]
* E-Mail: [mailto://m0rdredveil@yahoo.com m0rdred Veil]

== AUGrid-OGP Norgan ==
* http://66.197.247.222:9005 http://ogp.augrid.org:9005
* http://ogp.augrid.org:9005/OGP%20Plaza - OGP Plaza
* http://ogp.augrid.org:9005/nortopia - Nortopia
* http://ogp.augrid.org:9005/augrid.org%20ogp - Augrid.org OGP
* http://ogp.augrid.org:9005/jodyville - JodyVille
* http://ogp.augrid.org:9005/66.197.247.222 - Test Numerical Sim name
* All regions are on AUGrid.org and Beta Grid
* Online 24/7 - Info and custom objects with land shaped like Aust. more info http://www.augrid.org
* Contact: [[User:Norgan Torok|Norgan Torok]]
* E-Mail: [mailto://contact@augrid.org Norgan Torok (SL)/Norgan Crazys (AUGrid)]

== Berlinos ==
* 1. Region URL: http://testgrid.de:9000/berlinos
* 2. Region URL: http://testgrid.de:9000/berlinos2
* 24/7 uptime
* Contact: [[User:Easyfresh Auer]]
* E-Mail: [mailto://easyfresh.auer@easyfresh-auer.de Easyfresh Auer]

== Bulli's Land ==
* Region URL: http://83.247.63.174:9000
* Up as much as possible
* Contact: [[User:Bulli Schumann]]
* E-Mail: [mailto://bulli.schumann@gmail.com Bulli Schumann]

== GCSE ==
* Region URL: http://gcse.ath.cx:9300
* 24/7 uptime (unless NAT loopback fails)
* Contact: [[User:Herfulnerful Holsworthy]]
* E-Mail: [mailto://herfulnerful@charter.net Herfulnerful Holsworthy]

== Radioactive World ==
* Region URL: '''http://ct1aic.dyndns.org:9000'''
* Up as much as possible
* Also with 14 SIM's @ OSGRID
* Contact: [[User:Radioactive Rosca]]
* E-Mail: [mailto://radioactive.rosca@gmail.com Radioactive Rosca]

== Bloob box Island ==
* Region URL: http://87.98.134.166:9000
* Up as much as possible
* Contact: [[User:kaly Mayako]]

== Chandra ==
* http://surya.grids.litesim.com:8000/ogp_listen
* 24/7 except for maint and upgrades
* Contact: [[User:Armon Aeon|Armon Aeon]]

== Ciuso Prime ==
*http://128.177.27.217:9000 or http://prime.ciuso.com:9000 - Not available currently!
*intended to be up 24*7 except for maintenance and upgrades
* Contact: [[User:Sered Woollahra|Sered Woollahra]], seredsecondlife at gmail.com

== Lexania ==
* 1. OGP Region URL: http://lexa.ath.cx:9000/Lexania
* 2. OGP Region URL: http://lexa.ath.cx:9000/Lexania2
* Uptime: Quite a lot
* Status: Three trees and a puddle (per region!) :)
* Contact: Sure, why not
* Which one: SL IM: [[User: Lexa Sands|Lexa Sands]]
* Email: I'll get SL IMs via Email when offline

==Kurai's OpenSims==
*http://zeitenwerk.de:9128
*Uptime: 24/7 - 100 Mbits
*Contact: [[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]

== TicTacToe for Gridnauts ==
* This "opensim" (world) is a test for "minimum requirements". We are using a Dell Latitude D600 notebook having a Intel Centrino 2.0 Ghz, 512 Mb (RAM) and a broadband line having only 256 Kbps (for downloads)/100 Kbps (for uploads).
* 2 avatares can play the tic-tac-toe game clicking cubes, that will rotate.
* http://titactoe.ath.cx:9000/TicTacToe
* Our "opensim" is hooked to OSGrid. Region: TicTacToe.
* If you like to do a test or a demo, please contact me.
* Contact: [[User:Adamascj Aji|Americo Damasceno - Adamascj Aji]]

== Beta Technologies OpenSim (Mini-)Grid ==
* Micro-grid for [http://betatechnologies.info/ Beta Technologies].
* The first four regions are co-located in Phoenix, Arizona (ping times should be about the same as to LL's grids); the last four in Portugal, Europe. The purpose was to test running a common grid distributed among two data centres. Servers are quite different in performance: the European server has much more memory and performance, but the network access is poor. The Arizona regions are on a low-powered server which however boasts excellent connectivity. The experience of going from one to the other is quite intriguing.
* Open for now as we just test things out; some regions might be closed in the future as this Mini-Grid begins to be internally used for our own projects (mostly as a temporary sandbox before transferring content to LL's grid).
* Uptime: ought to be 99.7%, except for upgrades and the odd reconfiguration. Some sims or parcels might be closed as this is being used for some internal testing.
* No support web site for now (users are created manually)
* if you wish to add your region to our Mini-Grid for tests, and don't wish to go through the fuss of creating your set of central servers, you're welcome to do so at this stage. Just contact us!
* Available regions as follows:
** 3650/3650 - Beta Technologies - http://asimov.betatechnologies.info:9000/
** 3650/3651 - Theatron - http://asimov.betatechnologies.info:9001/
** 3651/3650 - Terreiro do Paco - http://asimov.betatechnologies.info:9002/ (lots of content here)
** 3651/3651 - Beta Business Park - http://asimov.betatechnologies.info:9003/
** 3652/3650 - EggVille - http://bradbury.betatechnologies.info:9000/
** 3652/3651 - Beta Sandbox - http://bradbury.betatechnologies.info:9001/
** 7000/7000 - Half Way - http://bradbury.betatechnologies.info:9002/
** 11000/11000 - Far Away - http://bradbury.betatechnologies.info:9003/

These last two are required because this minigrid is Hypergrid-enabled. So to jump across LL's grid and any other Hypergrid, due to the weird 4096-jump-limit, you need to jump to Half Way and later to Far Away and back.

* Contact: [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]]
* E-Mail: [mailto://Gwyneth.Llewelyn@BetaTechnologies.Info Gwyneth Llewelyn]

== eaglefx Binder ==

Sunred Beach Gridnaut

* http://gridnaut.sunredbeach.com:9008
* 24/7 - it may be unavailable for short periods for updates/maintenance
* Contact: [[User:eaglefx Binder | eaglefx Binder]]
* E-Mail: [mailto://eaglefx99@yahoo.com eaglefx Binder]

[[category:Open_Grid_Public_Beta]]

User:Infinity Linden/IETF Drafts and Meetings

2009-07-14T20:59:53Z

Infinity Linden: /* Current OGP Related Drafts */

== Upcoming OGPX Meetings ==

The initial OGPX Birds of a Feather meeting will take place in Stockholm, Sweden on Tuesday, the 28th of July at 3:20PM local time (more information about the IETF 75 schedule at http://lptools1.amsl.com/agenda/75/calendar .) The virtual world counterpart to this meeting will take place at "[http://slurl.com/secondlife/Levenhall/80/239/25/?img=http%3A//secondlife.com/app/image/faa9deeb-6410-1146-e84b-7f7b509be79f/1&title=Infinity%20is%20Full%20of%20Stars Infinity is Full of Stars]" at 6:20AM SLT.

== Current OGP Related Drafts ==

; [http://tools.ietf.org/html/draft-lentczner-rhttp-00 Reverse HTTP, Draft 00] : Reverse HTTP describes a mechanism for introducing bidirectional http. In other words, it describes the protocol that allows a client to connect to a RHTTP compliant server to establish a connection, then allows the server to send a request to the client.
; [http://tools.ietf.org/html/draft-hamrick-llsd-00 LLSD Abstract Type System, Draft 00] : LLSD describes an abstract type system and a protocol interaction interface description language. OGP services are defined using LLSD.
; [http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 OGP:Introduction and Requirements, Draft 00] : The "Introduction and Requirements" draft is an attempt to broadly define the problem domain of interoperable virtual worlds and introduce architectural patterns in its solution.
; [http://tools.ietf.org/html/draft-lentczner-ogp-base-00 OGP:Base, Draft 00] : This document describes fundamental aspects of OGP including Capabilities and Event Queues.
; [http://tools.ietf.org/html/draft-hamrick-ogp-launch-00 OGP : Client Application Launch Message, Draft 00] : This document describes a technique for launching a client application by way of an XML message.
; [http://tools.ietf.org/html/draft-hamrick-ogp-auth-01 OGP:Service Establishment, Draft 01] : This document describes techniques for establishing a seed cap from a remote OGP service, the first step when interacting with an OGP peer.
; [http://tools.ietf.org/html/draft-levine-ogp-clientcap-00 Client Capabilities for OGPX, Draft 00] : Describes the way a network peer can request a capability on a client with an unroutable IP address.
; [http://tools.ietf.org/html/draft-levine-ogp-layering-00 OGPX layering and architectural patterns, Draft 00] : Architectural layering and patterns for OGPX.

User:Infinity Linden/IETF Drafts and Meetings

2009-07-14T20:59:10Z

Infinity Linden: /* Current OGP Related Drafts */

== Upcoming OGPX Meetings ==

The initial OGPX Birds of a Feather meeting will take place in Stockholm, Sweden on Tuesday, the 28th of July at 3:20PM local time (more information about the IETF 75 schedule at http://lptools1.amsl.com/agenda/75/calendar .) The virtual world counterpart to this meeting will take place at "[http://slurl.com/secondlife/Levenhall/80/239/25/?img=http%3A//secondlife.com/app/image/faa9deeb-6410-1146-e84b-7f7b509be79f/1&title=Infinity%20is%20Full%20of%20Stars Infinity is Full of Stars]" at 6:20AM SLT.

== Current OGP Related Drafts ==

; [http://tools.ietf.org/html/draft-lentczner-rhttp-00 Reverse HTTP, Draft 00] : Reverse HTTP describes a mechanism for introducing bidirectional http. In other words, it describes the protocol that allows a client to connect to a RHTTP compliant server to establish a connection, then allows the server to send a request to the client.
; [http://tools.ietf.org/html/draft-hamrick-llsd-00 LLSD Abstract Type System, Draft 00] : LLSD describes an abstract type system and a protocol interaction interface description language. OGP services are defined using LLSD.
; [http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 OGP:Introduction and Requirements, Draft 00] : The "Introduction and Requirements" draft is an attempt to broadly define the problem domain of interoperable virtual worlds and introduce architectural patterns in its solution.
; [http://tools.ietf.org/html/draft-lentczner-ogp-base-00 OGP:Base, Draft 00] : This document describes fundamental aspects of OGP including Capabilities and Event Queues.
; [http://tools.ietf.org/html/draft-hamrick-ogp-launch-00 Open Grid Protocol : Client Application Launch Message, Draft 00] : This document describes a technique for launching a client application by way of an XML message.
; [http://tools.ietf.org/html/draft-hamrick-ogp-auth-01 OGP:Service Establishment, Draft 01] : This document describes techniques for establishing a seed cap from a remote OGP service, the first step when interacting with an OGP peer.
; [http://tools.ietf.org/html/draft-levine-ogp-clientcap-00 Client Capabilities for OGPX, Draft 00] : Describes the way a network peer can request a capability on a client with an unroutable IP address.
; [http://tools.ietf.org/html/draft-levine-ogp-layering-00 OGPX layering and architectural patterns, Draft 00] : Architectural layering and patterns for OGPX.

User:Infinity Linden/IETF Drafts and Meetings

2009-07-14T17:58:11Z

Infinity Linden: /* Current OGP Related Drafts */

== Upcoming OGPX Meetings ==

The initial OGPX Birds of a Feather meeting will take place in Stockholm, Sweden on Tuesday, the 28th of July at 3:20PM local time (more information about the IETF 75 schedule at http://lptools1.amsl.com/agenda/75/calendar .) The virtual world counterpart to this meeting will take place at "[http://slurl.com/secondlife/Levenhall/80/239/25/?img=http%3A//secondlife.com/app/image/faa9deeb-6410-1146-e84b-7f7b509be79f/1&title=Infinity%20is%20Full%20of%20Stars Infinity is Full of Stars]" at 6:20AM SLT.

== Current OGP Related Drafts ==

; [http://tools.ietf.org/html/draft-lentczner-rhttp-00 Reverse HTTP, Draft 00] : Reverse HTTP describes a mechanism for introducing bidirectional http. In other words, it describes the protocol that allows a client to connect to a RHTTP compliant server to establish a connection, then allows the server to send a request to the client.
; [http://tools.ietf.org/html/draft-hamrick-llsd-00 LLSD Abstract Type System, Draft 00] : LLSD describes an abstract type system and a protocol interaction interface description language. OGP services are defined using LLSD.
; [http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 OGP:Introduction and Requirements, Draft 00] : The "Introduction and Requirements" draft is an attempt to broadly define the problem domain of interoperable virtual worlds and introduce architectural patterns in its solution.
; [http://tools.ietf.org/html/draft-lentczner-ogp-base-00 OGP:Base, Draft 00] : This document describes fundamental aspects of OGP including Capabilities and Event Queues.
; [http://tools.ietf.org/html/draft-hamrick-ogp-auth-01 OGP:Service Establishment, Draft 01] : This document describes techniques for establishing a seed cap from a remote OGP service, the first step when interacting with an OGP peer.
; [http://tools.ietf.org/html/draft-levine-ogp-clientcap-00 Client Capabilities for OGPX, Draft 00] : Describes the way a network peer can request a capability on a client with an unroutable IP address.
; [http://tools.ietf.org/html/draft-levine-ogp-layering-00 OGPX layering and architectural patterns, Draft 00] : Architectural layering and patterns for OGPX.

User:Infinity Linden/IETF Drafts and Meetings

2009-07-14T17:34:47Z

Infinity Linden:

== Upcoming OGPX Meetings ==

The initial OGPX Birds of a Feather meeting will take place in Stockholm, Sweden on Tuesday, the 28th of July at 3:20PM local time (more information about the IETF 75 schedule at http://lptools1.amsl.com/agenda/75/calendar .) The virtual world counterpart to this meeting will take place at "[http://slurl.com/secondlife/Levenhall/80/239/25/?img=http%3A//secondlife.com/app/image/faa9deeb-6410-1146-e84b-7f7b509be79f/1&title=Infinity%20is%20Full%20of%20Stars Infinity is Full of Stars]" at 6:20AM SLT.

== Current OGP Related Drafts ==

; [http://tools.ietf.org/html/draft-lentczner-rhttp-00 Reverse HTTP, Draft 00] : Reverse HTTP describes a mechanism for introducing bidirectional http. In other words, it describes the protocol that allows a client to connect to a RHTTP compliant server to establish a connection, then allows the server to send a request to the client.
; [http://tools.ietf.org/html/draft-hamrick-llsd-00 LLSD Abstract Type System, Draft 00] : LLSD describes an abstract type system and a protocol interaction interface description language. OGP services are defined using LLSD.
; [http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 OGP:Introduction and Requirements, Draft 00] : The "Introduction and Requirements" draft is an attempt to broadly define the problem domain of interoperable virtual worlds and introduce architectural patterns in its solution.
; [http://tools.ietf.org/html/draft-lentczner-ogp-base-00 OGP:Base, Draft 00] : This document describes fundamental aspects of OGP including Capabilities and Event Queues.
; [http://tools.ietf.org/html/draft-hamrick-ogp-auth OGP:Authentication, Draft 00] : This document describes techniques for user authentication, the first step when interacting with an OGP service.

User:Infinity Linden/OGP Client Side Capabilities

2009-06-10T21:59:17Z

Infinity Linden:

Capabilities are pre-authorized URLs a network host may give to a trusted peer to access a sensitive resource. The Open Grid Protocol (OGP) makes extensive use of capabilities in preference to authentication token to avoid the [http://en.wikipedia.org/wiki/Confused_deputy_problem Confused Deputy Problem] and to support the decoupling of deployment from design. Information about capabilities in OGP may be found in [http://www.ietf.org/mail-archive/web/ogpx/current/msg00026.html An Inquiry into the Nature and Causes of Web Capabilities] and [http://tools.ietf.org/html/draft-lentczner-ogp-base-00#section-2.3 Section 2.3 of the OGP Foundations draft].

As traditionally defined and deployed, capabilities exist exclusively on "server" hosts (i.e. - a host with a routable IP address that provides a service.) Use cases have emerged demonstrating the utility of "client capabilities" where a capability exists on "client" host that may be behind a NATted firewall (i.e. - it doesn't have a routable IP address.) This document provides a narrative intended to describe the problem domain and offer some solutions.

==Client Side Capabilities With HTTP==

[[Image:Client side cap 01.jpg|frame|Figure 1 : Client Side Capability with HTTP|left|320px]] Figure 1 shows a very simple solution to the problem of exposing capabilities. It also shows the main use case for capabilities. In this flow, the client application wishes to expose a sensitive resource to the a server with which it has established a trust relationship, named "Server 1" in the illustration. The capability can then be used by Server 1 to access the client application or it can be given to Server 2 (which is what this diagram illustrates.)

So the sequence illustrated here is:

'''Step 1''': The Client Application (on host client1.example.org) creates a capability to represent Resource 1. It begins accepting TCP connection requests itself (say on port 12001) over which it will speak HTTP. When a peer requests the capability, the client will respond with the resource (let's say the path component of the capability is "/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855".) The client gives the server the capability http://client1.example.org/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855 by POSTing or PUTting it to Resource 2 on Server 1. (and yes, this should probably all go over HTTPS, but we'll talk about that later.)

'''Step 2''': Server 1 decides it needs to defer access to Server 2, a trusted peer. It provides the client capability to Server 2, likely by POSTing or PUTting it to Resource 3.

'''Step 3''': At some point in the future, the process implementing Resource 3 needs to access Resource 1, which it does simply by accessing the cap http://client1.example.org/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855 .

===Problems with Client Side Capabilities With HTTP===

[[Image:Client_side_cap_01_problems.jpg|frame|Figure 2 : Problems with Client Side Capabilities with HTTP|right|320px]] But there are two major deficiencies with this scheme: 1. NATted firewalls make it hard for the client to respond to inbound TCP connection requests and 2. What do you do if the client side capability expires?

User:Infinity Linden/OGP Client Side Capabilities

2009-06-09T22:00:04Z

Infinity Linden: New page: Capabilities are pre-authorized URLs a network host may give to a trusted peer to access a sensitive resource. The Open Grid Protocol (OGP) makes extensive use of capabilities in preferenc...

Capabilities are pre-authorized URLs a network host may give to a trusted peer to access a sensitive resource. The Open Grid Protocol (OGP) makes extensive use of capabilities in preference to authentication token to avoid the [http://en.wikipedia.org/wiki/Confused_deputy_problem Confused Deputy Problem] and to support the decoupling of deployment from design. Information about capabilities in OGP may be found in [http://www.ietf.org/mail-archive/web/ogpx/current/msg00026.html An Inquiry into the Nature and Causes of Web Capabilities] and [http://tools.ietf.org/html/draft-lentczner-ogp-base-00#section-2.3 Section 2.3 of the OGP Foundations draft].

As traditionally defined and deployed, capabilities exist exclusively on "server" hosts (i.e. - a host with a routable IP address that provides a service.) Use cases have emerged demonstrating the utility of "client capabilities" where a capability exists on "client" host that may be behind a NATted firewall (i.e. - it doesn't have a routable IP address.) This document provides a narrative intended to describe the problem domain and offer some solutions.

==Client Side Capabilities With HTTP==

[[Image:Client side cap 01.jpg|frame|Figure 1 : Client Side Capability with HTTP|left|320px]] Figure 1 shows a very simple solution to the problem of exposing capabilities. It also shows the main use case for capabilities. In this flow, the client application wishes to expose a sensitive resource to the a server with which it has established a trust relationship, named "Server 1" in the illustration. The capability can then be used by Server 1 to access the client application or it can be given to Server 2 (which is what this diagram illustrates.)

So the sequence illustrated here is:

'''Step 1''': The Client Application (on host client1.example.org) creates a capability to represent Resource 1. It begins accepting TCP connection requests itself (say on port 12001) over which it will speak HTTP. When a peer requests the capability, the client will respond with the resource (let's say the path component of the capability is "/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855".) The client gives the server the capability http://client1.example.org/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855 by POSTing or PUTting it to Resource 2 on Server 1. (and yes, this should probably all go over HTTPS, but we'll talk about that later.)

'''Step 2''': Server 1 decides it needs to defer access to Server 2, a trusted peer. It provides the client capability to Server 2, likely by POSTing or PUTting it to Resource 3.

'''Step 3''': At some point in the future, the process implementing Resource 3 needs to access Resource 1, which it does simply by accessing the cap http://client1.example.org/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855 .

===Problems with Client Side Capabilities With HTTP===

[[Image:Client_side_cap_01_problems.jpg|frame|Figure 2 : Problems with Client Side Capabilities with HTTP|right|320]] But there are two major deficiencies with this scheme: 1. NATted firewalls make it hard for the client to respond to inbound TCP connection requests and 2. What do you do if the client side capability expires?

File:Client side cap 01 problems.jpg

2009-06-09T21:58:58Z

Infinity Linden:

File:Client side cap 01.jpg

2009-06-09T21:33:03Z

Infinity Linden: uploaded a new version of "Image:Client side cap 01.jpg"

File:Client side cap 01.jpg

2009-06-09T21:31:42Z

Infinity Linden:

User:Infinity Linden/OGP Service Establishment Pattern

2009-05-22T17:43:04Z

Infinity Linden:

OGP uses this pattern when establishing a session with a particular service. In the discussions below, note that the client is the system making the request. This is not always the client application; sometimes it's an agent domain or region domain process or component.

[[Image:Service_initiation_pattern.jpg|640px|thumb|center|service establishment pattern]]

; Step 1 - the client sends the authenticate message to the service establishment protocol endpoint : We assume the client is in possession of the service establishment protocol endpoint's URL. How it gets the address of the endpoint is outside the scope of this pattern. The contents of this message will look astonishingly similar to the agent_login message in the OGP : Auth document. In fact, i propose we replace agent_login with authenticate.

; Step 2 - the server validates the credentials in the authentication request : Credentials may be the the user authenticator defined in the OGP : Auth document, or an OAuth token or a client certificate. (or in some cases, it;s going to be null.) The service establishment endpoint should have a policy for which credentials it prefers, which it forbids and which it allows.

; Step 3 - the client optionally verifies the server's certificate : Many service establishment requests will be made via HTTPS. The client SHOULD verify that it trusts a certificate in the server's cert chain.

; Step 4 - the client requests a set of capabilities by sending the cap/request message to the seed cap : Hmm... we need to specify how this is done. I don't see it in the current doc set, and the docs from last summer's interop fest were less than clear.

; Step 5 - the server responds with a set of capabilities for the client : These are the service capabilities; the client uses these to get a service from the server.

; Step 6 - the client sends a service request to a capability : This is how servers offer services to clients.

User:Infinity Linden/OGP Service Establishment Pattern

2009-05-22T17:42:49Z

Infinity Linden:

OGP uses this pattern when establishing a session with a particular service. In the discussions below, note that the client is the system making the request. This is not always the client application; sometimes it's an agent domain or region domain process or component.

[[Image:Service_initiation_pattern.jpg|640px|thumb|left|service establishment pattern]]

; Step 1 - the client sends the authenticate message to the service establishment protocol endpoint : We assume the client is in possession of the service establishment protocol endpoint's URL. How it gets the address of the endpoint is outside the scope of this pattern. The contents of this message will look astonishingly similar to the agent_login message in the OGP : Auth document. In fact, i propose we replace agent_login with authenticate.

; Step 2 - the server validates the credentials in the authentication request : Credentials may be the the user authenticator defined in the OGP : Auth document, or an OAuth token or a client certificate. (or in some cases, it;s going to be null.) The service establishment endpoint should have a policy for which credentials it prefers, which it forbids and which it allows.

; Step 3 - the client optionally verifies the server's certificate : Many service establishment requests will be made via HTTPS. The client SHOULD verify that it trusts a certificate in the server's cert chain.

; Step 4 - the client requests a set of capabilities by sending the cap/request message to the seed cap : Hmm... we need to specify how this is done. I don't see it in the current doc set, and the docs from last summer's interop fest were less than clear.

; Step 5 - the server responds with a set of capabilities for the client : These are the service capabilities; the client uses these to get a service from the server.

; Step 6 - the client sends a service request to a capability : This is how servers offer services to clients.

File:Service initiation pattern.jpg

2009-05-22T17:41:06Z

Infinity Linden:

User:Infinity Linden/OGP Service Establishment Pattern

2009-05-22T17:40:29Z

Infinity Linden: New page: OGP uses this pattern when establishing a session with a particular service. In the discussions below, note that the client is the system making the request. This is not always the client ...

OGP uses this pattern when establishing a session with a particular service. In the discussions below, note that the client is the system making the request. This is not always the client application; sometimes it's an agent domain or region domain process or component.

; Step 1 - the client sends the authenticate message to the service establishment protocol endpoint : We assume the client is in possession of the service establishment protocol endpoint's URL. How it gets the address of the endpoint is outside the scope of this pattern. The contents of this message will look astonishingly similar to the agent_login message in the OGP : Auth document. In fact, i propose we replace agent_login with authenticate.

; Step 2 - the server validates the credentials in the authentication request : Credentials may be the the user authenticator defined in the OGP : Auth document, or an OAuth token or a client certificate. (or in some cases, it;s going to be null.) The service establishment endpoint should have a policy for which credentials it prefers, which it forbids and which it allows.

; Step 3 - the client optionally verifies the server's certificate : Many service establishment requests will be made via HTTPS. The client SHOULD verify that it trusts a certificate in the server's cert chain.

; Step 4 - the client requests a set of capabilities by sending the cap/request message to the seed cap : Hmm... we need to specify how this is done. I don't see it in the current doc set, and the docs from last summer's interop fest were less than clear.

; Step 5 - the server responds with a set of capabilities for the client : These are the service capabilities; the client uses these to get a service from the server.

; Step 6 - the client sends a service request to a capability : This is how servers offer services to clients.

User:Infinity Linden/IETF Drafts and Meetings

2009-05-15T21:21:53Z

Infinity Linden: New page: == Current OGP Related Drafts == ; [http://tools.ietf.org/html/draft-lentczner-rhttp-00 Reverse HTTP, Draft 00] : Reverse HTTP describes a mechanism for introducing bidirectional http. In...

== Current OGP Related Drafts ==

; [http://tools.ietf.org/html/draft-lentczner-rhttp-00 Reverse HTTP, Draft 00] : Reverse HTTP describes a mechanism for introducing bidirectional http. In other words, it describes the protocol that allows a client to connect to a RHTTP compliant server to establish a connection, then allows the server to send a request to the client.
; [http://tools.ietf.org/html/draft-hamrick-llsd-00 LLSD Abstract Type System, Draft 00] : LLSD describes an abstract type system and a protocol interaction interface description language. OGP services are defined using LLSD.
; [http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 OGP:Introduction and Requirements, Draft 00] : The "Introduction and Requirements" draft is an attempt to broadly define the problem domain of interoperable virtual worlds and introduce architectural patterns in its solution.
; [http://tools.ietf.org/html/draft-lentczner-ogp-base-00 OGP:Base, Draft 00] : This document describes fundamental aspects of OGP including Capabilities and Event Queues.
; [http://tools.ietf.org/html/draft-hamrick-ogp-auth OGP:Authentication, Draft 00] : This document describes techniques for user authentication, the first step when interacting with an OGP service.

User:Infinity Linden/Notes On LLSD

2009-02-12T03:46:02Z

Infinity Linden: New page: LLSD is the abstract type system used by Linden Lab and some OpenSimulator components. It is described in varying levels of detail in several places. But the motivation for various design ...

LLSD is the abstract type system used by Linden Lab and some OpenSimulator components. It is described in varying levels of detail in several places. But the motivation for various design decisions in LLSD have yet to be documented. This document is an effort to more accurately describe LLSD and why it is the way it is.

==What Is LLSD?==

LLSD is an abstract type system which includes an interface description language and serialization formats. LLSD is a language-neutral facility for maintaining and transporting dynamic structured data. It provides dynamic data features for loosely-coupled collections of software components, even in statically-typed languages. It includes an abstract type system, an interface description language (LLIDL) and three canonical serialization schemes (XML, JSON and Binary). The term "LLSD" is used to refer to the abstract type system, code that implements the mapping and conversions between abstract and concrete types and the it's serializations. This can lead to confusion, so this document will make an effort to be explicit about which aspect is being discussed.

The term "language-neutral abstract type system" means that LLSD is used to define the "type" of objects in an application and protocol data being sent across the wire. When we say "type" we mean that different objects may have semantics. For instance, Integers are data objects that can be added together, subtracted one from another, multiplied or divided; Dates represent moments in time; Booleans represent true and false values.

It is "language-neutral" and "abstract" in the sense that is intended to be usable by programmers of several different computer programming languages. Another way to say this is that type semantics unique to a programming language are ''not'' replicated in LLSD. For instance, in the C programming language, there is not default date type. Rather, it is sometimes represented as an unsigned 32 bit integer and other times represented as a data structure. When represented as an integer, you can add an integer to a date and get the date of some time in the future. But you can't do this with the data structure from C's standard library. Because LLSD is language neutral, it makes no attempt to preserve the semantics of dates stored as a 32 bit unsigned integer representing seconds since 1970. LLSD is used to reason about type semantics of protocol data units in a manner independent of any particular programming language.

Saying that LLSD is "abstract" speaks to the fact that there are no programming languages that directly use LLSD's type system. It also implies that there's something out there that's "concrete." Implementations of LLSD (some of which are identified below) "concretize" it's abstract behavior. The Python implementation of LLSD for instance, maps LLSD's abstract types to types understandable by Python programs. C++ implementations do the same for C++ programs.

Finally... the term "dynamic structured data" implies that LLSD structures can be modified at run-time. Note that there are several languages where this is not the case. For languages like C or C++, the LLSD implementation would need to create the illusion that LLSD data structures are malleable at runtime.

===On Serialization===

==Where Is LLSD Defined?==

File:Conceptual Overview 04.jpg

2008-12-29T04:22:04Z

Infinity Linden:

User:Infinity Linden/Distributed Object Concepts

2008-12-29T03:33:01Z

Infinity Linden:

This is a brief discussion of how we (or at least some of us) here at Linden Lab view distributed applications. We spend a lot of our day knee-deep in code and specific networking issues, but I thought it might be good to take a breather, come up for air and talk about concepts. You may disagree with us on a number of points, but we figured it was a good idea to communicate how we see the world of distributed applications.

=Concept 1 : Applications Can Be Represented as Collections of Objects=

[[Image:Conceptual_Overview_00.jpg|200px|thumb|left|a typical object graph representing the state of an application]] This may sound a bit simple for most people reading this... OO systems are a pervasive part of software development these days. Whether you program in C++, Ruby, JavaScript or even PHP, you've probably run into ''objects'' and ''classes''.

But we figured it was worth re-iterating. We like objects, especially when they're coded as... well... objects. It's important to note that just because you're using an ''object oriented'' programming language, it's still possible to write code eschews the objectives of object orientation. Conversely, it's possible to write code that is OO-ish in non-OO languages, it's just a bit harder.

What we're talking about with this concept is that it's possible to model an application as a collection of cooperating objects. The figure to the left is meant to represent such an application. Rather than representing the application's state in a global data structure, state is distributed across a collection of smaller objects. Objects are intended to represent a conceptual entity manipulated by the application. Rather than writing routines to manipulate global data structures, we write methods that manipulate the state of an object in response to messages from other objects. Objects maintain references to other objects; the arrows in the figure at the left represent these references. Objects send messages to each other via these references, and it's these messages that trigger code to be executed to manipulate the state of our object friends. Okay.. so now that i've completely bored you with an extremely basic discussion that's so vague it has about zero utility.. let me conclude with the "important bits."

It's easy to get lost in the details of XML parsing and the wild flurry of UDP messages the SL client emits, but at the end of the day, there's this "application" thing that is independent of TCP or UDP or HTTP or whatever. It's a collection of cooperating objects (the mathematically inclined might call it an "object graph".) The object graph represents the "application logic" (escapees from the web 2.0 era may also occasionally use the term "business logic.") It represents the core abstractions of the application, independent of network transport, graphics rendering technology or even functional system architecture. We like OO development environments as they generally support concepts such as [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction], [http://en.wikipedia.org/wiki/Information_hiding Encapsulation] and [http://en.wikipedia.org/wiki/Decoupling Decoupling] that makes maintenance of an evolving system less painful.

=Concept 2 : Object Graphs Abound=

[[Image:Conceptual_Overview_01.jpg|200px|thumb|right|a client and a server application being represented as object graphs]] Still with me? Great! I was worried I was boring you.

So the next concept is pretty straight forward as well: you can represent a server application as an object graph as easily as you can represent a client application with an object graph. The figure to the right is supposed to represent this concept.

You could go on and say that this concept does not require client-server communications, and you would be right. It would be possible to replace every instance of ''client'' and ''server'' with the word ''peer'' and you would still have a very workable conceptual framework. We talk about client-server a lot at Linden cause:

# we make extensive use of HTTP in our system which uses the Request-Response pattern, thus implying a client and a server, and
# people sometimes confuse the term "''network peer''" with the term "''peer to peer''" and freak out, thinking we're supporting illegal file-sharing or opening an interface that allows "bad guys" to illicitly copy digital assets in contravention of asset permission meta-data. For the record, we go to great lengths to prevent such illicit asset copying.

=Concept 3 : Distributed Applications May Be Modeled as a Collection of Object Graphs=

[[Image:Conceptual_Overview_02.jpg|200px|thumb|left|a distributed application's object graph spanning machines]]And here's where it gets interesting. In the figure to the left we see four different machines each with it's own object graph. But if you look close you'll see there are references across machine boundaries. This is what makes this application a "''distributed application''" that uses a "''distributed object graph''". It has nothing to do with implementation details of which programming language was used to code it or what networking protocols are used to communicate between machines, but that the design treats remote and local objects the same.

C++ programmers should be aware that references in C++ objects are generally a pointer to a location in memory. They should probably also know that it's impossible for one CPU to directly access memory connected to another CPU (okay... well.. it's impossible in a non-multi-processor system that isn't using [http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access NUMA] clustering technologies like [http://en.wikipedia.org/wiki/Scalable_Coherent_Interconnect SCI])

So assuming we all don't have a [http://en.wikipedia.org/wiki/Convex_Computer Convex Exemplar] or a [http://en.wikipedia.org/wiki/SGI_Altix SGI Altix] system on our desktops, we're going to have an application that uses external references that know how to [http://en.wikipedia.org/wiki/Marshalling_(computer_science) Marshall] an object request and send it to its intended target on the network.

For what it's worth, if you hear discussion of [http://en.wikipedia.org/wiki/CORBA CORBA], [http://en.wikipedia.org/wiki/IBM_System_Object_Model DSOM], or [http://en.wikipedia.org/wiki/Distributed_Component_Object_Model DCOM] in [[Architecture_Working_Group]] meetings, it's usually related to this concept. CORBA, et al. were technologies intended to make referencing remote objects "easy" for software developers. It is a matter of fierce debate as to whether or not they achieved this objective. Ultimately, most software engineers responded negatively to the perceived complexity of such systems and either rolled their own distributed transaction system or hand-coded methods implementing remote message passing over HTTP(S). Developers familiar with Linden's SecondLife Viewer will see evidence of both approaches.

But... I digress... The concept I'm trying to communicate here is that from the high level design perspective, we can view a distributed application like Second Life as a big distributed object graph where some objects live on one machine and other objects live on another. Messages that need to pass from one machine to another use some form of request marshaling. The OGP specification attempts to define remote objects in terms of [http://en.wikipedia.org/wiki/REST REST-like resources] explicitly to enable this type of abstraction.

=Concept 4 : Method Invocation on Remote Objects Should be Independent of Transport or Serialization Format=

[[Image:Conceptual_Overview_03.jpg|200px|thumb|right|a distributed object graph where message invocation semantics are independent of transport]]Okay... open the image to the right in another window... you'll want to look back and forth often.

One of the things fans of [http://en.wikipedia.org/wiki/Object_Oriented_Analysis Object Oriented Analysis] yammer on about incessantly is this whole concept of clearly separating "[http://en.wikipedia.org/wiki/Business_logic business logic]" from "[http://en.wikipedia.org/wiki/Presentation_logic presentation logic]." If you're like me, you would rather spend eternity eating double-edged razor blades than have another person explain why [http://en.wikipedia.org/wiki/Separation_of_concerns Separation of Concerns] is a good thing. So, i'll not mention the motivation behind such architectural issues, only note that a lot of people (some of whom are considerably smarter than you or I) think it's a good idea.

Remember we talked about "business logic" before? Up at the top of the diagram we have our "business objects." They represent the state of the important concepts like where your avatar is, what she's dressed in and how many times she's been shot with the Bazooka 2000 in the last 15 seconds. They do not represent the state of a TCP/IP connection to remote machine or the number of seconds since the last packet was received.

The arrows between the white circles in the "Client Object Graph" represent references to objects. Links between these objects and the colored circles below represent references to "remote" objects. "Remote objects" live on other machines, and the mythical "remote object manager" is responsible for making the business logic objects think they're local by receiving message sends, marshaling the request, sending it over the wire and optionally receiving a response.

Below the proxy objects you should note multiple message serialization and transport methods. The fact that there are several of them implies there are several ways to communicate a business object state change to remote peers. Not shown in this diagram is the remote object manager on the peer system which un-marshals the message on the remote system.

So... the important take-aways here are "it's okay to have multiple transports" and "honestly, don't hand code message parsers, please" and "your business logic shouldn't care one whit which transport you use." (In the real world, there'll probably be a little bit of hinting by the business object like.. "oh... for the next several messages it would be really nice if they went over RTP, kthxbai," but we'll get to that again later.)

File:Conceptual Overview 03.jpg

2008-12-29T02:05:03Z

Infinity Linden:

User:Infinity Linden/Distributed Object Concepts

2008-12-29T01:33:31Z

Infinity Linden:

This is a brief discussion of how we (or at least some of us) here at Linden Lab view distributed applications. We spend a lot of our day knee-deep in code and specific networking issues, but I thought it might be good to take a breather, come up for air and talk about concepts. You may disagree with us on a number of points, but we figured it was a good idea to communicate how we see the world of distributed applications.

=Concept 1 : Applications Can Be Represented as Collections of Objects=

[[Image:Conceptual_Overview_00.jpg|200px|thumb|left|a typical object graph representing the state of an application]] This may sound a bit simple for most people reading this... OO systems are a pervasive part of software development these days. Whether you program in C++, Ruby, JavaScript or even PHP, you've probably run into ''objects'' and ''classes''.

But we figured it was worth re-iterating. We like objects, especially when they're coded as... well... objects. It's important to note that just because you're using an ''object oriented'' programming language, it's still possible to write code eschews the objectives of object orientation. Conversely, it's possible to write code that is OO-ish in non-OO languages, it's just a bit harder.

What we're talking about with this concept is that it's possible to model an application as a collection of cooperating objects. The figure to the left is meant to represent such an application. Rather than representing the application's state in a global data structure, state is distributed across a collection of smaller objects. Objects are intended to represent a conceptual entity manipulated by the application. Rather than writing routines to manipulate global data structures, we write methods that manipulate the state of an object in response to messages from other objects. Objects maintain references to other objects; the arrows in the figure at the left represent these references. Objects send messages to each other via these references, and it's these messages that trigger code to be executed to manipulate the state of our object friends. Okay.. so now that i've completely bored you with an extremely basic discussion that's so vague it has about zero utility.. let me conclude with the "important bits."

It's easy to get lost in the details of XML parsing and the wild flurry of UDP messages the SL client emits, but at the end of the day, there's this "application" thing that is independent of TCP or UDP or HTTP or whatever. It's a collection of cooperating objects (the mathematically inclined might call it an "object graph".) The object graph represents the "application logic" (escapees from the web 2.0 era may also occasionally use the term "business logic.") It represents the core abstractions of the application, independent of network transport, graphics rendering technology or even functional system architecture. We like OO development environments as they generally support concepts such as [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction], [http://en.wikipedia.org/wiki/Information_hiding Encapsulation] and [http://en.wikipedia.org/wiki/Decoupling Decoupling] that makes maintenance of an evolving system less painful.

=Concept 2 : Object Graphs Abound=

[[Image:Conceptual_Overview_01.jpg|200px|thumb|right|a client and a server application being represented as object graphs]] Still with me? Great! I was worried I was boring you.

So the next concept is pretty straight forward as well: you can represent a server application as an object graph as easily as you can represent a client application with an object graph. The figure to the right is supposed to represent this concept.

You could go on and say that this concept does not require client-server communications, and you would be right. It would be possible to replace every instance of ''client'' and ''server'' with the word ''peer'' and you would still have a very workable conceptual framework. We talk about client-server a lot at Linden cause:

# we make extensive use of HTTP in our system which uses the Request-Response pattern, thus implying a client and a server, and
# people sometimes confuse the term "''network peer''" with the term "''peer to peer''" and freak out, thinking we're supporting illegal file-sharing or opening an interface that allows "bad guys" to illicitly copy digital assets in contravention of asset permission meta-data. For the record, we go to great lengths to prevent such illicit asset copying.

=Concept 3 : Distributed Applications May Be Modeled as a Collection of Object Graphs=

[[Image:Conceptual_Overview_02.jpg|200px|thumb|left|a distributed application's object graph spanning machines]]And here's where it gets interesting. In the figure to the left we see four different machines each with it's own object graph. But if you look close you'll see there are references across machine boundaries. This is what makes this application a "''distributed application''" that uses a "''distributed object graph''". It has nothing to do with implementation details of which programming language was used to code it or what networking protocols are used to communicate between machines, but that the design treats remote and local objects the same.

C++ programmers should be aware that references in C++ objects are generally a pointer to a location in memory. They should probably also know that it's impossible for one CPU to directly access memory connected to another CPU (okay... well.. it's impossible in a non-multi-processor system that isn't using [http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access NUMA] clustering technologies like [http://en.wikipedia.org/wiki/Scalable_Coherent_Interconnect SCI])

So assuming we all don't have a [http://en.wikipedia.org/wiki/Convex_Computer Convex Exemplar] or a [http://en.wikipedia.org/wiki/SGI_Altix SGI Altix] system on our desktops, we're going to have an application that uses external references that know how to [http://en.wikipedia.org/wiki/Marshalling_(computer_science) Marshall] an object request and send it to its intended target on the network.

For what it's worth, if you hear discussion of [http://en.wikipedia.org/wiki/CORBA CORBA], [http://en.wikipedia.org/wiki/IBM_System_Object_Model DSOM], or [http://en.wikipedia.org/wiki/Distributed_Component_Object_Model DCOM] in [[Architecture_Working_Group]] meetings, it's usually related to this concept. CORBA, et al. were technologies intended to make referencing remote objects "easy" for software developers. It is a matter of fierce debate as to whether or not they achieved this objective. Ultimately, most software engineers responded poorly to the perceived complexity of such systems and either rolled their own distributed transaction system or hand-coded methods implementing remote message passing over HTTP(S). Developers familiar with Linden's SecondLife Viewer will see evidence of both approaches.

But... I digress... The concept I'm trying to communicate here is that from the high level design perspective, we can view a distributed application like Second Life as a big distributed object graph where some objects live on one machine and other objects live on another. Messages that need to pass from one machine to another use some form of request marshaling. The OGP specification attempts to define remote objects in terms of [http://en.wikipedia.org/wiki/REST REST-like resources] explicitly to enable this type of abstraction.

File:Conceptual Overview 02.jpg

2008-12-29T00:51:47Z

Infinity Linden:

User:Infinity Linden/Distributed Object Concepts

2008-12-29T00:42:46Z

Infinity Linden:

=Introduction=

This is a brief discussion of how we (or at least some of us) here at Linden Lab view distributed applications. We spend a lot of our day knee-deep in code and specific networking issues, but I thought it might be good to take a breather, come up for air and talk about concepts. You may disagree with us on a number of points, but we figured it was a good idea to communicate how we see the world of distributed applications.

=Concept 1 : Applications Can Be Represented as Collections of Objects=

[[Image:Conceptual_Overview_00.jpg|200px|thumb|left|a typical object graph representing the state of an application]] This may sound a bit simple for most people reading this... OO systems are a pervasive part of software development these days. Whether you program in C++, Ruby, JavaScript or even PHP, you've probably run into ''objects'' and ''classes''.

But we figured it was worth re-iterating. We like objects, especially when they're coded as... well... objects. It's important to note that just because you're using an ''object oriented'' programming language, it's still possible to write code eschews the objectives of object orientation. Conversely, it's possible to write code that is OO-ish in non-OO languages, it's just a bit harder.

What we're talking about with this concept is that it's possible to model an application as a collection of cooperating objects. The figure to the left is meant to represent such an application. Rather than representing the application's state in a global data structure, state is distributed across a collection of smaller objects. Objects are intended to represent a conceptual entity manipulated by the application. Rather than writing routines to manipulate global data structures, we write methods that manipulate the state of an object in response to messages from other objects. Objects maintain references to other objects; the arrows in the figure at the left represent these references. Objects send messages to each other via these references, and it's these messages that trigger code to be executed to manipulate the state of our object friends. Okay.. so now that i've completely bored you with an extremely basic discussion that's so vague it has about zero utility.. let me conclude with the "important bits."

It's easy to get lost in the details of XML parsing and the wild flurry of UDP messages the SL client emits, but at the end of the day, there's this "application" thing that is independent of TCP or UDP or HTTP or whatever. It's a collection of cooperating objects (the mathematically inclined might call it an "object graph".) The object graph represents the "application logic" (escapees from the web 2.0 era may also occasionally use the term "business logic.") It represents the core abstractions of the application, independent of network transport, graphics rendering technology or even functional system architecture. We like OO development environments as they generally support concepts such as [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction], [http://en.wikipedia.org/wiki/Information_hiding Encapsulation] and [http://en.wikipedia.org/wiki/Decoupling Decoupling] that makes maintenance of an evolving system less painful.

=Concept 2 : Object Graphs Abound=

[[Image:Conceptual_Overview_01.jpg|200px|thumb|right|a client and a server application being represented as object graphs]] Still with me? Great! I was worried I was boring you.

So the next concept is pretty straight forward as well: you can represent a server application as an object graph as easily as you can represent a client application with an object graph. The figure to the right is supposed to represent this concept.

You could go on and say that this concept does not require client-server communications, and you would be right. It would be possible to replace every instance of ''client'' and ''server'' with the word ''peer'' and you would still have a very workable conceptual framework. We talk about client-server a lot at Linden cause:

# we make extensive use of HTTP in our system which uses the Request-Response pattern, thus implying a client and a server, and
# people sometimes confuse the term "''network peer''" with the term "''peer to peer''" and freak out, thinking we're supporting illegal file-sharing or opening an interface that allows "bad guys" to illicitly copy digital assets in contravention of asset permission meta-data. For the record, we go to great lengths to prevent such illicit asset copying.

File:Conceptual Overview 01.jpg

2008-12-29T00:24:50Z

Infinity Linden:

User:Infinity Linden/Distributed Object Concepts

2008-12-29T00:18:49Z

Infinity Linden: New page: =Introduction= This is a brief discussion of how we (or at least some of us) here at Linden Lab view distributed applications. We spend a lot of our day knee-deep in code and specific net...

File:Conceptual Overview 00.jpg

2008-12-29T00:14:54Z

Infinity Linden:

File:Sidewinder platform 001.jpg

2008-12-11T20:24:57Z

Infinity Linden: gone, but not forgotten, Sidewinder Linden is remembered through the "Sidewinder T. Linden Memorial Diving Platform."

gone, but not forgotten, Sidewinder Linden is remembered through the "Sidewinder T. Linden Memorial Diving Platform."

File:Slhand.jpg

2008-10-24T17:48:22Z

Infinity Linden:

User:Infinity Linden/OGP Trust Phase 0

2008-10-21T21:24:50Z

Infinity Linden: Replacing page with 'this proposal has been deprecated'

this proposal has been deprecated

User:Infinity Linden/OGP Trust Phase 0

2008-10-21T21:24:21Z

Infinity Linden:

deprecated

=Introduction=

This page describes "near term" trust mechanisms for OGP protocol participants. The objective is not to define the ultimate trust or security system, or even to try to enumerate all trust issues; for that, please visit the [[User:Infinity_Linden/OGP_Trust_Model|OGP Trust Model Page]]. This page is intended to describe "near term" trust issues and how participants in the OGP Beta program may use features that currently exist to establish "trust" between region and agent domains. So.. the [[User:Infinity_Linden/OGP_Trust_Model|OGP Trust Model Page]] is where you will find information regarding Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc. This page is where you'll find discussions regarding how client applications, agent domains and region domains establish a base level of trust through the use of X.509 certificates used in conjunction with TLS / HTTPS.

'''todo:''' continue fleshing out this section. maybe add links to "howtos" when we've reached agreement between LL, OpenSim, PyOGP

=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|simplified trust model]]

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

==Authenticating Client Application Users to Agent Domain Servers==

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

==Authenticating Client Applications to Region Domain Servers==

Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.

Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.

Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.

==Authenticating Agent Domain Servers to Client Applications==

Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).

Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:

* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)

It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.

It also implies that:

* the Client Application SHOULD maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>

==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==

Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.

When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.

<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.

When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>

Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.

Clever readers will note that this implies:

* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.

Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)

=Specific Issues With Linden Lab Software=

'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.

==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==

Blergh. Okay, you caught us. We're using self-signed certificates.

In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.

In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.

So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.

The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.

Or we could use some set of common well-known CAs, like Verisign or somebody. Although they like charge money.

'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.

=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?

'''Teravus:''' One thing to note here, however.. is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently. The directions for setting it up are in *svn*/share/junkCA

Certain things don't work in SSL mode now. For example: teleporting from Vaak to a SSL enabled OpenSimulator region fails because Vaak rejects self signed certificates and upon reading the response, it terminates the connection. (So in OpenSimulator, you'll see Vaak invoke the cap, but it'll still fail because vaak doesn't read the response)

==Self Signed Certificates for Agent and Region Domain Authentication==
==Proposed Registration Authority for OpenSim Operators==

=Specific Issues With PyOGP Software=
'''Note:''' ''Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it''
=Discussions=
*Gridnauts IRC
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]

[[Category:AW Groupies]]
[[Category:Grid Interoperability]]
[[Category:AW Groupies User Pages]]

Talk:Open Grid Protocol

2008-10-06T21:06:59Z

Infinity Linden: /* Capability Lifetime */

== Choosing an Agent ==

=== Round 1 : Choosing an Agent ===

The credential presented by the viewer may be valid for more than one agent.
If so, then the viewer must specify the agent it wishes to control. If none is specified,
and there are multiple possible agents, then log in will fail, and contain a list of possible agents.
The viewer can then choose and reattempt login.

That looks like a security hole, because it means that a person who gets login credentials now knows something they did not prove they knew before, namely the agent list. It should not include a list of agents, instead, an identifiable agent should be considered part of the credentials necessary for login.

[[User:Lillie Yifu|Lillie Yifu]] 09:36, 22 August 2008 (PDT)

=== Round 2 : Agent Uniqueness is Checked After Account Authentication ===

Hey Lillie... sorry for taking so long to get back to this one...

If you look real close, you can see that the specification expects a compliant implementation to check for the multiple agent condition only after the account has been authenticated.

So... if you're a bad guy, you still have to know the account shared secret in order to get a list of agents on an account.

One "issue" with the specification is it's descriptive, not proscriptive. We don't define this as a requirement in the spec, because the spec defines stuff that flows over the wire. There are still interoperability profiles that will need to be hashed out, and defining that account authentication MUST occur before agent uniqueness is checked is one part of such an interoperability profile.

[[User:Infinity Linden|Infinity Linden]] 13:42, 6 October 2008(PDT)

== Capability Lifetime ==

=== Round 1 : Capability Lifetime ==

Since cryptologically secure means the amount of time since creation to forge, break, or steal. Shouldn't all capabilities expire? Shouldn't there be a way of indicating when a capability is set to expire, so that clients of that capability can renew the lease on it? Also having capabilities with known numbers of uses is very valuable, so that clients could hand them out, confident that if they were overly broadly disseminated, the risk is limited to so many invocations, even if that number is a larger number.

[[User:Lillie Yifu|Lillie Yifu]] 09:43, 22 August 2008 (PDT)

=== Round 2 : Leasing and Seed Caps ===

Hey Lillie... One thing to consider here is we don't want to introduce a TOCTOU (Time of Check, Time of Use) type vulnerability. Capabilities have a lifetime to ameliorate the TOCTOU ramifications implicit in capabilities. In other words, we don't (or at least shouldn't) do leasing on the capability's name, but on the permission it represents. In other words, if you have a capability named 'XXXXXXXX-XXXX-5XXX-XXXX-XXXXXXXXXXXX' which represents the right to rez your avatar in a given region, you don't want to renew that capability. Instead, what you _should_ do is request a new cap named 'YYYYYYYY-YYYY-5YYY-YYYY-YYYYYYYYYYYY' which represents the same thing, then expire the original cap. And... you should request this new capability using whatever authentication scheme you used to get the original cap. This way, if an untrusted third party happens to acquire the first cap, they won't have the ability to impersonate the agent indefinitely.

Now that i've said that... lemme run off to our simulator source and see if that's what we're actually doing.

With respect to caps with a wide number of uses... are you talking about seed caps? The expectation is that the seed cap is used just to get caps for other operations. We're expecting the viewer to get the list of subordinate caps once, then use those caps directly. In theory... after authenticating yourself to the agent domain and receiving the seed cap (which gives access to a list of subordinate caps), we could (and even should) expire the seed. That way, if a bad guy were able to get that seed, it would be expired by the time they could access it.

Again, we have the issue with the spec being descriptive rather than proscriptive. I'll see if I can add some text to upcoming drafts to either make it clear that this could / should be done, or write an interoperability profile that makes it more clear.

cheers, [[User:Infinity Linden|Infinity Linden]] 14:06, 6 October 2008 (PDT)

Talk:Open Grid Protocol

2008-10-06T20:44:44Z

Infinity Linden: /* Choosing an Agent */

Talk:Open Grid Protocol

2008-10-06T20:43:11Z

Infinity Linden: /* Choosing an Agent */

== Choosing an Agent ==

=== Problem Statement ===
Choosing an Agent

The credential presented by the viewer may be valid for more than one agent.
If so, then the viewer must specify the agent it wishes to control. If none is specified,
and there are multiple possible agents, then log in will fail, and contain a list of possible agents.
The viewer can then choose and reattempt login.

That looks like a security hole, because it means that a person who gets login credentials now knows something they did not prove they knew before, namely the agent list. It should not include a list of agents, instead, an identifiable agent should be considered part of the credentials necessary for login.

[[User:Lillie Yifu|Lillie Yifu]] 09:36, 22 August 2008 (PDT)

=== Solution Statement ===

Hey Lillie... sorry for taking so long to get back to this one...

If you look real close, you can see that the specification expects a compliant implementation to check for the multiple agent condition only after the account has been authenticated.

So... if you're a bad guy, you still have to know the account shared secret in order to get a list of agents on an account.

One "issue" with the specification is it's descriptive, not proscriptive. We don't define this as a requirement in the spec, because the spec defines stuff that flows over the wire. There are still interoperability profiles that will need to be hashed out, and defining that account authentication MUST occur before agent uniqueness is checked is one part of such an interoperability profile.

[[User:Infinity Linden|Infinity Linden]] 13:42, 6 October 2008(PDT)

== Capability Lifetime ==

Since cryptologically secure means the amount of time since creation to forge, break, or steal. Shouldn't all capabilities expire? Shouldn't there be a way of indicating when a capability is set to expire, so that clients of that capability can renew the lease on it? Also having capabilities with known numbers of uses is very valuable, so that clients could hand them out, confident that if they were overly broadly disseminated, the risk is limited to so many invocations, even if that number is a larger number.

[[User:Lillie Yifu|Lillie Yifu]] 09:43, 22 August 2008 (PDT)

LLSD

2008-10-02T18:40:50Z

Infinity Linden: Undo revision 94153 by Infinity Linden (Talk)

= The LLSD flexible data system =

The following text is from the comments in the source of the file:
linden\indra\common\llsd.cpp

LLSD stands [http://blog.secondlife.com/2006/07/19/web-services-serialization-format/#comment-101218][according to Andrew Linden] for '''Linden Lab Structured Data'''.

== Summary ==

LLSD provides a flexible data system similar to the data facilities of dynamic languages like Perl and Python. It is created to support exchange of structured data between loosly coupled systems. (Here, "loosly coupled" means not compiled together into the same module.)

Data in such exchanges must be highly tolerant of changes on either side such as:
- recompilation
- implementation in a different langauge
- addition of extra parameters
- execution of older versions (with fewer parameters)

To this aim, the C++ API of LLSD strives to be very easy to use, and to default to "the right thing" whereever possible. It is extremely tolerant of errors and unexpected situations.

The fundamental class is LLSD. LLSD is a value holding object. It holds one value that is either undefined, one of the scalar types, or a map or an array. LLSD objects have value semantics (copying them copies the value, though it can be considered efficient, due to sharing.), and mutable.

Undefined is the singular value given to LLSD objects that are not initialized with any data.

The scalar data types are:
* Boolean - true or false
* Integer - a 32 bit signed integer
* Real - a 64 bit IEEE 754 floating point value
* UUID - a 128 bit unique value
* String - a sequence of zero or more Unicode chracters
* Date - an absolute point in time, UTC, with resolution to the second
* URI - a String that is a URI
* Binary - a sequence of zero or more octets (unsigned bytes)

A map is a dictionary mapping String keys to LLSD values. The keys are unique within a map, and have only one value (though that value could be an LLSD array).

An array is a sequence of zero or more LLSD values.

== Scalar Accessors ==

Function: Fetch a scalar value, converting if needed and possible.

Conversion among the basic types, Boolean, Integer, Real and String, is fully defined. Each type can be converted to another with a reasonable interpretation. These conversions can be used as a convenience even when you know the data is in one format, but you want it in another. Of course, many of these conversions lose information.

Note: These conversions are not the same as Perl's. In particular, when converting a String to a Boolean, only the empty string converts to false. Converting the String "0" to Boolean results in true.

Conversion to and from UUID, Date, and URI is only defined to and from String. Conversion is defined to be information preserving for valid values of those types. These conversions can be used when one needs to convert data to or from another system that cannot handle these types natively, but can handle strings.

Conversion to and from Binary isn't defined.

Conversion of the Undefined value to any scalar type results in a reasonable null or zero value for the type.

== Automatic Cast Protection ==

These are not implemented on purpose. Without them, C++ can perform some conversions that are clearly not what the programmer intended.

If you get a linker error about these being missing, you have made mistake in your code. DO NOT IMPLEMENT THESE FUNCTIONS as a fix.

All of thse problems stem from trying to support char* in LLSD or in std::string. There are too many automatic casts that will lead to using an arbitrary pointer or scalar type to std::string.

== Attributes and Data ==
Attributes are only used for encoding parser and formatting instructions. The data in the elements is always data.

== Root Element ==
The root element is llsd. The root must have only one child element which can be any container or atomic type.

== Atomic Types ==
Each atomic type represents one value with type information. An atomic does not have a name, but may have attributes to specify format or processing considerations for the parser.
Consumers of atomics are encouraged to massage the data into the preferred native representation, but further serialization should honor the original type information if possible.

=== undefined ===
The undefined type is a placeholder to indicate something is there, but it has no value, and cannot be converted to any other atomic type. Though limited in this way, an undefined is still considered a first-class atomic, and is expected to behave like any other atomic structured data type at runtime.
==== Serialization example ====
<code>
<undef />
</code>

=== boolean ===
A true or false value.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||unity||
|-
|integer||true => 1, false => 0||
|-
|real||true => 1.0, false => 0.0||
|-
|uuid||n/a||
|-
|string||'true', 'false'||
|-
|binary||one byte us-ascii where true => 1, false => 0||
|-
|date||n/a||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>

<boolean>1</boolean>
<boolean>true</boolean>


<boolean>0</boolean>
<boolean>false</boolean>
<boolean />
</pre>

=== integer ===
A signed integer value with a representation of 32 bits.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||0 => false, all other values => true||
|-
|integer||unity||
|-
|real||closest representable number||
|-
|uuid||n/a||
|-
|string||human readable string||
|-
|binary||8 byte network byte order representation||
|-
|date||seconds since epoch||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<integer>289343</integer>
<integer>-3</integer>
<integer /> 
</pre>

=== real ===
A 64 bit double as defined by IEEE.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||exactly 0 => false, all other values => true||
|-
|integer||rounded to closest representable number||
|-
|real||unity||
|-
|uuid||n/a||
|-
|string||human readable string||
|-
|binary||8 byte network byte order representation||
|-
|date||seconds since epoch||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<real>-0.28334</real>
<real>2983287453.3848387</real>
<real /> 
</pre>

=== uuid ===
A 128 bit unsigned integer.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||null uuid => false, all other values => true||
|-
|integer||n/a||
|-
|real||n/a||
|-
|uuid||unity||
|-
|string||standard 8-4-4-4-12 serialization format||
|-
|binary||16 byte raw representation||
|-
|date||n/a||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<uuid>d7f4aeca-88f1-42a1-b385-b9db18abb255</uuid>
<uuid /> 
</pre>

=== string ===
A simple string of any character data which is intended to be human comprehensible.

Strings in the system that hold text a user might see or enter (chat, IM, notecards, AV names, region names,... basically almost everything!) should move to using a consistent set of acceptable characters. This set is:

* Unicode code points U+20 through U+10FFFD
** except U+D800 through U+DFFF
** except U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFE, U+2FFF ... U+10FFFE, U+10FFFF
** except U+FDDD through U+FDEF
* U+9 (tab, '\t')
* U+A (newline or line feed, '\n')
* U+D (carriage return, '\r')

Strings may be sequences of zero or more of these characters. Strings *may* be normalized by mapping line ending sequences to U+A. Do not rely on differences in strings that normalize to the same string.

These choices of valid strings are chosen from Unicode 4.0 which defines the following valid code points:
* Unicode code points U+0 through U+10FFFD
** except U+D800 through U+DFFF (the UTF-16 surrogate pair range)
** except U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFE, U+2FFF ... U+10FFFE, U+10FFFF
** except U+FDDD through U+FDEF (some historical screw up with Arabic)

The choice for special characters < U+20 is because XML defines acceptable text as all valid Unicode code points >= U+20, and U+9, U+A and U+D. The normalization is because XML defines that all line ending sequences are normalized to U+A.

See: [[Unicode In 5 Minutes]] for a brief introduction to Unicode.

==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||empty => false, all other values => true||
|-
|integer||A simple conversion of the initial characters to an integer||
|-
|real||A simple conversion of the initial characters to a real number||
|-
|uuid||A valid 8-4-4-4-12 is converted to a uuid, all other values => null uuid||
|-
|string||unity||
|-
|binary||raw representation of the characters||
|-
|date||An interpretation of the string as a date||
|-
|uri||An interpretation of the string as a link||
|}

==== Serialization examples ====
<pre>
<string>The quick brown fox jumped over the lazy dog.</string>
<string>540943c1-7142-4fdd-996f-fc90ed5dd3fa</string>
<string /> 
</pre>

=== binary data ===
A chunk of binary data.
The serialization format is allowed to specify an encoding. Parsers must support base64 encoding. Parsers may support base16 and base85.
==== Conversion ====
{|
||'''type'''||'''rules'''||
|-
||boolean||empty => false, all other values => true||
|-
||integer||len < 4 => 0, otherwise first four bytes are interpreted as a network byte order integer||
|-
||real||len < 8 => 0, otherwise first eight bytes are interpreted as a network byte order double||
|-
||uuid||len < 16 => null uuid, otherwise first sixteen bytes are interpreted as the raw binary uuid||
|-
||string||the raw binary data interpreted as utf-8 character data||
|-
||binary||unity||
|-
||date||n/a||
|-
||uri||the raw binary data interpreted as a utf-8 serialized link||
|}

==== Serialization examples ====
<pre>
<binary encoding="base64">cmFuZG9t</binary> 
<binary>dGhlIHF1aWNrIGJyb3duIGZveA==</binary> 
<binary /> 
</pre>

=== date ===
A specific point in time. Intervals or relative dates are not supported. The serialization and parser only understand ISO-8601 numeric encoding in UTC. The time may be omitted which will be interpreted as midnight at the start of the day.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||n/a||
|-
|integer||seconds since epoch||
|-
|real||seconds since epoch||
|-
|uuid||n/a||
|-
|string||standard serialization format||
|-
|binary||n/a||
|-
|date||unity||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<date>2006-02-01T14:29:53.43Z</date>
<date /> 
</pre>

=== uri ===
A link to an external resource. The data is expected to conform to [http://www.ietf.org/rfc/rfc2396.txt rfc 2396] for interpretation, meaning, serialization, and deserialization.
==== Conversion ====
{|
||'''type'''||'''rules'''||
|-
||boolean||n/a||
|-
||integer||n/a||
|-
||real||n/a||
|-
||uuid||n/a||
|-
||string||standard serialization format||
|-
||binary||n/a||
|-
||date||n/a||
|-
||uri||unity||
|}

==== Serialization examples ====
<pre>
<uri>http://sim956.agni.lindenlab.com:12035/runtime/agents</uri>
<uri /> 
</pre>

== Containers ==
Containers is a special data type which can contain any other data type including other containers.

=== map ===
A map of key and value pairs where key ordering is unspecified and keys are unique. The key is always interpreted as a character string and any character string is acceptable. If there are any elements in the map, it is serialized as a key followed by an atomic or container value. For every key, there must be one value.
Well formed and valid serialized maps may contain more non-unique keys. When a deserialized, the implementation should choose one of the the value objects, but that choice is not specified.
==== Serialization example ====
<pre>
<map>
<key>foo</key>
<string>bar</string>
<key>agent info</key>
<map>
<key>agent_id</key>
<uuid>93c73b16-cd86-434d-8b4a-76e12eee950a</uuid>
<key>name</key>
<string>testtest tester</string>
</map>
</map>
</pre>

=== array ===
An ordered collection of data members. Any member can be any atomic or container type.
==== Serialization example ====
<pre>
<array>
<real>7343.0194</real>
<array>
<map>
<key>offset</key>
<integer>9847</integer>
</map>
<string>da boom</string>
</array>
</array>
</pre>

= XML Serialization =
MIME type: <code>application/llsd+xml</code>

When possible, prefer using us-ascii or or UTF-8 xml encoding.

XML is the "standard" serialization format, being future-proof and readable by a wide variety of tools. The XML serialization should be preferred unless profiling reveals that the [[#Binary_Serialization | binary serialization]] provides an essential performance benefit. All the serialization examples in the above sections are of the XML serialization.

== DTD ==
<div style="font-size:1.6em;"><xml><!DOCTYPE llsd [
<!ELEMENT llsd (DATA)>
<!ELEMENT DATA (ATOMIC|map|array)>
<!ELEMENT ATOMIC (undef|boolean|integer|real|uuid|string|date|uri|binary)>
<!ELEMENT KEYDATA (key,DATA)>
<!ELEMENT key (#PCDATA)>
<!ELEMENT map (KEYDATA*)>
<!ELEMENT array (DATA*)>
<!ELEMENT undef (EMPTY)>
<!ELEMENT boolean (#PCDATA)>
<!ELEMENT integer (#PCDATA)>
<!ELEMENT real (#PCDATA)>
<!ELEMENT uuid (#PCDATA)>
<!ELEMENT string (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT uri (#PCDATA)>
<!ELEMENT binary (#PCDATA)>

<!ATTLIST string xml:space (default|preserve) 'preserve'>
<!ATTLIST binary encoding (base64|base16|base85) 'base64'>
]></xml></div>

== Example XML Output ==
This is a sample from a recently running sim (indention for readability):

<div style="font-size:1.6em;"><xml>$ curl http://localhost:12035/runtime/statistics
<?xml version="1.0" encoding="UTF-8"?>
<llsd>
<map>
<key>region_id</key>
<uuid>67153d5b-3659-afb4-8510-adda2c034649</uuid>
<key>scale</key>
<string>one minute</string>
<key>simulator statistics</key>
<map>
<key>time dilation</key><real>0.9878624</real>
<key>sim fps</key><real>44.38898</real>
<key>pysics fps</key><real>44.38906</real>
<key>agent updates per second</key><real>nan</real>
<key>lsl instructions per second</key><real>0</real>
<key>total task count</key><real>4</real>
<key>active task count</key><real>0</real>
<key>active script count</key><real>4</real>
<key>main agent count</key><real>0</real>
<key>child agent count</key><real>0</real>
<key>inbound packets per second</key><real>1.228283</real>
<key>outbound packets per second</key><real>1.277508</real>
<key>pending downloads</key><real>0</real>
<key>pending uploads</key><real>0.0001096525</real>
<key>frame ms</key><real>0.7757886</real>
<key>net ms</key><real>0.3152919</real>
<key>sim other ms</key><real>0.1826937</real>
<key>sim physics ms</key><real>0.04323055</real>
<key>agent ms</key><real>0.01599029</real>
<key>image ms</key><real>0.01865955</real>
<key>script ms</key><real>0.1338836</real>
</map>
</map>
</llsd></xml></div>

= Binary Serialization =
MIME type: <code>application/llsd+binary</code>

We also have support for binary serialization and deserialization in c++ and python. The binary format is useful when dealing where optimal parse time is necessary. Binary LLSD is the binary llsd prefix followed by a single LLSD element of any type.

<pre>
<?llsd/binary?>\n
</pre>

{| border="1"
|+ Binary element serialization
! type !! serialization !! notes
|-
| undef || '!'
|-
| true || '1'
|-
| false || '0'
|-
| integer || 'i' + htonl(value)
|-
| real || 'r' + htond(value)
|-
| uuid || 'u' + uuid || uuid is 16 bytes
|-
| binary || 'b' + htonl(binary.size()) + binary
|-
| string || 's' + htonl(string.size()) + string || notation serialization is considered valid
|-
| uri || 'l' + htonl(uri.size()) + uri
|-
| date || 'd' + htond(seconds_since_epoch)
|-
| array || '[' + htonl(array.length()) + (child0, child1, ...) + ']' || order is always preserved
|-
| map || '{' + htonl(map.length()) + ((key0,value0), (key1, value1), ...)+ '}' || order is not always preserved.
|}

<b>size()</b> is a byte count.

<b>length()</b> is a child count.

<b>htonl()</b> is a function to generate a 4 byte network byte order integer.

<b>htond()</b> is a function to generate an 8 byte network byte order double. htond is not a standard system call, but you can find a c implementation in <code>indra/llcommon/llsdserialize.cpp</code>.

= Notation Serialization =
We also have support for a serialization format meant for human readability. Parsing and formatting are currently only available in c++. Notation LLSD is the notation llsd prefix followed by a single LLSD element of any type.

<pre>
<?llsd/notation?>\n
</pre>

{| border="1"
|+ Binary element serialization
! type !! serialization !! notes
|-
| undef || '!'
|-
| true || <nowiki>'1' | 't' | 'T' | 'true' | 'TRUE'</nowiki>
|-
| false || <nowiki>'0' | 'f' | 'F' | 'false' | 'FALSE'</nowiki>
|-
| integer || 'i' str(value)
|-
| real || 'r' str(value)
|-
| uuid || 'u' str(uuid)
|-
| binary || <nowiki>'b(' str(size) ')"' raw_data '"' | 'b' base '"' encoded_data '"'</nowiki> || Base 16 and 64 encodings are supported.
|-
| string || <nowiki>" escaped_string " | ' escaped_string ' | 's(' str(size) ')"' raw_string '"'</nowiki> || When using single quotes, double quotes do not need escaping and vice versa.
|-
| uri || 'l"' escaped_uri '"' || See [http://www.faqs.org/rfcs/rfc1738.html rfc 1738] for encoding rules.
|-
| date || 'd"' YYYY-MM-DD 'T' HH:MM:SS [.FF] 'Z"' || Fractional seconds are optional
|-
| array || '[' object0 ',' object1 ',' ... ']' || order is always preserved
|-
| map || '{' string0:object0 ',' string1:object1 ',' ... '}' || order is not always preserved. The string is any supported string serialization format
|}

== String Escaping ==
Strings which contain non-printable characters delimited with quotes or double quotes require escaping. If a single quote delimited string contains single quotes, those must be escaped. If a double quote delimited string contains double quotes, the double quotes must be escaped.

To escape the delimiter character, prefix a backslash. Backslashes must always be escaped with another backslash.

"And then he said, \"I have nothing more to say on the subject.\""

'Look in "C:\\linden\\"'

The most generic escaping is to specify a hex value of the byte after a literal backslash and character 'x'. This can be used for any character and is required for all non-printable characters which do not have an abbreviation. For example:

\x0C

Serialized strings should only contain UTF-8 characters, so non-printable characters other than tab, newline, and carriage return should be avoided. However, common non-printable characters have short-hand abbreviations.

{| border="1"
|+ Notation abbreviations
! character !! value !! serialization
|-
| alert/bell || 0x7 || \a
|-
| backspace || 0x8 || \b
|-
| form feed || 0xc || \f
|-
| newline || 0xa || \n
|-
| carriage return || 0xd || \r
|-
| horizontal tab || 0x9 || \t
|-
| vertical tab || 0xb || \v
|}

== Example Notation Output ==
This is an excerpt from an agent request to enter a region serialized as notation:
<pre>
[
{'destination':'http://secondlife.com'},
{'version':i1},
{
'agent_id':u3c115e51-04f4-523c-9fa6-98aff1034730,
'session_id':u2c585cec-038c-40b0-b42e-a25ebab4d132,
'circuit_code':i1075,
'first_name':'Phoenix',
'last_name':'Linden',
'position':[r70.9247,r254.378,r38.7304],
'look_at':[r-0.043753,r-0.999042,r0],
'granters':[ua2e76fcd-9360-4f6d-a924-000000000003],
'attachment_data':
[
{
'attachment_point':i2,
'item_id':ud6852c11-a74e-309a-0462-50533f1ef9b3,
'asset_id':uc69b29b1-8944-58ae-a7c5-2ca7b23e22fb
},
{
'attachment_point':i10,
'item_id':uff852c22-a74e-309a-0462-50533f1ef900,
'asset_id':u5868dd20-c25a-47bd-8b4c-dedc99ef9479
}
]
}
]
</pre>

<pre>
[
{
'creation-date':d"2007-03-15T18:30:18Z",
'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730
},
s(10)"0123456789",
"Where's the beef?",
'Over here.',
b(160)"default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}

touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}",
b64"AABAAAAAAAAAAAIAAAA//wAAP/8AAADgAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABkAAAAZAAAAAAAAAAAAAAAZAAAAAAAAAABAAAAAAAAAAAAAAAAAAAABQAAAAEAAAAQAAAAAAAA
AAUAAAAFAAAAABAAAAAAAAAAPgAAAAQAAAAFAGNbXgAAAABgSGVsbG8sIEF2YXRhciEAZgAAAABc
XgAAAAhwEQjRABeVAAAABQBjW14AAAAAYFRvdWNoZWQuAGYAAAAAXF4AAAAIcBEI0QAXAZUAAEAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
]
</pre>

= Guidelines =

=== Questions & Things To Do ===

Would Binary be more convenient as usigned char* buffer semantics?

Should Binary be convertable to/from String, and if so how?
* as UTF8 encoded strings (making not like UUID<->String)
* as Base64 or Base96 encoded (making like UUID<->String)

Conversions to std::string and LLUUID do not result in easy assignment to std::string, LLString or LLUUID due to non-unique conversion paths.

LLSD

2008-10-01T23:09:19Z

Infinity Linden: Undo revision 90766 by SignpostMarv Martin (Talk)

= The LLSD flexible data system =

The following text is from the comments in the source of the file:
linden\indra\common\llsd.cpp

LLSD stands [http://blog.secondlife.com/2006/07/19/web-services-serialization-format/#comment-101218][according to Andrew Linden] for '''Linden Lab Structured Data'''.

== Summary ==

LLSD provides a flexible data system similar to the data facilities of dynamic languages like Perl and Python. It is created to support exchange of structured data between loosly coupled systems. (Here, "loosly coupled" means not compiled together into the same module.)

Data in such exchanges must be highly tolerant of changes on either side such as:
- recompilation
- implementation in a different langauge
- addition of extra parameters
- execution of older versions (with fewer parameters)

To this aim, the C++ API of LLSD strives to be very easy to use, and to default to "the right thing" whereever possible. It is extremely tolerant of errors and unexpected situations.

The fundamental class is LLSD. LLSD is a value holding object. It holds one value that is either undefined, one of the scalar types, or a map or an array. LLSD objects have value semantics (copying them copies the value, though it can be considered efficient, due to sharing.), and mutable.

Undefined is the singular value given to LLSD objects that are not initialized with any data.

The scalar data types are:
* Boolean - true or false
* Integer - a 32 bit signed integer
* Real - a 64 bit IEEE 754 floating point value
* UUID - a 128 bit unique value
* String - a sequence of zero or more Unicode chracters
* Date - an absolute point in time, UTC, with resolution to the second
* URI - a String that is a URI
* Binary - a sequence of zero or more octets (unsigned bytes)

A map is a dictionary mapping String keys to LLSD values. The keys are unique within a map, and have only one value (though that value could be an LLSD array).

An array is a sequence of zero or more LLSD values.

== Scalar Accessors ==

Function: Fetch a scalar value, converting if needed and possible.

Conversion among the basic types, Boolean, Integer, Real and String, is fully defined. Each type can be converted to another with a reasonable interpretation. These conversions can be used as a convenience even when you know the data is in one format, but you want it in another. Of course, many of these conversions lose information.

Note: These conversions are not the same as Perl's. In particular, when converting a String to a Boolean, only the empty string converts to false. Converting the String "0" to Boolean results in true.

Conversion to and from UUID, Date, and URI is only defined to and from String. Conversion is defined to be information preserving for valid values of those types. These conversions can be used when one needs to convert data to or from another system that cannot handle these types natively, but can handle strings.

Conversion to and from Binary isn't defined.

Conversion of the Undefined value to any scalar type results in a reasonable null or zero value for the type.

== Automatic Cast Protection ==

These are not implemented on purpose. Without them, C++ can perform some conversions that are clearly not what the programmer intended.

If you get a linker error about these being missing, you have made mistake in your code. DO NOT IMPLEMENT THESE FUNCTIONS as a fix.

All of thse problems stem from trying to support char* in LLSD or in std::string. There are too many automatic casts that will lead to using an arbitrary pointer or scalar type to std::string.

== Attributes and Data ==
Attributes are only used for encoding parser and formatting instructions. The data in the elements is always data.

== Root Element ==
The root element is llsd. The root must have only one child element which can be any container or atomic type.

== Atomic Types ==
Each atomic type represents one value with type information. An atomic does not have a name, but may have attributes to specify format or processing considerations for the parser.
Consumers of atomics are encouraged to massage the data into the preferred native representation, but further serialization should honor the original type information if possible.

=== undefined ===
The undefined type is a placeholder to indicate something is there, but it has no value, and cannot be converted to any other atomic type. Though limited in this way, an undefined is still considered a first-class atomic, and is expected to behave like any other atomic structured data type at runtime.
==== Serialization example ====
<code>
<undef />
</code>

=== boolean ===
A true or false value.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||unity||
|-
|integer||true => 1, false => 0||
|-
|real||true => 1.0, false => 0.0||
|-
|uuid||n/a||
|-
|string||'true', 'false'||
|-
|binary||one byte us-ascii where true => 1, false => 0||
|-
|date||n/a||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>

<boolean>1</boolean>
<boolean>true</boolean>


<boolean>0</boolean>
<boolean>false</boolean>
<boolean />
</pre>

=== integer ===
A signed integer value with a representation of 32 bits.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||0 => false, all other values => true||
|-
|integer||unity||
|-
|real||closest representable number||
|-
|uuid||n/a||
|-
|string||human readable string||
|-
|binary||8 byte network byte order representation||
|-
|date||seconds since epoch||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<integer>289343</integer>
<integer>-3</integer>
<integer /> 
</pre>

=== real ===
A 64 bit double as defined by IEEE.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||exactly 0 => false, all other values => true||
|-
|integer||rounded to closest representable number||
|-
|real||unity||
|-
|uuid||n/a||
|-
|string||human readable string||
|-
|binary||8 byte network byte order representation||
|-
|date||seconds since epoch||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<real>-0.28334</real>
<real>2983287453.3848387</real>
<real /> 
</pre>

=== uuid ===
A 128 bit unsigned integer.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||null uuid => false, all other values => true||
|-
|integer||n/a||
|-
|real||n/a||
|-
|uuid||unity||
|-
|string||standard 8-4-4-4-12 serialization format||
|-
|binary||16 byte raw representation||
|-
|date||n/a||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<uuid>d7f4aeca-88f1-42a1-b385-b9db18abb255</uuid>
<uuid /> 
</pre>

=== string ===
A simple string of any character data which is intended to be human comprehensible.

Strings in the system that hold text a user might see or enter (chat, IM, notecards, AV names, region names,... basically almost everything!) should move to using a consistent set of acceptable characters. This set is:

* Unicode code points U+20 through U+10FFFD
** except U+D800 through U+DFFF
** except U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFE, U+2FFF ... U+10FFFE, U+10FFFF
** except U+FDDD through U+FDEF
* U+9 (tab, '\t')
* U+A (newline or line feed, '\n')
* U+D (carriage return, '\r')

Strings may be sequences of zero or more of these characters. Strings *may* be normalized by mapping line ending sequences to U+A. Do not rely on differences in strings that normalize to the same string.

These choices of valid strings are chosen from Unicode 4.0 which defines the following valid code points:
* Unicode code points U+0 through U+10FFFD
** except U+D800 through U+DFFF (the UTF-16 surrogate pair range)
** except U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFE, U+2FFF ... U+10FFFE, U+10FFFF
** except U+FDDD through U+FDEF (some historical screw up with Arabic)

The choice for special characters < U+20 is because XML defines acceptable text as all valid Unicode code points >= U+20, and U+9, U+A and U+D. The normalization is because XML defines that all line ending sequences are normalized to U+A.

See: [[Unicode In 5 Minutes]] for a brief introduction to Unicode.

==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||empty => false, all other values => true||
|-
|integer||A simple conversion of the initial characters to an integer||
|-
|real||A simple conversion of the initial characters to a real number||
|-
|uuid||A valid 8-4-4-4-12 is converted to a uuid, all other values => null uuid||
|-
|string||unity||
|-
|binary||raw representation of the characters||
|-
|date||An interpretation of the string as a date||
|-
|uri||An interpretation of the string as a link||
|}

==== Serialization examples ====
<pre>
<string>The quick brown fox jumped over the lazy dog.</string>
<string>540943c1-7142-4fdd-996f-fc90ed5dd3fa</string>
<string /> 
</pre>

=== binary data ===
A chunk of binary data.
The serialization format is allowed to specify an encoding. Parsers must support base64 encoding. Parsers may support base16 and base85.
==== Conversion ====
{|
||'''type'''||'''rules'''||
|-
||boolean||empty => false, all other values => true||
|-
||integer||len < 4 => 0, otherwise first four bytes are interpreted as a network byte order integer||
|-
||real||len < 8 => 0, otherwise first eight bytes are interpreted as a network byte order double||
|-
||uuid||len < 16 => null uuid, otherwise first sixteen bytes are interpreted as the raw binary uuid||
|-
||string||the raw binary data interpreted as utf-8 character data||
|-
||binary||unity||
|-
||date||n/a||
|-
||uri||the raw binary data interpreted as a utf-8 serialized link||
|}

==== Serialization examples ====
<pre>
<binary encoding="base64">cmFuZG9t</binary> 
<binary>dGhlIHF1aWNrIGJyb3duIGZveA==</binary> 
<binary /> 
</pre>

=== date ===
A specific point in time. Intervals or relative dates are not supported. The serialization and parser only understand ISO-8601 numeric encoding in UTC. The time may be omitted which will be interpreted as midnight at the start of the day.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||n/a||
|-
|integer||seconds since epoch||
|-
|real||seconds since epoch||
|-
|uuid||n/a||
|-
|string||standard serialization format||
|-
|binary||n/a||
|-
|date||unity||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<date>2006-02-01T14:29:53.43Z</date>
<date /> 
</pre>

=== uri ===
A link to an external resource. The data is expected to conform to [http://www.ietf.org/rfc/rfc2396.txt rfc 2396] for interpretation, meaning, serialization, and deserialization.
==== Conversion ====
{|
||'''type'''||'''rules'''||
|-
||boolean||n/a||
|-
||integer||n/a||
|-
||real||n/a||
|-
||uuid||n/a||
|-
||string||standard serialization format||
|-
||binary||n/a||
|-
||date||n/a||
|-
||uri||unity||
|}

==== Serialization examples ====
<pre>
<uri>http://sim956.agni.lindenlab.com:12035/runtime/agents</uri>
<uri /> 
</pre>

== Containers ==
Containers is a special data type which can contain any other data type including other containers.

=== map ===
A map of key and value pairs where key ordering is unspecified and keys are unique. The key is always interpreted as a character string and any character string is acceptable. If there are any elements in the map, it is serialized as a key followed by an atomic or container value. For every key, there must be one value.
Well formed and valid serialized maps may contain more non-unique keys. When a deserialized, the implementation should choose one of the the value objects, but that choice is not specified.
==== Serialization example ====
<pre>
<map>
<key>foo</key>
<string>bar</string>
<key>agent info</key>
<map>
<key>agent_id</key>
<uuid>93c73b16-cd86-434d-8b4a-76e12eee950a</uuid>
<key>name</key>
<string>testtest tester</string>
</map>
</map>
</pre>

=== array ===
An ordered collection of data members. Any member can be any atomic or container type.
==== Serialization example ====
<pre>
<array>
<real>7343.0194</real>
<array>
<map>
<key>offset</key>
<integer>9847</integer>
</map>
<string>da boom</string>
</array>
</array>
</pre>

= XML Serialization =
MIME type: <code>application/llsd+xml</code>

When possible, prefer using us-ascii or or UTF-8 xml encoding.

XML is the "standard" serialization format, being future-proof and readable by a wide variety of tools. The XML serialization should be preferred unless profiling reveals that the [[#Binary_Serialization | binary serialization]] provides an essential performance benefit. All the serialization examples in the above sections are of the XML serialization.

== DTD ==
<div style="font-size:1.6em;"><xml><!DOCTYPE llsd [
<!ELEMENT llsd (DATA)>
<!ELEMENT DATA (ATOMIC|map|array)>
<!ELEMENT ATOMIC (undef|boolean|integer|real|uuid|string|date|uri|binary)>
<!ELEMENT KEYDATA (key,DATA)>
<!ELEMENT key (#PCDATA)>
<!ELEMENT map (KEYDATA*)>
<!ELEMENT array (DATA*)>
<!ELEMENT undef (EMPTY)>
<!ELEMENT boolean (#PCDATA)>
<!ELEMENT integer (#PCDATA)>
<!ELEMENT real (#PCDATA)>
<!ELEMENT uuid (#PCDATA)>
<!ELEMENT string (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT uri (#PCDATA)>
<!ELEMENT binary (#PCDATA)>

<!ATTLIST string xml:space (default|preserve) 'preserve'>
<!ATTLIST binary encoding CDATA "base64">
]></xml></div>

== Example XML Output ==
This is a sample from a recently running sim (indention for readability):

<div style="font-size:1.6em;"><xml>$ curl http://localhost:12035/runtime/statistics
<?xml version="1.0" encoding="UTF-8"?>
<llsd>
<map>
<key>region_id</key>
<uuid>67153d5b-3659-afb4-8510-adda2c034649</uuid>
<key>scale</key>
<string>one minute</string>
<key>simulator statistics</key>
<map>
<key>time dilation</key><real>0.9878624</real>
<key>sim fps</key><real>44.38898</real>
<key>pysics fps</key><real>44.38906</real>
<key>agent updates per second</key><real>nan</real>
<key>lsl instructions per second</key><real>0</real>
<key>total task count</key><real>4</real>
<key>active task count</key><real>0</real>
<key>active script count</key><real>4</real>
<key>main agent count</key><real>0</real>
<key>child agent count</key><real>0</real>
<key>inbound packets per second</key><real>1.228283</real>
<key>outbound packets per second</key><real>1.277508</real>
<key>pending downloads</key><real>0</real>
<key>pending uploads</key><real>0.0001096525</real>
<key>frame ms</key><real>0.7757886</real>
<key>net ms</key><real>0.3152919</real>
<key>sim other ms</key><real>0.1826937</real>
<key>sim physics ms</key><real>0.04323055</real>
<key>agent ms</key><real>0.01599029</real>
<key>image ms</key><real>0.01865955</real>
<key>script ms</key><real>0.1338836</real>
</map>
</map>
</llsd></xml></div>

= Binary Serialization =
MIME type: <code>application/llsd+binary</code>

We also have support for binary serialization and deserialization in c++ and python. The binary format is useful when dealing where optimal parse time is necessary. Binary LLSD is the binary llsd prefix followed by a single LLSD element of any type.

<pre>
<?llsd/binary?>\n
</pre>

{| border="1"
|+ Binary element serialization
! type !! serialization !! notes
|-
| undef || '!'
|-
| true || '1'
|-
| false || '0'
|-
| integer || 'i' + htonl(value)
|-
| real || 'r' + htond(value)
|-
| uuid || 'u' + uuid || uuid is 16 bytes
|-
| binary || 'b' + htonl(binary.size()) + binary
|-
| string || 's' + htonl(string.size()) + string || notation serialization is considered valid
|-
| uri || 'l' + htonl(uri.size()) + uri
|-
| date || 'd' + htond(seconds_since_epoch)
|-
| array || '[' + htonl(array.length()) + (child0, child1, ...) + ']' || order is always preserved
|-
| map || '{' + htonl(map.length()) + ((key0,value0), (key1, value1), ...)+ '}' || order is not always preserved.
|}

<b>size()</b> is a byte count.

<b>length()</b> is a child count.

<b>htonl()</b> is a function to generate a 4 byte network byte order integer.

<b>htond()</b> is a function to generate an 8 byte network byte order double. htond is not a standard system call, but you can find a c implementation in <code>indra/llcommon/llsdserialize.cpp</code>.

= Notation Serialization =
We also have support for a serialization format meant for human readability. Parsing and formatting are currently only available in c++. Notation LLSD is the notation llsd prefix followed by a single LLSD element of any type.

<pre>
<?llsd/notation?>\n
</pre>

{| border="1"
|+ Binary element serialization
! type !! serialization !! notes
|-
| undef || '!'
|-
| true || <nowiki>'1' | 't' | 'T' | 'true' | 'TRUE'</nowiki>
|-
| false || <nowiki>'0' | 'f' | 'F' | 'false' | 'FALSE'</nowiki>
|-
| integer || 'i' str(value)
|-
| real || 'r' str(value)
|-
| uuid || 'u' str(uuid)
|-
| binary || <nowiki>'b(' str(size) ')"' raw_data '"' | 'b' base '"' encoded_data '"'</nowiki> || Base 16 and 64 encodings are supported.
|-
| string || <nowiki>" escaped_string " | ' escaped_string ' | 's(' str(size) ')"' raw_string '"'</nowiki> || When using single quotes, double quotes do not need escaping and vice versa.
|-
| uri || 'l"' escaped_uri '"' || See [http://www.faqs.org/rfcs/rfc1738.html rfc 1738] for encoding rules.
|-
| date || 'd"' YYYY-MM-DD 'T' HH:MM:SS [.FF] 'Z"' || Fractional seconds are optional
|-
| array || '[' object0 ',' object1 ',' ... ']' || order is always preserved
|-
| map || '{' string0:object0 ',' string1:object1 ',' ... '}' || order is not always preserved. The string is any supported string serialization format
|}

== String Escaping ==
Strings which contain non-printable characters delimited with quotes or double quotes require escaping. If a single quote delimited string contains single quotes, those must be escaped. If a double quote delimited string contains double quotes, the double quotes must be escaped.

To escape the delimiter character, prefix a backslash. Backslashes must always be escaped with another backslash.

"And then he said, \"I have nothing more to say on the subject.\""

'Look in "C:\\linden\\"'

The most generic escaping is to specify a hex value of the byte after a literal backslash and character 'x'. This can be used for any character and is required for all non-printable characters which do not have an abbreviation. For example:

\x0C

Serialized strings should only contain UTF-8 characters, so non-printable characters other than tab, newline, and carriage return should be avoided. However, common non-printable characters have short-hand abbreviations.

{| border="1"
|+ Notation abbreviations
! character !! value !! serialization
|-
| alert/bell || 0x7 || \a
|-
| backspace || 0x8 || \b
|-
| form feed || 0xc || \f
|-
| newline || 0xa || \n
|-
| carriage return || 0xd || \r
|-
| horizontal tab || 0x9 || \t
|-
| vertical tab || 0xb || \v
|}

== Example Notation Output ==
This is an excerpt from an agent request to enter a region serialized as notation:
<pre>
[
{'destination':'http://secondlife.com'},
{'version':i1},
{
'agent_id':u3c115e51-04f4-523c-9fa6-98aff1034730,
'session_id':u2c585cec-038c-40b0-b42e-a25ebab4d132,
'circuit_code':i1075,
'first_name':'Phoenix',
'last_name':'Linden',
'position':[r70.9247,r254.378,r38.7304],
'look_at':[r-0.043753,r-0.999042,r0],
'granters':[ua2e76fcd-9360-4f6d-a924-000000000003],
'attachment_data':
[
{
'attachment_point':i2,
'item_id':ud6852c11-a74e-309a-0462-50533f1ef9b3,
'asset_id':uc69b29b1-8944-58ae-a7c5-2ca7b23e22fb
},
{
'attachment_point':i10,
'item_id':uff852c22-a74e-309a-0462-50533f1ef900,
'asset_id':u5868dd20-c25a-47bd-8b4c-dedc99ef9479
}
]
}
]
</pre>

<pre>
[
{
'creation-date':d"2007-03-15T18:30:18Z",
'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730
},
s(10)"0123456789",
"Where's the beef?",
'Over here.',
b(160)"default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}

touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}",
b64"AABAAAAAAAAAAAIAAAA//wAAP/8AAADgAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABkAAAAZAAAAAAAAAAAAAAAZAAAAAAAAAABAAAAAAAAAAAAAAAAAAAABQAAAAEAAAAQAAAAAAAA
AAUAAAAFAAAAABAAAAAAAAAAPgAAAAQAAAAFAGNbXgAAAABgSGVsbG8sIEF2YXRhciEAZgAAAABc
XgAAAAhwEQjRABeVAAAABQBjW14AAAAAYFRvdWNoZWQuAGYAAAAAXF4AAAAIcBEI0QAXAZUAAEAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
]
</pre>

= Guidelines =

=== Questions & Things To Do ===

Would Binary be more convenient as usigned char* buffer semantics?

Should Binary be convertable to/from String, and if so how?
* as UTF8 encoded strings (making not like UUID<->String)
* as Base64 or Base96 encoded (making like UUID<->String)

Conversions to std::string and LLUUID do not result in easy assignment to std::string, LLString or LLUUID due to non-unique conversion paths.

LLSD

2008-10-01T23:09:00Z

Infinity Linden: Undo revision 94148 by Infinity Linden (Talk)

Talk:LLSD

2008-10-01T22:59:14Z

Infinity Linden:

{{Open Source Talk Page}}

== LLSD JSON-ish notation ==

The login sequence appears to use "binary" LLSD for two of the variables, home and look_at. Unfortunately the format doesn't match up exactly with what is documented on this wiki. Sample values:

{'region_handle':[r255232, r256512], 'position':[r33.6, r33.71, r43.13], 'look_at':[r34.6, r33.71, r43.13]}

[r0.99967899999999998428,r-0.025334599999999998787,r0]

No size values, and the map keys are encased in single quotes. Is this normal? -- {{Unsigned|Eddy Stryker}}

:Oh wow, notation format. Ummmmm, I never documented that, did I. LLSD started it's life as a json-like language, with a well defined serialization which is not actually documented. I'll get on that. [[User:Phoenix Linden|Phoenix Linden]] 16:10, 6 April 2007 (PDT)
:Documentation has been added. [[User:Phoenix Linden|Phoenix Linden]] 17:34, 12 April 2007 (PDT)

== Versioning? ==

Personally I miss a few things here, especially the versioning/compatibility. Sure you can asume that older request just have less keys in a map, and that might work well for things like statistics results. But as soon as you want to call a method, it is much better to make the version obvious. You can encode that in a key/value pair, but it is much better to have that in a fixed element for routing (you can route requests for inventories to different servers, depending on the interface version)

I see a Version:i1 in the notation example for the teleport, which makes it clear, that this element is used already in LL. Maybe it is hard for you to make it to a llsd envelop, but I think you guys will have great use for it.

<pre><llsd>
<method version="1" interface="simstatistics" message="result" />
...</pre>

or something like that.--[[User:Bernd Elswit|Bernd Elswit]] 10:27, 18 May 2007 (PDT)

== Efficient binary support ==

maybe a more efficient binary transport can be added, too? For example Adobe's ASCII85 allows better compression (however you need to escape less-than and ampersand and CDATA). Very efficient could be precalculated huffman tables for the most common file formats.

Sample code at the end of the page: http://www.javaworld.com/javaworld/javatips/jw-javatip117.html

--[[User:Bernd Elswit|Bernd Elswit]] 10:26, 18 May 2007 (PDT)

:Any time that we need to conserve space or cpu resources, we will use zlib routines or [[LLSD#Binary_Serialization|binary serialization]]. [[User:Phoenix Linden|Phoenix Linden]] 12:41, 21 May 2007 (PDT)

== hexadecimal ? ==

does the integer type allow hexadecimal values ? e.g. 0xffcc00 instead of entering 16763904 ?

[[User:SignpostMarv Martin|SignpostMarv Martin]] 09:54, 31 May 2007 (PDT)

== Binary map and array encoding ? ==
The description is not clear how the delimiters for map and array elements should be encoded.
See here:

<pre>
array '[' + htonl(array.length()) + ''(''child0'','' child1'','' ...'')'' + ']'

map '{' + htonl(map.length()) + ''((''key0'',''value0''),(''key1, value1''),'' ...'')'' + '}'
</pre>

Especially the binary encoding of the <pre>''</pre> marked values is not defined. As I am sitting at an implementation of this, I will try with the supposed reference implementation llsd.py and see what that actually does for this part.
--[[User:Leffard Lassard|Leffard Lassard]] 10:04, 27 March 2008 (PDT)

From my own research it is more like this:

<pre>
array '[' + htonl(array.length()) + child0 + child1 + ']'

map '{' + htonl(map.length()) + 'k' + htonl(key0.length) + key0 + value0 + 'k' + htonl(key1.length) + key1 + value 1 ... + '}'
</pre>

--[[User:Leffard Lassard|Leffard Lassard]] 11:26, 28 March 2008 (PDT)

== XML <-> Notation? ==

The XML format is, let's face it, not fun to read or write, for humans, in those weird cases where humans have to. Is there a serialization converter, somewhere, or should I just rig my own? --[[User:Ky Aska|Ky Aska]] 06:12, 3 June 2008 (PDT)

== Motivations Behind LLSD ==

Just a quick note to say i've been having discussions with peeps about why LLSD was invented in the first place; more discussions than I ever thought I would have on the subject. The best answer I could give was a) we like dynamic data models and b) it helps a bit to avoid the Fragile Binary Interface problem. If we ever get around to updating the intro, we may want to mention why dynamic data models are "nice" from an agile programming perspective and why FBI is bad. And BTW, here's the wikipedia entry on FBI: http://en.wikipedia.org/wiki/Fragile_binary_interface_problem . --[[User:Infinity Linden|Infinity Linden]]

== base85 considered harmful ==

Please note: base85 as an encoding for binary elements in the XML serialization of LLSD data is not canonical.

LLSD

2008-10-01T22:55:28Z

Infinity Linden:

= The LLSD flexible data system =

The following text is from the comments in the source of the file:
linden\indra\common\llsd.cpp

LLSD stands [http://blog.secondlife.com/2006/07/19/web-services-serialization-format/#comment-101218][according to Andrew Linden] for '''Linden Lab Structured Data'''.

== Summary ==

LLSD provides a flexible data system similar to the data facilities of dynamic languages like Perl and Python. It is created to support exchange of structured data between loosly coupled systems. (Here, "loosly coupled" means not compiled together into the same module.)

Data in such exchanges must be highly tolerant of changes on either side such as:
- recompilation
- implementation in a different langauge
- addition of extra parameters
- execution of older versions (with fewer parameters)

To this aim, the C++ API of LLSD strives to be very easy to use, and to default to "the right thing" whereever possible. It is extremely tolerant of errors and unexpected situations.

The fundamental class is LLSD. LLSD is a value holding object. It holds one value that is either undefined, one of the scalar types, or a map or an array. LLSD objects have value semantics (copying them copies the value, though it can be considered efficient, due to sharing.), and mutable.

Undefined is the singular value given to LLSD objects that are not initialized with any data.

The scalar data types are:
* Boolean - true or false
* Integer - a 32 bit signed integer
* Real - a 64 bit IEEE 754 floating point value
* UUID - a 128 bit unique value
* String - a sequence of zero or more Unicode chracters
* Date - an absolute point in time, UTC, with resolution to the second
* URI - a String that is a URI
* Binary - a sequence of zero or more octets (unsigned bytes)

A map is a dictionary mapping String keys to LLSD values. The keys are unique within a map, and have only one value (though that value could be an LLSD array).

An array is a sequence of zero or more LLSD values.

== Scalar Accessors ==

Function: Fetch a scalar value, converting if needed and possible.

Conversion among the basic types, Boolean, Integer, Real and String, is fully defined. Each type can be converted to another with a reasonable interpretation. These conversions can be used as a convenience even when you know the data is in one format, but you want it in another. Of course, many of these conversions lose information.

Note: These conversions are not the same as Perl's. In particular, when converting a String to a Boolean, only the empty string converts to false. Converting the String "0" to Boolean results in true.

Conversion to and from UUID, Date, and URI is only defined to and from String. Conversion is defined to be information preserving for valid values of those types. These conversions can be used when one needs to convert data to or from another system that cannot handle these types natively, but can handle strings.

Conversion to and from Binary isn't defined.

Conversion of the Undefined value to any scalar type results in a reasonable null or zero value for the type.

== Automatic Cast Protection ==

These are not implemented on purpose. Without them, C++ can perform some conversions that are clearly not what the programmer intended.

If you get a linker error about these being missing, you have made mistake in your code. DO NOT IMPLEMENT THESE FUNCTIONS as a fix.

All of thse problems stem from trying to support char* in LLSD or in std::string. There are too many automatic casts that will lead to using an arbitrary pointer or scalar type to std::string.

== Attributes and Data ==
Attributes are only used for encoding parser and formatting instructions. The data in the elements is always data.

== Root Element ==
The root element is llsd. The root must have only one child element which can be any container or atomic type.

== Atomic Types ==
Each atomic type represents one value with type information. An atomic does not have a name, but may have attributes to specify format or processing considerations for the parser.
Consumers of atomics are encouraged to massage the data into the preferred native representation, but further serialization should honor the original type information if possible.

=== undefined ===
The undefined type is a placeholder to indicate something is there, but it has no value, and cannot be converted to any other atomic type. Though limited in this way, an undefined is still considered a first-class atomic, and is expected to behave like any other atomic structured data type at runtime.
==== Serialization example ====
<code>
<undef />
</code>

=== boolean ===
A true or false value.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||unity||
|-
|integer||true => 1, false => 0||
|-
|real||true => 1.0, false => 0.0||
|-
|uuid||n/a||
|-
|string||'true', 'false'||
|-
|binary||one byte us-ascii where true => 1, false => 0||
|-
|date||n/a||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>

<boolean>1</boolean>
<boolean>true</boolean>


<boolean>0</boolean>
<boolean>false</boolean>
<boolean />
</pre>

=== integer ===
A signed integer value with a representation of 32 bits.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||0 => false, all other values => true||
|-
|integer||unity||
|-
|real||closest representable number||
|-
|uuid||n/a||
|-
|string||human readable string||
|-
|binary||8 byte network byte order representation||
|-
|date||seconds since epoch||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<integer>289343</integer>
<integer>-3</integer>
<integer /> 
</pre>

=== real ===
A 64 bit double as defined by IEEE.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||exactly 0 => false, all other values => true||
|-
|integer||rounded to closest representable number||
|-
|real||unity||
|-
|uuid||n/a||
|-
|string||human readable string||
|-
|binary||8 byte network byte order representation||
|-
|date||seconds since epoch||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<real>-0.28334</real>
<real>2983287453.3848387</real>
<real /> 
</pre>

=== uuid ===
A 128 bit unsigned integer.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||null uuid => false, all other values => true||
|-
|integer||n/a||
|-
|real||n/a||
|-
|uuid||unity||
|-
|string||standard 8-4-4-4-12 serialization format||
|-
|binary||16 byte raw representation||
|-
|date||n/a||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<uuid>d7f4aeca-88f1-42a1-b385-b9db18abb255</uuid>
<uuid /> 
</pre>

=== string ===
A simple string of any character data which is intended to be human comprehensible.

Strings in the system that hold text a user might see or enter (chat, IM, notecards, AV names, region names,... basically almost everything!) should move to using a consistent set of acceptable characters. This set is:

* Unicode code points U+20 through U+10FFFD
** except U+D800 through U+DFFF
** except U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFE, U+2FFF ... U+10FFFE, U+10FFFF
** except U+FDDD through U+FDEF
* U+9 (tab, '\t')
* U+A (newline or line feed, '\n')
* U+D (carriage return, '\r')

Strings may be sequences of zero or more of these characters. Strings *may* be normalized by mapping line ending sequences to U+A. Do not rely on differences in strings that normalize to the same string.

These choices of valid strings are chosen from Unicode 4.0 which defines the following valid code points:
* Unicode code points U+0 through U+10FFFD
** except U+D800 through U+DFFF (the UTF-16 surrogate pair range)
** except U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFE, U+2FFF ... U+10FFFE, U+10FFFF
** except U+FDDD through U+FDEF (some historical screw up with Arabic)

The choice for special characters < U+20 is because XML defines acceptable text as all valid Unicode code points >= U+20, and U+9, U+A and U+D. The normalization is because XML defines that all line ending sequences are normalized to U+A.

See: [[Unicode In 5 Minutes]] for a brief introduction to Unicode.

==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||empty => false, all other values => true||
|-
|integer||A simple conversion of the initial characters to an integer||
|-
|real||A simple conversion of the initial characters to a real number||
|-
|uuid||A valid 8-4-4-4-12 is converted to a uuid, all other values => null uuid||
|-
|string||unity||
|-
|binary||raw representation of the characters||
|-
|date||An interpretation of the string as a date||
|-
|uri||An interpretation of the string as a link||
|}

==== Serialization examples ====
<pre>
<string>The quick brown fox jumped over the lazy dog.</string>
<string>540943c1-7142-4fdd-996f-fc90ed5dd3fa</string>
<string /> 
</pre>

=== binary data ===
A chunk of binary data.
The serialization format is allowed to specify an encoding. Parsers must support base64 encoding. Parsers may support base16 and base85.
==== Conversion ====
{|
||'''type'''||'''rules'''||
|-
||boolean||empty => false, all other values => true||
|-
||integer||len < 4 => 0, otherwise first four bytes are interpreted as a network byte order integer||
|-
||real||len < 8 => 0, otherwise first eight bytes are interpreted as a network byte order double||
|-
||uuid||len < 16 => null uuid, otherwise first sixteen bytes are interpreted as the raw binary uuid||
|-
||string||the raw binary data interpreted as utf-8 character data||
|-
||binary||unity||
|-
||date||n/a||
|-
||uri||the raw binary data interpreted as a utf-8 serialized link||
|}

==== Serialization examples ====
<pre>
<binary encoding="base64">cmFuZG9t</binary> 
<binary>dGhlIHF1aWNrIGJyb3duIGZveA==</binary> 
<binary /> 
</pre>

=== date ===
A specific point in time. Intervals or relative dates are not supported. The serialization and parser only understand ISO-8601 numeric encoding in UTC. The time may be omitted which will be interpreted as midnight at the start of the day.
==== Conversion ====
{|
|'''type'''||'''rules'''||
|-
|boolean||n/a||
|-
|integer||seconds since epoch||
|-
|real||seconds since epoch||
|-
|uuid||n/a||
|-
|string||standard serialization format||
|-
|binary||n/a||
|-
|date||unity||
|-
|uri||n/a||
|}

==== Serialization examples ====
<pre>
<date>2006-02-01T14:29:53.43Z</date>
<date /> 
</pre>

=== uri ===
A link to an external resource. The data is expected to conform to [http://www.ietf.org/rfc/rfc2396.txt rfc 2396] for interpretation, meaning, serialization, and deserialization.
==== Conversion ====
{|
||'''type'''||'''rules'''||
|-
||boolean||n/a||
|-
||integer||n/a||
|-
||real||n/a||
|-
||uuid||n/a||
|-
||string||standard serialization format||
|-
||binary||n/a||
|-
||date||n/a||
|-
||uri||unity||
|}

==== Serialization examples ====
<pre>
<uri>http://sim956.agni.lindenlab.com:12035/runtime/agents</uri>
<uri /> 
</pre>

== Containers ==
Containers is a special data type which can contain any other data type including other containers.

=== map ===
A map of key and value pairs where key ordering is unspecified and keys are unique. The key is always interpreted as a character string and any character string is acceptable. If there are any elements in the map, it is serialized as a key followed by an atomic or container value. For every key, there must be one value.
Well formed and valid serialized maps may contain more non-unique keys. When a deserialized, the implementation should choose one of the the value objects, but that choice is not specified.
==== Serialization example ====
<pre>
<map>
<key>foo</key>
<string>bar</string>
<key>agent info</key>
<map>
<key>agent_id</key>
<uuid>93c73b16-cd86-434d-8b4a-76e12eee950a</uuid>
<key>name</key>
<string>testtest tester</string>
</map>
</map>
</pre>

=== array ===
An ordered collection of data members. Any member can be any atomic or container type.
==== Serialization example ====
<pre>
<array>
<real>7343.0194</real>
<array>
<map>
<key>offset</key>
<integer>9847</integer>
</map>
<string>da boom</string>
</array>
</array>
</pre>

= XML Serialization =
MIME type: <code>application/llsd+xml</code>

When possible, prefer using us-ascii or or UTF-8 xml encoding.

XML is the "standard" serialization format, being future-proof and readable by a wide variety of tools. The XML serialization should be preferred unless profiling reveals that the [[#Binary_Serialization | binary serialization]] provides an essential performance benefit. All the serialization examples in the above sections are of the XML serialization.

== DTD ==
<div style="font-size:1.6em;"><xml><!DOCTYPE llsd [
<!ELEMENT llsd (DATA)>
<!ELEMENT DATA (ATOMIC|map|array)>
<!ELEMENT ATOMIC (undef|boolean|integer|real|uuid|string|date|uri|binary)>
<!ELEMENT KEYDATA (key,DATA)>
<!ELEMENT key (#PCDATA)>
<!ELEMENT map (KEYDATA*)>
<!ELEMENT array (DATA*)>
<!ELEMENT undef (EMPTY)>
<!ELEMENT boolean (#PCDATA)>
<!ELEMENT integer (#PCDATA)>
<!ELEMENT real (#PCDATA)>
<!ELEMENT uuid (#PCDATA)>
<!ELEMENT string (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT uri (#PCDATA)>
<!ELEMENT binary (#PCDATA)>

<!ATTLIST string xml:space (default|preserve) 'preserve'>
<!ATTLIST binary encoding (base64|base16) 'base64'>
]></xml></div>

== Example XML Output ==
This is a sample from a recently running sim (indention for readability):

<div style="font-size:1.6em;"><xml>$ curl http://localhost:12035/runtime/statistics
<?xml version="1.0" encoding="UTF-8"?>
<llsd>
<map>
<key>region_id</key>
<uuid>67153d5b-3659-afb4-8510-adda2c034649</uuid>
<key>scale</key>
<string>one minute</string>
<key>simulator statistics</key>
<map>
<key>time dilation</key><real>0.9878624</real>
<key>sim fps</key><real>44.38898</real>
<key>pysics fps</key><real>44.38906</real>
<key>agent updates per second</key><real>nan</real>
<key>lsl instructions per second</key><real>0</real>
<key>total task count</key><real>4</real>
<key>active task count</key><real>0</real>
<key>active script count</key><real>4</real>
<key>main agent count</key><real>0</real>
<key>child agent count</key><real>0</real>
<key>inbound packets per second</key><real>1.228283</real>
<key>outbound packets per second</key><real>1.277508</real>
<key>pending downloads</key><real>0</real>
<key>pending uploads</key><real>0.0001096525</real>
<key>frame ms</key><real>0.7757886</real>
<key>net ms</key><real>0.3152919</real>
<key>sim other ms</key><real>0.1826937</real>
<key>sim physics ms</key><real>0.04323055</real>
<key>agent ms</key><real>0.01599029</real>
<key>image ms</key><real>0.01865955</real>
<key>script ms</key><real>0.1338836</real>
</map>
</map>
</llsd></xml></div>

= Binary Serialization =
MIME type: <code>application/llsd+binary</code>

We also have support for binary serialization and deserialization in c++ and python. The binary format is useful when dealing where optimal parse time is necessary. Binary LLSD is the binary llsd prefix followed by a single LLSD element of any type.

<pre>
<?llsd/binary?>\n
</pre>

{| border="1"
|+ Binary element serialization
! type !! serialization !! notes
|-
| undef || '!'
|-
| true || '1'
|-
| false || '0'
|-
| integer || 'i' + htonl(value)
|-
| real || 'r' + htond(value)
|-
| uuid || 'u' + uuid || uuid is 16 bytes
|-
| binary || 'b' + htonl(binary.size()) + binary
|-
| string || 's' + htonl(string.size()) + string || notation serialization is considered valid
|-
| uri || 'l' + htonl(uri.size()) + uri
|-
| date || 'd' + htond(seconds_since_epoch)
|-
| array || '[' + htonl(array.length()) + (child0, child1, ...) + ']' || order is always preserved
|-
| map || '{' + htonl(map.length()) + ((key0,value0), (key1, value1), ...)+ '}' || order is not always preserved.
|}

<b>size()</b> is a byte count.

<b>length()</b> is a child count.

<b>htonl()</b> is a function to generate a 4 byte network byte order integer.

<b>htond()</b> is a function to generate an 8 byte network byte order double. htond is not a standard system call, but you can find a c implementation in <code>indra/llcommon/llsdserialize.cpp</code>.

= Notation Serialization =
We also have support for a serialization format meant for human readability. Parsing and formatting are currently only available in c++. Notation LLSD is the notation llsd prefix followed by a single LLSD element of any type.

<pre>
<?llsd/notation?>\n
</pre>

{| border="1"
|+ Binary element serialization
! type !! serialization !! notes
|-
| undef || '!'
|-
| true || <nowiki>'1' | 't' | 'T' | 'true' | 'TRUE'</nowiki>
|-
| false || <nowiki>'0' | 'f' | 'F' | 'false' | 'FALSE'</nowiki>
|-
| integer || 'i' str(value)
|-
| real || 'r' str(value)
|-
| uuid || 'u' str(uuid)
|-
| binary || <nowiki>'b(' str(size) ')"' raw_data '"' | 'b' base '"' encoded_data '"'</nowiki> || Base 16 and 64 encodings are supported.
|-
| string || <nowiki>" escaped_string " | ' escaped_string ' | 's(' str(size) ')"' raw_string '"'</nowiki> || When using single quotes, double quotes do not need escaping and vice versa.
|-
| uri || 'l"' escaped_uri '"' || See [http://www.faqs.org/rfcs/rfc1738.html rfc 1738] for encoding rules.
|-
| date || 'd"' YYYY-MM-DD 'T' HH:MM:SS [.FF] 'Z"' || Fractional seconds are optional
|-
| array || '[' object0 ',' object1 ',' ... ']' || order is always preserved
|-
| map || '{' string0:object0 ',' string1:object1 ',' ... '}' || order is not always preserved. The string is any supported string serialization format
|}

== String Escaping ==
Strings which contain non-printable characters delimited with quotes or double quotes require escaping. If a single quote delimited string contains single quotes, those must be escaped. If a double quote delimited string contains double quotes, the double quotes must be escaped.

To escape the delimiter character, prefix a backslash. Backslashes must always be escaped with another backslash.

"And then he said, \"I have nothing more to say on the subject.\""

'Look in "C:\\linden\\"'

The most generic escaping is to specify a hex value of the byte after a literal backslash and character 'x'. This can be used for any character and is required for all non-printable characters which do not have an abbreviation. For example:

\x0C

Serialized strings should only contain UTF-8 characters, so non-printable characters other than tab, newline, and carriage return should be avoided. However, common non-printable characters have short-hand abbreviations.

{| border="1"
|+ Notation abbreviations
! character !! value !! serialization
|-
| alert/bell || 0x7 || \a
|-
| backspace || 0x8 || \b
|-
| form feed || 0xc || \f
|-
| newline || 0xa || \n
|-
| carriage return || 0xd || \r
|-
| horizontal tab || 0x9 || \t
|-
| vertical tab || 0xb || \v
|}

== Example Notation Output ==
This is an excerpt from an agent request to enter a region serialized as notation:
<pre>
[
{'destination':'http://secondlife.com'},
{'version':i1},
{
'agent_id':u3c115e51-04f4-523c-9fa6-98aff1034730,
'session_id':u2c585cec-038c-40b0-b42e-a25ebab4d132,
'circuit_code':i1075,
'first_name':'Phoenix',
'last_name':'Linden',
'position':[r70.9247,r254.378,r38.7304],
'look_at':[r-0.043753,r-0.999042,r0],
'granters':[ua2e76fcd-9360-4f6d-a924-000000000003],
'attachment_data':
[
{
'attachment_point':i2,
'item_id':ud6852c11-a74e-309a-0462-50533f1ef9b3,
'asset_id':uc69b29b1-8944-58ae-a7c5-2ca7b23e22fb
},
{
'attachment_point':i10,
'item_id':uff852c22-a74e-309a-0462-50533f1ef900,
'asset_id':u5868dd20-c25a-47bd-8b4c-dedc99ef9479
}
]
}
]
</pre>

<pre>
[
{
'creation-date':d"2007-03-15T18:30:18Z",
'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730
},
s(10)"0123456789",
"Where's the beef?",
'Over here.',
b(160)"default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}

touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}",
b64"AABAAAAAAAAAAAIAAAA//wAAP/8AAADgAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABkAAAAZAAAAAAAAAAAAAAAZAAAAAAAAAABAAAAAAAAAAAAAAAAAAAABQAAAAEAAAAQAAAAAAAA
AAUAAAAFAAAAABAAAAAAAAAAPgAAAAQAAAAFAGNbXgAAAABgSGVsbG8sIEF2YXRhciEAZgAAAABc
XgAAAAhwEQjRABeVAAAABQBjW14AAAAAYFRvdWNoZWQuAGYAAAAAXF4AAAAIcBEI0QAXAZUAAEAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
]
</pre>

= Guidelines =

=== Questions & Things To Do ===

Would Binary be more convenient as usigned char* buffer semantics?

Should Binary be convertable to/from String, and if so how?
* as UTF8 encoded strings (making not like UUID<->String)
* as Base64 or Base96 encoded (making like UUID<->String)

Conversions to std::string and LLUUID do not result in easy assignment to std::string, LLString or LLUUID due to non-unique conversion paths.

Talk:OGP LLSD

2008-10-01T22:51:58Z

Infinity Linden:

Please add an unsigned 32-bit integer type to LLSD. LLSD XML human readability is shot when it comes to uints, and a lot of time is spent doing the Base64 encoding/decoding. See [http://jira.secondlife.com/browse/MU-18 MU-18]. --[[User:Eddy Stryker|Eddy Stryker]] 17:53, 30 September 2008 (PDT)

<hr/>

Eddy...

# how much is "a lot of time" ?
# what is the alternative binary encoding that you're recommending?
# wrt integer encoding.. can't you just assume two's complement and convert negative values to positive ones?

-- [[User:Infinity Linden|Infinity Linden]] 19:22, 30 September 2008 (PDT)

<hr/>

Hmm.. okay... how's this for an idea...

LLSD is really supposed to be an abstract syntax *yeah... i know... why are we defining int's as being signed and 32 bits wide in an abstract syntax* but the XML serialization really is an XML serialization, not the definition of LLSD. Maybe we could specify that concrete implementations of integers MUST support 32 bits of 2s complement integer (as most all modern systems do). We could then add ( signed, unsigned and IPV4) as encodings of the int element of the XML serialization, the same way that we are thinking of supporting base64 and base16 encodings of binary elements. so... where you would have something like this now:

<pre><llsd>
<map>
<key>ipAddress</key>
<binary encoding="base16">1501A8C0</binary>
<key>unsignedInteger</key>
<binary encoding="base64">/////w==</binary>
<key>signedInteger</key>
<integer>-1</integer>
</map>
</llsd></pre>

we would have something like this:

<pre><llsd>
<map>
<key>ipAddress</key>
<integer encoding="ipv4">192.168.1.21</integer>
<key>unsignedInteger</key>
<integer encoding="unsigned">4294967295</integer>
<key>signedInteger</key>
<integer>-1</integer>
</map>
</llsd></pre>

it is, however, vaguely problematic in that we would have to add annotation to LLIDL to define the preferred encoding of each element.. though we might be able to simply say that this is a detail for implementations, not the definition of LLIDL. -- [[User:Infinity Linden|Infinity Linden]] 15:12, 1 October 2008 (PDT)

Talk:OGP LLSD

2008-10-01T22:33:22Z

Infinity Linden:

Please add an unsigned 32-bit integer type to LLSD. LLSD XML human readability is shot when it comes to uints, and a lot of time is spent doing the Base64 encoding/decoding. See [http://jira.secondlife.com/browse/MU-18 MU-18]. --[[User:Eddy Stryker|Eddy Stryker]] 17:53, 30 September 2008 (PDT)

<hr/>

Eddy...

# how much is "a lot of time" ?
# what is the alternative binary encoding that you're recommending?
# wrt integer encoding.. can't you just assume two's complement and convert negative values to positive ones?

-- [[User:Infinity Linden|Infinity Linden]] 19:22, 30 September 2008 (PDT)

<hr/>

Hmm.. okay... how's this for an idea...

LLSD is really supposed to be an abstract syntax *yeah... i know... why are we defining int's as being signed and 32 bits wide in an abstract syntax* but the XML serialization really is an XML serialization, not the definition of LLSD. Maybe we could specify that concrete implementations of integers MUST support 32 bits of 2s complement integer (as most all modern systems do). We could then add ( signed, unsigned and IPV4) as encodings of the int element of the XML serialization, the same way that we are thinking of supporting base64 and base16 encodings of binary elements. so... where you would have something like this now:

<pre><llsd>
<map>
<key>ipAddress</key>
<binary encoding="base16">1501A8C0</binary>
<key>unsignedInteger</key>
<binary encoding="base64">/////w==</binary>
<key>signedInteger</key>
<int>-1</int>
</map>
</llsd></pre>

we would have something like this:

<pre><llsd>
<map>
<key>ipAddress</key>
<int encoding="ipv4">192.168.1.21</int>
<key>unsignedInteger</key>
<int encoding="unsigned">4294967295</int>
<key>signedInteger</key>
<int>-1</int>
</map>
</llsd></pre>

it is, however, vaguely problematic in that we would have to add annotation to LLIDL to define the preferred encoding of each element.. though we might be able to simply say that this is a detail for implementations, not the definition of LLIDL. -- [[User:Infinity Linden|Infinity Linden]] 15:12, 1 October 2008 (PDT)