[vwrap] starting point - client application launch message

Meadhbh Hamrick <ohmeadhbh@gmail.com> Fri, 28 May 2010 17:32 UTC

Return-Path: <ohmeadhbh@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3853A67F2 for <vwrap@core3.amsl.com>; Fri, 28 May 2010 10:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 brWJCG7Xb0Yu for <vwrap@core3.amsl.com>; Fri, 28 May 2010 10:32:26 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6EBBB3A6862 for <vwrap@ietf.org>; Fri, 28 May 2010 10:32:26 -0700 (PDT)
Received: by gyh4 with SMTP id 4so1184564gyh.31 for <vwrap@ietf.org>; Fri, 28 May 2010 10:32:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=fdk6ixA92y2E6JsYBI6QFqNDam//NLTNYJPS5TpoQgE=; b=VASeJR0JmWQ2unMiir2J97i/wPj1v0cFjkWpDuv26aySUL4QF9i8IbBaGS/g67weP5 4mqW+YMhFipztAKOPCN7TohB4SyG1PIN+Xy+DnoHsXd3wWxjzEguddsyvea2WI68LNIM HKqWI8lq/onsfP3HeqoyvxDwd6H53IDZRrVa8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; b=f7/OyJHy7zEl0q/OUpDg7RnhwZl5SYj4Hj0ZRFoTvC4eFHUYcbzXOdcJkdMbVPjnnX Uu2Ii/bYfO/4j2vWGnN+QU8yGeWF+JQ8qu3gNLOL/iTa5qHHk8ulSlkAm23jtbwx+IyH JzDaZrs60cUhJetN0x1mRdJA4Ji5GY0Cnda34=
Received: by 10.224.115.34 with SMTP id g34mr414262qaq.135.1275067933462; Fri, 28 May 2010 10:32:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.189.208 with HTTP; Fri, 28 May 2010 10:31:53 -0700 (PDT)
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Fri, 28 May 2010 10:31:53 -0700
Message-ID: <AANLkTinMc89HxrlNOwLW0m1PQ3cOfaaErfbUUljGbnqA@mail.gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: vwrap@ietf.org
Subject: [vwrap] starting point - client application launch message
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2010 17:32:31 -0000

hmm... strange... the gmail interface puts this message in the same
thread as the others even though it has a different subject line. i'm
changing the subject line even further to try to detach it from the
original thread.

just a quick FYI as to why the CALM message draft exists. The CALM
message draft defines a mime type and format of a message that goes
across the net. The stated use case, to leverage an existing web
authentication structure via OAuth or OpenID, is important to a number
of people in the working group.

I think that's good enough reason to specify it. The last I talked
with John, we were both going to support it. When I left Linden there
were plans to support it in Snowglobe, though obviously I'm not in the
position to task Oz and Merov these days.

It's important to note that it is an informational draft. It's out
there to describe one way of doing things, and it doesn't obligate
anyone to implement it. But putting this specification in front of the
working group allows those of us that do want to use it the ability to
publish what we're doing and solicit comments about it's contents and
use.

I totally get that you're not hip to the spec, and that's okay. I'm
not trying to force you to love it or implement it. Just trying to
explain why some of us other people out here do actually like the idea
of it.

So... to recap:

* it's a useful use case.
* the draft (and subsequent RFC) is required to register the MIME type.
* it describes a message used by two or more implementations.
* it's an informational draft, and is thus entirely optional.
* we're not trying to say the CALM draft is "done," only that we think
it's a good use case and want to use the current draft as a starting
point

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com



On Fri, May 28, 2010 at 7:52 AM, Morgaine
<morgaine.dinova@googlemail.com> wrote:
> This is a new discussion thread with a new subject line, as Barry requested.
>
> I gave three documents a Yes and two a No, the meaning of "Yes" being as
> Barry said, that they represent a viable starting point --- many large
> changes (to some) will be needed before the "Yes" drafts are anywhere near
> to being correct and useful though:
>
>> Introduction and Goals - yes
>> Trust Model and User Authentication - yes
>> Abstract Type System - yes
>
> Now regarding my two "No" responses, meaning "not adequate for group
> consideration":
>
>> Client Application Launch Message - no
>> Foundation - no
>
> "Client Application Launch Message" -- this simply has no business being
> part of the VWRAP protocol suite at all.  Launching applications is
> completely outside of our remit I believe, and undoubtedly there will be a
> large number of ways of achieving it, depending on the platform.  The
> closest I think we might get to this area is to define the meaning of a
> "landmark" entity (as an URI in the protocol), but blessing one particular
> use of such an entity is quite unnecessary.
>
> "Foundation" --- I gave this a "No" because it appears to be an
> "archeological OGP" document, unearthed from the original days of OGP.  It
> does not reflect the OGPX or VWRAP group discussions at all, and is even
> oblivious of the group charter --- notice its attempt to create a single
> "vast, Internet wide virtual world".
>
> What's more, we already have a foundational document --- it's called
> "Introduction and Goals".  Admittedly it's not a very friendly document
> either as background reading nor for the implementer, but nevertheless its
> purpose was to provide the foundation, I believe.  Perhaps the new
> "Foundation" document was a gentle attempt at saying "Unreadable" to the
> first document, and asking for a refactoring?  If so then I'd support that,
> because currently "Introduction and Goals" is a meandering document with
> little clarity of purpose.  Perhaps "Introduction and Goals" should be
> renamed "Protocol Elements" and have all its background sections removed,
> which would then leave room for an "Introduction" document that would
> provide background and glue for everything else, but no details.
>
> I get the feeling that a big refactoring is due.  Documents have been
> appearing out of the blue without any prior discussion of their need or of
> their scope, as a result of which we currently have a random checkerboard of
> documents, and nothing outside of the type system is particularly well
> described or useful so far.
>
>
> Morgaine.
>
>
>
>
>
> =========================================
>
> On Thu, May 27, 2010 at 2:14 AM, Barry Leiba
> <barryleiba.mailing.lists@gmail.com> wrote:
>>
>> It's time to think about which pre-WG documents the working group is
>> ready to adopt.  As I introduce this, I want to stress that adoption
>> of documents does NOT mean that the group has consensus on the current
>> content of those documents, that it collectively agrees with what they
>> say, that the documents are in any sense "ready".  All it means is
>> that the working group thinks they're headed in the right direction,
>> and can be used as a starting point for further refinement.  Indeed,
>> documents adopted as starting points by the working group might have a
>> number of significant revisions before they are declared "ready" and
>> are sent to the IESG.
>>
>> That said, the chairs would like to take a poll on whether the
>> following are ready for adoption on their next revisions:
>>
>> * Introduction and Goals
>> http://tools.ietf.org/html/draft-hamrick-vwrap-intro-01
>>
>> * Trust Model and User Authentication
>> http://tools.ietf.org/html/draft-hamrick-vwrap-authentication-01
>>
>> * Abstract Type System for the Transmission of Dynamic Structured Data
>> http://tools.ietf.org/html/draft-hamrick-vwrap-type-system-00
>>
>> * Client Application Launch Message
>> http://tools.ietf.org/html/draft-hamrick-vwrap-launch-00
>>
>> * Foundation
>> http://tools.ietf.org/html/draft-lentczner-vwrap-foundation-00
>>
>>
>> Please reply in this thread as in this example, listing each document
>> and giving your opinion:
>> > Introduction and Goals - yes
>> > Trust Model and User Authentication - yes
>> > Abstract Type System - yes
>> > Client Application Launch Message - yes
>> > Foundation - yes
>>
>> Please make your opinion either "yes" (the working group should adopt
>> the document) or "no" (the working group should not adopt the
>> document).
>>
>> Please do not discuss anything else in this thread.  If you need to
>> discuss your answer, please start a new thread, with a new subject
>> line, for the discussion.  If you have any issues you prefer to bring
>> to the chairs off-list, contact us at <vwrap-chairs@tools.ietf.org>rg>.
>>
>> Thanks very much.
>>
>> -- Barry, as chair
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>