Re: [mmox] LLSD and content schema

Lisa Dusseault <lisa.dusseault@gmail.com> Tue, 24 February 2009 00:49 UTC

Return-Path: <lisa.dusseault@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A99028C26A for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 16:49:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level:
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tRoHd1ASSuh for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 16:49:35 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 57BDB28C1C6 for <mmox@ietf.org>; Mon, 23 Feb 2009 16:49:35 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so2051818rvb.49 for <mmox@ietf.org>; Mon, 23 Feb 2009 16:49:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=986Inz51lusV3A43rpK4PQ2CB2FbK7Hy53p2UcCoA44=; b=OhBcfb8rfcVlYpV4p/pyhHLe8lRQEn9XwoonkvAErCi5YelhmeQnapTVjxhe4rJJO4 1DSXYlCMkIUALxldYajC2Gav4dPTw455fkchRzysLNfB2xJSbF/H6ZAYR8822SRKb5df e7E58oUslKNhOcC+5/b4lQ9YUrT3Q/CO0qNHA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I9igeiaVjFKSbFOlzhLkbCCC1mL5agRZCHIy12PE22hO/adPEPhJCK1gF8LNyYn4QH g4cXjoD3msA0eKIcJ9Uf7I22tw0OJJhHnTOd/Sos1KYvGuxLzAcEqsSVJnAxmXHn3VgD /5TuhY5N6C+9uDBsb403JDQSZTpFvxxooIeME=
MIME-Version: 1.0
Received: by 10.141.132.1 with SMTP id j1mr2258948rvn.277.1235436593119; Mon, 23 Feb 2009 16:49:53 -0800 (PST)
In-Reply-To: <CAAD3457-49CD-4F62-BD42-90BE79DA232D@lindenlab.com>
References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> <962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> <499F10D7.5080605@gmail.com> <CAAD3457-49CD-4F62-BD42-90BE79DA232D@lindenlab.com>
Date: Mon, 23 Feb 2009 16:49:53 -0800
Message-ID: <ca722a9e0902231649x216e71ebsfaab517a4c66ca2e@mail.gmail.com>
From: Lisa Dusseault <lisa.dusseault@gmail.com>
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
Content-Type: multipart/alternative; boundary="000e0cd295f44681f304639f7f99"
Cc: "mmox@ietf.org" <mmox@ietf.org>, Jon Watte <jwatte@gmail.com>
Subject: Re: [mmox] LLSD and content schema
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 00:49:36 -0000

Finally, a topic on which I have more than passing technical familiarity:

On Sat, Feb 21, 2009 at 1:18 AM, Meadhbh Hamrick (Infinity) <
infinity@lindenlab.com> wrote:

>  In this sense XML is more restrictive because it REQUIRES you to create a
> new DTD to extend an existing message flow (though presumably you would
> configure your DTDs or Schemas to be easily extensible.)


The way XML is used in IETF protocols certainly does not require anybody to
create a new DTD to extend an existing message flow.  E.g. in WebDAV XML
request bodies, a client may insert additional elements at certain places
(other places have defined meanings) and if the server doesn't recognize
them it just ignores them.  Same with Jabber.


>
> LLSD is intended to be used in a "loosely coupled" environment. one
> "feature" of such an environment is that systems be resilient in the face of
> heterogeneity in terms of component version. for example, consider a logging
> system that received logging messages from a number of clients and stores
> them for later analysis. when the system is initially deployed, messages may
> be defined as the tuple (source, severity, description). it is not difficult
> to imagine the situation where one client wishes to add a value to that
> tuple to make it (source, facility, severity, description). in tightly bound
> systems, you might create a new message PDU format, but both the client and
> the server would need to know about this change at exactly the same time
> (otherwise the server would signal an error when it received an unknown
> message format. now imagine the mess if half of the systems were in one
> administrative domain and the rest in another.
>
> Again, this is very much the way IETF uses XML, so I don't see this as a
distinguishing point between XML and LLSD.

Also, related to this thread, the IETF rarely does binary protocols in the
layers I've been involved in.  Clear text, perhaps with compression at a
lower layer, makes a protocol much easier to debug, maintain, test and make
interoperate.

Lisa