DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=subject:from:to:in-reply-to:references:disposition-notification-to
 :content-type:date:message-id:mime-version:x-mailer;
 b=NYhnr8fE33vrN47UzDsJhzO4TqX53YcHrxqlKh3pqe4yFa5qtZVRgkaPpq4Wuzy7g9
 L1jpK3shVWCiIyeR9llm0SIz1rhBleVX3xt0R2IeVsFTQ3AYCz9lVPDHnRkGUkzVvWLz
 FR7ahYgvA9UHcRRrYcT923YiNBsRKvvo9oLII=
From: Kajikawa Jeremy <belxjander@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
In-Reply-To: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com>
References: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-C6vUEapDNy6dfwqfM09p"
Date: Wed, 18 Feb 2009 23:26:15 +0900
Message-Id: <1234967175.7560.30.camel@localhost>
Mime-Version: 1.0
Subject: Re: [mmox] A few assumptions if I may
Precedence: list

--=-C6vUEapDNy6dfwqfM09p
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I agree with gareth about having a required "core" and then working from
that
  and I am also in agreement about needing *neutral* or open standards,

 not the limited and limiting use of stuff like .NET remoting which I am
aware of
 has a limit with regards transfer of non-public data being non remote
capable.

speaking of this however also opens up the use of C# and .NET runtime as
a limitation
  since no one outside microsoft actually has ownership of anything in
the code using it.



and a true server will work with one core protocol and allow for
extensions,
  apache was built similarly and I can already expand that with existing
scripting for
  provision of the non-region services in SL.

I personally see OpenID and OAuth being usable components towards an
open grid
  infrastructure that is easily maintained.

And see dependence on the .NET runtime as sitting with a permanent
hammer ready
 to drop at any time. (loss of msft,  what happens to that runtime?,
new owner?)

Also Im finding myself primarily hamstrung in my own work due to
non-code issues,
  and the real world need for paying work that actually pays on time.

if anyone wants to hire me to actually get things done quicker...
*please do so*

Im not knowing the "Snow Crash" book(s?) that are referenced by the
OpenSIM group,
  Ive also tried to play with the libSecondLife before the
LibOpenMetaverse naming.
 (very unsuccessfully) and I am currently working with python which is
letting me get
 somewhere.

I get the feeling like I will be burning braincells before I actually
get to be at any of the
  "real" discussions or get a decent handle on the vocabulary terms used
by this group
  when meetings happen (Im in Japan and have real life keeping me out of
sync with
 "Office hours" as it is).

Sincerely,
  Jeremy Kajikawa (Real)
(Belxjander Serechai (Internet))
( Freija Yoshikawa (Internet@SecondLife+OpenSIM))

On Wed, 2009-02-18 at 02:01 +0000, Gareth Nelson wrote:
> 1 - We need an absolute basic core of identity
> 2 - We need a modular design where extra services (simple stuff such
> as chat and inventory) are bolted onto that core with mechanisms such
> as optional caps URLs (man I love caps)
> 3 - On the "intellectual property" issue, we should take the view that
> if a particular system is serving up an asset, it is authorised to do
> so - in other words, if you can do (for example) an HTTP GET on an
> object, it may come with permissions flags in the metadata, but we
> should enforce these flags only on end systems - clients, inventory
> servers, asset servers and simulators - this simplifies the legal
> issues and pushes liability to where it belongs, with the users
> 4 - This should be obvious, but anything intended for an actual RFC
> should be 100% neutral of any particular virtual world/MMO or
> platform, so stuff like the .NET remoting in opensim (a pet peeve of
> mine) is out
> 5 - Binary protocols should be used whenever efficiency is important,
> but designed in an extensible fashion such that one particular packet
> type once defined will always mean the same thing and systems
> implementing such protocols can rely on a  core set of messages always
> being available with graceful degradation for anything outside of this
> core - we need not see the whole world through HTTP-tinted glasses
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox

--=-C6vUEapDNy6dfwqfM09p
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iQIbBAABAgAGBQJJnBqHAAoJECHrKutFYVwT8BcP+PndpfTmbGTeopuRrZenTzzV
1S0fQeHFgQFIcUkjz3OGonkEqE320qZO5NOBhV6bulcoKKRhCStkSDSgHwEtQIFB
nNAEqCP/hGUQEpyfHakUkhHccZ/39wY50mRopQPEjB9Wgbh4JeF0pYRtNlys7vlH
7oTZBsl8fTJkJ5C5xHgCMuQLIpE7m7NPi9N592FVcFWXDgR4m/XBmyXyf52rK81L
sq58IehX8ZMlahbEPPWbCII93qelT+k50tF9Lj06indQ5IoCRrosxPazHofeieLY
k8aM5LW+io+i+n67hgy2lh12y0Weris31rTzR/5y29RXCq5tsfK4K7HS2lh7RM5s
Noyf1u1Unhd1tl2KN2W96r00Ztg/DxMw7ZpNhe0RPAhvHFiYebjc151FjqRc1UwD
o//1zUb1Ky4Oecu4yEWYX2pjVg9kZRmzwL0UBTIuxleW5R3XYNsSR1bl9U6uENLZ
lx+4ikHcfbp/A3EUl1LqmISHuaPVPn7mhaht7WKHGeCNxOtKByX+d91gc4DfOXne
U3yy8WEnRVsXZjokas3g32E1VIuxNcWTW3GTrJ0M0Wg1c9UrV6ecyWGtrc7S1prw
N7eTuQ+QIbXzzGzsgiewjZBFNA6qFBeL3+2zRzCCSGU3wYPfvnkNt4sAAg11Xcus
BhG/l9nG6zZrbNEzQNs=
=v5XE
-----END PGP SIGNATURE-----

--=-C6vUEapDNy6dfwqfM09p--